language popularity

TIOBEによる話題の言語ランキングというものがあるのだ。なるほど、Java が C を抜きましたか。VB も根強いですな。成長加速度が見られるのが面白い。

これは「話題になってる数」がベースだから実際の市場規模とは乖離があるだろう(先行してるだろう)が、数年後にはこの傾向で「売れるプログラマ要件」が推移していくのだろう。
第一位…Java
第二位…C
第三位…C++
第四位…PHP
なるほど、Web系と組み込み系に需要が高い傾向にあるんでしょうね。そして、
第十六位…ColdFusion
第二十二位…Ruby
とな。ColdFusion は JRun ベースの J2EE なんだけど、高度に隠蔽されてるのでタグ言語だけでアプリができちゃうという認識だったんだけど、急激に話題になってるようだ。Flash 連携テクが増進中ということだな。Ruby は研究者人気は高いけど、まだ世の中で商業的に教育されてる言語ではないってことかな。

さらに、
第四十八位…Objective-C
うわー、MacOS ネイティブの言語はこんなとこにしかいないのか!
comp | - | -

人間が管理職になっていく様

アイテー業界でのキャリアの積み方については侃々諤々と論じられてますが、「どこが労働集約的か」すら固定的ではなく、高速にシフトする中ではそれもしょうがあるめえなと思いながら、こんな対比を考えた。

ギター小僧の出世道:

ギター小僧
 ↓
バンマス(もちろんギターは弾ける)
 ↓
レーベルオーナー/プロデューサー(バンドもやってる)
 ↓
イベントオーガナイザー(その昔バンドやってなあ)

すなわち、ギタースキルを持ちながら、バンドを牽引する役割をこなし、後に自分のバンドも含めて複数のバンドをプロモーションするような役割になっていくとともに、最終的にはドカンとデカいイベントやっちゃう、というひとつのキャリアモデルがある。(イベントオーガナイズは、たどりがちな道ではないかもしれない)

同様に、
なんらかのプロフェッショナルスキルのある人がプロジェクトマネージャになるまで:

 職人
 ↓
複数の職人からなる開発チームのリーダー
 ↓
複数の開発チームをオーケストレーションするリーダー
=プロマネ
 ↓
複数のプロマネを率いる事業部の長(もしくは社長)

ここでは、どの職人か、プログラマか意匠デザイナーか内部デザイナーか、は問わない。それは専門領域の差であってキャリアとは独立していると考えている。

いずれにしても管理職=管理する職という、文字通りの管理側面ばかりがネガティブに捉えられて、「管理なんてされてたまるかコンニャロ」などと若人には思われがちだけど、管理職っつっても、例えれば「自分のバンドを牽引するバンマス」、「自分のバンドの付加価値をあげてくれるレーベルオーナー」と似たもんだな、と例えるとそうも思わなくなる。

それに、実際やることは同じようなもんだ。
misc | - | -

buildemacs.sh

そんなに使わないと思いつつ、やっぱりコンパイルしておきたい Emacs.app ですが、OSX用は割と進化が早いので追いつくための build 作業も回数が多くなると面倒、ということで作ったスクリプト。$ sudo ./buildemacs.shなどとして数十分ほっとくと完成し、/Applications に Emacs.app が鎮座してくれるというもの。
#!/bin/sh

export CVS_RSH='ssh'
cvs -z3 -d:pserver:anoncvs@cvs.sv.gnu.org:/cvsroot/emacs co emacs

cd emacs
./configure --with-carbon --without-x
export MACOSX_DEPLYMENT_TARGET=10.4
perl -i.bak -p -e 's/(#define HAVE_GETADDRINFO 1)/\/* $1 *\//' src/config.h
make bootstrap
make install
cp -r Emacs.app /Applications
HAVE_GETADDRINFOをコメントアウトすることで、ローカルで名前解決をしようとするのを防いでます。
comp | - | -

真空メロウの

流行歌(という曲)がすげえいいこりゃアルバム買わなきゃと SEA UNDERSTAND を買って爆聴してたら解散してたというショック!

が、個人的にさっき発生しました。

たいして興味もないのに
あの映画も本も全部
つめこんで
何がしたいんだろう

正直よくわからないんだ
次から次
次の次で
目がまわる
きっと終わってる


毎日毎日漫画雑誌を買って読み捨ててる32歳がドキリとした曲でございます。
music | - | -

みんなフィルムでも写真撮ろうぜ

京セラがCONTAX事業から撤退しNikonが縮小しコニカミノルタが撤退しブロニカの中判事業も終了し、フィルムカメラは市場からもデジタルに取って代わられた。これはもう観測的には事実だろう。キヤノンさんはまだ発表してないけど今後市場を独占だぜ! と見るか、やっぱ縮小しよーと思うか。

時代の変化なのは認めます。特にフィルムカメラ業界にもうそんなに$も落としていない一消費者として、変化を受け入れなければいけないことも意識しています。でも、ファインダーで対象を狙い、画角を決め、露出に応じて絞りとシャッター速度を選び、シャッターを押すことでミラーが跳ね上がり、シャッター幕が開き、絞りを経由して装填されたフィルムに像が入り込むことで、フィルム表面でRGBの感光色素のおのおのの層に吹き付けられた臭化銀が還元されることで銀となり、補色が生成され、シャッターが閉じ、フィルムを巻き上げて完了する一連の撮影プロセス。そしてフィルムを現像に出すまで出来がわからず、数時間~数日待ってやっと見る時の緊張感。これが撮影という儀式だろうと思うのですよ。それがAEでテキトーに、もしくは固定的に決められた露出で、荷電結合素子(CCD)に光が入り込み、個々のフォトダイオードから光電効果で電荷が取り出され、その電荷を増幅して数値化した後にメモリに保存し、このあと数瞬でノイズを除去してCFカードにファイル名を添付して保存し、カメラ内のOSを操作して…えーとはしょってTFT液晶なんかでプレビューしちゃえたりしていらなかったら捨てちゃうなんてデジカメのプロセスに置換されるのはちょっと無理があるのですよてか全然別ですよ! お子さまに説明できませんよ! お子さまにとって「撮影のポーズ」といったら最近じゃケータイを縦に構えた写メポーズになっちゃうくらいですよ!(ここまで一息。てか撮影の原理ってこまっかく話そうとすると深いな…)

…ハァハァ。

そうか、どうも俺は漢の買い物のひとつであるフィルムカメラが減ってしまうことが哀しいのかもしれない。

(ほか、漢の買い物の例:自転車、自作PC、楽器、スポーツカー、アウトドア製品、モデルガン、時計など、ぜったいヨメに怒られそうなガジェット類。つうか MONO MAGAZINE 的買い物)
misc | - | -

無理な比喩という試み

リピーター、ハブ、スイッチ(ブリッジ)、ルータ、L3スイッチ、なんてなネットワーク装置(とりあえずアライドテレシスの講座を)については、人間の活動に例えて覚えることにしているのだけど、通信を成立させるこれら装置は、集団活動における振る舞いでのメタファーが可能ではないかしら、と考えてみる。

リピーターは基本的には文字通りただ信号をリピートするだけなので、「○○さんがこう言ってたヨ」てな伝聞上手なのだろう。ただし、歪んでしまった信号を整形したり、コリジョンを防止したりする機能もあるため、たとえばまとめサイトを編集するような行為、あるスレから面白いところを抜粋する行為はリピーター的と言える。

ハブはリピーターを集結させたようなものだ。発信側の信号をさらに同時大人数にリピートする。あるハコでのライブかもしれない。ハブは多段化もできるため、複数のバンドが出現するようなイベントは多段ハブ的だ。

これに対し、ブリッジは LAN 同士を接続するものなので、セグメントまたぎを可能にする。
例えばわかりやすいところでマイミク、というセグメントがある。マイミクのマイミク、又ミクの関係にある人物と自分はさしずめブリッジとしての位置にいるが、ブリッジとして機能しているかは別問題だ。その人がパーティを主催して、又ミクをマイミク化させれば、ブリッジとして機能していることになる。利用言語、という観点でのセグメントであれば、通訳者がブリッジだろう(同時にプロトコル変換も必要となる場合が多いが)。

オタ vs サブカルな話題が去年あったように、これもセグメントのいい例だ。ブリッジになれる位置にいる人はいるはずなのだが、ブリッジしないほうがいいだろう、的なムードになってる気がするが、ユリイカがそのブリッジを果たそうとしてみたのかもしれない。

そうだ、あるセグメントとセグメントの喧嘩をヲチするのはポートミラーリングしてトラフィックを監視するようなものかな。とすると、ユリイカはポートミラーリング行為を増産したとも言える。

ルータはスイッチをさらに広域対応にしたようなものだ。そう考えると mixi 自体がある意味ルータだが、コミュニティ、という機能は VLAN 的だ。ちなみに NAT は複アカだ。

L3 スイッチはルータ行為をハードウェアで行い、かつスイッチでもあるのでもうちょっと偉い(そして高い)が、イーサの口しか持ってないので別のネットワークでは使えない。ある程度の規模と範囲に限って高パフォーマンスなブリッジとルーティングを行う人、みたいなものか。

こんなふうに信号を受け取る側の個々人のお話もプロトコルスタックに照らして考えると面白そうだけどこれはまた今度。
misc | - | -

モデる側とモデられる側

コンピュータそのものではなく、コンピュータを用いたシステムでは、その設計段階で、扱う情報、ユーザーの振る舞い、メッセージ、そしてもちろん実現したい機能をモデル化する。設計(デザイン)とはモデル化とその実現方法の検討に他ならない。このデザイン屋をモデる側とし、情報や振る舞いの源泉たる人、をモデられる側とここで称してみる。

さて、システム屋のはしくれたる俺もモデリング手段なり新しいモデルなりへの興味は尽きない訳だけど、この、モデル化そのものに対して嫌悪感を抱き、反発する層ってのが存在する。

この層は「ふふん、オラのクリエイチビティをオメーなんぞのカタにハメられてたまるかコノヤロ」みたいなマインドを持つ層、と言い換えることもできる。新たにモデル化できたもの=スタンダード予備軍という側面もあるため、あらゆる標準化への嫌悪感を抱く連中がいることは、まあ、想像できなくもない。でもユーザーさんですので「少数意見」てな風に無視する訳にもいかん場合がある。

こういった層に出くわす場合、「どこまでモデル化するか」、というモデル化レベルそのものの議論となる。情報や振る舞いを、網羅性の高いガチガチのモデルにしてしまえばしてしまうほど、確かに実装はラクでしょうし、モデる側としては「モデれるものは全部モデりたい!」と思うのも自然ですが、ガチガチにモデル化されたオブジェクトはその発生元であるヒトの創造性を潰してしまうことにもなりかねない。

これが業務システムなら納期だなんだの制約事項のせいで現実解への収束もありえましょうが、コンシューマサービスは難しい。情報の用途をガチガチにしてしまったがために、(実はあった)多様性をomitしてしまう、という事態は避けたい。

オブジェクト指向のおかげで、モデる側は情報、に対するmethodは増やしうることを想定して設計できるようになったが、どうもそれだけでは済まないような気がする。

Web2.0のキーワードに「情報のremix」も掲げられているように、「情報」自体は非常に単純な構造で、そのmethodを足すためのAPIがオープンになっている、というアプローチが、情報の用途の多様性を担保するためのヒントではないだろうか。

なんて思いつつ2005年は暮れていく。
comp | - | -

生産性の向上だけが興味かしら

コンピュータの世界、というかIT屋の世界ではRoRなどAgileな開発手法についてトピックとなることが多い。メディアの煽動なのかもしれないが、皆の関心がそこにある、という顕れでもあるだろう。

しかし皆の関心が固定的になればなるほど、その分野での差別化は難しくなる。この世界、αな技術に対する興味が業界全体を先導しているという事実も無視できないが、本当のプロジェクトでは「実装が早くできましたね」という生産性だけが成功要因ではない。そして過去にも、本当に問題になったのはコーディングの生産性だけではなかったはずだ。

もちろん、これら生産性向上技術をトレンドとして踏まえておく、共通言語として知っておく、さらには生産性に対する世の中基準が今後こういった技術ありきとなることへの理解、という最低限の努力は必要だろう。が、懐刀として必要なスキルは生産性の向上だけなのか考えていくべきだ。

IT業界は、まだ、買い物下手なお客と売り下手なベンダとが互いに「どうやったら互いに納得する取引になるのか」を勉強している状態にあると思う。そんな中で、売り手、作り手が、己の視点で生産性にだけ興味を先行させ、本来顧客へ提供すべき価値がどこにあるのか、という議論がないがしろになってしまうことは避けたい。

などと思っているところに ITProの記事が現れて、自戒を込めて同意した次第。
comp | - | -

論理整理と物理整理


  • 部屋が汚い。てか物が多い。

  • (PCの)デスクトップやファイルツリーが汚い。てかアイコンが多い。


こういう、整理のできてない状態はあまり望ましくない訳ですが、自分の場合、後者のデスクトップやファイルツリーの最適化ならノリノリで行うことができます。これを論理整理と呼ぶことにしよう。

一方の部屋の整理整頓、物理整理はどうにも気が乗らない。これは昔からの性分でもあるけど、なんで論理整理はニコニコしながらやるのに、物理整理はイヤなのかを考えてみることにします。一度論理整理と比較して、論理整理ではよくつかう手段をどうやって物理整理に応用するか、これを考えてみるのです。


圧縮を効かす

布団なら有名な装置で圧縮できる。CDも、プラケースを外して圧縮できるな。書籍はムリだ。
そして伸張するにも天日干しとかしないといけなくて、面倒だ。


index をつけてみる

たとえばある引き出しの中身、について index を作ることはできるけど、出し入れしてもそのメモが自動更新されない。
検索もできない。

アクセシビリティを損なわないようにする

普段は触らないようなファイルは圧縮して「その他」みたいなフォルダに置いておくとしても、一覧性は損なわれても、アクセスしやすさはそんなに変化がない。が、物理世界では奥の方にしまってしまうと、取り出しやすいようにしておくのは難しい。


オブジェクト指向的にモノの method に応じた配置をする

ちょっと前ならCDを聴くためのコンポなどがあって、CDはそのそばにあればよかったけど、CDをリッピングする、という method が増えると、今度はPCのそばにCDを置かないといけない。
テレビ、ビデオ、HDDレコーダ、ゲームのコントローラなど、TV画面に関わる操作内容も年々増えてて、増えるたびに困る。


どうもうまくいかなそうだ。

それはそうと、部屋が綺麗で几帳面な人でも、デスクトップは異常に汚い場合がある。これは面白い。根本的に物理整理と論理性能は違う才能なのかもしれない。
misc | - | -