2010年3月30日火曜日

仕事で使いたくないプログラム言語

結論から書きます。続編あり升

仕事で(プロが)使うなら、次のことをサポートすべき。
言い換えると、私が使うならサポートして欲しい。

  • 概ねオブジェクト指向 → 大規模開発に必要
  • 多重継承 → コピペ禁止。mix-inには必須。
  • 豊富なシンタックスシュガー → 細かい事なんか気にしてられない
  • 名前空間 → 大規模開発に必要
  • 豊富な標準ライブラリ。もちろん名前空間で適切に隔離していること。
  • 例外処理 → 大規模開発に必要
細かい話は、別エントリを書く予定なので、とりあえず割愛します。

日本では何やら、エンタープライズ界隈を中心に、
Java信仰なるものがあるっぽいですが、
Javaは小規模の仕事にはまるで向いてません。
10人月以上の案件に使うべき。
シンタックスシュガーが無いのもダメです。

今大流行りPHP系も、正直気は進みません。
重要な、名前空間と多重継承が使えません。
別エントリでも書いてますが、暗黙型変換が暴発してるので、
故に、今度は大規模開発には向いてません。
豊富すぎる標準関数が、名前空間を食いつぶすのもダメです。
PHPタグで始めなきゃいけない点も萎えます。

C++/C系は、生ポインタがある時点で、正直勘弁です。
言語は道具でしかありません。
受注金額がゴリゴリ落ちてるこのご時世、
メモリ確保と開放の心配までやってられません。
人間のやることですから、メモリ開放なんて、忘れるに決まってます。

Perlは、「CGI言語」として定着しましたが、
最近はPHPにその人気を奪われがちです。
オブジェクト指向の切り口が特異なのと、例外処理が無い点で、
仕事言語としてはマイナスです。
Mooseとやらのお陰で劇的に改善しては居るらしいですが。
いや、嫌いじゃないですけど。括弧を省略できたりとかね。
わざわざ「Perlで書いてね」なんて酔狂な顧客は居ないでしょう。

ケータイアプリプラットフォーム事情2009年度版

アプリ紹介ではありません。
プラットフォームとしての考察です。

日本でケータイアプリというと、キャリア毎にそれぞれ1仕様。

docomo→iアプリ。javaベース。DoJa系
au→ezアプリ。C++
softbank→V/Sアプリ。javaベース。MIDP系

同じjavaでも、docomo/softbankではフレームワークが違ってたり、
例えばezアプリ範疇であっても、機種毎にメモリや解像度やら大違いだったりで、
作ってみても、実機で動くとは限らない。らしい。
だからezアプリのサイトの「対応機種」は、あんなに一杯書かなきゃならない。

さらにezアプリJava版も始まっちゃって、混乱に拍車を掛けてます。
とは言え、C++ベースの開発が、評判悪かったに違いない。

日本のケータイアプリSDK付属のエミュレータは、
いわばフレームワークエミュレータ。と言うべきか。
ハードウエアレベルの保証はできて ません。

iPhoneも有るけど。プラットフォームとしては、
世界共通さらにiPod touch互換なので、
非常に好意的な意味で、事情が違う。
ケータイアプリだと思わない方がうまく行きそうな気はします。

実際に製作している現場の苦労は尋常じゃない。らしい。

ezアプリの開発では、「検証センター」というのがあるらしく、
auの実機が大量にあるらしい。それを端から試していくわけです。

こんな「機種依存」の激しい業界って、ありえなくね?
16ビット未満のノリですよ。正直。

まあ何処かの政治家に言わせると、
産業の創出、って奴にはなってるのかも知れませんが。
いや聞いたことはありませんが。

こういった事情に一石を投じよう、というのが本来のAndroidの姿勢。だと思う。

ケータイアプリで苦労した経験のある人は、
Android SDK付属の「エミュレータ」を疑ってるんだけど、
CPUレベルエミュレータ だから、互換性が尋常じゃない。
docomoのアレとは大違いです。

そうは言っても、
日本のケータイ事情を考えれば、今まで散々作っちゃったアプリがあるから、
Androidに移行してハイさようなら、って訳にはいかないでしょう。
そういう意味では、HT-03aの発売には、一定の評価はしています。

ezアプリは、ベンダーに苦労のさせっぷりが尋常でない。らしいので、
docomoよりさらに呪縛がキツイと思う。
auがAndroid参入が出遅れたのは、致し方ない。と勘ぐります。
それにしても遅すぎ。docomoより先に出すべきじゃないか?芸風的には。

一応筆者は、iアプリの製作経験もあるにはありますが、
作り比べてみると、Androidは、プラットフォームとしては優秀です。
ケータイアプリの範疇を、最初から逸脱してますから。
例えば、電話の着信を拒否、を実装できる。

ただいずれも、開発にはある程度の熟練を要する、という点では一緒です。

とは言え、softbank以外は、Androidを出すことになるらしいですから、
ケータイアプリ開発業の皆さんも、ある程度楽にはなるでしょう。

2010年3月27日土曜日

携帯電話とスマートフォンと、そうでないモノ

最近は、携帯電話にもフルブラウザを載せることが増えてきたようなんですが、
わざわざ「フルブラウザ」と強調している通り、
「フルでないブラウザ」も依然として搭載してますね。

理由はハッキリしていて、

17インチで閲覧することを意図したサイトを
4インチでは、どうやったって見にくい。

#スマートフォンでも事情は大差ありません。
#ポケットに入れて持ち運ばなければならないので
#筐体サイズは頭打ちになります。

見られなくはないけど、結構ストレスが溜まる。

何しろ、マウスでクリック用に出来てるサイトなんかは、
4インチまで縮小表示すると、的がとても小さくなる。
何かの競技か?ってぐらいに。
そもそもそこまで縮小したらもう、何が書いてあるか判らない。

結論として、A5/B5用にデザインしてあるコンテンツを見るには
相応の大きさのディスプレイが必要って訳です。

一方、ポケットに入る無線端末も依然として必要で、
当面、無くなる気配がない。

4インチ画面に最適化したコンテンツ/サイトも、
もうしばらくは作らなければならないでしょう。

その一方で、スマートフォンに慣れた人たちは、
マウスで小さい「的」を狙ってクリックするよりも、
指で押せた方が、楽なのに気づいてしまった。

しかし、居間でダラダラwebブラウズするには、
iPhoneの4インチは狭いし、
B4ノートの15インチは持ち歩いて居られない。
ネットブックだと遅すぎてストレス溜まる。

故に
ケータイより大きい画面で、
ノートPCより軽くて、
縦持ちで使える。
タッチで操作できればなおよし。

まさしくiPadがそうであるように、ケータイとPCの中間のデバイスが
有っても良い事に気がついた。消費者も。

結論として、2010年は、この辺りでようやくAndroidがキそうな気がします。

ハードディスクレコーダに思う

筆者はアニメオタクではありません。漫画オタクです。自分でも、最近まで忘れてましたが、そうなのです。気に入ってる連載がついにアニメ化/ドラマ化!という辺りから地上波を見始めました。

当初はVHSビデオレコーダで運用してましたが、根本的に、見る時間が無い上に、油断していると再生中に、他の番組を見逃したりするんですよね。巻き戻し忘れで録画失敗とか、もう運用ミスは枚挙にいとまが有りません。

ハードディスクレコーダの導入は必然でしょう。

ハードディスクレコーダの革命は、「録画しながら再生」に尽きるでしょう。

一旦デジタルにして非可逆圧縮する、のは、収録時間の拡大のためですね。

ところが、このハードディスクレコーダのお陰で、

  • 広告を見てくれなくなる可能性が増えたのと、
  • 番組をデジタルコピーできてしまう可能性が増えたこと。
  • それによって、将来的にDVDを買ってくれる可能性が減ったこと。

大分ズバリ言っちゃいましたが。
地上波を中心とした、コンテンツビジネスがぶち壊しですね。

アレですよ。「日本人は、水と、地上波放送はタダだと思ってる」そういう事でしょう。

  • タダで放送してるものを録画するために、
  • 金をだしてレコーダ買ったんだから、
  • これ以上はビタ一文払わない、

ってのは一見正しい主張に見えます。

極めて自分勝手だけど、それでこそ&だからこそ消費者だから。

しかし、金を出したくない訳じゃない。減らしたいだけ。

ケータイ音楽配信のお陰で、貧乏人でも、必要&小額なら、割とアッサリ金を出す、
ということが判ってきた。1日タバコ1箱分です、ってアレよ。最近は見ないけど。

#詐称じゃないですよ>貧乏人。なぜなら筆者自身が貧乏人だから。

故に、今後はオンデマンド配信にどんどんシフトしてくる気はします。何時でもダウンロードできるのなら、個人で録画する必要は無いです。

放送側の保管庫と、それを録画した誰かのストレージ。そしてほぼ同じ内容が入っている筈のDVDシリーズ。地球規模で、データが重複しているわけですね。ハードディスク製造元は、どんだけ儲けてるのかと。

NHKは、受信料を貰えるもんだから、余裕でオンデマンドなんかやらかしてますが、広告ありきの民法は色々難しそうではある。

家電レコーダそのものとしては、地上波に固執する必要は、実はありません。実際、ケーブルテレビ対応とか、衛星放送対応とか、既にありますね。むしろ、ダビング10とかにB-CASとかに付き合わされて、ウットオシイのではないだろうか。と思ったり、思わなかったり。

家電専用のインターネット経由でのストリーミングサービスがあって、当然それに対応しているハードディスクレコーダもある。だそうです。
http://actvila.jp/guide/product.html
こういうのは時代だなあと思います。

かく言う筆者は、映像コンテンツで時間を潰そうという意識が薄いので、基本的にPCで録画しっ放しです。アナログです。mpgファイルがゴリゴリ増えます。こういう雑な運用は家電だと無理。そして、気になる奴だけ、1.6倍速で見ます。vlc-1.0だと音声が高くなりません。

この運用は、アナログ終わっても続けるかどうかは、ちょっと判りません。地デジ録画可能なPCは、今でも所有してますが。

放送時間がゴリゴリずれる地上波には嫌気がさしているので、(50周年記念ドラマが野球でズレるって、意味判らん。フジテレビだけど)いまさら衛星放送とかに切り替えようかとも思ってたり。

2010年3月25日木曜日

AndroidはタブレットPC用OSでもある

Android OSは、携帯電話OSとしては、微妙ですが、
携帯電話「以外」向けとしては、地味に普及しつつある気がします。
このジワジワ感は、linuxの黎明期を彷彿とさせる感じ。

ASUS eeePCのlinux英語版を購入したことがあるのですが、
起動画面はまさしくフォトフレームでした。
オープンソースのウインドウマネージャ(icewmだったかな)の設定だけで実現してました。
目から鱗が落ちました。

この調子だと、他のアジア製のフォトフレーム製品も、
中身はlinuxだったりするんだろうな、と思いました。

とはいえ、ディストリビューションを、
1個作るぐらいの手間は掛かります。

この点、Android OSであれば、
何もイジらなくても「それっぽく見える」上に、
多国語、タッチパネル対応ですから、
この手の製品向けとしては、有力な選択肢でしょう。

実際、Android tabletで検索すると、何機種か引っかかります。

日本製もあります。
http://www.widgets-tr.jp/

しかも古典的フォトフレームと違うのは、
本質的に、arm linuxベースのOSなので、
ブラウザもメールも使える訳です。
何だったら、無料SDKで、プログラムを自分で書けます。

この辺りの市場を睨んで、先手を打ってきたのがiPadなのだろう、
と解釈してます。

家に帰ったら、PCはメイルを読むだけ。
もしくは子供にとられて使えない、なんてお父さんも居るでしょう。

今まではベッドサイドPCは、ミニノートの出番でしたが
こういう「メイルを読むだけ」端末の登場で、PC離れが加速しそうです。

自由な姿勢で使えるので、布団の中でも使えます。
個人的にはこれを「ごろ寝ソリューション」と呼んでいます。

2010年3月24日水曜日

オープンソースを使っても、0円にはならない

グーグルのお陰で、オープンソースがかなり広まってしまいました。それ以前でももちろん有ったのですが。mozillaとか。

ソフトウエア製作業界としては、フクザツです。「オープンソース持ってきてチョコチョコっとイジれば、タダで作れるでしょ?」と言われてしまう。私は言われたことないですが。

YESかNOかで言えばYESだけど、YESにも色々あります。「俺アナログなんだよねー」、という方に限って、判断は2択。

生々しい数字で具体例を示すなら

200万円相当の案件のために、オープンソースを持ってきました。これが20万行ぐらいあります。それを1000行改造して納品しました。それじゃあ、制作費1万円だね。

ちがーう。
#こんな雑な計算はあり得ませんが、ただの喩え話なんでスルーしてください。

いや改造量だけみればチョコチョコなんだけど、元々あったプログラムの挙動を変える、って事ですからどんな副作用が出るか解りません。

オープンソース部分込みで、責任をとらなきゃならない。それが受注開発です。

別の観点から言えば、ソースがオープンだから改造はもちろん可能だけど、それが現実的かどうかは別問題。オープンソース部分の補償コストも考慮すべき。

条件付きYESなんですよ、という話。

プラスマイナスで言えば、もちろん減ってるんですけどね。実際の製作量に対してのコストは逆に上がる。むしろ大変。ほとんどゼロだね、って話には絶対なりません。

下手なオープンソースを持ってくると、使わない方が簡単だった、なんてオチもあります。

インターネットエクスプローラとファイヤーフォックスとクロームとグーグルの関係

重い重い、と言われているFirefoxですが、
理由はハッキリしています。
「Windows向けの裏技を使ってないから」です。

InternetExplorerは当然使っています。
裏技って何か?
Internetが付かない、エクスプローラは、
実はInternetが付く方のプログラムの殆どを包含してるのです。
#この表現は厳密ではありません。説明用です。

InternetExplorerの3まではそうでもなかったのですが、
InternetExplorerの4からそうなりました。
Windows98辺りから、アクティブデスクトップとか言い出したでしょう?
デスクトップにHTMLを貼り付けられる。
それはそういう事です。

http://msdn.microsoft.com/en-us/library/aa741312(v=vs.85).aspx


一昔前のモバイルノートPCは、WindowsXPでメモリ512MB、とかなので、
「Firefoxは重いからIE使ってる」となるのも無理からぬ事です。

しかし、起動しちゃった後の方が問題です。

IE7未満は、他のブラウザに比べて、javascriptエンジンが遅いのです。
具体的には、文字列連結処理が遅い、らしい。
文字列連結って何か?

webの殆どはHTMLで書きますね。
HTMLの一部をjavascriptで切ったり貼ったりできます。
サーバに一括でHTMLを作るんじゃなくて、ブラウザ側で自分で作り直すんですね。
ブラウザに処理させる、って言ったら、現状はjavascriptしか選択肢が無い。

サーバとPCとの、データの行ったり来たりがゴッソリ減るので
レスポンスが良くなる、
だけじゃなくて、インタラクティブな操作が出来る。それがajaxです。
もう何年も前ですが、グーグルマップの登場は衝撃だったでしょう?
ajaxの真骨頂です。
javascriptの株が、大幅に上がりました。あれで。

javascriptは結構おもしろい言語です。
画面をフェードしたり、ポップアップボカボカ出したり、だけが脳じゃないんです。
グーグルマップの様な、高度な実装もちゃんと書ける。
この辺りは話すと長いので。

HTMLは文字列です。切ったり貼ったりは文字列処理です。
それが遅い、と言ったら、イマドキのajaxのサイトが遅い、のと同義です。

まあ普通の、日本国内のwebサイトを見ている分にはIE7でも平気ですが、
Gmail等、グーグルのajaxサイトは、
javascriptの限界に挑戦しちゃってますので、
Gmailが遅い、から使いたくない、という話になっちゃいます。
実際に、そういう人は多いです。

「IE7でGmailが遅いから、メモリを買ってきた、2GBにしてるのにまだ遅い」
知人がそんなコントをやってました。

#話の流れてきには、「ここでFirefox」と言いたかったのですが

面白くないのグーグル。
Gmailが重いのはオレらのせいじゃねえよ、と思ったかどうかは知りませんが。
Chromeを作りました。

試してみてください。馬鹿っ早いです。
512MBでも実用になるはずです。

一方、Chromeは「webサービスの利用」に特化しているので、
ブラウザとしてはかなり機能アッサリです。

InternetExplorer8では、文字列処理の速度が大幅に改善してます。
アップグレード出来る人は、アップグレードするべきでしょう。
マイクロソフトもアップグレードさせたがってるでしょ?

ただそれでもFirefox3とかChromeには追いついてないらしいですが。

Firefoxが重いのはまた理由が違います。
Firefoxがマルチプラットフォーム対応なのに関係があります。

マルチプラットフォームブラウザを実装するにあたり、
マルチプラットフォームフレームワークを開発した、らしいんですね。
XULナントカって奴、らしい。
http://ja.wikipedia.org/wiki/XULRunner
https://developer.mozilla.org/ja/docs/XULRunner/What_XULRunner_Provides

Firefox内部は、結構javascriptで動いてます。
エクステンションがドッサリありますが、これらはすべてjavascriptで出来ています。
https://addons.mozilla.org/ja/firefox/

ただwebを見るためのブラウザとしては、考えすぎとも言えます。
この「考えすぎ」部分は、当然、ある程度はメモリを食います。だから重い。



故に、エクステンションを使わない人は、
FirefoxのHTMLエンジンだけを抜き出したブラウザが幾つかあります。
HTMLエンジン単体は、mozillaプロジェクトの中の、geckoという単体製品なので、
スキルがあれば、他の製品に組み込めるわけです。
http://ja.wikipedia.org/wiki/Gecko
https://developer.mozilla.org/ja/docs/Gecko

むろん、mozillaプロジェクトとして、そうして欲しいわけです。
https://developer.mozilla.org/ja/docs/Embedding_Mozilla

例えば、K-meleon http://kmeleon.sourceforge.net/
InternetExplorer並の軽さ、しかもGmailも快適。
ただしWindows版しかないけど。

と言うわけで、IE7未満以外を使えば、Gmailが快適に使えます。

2010年3月22日月曜日

Androidとiphoneとスマートフォンと私

日本では、依然としてケータイが人気です。
「ケータイ」は、日本製のオーソドックスな携帯電話を指して言っています。

カメラ、ワンセグ、音楽配信対応、お財布ケータイ、ケータイサイトブラウザ、
絵文字、デコメール

あまりにも全機種についているので、逆に選択に困ります。
どれを選んでも大差なさそう。

一方「スマートフォン」ですが、前述のケータイの機能の殆どを実装していません。
カタログにありがちな、マルバツで機能比較をすると、ダメなケータイにしか見えません。

筆者は、auとDDIポケットを使ってましたが、iPhoneとAndroidを導入しました。
3キャリア対応です。一応名目は、市場ニーズの研究のため、です。

iPhoneは、一応スマートフォンに分類していますが、
iPod touchとソフトウエア互換性があります。
iPod系としての方が歴史が古いですね。
厳密には、電話もできる、携帯音楽プレーヤであると言えます。

いや実際、イーモバイルのポケットwifi使えば、
iPod touchで良かったのか?とかグルグル悩みましたが。買った後に。

iPhoneは、発売当初でこそ、「Macユーザ向けマニア携帯電話」でしたが、
今では、尋常でなく普及しています。
昨年秋に契約しましたが、入荷に2週間待たされてようやく、です。
電車に乗ると、10人に一人は使ってる気がします。数えてませんが。
理由は私には判りません。ホワイトプラン恐るべし?ってこと?

それでも依然として、Windowsベースのスマートフォンや、
ケータイを使っている人もまだまだ見受けられます。

昨年、ようやくdocomoからAndroidが出ました、が、低迷もいいところです。
在庫がドッサリあるらしい。待たなくても買えます。実際そうでした。

今となっては、Xperiaが出る前の時間稼ぎだったのかな、とは思いますが、
HT-03aは余りにも「素のAndroid」過ぎた。
そしてAndroid自体がPCっぽい。デコってない。
可愛くない。凄そうに見えない。

家電雑誌やらガジェット雑誌やらで、たまにAndroid特集をやってますが、
HT-03aの記事は、書きにくそうでしたね。
「グーグルマップが使いやすい!」とか。見りゃ判るよ!
とは言え、ケータイライターを名乗るなら、
もっとマシな記事を書け、と言いたい。

でも劇団ひとり氏も似たようなもんだし。仕方ないのでしょう。
あのCMはサイトで見当たらないけど、
このCMはまあまあ。http://www.nttdocomo.co.jp/corporate/ad/tvcm/090710_01.html

グーグルの売り方も悪かったような。「携帯電話OS」と言ってしまったから、
日本人はケータイに入れなきゃならないと思い込んでしまう。
でも作る方にしてみたら、Androidにしたら、ワンセグできないじゃん、みたいなね。
そんなことは無いのですが。カーネルドライバを書けば多分ね。

#Android OSは、質的には、タブレットPC用OSと言えるでしょう。
#そしてそれに一番近い家電は、フォトフレームだったりするのですが、
#それは別途。

最初に市場ニーズの研究のため、と書きましたが、実際使い比べると色々判ります。

私も実用品としては、iPhoneを常用してます。
マルチタッチが秀逸です。革命と言っても良いんじゃないですかコレ。

お蔭さんで、最近は、マウスカーソルが面倒です。トラックボールを漕ぐのがね。

AndroidのOS自体には不満はまったく無いのですが、
HT-03aのハードウエアに不満大有り。
電池が大食いだとか、それゆえに実はCPUクロックを抑えてるとか、
それゆえに、全体的にモッサリな使用感が付きまとうとか。
悪循環スパイラルもいいとこです。

結論として、HT-03aじゃ、Androidは普及しないな、と思っちゃいました。

Xperiaに機種変更しようか、グルグル悩み中です。
HT-03aを買った人のほとんどがやり兼ねません。今の有様だと。

HT-03aにしたのは「キャリア経由で販売する製品と、素のAndroidとの差異」が
見たかったからです。それにしてはまあ高い買い物だったかなあ。
損をしたとは思ってませんが。

クライアントの要求を、日本語で確認するのは無理だと思う

「日本語」とか「英語」とかのことです。厳密には、自然言語とか言うらしい。
だけの話、の、つもりでしたが、プログラム言語もそうかもしれない。

言語は、概ね1次元表現ではないか、と思います。

ツッコミ所満載だと思いますが、まあ続きを。

一方、人間の思考は、4次元以上はある気がします。
少なめに見積もっても、3.5次元以上?

故に、自分が考えていることを、他人に説明するときは、
4次元から1次元に変換しているということです。
これはどエラいことです。
誤解や語弊があって当たり前です。

ああ、そうかもね、って気がしませんか。

絵というか、図は間違いなく、2次元でしょう。
図表を使うと、誤解がゴッソリ減る経験は、皆さんもある筈です。
そりゃそう、文章に変換するよりも、1次元得してますからね。

オチは、ソフトウエア受注開発の話です。
最近の個人的見解では、ソフトウエアの仕様は、4.5次元ぐらいある気がします。
故に、作ってる本人でさえ、全貌を把握するのは困難でしょう。
要件定義段階で、お客さんが把握するのは、まあ無理でしょう。

これを1次元の日本語で説明したり、1次元のプログラム言語で実装したりする訳ですから、
出来上がってみたら、「あれ、こんなのだっけ?」というのも程度仕方ないとは思います。

結論として、プログラムは、ある程度出来上がってからじゃないと、
お客さんの脳内と比較ができない、ってことですね。

とはいえ、終盤の出戻りは、コストに響くので、避けたい所です。
どうにかならないものかと日夜考えては居ます。

メイルの整理で、フォルダに完全分類は無理

筆者は、5年前ぐらいから、完全にGmailに切り替えてしまいました。
古典的なフォルダに相当する概念として、ラベルがあります。
逆にフォルダ機能はありません。
特に、アウトルック利用者で、これに抵抗を感じる人は多いですが、
いや本当に貴方、メイルの整理できてますか?と聞きたい。

ファイル類の整理と言うのは、普通は「○○の件はココ」と決めて、
そこに置くことです。これはもう紙文書のファイリングの延長線上の運用です。

受信箱の下層にフォルダを作って、自分で運ぶ。
「○○株式会社様」とかね。

しかし、直接取引ならともかく、代理店や中請けが挟まると、もう駄目です。
大抵メイル1通に、複数クライアントの話を混ぜてくれます。
結果として、クライアント名での分類は、無理です。

じゃあ案件名で。それも無駄です。
元請けさん的には、大抵クライアントは1軒一括り。
だからその調子で下請けにも連絡してしまう。らしい。

結果的に、「フォルダに分類」を諦めて、受信箱にメイルがドッサリ。
「アウトルック最近起動が遅くてさー」目に浮かびます。

この通り、普通にメイルといっても、複数の切り口があり、
「○○の件はココにあります」っていうフォルダベースは無理です。
複数のフォルダにコピーしておくのも気持ち悪いですね。

そこでラベルです。
まあ、メイルに貼る付箋紙みたいなものだと思いねえ。

前述の例で行くと、「○○代理店」「○○株式会社様」「○○システム」
ラベルを3枚貼れば良いわけです。それで整理は完了です。
少なくとも矛盾は出にくいことは、お分かり頂けるでしょう。

これの肝は、「メイルの実体は何処にも動かしてない」ところです。

後は、特定のラベルが付いているものを、抽出する機能があれば、
フォルダに整理したのと似たようなものです。

コンピュータならではの方法ですね。物理文書ではこうはいきません。

メイルソフトでもラベル機能を実装したものはあるかも知れませんが、
筆者はGmailに出会って、それ以外の選択を放棄しています。

「済んだ案件は、受信箱から見えなくなってほしい」なら
「アーカイブに送る」を使えば良いです。

しかも、Gmailは検索機能が強力。

アウトルックを使っている人は、アウトルックの検索能力を信用してないので、
日付でソートして、肉眼で探すくせがあるようです。
「そのメイル、何時送った?」って口頭で聞いてきます。意味ないです。
私のサンプリングが偏ってるのでしょうか?そうであって欲しいです。

wikiの限界

wikiは、誰でも色々なところから書き込める、のがウリです。何かを検索すると、「○○まとめwiki」かwikipediaか、どっちかのお世話になってることでしょう。

しかし、wikiが提供している機能は、「HTMLを書かなくても」から逸脱しては居ないので、1次元的データしか扱えません。2次元には足りてない気がします。複雑なデータ構造を表現しようとすると、早々と破綻します。

典型的なのは、アニメやら漫画やらのwikipediaのページ。キャラ紹介だけに飽き足らず、△△グループに居たけど○○話で脱退したとか、○○話で喧嘩した、○○話で和解した、なんて話も書いて有ったりします。

これが、アニメと漫画で、エピソードのタイミングに差異があったり、原作小説があったりしたらもう駄目です。何が何処に書いてあるのやら? 

ネタバレだろ、って話はおいといて、キャラ相互の絡みと、連載ベースの時間軸の話は、実は多次元データの領域に入っており、同列で扱うのは理論的に無理です。それを、wikiで、1次元的に表現しようって言ったって無理がある。

前述のアニメやらマンガやらの話で言えば、キャラ紹介単体と、他キャラとの相関、ストーリ時間軸上の展開は、別層として扱うべきでしょう。

結論からいうと、項目単位でラベリングをするしかない。

しかし、そこまでするのは逆に面倒、wikiエンジンに機能が無い、これがページベースのwikiシステムの限界です。

そこで、そういうwiki(っぽい何か)を作ってみたら、ニーズがあるかどうか、昨年辺りから思っているんですが。

PHPって何が駄目って on PHP 5.2.X

5年ばかり、PHPで仕事をしてました。してたときは気にしてなかったというか、なんとなく引っかかってたんですが、pythonと比べると、駄目さが解ります。

一つは、名前空間がないこと。

PHP4で書いたスクリプトが、PHP5で動かないというのはままあります。
構文的な違いもさることながら、組み込み関数/クラスをドカドカ増やす。

私がPHP4時代に仕事で書いたスクリプト。
ディレクトリ検索クラスにDirectoryIteratorと付けました。
付けたくなる名前ですよね。ハイもう落ちが解りましたね。

PHP5になったら、定義済みクラスなので、2重定義でピクリとも動かない。
定義済みクラスってなに?includeしてないよ俺?度肝を抜かれました。
こっちが避けるしかないので、DirectoryIterator1とかに改名。

豊富な組み込み関数&クラスがPHPのウリなのかも知れませんが、
いらない人も居るんだよ、って話が抜けてる。
DirectoryIteratorはSPLエクステンションだが、PHP5.3で内蔵にしちゃったらしい。
http://www.php.net/manual/ja/spl.installation.php

大きなお世話です。

PHP5.3で名前空間をようやく実装したらしいですが、
「名前空間専用の区切り文字」が有って、バックスラッシュでした。
http://www.php.net/manual/ja/language.namespaces.nested.php

正直気持ち悪いんですけど。そうせざるを得なかった理由は想像できる。

オブジェクト指向の実装が不完全なので、階層管理が出来なかった。
なので、識別子名レベルでの代替手段を使った。
ピリオドもコロンも使用済みなので、バックスラッシュしか余ってませんでした。
変な文字も使えるようにして、名前空間っぽく使ってね、みたいな。
のかな?

もう一つは、暗黙の型変換の脅威。

PHPは、知らない間に、過激な型変換をしていて、それで知らずにバグることがあります。
例えば、これが通ります。
"" == 0 
あえて型変換を強調して書いてみましょう。
(int)"" == 0 
意味解らないでしょう?
もちろん、わざわざこんなif条件を書くのは変態です。
しかし左辺が変数だったら
$result == 0
よくある話でしょう?

こういう実装になってる事情は解ります。
多分彼らはコレをやりたいのでしょう。
(int)"9" + 3 == 12 
PHPは、左辺を優先して、型変換を繰り返している。
確かにwebベースのプログラミングで、数値変換はよくある話。
手間が省けるのは歓迎です。

入力値に対しては良いです。

これがハマりそうなケースは、関数の戻り値。

PHPの組み込み関数でも、intとfalseを使い分けちゃってるケースが結構あります。
例えば、mb_strpos。見つかると文字の位置を返しますが、見つからないとfalse。
先頭に引っかかった場合は0を返しますが、== falseとかでチェックしてると通りません。

PHP4で書いて、PHP5で動かなくなる話にも、これが関わってきます。
組み込み関数の挙動が微妙に変わってたりする。
エラーの時は、-1を返す、と思ってたらfalseを貰った、とか。
エラーを < 0 で判断してたら、正常で通過しちゃうわけです。

大昔に書いたプログラムを改造する場合にも、この辺りで微妙にバグる可能性もあります。

これは正直、センスを疑いますが、事情は想像できなくもない。
PHP4時代には例外は無いので、戻り値で遣り繰りした。
しかし、式実装全体としては、intとboolが区別できてる癖に、
暗黙の型変換をしちゃうという、チグハグな実装。
かな?

総評として、「安全に」「大規模な」プログラムを書くには、無理がありそう、
と言えます。

今更「クラウド」

「「クラウド」って何」っていう質問を受けなくなってきたけど、定着してきた、ってことでしょうか。

個人的な認識を言わせてもらうと、

膨大なハードウエア資源をもっている企業が、領域やらCPUパワーやらを、任意サイズで切り売りするのがクラウドである、

アマゾンやらグーグルだから出来るわけです。

ポっと出の、吹けば飛ぶような日本企業が出来るこっちゃない、って事ですね。その意味では、なかなか言い得て妙だと思うのですが、如何がでしょう。

日本のレンタルサーバサービスだと、1台分をまるまる貸し出して、月幾ら、ですが、サービスが大型化&複雑化してくると、数台借りることになってくる。運用は指数的に面倒になってくるし、壊れた心配もしなきゃなりません。信頼性を上げるためにRAID5で、とか価格もドンどん高くなる。

何故、切り売り出来るのかというと、仮想コンピュータありきです。

物理的に1台のコンピュータの上で、OSを幾つも動かします。幾つも、というとアレですけど、OSがアプリケーションにまで成り下がって、他所のOS上で稼働します。ホストOSとかゲストOSとか言ったりしますけど。

VirtualPCを幾つも動かしていると思いねえ。

それでもってVirutalPCの1台分づつを切り売りしている訳です。この表現は厳密ではありません。説明用です。

これで何が良いかというと、まず「切り売り」の「切り」が自由自在になった。

世間一般に「webサービスやります」って言うと、DNS/WEB/メイル/DB をそれぞれ1台づつ用意して、何て話になります。apache入れてどうたらこうたら、までは大抵はプロバイダの人がやってくれますが、そこから先は、今度は自前のサービスのためのセットアップが残ってますからこれで負荷分散で、WEBとDBに2台づつ、なんて言ったらもう何が何だか判りません。

TCPサービス単位でディレクトリ切ってどうこう、するよりは、ゲストOSを複数用意しちゃった方が、総合的に楽です。このゲストOSの起動まで自動化して、「何処のPCでゲストOSを稼働」までリモートで制御できるようになれば、切り売りコストはゴッソリ下がります。

これで更に何が楽になるかというと、ハードウエアを導入するときに使い道で悩まなくて済む。

「ゲストOSセット」をインストールすれば良い。これならアルバイトに頼んでも問題はないでしょう。

アマゾンのソレと、グーグルのソレは、「切り売り」という面では一緒です。なので、両方共「クラウドサービス」とか言っちゃう訳ですが、なにしろ「切り売り」なので、味付けやら切り口やらが違います。

実際登録してみると解りますが、WEBから登録&クレジットカード入力して、3分で「サーバ」が立ち上がります。全自動です。人間やら「契約書」やら「印鑑」は一度も介在しません。この小回りは、「レンタルサーバ」には到底真似できません。

アマゾンEC2では、比較的、生のゲストOSを提供しているため立ち上がっちゃった後は、日本のレンタルサーバと大差なく使えます。リスタートしたらデータが消えちゃいますよ、って以外は。

言うなればリソースクラウド?今思いついた呼称です。

私が研究した当時は、データの保存はS3に送るしか無かったりで、やや手間でしたが、今はelasitic storageがあるので、そうでも無い模様。

最近では類似サービスが日本でも始まってます。Virutal Private Serverとか呼んじゃってるらしいです。

アマゾンEC2に対抗して、と言われているのが、グーグルappengineです。

グーグルappengineは、プログラムコードだけを預かる。サービスのURLも予め決めます。しかし、何処で動くかは決めません。グーグルの都合で、クラウド上の何処かで動きます。

言うなればランタイムクラウド?これまた今思いついた呼称です。

故に、appengine-SDKに準拠して、プログラムを作成する必要があります。これは必須です。何しろ破ると、動かしてもらえない。逆に、それに準拠する限りは、グーグルのクラウドにバラまいて動かしてもらえます。

対抗して、と言われがちな、2サービスですが、使い勝手は大違いである、のがお分かり頂けるでしょうか。

いずれもポっと出の企業が、何か「WEBサービスをする」には、非常に便利です。例えば、SecondLifeは、アマゾンEC2/S3を使っているっぽい。

この通り、運用面では良い事づくめの「クラウド」ですが、秘密主義の日本人に受け入れられるまでには時間がかかりそうです。

「本店のサーバールーム」に置くのは、やっぱり「Windowsファイルサーバ」だったりする。