Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
「戦略的OS」の開発がことごとく失敗している点に関する一考察
９０年代にIBM、Microsoft、Apple各社が巨額の開発費を投じて作っていた「戦略的OS」がすべて失敗してしまったことを皆さんはご存知だろうか？ IBMが作っていたのはOS/2。元々はMicrosoftとの共同開発だったが、途中で仲違いをしてしまい、最後はIBMだけが細々とサポートしていたことすら覚えていない人が多いとは思うが、Windows95の成功であっというまに市場から消えてしまったのがOS/2。具体的な数値は公開されていないので分からないが、両社が数百人体制で数年間開発していたので、少なく見積もっても日本円で数百億円は投じられたことは間違いない。 Cairoの方は私自身が初期のころにいたこともあるし、最終的には「Chicago(Windows95のプロジェクト名) vs. Cairo」の戦いの最前線にいた私としては知りすぎている点も多いのだが、一つだけ確かなのは、プロジェク
「言論の自由」の大切さに関して一言
民主党は18歳未満の若年者が犯罪に巻き込まれるのを防ぐため、インターネット上の違法・有害サイトの削除をプロバイダーなどに義務付ける法案の国会提出に向け、党内調整を始めた。自殺勧誘や、児童買春の温床とされる出会い系や児童ポルノなどに簡単にアクセスできないようにする狙い。与党との共同提出も視野に入れており、今月召集の通常国会での成立を目指す。 検討中の法案では、サイト開設者やプロバイダーは違法情報を発見し次第、削除しなくてはならないと規定。違法かどうか明確でなくとも、有害な恐れがある場合は児童が閲覧できなくなるような措置を講じるよう義務付ける。罰則を設けることも視野に入れる。 【NIKKEI NET（日経ネット）：主要ニュース−各分野の重要ニュースを掲載より引用】 弾さんも指摘していたが、この民主党の発言は先進国の政党としては許しがたい発言。イギリスやアメリカなら法案どころか、それを臭わす発言
Life is beautiful: 会社のカルチャー作りの大切さ
University Washington で Executive MBA のコースを受けることにした理由の一つは、成功する企業とそうでない企業を分ける要因を私なりにちゃんと理解したかったからである。 Microsoft 時代に Bill Gates の下で働くことにより、業界の流れを読んだり、それに基づいた企業戦略を立てることに関しては、それほど不自由を感じなくなった。しかし、いざ自分で起業をしてみて強く感じたのは、企業戦略を立てることは「初めの一歩」でしかなく、その戦略に基づいてちゃんと利益を生み出す組織を作りあげる方がその何倍も何十倍も難しいということ。 色々と反省する点はあるのだが、あえて一番反省している部分を上げるのであれば、会社のカルチャー作りに十分な注意を払って来なかったこと。戦略に関わる mission statement や vision に関しては常にはっきりと語り続け
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
ソフトウェア・パテント不要論
今日、家に帰ってみると、Georgia Institute of Technology （ジョージア工科大学）から、Inventors and Their Inventions: Understanding the Innovation Process というアンケート型の質問状が届いていた。過去数年間に、米国・ヨーロッパ・日本でパテントを申請した人の中からランダムに抽出したサンプルだという。 質問の内容は、なぜパテントを申請したのか・その発明にどのくらいの時間をかけたのか・その発明は実際の商品に活用したのか、などのありきたりのものだったが、最後に自由にコメントを書いてほしいという欄があったので、そこでソフトウェア・パテントに関して徹底的な批判を加えておいた。 前にもこのブログで書いたことがあるが、ソフトウェア、ユーザー・インターフェイス、そしてビジネス・プロセスに関してのパテントは認める
ウェブサービスAPIにおける『成りすまし問題』に関する一考察
先週の末に、はてなのウェブ・サービスAPIを使ったMash-upアプリをFlash上で作り始めていきなりつまずいたのが、Cross-Domainセキュリティ。satoshi.blogs.comから取得したswfファイル上のActionScriptからb.hatena.ne.jp下にあるRSSフィードだとかXML-RPCにアクセスができないのだ。 「確か方法があったはず」と調べてみると、はてな側がサーバーにcrossdomain.xmlというファイルを置いて明示的にCross-Domainアクセスを許可していなければならない、という。そこで見つけたのが、「Flashから各APIの操作、データのロードができるよう、サーバ上に「crossdomain.xml」というポリシーファイルの設置をお願いしたい。」というはてなアイデアへのリクエスト。2006年の2月にリクエストが出されているのだが、11月
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
習作UI: 縁日の金魚を再現してみた
Flashでプログラムを書く機会があったら一度は作らねばと思っていたのが、鳥や魚の群れ（flock）のシミュレーション。そこでカスタムクラスのプログラミングの練習も兼ねて作ったのがこれ。アルゴリズムそのものは、良く知られた（１）仲間と同じ方向に泳ごうとする気持ち、（２）仲間と一緒に泳ごうとする気持ち、（３）衝突を避ける気持ち、をそれぞれの魚に持たせて泳ぐ方向を少しずつ変化させる、というものである。 プログラムはそれほど時間をかけずに作ることができたのだが、苦労したのがそういった「気持ち」の部分を表現するのに必用な具体的なパラメーター（どのくらい離れた仲間まで認識しているか、どのくらいの距離までの接近を許すか、など）を見つけ出す部分。金魚すくいの水槽の中の金魚の動きをちょうど良い感じで再現するためのパラメーターを見つけるのにかなりの試行錯誤が必要であった。 しかし、これを作って思ったのは、F
ドリコムの「ジョブボード」を試してみた
「なかのひと」サービスを使って、企業からのアクセス一覧を簡単に見ることができるようになってくると（参照）、どうしても考えたくなるのは「このブログを訪れる人たちに最も効果の高い広告は何か」ということである。 今までAmazonアソシエイトやGoogle AdSenseなどを試してきてつくづく感じるのは、「読者層をはっきりと意識した広告」の効果の高さである。Google Adsenseにまかせっきりの広告はほとんどクリックされないが、書評に貼り付けたAmazonの広告は、単にクリックする人がたくさんいるだけでなく、実際のセールスにもつながる。 その意味では、一度ぜひとも試してみたかったのが、求人広告。今までも、「就職・転職活動に役に立つブログの書き方」、「『あなたもレールから外れてみませんか』」と言う気もないが」、「知的労働者には『組織を移る力』がある」、「自分がやりたいことと会社にとって必要
JavaFX Script 入門、とりあえず言語仕様に目を通してみた
CNetでも報道された通り、Sunが独自のスクリプト言語JavaFX Scriptを発表した。テクノロジーの優劣だけで決まるものではないので、この試みがうまく行くかどうかは何とも予測しがたいが、とりあえず言語仕様が公開されたので目を通してみた。 私なりに興味深いと思った点は以下の５つ（ただし、私なりの拡大解釈が多少入っている可能性もあるので要注意）。 １．宣言型のUIをサポートしていること 宣言型大好き人間の私としては、この方向性は大賛成（ちなみに、UJMLも宣言型のUI言語^^）。"押してね！"というラベルがついたボタンを表示するには、こう書けば良い。 Frame { content: Button { text: "押してね！" action: operation() { System.out.println("押してくれて、ありがとう"); } } visible: true } ２
マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
Life is beautiful: Googleの強さはStructured Chaosにあり
今週号のFortuneの特集記事（原文へのリンク）は、"Chaos by Design"というGoogleのマネージメントスタイルに関する記事。GoogleのBusiness Operationの上級副社長は、Shona Brownという元マッキンゼーの女性。1998年にCompeting on the Edge: Strategy as Structured Chaosという本を書き、イノベーションを起こすには、会社を「カオス状態」と「きちんと構造化された状態」の間の "structured chaos"(構造化されたカオス)と呼ぶ状態に置くのが一番良いと説いたのだが、Googleが今ある状態はまさにそれ、というのがこの記事の論点だ。 今考えてみると、Microsoftも、９０年代の前半から中盤の、Windows95、IE3.0、IE4.0を出した時期は、まさに"Structured C
Life is beautiful: JSON COMETでリアルタイム・ページビュー・カウンターを作ってみた
最近Linuxの勉強もかねて作っているのが、超シンプルなアーキテクチャーのHTTPサーバー。そこそこ動き始めたのだが、それだけでは面白くないので、サーバー側からイベントに応じてデータをPushできるCometの機能を足してみた。 ストレステストのために、昨日からこのブログにこっそりとテスト用のIFRAMEを貼り付けてあったのだが（そのおかげで、バグを三つばかり見つけることができた―感謝、感謝^^）、安定して動き始めたので、見栄えを整えてこのブログの右上に貼り付けてみた。 題して、「リアルタイム・ページビュー・カウンター（RPV Counter）」。Totalはこのカウンターをリセットしてからのページビューの数、Currentはその時点でこのブログを見ている人の数（ただしノイズあり）、PeakはCurrentの過去最大値だが、ページを再ロードせずとも、それぞれのカウンターが自動的にアップデー
Life is beautiful: ドラッカー博士著「経営者の条件」は、会社経営者のための本ではない
先日、ダイヤモンド社の人と会う機会があったのだが、その時に出たのがドラッカー博士の「経営者の条件」という本の話。題名が「会社経営者のため」の本という誤った印象を与えるために、読者層が偏っているらしい。ドラッカーファンとしては、これは何とかしなければならない。ということで、今日はその誤解を解くためのエントリー。 原題は "The effective executive"、直訳すれば「成果のあげられるエグゼクティブ」。日本語にしにくいのが、このエグゼクティブ。決して「経営者」でもなければ「管理職にある人」でもない。立派なスーツを着た商社マンのことでもない。一言でいえば、「なんらかの意思決定をする立場にある知識労働者」のことである。（この業界で言えば、「次のプロジェクトはRubyを使った開発に切り替えるべきか」、「次世代テレビにはどんな機能を盛り込もうか」、などなどの意思決定） ドラッカーが他の
プロトタイプを重視するカルチャー
最近、UIEJのメンバーの間で「うみがめ」というGoogleの「20%ルール」に相当するルール作りの話が盛り上がっている。ルール作りはおおいに結構なのだが、「なぜうみがめが必要か」というプリンシプル（相当する良い日本語がないが、あえて選ぶなら「筋」－詳しくは「プリンシプルのない日本」参照）を見失って「ルールのためのルール作り」に陥らないで欲しい、というのが私からのお願いである。 そこで、今まで私がプロトタイプ作り、ベータ版サービスの重要性に関して言って来たことをまとめてみた。 １．UIEのような会社にとって何よりも大切なものは、賢くてクリエイティブな人。そんな人たちが働きたいと思うような、そして彼らがクリエイティビティを最大に発揮できるような環境を提供することが大切。 ２．本当のイノベーションはごく少人数でおこすもの。一人とか二人とかのクリエイティブな人が、「こんなもの作りたい」という情熱
Life is beautiful: Edward Tufteに学ぶプレゼンのスキル
「スティーブ・ジョブスに学ぶプレゼンのスキル」は、このブログの人気エントリーの一つだが、ことプレゼンに関して私が師と仰ぐのはEdward Tufteである。日本ではあまり名が売れていないようだが、米国では「データのプレゼン技法」に関しては第一人者で、本も何冊も書いているし、全米各地でセミナーも行なっている。 私自身も、一日セミナーに参加したことがあるが、膨大な量の実例を集めて、それぞれのどこが優れているか、どこがダメなのかを的確に分かりやすく説明してくれるTufteは、まさに「プレゼンの神」であった。彼からは色々なことを教わったが、特に心に残り、今でも常に実戦しようと心がけていることは、 ・文字に頼らず、図を効果的に使うこと ・一度に見せる情報量を絞ること ・意味を持った色使いをすること の三つである。特に最後の「色も情報を運ぶことができる」という点は、それまで意識したことがなかっただけに
「色に情報を運ばせる」テクニック
昨日のエントリーで、プレゼンの資料において、「色に情報を運ばせる」ことについて簡単に触れたが、少し説明が不十分だったと思われるので、具体的な例をあげてもう少し分かりやすく説明しよう。 まずは下の図を見て欲しい。 ブログに関わる人たちをグループ化した図だが、グループが三階層に分かれることと、その数が上位層になるほど数が少なくなることを表現する、という目的はきちんと果たしている。 問題は色使いである。せっかくカラー画面を使ってプレゼンをするのだからと、色を着けたのだろうが、色分けそのものは何の役も果たしていない。「役目はないが、無駄ではなかろう」というのが通常の考え方だが、Tufteはそれを「情報量の無駄使い」と呼ぶ。彼ならば、こんな「色使い」を薦めるだろう。 上位層に行けば行くほどブログとのかかわりが「濃い」ことを色の濃淡で表している。つまり色情報がちゃんと役割を果たしているのだ。それに加え
子供達にだけ聞こえる超音波着メロ
「授業中にはケイタイの電源は切るように」 こんな規則は今や世界中の学校にあるが、そんな規則の裏を書く特殊な着メロを使う子供たちがイギリスで増えているらしい。 Pupils perform 'alarming' feat - Metro.co.uk（英文） 人間の耳はある程度以上の周波数の音（超音波）を聞き取ることは出来ないが、その上限の周波数には個人差があり、特に年齢が大きく影響する。２０才を超えた辺りから、ちょうどボーダーラインの１８～２０KHｚが聞き取りにくくなるのである。 イギリスの子供がそれを利用して作った「子供達にだけ聞こえる超音波着メロ」が、イギリス中の子供達に大流行だという。授業中にその着メロがなると、子供たちは聞こえるのだが、先生には聞こえないために、それがおかしくてクラス中がクスクスと笑い始めるのだそうだ。
StarOffice/OpenOfficeがMicrosoft Officeに勝てない理由
このことは以前から書こうと思っていたのだが、誤解を招かずに説明するのが難しいので、しばらく棚にしまっておいた。しかし、今回「Blue Ocean Strategy」（日本語訳：ブルーオーシャン戦略）を読み始めて、なかなか良い表現を見つけたので、それを利用して説明する。 詳しくは、この本の第二章、「Analytical Tools and Frameworks（分析のためのツールとフレームワーク）」を読んでいただくのが一番良いが、あるマーケットを見たときに、既存の商品の「主要な要素（principal factors）」を抽出して、そこで真っ向から血みどろの戦いを挑むのが「red oceanの戦い」であり、逆にその要素から幾つかの項目を思い切って切り捨て、それとは別に新しい価値を生み出す要素を追加して、真っ向からの戦いを避けるのが「blue oceanの戦い」なのである。 この観点から St
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
