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
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
Google App Engine入門：実践編
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
Python Hack : 噛めば噛むほどおいしくなるクロージャの話
最近 JavaScript を書く機会が増えているが、それに従って自分のコーディングスタイルが少しづつだが変化してきているのが分かる。もともと「コードの読みやすさ」や「実行効率」にとことんこだわるタイプだが、（JavaやC++になくて）JavaScriptやRubyにあるクロージャや無名関数が私のコーディングスタイルにとてもマッチしているからだと思う。 簡単な例を紹介しよう。Pythonで書かれた config.py というモジュール。config.yamlという設定ファイルを読み込んで Dictionary として返す config.get() という関数。普通に実装すると、以下のような感じになる。 import yaml _config = None def get(): global _config if not _config: data = open('config.yaml')
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
「Flash vs. HTML5」という構図がはっきりと見え始めたぞ、と
業界関係者（特にスマートフォン関係の仕事をしている人たち）少し前からすでに気がついていた話だが、今回のAdobeからの一連のアナウンスメントで明らかになってきた「HTML5対Flash」という構図。とてもワクワクする戦いだ。 ウェブ上のリッチコンテンツという分野でリーダーシップ・ポジションを取りながらも、「無料Flashゲーム」と「ウェブサイトの見栄えをちょっと良くするアイ・キャンディ」というニッチなポジションに一度は追いやられるように見えたFlash（数年前の話）。しかし、動画フォーマットがReal Networks、Microsoft、Appleの三強いの間で中に浮く隙間を付いた戦略で、見事に「ウェブ上のマルチメディアのデファクト・スタンダード」のポジションをがっちりつかんだかに見えるFlash（現在）。しかし、その地位も安泰ではない。 Adobeにとって一番頭の痛い問題はiPhone
Life is beautiful: Google Chromeに関してひとこと
今回Googleが発表したウェブ・ブラウザー、Google Chromeは、ひと言で言えば、「安定度・安全度を高めるために、それぞれのタブを別プロセスで走らせるタブ・ブラウザー」である。 ９５年にIE3.0を設計した時には、タブのコンセプトも存在せず、セキュリティの問題もそれほど強く意識していなかったので、ウィンドウごとに１スレッドを割り当てたマルチ・スレッドを選択した訳だが、ここまでウェブ・アプリケーションが重要になってくると、マルチ・プロセスに移行するのは当然。特定のページ上でのJavaScriptの挙動がおかしくなったからと言って、ブラウザーすべてが落ちてしまう今までの設計が異常。 一つのウィンドウ下で管理させるそれぞれのタブにプロセスを割り当てる、一般的に一つのウィンドウに一つのプロセスやスレッドを割り当てる通常のGUIアプリケーションとは異なるが、ユーザー・モデルとリソース管理は
そば屋の味はカレーライスを売り始めた時から下降線をたどる
今日もいくつかPhotoShareに関するブログエントリーを見つけたのだが、その中でもとてもうれしかったのがこれ。 あとはタイトルを付けて「完了」ボタンをタップするだけ。めちゃくちゃ簡単に投稿できます。【 iPhoneのキラーアプリになりそうな写真共有アプリ「Big Canvas PhotoShare」（もとまかApp Selection 第７回） - もとまかのiPhone・iPod touch戯れ日記より引用】 増井君と一緒にPhotoShareのアーキテクチャの設計した際に、もっとも力を入れたのが「どうやったらこれ以上簡単にすることは不可能なぐらいに簡単に写真を投稿できるようにできるか」という部分。その意味では、「めちゃめちゃ簡単」という言葉は最高の褒め言葉。 この手のアプリを作っていると陥りがちなのが「機能のてんこもり」。特に他のサービスと比較されることを意識し始めてしまうと、「敵
iPhoneアプリを作る際に注意すべき５つのポイント
毎日のように「iPhoneアプリでApple Design Awardを取るぞ！」と騒いでいるので、知り合いに「それって（現実が分かっていない）大学生のノリですよ」と指摘されてしまった私だが、マイクロソフトを２０００年に退社してからは、ひたすらモバイル・組み込みの世界で仕事をしてきた私としては「俺が取らなくて誰が取る？」という気分。その超楽天的な態度が彼が言うところの「大学生のノリ」なのだろう。 市場に受け入れられるアプリを作るためには、もちろん「誰にどんな価値を提供するのか」が一番大切。しかし、そこには残念ながら成功の一般方程式はないので、今日は比較的に一般化しやすい「どう作るか」という部分に関して、まとめることにした。 1. ユーザーの利用シーン・使用パターンを良く考えて作る パソコンやゲームコンソール向けのソフトと大きく違うのが、ユーザーの使用パターン。iPhoneに限らず、携帯電話
Life is beautiful: 複数のbookmarkletの機能を一つにまとめた「シオレット」
Bookmarkletの存在を知ってから、いくつか気に入ったものをインストールしたり、自分で作ってみたりして遊んで来たのだが、普通のウェブページへのリンクも含めて数が増えてくるとツールバーが一杯になってしまい、使い勝手がぐっと悪くなる。 そこで、いくつかのBookmarkletの機能を一つにまとめた、メタBookmarkletを自分のために作ったのだが、せっかくなので、ここで公開。名づけて「シオレット」だ（bookmark=しおり）。 【シオレットのインストールの仕方】 [シオレット] ← このリンクを右ボタンでクリックして「お気に入り/bookmark」として追加する。左ボタンでクリックしてしまうと、シオレットがこのページ上で動いてしまうので注意（その場合は、グレーの部分をクリックすればメニューを閉じることができる）。 追加する場所としては、Firefoxの場合は Bookmark To
優秀な主婦はイベント・ドリブン（event-driven）方式でパンを焼く
昨日のエントリーで、「人は一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する」と書いたが、「パンを焼く」という仕事を例に取れば、こんな風になる。 １．イーストを３０℃のお湯と一つまみの砂糖とまぜて１５分間予備発酵させる ２．ボールに強力粉、予備発酵させたイースト、砂糖、塩を入れて良く混ぜる ３．こね板の上で生地をこねる ４．ボールにラップをして室温で１時間発酵させる（一次発酵） ５．適当な大きさに生地を分割し、丸めて形を作る ６．オーブンに入れ、３０分発酵させる（二次発酵） ７．オーブンの温度を２００度にして１８分焼く これは、ソフトウェアで言えば「手続き型のプログラム」であり、人間が一連の作業を把握するのに最も適した記述の仕方である（その証拠に、実際のどのレシピブックを見ても、レシピは必ず「手続き型」で書かれている）。 興味深いのは、このレシピにおける、「１５分予備
Life is beautiful: Amazon AffiliateがGoogle AdSenseに勝てる理由
今まで、このブログでも何回もGoogleとMicrosoftを比較して、Googleにばかり軍配を上げてきた私だが、Googleに弱点が全く無いと思っているかというと決してそんなことはない。そこで、今日はこのブログでも採用しているAmazon AffiliateとGoogle AdSenseとを比較した場合、どうして私が「長い目で見たらAmazon Affiliateの方が強いかも知れない」と思っているかを述べてみたい。 まずは、このブログでの過去数ヶ月の実データを元に、Amazon Affiliateの結果をまとめると以下のようになる。 ・測定単位： 10万ページビュー ・クリック数： 約2500クリック ・注文数： 約150点 ・アマゾンの売り上げ： 約25万円 ・紹介料： 約1万５千円 まあ妥当な数値である。クリック率は約2.5%。クリックから実際の注文へのコンバージョン率は約6%で
Life is beautiful: プロトタイプ作りの効用
私の関わっているプロジェクトの一つに、「全く今まで存在しなかった形のデジタル・エンターテイメントを実現しよう」というとても楽しいプロジェクトがある。この手の大きなプロジェクトを成功させるには、「大きな夢を共有しつつ、同時に一つ一つ着実に駒を進めていくこと」が大切なのだが、なかなか簡単ではない。特に、まだ「最終的に目指すもの」のイメージがちゃんと共有されていないので、各チームの動きがちぐはぐなのだ。 そこで、私が「プロジェクトメンバー向けに、目指すライフスタイルのイメージ・ビデオを作ろう」と提案しているのだが、なかなか理解してもらえない。「プロジェクトが立ち上がったばかりなのに、そんなものはまだ作れない」とか、「もう少し見えてきてからにした方が良いのではないか」という否定的な意見が出るのだ。今日は、そんな人たちへのメッセージ。 私がもの作りをするときは、常にユーザー・インターフェイスのプロト
Life is beautiful: Web 2.0な人たちへの英語勉強法：podcast編
アップルが発表してから遊びたくて仕方がなかったのが podcast。特にiPod nanoを入手してからはなおさらだ。しかし、残念なことに私には音楽を作る才能もないし、社内会議を公開するのに社員に賛成してもらえるとは思えない。それならば、クリエイティブ・コモンズでライセンスされている音楽でも見つけて独自のラジオ番組でも作るかな、と考えたいたところに、梅田望夫さんが絶好のエントリーをしてくれた。 Web 2.0時代を生きる英語嫌いの若い人たちへの英語勉強法:リスニング編 かつての同僚のAdam Bosworthのスピーチを車で聞くのも良かろうとダウンロードの準備をしているとき、気が付いた。このサイトのコンテンツはクリエイティブコモンズでライセンスされているではないか。つまり、オリジナルのpodcastを作るのに絶好のコンテンツなのである。 そこで、さっそくpodcast用のRSSフィードを作
Google Map で遊ぶ（２）：東京観光案内
昨日に引き続き、もう少し Google Map で遊んでみた。今日作ったのは、東京観光案内。独断と偏見で選んだ東京の名所１２箇所の衛星写真を、解説付きで見られるようにした。 【東京観光案内】 （←これをクリックする） 昨日のサンプルとの違いをまとめると、以下のようになる。 １．Google は東京の地図をまだサポートしていないので、最初から衛星写真モードで始まるように、map.setMapType(_SATELLITE_TYPE); という一文を入れた。この辺りに関しては、少しドキュメントが不十分だったので、フォーラムで答えを見つけた。 ２．上部に行き先ボタンを表示し、onclick イベントに応じて、目的地を中心に持ってくるようにマップをスクロールさせてから、解説をポップアップさせている。 ３．openInfoWindowHtml HTML テキストを渡す時に、幅を指定した DIV に入
Life is beautiful: Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ
最近、「これからのウェブ・アプリケーションはAjaxだ」という声を良く聞く。ソフトウェアを生業としているエンジニアとしては、この手の「流行もの（hype）」に触れた時には、表面的なものに踊らされずに、その本質を自分なりにしっかりと捕らえて消化・吸収して自分のものにしなければいけない。今までも、「オブジェクト指向」、「マルチ・ティアー・アーキテクチャー」、などの言葉が一人歩きするたびに、「これからは○○だ」とか「○○の時代は終わった」などと、過激なことを言って読者の目を引こうとだけするマスコミや企業のマーケティング戦略に数多くの人が踊らされてきた。 そんなノイズだらけのメッセージに混乱させられた結果、「Ｃではオブジェクト指向のプログラミングは出来ない」と信じているエンジニアがいまだに沢山いることは全く嘆かわしいことだ。「オブジェクト指向のプログラミング」は、設計姿勢・プログラミングスタイルに
Life is beautiful: 日本語とオブジェクト指向
先日、日経BPの出版局の方と話をする機会があったのだが、私がマイクロソフトでウィンドウズ９５の開発に関わったことに触れた際、「ユーザーインターフェイスの設計において、日本人であることで何か役に立ったことはありますか？」と聞かれた。日本人であることがプラスになったとは思わないが、ふと思い出したことがある。当時、「日本語はオブジェクト指向な言語だな」と思ったことである。 その当時（９０年代初頭）、アップルの方が使い勝手に関しては一歩も二歩もマイクロソフトより進んでおり、そのためには、もともとゼロックスが提案しアップルが商品化した、「オブジェクト指向ユーザーインターフェイス」の考え方を、より推し進めるしかないという戦略で、ウィンドウズ９５のユーザーインターフェイス（当時は Object-Oriented Shell と呼ばれていた）の開発をしていた。 「オブジェクト指向ユーザーインターフェイス」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RSSフィードを「森」として視覚化してみた