幻想は試さなければならないものだ
あれは幻想と括って試さずにいれば
本当に幻想のまま終わってしまう
ユーザーインターフェイスデザイン読みかけで止まってるんですか。GUI のなんかを作るときまでには是非とも読み終えることをお勧めします。もちろん他の本を読む必要もあるんですが、その本の注意事項ですら守られていないアプリもけっこう……
[topic:プログラミング]
今日は CLOS セミナー第二回にいってから、developer summit へ向かい
まつもとさんを囲う囲む会やその後の食事会
などに参加してきました。
その前にあった Java のセッションも時間があまっていたので「軽量」の文句につられてついでに見に行ったんですが(参加登録が遅かったので他が埋まってたのもある)、えーとつまり (Generics を導入しても C++ のような本物の) Template がないし(そのせいもあって)マクロのようなことができないため表現が冗長になりがちな Java よりもずっと agile で flexible
な XML を使うんだけど、それでも総合的なコード量はあんまり減少しないので XDoclet を使って JavaDoc 用のコメントから XML を自動生成すれば J2EE のような筋の悪いフレームワークでも IDE なしで WebObjects のようなことができますよ、そして (XML は使わないけど)このような感じのコード生成機能が将来の J2EE では実装されるはずですよ……って、マクロ欲しいんじゃん。使いまわしの利く分野ならあった方がいいので定型のプリプロセッサや構文を用意すること自体は否定しないけど、C のスコープがなくて再帰もないマクロがいかに悪かったとはいえ(言語設計者)みんなマクロを導入することにアレルギー持ちすぎ。AOP とかでやっていることも要するに Common Lisp (CLOS) の Method Combination のようなマクロの結果としてできることの一部をツールを利用して遠まわしにできるようにしたに過ぎないので、それならば必要に応じて新しく導入したりカスタマイズのできるマクロの方がどれほど良いか……。もっとも、マクロを極力使わない言語構造や直接用いることを少なくするライブラリの存在がもちろん重要なのには変わりないけど。
その後のオープンソースについてのセッションは、Linux-kernel 周りのことについては知らなかったので「そうか分散バージョン管理システムを使えば誰もが自分リリースを出せるんだな」とかそういう意味で面白かった。やはり前々から思っていたように darcs を使うことにしよう。まつもとさんのセッションは風穴さんの案内がずぶの素人には難しいだろうし分かっている人には物足りない中途半端なものだったという意見もあるけど、まつもとさんの Ruby 周りの話を面白く聞けていたので個人的には良かったと思う。Q&A とはいえ、オープンソースだから特許のリスクがあるんじゃなくてそれは製品でも同様にあるしむしろ金があるところが責められる、という見解がきちんと示されていたし。ところでその後の食事会で言ってみたけど、
特許に慣れ親しんだ電機産業の何でも出願主義、ソフトウェア産業に昔からいるものにとっての、よく見る当たり前の機能がまさか特許という感覚
のすり合わせを行うには特許を使って製品を作らせないようにするのかライセンス料を払わせたいのかを申請時に決めるゾーニングが必要なんじゃないかなと思った。そうすればライセンスを払う仕組みを事後評価制にすることもできるだろうし。まあ、今回の松下の件は完全に前例があったんだけど。
あっ、そうそう。Web フレームワークが乱立しているせいで仕事で Ruby を選択しにくいという意見があるので標準はどれって言ってください、そのフレームワークに不満があれば誰かがパッチを投げるだろうし、という話の中でまつもとさんが Ruby の Web フレームワークの標準はどれか宣言するということになったはずなので、いつまでたっても言い出さない場合はメーリングリストでつついてあげてください。
今日は RHG 読書会延長戦の YARV の発表会予行演習のはずが以前の発表資料を紹介されつつ突っ込む会でした。3時間30分にわたる問い詰めとか期待してたんだけどなー。
ライブドアの件についてメモ。まず未踏の交流会みたいなのでライブドアは M&A でよその会社を買いあさることでそこの業績をまるまるもらって売上を増やしていくというモデルを使っているという話を聞いていたので、投機屋という印象は最初からもっていた。次に会見のニュースを覗いていったなかでテレビを既に獲得したことを前提にして話していたかのような発言があったので、関心ははじめから過去のテレビ番組を pay per view で見れるようにしていくこと意識して行動しているんだろうなと思っていた。あとアメリカでは過去 IT 企業がそうやってメディアを買い取っていくという動きがあった。三つ目に Google での成功のように欲しいときに欲しい情報にリンクさせていくということを重視していって、広告を広告として意識させる領域から遠ざけていくことが今後の広告成功の秘訣だろうという試論。まあフジテレビを買い取ることは無理だから、ニッポン放送ごしに議決権を獲得できるかどうかが勝負の分かれ目だろうねー。できたからって望む方向に動かせていけるとは限らないということを含めて、博打的過ぎるけど。
今日はいつも通り陰陽大戦記の日。記憶を失ったソーマのお母さんに萌えたり、必殺
冒険王ビィトの方は……いつもいつも話の展開が遅くてどうしようもない中で今日は珍しくまとも。グルメアントの止め、どうせ体内に入るんだったらそこでしか使えないボルティックアックスじゃないのか、とだけつっこんでおく。
今日は第四回圏論勉強会でした。飲み会で「この会は圏論勉強会であって Conceptual Mathematics 読書会ではないので全部精読する必要はなく必要箇書だけ読んでいった方がいいんじゃないか」という話になって同意を求めたところ、賛成多数だったのでこれからやり方が変わりそうです。
IE7 がどこまで規格をサポートしてくれるかなという話になった時に「CSS3 で Web ページの角が丸い枠を作ったりするための border-radius というものが提案されていて Mozilla には既に先行実装があるんだけど、もし IE7 がまともに CSS2 はおろかこうした機能を持つ CSS3 をサポートして標準でできるようになったらこうした機能を table タグなんかでやらずに済むから(一部の) Web デザイナーが泣いて喜ぶだろうな」という風に言ったのですが、table タグや画像を使って (HTML ハックで)表現できるなら別にそんなものなくてもいいんじゃないというような感じであまり反応が良くありませんでした。個人ページにはそんな凝った装飾はいらないというような意見は分かるけど、P2P 方面といいどうもプログラマーは Web ページの構築におけるデザインとロジックの分離を標榜するわりに HTML で書いておいて CSS で(企業サイトなどを)デザインすることでロジックと分離するというアイデアに冷淡な気します。CSS3 が今の提案通りにのものとなったら、今の状態では HTML ハックを使わなければいけないものもどうにかなると言ってもいまいちでした。これはプログラマーにとって CSS は優しくない (tdiary とかはてなとかのCSS によるテーマを作れるのは別種の才能とか言われる(ソース失念))というのが関係しているんでしょうか？
一周忌ということであの人のお墓参りに行ってきました。可能性がありながら叶えられなかったもの、それを見届けるために。
なんかちょっとした間はまってたスランプを脱出。FFI で外の関数を呼び出すのはともかく、構造体を直接弄るというのはなんとなくためらいを感じてしまってつまってしまいました。むー、こういうとき物怖じせずに進んでくれるペアがいれば……。まあ、ちょっとしたテストプログラムを組んでみれば良かったんだろうけどね。
[topic:ビジネス]
企業にとって使えない人材をどうにかしようとする最も安易な方法は、その人材でも多分うまくやれそうな仕事を任せること、あるいは使えない人の首を切って使えそうな新しい人材を雇うことだ。しかし待って欲しい、これはミクロ的にはうまいやり方ではあるかもしれないけれどマクロ的には問題を生み出す。まず挙げられるのは、その使えない人材でもうまくやれそうな仕事を回すにしてもその仕事をこなすための能力が高い方がいいだろうし、仕事の内容によってはスループットから考えても割に合わないだろう((よくある TOC で言うところのコストワールドでの誤解のように)全体としてスループットが高くなるならばその人が何もやらない暇な時間が生まれてしまうことが悪いわけではないが、その人の仕事の内容への制限が全体としてスループットを悪化させてしまうような仕事の割り振り方になってしまうとまずいし、逆にその仕事の能力が高い人であればもっと早くこなせる仕事を閑職扱いされている実は忙しい仕事に回してボトルネック化させたりしてしまっていたら会社全体にとっての利益にはならない。)し、使える人の偏重が間が抜けてベテランの技術が若者に伝わらないギャップを生み出すという現象を起こしてしまうということである。もう１つはその人にとってそれが向いた仕事でないかもしれない場合に、能力の発揮できる向いた仕事へ就かせる可能性を閉じてしまわないかという問題である。日本型経営の大企業だと部署をぐるぐる回して一通り経験を積ませるということをやるようだが、それだけ仮定しなければならないということは誰でもその恩恵に預かれるわけでもなく、道を開くための手段は偶然に大きく依存してしまう。物凄く極端な例を言うと、年功序列にしろ成果主義とエリートコースにしろ出世レースはそこまでの成功に大きく依存するわけだが、中卒・高卒で現場の仕事はあまりうまくないけど人の上に立つとめきめきと頭角を現す人を偶然以外の何で釣り上げていくことができるだろうか？ ……まあ、極論ですが。
とは言っても何らかの対策をやるには普通その企業には余裕が必要(という考えになりがち)だから、使えない人材をいかにして使えるようにするかという問題はおそらく複数社で組んで取り組まなければならないことだろう。適所適材についてはあまり良い答えは見つからないが、ホンダのように最初に複数の業務に就かせて適正を見るというやり方を複数社を使ってやってみるということを試して見る価値はあるかもしれない。
人材を教育するという視点では、2人ペアで仕事をやらせるというのが１つのアプローチだろう。ペアプログラミングに関する文献や認知学習論などでペアで仕事をする方が学習効果が高くなることがいくつか実証されているし、ペアで働くことは一緒に働かなければいけないという強制やペアへの義務感などから怠業を抑制する効果や相手に話し掛けることで問題を理解したり一人が詰まったところをもう一人のアイデアで解決するという補助輪の効果を期待することができる。また、一人では気づけないことをもう一人の人が気づけることで最終的にアウトプットが良くなるので、リスク管理の面から見ても期待すべきところはあるだろう。仕事の中で教育する (OJT) を標榜する企業であれば、これをやるのは尚更理にかなったものだろう。……ただし、使用上の注意が1つだけある。長い間同じペアと組ませていると学習効果に限界があるし、癒着する可能性があるので、定期的にメンバーを交代しなければならないということだ。
というわけで、この二つを提案しておく。
"陰陽大戦記 夢小説"で検索かけてきた人がいた。夢小説ってなんだと思って探してみると、ボーイズ系サイト界隈で流行ってる 読み手側が主人公の名前をつけられる小説の仕組み
で(複数の)登場人物の名前を好き勝手に変えられる小説という定義と、自分を登場させる小説の二つの定義があるらしい。そんなの書いてません。ところで、オープニングでマサオミさんの属する流派がきちんと神流と表示されていることに今頃気がつきました。んー、すると第三勢力が存在することを気づいていた人はとっくの昔に気づいていたかもね。神流、の闘神士は位が高いせいか必殺技の嵐のなかを平然と潜り抜けたり、(様子見だったからか)伝説の闘神士と言われるヤクモを本気を出すまで追い詰めたり式神がやたら強いんですが……
そういえば書こうとして忘れてたネタがあるのでメモ。P2P でファイル共有ソフトを作るのに最良の戦略は、BitTorrent のように Python や Ruby、Lisp 等の動的言語を使ってオープンソースで海外に大元のソースを置いて開発することだと思う。そうして設計は僅か数行の書き換えで様々に変化することのできるモジュラリティの非常に高いものにしておいて、プロジェクトは純粋に技術的な関心を持って行われていることを標榜しておく。(ファイル共有以外の目的でも役に立つものにしておくこともポイントかも。)また、バージョン管理システムにはソースを分散して開発のできる darcs や Arc、Bitkeeper などを用いることで、Linux kernel のように様々な人が俺バージョンをリリースできるようにしておく。こうすれば例えそのソフトが違法な目的に使われたとしても、できる限り(絶対とは言わない)延命することができるんじゃないかなと思う。またオープンソースであることで、PGP であったようなソースコードを印刷した本を出版して言論の自由で争う方針も使えるだろうし。
[topic:C, C++]
mixi にだけ書いておくの情報閉鎖な気がするし、あそこの掲示板リンクが張りにくいのでこっちにも書いておきます。
C/C++ を学ぶための最初の一冊としては Accelerated C++ (Amazon) を読むのがいいと思います。もちろん、「プログラミング言語 C++」が良い本であることは間違いないし、厚い本の方が良いだろうという気持ちは分かります。だけど、C -> オブジェクト指向の順番で学ぶことが C++ を使いこなすための道を閉ざしてしまうことに成りかねないという実態 (たとえば STL を使わない) や、多くの人の「C++ が複雑でダメだ」という意見が学習過程のまずさからくることが多いのや、コーディングスタイルについて紆余曲折してしまうのを考えると、最初に C++ エキスパートに近いスタイルを道として示してくれるこの本で入るのが最良の道と思います。また多くの本では言語の機能を紹介しながらもその機能をどうやって使えば作りたいプログラムが作れるのかという道を示してくれないので、実際に問題の例を出してそれを解きながら言語のやライブラリの機能を解説していくというこの本のやり方は C++ (及びプログラミングすらやったことのない)初心者にとって助けになるでしょう。
STL など C++ の標準ライブラリを多用するこの本のやり方は C 出身で C++ といえばオブジェクト指向だろうと思っているような人には過剰に思えるかもしれませんが、実際のプログラミングでは一から全てを作っていくことなどまずなく既存のライブラリや API を何らかの形で利用することになるので、こういったアルゴリズムを使うことによって詳細を省略できるということを知っておくということは後々のことを考えると良い経験になると思いますし、また STL コンテナを引き合いに出すことでポインタや配列などに関しても短いながらも要領を得た説明で深いところまで説明しているという点で優れているので、例え実際の仕事で STL を使うことができないとしてもこの本でスタートをきった方が良いと思います。そういう意味で C++ を使う気がなく C を学びたいだけだという人にもお勧めします。K&R はその次に読めばいいと思います。
また、この本で STL + template から入っていけば、C よりも C++ が好き、 Java や C# の Generics がどうしてあんな偽物で言語の使いやすさを増さないものなのかというような C++ エキスパートの感情を理解することができるんじゃないかなという部分にも期待しています。C++ の template は Template Metaprogramming のようにそれを使えば何でもできるという凄さがあるためよく議論になるとその部分を強調して言いがちだけど、実際にはこの本に載っているようなごくごく初歩的な部分で template のメリットや Generics に対する不満など C++ にあって他の自称改良した言語にはない不便さが見えて来ます。そんな背景のない人間に色々とできることを主張したって、それができたからってどうというのだという冷たい反応を受けるか、それならまだいい方で、だからそれが使いこなせないといけない複雑な言語といった印象を与える結果になりかねませんから。
[topic:C++]
ちょっと前から DI、DI ってよく聞くなと思っていましたが、どうも最近またその話題が持ち上がったようなのでちょっと調べて見ました。あー、要するに STL のコンテナを typedef して vector や list などコンテナのアルゴリズムを自由に取り替えるというテクニックから始まって、標準ライブラリに見られるように依存するパラメータを Traits (特性)クラスにして template に突っ込んだり、Modern C++ Design で脚光を浴びたメモリ管理やソーティングアルゴリズムなど実際のライブラリの振る舞いを Policy クラスにして template に突っ込んだりする(例えば template 内ではクラス T を取って T::do_somthing を実行するようなものを書いておいて、実際にそのインターフェースを持つクラスを注入する)テクニックのようなものですか。C++ が何年も前に辿り付いた地点ですね。ただし template を使う以上、使用ケースは静的なものになるのが当然のような感じで C++ コミュニティは受け止めていますが。すると、Mock Object でのテストのために DI が必要な他の言語とは違い、目的用の DI を用意するために (Mockpp のような ものを利用した) Mock Object のよるテストを必要とするという逆転の現象が起こるわけですね。面白い。ただ STL どころか template の使用ですら躊躇う C++ プログラマーが多いなかではあんまりこうした分析が脚光を帯びそうにないのが残念。(例え注目されたとしても一部の最先端の人だけになりそう。)
今日は『計算機プログラムの構造と解釈第二版』を読む会II第二五回と WOMeeting と P2P 勉強会の懇親会のトリプルブッキングの日。どの飲み会も良かったらしいので体が三つあったらよかったのにと考えてしまう。その後来るなんて卑怯だよ。
WebObjects は CGIKit や Zope がそうであるようにフレームワークの重厚さから(チュートリアルなしで)入っていくのに壁があるので、WebObjexts による生産性の高さには GUI との連携による面も大きいのだと思っていたけど、GUI 派とエディタで自分で書く派がいるそうな。すると Kahua にはコード生成を主体とすることでコード量が少なくなると噂の Rails のようなアーキテクチャーが似合うと思っていたけど、意外に容易に WebObjects 的なものも取り入れていけるかも。もっとも設定ファイルの更新に応じて分散オブジェクトが現在実行中の処理がきちんと遂行できるようにブロックしつつシステムを更新するなど開発ツールのバックエンドでの処理に依存する部分は大きいらしく、Eclipse のプラグイン WOLips を作る方はそのへんの再現に苦労しているそうな。
P2P の集まりは未踏等 IPA のプロジェクトに関わっている人の卓にいたのでお話が非常に刺激になったし、動的にシステムを更新できる Lisp の CLOS の話をしたところ、汎用機のシステムを機械語で組んでいたころはコードを自動的に生成することをやっていたという話を聞けて、分散 -> 統合 の繰り返し用に (Wizard などのツールによらない) 言語内でのコードの自動生成というテクニックが何度も舞台に現れているという技術の繰り返しの歴史を改めて発見したのも収穫だったと思う。
で、前回同様飲み会終わるの早い。あまりに早いので、ちらっと WOMeeting の飲み会に参加した方が良かったかなとちらっと思ってしまった。そして帰りの電車で位置的に近いところではマルチキャストにして遠ければ DHT を使ってと言っていたけど逆にしてはどうだろうか(このあたりうろ覚え。言っていることが逆かも。)というような勉強会の内容に触れている話をしていたので、最初から参加していた方が良かったかなとちょっと思う。そして帰ってきて去った後で最初の読書会の方に来ていたことを知ってそこにずっといれば平内さんとかの「ユースの成果報告会」の話が聞けただろうにと思ったり……はい、そうです。浮気性です。
どれか１つに絞っていればかなり充実した内容を得られたのだろうけど、こういうスケジュールのおかげで飲み会でその席についたこと自体が偶然だし、それに動き回らなければそれぞれの情報を入れることができなかっただろうから、結局どっちが良かったのか分からない。
shiro さんの『Lisp 脳の恐怖』。Lisp に対する様々な逸話を知っている人には受けがいいけど、そうでない人の反応がなんだかいまいち。
パンヤで最近実装されたという、レベルアップして能力値が上がったことで使いにくくなったから能力値を下げるダウングレード機能のその発想は面白いなと思った。
オンラインゲームのフレームワークについて話題が出ると、既存の MMORG のようなものをどうやってうまく運用できるよう実装するかという話が主流になってどのような部分にゲーム性を持たせるかという視点が抜けがちになる。 ……既存の問題にどう対処するかを考えるのに興味があるんだろうから仕方ないのかもしれないけど、逆にそういった技術的問題が発生しないようにゲームをいかにデザインするかも重要なはずだ。例えば、パラメーターを弄るチート行為に対する技術以外の対処方法が少なくも二つ挙げられる。チートしてもそれがゲーム性にあまり影響を及ぼさないゲームにしたり、チートをするという行為をゲーム自体に組み込んでしまうという方法だ。もっとも、サイバーパンク的な世界観などを用意することでプレイヤーがそういう行為ができることに違和感を覚えないようにするといった工夫は必要だろうけど。どうように BOT に対しては、自動操作が意味なさないスタイルのゲームを作る他にも、最初から質の高い BOT 生成ツールを用意して誰が人間で誰がそうでないのかを突き止めるゲームというやり方もありだろう。P2P で Online ゲームを作る場合にその場所に人が集中するのが問題になる……ってそこに群集として集まることができる必然性はないわけで。……というか、みんな同じようなゲームを作る必要ないし。まあ、フレームワークとなるとできるだけどんなゲームにも対処する必要があるんだろうけど……汎用化って罪ね。