今日は日経BPのセミナー（参照）で、iPadと電子出版の未来について講演をしてきた。私の講演の内容に関しては、一両日中にネットに上がると思うのでここには書かないが、この講演およびその準備段階を通して学んだとても大切なことを一つ書こうと思う。それは日本の出版社に迫る「コンテンツのガラパゴス化の危機」である。 午後の部でヤッパの伊藤氏の講演を聞いていて少し疑問に思ったので、フォーマットのオープン化に関する質問をした私だが、彼の「まだコンテンツの数が少ないのでオープン化を考慮する必要はない」という返答でヤッパの狙いが明らかになった。セルシスと同じく「クローズドなフォーマットによるコンテンツの抱え込み」である。 ここまでフォーマットのオープン化（すなわち誰でもビューアーをライセンス・フリーで作れること）の大切さが叫ばれている今、時代に全く逆行するビジネスモデルだが、漠然とした危機感を抱いてはいるが

iPadに関しては、あまりにも私が予想した通りだったのであまり書くこともないが、「聴く、観る、遊ぶ、読む、撮る」という普通の人たちの生活のネットやモバイル・コンピューターが関わってくるなかで、これだけ確実に完成度の高い製品を出してくるAppleには、本当に関心してしまう。 ジョブズ自身もプレゼンで述べていたが、「MacBookとiPhoneの間にプロダクト・カテゴリーはあるか？」という疑問は、Apple内部で長いこと検討されて来たことは明確である。「とりあえず出して市場の反応を見る」戦略とは大きく違い、「なぜこんな商品が必要か？」「なぜAppleがこの商品を出さなければならないのか」と考えに考えた結果、インパクトの強いものだけを出してくるのがAppleである。 最近の唯一の失敗と言えば、Apple TVだが、これもカテゴリーとしては決して間違ったものではなく、タイミングとディール不足が原因

ここの所、「クラウド」という言葉が一人歩きしているようなので、言葉の定義を明確にして業界関係者間のコミュニケーションをスムーズにすることを試みてみたい。 クラウド・コンピューティング もともとは、すべての計算をクライアント側で行う「デスクトップ・コンピューティング」に対して、（しばしば雲の形で図式化される）ネット上のサーバー側で計算してしまうことを表すために生まれた言葉。しかし、後述の「クラウド・サービス」の普及とともに狭義・広義・誤用・バズワード化が進み、今や「ユビキタス」と同じぐらい使っている人によって意味が異なる言葉になりつつあるので要注意。 クラウド・サービス アマゾンのec2、GoogleのApp Engineのようにサーバーの能力を従量課金方式で提供するサービスのこと。自社サーバーやレンタルサーバーと比べて、初期投資の面でもスケーラビリティの面でも優れていることが特徴。 クラウ

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

Ruby on Railsに代表されるDRY（Don't Repeat Yourself）スタイルのフレームワークは、手っ取り早くサイトを立ち上げるのにはとても便利だ。特にRailsのActive Recordの様に、ランタイムにダイナミックにコードや設定ファイル（もしくはそれに相当するもの）を生成してくれる仕組みは、情報を一カ所のみに記述することによりミスを減らすという意味でもアジャイルな開発という意味でも重要である。 ただ、この手のフレームワークを使う場合に一つ気をつけなければならないのは、それがスケーラビリティの面で商用に耐えられるものか、という点である。特に、その手のダイナミックなコードや設定ファイルの生成（Railsの場合だとデータベース上のテーブルのスキーマに基づいたActive Recordクラスのダイナミックな生成）が、最初にサイトにアクセスが来た時に一度だけ実行されるもの

先日、地震速報のフィードがないものかと気象庁のホームページを探していてこんな記述を見つけた。 （財）気象業務支援センター 天気予報や天気図、注意報、地震情報などの即時情報は（財）気象業務支援センターから必要経費によりオンラインやファックスなどで入手することができます。 データの種類や料金などの詳細については（財）気象業務支援センターのホームページに掲載されていますのでご覧下さい。 普通に考えれば、オンラインでのデータの配布コストは限りなくゼロに近いのだから、税金を使って集めた気象情報や地震速報などはRSSやJSONのフィードとして気象庁のホームページから無料で配布して当然である。　ところが実際には、FAXや電話でしか情報が流通できなかった時代の名残りか、気象業務支援センターという財団法人が一括して、それも有料で配布を担当しているのだ。 ならば、さっさとそんな仕組みは廃止して気象庁から直接フ

今週に入ってから、ようやく少し本気で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')

Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの

先日のMVCの議論の際には、私自身いろいろと勉強させていただいたが、少し心配になったのは、「MVCの定義だって時代とともに変わる」「ウェブサービス用のMVCはSmalltalk時代のMVCとは異なるもの」「MVCなんか理解してなくてもアプリケーションが作れればいいじゃん」など、そもそも「MVCとは何か」どころか「デザイン・パターンとは何か」を理解していないんじゃないかと思われる発言が見られたこと。ということで、今日はデザイン・パターンについてひと言。 デザイン・パターンとは、（業界に蓄積されたノウハウに立脚した）何かを作る際の指針のこと。ソフトウェアに限らず、ものを作るときにはさまざまな（場合によってはお互いに矛盾する）要求条件や制約が課せられるわけだが、そんな時に過去にさまざまな事例を解決してきた先人の知恵を「パターン化」してノウハウとして身につけておけば、似たような事例に出会った時に効

昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ

先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避

業界関係者（特にスマートフォン関係の仕事をしている人たち）少し前からすでに気がついていた話だが、今回のAdobeからの一連のアナウンスメントで明らかになってきた「HTML5対Flash」という構図。とてもワクワクする戦いだ。 ウェブ上のリッチコンテンツという分野でリーダーシップ・ポジションを取りながらも、「無料Flashゲーム」と「ウェブサイトの見栄えをちょっと良くするアイ・キャンディ」というニッチなポジションに一度は追いやられるように見えたFlash（数年前の話）。しかし、動画フォーマットがReal Networks、Microsoft、Appleの三強いの間で中に浮く隙間を付いた戦略で、見事に「ウェブ上のマルチメディアのデファクト・スタンダード」のポジションをがっちりつかんだかに見えるFlash（現在）。しかし、その地位も安泰ではない。 Adobeにとって一番頭の痛い問題はiPhone

CNet/WSJにも書かれていたが（参照）、DellがAndroidを使ったスマートフォンのリリースに向けて着々と準備を進めているらしい。 Microsoft/Intel連合がOSとチップセットという組み合わせでパソコンビジネス（ハード）への参入障壁を極端に低くし、大量の新規参入組と自然淘汰により一気にパソコンの低価格化・コモディテぃ化が進んだことは記憶に新しいと思うが、それと同じような波がようやく携帯電話の世界に押し寄せて来ている。 ここに来てはっきりと見えて来たことがいくつかある。 Androidにより参入障壁が大幅にさがり、中国・台湾・韓国などからメーカーが大量に参入してくる そういったメーカーに製造をまかせ、自分はデザインとブランドだけで勝負する企業も参戦する（Dellはだぶんここに位置することになる） スマートフォンとそれ以外の境があいまいになり、フルブラウザーを搭載するのがあた

Internet Explorer 3.0/4.0 の開発に関わっていた人間として言うのも変な話だが、そろそろIEには主役の座を降りてもらった方が良いと思っている。いろいろな要因がからみあって今の状況があるわけで、その部分について今さらここであれこれ言うつもりはないが、実際のところ、 IEが他のブラウザー（Safari/Firefox/Chrome/Opera)と比べてHTML5やCSS3のサポートに関して大きく遅れている そもそもIEの進化のスピードが（というかMicrosoftから出る製品すべての進化のスピードが）遅すぎる にもかかわらずIEのシェアが大きいため、業界全体の足を引っ張っている という現状があることは誰にも否定できない。 HTML5やCSS3の新しい機能により可能になる新しいウェブアプリをどんどんと作って行きたいと考えているエンジニアは私だけではないわけで、その意味では「

９０年代にIBM、Microsoft、Apple各社が巨額の開発費を投じて作っていた「戦略的OS」がすべて失敗してしまったことを皆さんはご存知だろうか？ IBMが作っていたのはOS/2。元々はMicrosoftとの共同開発だったが、途中で仲違いをしてしまい、最後はIBMだけが細々とサポートしていたことすら覚えていない人が多いとは思うが、Windows95の成功であっというまに市場から消えてしまったのがOS/2。具体的な数値は公開されていないので分からないが、両社が数百人体制で数年間開発していたので、少なく見積もっても日本円で数百億円は投じられたことは間違いない。 Cairoの方は私自身が初期のころにいたこともあるし、最終的には「Chicago(Windows95のプロジェクト名) vs. Cairo」の戦いの最前線にいた私としては知りすぎている点も多いのだが、一つだけ確かなのは、プロジェク