Life is beautiful: canvas 対 SVG
先日のエントリーで少し触れたが、アップルがSafariに導入してから、Webkitは当然ながら、Firefox、Operaにも標準採用されて一気に業界標準になりつつあるcanvas。iPhone上のSafariでも使えるし、Googleが先日発表したandroid上のブラウザーでも使えるとなれば、私としては色々とやってみたくなるのは当然。 問題は、同じく「ブラウザーにベクター・グラフィックスを追加する」という役目を果たすはずだったSVGの存在がこれで怪しくなってきたこと。そもそもが、FlashキラーとしてAdobeが全面的に押していたSVGの戦略的な価値が、AdobeによるMacromediaの買収でなくなってしまったところに合わせた様に来たcanvasの対等。一気に形成が逆転だ。 SVG派の人たちに言わせると、「SVGは既に業界標準だし、記述型でないcanvasはJavascriptとの
Life is beautiful: 「便利になるとストレスが上昇する」という不思議なジレンマ
週末の夕方。東京都内の広告会社で営業を担当する佐野裕美子さん（２３）＝仮名＝は、仕事を終えると気の合う友人２、３人に携帯メールを送る。 「いま何してる？」 送り終わると、すぐに返信確認。１分、２分、３分…何度も操作を繰り返す。返事が来たら食事に誘う。５分も返事が来なければイライラする。「早く決めたいから、すぐ返信がほしい。自分が待てなくて嫌な思いをしているので、わたしはいつも即レス（即答）です」 【【溶けゆく日本人】快適の代償（１） 待てない人々 数分間でイライラ (1/4ページ) - MSN産経ニュースより引用】 これと全く同じことが、アメリカでBlackberryを持つビジネスマンにも起こっている。私も３年ほど前にしばらく持ち歩いていたのだが、あまりにもイライラするので持つのをやめてしまった。 Blackberryを持つと会社のメールに２４時間いつでもどこでもアクセスできるようになる。
Life is beautiful: Googleからandroid SDKがリリースされたけれど...
今朝になってGoogleからandroid SDKがリリースされた。予想通りの独自VM（参照）。それも、Javaのバイトコードではなく、独自のバイトコードであるところがまるでDangerのSidekickと同じ（Danger Inc.とAndyの間で知的所有権の問題はないのか心配になってしまう）。APIが業界スタンダードであるJ2ME/MIDPと異なるところまでSidekickと同じだ。すでに、J2ME/MIDP（業界標準）、J2ME/DoJa（ドコモ独自）、J2SE（SavaJ/Sun）と３種類のモバイル向けJavaがあるところに、さらにもう一つのプラットフォームが加わることになる。１０年後にどうなっているかは予想しがたいが、ここ数年はますます混乱することは間違いない。 ちなみに、ブラウザーはやはり予想通りのWebKit。ただしJavascript VMに関しては特に興味深い情報は発表さ
androidは電気羊の夢を見るか？
普通はエントリーを書いてからタイトルを決める私だが、今回はタイトルが先。Google の android に関しては色々と書かれているが、携帯電話業界側から見た感想としては、海部さんのこれが一番端的。 そういえば、その昔、シンビアンが立ち上がったときも、日本からもドコモや端末メーカーがわんさか参加して、大騒ぎだったなぁ。で、結局一人、また一人と去っていき、最後にはノキアだけが残った。「デジャヴュ」感。【Tech Mom from Silicon Valleyより引用】 特にメンバーを見ると、Java VMで飯を食っているはずのアプリックス、BREW OSをWCDMA端末にまで広めようとしているQualcomm、J2ME/MIDPのコンソーシアムに加わっていながら独自のJava（DoJa）で先走ってしまったNTT DoCoMo、つい最近 Sony EricssonのUIQに共同出資したばかり
「au向けのiPhoneは作ってはいけない」という契約になっている（らしい）
UWで受講している"General Management & Strategy"という授業の課題の一つが「携帯電話事業」に関する"Five Forces Analysis" (新規参入の難しさ、業界内の戦いの厳しさ、などの５つの側面から業界を分析すること)。２０００年からこの業界で働いている上に、iPhoneやgPhoneに関しては誰にも頼まれてもいないのにブログで色々と書きまくっている私としては、「待ってました」という感じのテーマ。 とは言っても、何の資料も使わずに書いても説得力がないので、ネットで少し調べものをしてみたところ、思わぬ発見。今年の５月の記事(USAToday)だが、AT&TとAppleの間の契約について、公式発表には含まれていない条件が書かれている。 AT&T has exclusive U.S. distribution rights for five years —
優秀なエンジニアは「入社時のスキルを問わない会社」には就職してはいけない
ちまたで問題になっているIPAフォーラム2007に参加した学生がエントリーを書いているのだが、それが半端じゃないぐらいのエンターテイメント。 ...IT産業というよりSIerの人気がないことについて語りたいだけなんじゃないかという顔ぶれだったし... ...はてなブックマークのコメントを見ている限りでは、パネリストの方々は相当現実の見えていない発言をしているようだ。... ...ITを専攻している学生達からは、「就職時にITスキルが問われないのだとしたら、大学でやっていることには何の意味があるのか」という質問が出ていたのだけど、明確な回答はなかったと思う。その人たちは、ちょっとショックを受けていたような気がする。... ...その流れで、「入社時にITのスキルを問わないというのは、Googleのような企業の方針とは反対であるが、それですばらしいサービスを作ることができるのか」という質問が出
gPhone雑感：「モバイル・プラットフォーム戦国時代」の幕開けだ
今朝になって、話題のgPhoneがアナウンスされた（参照１）訳だが、大方の予想を裏切ってそれはデバイスではなくてソフトウェア、それも2005年にGoogleが買収したandroidという会社の作っていたLinuxベースのマイクロ・カーネルと、バーチャル・マシン。androidの買収とともにGoogleに入ったAndy Rubinがandroidの前に作ったSidekick (Danger Inc.)の中身を良く知る私としては、「これってDanger OSとどこがちがうんねん？」という感じ。 ほぼ同じ時期に会社をスタートしたこともあり、Dangerの連中とはスタートアップ当時から一緒に仕事をし、サードパーティとしてSidekick向けのソフトウェアを作った数少ない会社の一つがうちの会社UIEvolution Inc.だ（資料２）。 Javaに似てはいるが微妙に異なるバーチャル・マシンを持ち、
「CGMサービス」と「０と１で割り切れるデジタルの世界」との妙なミスマッチ
ずいぶんとスパムに攻撃されてしまっていたブログパーツ「ラーメン大好き」。ブログパーツを貼付けていただいた方々にはご迷惑をおかけしてしまったが、ようやくデータベースのお掃除をし、簡易スパムフィルターを設置させていただいた。 今回の場合は、私自身が注意を払っていない間にスパムに攻撃されてしまい、それをユーザーの方にコメント欄で指摘していただいてから対処する、ということになった。小さなサービスだし、ユーザーもそれほど多くないので大問題にはならなかったが、それでもご迷惑をおかけしたことには違いなく、反省している。 ここ２〜３年の間に「Web2.0だ、CGMの時代だ！」と星の数ほどのベンチャー企業が作られたわけだが、そこでちゃんとビジネスを成立させたり、Googleによる買収などのExitに成功させた企業はごくわずか。どうやったらそんな企業の一つになれるのかが分かれば苦労はしないのだが、その鍵を握る
広げた「大風呂敷」の大きさだけなら誰にも負けない
UIEvolutionという会社は２０００年に立ち上げたのだが、「さまざまなデバイスに、あらゆるネットワークを通して、どんなアプリケーションでも、インタラクティブなウェブアプリケーションとしてとどける」という会社のビジョンに関しては、多くの投資家から「フォーカスがなさすぎる」「マイクロソフトじゃないんだからそれは無理だろう」「一つのマーケットに絞りなさい」「夢は大きいけどどうやってビジネスにするのか理解できない」「デファクトを取るにはやたらと資金が必要」などの批判をもらったことを良く覚えている。 「会社のビジョンは大きい方が良いに決まっている」との信念で始めたからにはそこを変えるつもりは毛頭なかったが、投資家向けの説明資料には、「まずはモバイル向けのゲームでビジネスを立ち上げて」などの補足説明を加えてなんとか資金を提供してもらおうと苦労したものだ（そのために、「モバイル向けゲームの開発会社
言語学の研究をググってするというのはありなんだろうか？
たったいまNHKで、「極め付け・幕開け」は誤っており、「極め付き・幕開き」の方が正しい言い方だという話をしていた。文化庁の調査によると、「極め付き」は６割ぐらいの人が、「幕開き」は９割以上の人が間違った言い方をしているという。言葉なんて人間が決めるものなんだから、大半の人が使い始めた段階で「そちらを正しい使い方」と認めてしまうべきだと私は思っているが、今日のテーマはそれではなく、この「文化庁の調査」とGoogleの検索結果の比較。 Googleでそれぞれの言葉を検索して、見つかったページ数を調べる。 極め付け：極め付き＝121,000：103,000 （54%が誤用） 幕開け：幕開き＝1,880,000：56,100 （97%が誤用） 文化庁の調査結果ととても近い。こうなってくると、言語学を選考している学生が、Googleで調査したデータに基づいて卒論を書くというのは十分有りのような気が
交渉の場にのぞむ前にしておくべき心の準備
ネゴシエーション（交渉）に関するテクニックにはさまざまなものがあるが、その多くが「いかに自分の欲する条件に近いものを勝ち取るか」をゴールとしたもの。それはそれで役に立つのかも知れないが、私としてはどちらかというと、今読んでいる「Getting to YES（日本語訳：ハーバード流交渉術）」という本に書いてあるアプローチの方がしっくりと来る。 この本の筆者（Roger FisherとWilliam Ury）は、一般に良く使われる「交渉は勝つか負けるか」「相手に手の内を見せない」「自分はできるだけ譲らずに相手に譲らせる」などのテクニックは交渉を長引かせるだけだし、その過程で相手との信頼関係を損ねかねないと警告する。 この本にはいくつかの有効な提言が含まれているので何回かに分けて紹介したいと思うが、まず最初に紹介したいのは、交渉の場にのぞむ前に自分がしておくべき心の準備の話。 多くの場合、人は交
Apple 、iPhone用のSDKを来年二月にリリース：待望のiPhone向けのネイティブ・アプリの開発が可能に
たった今アップルのホームページで発表されたばかりの資料。Steve Jobsが自ら書いたニュースリリースだ。ざっと訳してみる iPhone向けのサードパーティ・アプリケーション 思い切って言ってしまおう。サードパーティによるiPhoe向けのネーティブなアプリケーションが欲しいんだ。２月には開発者の手にSDKを渡すつもりだ。iPhoneのまわりに活気に満ちたサードパーティ開発者のコミュニティを作り、何百もの新しいアプリケーションをユーザーに届けることにエキサイトしている。iPhoneが持つ革新的なマルチタッチ・インターフェイス、パワフルなハードウェア、そして（他の携帯電話よりも）遥かに進んだソフトウェア・アーキテクチャで、開発者にとって最高のモバイル・プラットフォームを提供できると確信している。 SDKをリリースするのが２月になってしまうのは、二つの相反するゴールを同時に達成しようとしている
Life is beautiful: Googleに就職面接に行く前に知っておくべきこと
CNet Japanを見ていて気がついたのだが、Googleが積極的に日本でエンジニアをリクルートし始めた（参照）。優秀なソフトウェアエンジニアがハードウェア企業にばかり就職してしまう日本の現状を打破するのには、良い特効薬かもしれない。 そこで、マイクロソフト本社でエンジニアの面接をしてきた経験を生かし、「私がGoogleの面接官だったら」という設定で、どんな人を採用したいかをGoogleの立場に立って述べて見たいと思う。 まず何よりも大切なのは、「Googleで働きたい」、という強い気持ち（Passion）である。「好きこそものの上手なれ」ということわざがあるが、その仕事にどのくらい夢中になれるかがエンジニアの生産性を考えた上で最も重要なファクターの一つであることはどの面接官も知っている。すると、「今の仕事がつまらない」、「上司がいやな奴だ」、「今の仕事がきつい」などのネガティブな理由で
変化をもたらす立場に立った方が有利だ、という話
読んでいた資料に出て来た William Pollard という人の発言が気に入ったのでここで紹介する。 Without change there is no innovation, creativity, or incentive for improvement. Those who initiate change will have a better opportunity to manage the change that is inevitable. by William Pollard 訳せば、「変化なしでは、イノベーションも、クリエーティビティも、より良くするためのインセンティブもない。避けることができない変化が起こる時には、変化を自ら起こす立場に立った人の方がその変化をコントロールするチャンスがある。」
Life is beautiful: 教えながら学ぶRuby: 言語を拡張したくなる衝動に関して
少しMBAの勉強の方が一段落したので、今日はRubyの勉強。「Ruby本」にサンプルとして掲載されているチャットのプログラムを色々な技巧を使って「どこまで美しくできるか」を試みるのが今日の課題。そこで悩んでしまったのが、「やたらと言語を拡張したくなる衝動」を押さえるべきかどうか。Rubyの場合、すべてのものがオブジェクトで、かつ、すでに存在するクラスにメソッドを自由に追加できるので、FixNumだとかNilClassなど基本的なクラスの再定義をすることにより、あたかも言語を拡張しているような効果を生むことが可能なのだ。 今日書いていて気に入らなかったのは下のコードの太字の部分。 while([email protected]) r,w,e = select(@socks) next if r.nil? r.each { |sock| case sock ... } } これは、select
Haloを作ったBungie StudioがMicrosoftからスピンアウトした件について
XBox360がそもそもパッとしない日本では大したニュースではないのかもしれないが、発売後わずか１週間で$300millionを売り上げたHelo3はこちらでは大きなニュースだ。先日も、スポーツクラブで「Halo3が楽しくて」と隣で話している人を見ると初老の女性二人。どうみても「典型的なゲーマー」ではない。 しかし、Helo3の売り上げよりも業界を驚かせたのは、ほぼ同時にアナウンスされた、Haloを作ったグループ「Bungie Studio」がMicrosoftからスピンアウトするというニュース。 Bungie has 113 employees. Evan Wilson, a video game industry analyst with Pacific Crest Securities, said that leading employees of Bungie had bought
「渡された仕様書を実装するサラリーマンプログラマ」の悲哀
@ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括本部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − ＠ITより引用】 これは言語の問題ではなく、日本のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーで書いたが、本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ
Life is beautiful: 会社のカルチャー作りの大切さ
University Washington で Executive MBA のコースを受けることにした理由の一つは、成功する企業とそうでない企業を分ける要因を私なりにちゃんと理解したかったからである。 Microsoft 時代に Bill Gates の下で働くことにより、業界の流れを読んだり、それに基づいた企業戦略を立てることに関しては、それほど不自由を感じなくなった。しかし、いざ自分で起業をしてみて強く感じたのは、企業戦略を立てることは「初めの一歩」でしかなく、その戦略に基づいてちゃんと利益を生み出す組織を作りあげる方がその何倍も何十倍も難しいということ。 色々と反省する点はあるのだが、あえて一番反省している部分を上げるのであれば、会社のカルチャー作りに十分な注意を払って来なかったこと。戦略に関わる mission statement や vision に関しては常にはっきりと語り続け
教えながら学ぶRuby: それでも僕は君をイテレータと呼ぶ
前回の「イテレータに片思い」、たくさんのフィードバックをいただき、とても良い勉強になっている。一人でこつこつと勉強するよりも、励みになるしずっと楽しい。 ちなみに、１問目の問題だが、 def hello(to, *mesg) print "Hello, ", to, ".\n" print "-- message -- \n" for m in mesg print m, "\n" end end これに関しては、予想した通り、ほとんどの人が私と同じく、 def hello(to, *mesg) print "Hello, ", to, ".\n" print "-- message -- \n" mesg.each { |m| print m, "\n" } end という答えにたどりついた（{..} のかわりに do..end でも良い）。圧倒的に読みやすいし、とにかく美しい。「プログ
Life is beautiful: RailsがRubyで作られた本当の理由
弾：最初の質問です。なぜRubyを選んだのですか？ DHH：極端なことを言うと，Rubyが一番美しく自分のコードが書けるからです。 【小飼弾のアルファギークに逢いたい♥：#2 Ruby on Rails作者 David Heinemeier Hansson（前編） RubyでRailsを書いたわけ｜gihyo.jpより引用】 この記事を既に読んだ方も多いと思うが、この「Rubyが一番美しく自分のコードが書ける」というセリフは非常に重要である。「イテレータに片思い」というエントリーで書いた通り、Rubyには生みの親の「コードは読みやすくあるべき」という魂がしっかりと込められており、それが「コードの美しさ」に繋がっているのである。 私がRubyを触り始めて一番強く感じたことは、Smalltalkとの類似点である。私自身、９０年に数ヶ月間Smalltalkにどっぷりと使っていた時期があるが（マイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
