各種ブラウザーで Java (applet) を無効にする方法
こちら（米国）では、見つかった Java のセキュリティホール（＋それを利用した実際のアタック）が大問題になり、米国政府が「ただちに Java を無効にするように」と声明を出し（参照）、全国ニュースでも大きく取り上げられている。 実質的な危険があるのは Java applet なのだが、Java と Java applet の違いの分からない報道機関は、大々的に「Java が危険」と報道しており、Sun Microsystems を買収して Java を入手した Oracle にとっては大きなブランドイメージの損失だ。Oracle は火曜日には５６カ所のセキュリティホールを塞いだパッチを提供するそうだが、そんなパッチでは、今回作られてしまった「Java は危ない」というイメージは拭えない。 どのみち、Java applet にはほとんど価値がないので、これを機会に無効にする人も多いようだ（
ザッカーバーグの面接試験２：アクティビティ・インディケーター
先日の「ザッカーバーグの面接試験：Objective-C のブロックを使いこなす」には数多くの答えをいただいたので、それに気を良くして第二問。これも iOS 用だが、先の問題と違い、この問題は初級者〜中級者向けだ。 [問題] iOS ではステータスバー上のアクティビティ・インディケーターの ON/OFF は、[UIApplication sharedApplication] の networkActivityIndicatorVisible プロパティに YES/NO をセットすることにより行います。そのため、複数の非同期通信を同時に行うアプリケーションの場合、少なくとも一つの非同期通信が行われている時だけ YES にする仕組みを作る必要があります。 そこで、NetworkActivityManager というシングルトン・クラス（インスタンスを一個しか持たないクラス）を作り、非同期通信中
スティーブ・ジョブズに学ぶプレゼンの秘訣
ベスト・セラー「スティーブ・ジョブズ 驚異のプレゼン」の著者で、Business Week のコラムニストでもある Carmine Gallo が書いた "10 ways to sell your ideas the Steve Jobs Way!" という資料を手に入れたので、簡単に内容を紹介する。 1. 最初は手書きで考えをまとめろ いきなりパワポの資料を作らず、まずは紙やホワイトボードなどで（訳注：neu.Notes+ でももちろんかまわない^^）、プレゼンの大まかな「流れ＝ストーリー」を作るべき。つまらないプレゼンでは、観客はすぐに飽きてしまう。語るべき「ストーリー」がないうちにパワポの資料を作っても意味がない。 2. Twitter 向きの短いフレーズを使え Twitter の「口コミ効果」に関しては、いまさら強調するまでもないが、それを最大限に活用するには、１４０字以内に収まる
福島第一にはメルトダウンした核燃料よりももっと危険なものがある
菅政権の内閣官房参与で、福島第一原発事故対策や原子力政策のアドバイザーだった田坂広志・多摩大学大学院教授が原発事故の教訓や今後の課題について語った講演「パンドラの箱」が公開されているので下に貼付けておく。 原子力発電を利用するというのは、その国全体にとって何を意味するのかをとても的確に表しているので、原発に賛成の人も反対の人もぜひとも見ていただきたい。特に使用済み核燃料の問題が技術的な問題ではなく社会的な問題であること、そして福島第一でもっとも危険な存在は実はメルトダウンしてしまった１〜３号機の核燃料ではなく、４号機のプールにあって取り出す事もままならない大量の使用済み核燃料であること、などが専門家の立場から的確に語られている（ビデオの40:00〜45:00あたり）。万が一４号機のプールがこれから起こる地震で壊れたりしたら、関東にも人が住めなくなるのだ。 １時間強と少し長いので、忙しい人は
読者への公開質問：なぜソニーはアップルになれなかったのか？
私も交換書簡およびアプリの開発を担当している、梅田望夫さんの「iPadがやってきたから、もう一度ウェブの話をしよう」、電子書籍ならではの目玉は、発売後に読者からいただいた質問に私と梅田さんが答えるという「増える交換書簡」。 すでに二つの質問に対する回答がアップロードされているが、これからも順次答えて行く予定なので、質問の方、よろしくお願いする。 興味深いのは、最初の二つの質問がどちらもソニーに関するものであること。「なぜソニーがアップルになれなかったのか？」「ソニーとグーグルの提携に未来はあるのか？」。 株価総額でもあっさりとアップルに抜かれ、ここのところいまいち元気のないソニーだが、「もし日本のメーカーでアップルに対抗することができる企業があるとしたら、それはソニーだろう」という多くの人の期待を込めた質問なのだろうと解釈している。 私の回答は交換書簡を見ていただくとして、逆に私からこのブ
iPadアプリ開発日誌：neu.Notes、仕事効率化カテゴリーで１位に
特にはっきりとしたビジネスモデルがあるわけでもないが、「とりあえず良いものを無料で提供して、たくさんの人に使っていただいて、それから考えよう」とリリースした、iPad用の手書きメモアプリneu.Notes。とりあえず当面の目標の「仕事効率化カテゴリーで１位」を達成（日本のアプリストア）。瞬間風速かも知れないが、Evernote、Dropboxなどの強豪がいるこのカテゴリーでの１位はうれしい。 iPadアプリの市場は、私が予想した通りのレッドオーシャン。有料だろうが無料だろうが、たくさんの人に使ってもらってランキングに載らないかぎり試合に出れない野球選手と同じ。これだけの数の玉石混淆のアプリが並ぶ中で「目立つ」ためには、単に「良いものを付くる」だけでなく、「どいういうシナリオで使ってもらうのか」「どうやったら使い続けてもらえるのか」を考えつつ、ユーザーの声を反映させながらこまめにアップデート
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
ガラパゴス・ケータイと「政府の役割」と
最近、技術評論社のWEB+DB PRESS向けに連載を始めたのだが、次号のコラム向けの原稿を書いているうちに、妙に熱くなってしまったテーマがある。米国の政府の産業界との関わりを書いた部分。 米国におけるソフトウェア・ビジネスは、基本的にベンチャー主導型で成長して来た。Microsoftが典型的な例だが、Adobe、Google、Apple、Salescorce.com など、この業界を牽引する会社はほとんどすべてが「起業家」と呼ばれる野心的な人たちによって作られたベンチャー企業である。そういったベンチャー企業は、まずは開業資金を起業家本人や家族から集めた「自己資金」で会社を立ち上げ、少し軌道に乗ったところでベンチャー・キャピタルと呼ばれる投資家から資金を集めて会社を大きくして行く。そこでの政府の役割は、起業家が会社を成功させた時に得る利益（創業者利益）への税率を低く設定して起業家精神を刺激
iPadアプリ作成日誌: Apple に Submit しました
先日予告した「クラウド本棚付きeBook Reader」（正式名称はCloud Readers）、予定通りに開発も終わり、 Apple に Submit することができたのでここに報告させていただく（現在、Appleによる審査中）。前のエントリーでも書いたが、これは私自身がiPhoneで主にマンガを読むために自分用に作ったマンガリーダー（非売品）をiPad用に改造したもの。１年近くもの間、細かなところで微調整を繰り返して作り込んで来たものなので、満足していただけると思う。 一つだけ不安なのが、リリース前に実機でのテストができなかったこと。本来ならば、iPad上で私自身がしばらく使い込んで微調整を繰り返してからリリースするべきなのだが、「iPadアプリストアのグランド・オープニングに自分の作品を並べたい」という欲求には勝てず、エミュレータでのテストに頼らなければならなかったのが残念。 もう一
「なぜAppleはiPadにFlashを載せるべきではない」のか
気がついた人も多いと思うが、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は「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以
アップルの３０年ロードマップ
昨日、日経BP主催のAndroidに関するセミナーで講演＋パネルディスカッションをしたのだが、パネルディスカッションを一緒にさせていただいた、日本通信の福田尚久氏との話（特に、楽屋に戻ってからの非公開の話）が興味深かった。 福田氏は、スティーブ・ジョブズがAppleに戻り、Microsoftからの資金調達、iPodのリリース、アップル直営店の展開、という今のAppleの成功の基盤となる「奇跡の復活」を遂げた時期にジョブズの側近として活躍した人。 彼に言わせると、今のAppleのビジネス戦略は、倒産寸前だった９７年当時に作った「３０年ロードマップ」に書かれた通りのシナリオを描いているという。 もちろん、具体的な内容は企業秘密でもあるので直接聞き出すことはできなかったが、ここ１２年の間にアップルが出して来たもの（iPod, iTunes, iPhone, Apple TV, Safari, O
「官僚たちの夏」と「ガラパゴス携帯」と
知り合いの勧めで録画したままにしてあった「官僚たちの夏」を今になって見ている私だが、あのドラマを単純に「なぜ戦後の日本はあれほどの急成長をとげたのか」という視点から見るだけでなく、「その同じ日本でなぜガラパゴス携帯ができてしまったのか」を考えながら見るとより面白い。 「今の官僚や企業が（あのころの官僚や企業とくらべて）だらしないから」という見方もあるかも知れないが、私としては「そもそも官僚主導の産業政策が今の時代に合わなくなっている」と見る方が正解に近いように思える。 もちろん、その場その場で異なる状況があるので、あまりに単純化して見るのは危険だが、少なくともアナログ方式からデジタル方式に移行した2Gケータイの時代に霞ヶ関主導で「モトローラやノキアなどの海外メーカーに席巻されることを嫌い、あえて日本独自の方式を採用して国内の携帯機器産業を保護・育成しようとした」ことは歴然とした事実である。
iPhoneアプリを作る際に注意すべき５つのポイント
毎日のように「iPhoneアプリでApple Design Awardを取るぞ！」と騒いでいるので、知り合いに「それって（現実が分かっていない）大学生のノリですよ」と指摘されてしまった私だが、マイクロソフトを２０００年に退社してからは、ひたすらモバイル・組み込みの世界で仕事をしてきた私としては「俺が取らなくて誰が取る？」という気分。その超楽天的な態度が彼が言うところの「大学生のノリ」なのだろう。 市場に受け入れられるアプリを作るためには、もちろん「誰にどんな価値を提供するのか」が一番大切。しかし、そこには残念ながら成功の一般方程式はないので、今日は比較的に一般化しやすい「どう作るか」という部分に関して、まとめることにした。 1. ユーザーの利用シーン・使用パターンを良く考えて作る パソコンやゲームコンソール向けのソフトと大きく違うのが、ユーザーの使用パターン。iPhoneに限らず、携帯電話
Life is beautiful: Windows95と地上の星
Windows95の開発の総責任者であるDavid Coleから開発の主要メンバーに緊急召集がかけられたのは、Windows95の開発も大詰めを迎えた1994年末のことである。 Shell（デスクトップ、エクスプローラ、スタートメニューなどのユーザーインターフェイス）の開発を担当していたSatoshiは、いままでの経験からこの手の緊急招集が良い知らせでないことはないことは知っていた。 David Coleが深刻な顔をして緊急招集の理由を説明し始める。Windows95そのものの開発は順調に進んでいるが、Windows3.1との互換性の維持が思うように進んでいないのである。 「このままだと、９５年中にリリースすることはできない」 深刻な問題である。既に当初の予定より１年以上遅れているWindows95のリリースをさらに遅らせて95年のクリスマスシーズンを逃すことはOffice95を同時にリリ
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
Life is beautiful: Google Chromeに関してひとこと
今回Googleが発表したウェブ・ブラウザー、Google Chromeは、ひと言で言えば、「安定度・安全度を高めるために、それぞれのタブを別プロセスで走らせるタブ・ブラウザー」である。 ９５年にIE3.0を設計した時には、タブのコンセプトも存在せず、セキュリティの問題もそれほど強く意識していなかったので、ウィンドウごとに１スレッドを割り当てたマルチ・スレッドを選択した訳だが、ここまでウェブ・アプリケーションが重要になってくると、マルチ・プロセスに移行するのは当然。特定のページ上でのJavaScriptの挙動がおかしくなったからと言って、ブラウザーすべてが落ちてしまう今までの設計が異常。 一つのウィンドウ下で管理させるそれぞれのタブにプロセスを割り当てる、一般的に一つのウィンドウに一つのプロセスやスレッドを割り当てる通常のGUIアプリケーションとは異なるが、ユーザー・モデルとリソース管理は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
で、実際のところHTML5でどのくらいのアプリが実装できるのか実験してみた
単なる「低コストの外注先」ではなくなりつつあるインドのIT産業
常に地に足をつけて仕事をするということ