Categories

  • Android開発
    android marketで目指せ億万長者(ウソ)
  • cocos2d
    pythonでも使えるゲームフレームワーク
  • Google
    ここには未来を開くためのAPIがたくさん用意されている。
  • GoogleAppEngine
    どこまでもスケールアウトするクラウドサービス。使いこなすのが大変
  • Hack
    様々な電子機器を本来の用途とは別の用途に使ってみる。
  • iPhone開発
    app storeで目指せ億万長者(ウソ)
  • python
    LightWeightLanguageで一番難しいがLispにも通じるところがある面白い言語。
  • TIPS
    覚えておくともしかしたら役に立つかもしれないチョットしたこと。
  • うまくいきません
    やってみたけど、うまくいかなかった失敗記事
  • ネット世界
  • 夢見るソフトウェア
    こんなのいいな、できたらいいな、いつかつくろう
  • 開発環境
    開発するまえに環境を整えた記録、次に同じことをするためめの忘備録
無料ブログはココログ
My Photo

« February 2006 | Main | April 2006 »

March 22, 2006

どうして規格は一つにまとまらないのか。

 デバイスの呪縛って言われてもね。 そもそもコンピューターが世に出た時から互換性の問題というものは存在しているわけだし、それ以前にはVHSとβの争いがあり、 もっと前にはNTSCとPALの戦いがあったわけで、消費者不在の規格競争というのは今始まったことではない。そして、 次世代DVDのゴタゴタを見ると永久に解決するとは思えない。

 登場人物を整理しよう。規格を作るハードウェアメーカー、コンテンツを作るソフトウェア産業、消費者。 ハードウェアメーカーは莫大な開発費をかけて新規格を作る。そして、コンテンツを作る会社に対応ソフトウェアを作ってもらうように頼む。 消費者はハードウェアを選択する基準としては欲しいコンテンツが提供されていることを最も重視する。

 というわけで、3社のうち最も強い立場にいるのはソフトウェア産業であることがわかった。 彼らの立場から考えれば同等の規格が複数あったほうがいい。ハードウェアメーカーに対して強い立場を取ることができ、 2番手3番手のメーカーからはキャッシュバックやミニマムギャランティなども期待できる。

 一方、消費者に対しては複数の規格があるおかげで同じソフトを移植、またはメディア変換するだけでも新製品として発売できる。 元手がかかっていないので実においしい。

 それでは、ソフトウェアメーカーに対して何も打つ手はないのかといえば、ひとつの回答がエミュレーターである。 ゲーム機などは新製品に下位互換エミュレーションをつけることは標準仕様になりつつある。パソコンではCPUが仮想化対応命令を装備したり、 Xenが登場したりVMWarePlayerが無料化するなどOSまで含めたハードウェア一式を単なるファイルにすることが出来る。

 じゃあ今年、 WindowsVistaが出たら対応ソフトを買わずにVMWareの仮想マシンで動くXPで今のソフトを使うのかといえば、 んなわけはない。やっぱり、最新版のソフトは欲しい。

 で、もうひとつの回答がウェブ・アプリケーションである。主要な処理はサーバーで行うので、 クライアントとして使用するPCのOSとかメーカーとか、いやそもそもPCですらなくてもかまわない。ということになる。

 しかしながら、これはソフトウェアメーカーにとってみれば大きな負担となる。クライアントの画面の解像度、ネットワークの応答速度、 入力デバイスの差異などを吸収するために多大な労力を費やす必要がある。さらにクライアントには機種固有情報つまりバグが存在する。 理屈どおりではないのだ。

 既存のソフトウェアメーカーがビジネスとして考えた場合、結論は明らかである。 ユーザーにとっても現在使用しているソフトウェアからの乗り換えという最も高いハードルを越える必要がある。

 ただし、RSSリーダーのような新しい分野のソフトウェアに関してはウェブ・アプリケーションの出番はある。 文書作成や集計にワードやエクセルと違うアプローチがあればブレイクするかもしれない。

March 19, 2006

脆弱性とかバグとかを見つけるやつを絞め殺してやりたい

 ソフトウェア開発の後半ででデバッガーから「バグです。よくみつけたでしょ」とうれしそうな顔をしてレポートを提出されるとね、 もう、「こいつさえいなければ」と思ってぶっ殺したくなるわけです。Webアプリなんかの場合は、 公開しながら作っていくスタイルなので常にデバッグです。正しく動作しないぐらいならよいのですが、 脆弱性があるものに関しては緊急性を要するのでさらに殺意が増します。 

 で、そもそも何でイヤかというと、一旦、機能追加部分を作るのやめてソースを見直していく作業をやらないといけないからです。 イヤですねえ。誰もやっていない新機能を作る仕事は楽しいし、周りの評価も高いけど、今まで作ったソースを洗う仕事は結果がわからないし、 犯人探しで責任追及することになりかねないし、終わりも見えない。「3日たった自分は他人」とか「他人のソースは読めない」とか、 そういう後ろ向きの作業をやらないためにはウソだってつきます。そもそも、脆弱性を突かれて困るのはサイト運営をやっている人であって、 作っている人は困らないしね。

 ということで、脆弱性を指摘された場合に現場がつくウソ

  • そのような弱点はない
  • その弱点を突かれてもたいしたことは起こらない
  • どこの誰かも知らない人の情報はあてにできない
  • そもそも脆弱性を調べること自体犯罪なので、警察に連絡して逮捕してもらえ

 運営者がこれを真に受けてそのまま発表したりすると、発見者の神経を逆なですることになり、悪い人に手口を教えたり、 自分で実証してみたりすることになったりと火の手が上がってさあ大変です。まあ、 指摘する相手が何をするかよくわからない場合、脆弱性を発見した人は保身を考えたほうがいいです。 IPAのガイドラインでも、脆弱性の指摘によってサイトの安全を守るよりも、発見者の安全との確保を優先して書いてありますし。 IPA自体が盾にならないように微妙に文書も練られているし。

 ということを、 『ネットランナー』はまちゃんにインタビューのコメント欄を読んで考えたわけです。

 ちなみに、プログラマーを10年ぐらいやっていると、問題を指摘されたとき感謝するようになることも付け加えておきます。 いずれ直すべきものが早期に見つかってよかったし、なにより考え付かなかった方法を教えてもらったことに対しても。

 「建造物を作るときは、基礎工事などの前の手順に問題があったときは工事をストップして修正するでしょ。」 と上申して納期を変更してもらう政治力がついたからかもしれませんけどね。

« February 2006 | Main | April 2006 »