日本の家電メーカーのソフトウェアの作り方や、人材の活用方法の問題点関しては、このブログでもメルマガでも何度も指摘したが、その問題を浮き彫りにするブログエントリーを見つけたので紹介する。 パナソニックを退社しました ...私の部署では、絵に描いたような昔ながらのソフトウェア開発が行われていました。 単価計算は人月とステップ数。仕様書を書く上流工程が重要で、コーディングは単純作業という価値観のもとでの開発です。当然正社員はなかなかコーディングに携わることができませんでした。 また、単純作業とみなされがちなコーディングを効率化しようとするモチベーションが少なかったのか、いくつか作業環境で疑問に思うところもありました。例えば、メモリ 1GB ぐらいの遅いマシンでビルドしている、ディスプレイが17インチ、きちんとしたソース管理がない、などです。PCスペックやディスプレイなどは入社の時期によってはそこ

ベスト・セラー「スティーブ・ジョブズ 驚異のプレゼン」の著者で、Business Week のコラムニストでもある Carmine Gallo が書いた "10 ways to sell your ideas the Steve Jobs Way!" という資料を手に入れたので、簡単に内容を紹介する。 1. 最初は手書きで考えをまとめろ いきなりパワポの資料を作らず、まずは紙やホワイトボードなどで（訳注：neu.Notes+ でももちろんかまわない^^）、プレゼンの大まかな「流れ＝ストーリー」を作るべき。つまらないプレゼンでは、観客はすぐに飽きてしまう。語るべき「ストーリー」がないうちにパワポの資料を作っても意味がない。 2. Twitter 向きの短いフレーズを使え Twitter の「口コミ効果」に関しては、いまさら強調するまでもないが、それを最大限に活用するには、１４０字以内に収まる

先週、「MotorolaがWindows Phone陣営に乗り換える可能性を示唆」というエントリーに書いた通り、あの手のアナウンスメントにはだいたい何か裏の事情がある。 そして今日、GoogleがMotorolaの携帯電話部門を買収することがアナウンスされ（参照）、その裏事情が何であったかが明らかになった。あれは、MicrosoftとGoogleを競争させて価格をつり上げるための牽制球だったのだ。 Microsoftが実際どの程度Motorolaとの話をしていたかは不明だが、１ドルでも高く売りたいMotorola側としてはGoogleから買収の話が来た時点でわざわざMicrosoftを「当て馬」として引きづり出して競争させようとするのは当然。あのアナウンスメントは、Microsoftに向けたラブコールでもあり、Googleに対する「早く良い条件で結婚を申し込んでくれなきゃ、他の人と浮気しち

先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。 https://github.com/snakajima/SNBinder SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData（JSON）を結合して HTML を生成するテンプレートエンジン」である。 ９０年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。 その方向性を究極にまで突き詰めると、サーバー側は（MVC

ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt

先月の「プレゼン専用、平置き液晶モニター」というエントリーに対しては沢山の人からフィードバックをいただいたのだが、そのほとんどがこの液晶モニターに対してではなく、私がなぜそんなデバイスが欲しいかの理由として挙げた、以下の文に対するものであった。 多くの人が勘違いをしているのだが、プレゼンの主役はパワポのスライドではなく、プレゼンをしている本人である。社内の企画会議であれ、顧客に対するセールスであれ、一番強く印象付けるべきは、提案する企画や商品ではなく、プレゼンをする自分自身なのだ。もちろんプレゼンの中身も重要なのだが、本当に重要な情報はどのみち文書で別途提出することになるので、プレゼンの段階で重要となるのは、とにかく自分を印象付け、「こいつの提案する企画に社運を賭けてみよう」、「こいつを見込んでこのテクノロジーを導入してみよう」などと思わせることである。やたらと文字ばかり並べたスライドを読

Tech Waveの「iPadに期待する米出版業界、期待すれば裏切り者扱いされる日本の業界【湯川】」という記事を読んでから色々と気になったことがあったので日本における書籍の流通の仕組みについて調べてみた。 とても参考になったのが、少し古いが「書籍の価格構成比をめぐる小考」というブログ記事。流通マージン等に関して、具体的な数字が列挙されているのがうれしい。 紙代：6％ 製版・写植代：12％ 印刷・製本代：7％ 編集コスト：3％ 版元粗利：32％ 著者への印税：10％ 取次マージン：8％ 書店マージン：22％ この数字（特に写植代と取次マージン）がそもそも電子写植・大規模店舗・オンライン店舗・チェーン店の時代に適切かどうか、という話はひとまずおいておいて、電子書籍の時代にどうなるかを考えてみる。 紙代：0％ (不要） 製版・写植代：?％ （はるかに低コスト） 印刷・製本代：0％（不要） 編集コ

Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En

気がついた人も多いと思うが、iPadのアナウンスメントであっさりと無視されたのがAdobeのFlash。私は意図的（＝「Flashなんか重要じゃない」というメッセージ）と読んだが、皆さんはどうだろうか。 iPhoneがFlashをサポートしていないことに対するAdobeを含めたさまざまな方面からの批判を考えれば、「the best way to experience the web （最高のウェブ環境）」を売り文句のiPadが、これだけ広く使われているFlashをサポートしないというのはおかしな話だ。 不思議に思う人も多いかもしれないが、自分をAppleの経営陣の立場に置いて良く考えてみれば答えは明確になる。 Appleという会社は、昔からさまざまなクリエーターたち（アーティスト、ミュージシャン、ウェブ・デザイナー、etc.）を魅力的で便利なパソコンやツールで味方につけ、彼らの作品を消費者

一つ前の富豪プログラミングのエントリーともつながる話だが、Google App Engineは「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以

Google App Engine向けのアプリを作る際に最初に悩んだのはフレームワークの選択。Google App Engineにはwebappという最低限の機能を持ったフレームワークが付いて来るが、Python使いの人たちの間では、DJangoというフレームワークが広く使われているらしいし。かといって、あまり大きなフレームワークを使うと、パフォーマンスのチューニングとかもしにくくなるし、フレームワークそのもののバグや制限に悩ませられる可能性もある。 そんな中で増井君が見つけてくれてまず試したのが、Junoというフレームワーク。DJangoと比べると遥かに小さく、WebappよりもURLのルーティングのメカニズムとかが充実している。 そこで一旦はアプリをJunoの上で作り始めたのだが、Junoのソースコードを見ているうちにいろいろと気に入らないところが出て来た。不必要にオプションが多いし、

Google App Engineを使った最初の作品 Tiny Message （http://tinymsg.appspot.com）をリリースしてまだ２０時間経っていないが、設計の過程でいろいろと学べたことがある。 その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。 もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。 リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデー

Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン

今週に入ってから、ようやく少し本気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。 Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。 イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。 そこで、「ある時点でハノイの塔ボード（三つの棒を支えている水平に置かれた板）に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、す

最近 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')