neu.Node リリースのお知らせ
去年の暮れから準備を進めて来た neu.Node だが、ようやく今日、オープンソース・プロジェクトとして github に公開することができたので報告する。 https://github.com/snakajima/neunode 詳しくは README.md ファイルに書いたが、neu.Node は iOS 上で Node.js の API を使って作った マイクロ・サーバーを走らせる仕組みである。iTunes ストアで配布する iOS アプリに組み込んでも良いし、自分や仲間だけで楽しむ「手作りアプリ」に組み込んでいただいても良い。ライセンスは MIT で、ライセンス料フリーで、非営利・商用、無料・有料の区別なく使える。 neu.Node が目指すのは、新しい形の分散コンピューティングである。「モバイル・デバイスはクライアント、サーバーはウェブ・サービス」という垣根をとっぱらい、全てのモ
日本のケータイが「ガラパゴス化」した本当の理由
「ガラパゴス」という言葉が今年の流行語大賞の候補に選ばれたということを聞いていたので、密かに受賞しないかと期待していたのだが、残念ながら大賞は逃したようだ（もし大賞に選ばれていたら、私が受賞することになったのかどうかの疑問はこれで解けずに終わってしまった）。しかし、この言葉をずいぶん前から使っている私としては、この言葉が一人歩きしているようでなんとも言えない気持ちなのでひと言。 まず最初に断っておくと、私が２００１年のCTIA（米国の携帯電話業界で一番大きなカンファレンス）のスピーチでこの言葉を使った時は、単に日本という「単一民族で、国民の大半の生活レベルが同じで、家電とか携帯電話のようなガジェットに流れるお金が比較的多い」という特殊な環境で、iモードを中心に「ケータイ・ライフスタイル」が異常なスピードで進化をとげていることを表して、「ガラパゴス現象」と呼んだだけのこと。決してネガティブな
Oracleの「Android訴訟」についてひと言
今日のこちら（米国西海岸）でのもっぱらの話題は、Oracleの「Android訴訟（詳細）」だが、これに関しては、私も含めて「やはり来たか」と見ている専門家は多い。 そもそも、スマートフォン以前の携帯電話用のJavaがプラットフォームとして成功しなかった理由の一つは、J2MEが根っこのところで、NTTドコモ独自のDoJaとモトローラ主導のMIDPに分岐してしまったことにあるし、同じJ2ME間でも実装の差異が大きく "write once, run everywhere" が机上の空論になってしまったことにある。Sunがちゃんとリーダーシップを発揮できなかったためである。 その意味では、J2ME/MIDPとコンパチビリティがなく、Sunから正式にJavaをライセンスしていないAndroidはけしからん、というのは（今はOracleの一部になった）Sunから見れば当然のこと。 「J2MEの時に
スタートダッシュ型仕事術：実践編
昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部
もし日本のメーカーが iPhone を発売していたら..
iPhoneは会社から支給されて使っていますが、非常に使い勝手がいいです。 ただ、これでは、いまほど欲しくならないことはたしかですね。 他の機種と同じ土俵の上に上がってしまっているので、「なんかいろいろ機能がごてごて付いてる中の携帯の一つ」というところでしょう。 つまり、「売れるモノも売れなくなる」、「売り方次第」ということを今更ながら思い知らされました。
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
iPhoneに関するアンケート調査結果
まず最初の質問は、「iPhoneを持っていない理由を教えてください」だが（注：このアンケートはiPhoneを持っていない人たちにたいするアンケート）、結果は以下のように「ソフトバンクでしか使えないから」が大半という結果になった。予想外に低かったのが「今持っている携帯で満足している」と答えた人。これを見る限りでは「まだ買い替えの時期じゃないから」と合わせると８０%もの人がiPhoneの潜在ユーザーということになる。NTT DoCoMoがiPhoneを採用することになれば、iPhoneの普及率が一気に伸びる事はほぼ間違いなさそうである。 次の質問は「iPhoneをさわったことがありますか」という質問。興味深いのはこの「ちょっとだけある」というユーザーの多さ。他の携帯の数字がないので比較しようがないが、友達が持っていたりすると「ちょっとさわらせて」となるのがiPhoneの強みなんだと思う。 三番
「戦略的OS」の開発がことごとく失敗している点に関する一考察
９０年代にIBM、Microsoft、Apple各社が巨額の開発費を投じて作っていた「戦略的OS」がすべて失敗してしまったことを皆さんはご存知だろうか？ IBMが作っていたのはOS/2。元々はMicrosoftとの共同開発だったが、途中で仲違いをしてしまい、最後はIBMだけが細々とサポートしていたことすら覚えていない人が多いとは思うが、Windows95の成功であっというまに市場から消えてしまったのがOS/2。具体的な数値は公開されていないので分からないが、両社が数百人体制で数年間開発していたので、少なく見積もっても日本円で数百億円は投じられたことは間違いない。 Cairoの方は私自身が初期のころにいたこともあるし、最終的には「Chicago(Windows95のプロジェクト名) vs. Cairo」の戦いの最前線にいた私としては知りすぎている点も多いのだが、一つだけ確かなのは、プロジェク
そば屋の味はカレーライスを売り始めた時から下降線をたどる
今日もいくつかPhotoShareに関するブログエントリーを見つけたのだが、その中でもとてもうれしかったのがこれ。 あとはタイトルを付けて「完了」ボタンをタップするだけ。めちゃくちゃ簡単に投稿できます。【 iPhoneのキラーアプリになりそうな写真共有アプリ「Big Canvas PhotoShare」（もとまかApp Selection 第７回） - もとまかのiPhone・iPod touch戯れ日記より引用】 増井君と一緒にPhotoShareのアーキテクチャの設計した際に、もっとも力を入れたのが「どうやったらこれ以上簡単にすることは不可能なぐらいに簡単に写真を投稿できるようにできるか」という部分。その意味では、「めちゃめちゃ簡単」という言葉は最高の褒め言葉。 この手のアプリを作っていると陥りがちなのが「機能のてんこもり」。特に他のサービスと比較されることを意識し始めてしまうと、「敵
"Less is more"なもの作りと合議制と
ズバリ言ってしまうと既存機能に上乗せする企画は通すのが簡単だし、リスクが少ないからだ。【機能やボタンが多すぎ!! 使いにくいUIのデジタル家電が発売されてしまう本当の理由 - キャズムを超えろ！より引用】 こういった罠にハマらないためには、色々とすべきこと・してはいけないことがあるが、たぶん最も強く意識すべきは「合議制では良いものは作れない」という法則。デザインに関わる人が多ければ多いほど、「いろいろな意見」が寄せられてしまい、「せっかく有意義な意見を出してもらったのだから」と次々に意見を取り入れているうちに、機能だけはたくさんあるけど魂が無くて妙に使いにくいものが出来てしまう。 その意味では、37signalsの人たちが言うところの「less is more」は「単に機能を削って使いやすくする」というだけの話ではなく、「企画に関わる人の数を削って魂があるものを作る」というもの作りの過程そ
Life is beautiful: 日本語の進化について、一つの実験をしてみる
年配の人が「最近の若者の言葉はめちゃくちゃだ」と言うのは、言葉が進化しているから。誤用する人が増えて来て、多くの人に通じるようになれば、りっぱな日本語だ。その過程で年配の人が「わかもの言葉」に違和感を持つのは当然。そんな「新しい日本語」を発掘してみるというのも楽しそうなので、一つ実験をしてみる。 下の６つの文を、あまり深く考えずにさらっと読んで欲しい。そして違和感を感じたかどうかをコメント欄なり、ブックマークコメントでいただきたい。「最初に読んだ時は違和感を感じなかったけど、もう一度読み直してみたらどれが変なのか気がついた」、「どれに問題があるかは言われれば分かるけど、別に通じるからいいじゃん」、「普通に使ってたけど、これって間違ってたの？」という返事もOK。 ・そこの公園で子供が遊んでいる ・そこのクラブで彼女が踊っている ・そこのコンビニでおでんが売っている ・そこの畑でキュウリがなっ
ユーザーに尋ねても必ずしも正しい答えは返ってこない
今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち
会議での「先送り助け舟」が本当に迷惑な点について
私は基本的に会議はきらいだが、特にアジェンダがはっきりと決まっていない会議だとか、何も決定を下さない会議が大嫌いである。そんな中でも、もっとも許せないのが「提案を文書にする」「次のミーティングを設定する」などの一見建設的だが、実は単に意思決定を先延ばしすることを許容するだけの「助けにならない助け舟」である。 営業部長「こうなると選ぶ道はAかBしかありませんね」 社長 「そうは言っても色々と難しい面もある」 技術部長「ここで、決めるしかありませんね」 社長 「そんな簡単な話ではないだろう」 営業部長「そんな悠長なことを言っている暇はありません」 社長補佐「まあまあ。じゃあ、まずは営業部長に彼の提案を文書にしてもらうというのは、どうでしょう」 技術部長「文書にするって、今さんざん話したばかりで、もう分かっているじゃないか」 社長補佐「そうあわてずに。文書にしてもらえば見えてくることもありま
Life is beautiful: 悪徳マルチ商法の被害者をインタビューしてみた
先日、ひょんなことから悪徳マルチ商法の被害者（２４才、男性、四大卒、現在ニート）をインタビューする機会があった。社会人になりたての若者を餌食にする巧みにしくまれたワナ。表面上は合法的なマルチ商法を装っているが、その実質はねずみ講だ。この手の悪徳商法は決して今に始まったものではないが、これだけ教育が充実し、ネットに情報があふれる時代になったにも関わらず被害者が続出するのを放置しておくのは、このブログで常日頃から発言をしている身としては許せない。そこで、今日は、そんな被害者を一人でも少なくするための私なりの試み。 その青年と話して何よりも驚いたのが、彼自身が被害者だということにまったく気付いていないこと。現在ニート生活中の彼いわく、「自分が本当にやりたいと思う仕事をするためには、生活の基盤が必要。その基盤作りのためにこのネットワークに参加した。もう少し傘下の会員を増やすことができれば、何もしな
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
「色に情報を運ばせる」テクニック
昨日のエントリーで、プレゼンの資料において、「色に情報を運ばせる」ことについて簡単に触れたが、少し説明が不十分だったと思われるので、具体的な例をあげてもう少し分かりやすく説明しよう。 まずは下の図を見て欲しい。 ブログに関わる人たちをグループ化した図だが、グループが三階層に分かれることと、その数が上位層になるほど数が少なくなることを表現する、という目的はきちんと果たしている。 問題は色使いである。せっかくカラー画面を使ってプレゼンをするのだからと、色を着けたのだろうが、色分けそのものは何の役も果たしていない。「役目はないが、無駄ではなかろう」というのが通常の考え方だが、Tufteはそれを「情報量の無駄使い」と呼ぶ。彼ならば、こんな「色使い」を薦めるだろう。 上位層に行けば行くほどブログとのかかわりが「濃い」ことを色の濃淡で表している。つまり色情報がちゃんと役割を果たしているのだ。それに加え
ビル・ゲイツの家のトイレは流そうとすると「本当に流しますか？」と警告してくる
今回のみずほ証券による株の誤注文事件は、１株を６１万円で売るところを、オペレーターが誤って「６１万株を１円で」と誤入力してしまったのが原因だが、その際に端末には市場価格との隔たりを示す警告が表示されたにもかかわらず、オペレーターが「（警告が）よく出るので慣れの中で結果的に無視してしまった」という点が注目に値する。 以前にも、「事故防止の難しさ」というエントリーで触れたことがあるが、「不必要な警告をしょっちゅう見ているとそれに慣れてしまい、本当に対応が必要な時にも無視してしまう」というのは人間の性である。この手のミスをした人を一方的に非難したり、「これはヒューマン・エラーでした、今後はこのようなことを繰り返さないように注意します」と謝るのは簡単だが、それでは根本的な事故防止はできない。 「不要な警告」と言えば、パソコンがその代表選手。ファイルを消去した時の「本当に消去したいですか？」という警
Web2.0時代らしいエンジニアのクリエイティビティの引き出し方
Foxnews の "Lerning From Google" という記事を読んだ。特に目新しいことは書いていないのだが、その冒頭に書いてある、 The top executives at Google recently admitted that they kind of let their employees invent and develop whatever they think is cool and the company has no problem putting it online to see what happens. 【意訳】Googleの重役たちは、エンジニア自身がカッコいいと思うものであれば、何であれ（誰にも了解を取らずに）作ってしまって良く、会社としてもそれをそのままサービスとして公開してしまってユーザーがどう反応するかを試してみる、というやり方が全然かまわ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
