\\n<span id=\\"message\\"></span><br />\\n<input type=\\"button\\" value=\\"hello\\"\\n onclick=\\"$(\'#message\').load(\'hello\');\\"/>\\n \\n<script src=\\"http://code.jquery.com/jquery-1.4.2.min.js\\"></script>\\n<script type=\\"text/javascript\\">\\n$(function() {\\n $(\'#ready\').load(\'ready\');\\n});\\n</script>\\n</body>\\n
scriptタグをbodyの最後に持ってきているのは、JavaScriptのロードで描画を中断しないようにするためです。これで(Mockとなる)HTMLが最初に描画され、ユーザは直ぐに画面を見ることができます。
\\n動的に変える部分はreadyイベントやclickイベントで書き換えています。
readyとhelloのURLに対応するSlim3のControllerは次のようになります。
\\npublic class ReadyController extends Controller {\\n\\n @Override\\n public Navigation run() throws Exception {\\n response.getWriter().write(\\"Ready\\");\\n return null;\\n }\\n}\\n
public class HelloController extends Controller {\\n\\n @Override\\n public Navigation run() throws Exception {\\n response.getWriter().write(\\"Hello\\");\\n return null;\\n }\\n}\\n
\\nViewでサーバーからデータを引っ張ってくるので、pull architectureと呼んでいます。pullという言い方は確かWebWorkが使っていた気がします。
AppEngineでは、HTMLをstaticファイルとして登録しておくと、App Serverまで処理がわたらず手前の専用のstaticファイルサーバーで処理されるので高速です。(JSPだとstaticファイルとして登録できない)
\\n実は、App Serverに処理がわたらないとspin-upも起きないので、最初のHTMLの描画はspin-upなしで行われます。これがちょっとしたトリック。
実際のspin-upはリクエストがReadyControllerに渡ったときに起きますが、JSPを使っていないので、Jasperの初期化(5,600cpu_ms)を避けることができ、しかもHTMLの情報を含んでいない純粋に必要なデータのみをやり取りしているので、spin-up時間は非常に短いものになります。
AppEngineのログによるとindex.htmlは0cps_ms、ReadyControllerはspin-upした時でも630cpu_ms(ほぼ素のServletと同様)くらいで処理出来ています。自分が試した感じでは、spin-upした時としてない時の差は実感することができません。ほぼ同じ感じ。これは、すぐに描画が終わり、非同期でサーバーにアクセスしているせいだと思います。
次のURLで実際に試すことが出来ます。
\\nhttp://test.latest.higayasuo.appspot.com/ajax/index.html
HTMLが描画されてからReadyの文字が出るまで若干間がありますが、HTMLは既に描画済みなためほとんど気にならないでしょう。
これで完全にAppEngine for Javaに勝った気がするv(o^_^o)v ぶいっ
ただ、この方法は、自分がすべて考えたわけではなく、従来からあったのをまとめただけです。素のHTML使ってAjax使うやり方は、appengine ja nightで小川さんがやっていたと思います。後、ガラケーでは基本使えません。
","description":"AppEngineは、アクセスがあったときにアプリケーションを起動し、しばらくアクセスが無ければアプリケーションを終了させ、また次のリクエストで再起動するという仕組みを導入しています。 そのため、アプリケーションを起動(spin-up)する時間がとても重要になってきます。このspin-upの時間はpython(webapp)で60cpu_ms以下。(cpu_msはcpuが使う仮想的な時間ですがmsと同じ感じで捉えてもらってもとりあえずは大丈夫です)JavaのServletだと600cpu_msくらいです。PythonでもDjangoような大きなフレームワ…","guid":"hatenablog://entry/17680117126970905575","author":null,"authorUrl":null,"authorAvatar":null,"publishedAt":"2010-11-09T08:09:03.971Z","media":null,"categories":null,"attachments":null,"extra":null,"language":null},{"title":"AppEngineにどんなアプリが向いているのかを知ろう","url":"https://higayasuo.hatenablog.com/entry/20101108/1289206846","content":"AppEngineは、万能なプラットフォームではありません。むしろ、かなり使い道は限定されていると言ってもいいでしょう。
\\n向いていないアプリで使うとかなりはまって、アプリが完成しないリスクがあります。
\\n一方、向いているアプリで使うとこれまでよりかなり費用を節約できたりとか、儲けにつなげることができます。
AppEngineにどのようなアプリが向いているかというと、AppEngineがGoogleの既存のインフラをそのまま利用していることをまず知っておく必要があります。
\\nGoogleのインフラは、(極端に単純化すると)大量のデータを多くの人に同時に見せるために最適化されています。
\\nAppEngineも同様で、大量のデータに大量にアクセスがあっても大丈夫なように、BigtableというKVSを使っています。また、自動でスケールアウトするWebのFront Endも既存のインフラをそのまま使ってます。
\\nBigtableはGmailでも採用されていて、お世話になっている人も多いのではないでしょうか。
というわけで、インフラから見たAppEngineに向いたアプリというのは
\\n\\nものだということがわかります。難しい言い方をするとWebもデータベースも自動的にスケールアウトすることが必要なアプリということになります。
これが基本です。これから分かることは、大量にアクセスがあるコンシューマー向けサイトにAppEngineは向いていて、そうでないサイトに対しては、インフラが too muchであるということです。
\\nまた、自動的にスケールアウトするという性質が、インフラのメンテナンス要員が基本いらないということにつながります。大量にアクセスがあるサイトは、インフラにもかなり気を使い、お金を投入していることでしょう。そのコストの大部分が削減できるのはかなりのメリットですよね。
次に重要なことは、インフラのコスト削減のために、アプリごとに専用のVMを用意するのではなく、アクセスがあったときにアプリケーションを起動し、しばらくアクセスが無ければアプリケーションを終了させ、また次のリクエストで再起動するという仕組みを導入していることです。
\\n使っていないときは、リソースを消費しないので、限られたリソースを効率的に使うことができます。
\\n専用のVMを用意すると使ってなくてもその分のリソースを消費してしまいますからね。
\\nいいことばかりではなく、Sandboxによる制限があったりなどいつくかトレードオフがありますが、今回は省略します。知りたい方は、Slim3本を立ち読みしてください。
このような仕組みが何をもたらしたかというと大きく言って次の二つです。
\\n\\n
\\n従量課金も安価に提供されています。たとえば、mixiアプリの「ふにゃもらけ」は、一日680万PVを一日15$でAppEngineでさばいているそうです。一日680万PVのサイトというのはかなりアクセス数は多い方です。それを月5万以内で済ませることができるというのは、かなりお得だと言えるでしょう。実際は、もう少しなんだかんだでかかると思いますが、安価なことに代わりはありません。
安価な従量課金が可能になったおかげで、普段はあまりアクセスがないが、ピークにはアクセスが集中するようなサービスにもAppEngineは向いています。急にアクセスが集中しても自動スケーリングで乗り切れますから。
月500万PV相当までは無料というのは、手軽に何かを作りたい人にはぴったりですよねー。でも、これは罠です。あとから説明します。
上記がAppEngineのインフラの特徴から来る向いているアプリの特徴です。
AppEngineに向かないアプリを知るには、AppEngineのデメリットについて知る必要があります。
\\nそれは、BigtableというSQLではないKVSを使っているということです。デメリットには、次の二つが挙げられます。
\\n自分の経験では、Bigtableを何も知らない状態から大体使いこなせるようになるには、半年以上はかかります。半年以上も使いこなすためにかかるなんて、やってられないですよね。
\\nしかし、心配はありません。先行者達によって、Bigtableを使いこなすためのノウハウはコニュニティに蓄積されています。
\\ntwitterで #appengine をタグ(検索キーワードgaeは自分は見ていません。ノイズが多いから)に入れて、聞いてもらえれば、大抵誰かが答えてくれます。
\\nBigtableは、集計が弱い(count,min,maxは可能だけど、sumやavgができない)、前方一致以外の検索ができないという問題があります。これらの問題に対する解もあるのですが、作り込みのコストがかかるので、Bigtableの弱点を多用するような案件はAppEngineでやるのはおすすめしません。
Bigtableの使い方を覚えるのが大変という問題は、コンパクトなSlim3本を読めば解決するので、今となっては問題とは言えないでしょう。
\\nhttp://www.amazon.co.jp/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E5%BE%B9%E5%BA%95%E6%B4%BB%E7%94%A8-Slim3-Google-Engine-Java/dp/4798026999/ref=sr_1_2?ie=UTF8&s=books&qid=1280117730&sr=8-2
\\nこの本は、Slim3がタイトルに入っていますが、内容はBigtableを理解するためのことがほとんどです。Slim3を使わない人でもBigtableを扱うならオススメ。「Bigtableを使いこなせ」ってタイトルにしたかったんだけど、いろいろな理由があっていまのタイトルになっています。
月500万PV相当までは無料というのは、手軽な感じがすると思いますが、手軽さを求める人にSQLのかわりにBigtableをマスターしろというの無理があるかなぁというのが自分の意見。手軽にやりたいけど、新しいことを勉強するのもやってみたいという方なら問題ないでしょう。
それでは、結論を出すと
\\n\\n私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。
\\n
\\nソフトウェア業界(特に受託開発業界)は、基本的に正直者が馬鹿を見る世界である。顧客(あるいは経営者)が、保守性というソフトウェアの最も重要な品質を正しく評価できないという、情報の非対称性が存在するからだ。
\\n経営者やお客様は、ソフトウェアの品質を正しく評価できない。なぜなら、その人達は、訓練を受けたプロではないから。
言ってることは、かなりの部分、そのとおりだと思います。しかし、これは、ソフトウェアに限らず、普遍的な真実なんですよ。
あんなだめな仕事をしている人に比べて、自分は、ちゃんとした仕事をしている。でも、上司も経営陣もお客様もそれを認めてくれない。
\\nこれは、どんな仕事をしていてもあり得る話です。ソフトウェア業界に限った話ではない。だって、評価している人たちはプロじゃないんだから。
自分が言いたいのは、elm200さんが、どう思うのかは個人の判断なんで私は何も言いませんが、あのエントリを見てソフトウェア技術者がいまいちな職業だと、いろいろな人(特に若い人)に思ってほしくないということです。
\\n自分も、ソフトウェア技術者(プログラマ)だし、この業界にいて得られたものも多い。この職業が好きなら、続けて欲しいと思うから。
\\nこの辺は、弾さんが書いていますね。
\\n404 Blog Not Found:私がソフトウェア技術者でもありつづける理由
どんな仕事をしていても、認められるには時間がかかります。いい仕事をしていたとしてもです。いい仕事をしていたから、世間に認めてもらえるほど、世の中甘くない。でも、認めてもらうためには、良い仕事を地道にし続けるしかない。
「いい仕事をしていたから、世間に認めてもらえるほど、世の中甘くない。でも、認めてもらうためには、良い仕事を地道にし続けるしかない。」
\\n大事なことなので二度言いました。
後、blogのタイトルは変えたほうがいいと思うなぁ。もちろん、個人の自由ですが、elm200さんは、世の中の人をひきつけるエントリをかかれることが多いので、検索エンジンの上位に来ることも多いはずです。そのときに、Railsの技術情報を検索したい人の邪魔しないように。
","description":"私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。 ソフトウェア業界(特に受託開発業界)は、基本的に正直者が馬鹿を見る世界である。顧客(あるいは経営者)が、保守性というソフトウェアの最も重要な品質を正しく評価できないという、情報の非対称性が存在するからだ。\\n\\n\\n 経営者やお客様は、ソフトウェアの品質を正しく評価できない。なぜなら、その人達は、訓練を受けたプロではないから。\\n\\n\\n\\n\\n言ってることは、かなりの部分…","guid":"hatenablog://entry/17680117126970905657","author":null,"authorUrl":null,"authorAvatar":null,"publishedAt":"2010-09-26T03:59:12.598Z","media":[{"url":"https://b.hatena.ne.jp/entry/image/http://blog.livedoor.jp/dankogai/archives/51523822.html","type":"photo","width":55,"height":13,"blurhash":"LETO^L:Qd=..?vjFeTiwheh0gNg$"}],"categories":null,"attachments":null,"extra":null,"language":null},{"title":"ある程度の年齢を迎えたプログラマが生き残るには","url":"https://higayasuo.hatenablog.com/entry/20100923/1285233194","content":"ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。
\\n
\\n35才(2004年)でプログラマとしてオープンソースを始め、今年で42才になる俺が通りますよ。
\\n35才までは、SIerの中でSEをやってたので、そんなにプログラムは書いたことがないです。
上記のエントリには、いろんな戦略が書いていますが、ぶっちゃけ戦略は一番重要なことではなく、一番重要なのは、常に自分の価値を高めるために努力し続けることです。
\\n努力や挑戦をやめたら、自分の価値はどんどん陳腐化して下がっていくのは当たり前なのです。
自分がどんなことに挑戦してきたのかちょっと書いてみますね。
2004年1月、プログラマとして何か新しいことに挑戦したかった自分は、DI(Depencency Injection)とAOP(Aspect Oriented Programming)いう技術を選択し、オープンソースプロジェクトとしてSeasar2をスタートさせます。当時、DIやAOPは何が嬉しいのかあまり理解されていなかった頃です。でも直感的に良い気がしたんだよねー。特に理由はなく勘。そして、3月末にSeasar2をリリースすることになります。
DIやAOPは良いプログラミングスタイルをもたらすもので、生産性を向上させるものではないと当時思われていましたが、普及させるためには、生産性を向上させることも示さなければいけないと考え、インターフェースにAOPを仕掛け、SQLを自動生成するというS2Daoというデータベースフレームワークを思いつきます。
\\nリリースは2004年、夏くらいかな。
\\nこの後のSeasar2の普及には、S2Daoが欠かせなかったと思います。S2Daoを使いたいために、Seasar2を(仕方なく)使うという人も多かったはずです。
\\nインターフェースにAOPを仕掛けコードを自動生成するというスタイルを思いついたのは私が初めてだったはず。
データベースだけでなく、Webの部分も生産性を向上させなければいけないと考えた私は、HTMLテンプレートを使ったWebフレームワークであるS2JSFをリリースします。HTMLテンプレートを使ったフレームワークは、当時Tapestryなどいくつかありましたが、JSFという標準技術でHTMLテンプレートを採用したのは、私が初めてだったはず。その後、Faceletとか出てくるんだけどね。
\\nリリースは2005年、頭くらいかな。
2005年、Railsが徐々に人気が出てきて、設定ファイルは悪みたいな流れが出てきます。この流れに沿って、設定ファイルなしでアノテーションで設定を行うSeasar2.3をリリースしました。
\\n2005年、末くらいかな。
\\n今では、クラスパスを捜査してクラスに設定されているアノテーションを読み取る手法は、非常にポピュラーですが、Javaでこのスタイルを導入したのは、Seasar2が初めてだったはず。
設定ファイルをなくすだけでは、生産性は余り向上しないと気づいた私は、Javaの生産性を飛躍的に向上させるために、スクリプト言語のようにソースコードを修正したら、その変更が即座に反映されるHOT reloading(当時はHOT deployと呼んでました)という技術を思いつきます。Javaでこのスタイルを導入したのは、Seasar2が初めてだったはず。
\\nSeasar2.4のリリースは2006年末です。
当時、Webフレームワークの代表であるStrutsは時代遅れだと考えられていて、次々新しいフレームワークが発表されていましたが、いまいち普及していませんでした。この状況を見た私は、全く別のフレームワークを作るのではなく、Strutsをベースにbetter Strutsを作るのが世のニーズにあっているのではと考え、SAStrutsを作成します。
\\nSAStrutsのリリースは2008年のはじめのほうです。
\\nSAStrutsは、かなりの成功を収めました。今でも人気があります。
2009年4月、Google App Engine for Javaが発表になりました。これをみて、これまでの自分のテリトリーだったEnterprise Javaを捨て、Cloudに行こうと決心します。Slim3の開発が始まります。
\\nSlim3のリリースは、2010年3月くらいです。
2010年、これからの時代は、ソーシャルアプリだと思っていましたが、携帯でFlash Liteを使ったソーシャルアプリは、2010年でピークを迎える気がしていて、どうやってビジネスをやっていこうか悩んでいました。
\\nそこで発表されたのが、JobsのFlash外し(これは、後にまたひっくり返されるんですが)です。
\\nよし、これからはHTML5でソーシャルアプリだと考え、技術調査 + 新規事業を計画し、金を出してくれる人の説得を始めることになります。
で、今に至る感じ。他にも紹介していない話はありますが、だいたいはこんな感じです。
ずっと、挑戦し続けているでしょ。挑戦したから必ずしも成功するとは限らないけど、挑戦しなければ、自分が陳腐化してだめになることは間違いないです。
これは、実はプログラマに限った話ではなくて、どんなことにでも言えることだと思います。常に自分の価値を高めるために挑戦し努力し続けることが重要だということです。
9/28のGoogle Developer Day 2010では、ソーシャルアプリを作るのにGoogle App Engineがどんなに向いているかの話をします。お楽しみに。
","description":"ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 35才(2004年)でプログラマとしてオープンソースを始め、今年で42才になる俺が通りますよ。\\n 35才までは、SIerの中でSEをやってたので、そんなにプログラムは書いたことがないです。\\n\\n\\n\\n\\n上記のエントリには、いろんな戦略が書いていますが、ぶっちゃけ戦略は一番重要なことではなく、一番重要なのは…","guid":"hatenablog://entry/17680117126970905686","author":null,"authorUrl":null,"authorAvatar":null,"publishedAt":"2010-09-23T09:13:14.474Z","media":null,"categories":null,"attachments":null,"extra":null,"language":null}],"readCount":0,"subscriptionCount":1,"analytics":{"feedId":"138797766802329657","updatesPerWeek":null,"subscriptionCount":1,"latestEntryPublishedAt":null,"view":0}}')