「エンジニアの生き方」出版イベントのお知らせ偶然にも大震災の日に発売になってしまった「エンジニアとしての生き方」、ようやく出版イベントの準備ができたのでお知らせする。日時は４月２４日（日）１５：３０、場所は東京の神保町。 詳しくは上のリンク先を見ていただきたい。 ちなみに、本書に関してのフィードバックをいくつかブログなどを通じていただいたので、気がついたものはFacebookのページにリストアップしておいたので、興味のある人はどうぞ。
JavaScript HTMLテンプレートエンジン SNBinder 公開
先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。 https://github.com/snakajima/SNBinder SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData（JSON）を結合して HTML を生成するテンプレートエンジン」である。 ９０年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。 その方向性を究極にまで突き詰めると、サーバー側は（MVC
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
「リニアにスケールするように作れる」からこそのGoogle App Engine
Google App Engineを使った最初の作品 Tiny Message （http://tinymsg.appspot.com）をリリースしてまだ２０時間経っていないが、設計の過程でいろいろと学べたことがある。 その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。 もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。 リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデー
Google App Engine入門：フレームワークの選択
Google App Engine向けのアプリを作る際に最初に悩んだのはフレームワークの選択。Google App Engineにはwebappという最低限の機能を持ったフレームワークが付いて来るが、Python使いの人たちの間では、DJangoというフレームワークが広く使われているらしいし。かといって、あまり大きなフレームワークを使うと、パフォーマンスのチューニングとかもしにくくなるし、フレームワークそのもののバグや制限に悩ませられる可能性もある。 そんな中で増井君が見つけてくれてまず試したのが、Junoというフレームワーク。DJangoと比べると遥かに小さく、WebappよりもURLのルーティングのメカニズムとかが充実している。 そこで一旦はアプリをJunoの上で作り始めたのだが、Junoのソースコードを見ているうちにいろいろと気に入らないところが出て来た。不必要にオプションが多いし、
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
jQBinder, ブラウザー側でのHTML templateを可能にするjQuery plug-in
一昨日はMVCの話で妙に盛り上がってしまったが、考えてみるとModel/View/Controller間の分離が不十分という話はサーバー側だけの話ではなく、クライアント側にも言える事。事実、私自身も div.innerHTML = "<span class='red'>" + message + "</span>"; みたいなHTMLが混ざったJavaScriptコードを書く事は良くある。特に、最近はJSONとして取得して来たデータセットをリストとして表示するケースが増えて来たが、そんな時に「サーバー側のようなHTMLテンプレートが使えたらいいな」と思う事は良くある。手っ取り早くとりあえず動くものを作るのにはHTML埋め込み型のJavaScriptで良いのかも知れないが、後々のメンテナンスを考えると少なくともModelとViewぐらいはキチンと切り話しておいた方が良い事は確か。 ということ
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
HTML5時代の「運営しやすいアーキテクチャ」の話
増井君と二人でPhotoShareというサービスを立ち上げてもう１５ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS,
HTML5入門：アニメーションの実装方法３種
HTML5・CSS3のような新しい技術の問題点は、HTML4やらFlashなどの枯れた技術と違ってノウハウ・ライブラリ・ツールとかがまだ十分にそろっていない事。普及のタイミングもまだはっきりとしていないこの段階で手を出せない・出しにくいと感じている人が多いのも良く理解できる。 私から見れば、逆に「こんな楽しい状況は滅多にない」わけで、商売になるかならないかは二の次にしていろいろと試したくなる。 今日作ったのは、HTML5+CSS3上で可能になる（ただし現在ではWebkit独自の拡張を含む）３つのアニメーション・テクニックの比較（左に貼付けたものがそれ、Safari/Chromiumだとすべて動く。Firefox/OperaだとDOMとCanvasのみ（ただし別ウィンドウで開かないとCanvasが動かないークロス・ドメインセキュリティのバグか？））。 詳しくはソース（参照）を見ていただければ
「Flash vs. HTML5」という構図がはっきりと見え始めたぞ、と
業界関係者（特にスマートフォン関係の仕事をしている人たち）少し前からすでに気がついていた話だが、今回のAdobeからの一連のアナウンスメントで明らかになってきた「HTML5対Flash」という構図。とてもワクワクする戦いだ。 ウェブ上のリッチコンテンツという分野でリーダーシップ・ポジションを取りながらも、「無料Flashゲーム」と「ウェブサイトの見栄えをちょっと良くするアイ・キャンディ」というニッチなポジションに一度は追いやられるように見えたFlash（数年前の話）。しかし、動画フォーマットがReal Networks、Microsoft、Appleの三強いの間で中に浮く隙間を付いた戦略で、見事に「ウェブ上のマルチメディアのデファクト・スタンダード」のポジションをがっちりつかんだかに見えるFlash（現在）。しかし、その地位も安泰ではない。 Adobeにとって一番頭の痛い問題はiPhone
Javascript雑学：SetTimeoutについて知っておくべき事
昨日のベンチマーク・プログラムだが、MacやWindows上で走らせて60-70fps程度しか出ていない事に驚いた人も多いかも知れないのでひと言補足しておく。 あのベンチマーク・プログラムは１フレーム描画するごとにSetTimeout()を使って1msの遅延で関数updateFrameを呼び出し、実際に１秒間に何回呼び出されるかを測定している。スマート・フォン上でこのベンチマーク・プログラムを走らせると、フレームの描画の部分に30msとか40msとかが必要なので、その結果33fps、25fpsなどの測定結果が得られる。 ということは、Javascriptの実行速度が猛烈に早ければ1000fpsも可能なはずだが、どんなに高速なパソコンを使おうと、どんなに描画のロジックを単純化しようと、実測値が通常100fpsを超えることはないのをご存知だろうか。
モバイルブラウザーのデファクトスタンダードになりつつあるWebkit
最近、なぜかいろいろなところでHTML5やら モバイル端末向けのブラウザーの話をすることが多いのだが、今年になってトレンドとしてはっきりと見えてきたのは、WebKitがモバイル端末のブラウザーのデファクト・スタンダードになりつつあるということ。 私自身、最初にAppleがブラウザーを作ると聞いた時には「なんでそんな大変なことを今更？片手間でできる仕事じゃないぞ」と思ったりしたわけだが、その予想に反してAppleが見せた本気度とリーダーシップには本当に関心してしまった。 世の中にすでに何百万とあるサイトとコンパチビリティを保つというだけでも大変な作業なのに（経験者語る）、CANVASやCSS Transform/Transitionなどの新しいコンセプトを次々に導入してHTML5の標準化でリーダーシップを取っている点は注目に値する。 「スタンダードを決める」立場に自分を置く事がどのくらい重要
Ruby on Rails: なぜActiveRecordが必要なのか？
Railsの勉強がしばらくストップしてしまったので、今日はビデオを見てお勉強。Rails Envyの「ActiveRecord Tutorial」は長さも２５分とちょうど良いし、「ActiveRecordとはなんぞや」を具体例を交えて簡潔に教えてくれるのでとても良い勉強になる。 英語だが、冒頭の部分を乗り越えればあとはプログラミングの話なので、日本人にもそれほど難しくないはず。念のため、オープニングの部分のみ、超訳しておいた。 ActiveRecordのアイデアは、いったいどこから来たのか？ まずは"Active Record"の意味から （ActiveRecordではない点に注意） "Active Record"とは、デザイン・パターンの一つ。 どうやってデータベースにアクセスするか？ SQLにプログラムから直接アクセスする方法もあるが...ちょっと不便 データベースのテーブルをオブジェ
Life is beautiful: リッツ・カールトンのおもてなし
私が講演などで「ユーザー・インターフェイス」と「ユーザー・エクスペリエンス」との違いについて説明するときに、よく引き合いに出すのはディズニー・ランド、スタバ、そしてリッツ・カールトン。この三つに共通していることは、個々の設備や商品（アトラクション、コーヒー、部屋）で勝負するのではなく、そこの場所で顧客が体験するすべてのものに細心の注意を払うことによって、特殊な「場」を作りだすことによって勝負しているところ。 そんな私だから、本屋で「リッツ・カールトンで学んだ仕事でいちばん大事なこと」というタイトルの本を見かけた時にはすぐさま買い求めてしまったわけだが、なかなかするどい指摘が幾つも書かれている。 例えばこれ。 よくデパートの研修などで、全員が一列に並んで大きな声で「いらっしゃいませ」「ありがとうございました」と唱和しているシーンを見かけます。一般的には非常に礼儀正しい気持ちのよい挨拶であると
Javascriptの黒魔術＝クロージャを宮沢賢治風に説明してみる
先日のエントリーで、「Javascriptの黒魔術」と呼んだのはクロージャのこと。関数呼び出しの際に一時的に作られただけのはずのローカル変数が、ある条件が整うとその関数の実行が終わった後もゾンビのように生き延びて参照が可能、というのがJavascriptのクロージャだ。 これを宮沢賢治風に書いてみるとこんな感じになる。 ある町でふらりと一人で立ち寄ったカラオケ・スナックは、カウンター席しかないとても小さな店だが、客のノリが良くてとても気持ちよく歌えた。おかげでマイクが離せなくなってしまった私に、帰り際にマスターが「そんなに気に入ったのなら、そのマイク持って返ってもいいですよ」と言う。 言われるままに持って返ったマイクは、しばらく家のテレビの横にだらしなく置いてあったのだが、ある晩に歌番組を見ていると私がカラオケで十八番にしている曲が流れるものだから、おもわずそのマイクを手に取って歌ってみた
「渡された仕様書を実装するサラリーマンプログラマ」の悲哀
@ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括本部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − ＠ITより引用】 これは言語の問題ではなく、日本のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーで書いたが、本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
