Shiro:log:2007後半
→ Shiro
(2007/12/31 17:19:58 PST)
今年もあと9時間だというのに仕事のキューは伸びるばかりだ。
仕事上必要があって組んでいたAMD64x2のWindows機に、これまた仕事上必要に なってUbuntuを入れた。で、Windowsの開発環境も必要なのでVMWareを入れて その中にWindowsを再構築。メモ→Shiro:WinXPonVMWareonUbuntu
-*-*-
blog.pmarca.com: The world is not so flat, God of Visas edition
Praying to the Visa God is actually quite a bit more rational than current US immigration policy.
インドにはヴィザの神様がいるそうな。H-1Bを取るために寺院を 訪れる人々がひきもきらないとか。
(2007/12/16 16:46:10 PST Spectrum, Stalin)
普段あんまりちゃんと読んでないIEEE Spectrumなのだが、今月号はおもしろかった。 Taser銃の仕組みとか、MMORPGのbotとRMTで稼いでいた人の話とか。
-*-*-
comp.lang.schemeの 速いScheme処理系は?というスレッドにて
- Stalinは速いぜ。チューニングされたCより速い。
- ホント? 単に比較してるCコードの方がタコなんじゃないの?
という流れにStalinの作者Jeffrey Mark Siskind本人が 有無を言わさぬベンチマークをひっさげて降臨。おもしろいことになってる。
言語の速度の比較で忘れられがちなのが、最適化はトレードオフである ってところだ。StalinはCを経由してネイティブコードを出してるんだから、 Stalinが出すCコードと同じものを手で書いてやれば、Cだって同じ速度が 出るわけで。でもそれだとあまりに不便なので、利便性と天秤にかけた 結果として現在のCの処理系に落ち着いてる。Stalinがすごいのは Schemeだからではなくて、バランスの秤を実行時の速度という方向に 振り切ったらどうなるかというのを 実装して動かしてる ところだ。 理屈の上ではどんな言語でも出来る。それを実際にやってるかどうかという 問題。
(2007/12/13 04:42:41 PST "Acting for the camera" 終了)
8週間のクラス終了。内容のまとめは少し落ち着いてから。 最後の最後まで濃いクラスだった。周囲のレベルも高くてついてくのに必死だったけど、 今まで取ったクラスの中では一番身になったように思う。 これを忘れないうちに応用できるチャンスがあるといいのだけれど。
別の参加者に先生が言ってたこと:
「役者としてのキャリアを続けるつもりなら、絶対に中途半端(half ass)な準備で シーンに臨むな。一度でも自分にそれを許すと、二度、三度とついつい基準を下げてしまう。 自分のつくるものが高い基準を満たすことに、常に厳格であれ。」
これは役者に限らないよね。プログラマでもフリーランスなら、 今自分がつくっているものの出来が良ければ次につながるし悪ければ次が無くなるわけで。
プロとアマの違いは何だろうかと時々考えるのだけれど、ひとつ確実に言えるのは、 プロはどんな場合でも仕事の質がある下限以上であることが期待されているということだ。 フィールドによっては、アマチュアがプロよりも良い仕事をする場合がある。 ただ、それは上のピークを見た場合。どんな人でも長く続けてれば波はあるもので、 プロかどうかを分けるのは山の頂きではなく谷底の標高が一定の高さをクリアしている ことではないかと思う。
(2007/12/09 19:16:38 PST 「好き」のいろいろ)
どんなにプログラミングが好きな人でも、毎日休まずプログラムを書き続けないと
生活できないとなると、それはだんだん苦痛になってくる。
好きなことを仕事にして生きていく、というのは、本質的にそういうことなのだ。
好きなことを仕事にしたとたん、「好き」はあなたを縛り付け、苦痛を与え続ける拷問台になる。
「好きなことを仕事にする」というのは耳あたりが良い言葉だが、 「何が好きなのか」に注意深くないと、このように困ったことになる。
私は確かにある種のプログラミングが大好きで、その種のプログラミングを やらせてもらえるならそれが毎日続いても全く苦痛ではない。 もちろん仕事とする場合、9割方はその本当にやりたいプログラミングを 成立させるために必要な雑事だったりするわけだが、その雑事も やりたい1割のことにつながっていさえすれば(つまり、やりたいことを やるための準備になっていれば)どうってことはない。
けれど、自分がやりたい種類のことにつながりがないプログラミングは 非常に苦痛だ。だから、「好きなことはプログラミング」と言い切る自信は さらさら無い。
自分の経験から考えると、「好きなこと」というのは仕事の名前で括れるような 大雑把なものではなく、もっとずっとずっとspecificなものだ。 Joel Spolskyが述べたように、 ソフトウェア開発だけ見てもその世界は細分化されている。 ひとつのジャンルでうまくやっていける人が他のジャンルでもうまくやれるとは 限らない。それだけでなく、同一のジャンルの中でさえ、個々のソフトウェア開発者が 担っている役割は大きく異なり、ある役割にフィットしている人が別の 役割にもフィットするとは限らない。例えばひとくちに「ゲームプログラマ」と言っても、 レンダリングエンジンをチューニングするのと、 プランナーやシナリオライターと連携を取りながらスクリプトエンジンを開発するのと、 CGデザイナーと連携を取りながらデータのコンバータや実機上のモデルエディタを開発するのと、 マルチプラットフォーム対応のためのフレームワークを開発するのでは、 やっている仕事の「感じ」はかなり違ってくる。 さらに、小さなスタジオでこれらの役割をいくつも兼ねながら小規模のゲームを 作って行くのと、大きなスタジオで単一の役割だけを極めてゆくというのも、 また全然違うことだ。
結局、「プログラミング」とか「ソフトウェア開発」とかというのは、 好きなことをやるための手段にすぎない。「プログラミングが好き」と言って 仕事をしていたとしても、本当に好きなことというのは多分ひとそれぞれ、 大きく違うものだと思う。単に手段としてたまたまプログラミングを選んだというだけで。
しかも、好きなことをやるための手段はそれだけではないかもしれない。 例えばピアノを弾いたり演技をしたりすることも、私の中では同じ「好きなこと」 の根源につながっているようだ。その根源が何かということは言葉でうまく説明 できないのだけれど。(というより、そこに何か一定の「根源」があると考えることが 間違いなのかもしれない。もっと高次の、演算子みたいなものがあって、 移り変わる状況のそれぞれに適用するとそれぞれの具体的な何かが出てきて それが次の状況に影響を与える、みたいな。)
手段に惑わされずに好きなことを追う方法は、常に好きなことに対する嗅覚を 磨いておき、うまそうな匂いをかぎつけたらすぐにそっちへいける準備を 怠らないことだ。そういう目で見るとfromdusktildawn氏は充分に好きなことを 追い続けているように見える。
(2007/11/29 16:08:30 PST Fitts's law)
最近になってFC6からFedora 8に変えた際にようやくFirefox 2.0系列を 使い出したのだけれど、タブを消すボタンがデフォルトで各タブにつくように なっててこいつが鬼門だ。タブをクリックするつもりで消すボタンをクリック してしまって肝心のタブを消してしまうことしきり。 タブ上右クリックのメニューからも消せるんだから、ここに消すボタンは 要らないとおもうけどなあ。user.jsいじれば消せるんだろうか。
あ、browser.tabs.closeButtonsだな。消えた。
しかし間違いやすいのがデフォルトになってるのは不自然なので、 私のマウスの動作が平均よりもケアレスなのかな。実はpersonal toolbarも 出しておくとタブをクリックしようとして行きすぎてクリックしちゃうことがあって 不便なのだ。
- 齊藤(2007/11/29 19:01:39 PST):私も同じ理由でタブを閉じるボタンは消して使ってます。確かに間違い易いと思いますし、Firefoxに限らず細かい機能を必要以上に表に出しているものは多いように感じます。しかし、考えてみると逆に各タブの閉じボタンを見せないのをデフォルトにした場合、閉じボタンが有った方が便利だと感じる人はわざわざマニュアルを見てそのように設定しようとするでしょうか?大半の人はマニュアルもリリースノートも見ないか、見てもざっとしたものでしょう。デフォルトで機能を隠すと、そういう機能が在るということを認識する機会が無くなるのではないかと思います。誰しもがアプリケーションソフトの全機能を把握してから使うわけでなく、特に規模の大きいソフトだとなおさらでしょう。そういう風に考えると、設定しなおす手間はあっても有る機能は見せる方向をデフォルトにするのは妥当な選択かなという風にも思えます。
(2007/11/27 17:05:13 PST)
あのGRAPE開発者・伊藤智義が目指す三次元TV実現: 「クレージー☆エンジニア」の連載は読んで元気が出る記事が多いがこれも良かった。 おっ、と思ったのはこの人、高校の数年上の先輩にあたるんだ。 少し前に「好きなことをとことん追求する自由」と書いたが(2007/9/9)、 あの高校は全体的にそれを許す雰囲気があったと思う。 (東大云々のくだりは私の世代ではちょっと変わってて、確か現浪合わせて10人くらい いたはず)。
(2007/11/19 03:31:16 PST ハック)
本来ハックっていうのは金儲けとは関係ない話なわけで。 ハックが金儲けにつながるかどうかはハックの範疇外の 話なんだよな。P.Grahamがペテンなのは、ハックがあたかも 金儲けに直結するような幻想を生んでるところなんだよな。
ペテンといっちゃぁかわいそうか。ハックと金儲けを 結びつける実験ということにしておくか。
いや、資本主義の仕組みをハックしてるんじゃないの? ハックの対象はプログラムコードだけじゃないって好例。
(追記2007/11/20 16:57:11 PST) バカが征く200711202
Shiroさんのいうように、P.Graham氏が『資本主義をハック する』、あるいは、資本主義のある側面を極端に推し進める のだとしたら、やっぱり自分は『それでいいの?』って いう疑問が湧くんですよ。
PGは戦略的にそういう方向のエッセイを書いてるから、 そういう疑問を持つ人がいるのはバランス的には良いことだろう。
あくまで個人的な印象だけど、Paul Grahamのメッセージは実は非常に 限られた種類の人間をターゲットにしてて、そこにメッセージを届けるためなら それ以外の人々に誤解されても構わないと割り切ってるふしがある。 だから、彼の書いたものを読んでそれは自分向けではない、あるいは みんながみんなそう考えたら困るじゃないか、と思ったとしても、それは正しい。 もともと万人に向けて書かれているわけじゃないから。 (ただ、ある人が対象でないということは、その人が「ふるい落とされている」という ことにはならない。単に対象でないっていうだけ。)
そうやってブロードキャストしたメッセージが埋没している潜在的な ハッカーに届いて、そのハッカーの背中を押すことができれば、 社会が結果的に(ハッカー以外の人にとっても)より良い場所になると彼は思ってるのでは。
で、ハッカーは贈与の文化で動くかもしれないけれど、人の称賛だけを喰って生きて ゆくわけにはいかないわけで。 もちろん有名になるにつれそれに若干の金銭的なものがついてくるので、ハッカー本人が 喰ってゆくことはできるようになるかもしれないが、ではそのハッカーが若い ハッカー達を育てたいと思ったらどうする? 「若いハッカー達が思う存分ハックできる ような社会を作る」というメタハックをするためには、経済を回してゆく手段が必要になる。
「起業→大儲け→新たなベンチャーに投資」というサイクルはそのメタハックにとって たぶん歴史上最も成功したモデルであって、PGはそのモデルをプロモートしてるわけだ。 金儲けはそのモデルによってハッカーによる社会を作るための手段にすぎない。 もちろんそれが唯一の方法じゃなくて、例えばRMSは似たようなメタハックを 全く別の切り口からやっているわけだけど、それはちょうどひとつのソースベースの あっちとこっちを別々にいじってるようなもんじゃないかなあ。
(まあ、PG的なやり方にある種の残酷さがあることは事実。例えばプロのスポーツ 選手とかミュージシャンとかアーティストとかが、そのような人生がいかに素晴らしいかを 語ってより多くの若者がそっちの道を目指すようになったとして、でもその中で成功するのは ほんの一握りであるという事実は変わらない。 そこにはバランスを取るために、「そっちは茨の道だよ」と言い聞かせる大人も必要だろう。 ただ、それでもそっちを目指す人間が増えて、裾野がひろがって頂点が高くなることで、 社会全体としてはより良いものを享受できるようになる。
でも成功オンリーの人生なんてことはそもそもありえないんだから、その残酷さは単に 現実の残酷さを隠してないだけとも言える。まあ、 捨てる神ありゃ拾う神ありで世の中うまく回るもんじゃないかなあと私は 思ってるんだけど。)
(2007/11/17 03:35:21 PST 入稿)
「プログラミングGauche」ひとまず入稿とのこと。細かい直しはまだ入ると思うけど。 もともとの予定は8月のLLイベントで発売ってことだったから半年くらい遅れて しまった。私がわがまま言って遅らせたんだけど。当初はユーザ視点で書いてもらう のがいいかなと思ってたんだが結局手を出したくなってしまった。 そのせいでGauche本だけじゃなくあちこちの締切をオーバーしていて 大変申し訳ないことになっているのだが、Gauche本そのものについては この半年の作業は無駄ではなかったと思う。 (ちなみにKarettaで読める「立ち読み版」からは 構成も内容も大幅に変わってる。大幅に良くなってる、はず。)
今回は共著だったけれど、それでも本一冊書くというのはしんどいものだと思った。 雑誌の特集記事が短距離走なら本はマラソンという感じ。
ソフトウェアは規模が大きくなると、なるべくモジュラリティを高めて コンポーネント間の依存関係を減らすことで、頭の中に収めておく複雑度を 押えることができる。ところが本の場合、まあどういう性質の本かにも よるけれど、むしろ依存関係がいろいろな層でたくさんあった方が良いんじゃ ないかと思う。物語でいうなら伏線みたいなものだが、技術書であっても 一見独立したトピックを扱っているようでいて前の章で振っといた問題に対して 後の章で意外な解決法を見せるとか、重要なテーマについては表現を変えながら 何度も触れるとか。それをやってると、一箇所直したらその影響が連鎖して 前の数章を手直ししないとならなくなったりする。
良くできたソフトウェアがコンポーネントを線形合成できるのに対して、 良くできた本は非線形の塊、カオスなプロセスだ。 本来はそうやって練って練って最後に落ち着いた平衡状態がベストなんだろう。
今回そこまでやれたかどうかは心許ないが、 一度リリースしてみる良いタイミングではあると思う。
技術書を執筆される方々にお願いしたい10の項目 -- 耳が痛いっす。
- ご苦労さまでした。
今回の共著に関して言えば、Shiroさんの場合は他人が書いた部分を活かしてあげながら修正しようとした箇所なんかは かえって不自由だったんじゃないかなぁ。
いっそイチから書いた方が楽だっただろうと思ったり。
ともあれ、立ち読み版と比較するまでもなく、ねばるだけの価値があったと思います。cut-sea:2007/11/19 19:45:24 PST - Shiro(2007/11/19 23:41:41 PST): いや、どうかなあ。 新規に書き起こしたいくつかの章もなんだかんだでかなり時間を取ったので、 全部新たに書いてたらとんでもなく時間がかかったのではないかと。
(2007/11/11 22:52:06 PST プライド)
理系の女の子が 一部で盛り上がっているがおじさんの出る幕でもないかとスルーするつもりでいた ところに弾さんが参入:
こういう幼少期の「プライド」が本物のプライドに化けるためには、一度「プライド」は徹底的に破壊される必要があるのかも知れない。私にとって、それが大学だった。
このエントリには大いに共感するのだけれど誰もがいきなりバークレーに 行けるわけでもないし、またこの話は元エントリの「東大理系女子」に限らず 大かれ少なかれスケールを変えていろんなところで見られる話なので (「初対面の人に大学名を聞かれて素直に答えられない東大生」、とかね) ちょっと書いてみよう。
弾さんが括弧を付けてる「プライド」は、昆虫や甲殻類の外骨格のようなもので、 特にまだ中身が未完成であるうちに外の世界から身を守るために重要な役割を果たす。 (子供時代のhigh achieverにはおそらく不可欠の要素だろう)。 ただ、やはり昆虫と同じように、中身が成長してきたらそれを脱ぎ捨てねばならない。 ちょうど学部生の頃はこの「プライド」の存在についてアンビバレントな感情を 持つ時期だろう。ずっと自分を支えててくれたものを手放したくない、けれども やりたいことをやるのに邪魔になっていることも感じる。
弾さんのようなショック療法で破壊してもいいんだけれど、問題は普段の日常の 中からいきなりそういう環境へと身を移す機会を誰もが持っているわけではないことだ。 また、やはり昆虫の脱皮と同じように、一度脱皮すれば本物のプライドが手に入るかというう とそんなことはなくて、脱皮してしばらくすると再び面の皮が突っ張ってくるものなのだ。 基本的に「プライド」は身を守る反応だから、何歳になろうとも、生き方が守りに 入れば自然についてきてしまう。(で、歳を食ってるほど「プライド」が破壊された時の ショックがでかいから、ますます守りに入るという悪循環があり得る。)
「プライド」を忌避したり隠したりするのではなく、 春になったらコートを脱ぐように、気軽に脱ぎ捨てるコツを身につけることが肝心だ。
それにはどうすればよいか。方法のひとつは、 モノを作り、それを衆目に晒し、批評に耳を傾けることだ。 あなたがあなた自身をどう思っているかにかかわらず、 あなたの作品は現在のあなたを残酷なまでにはっきりと表現する。 (その意味では 元エントリの gomi-boxさんは良いスタートを切った。ただし「自分語り」は最初の きっかけとしては良いけれど、二度は使えない。)
そうやって「自分が思っている自分」と「表現し得る自分」とのギャップを 何度も感じているうちに、奇妙な主客の転倒が起きる。
自分が作品を作るのではない。何か大きなものが、自分に作品を作らせていることに気づくのだ。
その大きなものに比べたら、「プライド」などはごく瑣末なものにすぎない。 瑣末であっても使える時はある。例えばしばらく表現することをさぼっていると 「プライド」の殻がくっついてくるが、 それは生き方が守りに入っているシグナルとして使える。攻めるばかりの人生も 疲れるので、守りに入ることは別に悪いことじゃない。 ただそれをわかってやっているかどうかは大きな違いになり得る。
(現役東大生の人には、手軽に使えるリトマス試験がある。 大学名を聞かれて、一切の照れもわだかまりも無く答え、 相手の反応を素直に受け取ってそこから自然に話を発展させてゆけるようになったら、 東大生という外骨格からの脱皮は完了だ。)
(追記2007/11/12 12:13:36 PST: 東大とかバークレーとか連呼してるから学歴ネタかと思われる かもしれないけれど、一般的な話をしているつもり。つい自分を属性で語ってしまい (「理系である」「女性である」「中卒である」etc)そうすることに こそばゆい自意識を覚えてしまう、もしくは逆に属性で語ることを意識的に避けてしまう 人にはすべて当てはまる; 別にそれが悪いというのではなくて、 もしそういうことに足を取られる感じがあるとしたら、どうすればいいかって話ね。)
- (ソフトウェアにせよ、それ以外のものにせよ)生産物を公開して批評されるとよい、という主旨には大賛成です。ただ、東大生云々の部分だけちょっとよくわかりません。私もよく(現役ではありませんが)相手によっては東大卒であることを隠したくなりますが、それは「東大生」という「属性」の平均的イメージによって馬鹿にされるのが嫌で隠すので(運動能力が低い、芸能に疎い、容姿が悪い、等々。少なくとも私についてはすべて事実ですが)、むしろプライドとは正反対の問題(劣等感)ではないでょうか。もちろん、劣等感は劣等感で問題なので、劣等感も含めて「プライド」と言っているのであれば非常によくわかります。:-)[sumii]
- Shiro(2007/11/15 17:44:30 PST): 括弧付きの「プライド」の定義をちゃんと示して いないのですが、弾さんの記事の文脈を受けてここでは「過剰な自意識が沈着して固まった何か」程度の意味に取っていただければ。従って劣等感もその一部でしょうね。 もちろん、弾さんの記事で「本物の」プライドと述べられているもの、 他者からの毀誉褒貶でゆるがないものに関しては全くの別物でしょうが。
- なるほど、元々の自意識過剰に加えて、最も身近な人からも毎日毎日毎日「あなたは東大生だからXXXなのよ」(XXXは任意のネガティブな言葉)と罵られている(笑)身としては、何かを公開して脱皮できるものなのかどうか全く自信がありませんが、頑張りたいと思います(?)。どうもお邪魔しました&ありがとうございました。
(2007/11/10 03:16:26 PST BABEL)
"Babel" を観た。すげー映画だと 衝撃を受けた。完成度の高さに。ほんのひとつのシーンを真っ当に作ること がどれだけ難しいかをactingのクラスで思い知らされた直後なだけに なおさら。ハーフマラソンで死にそうになってるところでトライアスロン 10周連続でやってる人達を目にして、ああ、あんなところにはとても 手が届かない、と雲の上を見上げる感じだ。
その後ネットでレビューを見ていたら別の意味で衝撃を受けた。 万人向けの映画でないことは確かだがこんなに評価が割れているとは… でもSICPのレビューも評価が極端に割れてたし、人の世界の見方に影響を 与え得るような力を持つ作品というのはそういうものなのかもしれん。 しかし、「わからない」「期待していたものと違った」とか、 あるいは「理解したけれど共感はできない」という感想は理解できるのだけれど、 「日本パートは不要」とか「無駄が多い」とか、ひどいのだと 「"Crash"の真似」なんていう評を見るとがっくりするなあ。
(ちなみにCrashの公開は2005年中盤。Babelは2005/4の段階の ドラフトの脚本で既に ほぼ最終形と同じ構成になっている。だいたい、製作規模の大きい 映画なら構想のタネから公開まで数年とか普通にかかるわけで、 1年かそこいら公開日が前の映画に影響されるわけないじゃん。 むしろその時の世界の空気によって同時多発的に似たような構想を 得る人がいると考える方が自然だろう)
脚本の完成度の高さは上のドラフトを読んでもわかるが、最終形では さらに刈り込まれているのが興味深い。例えば序盤、Scene 14のAmeliaによる 子供を寝かしつけるための物語などは入れておいたらより「わかりやすく」 なったろうけど、カットしたのは入れなくてもわかるという判断だろう。 とにかくそうやって贅肉をひたすら削ぎ落としているので、 ひとつでもセリフやアクションを見逃すとついていけなくなるかもしれない。 また、先入観無しで素直に見ればとてもわかりやすいのだけれど、 謎解きとか何かを探そうと思って見てしまうと全体が見えなくなって わからなくなるかもしれない。だから「わからない」という感想はわかるが 「無駄が多い」という批評には全く同意できん。
(2007/11/08 01:40:39 PST)
"obvious" と "oblivious"、字面はめちゃめちゃ似てるのに意味がほとんど正反対 なのはなんでだろうと思っていたのだけれど、わかった。 語源的にどうのって話じゃなくて直感的に。
このふたつは本当に紙一重なんだ。あまりにobviousなことは、しばしば背景に 溶けこんでしまって人はそれにobliviousになる。それが何かのきっかけで目から鱗が取れて、 「まえからそこに見えていたのに今やっと気づいた」と膝を打つ。"li"が鱗、あるいは 意識と無意識の間の蓋かね。
(2007/10/31 20:27:12 PDT)
ABAの日誌より
マイコンって'A'キーを押すとテレビに'a'で出るんだぜ!すごくね?
そう!すごいんだよ!
手製のマイコン (Shiro:OvenPC) にCRTCをつけてついに居間のテレビに つながった時、あんまり嬉しくてばあちゃんに 「キーを押してから画面に文字が出るまでがいかに大変か」を力説した。 ばあちゃんはどこまでわかってたものかわからないが、 とにかく盛んに感心してくれたものだった。
(2007/10/27 00:39:58 PDT Acting class)
ハワイ大学のnon-credit courceで「Acting for the Camera」というクラスを 取っている。一昨日が初回だったが、ディスカッション形式でなかなかintense なコースになりそう。メモをShiro:ActingForTheCameraにつけてゆくことにする。
今秋はもうひとつ、ベテラン俳優のOlympia Dukakisによるワークショップが予定されてて、 申し込んでいたんだけれどそちらはキャンセルされてしまった。 残念だけれど、Acting for the Cameraの方が課題の準備でそうとう忙しく なりそうなのでむしろ良かったかもしれない。
(2007/10/05 01:27:41 PDT Erik NaggumとTom Lord)
comp.lang.lisp名物の毒舌Lisper、Erik Naggum (Erik on C++、 Erik on Perl)の insightfulなポストを集めた記事があった: Lisp Usenet Classics。 メモリ管理のテクニックとか興味深い。 あと、随所に散りばめられる鋭い言説。
the hardest part for a programmer used to C and C++ and that crap is to shed the _invalid_ concerns. psychologists call them "obsessions" and charge people a lot to get rid of them. some programmers charge their users a lot to be able to keep them. go figure.
とか、
the C mind-set is that C is fast. this is even less true than their idea that CL is slow. writing really fast C code is _incredibly_ hard, ...
if you can't outperform C in CL, you're too good at C.
とか。
comp.lang.scheme名物のTom Lord。Guileから外れたあとPika Schemeってのを 作ってたと思ったんだが、なんかXMLベースの言語も作ってたらしい: The XQVM Programming Language and Doc-Soup Messaging。 見た目は気持ち悪いけど、セマンティクスは筋が良いっぽい。 しかし言語の人気は人間と同じで見た目にも左右されるからなあ…
(2007/10/03 18:28:46 PDT R6RS、エレベータ)
いつかはやらねばと思いつつ先伸ばしにしてきたんだが、何やらあちこちでR6RSの文字を ちらほら目にするようになったのでこれを機会にまとめることにした→ R6RS。 案外時間を喰ってしまった。こんなことやってるから締切が…
たぶん後輩のブログから: エレベータ使用禁止
***工学部2号館運営委員会からの連絡*** (1)1階から5階までの学生は,原則エレベータ使用禁止. (2)2〜3階の移動には,階段を使用すること.
(注:工学部2号館は12階建で,ボクは4階で生活する学生である.1階から5階の学生が平気でエレベータを使うコトによるエレベータの遅延が問題化していた.)
わしが居た頃はエレベータなんぞ無かったぞい。毎日階段を4階まで駆け登ったものじゃ (4階までしか無かったがな)。
というのは置いといて、運用で逃げてしまうのはいかにもださい。 電気電子の誇りにかけてエレベータをハックし、 最適化スケジューラを走らせる強者はおらんのか。
(ちなみに、今あるかわからないけれど、昔電気電子が3号館、2号館、弥生に分散 してた頃、各棟の入口付近に教官の在校状況が一目でわかるパネルが設置されていた。 3棟のパネルは連動していて、さらに秘書室でも状況が一目でわかるので 秘書室にかかってきた電話を効率良く処理できたという。 何でも、他の学科が木の札を裏返すとかそんなことをやってた時代に電電の先生が自ら 作ったシステムだと聞いたが…)
- はやみず(2007/10/04 04:47:03 PDT): 最適化云々というより、大勢が移動する時間帯(特に昼)には完全に定員オーバーしているようなので、おそらくそれが原因なのではないかと。エレベータは普段ほとんど使わないので推測ですが。
- 個人的には花より団子、システムより花をage。cut-sea:2007/10/04 06:06:39 PDT
- Shiro(2007/10/04 11:39:35 PDT): ナードの集まりであるところの工学部2号館においては、 時間を取られることが許せないのではなく、 (キャパの設計も含めて)間抜けなシステムが建物内にあることが許せないので、 花ではだめです。ただ、エレベータそのものハックしないでも、 クールなシステムが動いていることが示せれば可。(カメラでおよその待ち人数を計測し 予想されるその時点での待ち行列長さ、待っている人のうちn人が階段を利用した場合の 待ち行列長の変化を示してみる、とか。)←実は、混雑のピーク時に一度人力で 到着の分布を計測して待ち行列モデルに当てはめ、n人が階段を利用した場合の シミュレーション結果とともにわかりやすくパネルにして張っとくだけでもいいかも。 個々の利用者の事情の違いを切捨てて「n階までは階段使え」っていうような 官僚的対応がださいってだけだから。
(2007/09/28 18:48:58 PDT 悪女とツンデレ)
これ面白かった:西欧的悪女とキリスト教的な善悪の繋がり 悪女とツンデレの違い
西欧的悪女というのは、男の側に「悪」の影響を及ぼして男の運命(悪女が現れなければ善と して生きられる筈だった男の運命)を狂わして、破滅に誘う(例え、男が悪へ転向 することで生涯、物質的には成功しているように見えても、悪に堕落することは、 最後の審判があるキリスト教的価値観から見れば破滅以外の何ものでもない)、 男の運命を破滅させる女、ファム・ファタル(運命の女)としてあるんですよ。
日本にも悪女はいますが、この価値観(神の信仰による絶対的善悪と、悪=破滅 の価値観)が抜けているので、西欧では悪女とされるものも、「男を成功させれば、 別に悪女じゃないんじゃね?」みたいな感じで、悪女の概念が不確かになっている ところがありますね。日本では善悪の規範がはっきりとしてないので、悪女という概念 は捉えられにくいところがある。男を惑わせるのが悪女みたいな日本的通俗理解。
日本における上記のような西欧的悪女、というのでは斎藤憐の『クスコ』がすぐに 思い浮かんだ。といっても芝居を見たのははるか昔でストーリーもよく覚えていないんだけど、 目的のためにあらゆるものを利用しようとする藤原薬子を演じた吉田日出子と、 破滅へ向かうことを予感しながらも薬子との道を選ぶ小日向文世 (役名は忘れた) の 演技が忘れられない。
『クスコ』を見たときに「なんかシェークスピアみたいだなあ」と思ったんだけど、 たぶん斎藤憐は意識的に上のエントリのような西欧的な構図を日本の史劇に 持ち込もうとしたのではないかという気がする。もちろん薬子に唯一神に 基づく絶対善/悪という概念があったわけじゃないけど、定められた道を 外れるために悪を選ぶという点で、メフィストフェレスと取引したファウスト みたいな構図ではある。戯曲が手元にないからあまり分析できないけど。
逆に、シェークスピアの方に登場するツンデレといえば『から騒ぎ』のベアトリスだろう。 ベネディックとは会うたびに互いに悪口を浴びせあっているが、周囲の計略で 「ベネディックはあなたを好きなんだよ」と言い聞かされて心が動いて 恋文までしたためる。しかも計略が明らかになった後でも、 「あなたが可哀想だから結婚してあげるんだからねっ!」。 これをツンデレと言わずして何といおうか。
BEATRICE: I would not deny you, but by this good day,
I yield upon great persuation, and partly to save your life,
for I was told you were in a consumption (註: love sickness).BENEDICK: Piece! I will stop your mouth. (They kiss)
[Much Ado About Nothing, Act 5. Sc. 4]
ベネディックも相当鈍い男で見てていらいらするのだがここの行動は称賛できる。
しかしラブコメの要素なんてここ数百年変わってないような気がするな。
(2007/09/26 06:01:23 PDT マシン語ブーム便乗)
ついかっとなってやった。マシン語ならなんでもよかった。今は反省している。
当然のことながら、プログラムというのは、マシン語を出力して初めて「生成できる」と言うのです。
(追記) このお題についてはもうひとつネタを思いついていたのだが アセンブラと戯れていたら時間がなくなってしまった。 アイディアをここに記しておくので興味のある人はチャレンジしてみては。 基本的なアイディアは、コード生成をlazyにやるということ (お題を満たすかどうかは微妙だが)
- gensortは入力数Nを受け取ると、ソートプログラム sorter0 を生成する。
- sorter0 は最初の入力を受け取ると、「残りのN-1個の入力を受け取り、 それをソートしてN個の値を出力するプログラムsorter1」 を生成してただちに実行する。
- sorter1も実は同様に、入力を一個受け取ると「残りのN-2個の入力を受け取り、 それをソートしてN個の値を出力するプログラムsorter2」を生成して ただちに実行する。
- 以下、入力が全て消費されるまで再帰。
プログラムをカリー化してる、と考えられなくもない。Partial Evaluationの 限定的な応用とも言えるかな?
各ステージのプログラムは次のステージの生成規則を持っていればいいはずだし、 既に受け取った入力によって大幅に枝刈りが出来るから、 元のお題のようにn!で大きくなるってことは無いと思うけど、 どんな姿になるのかは興味がある。 あと、「「「プログラムを生成するプログラム」を生成するプログラム」…」 というふうに入れ子になってゆくとS式が圧倒的に有利になるんじゃないかと 思うんだが、実はそうでもないかもしれない。
- quine のバリエーションになりそうな予感nobsun(2007/09/27 00:55:26 PDT)
- gensort n は不要で、いきなり sorter0 から始められそう。(nobsun)
- Shiro(2007/09/27 02:00:23 PDT): いや、総データ数は必要じゃないすかね。 終了を知る必要があるので。 総データ数を最初に与えるのではなく、特定の入力があったら終了ってことに すればnは不要になるけど。そっちの方が綺麗かな?
- nobsun(2007/09/27 05:24:29 PDT): sorterN への入力はだんだん短くなるんだから、 その入力がなくなった時点で打ち切ればいいだけじゃないの?
- (2007/09/27 08:44:34 PDT): Haskell版を投稿しちゃった。
(2007/09/20 14:08:14 PDT 暗算)
私が子供の頃には、「アメリカ人は暗算が出来ない。ものを買うと、 こちらが払った値段になるまで、買ったものの値段に釣り銭を加えてゆく」 というようなことを聞いたものだった。 だが実際にアメリカで生活していて、そのやり方でお釣りをもらうことは滅多に無い。 それどころか、$8.77に対して$10.02出しても、眉毛ひとつ動かさずに 1ドル札1枚と25セント貨1枚を返してくる。
彼らが暗算能力を身につけたわけではない。 レジが釣り銭を計算してくれるようになったからだ。
などというくだらないことをこれを読んで思ったりした。
(2007/09/18 19:21:29 PDT 人と違うこと)
On off and beyond: 「迷ったら人と違うことをする」ということについて
「迷ったら人と違うことをする」というのは、本にも書いたし、メッセージとして日本のワカイ人に伝えたいなーと思っていることでもある。でもその伝えたい相手は
「ついつい人と違うことをしてしまうのだが、それではいけないのではないかと思い、自分を殺して世の中標準にあわせている人」
で、そういう人に
「人と違うことしても大丈夫。死んだりしない。安心して自分の好きな道を選んでください」
と言ってあげたいなぁというのが趣旨だったのでした。
わかるようなわからないような。例えばPaul Grahamが 「みんなが主流の言語で開発してるときにLispを使えば勝てる」と 言うのはよくわかる。彼のエッセイは上に引用したChikaさんの意図と似て、 非主流である技術を使うことにしりごみする必要はないよ、というメッセージだ。
けれど、例えば芝居がうまくなりたかったら、「クラスやワークショップに通うかたわら、 オーディション受けたり劇団に所属したりして経験を増やしてゆく」っていうのが 普通のことで、他の道も無いわけじゃないだろうけど、ここで「人と違うこと」をする メリットってあまり無い。(もちろんオーディションや舞台ではみんな「人と違うこと」を しようと思ってるわけだけど、常に人と違うことをしようと考えている人々の集団でさえ、 集団として一歩引いてみれば同じようなことをやっている人たちである、というのが おもしろいところだ。日本の芝居仲間とハワイの芝居仲間の行動を比較すると、 たぶん適当にサンプリングした日本人同士の行動を比較するよりも多くの共通点が 見つけられるのではないか)。
だから無限定に「人と違うこと」という言明にはあまり意味が無いと思う。 Chikaさんのエントリの結論に同意するかどうかはともかく、前提の 「迷ったら人と違うことをする」という話にひっかかりを覚えないとしたら、 それは対象としている集団について暗黙の仮定を置いているってことで、 その仮定が何なのかを考えてみるのはいいことなんじゃないだろうか。
「『他人が《普通》と考えているだろう』と自分が考えていること」を 認識するってこと。この入れ子関係が面白い。 実はこれがコメディの原点だ。
「普通の人」を演じるのは「変な人」を演じるよりずっと難しい。 なぜなら「普通の人」なんて人はいないからだ。よく見れば見るほど、 人は一人一人違う。普遍性は個人にではなく、 「その人が『他人はこれを《普通》と考えているだろう』と考えて、 それに影響を受けるさま」にある。 (本当は「変な人」も難しい。リアリティがある「変な人」とは、 上の入れ子構造の『他人は〜だろう』の中だけが極端に違っていて、 その外側のフレームは普遍的なものであるような人だ。)
(2007/09/15 20:22:19 PDT jottit)
Aaron Swartzの新しいプロジェクト Jottit。 機能はごく単純なwiki (というかwikifarm) なんだけど、インタフェースが秀逸。 less is moreの精神。
(2007/09/15 12:22:02 PDT)
Why g 〜 π^2: 重力加速度gは9.81m/s^2。π^2は9.87。このふたつの値が近いのは偶然ではない、 という話。
メートルは当初、地球の大きさを基準にしてた、と教わったものだったが、実は それ以前に、2秒を周期とする振り子の長さ、という案があったそうだ。 この定義を用いることは、gがπ^2と等しくなるように単位系を決める、ということと同じってわけ。
(2007/09/15 00:49:54 PDT)
つまりあれだ、普段からだだ漏れ抽象化の穴を塞ぐために右往左往してるから こういうネタがあると毒を吐きたくなる、ということなのだな。
(2007/09/14 18:40:15 PDT 収束)
あちこちで議論して、なかなか自分としては有益だった。だらだら書いてみる。
私の下のエントリの問題のひとつは、 (a) 現場でトラブル発生時に実際に「降りてゆく」必要性とか、計算機を「使いきる」ための 下層からくる物理的制約、という話と、(b) システムを理解してゆくための論理的、 あるいは数学的根拠、という話の2つがごっちゃになっているから、であるようだ。
鵜飼さんとこで 出たように、トラブル発生時に降りてゆく必要という意味では CPUのインストラクションセットアーキテクチャ(ISA)までわかっていればほぼ大丈夫なはずで、 というのは論理回路のバグはたとえ気づいたとしてもソフト屋さんには手の出しようが無い。 (TTLで組んだクロック2MHzとかいう時代ならロジアナやオシロで追いながらジャンパ 飛ばしてって話はあったろうけれど、今のマシンでそこまで追えないし、たとえ 追えたとしてもジャンパひとつ飛ばすのにだって分布定数回路の知識が必要になるから、 「論理回路」の下層まで降りるってことになる。そこはもうハード屋さん、あるいは ファーム屋さんが触るところで、ソフト屋さんの領域ではないと言い切っていいだろう。) ISAの上にはOSやミドルウェア、言語処理系、各種ソフトウェアツール郡が乗り、 抽象化の層を為している。
一方、ソフトウェアを支えている理論的な骨組みを学ぶ、という意味では、個々の CPUのISAはあまり問題ではなくて、抽象機械としてのチューリングマシンやラムダ計算、 それを実装するノイマンアーキテクチャのモデル (仮想的なCPUでいい)、 それを実現するための論理回路 (組み合わせ回路と順序回路)、って具合の話だ。 こちらは、現実の計算機に沿ってはいるものの、特定の面だけに注目して 他を捨象したモデルを取り扱う。こちらも抽象化の層があり、 下層のモデルは上層のモデルの振る舞いをある程度定量的に議論するために 必要だ。Knuthが "The Art of Computer Programming" で仮想機械語MIXを 導入したのは、アルゴリズムの計算量をO(n)などの見積よりもより細かく (係数レベルまで)算出するためにCPUのモデルが必要だったからだ。 もちろんMIXのモデルは現実のCPUにあるいろいろなgotchaを捨象している; キャッシュやパイプラインの振る舞いとか、アドレッシングモードによる 命令長や実行時間の違いとか。
こう考えると、抽象化には2種類あることになる。現実の部品と、そのモデル。 そして、部品を組み立てて、より大きな部品とすること (論理回路→組み合わせ/順序回路→ノイマンアーキテクチャ)。 モデル化にも、必要に応じていくつかの段階があろう (論理回路を理想的な ブール代数演算とみなすか、遅延やファンイン/ファンアウトまで考慮するか、等) 抽象化の網はこのようにふたつの方向にひろがっていることになる。
さて、現場で問題になる「抽象化の破れ」は主に、 モデルと現実の部品との間の差異に起因するように思える。 出力が1に確定しているはずなのが間に合わなくて時々0に見えたりする、とか、 「nextNode」を指すリンクにはノードクラスへのポインタか終端を表す値が 入っているはずなのにごみデータが混入していた、とか、 がんがん再帰してたらスタックが伸びすぎてヒープを上書きしてしまった、とか。
この時、トラブルシューティングをするには、まず「小さなモデル-大きなモデル」 という抽象化の階層を降りてゆき、破れが生じているレベルで「モデル-現実」 という抽象化の壁を越える必要があるわけだ。
「論理回路とその下の間に非常に強固な壁がある」というのは、そこでは 「モデル-現実」の壁が非常に厚いので、現場でそこの破れが問題になることが ほとんどないってことだ。より大きなモデルへと見て行った時に、 破れが起きやすい最初の場所が、CPUのISAなのだろう。だからトラブルシューターは 最悪、モデルの階層をCPUまで降りていって、現実との齟齬を調べることになる。
次はなんだろう。メモリとCPUからなるノイマンアーキテクチャのモデルかな。 スタックオーバーフローなんて話は、現実的には容量制限があるメモリと、 抽象的なスタックマシンというモデルとの間の齟齬と言えるかな。 あるいはバッファオーバランとか。言語モデルで見えている データは独立しているはずなのに、現実にはメモリ上に一直線に並んでいて 干渉することがある、とか。
あるいは、整数の演算というのは、モデルの階層は数学で作られている。 加減乗算については閉じているけど除算については云々、とかそういう話。 その世界では 1 + 1 も 10^100 + 1 も似たようなものだけれど、現実とのマッピング の段階でオーバフローを起こしたり多倍長演算が入って一方が極端に遅くなったりと、 齟齬が発生する。
まあ、この論自体もひとつのモデルであって、つっこみどころはたくさんあるけれど (「2種類の抽象化」って常に綺麗にわけられるのか、とか)、ここから何か無理矢理 考察を引き出すとすれば、
- 「理解する」というのは「小モデル - 大モデル」の階層を降りてゆくことになる。 これはある意味きりが無い。一直線ではなく分岐があって、ひとつの流れにおいては 一番基礎となるモデルがあるかもしれないけれど、別の流れを降りて行くとどんどん 先が続いている、という具合。
- 現場でトラブル解決には、「モデル - 現実」対応が破れている場所を 探す必要がある。こちらについてはある意味「きりが有る」。 現在の計算機を相手にしている限り、量子力学まで降りる必要は無い。
- トラブルが「モデル - 現実」の齟齬だとすれば、 「小モデル - 大モデル」の構造を知らずに現実の部品ばかりを相手にしていても 役に立たない。CPUが大事だからって80386のアセンブラに飛びついても、 「CPUのモデル」からアプリケーション層に至るまでのモデル階層の理解が無ければ、 現実のトラブル解決が出来るようにはならないだろう。
うーん、結局「どっちも重要」っていうありきたりの話にしかならないなあ。
(2007/09/12 20:22:11 PDT 子どもは何にも知らないの)
元のshi3zさんのエントリが断定調で、一般論と具体論が混ざってることもあって 異論反論パロディが続出したようで。つい黙ってられなくて あちこちにコメントしてしまったけど まとめとく。
解釈が割れた点は:
- 元の論の対象となる「プログラムが書ける人」は一般の職業プログラマや趣味プログラマまで 含むのか、それとも抽象化の破れにいつも直面してそれを何とかしてしまえるような 一部のタフな人材を指してるのか。
- 元の論の「マシン語を理解する」は80386アーキテクチャ特有のバッドノウハウまで 理解してばりばりアセンブラを書き下せることを指すのか、それともストアドプログラム アーキテクチャ、MMU、特権命令、割り込み、コンテキストスイッチなどの現代の 代表的なマシンアーキテクチャを理解するということを差し、80386を持ち出したのは 単なる代表例にすぎないのか。
あたりかな。私は両方とも後者と取ったけど、別に解釈すれば異論が出るのがわかる。
ただ、どういう解釈をしても次のような意見が出てくることには首をひねる。
「抽象化はレイヤの積み重ねで、論理回路の下にも半導体があり、電磁気学や 量子力学を知る必要があり、と続いてゆくから程度問題にすぎない。結局「自分は 論理回路から知っているよ」という優越感ゲームにすぎないのでは」
そう思う人にはDaniel HillisのThe Pattern on the Stone (翻訳: 思考する機械 コンピュータ) を勧めとく。翻訳は読んだことが無いが、原書の内容はとても平易なので、 内容だけなら中学生でも理解できるだろう。
第1章は論理回路。第2章で論理演算と状態機械。第3章でプログラミング言語。 第4章でチューリングマシン。第5章でアルゴリズム。以降、暗号や並列計算、 機械学習などを扱う。これを読んだからってプログラムがかけるようにはならないし 紹介された個々の概念を理解したことにはならないけれど、少なくとも現代のコンピュータが どういう概念の積み重ねで出来ているかという構造がわかるようになっている。
で、第1章の論理回路なんだけど、Danny Hillisはここで「スイッチとランプ」 「棒とばね」「パイプと弁」などで論理回路を作って見せる。つまりデバイスが 何であろうと、1と0が表現できてそれを伝達する仕組みさえあれば、残りの全ては その上に構築できるということだ。もちろん物理的に実現可能な規模で現代の CPUを作ろうとしたら半導体以外では非常に困難だろうけれど、今後全く新種の デバイスが出現して物理層がごっそり置き換わったとしても、上の層に 変化はない (ちなみに量子コンピューティングになったらどうなるの、という話は ちゃんと同書の中にも出てくる)。
私は高周波回路も量子力学も苦手だったし、数百MHzのバスクロックに乗るパルスの 波形や数GHzのチップクロックの中を走る電子の雲がどうなってるかなんて 考えたくも無いんだけれど、それらがデジタル回路の抽象化の壁を越えてくる確率と 「高級言語」で書かれたプログラムのSEGVに出会う確率にはあまりに大きな差がある。 抽象化力を指標とすれば、論理回路は非常に強力で成功した抽象化であり、 一方現代の高級言語の多くはまだその域に達していないとも言える。
このような抽象化の壁の厚さの違いに自覚的であることにより、次のようなメリットがある。
- 学ぶものごとに優先順位をつけられる。たくさんの層があっても、 壁が分厚くなっているいくつかの層を重点的に学べば安定した足場が得られる。
- 良い抽象化と悪い抽象化の区別がつけられる。自分で抽象化を設計する時に、 自覚的に壁の厚さを選択できる。
抽象化力の違いを無視して相対化してしまう危険は上のメリットの裏返しだ。
- あまりにたくさんの層があって全部は学べないから、とりあえず目の前の層を学んどいて、 漏れが出てきたらすぐ下の層、というふうに広げてゆくしかない、と思う。 でも時間に限りがあるから安定した足場までなかなか到達せず、いつも不安を抱えている
- 自分の設計した抽象化が良いのか悪いのか、判断基準が良くわからない。 また、与えられた問題に必要とされる抽象化の程度を判断できない。
なんだかんだで、ネタにマジレスな野暮だけど、せっかく書いたから貼っておく。
(2007/09/09 05:21:30 PDT)
前線からのニュースについて、 USと日本では大学入試の制度が違うから当てはまらないのでは、という意見があるが、 見るべき問題はUSの入試制度そのもの(admission officerだとかなんだとか)に あるんじゃなくて、 「ものをつくる能力、あるいはものをつくるために学ぶことができる能力と、入試で問われる能力との間に関係が無い」ことにある。 その点では日本の大学も同じようなポジションだろう。
(もちろん、全ての大卒がものをつくる人になる必要はないんで、 今の大学とか入試とかを変えるべき、という議論ではない。 「もしあなたがものをつくる人になるつもりなら、大学は関係ないよ」という話である。)
傾向として入るのが難しい大学には面白いものを作ってる人が多そう、 ということはあるのかもしれないが、個人的にはそれは入試によって ものつくりの能力が直接選別されたわけじゃなくて、高校までの段階で 「学業ができる生徒ほど、好きなことをやっていても干渉されないで済む」 というバイアスがかかったからではないかと思っている。
たぶん高校までで成績が良いことの最大にしてほぼ唯一のメリットは、 好きなことをとことん追求する自由が手に入りやすいということだ。 もちろん全体的な傾向としてであって、局地的には成績にかかわらず 自由なことをやらせてもらえる環境というのはあるだろうし、 そういうところからはやはり面白いものをつくる人が出てきているように思う。 (というよりも、好きなことを好きなだけ追求できる環境を経験せずに ものをつくる人になるのは不可能だろう)。
(2007/09/05 21:24:33 PDT)
久しぶりにPaul Graham節爆発って感じだったので思わず訳してしまった→ 前線からのニュース---News from the Front。
ところで野暮を承知でちょいと背景解説。
- Paul Grahamのエッセイのほとんどは、ハッカーもしくはハッカー的なるものを胸に秘めた 人に向けてかかれており、胸に秘めたハッカー性を積極的に追求して創造行為を行う人の 後押しをするという意図がある。もちろん目指すのはハッカーの創造によって 支えられる社会である。
- この話は、大学Aからランダムサンプリングした学生aと、大学Bからランダムサンプリング した学生bとの比較ではない。また、普通の企業に就職したり公務員になっていったり することを選択した(現在は大部分を占める)学生の話でもない。
- タイトルを "News from the Front" とつけたということは、Y Combinatorが "the Front" ということ。何に対する「前線」なのか。 もちろん、現在変わりつつある世の中の、変わって行く先にY Combinatorがいる、 という自負のあらわれであろう。
- いつも楽しく読ませてもらってます。気が付いたtypoをご報告します。(2007/09/07 08:17:55 PDT yuki)
- 最後から3番目の段落:「多くの場合たったひとつ利点しかない。」→「たったひとつ『の』利点しかない。」
- 註[3]:「それは世間一般の認識とそう変わらないなろう。」→「変わらない『だ』ろう。」
(2007/08/31 20:30:06 PDT)
http://theschemeway.blogspot.com/ 経由。 モントリオールでSchemeの求人ふたたび。
L'Association Mondiale des Radiodifusseurs Communautaire (AMARC) est à la recherche d'un Responsable des technologies de l'Information pour son secrétariat International situé à Montréal..Le candidat devra maitriser au minimum les technologies suivantes: * Internet (HTML/CSS/PHP/MySQL/GIMP e.t.c), * Administration des serveurs Linux (Postfix, nameserver, Apache, MySQL e.t.c) * Programmation en Scheme (Gauche & Guile) * WebStreaming (Icecast2) Le Candidat devra montrer un intérêt pour la radio Communautaire et être bilingue français et anglais (espagnol un atout important).
3番目の項目に注目。Gaucheが求人要項に明示されてるのを見るのって初めてかも。 ちょっと (いや、結構) 嬉しい。
それにしてもモントリオールは、こないだもGambit&Termiteの開発の 求人があったし、ひょっとしてSchemer天国? (Marc FeeleyがUniversité de Montréalにいるし)。
(2007/08/30 00:41:15 PDT)
博士の就職問題については分野によって事情が全然違うので、 背景を良く知らずに個別事例に口を出すのははばかられるんだけど、 これはどうかと思った。
理工系ですから、研究室の教授が、助手に残れといってくれるか、他の大学や研究所を世話してくれるか、企業に推薦状を書いて就職の面倒を見てくれるものと思っていました。
しかし、その期待はみごとに裏切られてしまったのです。教授は息子の将来について何も言ってくれなかったし、何もしてくれなかったのです。
ちょっと待てい。博士修了ということは、自分でプロジェクトを立案して遂行する 能力を身に着け、独り荒野を切り開いてゆく準備が出来たということではないか。 そこでなぜ他人に就職の面倒を見てもらおうという考えが出てくるのだ。
いやもちろんこの世は助け合い、何もかも一人でやれるものではない。 私とてバイト先で知り合ったベテラン技術者の人に紹介を受けて院卒後の就職先が決まったし、 独立してからもそれまでのつながりで仕事を受けているわけで、 いろんな意味でいろんな人に「面倒を見てもらいながら」生きている。 誰しもそうだろう。けれど最初からそれを期待して、何もしてくれなかったといって 愚痴を垂れるのは勘違いもいいところではないか。
まあこの記事は親の視点で、本人がどう思っているかはわからないから、 案外本人は親の心配をよそにしたたかに生き抜いているのかもしれない。
***
別に、博士を選んだのは自己責任だから自分でなんとかすべき、などと言うつもりはない。 私も博士卒の就職難は構造的に対応すべき問題だと思う。けれどその問題を、 個人的な視点から「多くの努力をして博士号を取ったのに職がない、悲惨だ」と記述 してしまうのは戦略的に上手くない。だって、音大を出たり俳優養成所を出たって 専業の音楽家や俳優になれるのはほんのひと握りだけど、そうなれなかったから 悲惨な人生だって愚痴る人はあんまりいない。ミクロな視点からは同じ状況なのに。
博士が問題になるのは、マクロで見た場合に、そういう人材を活用しないのは 国家的、あるいは人類にとって損失だから、だろう。そう思わない人もいる だろうけれど (というかそう思われていないから現在の状況があるのだろうけど)、 そこを「いや損失なんだ」と具体的な事例を積み重ねて説得してゆくことでしか、 構造は変えられないんではないか。
- どうも一般に「大学まで行かしたのに」的発言には
大卒の方が高卒より就職しやすいという誤解があるように思ったりします。
実際には学歴によって職(ポスト)が違うだけなんですが。
だから求職の市場は大卒と高卒で別市場だし、博士も大抵別市場になるわけで、 当然この博士さんの職(ポスト)争いをする相手は同じ博士達だから、 その中での競争に敗れれば学歴なんか関係なくプーになるのも至極当然の成り行き。 俳優だって棋士だって皆それぞれのフィールドで厳しい生存競争しているわけだしね。
このブログの人は理屈では、それなりに客観的に分析できてるように見受けるんだけど、 親としての感情が納得できないんでしょうねぇ。
こんだけ金かかって博士課程まで進んで、学会で何やら賞まで貰ってくるし、 末はえらい先生になるんだろうって、 息子を介してしか情報が入ってこなきゃ期待ばっかしちゃうわなぁ。 まさか行き先が無いなんて夢にも思わなかったんでしょう。
私も「教授は何もしてくれなかった」という発言には オイオイ!なんじゃソレ?と頭に血が昇りそうになりましたが、 サイトが母校っぽいのに気付いてガックリ萎え萎えですよ。cut-sea:2007/08/30 23:33:54 PDT
(2007/08/26 16:40:13 PDT 米国の医療保険料)
Michael MooreのSiCKOがあちこちで話題になっているのを見る。 早く見たいが子連れで映画館はきついのでDVD待ち。
米国での保険の負担はケースバイケースで一般的な話にするのが難しいんだが、 うちの場合、個人加入の家族プランで月$520払っている。年間$6,000超。 これで医療費の個人負担は1割〜3割になる。但し眼医者と歯医者は別で、 それらは入っていても保険料に見合うほどにはカバーされないので、 無保険にしている (歯磨励行虫歯厳禁、年に2回のチェックアップを自己負担で受けている)。 薬もほとんどカバーされない。また、HMOプランと言って、主治医が決まっていて 専門医にかかる場合も必ず主治医にかかって紹介を受ける必要がある。
うちの場合、自分の会社の従業員という形にして会社として加入することもできる。 するとカバー率は非常に良くなり、眼医者も歯医者も薬もOK、医者もPPOと言って 好きな医者にかかれるプランになる。しかし、保険料は家族プランで月$1,000を越える。
探せば多少安いプランはある。以前探したところだと、 計算機学会ACMのグループプランで月$450前後からあったかな。 ただ、ネットワークが違うために馴染の医者にかかれなくなるのであきらめた。 あと、プランもいろいろ複雑で、保証額の上限が決まっていたりすると 普段はいいけれど重病や大怪我で一番必要な時に保証されないという悲劇があり得るので、 安ければいいというものでもない。
なおこの金額は子供の居る家族の場合で、子供無しのカップルなら2/3、 独身なら1/3くらいになる。さらに所得などのいろいろな条件をクリアすると うんと安いプランが見つかる場合もある。そういう条件に当てはまらない ミドルクラスがいちばんきついのかも。
米国に渡っていつか独立しようと思ってる人はこのへん勘定に入れとくように。 理想は配偶者が勤め人でそちらの保険でカバーされる、ってパターンだろうなあ。
(2007/08/22 21:21:25 PDT 護民官ピート)
Paul Grahamと一緒にViaWebを創業し、 少し前には手製のセグウェイが話題になった Trevor Blackwellは、何とロボット会社を興して万能フランクを作っていた→ Anybots。 (いや万能フランクとは呼んでないけど。今あるのは"Monty"と"Dexter"らしい)。
ちなみに人材募集もしてるみたい。オフィスはY Combinatorのベイエリアオフィスと 同じとこらしいぞ。
(2007/08/18 01:02:06 PDT Sunday Wind)
一昨年撮影に参加した短篇映画 "Sunday Wind" が Palm Springs International Short Film Festival で上映される。8/24日。 http://www.psfilmfest.org/festival/film/detail.aspx?id=19246&FID=31
"Sunday Wind" 自体は14分程度の小品だけれど、監督達はオムニバス形式の フルフィーチャーフィルムの一部として構想しているそうなので、 これで全編完成への足がかりになってくれると良いなあ。
地元紙Honolulu Advertiserにも報じられていた。 http://the.honoluluadvertiser.com/article/2007/Jul/25/br/br5791032864.html
(2007/08/16 19:14:50 PDT 67対33)
オフィシャルなアナウンスは26日になされるので、これはあくまで現段階の集計だけれど:
賛成67、反対33。 選挙人登録は112人いたから、 何らかの事故で投票が届かなかったという人がまだ若干名出てくる可能性はあるにせよ、 「全投票者の60%以上の賛成票で批准」という規定によってR5.97RSがR6RSになることは ほぼ確実となった。 (棄権扱いになってる12人全員が、「俺Noに投票したぜ」と主張したら逆転するが… それはそれで面白いかも)。
何だかんだ言っても最初の頃のドラフトに比べたら非互換で大きな変更というのは それほど無くて、ライブラリレベルでサポートできる話がほとんどだから Gauche的には当面オプショナルな扱いでサポートしてゆくことになるかなあ。
それにしても微妙な結果だ… SCM, Chicken, Stalin, Larceny, Gambit, Scheme48, MIT-Schemeの作者は反対票。Gaucheもね。主要なScheme処理系の作者でも 投票していない人も多いし。Scheme界はさらなる混沌の時代を迎えるのであろうか。 あるいはPLT帝国が全Scheme界を掌握し、他の処理系を銀河の辺境へと追いやるのだろうか。 そしてR7RSで非PLT連合共和国が復活を遂げる、のか!?
(2007/08/14 17:30:27 PDT)
さっきラジオを聞いていたらキャスターのこんな言葉が頭にひっかかった。
Any idea is a good idea if you do it well.
(2007/07/29 20:49:15 PDT 求職中マーク)
キャリアエクスプローラーマーク。 応用物理学会の大会で、 求職中の学生はスライドやポスターにこのマークをつけてアピールできる、って話。
アイディアは別に悪くないと思うけれど、計算機系のいくつかのカンファレンスでは 特にアピールしなくても良さげな発表をした学生に企業がアプローチするとか、 学生側も企業の人と話してる時に "by the way, are you hiring?" とか言って レジュメをさっと出すとかってわりと普通のような気がする (いや、特に学生とは限らないな。会社名を出して発表しても後で「ところで うちに来る気無い?」と声をかけられることもあるし、転職のきっかけを 探すつもりでレジュメを持ってきてる社会人も少なくない。私自身も カンファレンスの場で誘われたことも誘ったこともある。)
これはやっぱり産業規模がでかくて就職口が多く、人間の流動も多い業界だからか、 それとも産業寄りのカンファレンスだからかなあ(SIGGRAPHとかGDCとか… SIGCHIで声をかけたこともあるか。) 計算機系でもPLDIとかPOPLとかICFPとかは雰囲気違うんだろうか。
- "are you hiring?"とはまた、えらい直接的かつ軽いなぁ。ノリが。cut-sea:2007/07/29 21:12:52 PDT
- Shiro: 軽いのかなあ。ごく普通の会話に出てくるけど… 企業側がアプローチかける時はもう少し丁寧かな。"if you happen to be seeking for a new career opportunity,..." とか。
- POPLか何か忘れましたが、発表の冒頭に「もうすぐ卒業するので求職しています」みたいなことを言っていた(&タイトルスライドにも書いてあった)人を見たことがあります。[Sumii] (P.S. コメントのしかたはこれで良いのでしょうか? 違っていたらすみません。)(P.P.S. 計算機科学としては超硬派(?)の理論系学会であるIEEE LICSでも、今年はGoogleがお金とブースを出して求人をしていました。)
- 私は元々業界が違うとこに居たからか、 「文化がちがーう」(エウメネス風)って感じです。:)cut-sea:2007/07/30 01:56:52 PDT
(2007/07/29 03:14:51 PDT どう書く.org, Haskell)
どう書く.orgは、問題の大きさが ちょろっと書いてみるのにちょうどいいくらい (SchemeやHaskellで 「エディタ1画面に収まるくらい」の長さ) なこともあって、ついつい考えてしまう。 締切前なのに。
せっかくなのでHaskellの練習をしてみてるんだけど、このくらいの小さな 問題だと確かに型って全然考えないなあ。全部型推論任せ。便利だわ。 Schemeにも型推論欲しい。
遅延評価については、まだ頭の中で動作を展開している感じだなあ。 Haskellの関数やオペレータを「遅延評価つき高レベルライブラリ」みたいに 認識している感じで、組み合わせた時の動作は操作的に理解している。 ただ、それだとモナドを組み合わせてくようなところで途中でわからなくなるんで、 宣言的頭をもすこし強化せねば。
そんで、Haskellをぽちぽち書いてみての印象:
- 優先順位覚えるのが面倒。型エラーのほとんどは今のところ優先順位を
間違えてて思ってたのと違う結合になっちゃってるせいだ。慣れればいいんだろうけど
慣れちゃうのも癪なんだよなあ。
- 関数適用は左結合で最強、$ は右結合で最弱、これだけ覚えておけば、あとは括弧でくくればいいと思うだすnobsun
- ごちゃごちゃいじってる最中に、ソースが型的にinconsistentになるってことが 良くある。例えば下請け関数x,y,zを書いてghciで動作を確かめて、それを組み合わせた wを書いている途中でふと気づいてxの定義を直した、みたいな場合。 またさくっとソースをロードしてxの動作をインタラクティブに確かめたいんだけど、 xの型が変わってるのでwのコンパイル時にエラーになる。 Lisp/Schemeだとそこは全く気にしないでいいわけだが、Haskellerはどうするんだろう。 いまのところこういうケースではwの定義をいちいちコメントアウトして ロードしてる。
- 具体的にはどういう場合なのかしらん。w の型宣言を省略するか、しないかということ?Schemeで気にしなくていいところは、Haskellでも気にしないんじゃないかなぁ。nobsun
- 型宣言がどうこうじゃないと思う。xの型が変わってしまった時にwもそれに合うように修正してやらないとダメで、新しくしたxだけを評価して確認することができない。
新しくなったxの確認のためにwも刷新してやらないといけないってことだと思う。
;; 正直型はどうでもいい x :: Int -> Int y :: a -> a z :: [a] -> Int ;; ここでは引数にx,y,zを使ってるっぽく書いてるけど、 ;; 一般化して x,y,zが使われている場合と考えてね。 w :: (Int->Int) -> (a->a) -> ([a]->Int) -> a
な何かだったとして、;; 新しくxを書き換え。これもさっきと型が違えばなんでもいい。意味なし。 x :: [(a,Int)] -> (a, Int)
となる何かに変更したとする。 xだけちょっと確認したいんですよ。要は。 この時にwをどうしてる?ってことでしょう。cut-sea:2007/07/30 09:36:47 PDT - で、wがfとかgから使われてる場合もあるので、コメントアウトは芋蔓的に拡大しうるからあまり常用できそうにないっすよね。
多分、xを直接変更するんじゃなくてx'を別途作って、動作確認してからxと差し替えたりするんじゃないかなぁ。まぁその辺はどうしても手間にならざるを得ないと思うけど。cut-sea:2007/07/30 09:54:36 PDT
- この手間は言語に関係なく同じだよね。--nobsun
- もちろん修正の範囲は言語に関係なく同じです。
Haskellでは、この場合コメントアウトなんてしないよ。 どうせxだけ確認してもダメでしょ? 結局最後には全部修正しないとダメなんだから、 xの確認なんかより全体がロードできるようにするのが先! ということであれば、まぁそういうものかと納得するしかないです。
ただSchemeだと開発の作業順(作業量じゃなく)て、 repl使ってちょこちょこ部分部分を積み上げていけるスタイルが、 楽チンだと感じる面があるので、 作業量が一緒だから同じでしょということに対しては、 やっぱり感覚が違うなーとは思いますが。cut-sea:2007/07/30 23:38:36 PDT
- もちろん修正の範囲は言語に関係なく同じです。
- この手間は言語に関係なく同じだよね。--nobsun
- Shiro(2007/07/30 12:02:59 PDT): そういうことです > cut-sea。
ファイルをリロードしたいんだけど、その中の「すぐに使わないことがわかってる関数」
の中に矛盾があった時どうするかっていう。
Schemeではそれは気にしなくていい。
- Haskeller は怠けものだから、そもそも「すぐに使わないことがわかってる関数」なんか書かないんです。:) --nobsun
- ハイそうですかとは納得できない。:(
nobsunや他のHaskellerが書く書かないじゃなくて、 仕様変更が関数の型を変えることを要求するってのはあるんじゃない? リファクタリングの過程でもいいけど。
Haskellはじゃなくて、Haskellerは人間なんだから、 間違った型の設計をすることはあるんじゃない? それに気付くのは後の方だったりしないのかな?
この件については、私自身はトレードオフだと思ってて、 Haskellは(型レベルでの)全体のconsistencyを保証することと引き替えに、 プログラマにはコード全体を完成させることを要求するわけで、 部分だけ試したいという欲求にはそもそも応えにくいのは仕方ないと思ってるんですよ。 Schemeとかはconsistencyの確保はプログラマまかせだけど、 全体と矛盾している状況でもとりあえず部分を確認することは出来る。
確かにアプリが完成した(エラーが出なくなった)時点でHaskellの方が安心感はあると思う。 でも、改修規模が大きな状況では、改修の途中段階で、ある変更したことによって、 その部分がとりあえず動くという確認がこまめに取れるのはストレス軽減になるでしょう?
だからHaskellでだって一個関数書いたらC-cC-lでこまめに確認したりしますよね? これって今書いたところまでが問題なさげか確認して足場を確保してる感じだと思う。
セーブポイントのない巨大なダンジョンの中を延々歩かされるストレスから逃げたいんですよ。 セーブポイントはいたる所にある方が安心できるんです。
(Haskellerはリリースした後までinconsistentかもなんて 不安やストレスから逃げたいんですよ。って言われたら納得ですが。)- Haskellerにとって一番重要なのはリリースした後までinconsistentかもなんて不安やストレスから逃げたいということです.
- ナットク。:)
- で、このセーブポイントがHaskellだとなんかコメントアウトしたりして、 面倒なんだけど、どうしてんのかな?ってのは当然の疑問だと思う。 言語の問題じゃないんだから、そういう状況は当然ありえると思うんだけどなぁ。cut-sea:2007/07/30 23:02:51 PDT
- ハイそうですかとは納得できない。:(
- Haskeller は怠けものだから、そもそも「すぐに使わないことがわかってる関数」なんか書かないんです。:) --nobsun
- やっぱり考えかたが違うかもしれない.そもそも使われかたによって,型が決まるので,x :: a だったものを x :: (a, Int) にするということの動機あるいは根拠はこれを利用する関数側からのものだから.孤立した文脈でテストしたいなら,x' という名前でテストするなりすればいいんじゃないかと思うけど.ghci にかぎれば,repl で let x = ... とするというのもありかも.--nobsun
- x を直接利用している関数が w だけだということが分っているなら
w = ... x ... x ....
をw = undefined {- ... x ... x ... -}
のように一時的に undefined の値にしてしまうという手はあります. 一種の comment out だけど、w 自身は型としては適切に定義されるので w を呼ぶ関数は変更しなくてもよい。ときどきやります。 --nobsun - ああ nobsun に書かれてしまったかな。 w の局所定義で x を undefined にするという手があると思います。というのを書いてみました→ http://www.jmuk.org/diary/2007/07/31/0 これは w でしか x を利用していない、といったケースを想定しています。 w 自身を undefined にするというのはわたしもやります。ところで const undefined ... だと型検査に失敗しませんか? -- jmuk
- ああそうですねぇ.うまくいくこともあったと思いますが,一般にはだめですね.筆がすべった.:)
- Shiro(2007/07/30 22:53:29 PDT): 「使われ方によって型が決まるので」--- その使われ方を試行錯誤している段階の話なんですが、Haskellerは 最初に使われ方が頭に浮かんじゃうんでしょうか。 例えばどう書く.orgのトランプの問題で、 引いたカードの可能性をカードの数のタプルだけで [(Int,Int)] と表現すべきか、 積と和もついでに計算しといて [(Int,Int,Int,Int)] でやった方が簡潔になるか… どれが良いかはある程度上位の関数まで書いてみないとわからないじゃないですか。 [(Int,Int,Int,Int)] で書いてて、途中で [((Int,Int),Int,Int)] にしたら 余分なlambdaを書かずに素直な関数合成で済むことに気づく、とか。 そういうのは無くて、最初からもう型は見えてるもんなのかなあ。
- Shiro: ああ、「使う方から型を見る」ってことは、トップダウンで考えてるって かな。だからxやyで試行錯誤する前に、wがもう出来てて、そこの要請にあわせて xやyを書いてゆくと。私は具体的なデータが目に見えないとピンと来ないんで 先に下の方のユーティリティ関数を書いていろいろデータを流しながら 考えることが多いんだけど、nobsunは逆なのかなあ。
- トップダウンで書くこともあるし,ボトムアップに書くこともあります.でも常に型のプログラムを先に書きます.tramp問題なら最初は
type CardPair = (Int,Int) n :: Int n = 13 solve :: [CardPair] solve = b2 xys :: [CardPair] xys = [(x,y) | x <- [1..n], y <- [x..n]] a1 :: [CardPair] b1 :: [CardPair] a2 :: [CardPair] b2 :: [CardPair] a1 = undefined b1 = undefined a2 = undefined b2 = undefined
てな感じではじめます.常に型検査がパスするように定義を追加します.Haskellプログラミングは「型をプログラミングする」=「仕様をプログラミング」するという感覚です.型検査をパスするようにすること自体もプログラミングなので全然面倒だとは思わないんですよね. - Shiro(2007/07/31 01:22:24 PDT): あーこりゃ見事にトップダウンですねぇ。 私は最初にmultiplesToとかsumsToなどのユーティリティ関数を作って、 その出力をいじりながら a1, b1…と作ってって、最後に全体をsolveでまとめました。
(2007/07/25 13:51:33 PDT Y Combinator portfolio)
WikipediaのY Combinatorのページが妙に充実していた。
Summer 07の会社名はまだ追加されてないが、Summer 07の Adpinionはなかなか良さそう。 バナー広告をビジターが評価できて、それによりオーディエンス向けにターゲッティング してゆくというアイディア。インタフェースとかうまく作りこんでると思う。
ところでDropboxはYCだと思ってたんだけど 載ってないなあ。勘違いか、それともこのリストは全部じゃないのかな。
追記2007/07/27 12:52:11 PDT): Adpinionのアイディアは面白いとは思うけど、実際どのくらい うまく動くのか---広告を見てわざわざvoteまでする人が十分にいるのか---は やってみないとわからない。ということで実験に協力してみることにした。 気づかれた方もいると思うが、practical-scheme.netのトップページ、 Paul Grahamの翻訳、それと Scheme Cross Referenceの ページにAdpinionを入れてみている。 まだ広告主が少なくバリエーションに乏しい感じだなあ。
ちなみにまだレポート機能は作ってる最中だそうなんで、 実際どのくらいの人がvoteしてるかとかはわからない。 最初のうちは好奇心でクリックする人も多いだろうから、 しばらく続けてみないとなんとも言えないだろう。
(2007/07/20 02:00:00 PDT コードを書く人)
アーキテクチャを決めて下の人に実装を任せたりだとか他人に仕事を振ったりだとかたくさんのサブコンを使って一定の品質のアウトプットを出すべく管理したりだとか複数の会社の係る仕事でお互いの進捗を管理しつつ予想外の事やらトラブルやらを調整したりだとか会社の方針を決めるような上の会議に参加して問題を根本から解決したりだとか業界の趨勢を決めるようなサービスの立案やら実現やらに力を注いだりだとか。
そういった仕事に関わっている天才プログラマよりも、現場の最前線で延々とコードを書いているコーダーの方が最後にはプログラマとしての「物を作る能力」は高くなる、という信念のような物を、私は持っています。 最後にはコードを書いている人が勝つ、と。
Googleでは偉い人ほど多くのコードを書いている、って中の人に聞いたことがある (さすがにSergeyとBrinレベルになっちゃうとそんな暇は無いそうだが)。
下にメモしたFlektorのJason RubinとAndy Gavinだとか、ZenterのWayne Crosbyだとか、 まあその流れならViawebを作った当時のPaulとRobertとTrevorにしたって、 やっぱり「天才プログラマ」という称号は誰よりもコードをたくさん書いて ゼロから何十Mっていう価値を生み出しちゃう人々にこそふさわしいのじゃないかなあ。 (IPAに認定されたぐらいじゃだめだよね。)
世の中というのは色々な人がいてこそ動いているので、コードを書かないでも 人をがんがん動かしてどんどんプロジェクトを回して行く人がいていい。 でも、技術ベンチャーをやるなら、コアメンバーはやっぱり誰よりも良いコードを たくさん書く人であって欲しいかなあ。少なくともプロトタイプ作成くらいまでは。
ところで、アウトプットの管理とか現場の調整とか方針の決定とか、 そういうのってプロデューサーの仕事だよね。コンテンツ製作現場では、 プロデューサから制作管理へのラインと、ディレクターから製作部隊への ラインとの役割分担がわりと明確で、うまく機能してると思うんだけど、 ソフト製作でもそういう分担があった方がいいんじゃないかなと思うことはある。
(2007/07/18 23:52:43 PDT Flektor)
Web上でメディア(video, audio, image)等の編集ができて、そのままMySpace等に パブリッシュできるFlektor。最近買収によるexitを 果たしたそうな。トップページはずいぶん派手だけど(target audienceが MySpaceユーザ層あたりなのかな)、"Full Editor" などよく作りこんであるっぽい。
この会社、かつてNaughty DogをやっていたJason RubinとAndy Gavinによるものだ。 そう、Lispでコンソールゲーム作ってたところである。 SCEに買われて、Lispやめちゃったと聞いていたけど、Founder達は抜けてこんなこと やってたのね。バックエンドは何を使ってるのかなあ。
Startup Reviewの記事。あまりテクニカルな面には触れていないけど、 「コンソールゲームで培った方法論=ツールの整備にたっぷり時間をかける」が効を奏したとある。
(2007/07/16 14:10:26 PDT 時をかける少女)
アニメ版。DVDになってこちらでもレンタルできるようになったんでようやく観た。 脚本も演出もやりたいことの筋が通ってて、丁寧に作られていて好感が持てたし楽しめた。 それほど感情移入は出来なかったけど---20代で見てたら違ったかもしれん。 まあそれだけ分別くさい大人になってしまったということだろう。今や、 登場人物よりも作り手の情熱の方に共感してしまう。
背景が美しい。教室と、校門脇の守衛所、それから中庭の屋根付き通路は東京女子大かな? スペシャルサンクスに出てたし。学生の時の劇団が東女・東大中心だったので よく東女のキャンパスで稽古をしてた。
で、やっぱり気になったのが、ネット上でも盛んに議論されている 例の記憶に関するinconsistencyだなぁ。 (一応、以降完全ネタバレ)。
叙述トリックという説もあるんだけれど、そう解釈するには苦しいセリフが 2箇所ある(真琴の「だって、今、ここで…」と「ゼロになったはずなのに」)。 脚本は十分に練られたらしいから、 叙述トリックにするつもりならちゃんとそう出来ただろう。 敢えてそうしなかったのだから、これらのセリフは (脚本上のミスではなく)制作者側が意図したものだと考える。
さらに、リーパー以外の記憶が通常は巻戻されることもセリフではっきり述べている (千昭「今のお前は知らないだろうけど、功介とあの子、一回…」)。 (「実は千昭も全部覚えていたよ説」「千昭が真琴を道連れに跳んだ説」は このせりふと整合しない)。
この矛盾を解決するものとして「真琴勘違い説」とか「白昼夢説」とかがあるけれど、 一見矛盾するせりふが意図的に仕込まれたのなら、そこには制作者の明確な意思があるはずで、 これらの説はちょっと明確な意思としては弱い。制作者側に立つなら、 メカニズムはどうあれ、あの記憶だけは(通常のタイムリープのルールを超越する) 特別なものであったとしたかった、と考えるべきだろう。
脚本は他の部分でも余分な説明をギリギリまで刈り込んでるから、 ここでもメカニズムの説明が省略されたのは意図的だと思われる。 SFやミステリとしてはルール違反だろうけど、 メカニズムの説明よりもその記憶の重大さこそが制作者の 伝えたかったことなのだろう。
それでも納得できない人はターゲットオーディエンスではなかったということで。
(2007/07/11 18:51:00 PDT Scheme Job)
カナダ(モントリオール)にある会社がSchemeプログラマ募集中、だそうな。要フランス語。 → http://theschemeway.blogspot.com/2007/07/scheme-developer-wanted-alive.html
- Frenchまるで分からない某Tくんもフランス行き決定したらしいっす。 初の一人暮らしで言葉の分からんフランスに行くってんで、 周りをおどろかせました。度胸満点。cut-sea:2007/07/11 19:02:50 PDT
- び(2007/07/11 19:48:09 PDT): Scheme/Javaプログラマってことは、SISCかなぁ...
- どうだろう。その可能性もあるけど、 仕事となると複数の言語で部分部分を別にやることはありえるから、 言語そのものの実装とは別なんじゃないかなぁ。cut-sea:2007/07/11 19:53:41 PDT
(2007/07/08 02:11:09 PDT チームでの集中)
バカが征くより:
そうそう、concentration (あるいはzone、あるいはその意味でのflow) はXP の価値ではないということもできます。一方で、communicationはXPの価値の1 つだと。
communicationという価値を基準に考えたら、キーボードから手を離して相手の ほうを見るというのはごく当然のことです。「集中しているときは communicationは疎かにしても構わない」というのは自分にはダブルスタンダー ドに思えますし、そういうのは避けたいです。
それはチームとして集中しているってことなんじゃないのかなあ。 バンドの練習中、スポーツの試合中、芝居の稽古中、参加者同士で コミュニケーションは当然取るわけで。それは集中を乱すことにはつながらない。 そういう時って意識がシンクロしてて、ちゃんと「声のかけどころ」が わかるんだよね。 けれどそういう雰囲気のところに全然関係無い人が来て全然関係無い 話をしてったら、困るでしょ。
結局、発端になった結城さんのエントリの「話しかける人」と 「話しかけられる人」の関係をどう取ったか、なんだろうなあ。
(2007/07/07 19:24:27 PDT Redirection)
http://shiro.dreamhost.com/scheme/ 以下のURLを http://practical-scheme.net/ 以下のURLへと転送するようにした (301 Moved Permanently)。
もともとpractical-scheme.netを取ってすぐにやるつもりだったんだけど、 生来の怠惰さを発揮して単にミラーしたまま放っといたのだった。 今までも完全に同一のコンテンツを見てたはずだから変わることはないと 思うけれど、何か問題が出たら教えてくださいな。 あと、ブックマークとかリンクとか、ついでがあれば直しといてください。 もっともshiro.dreamhost.comの方を止める予定はないんで、すぐに リンク切れになっちゃうというようなことにはならないですが。
あと、practical-scheme.netの方にAdSenseなどつけてみた。 収入よりは、どんな広告が出るのかという興味からだけど。 これも2年前くらいに申し込んでたんだが、面倒で今まで放っといたのであった。
今のところ、時々車の広告で埋めつくされたり (まさかcar, cdrのcarが ひっかかったとか?)、Nursingの広告が出たりとよくわからないことが あるが、 "Do you think in closures? We do too. Scheme programmers welcome." なんてズバリの広告が出たりすることもある。 自分でクリックできないのが残念。
(2007/07/04 00:58:39 PDT 油売り算)
斗桶 (a) に油が 1 斗 (10 升) ある。これを等分したい。7 升枡 (b) と 3 升枡 (c) しかない。この 2 つの枡だけで、5 升ずつ等分する方法を記述せよ。
- 7升枡を辺と並行に傾け、3.5升を量り取る。
- 3升枡を辺と並行に傾け、1.5升を量り取る。
- ふたつ合わせて5升。終わり。
…という解も許すなら、かなり問題が楽しくなりそうだ。
- 枡は単独で、その容量の1/2と1/6を中に残すことができる
- 枡は単独で、その容量の1/2、1/3、5/6を他の枡に注ぐことができる、 あるいは、他の枡から受け取ることができる。
(他にあったっけ?)
組み合わせの数が一気に増えそう。
- m.hana(2007/07/04 17:44:00 PDT)学生時代にこの問題を知り、プログラムで解くなんていう考えは浮かびませんでしたが、まる一日かかってやっとひとつ答えを見つけました(いくつ答えがあるかは知りません)。会社に入って、ある同期に問題を出したら、1,2分で解かれました。自分のできなさをあらためて知った次第ですが、この問題、なんとどこかの有名小学校の入試問題だそうです。こんなの解ける幼稚園児がいるのか?もしいたらうちの会社は私よりもその子を雇うべきです。
(2007/07/03 20:29:18 PDT キーレスエントリ)
車のリモコンキーの電波到達距離を伸ばす方法。 口を開けるのは知らなかったが、キーを顎の下に付けるというのはディーラーに 教わったことがある。これは覚えておくべき知識である。なぜなら、 電波塔の直下など、強い電磁波の干渉下では、普通にキーレスエントリでセキュリティロックを解除できなくなる場合があるからだ。
昔乗ってた車が、キーレスエントリとセキュリティロックが連動してるタイプで、 アラモアナのダイエーの駐車場で解除出来なくなって大変困った (あそこはカピオラニ沿いに電波塔が建っている)。 ちなみにセキュリティロックを解除しないままキーで直接ドアを 開けるとアラームが鳴りつづけ、しかもエンジンがかからない。 なんかロックを強制的にoffするスイッチがどっかにあるらしいんだけど 電話越しのディーラーの説明ではわからんかった。 新車で買ったらそういうのも説明してくれるのかもしれないが 中古だったしな。 その時は結局顎であっけなく解決。
ちなみにそんなセキュアな車だったがあっさりと盗まれてしまった。 今はアナログなハンドルロックとブレーキロックを使っている。
(2007/07/02 02:11:33 PDT PCに向かっている時に話しかけられたら)
人から話しかけられたら、キーボードから手を放し、相手のほうを向く。
えええっ。これに賛同する人って、
- 練習中のピアニストに話しかけたら、ピアニストは手を止めてこっちを向いてくれる、とか
- 作曲中のコンポーザーに話しかけたら、コンポーザーはヘッドフォンを取ってこっちを向いてくれる、とか
- リハーサル中の役者に話しかけたら、役者は演技を止めてこっちを向いてくれる、とか
期待してるのかなあ。
コミュニケーションのヒントとして重要なのは、プログラマ以外には 「プログラマに声をかけていい時」と「プログラマに声をかけちゃまずい時」の区別をつけるのが ほとんど不可能(らしい)こと。なので、中断されたく無い時に声をかけられたら 「ちょっと今ダメ」とはっきり意思表示をするのがとても大事。 その時「キーボードから手を放し、相手のほうを向く」必要は必ずしも無いと 思うなあ。
あと、話しかける方は「今いい?」と最初に聞くのがコツ。
(追記2007/07/02 12:42:52 PDT): 萩尾望都の「メッシュ」か何かで、画家と少年が一緒に 暮らしてるんだけど、少年は画家の集中がちょうど途切れた時にうまく声をかける。 そんで画家が「過去に付き合った女性はみんな声をかけるタイミングが悪くて 俺が切れてだめになった」と回想するシーンがあった。
集中を生業とする人にとってかの少年のように空気を読んでくれるパートナーは 理想的。だけど、現実はそううまくはいかない。ちゃんと「集中の切れ目」を 明示しない限り、パートナーは悪いタイミングで声をかけることを続けるか、 遠慮して声をかけなくなるか、になってしまうだろう。
(2007/07/01 21:15:55 PDT History)
コーヒースタンドでアイスコーヒーを注文したら、20歳そこそこのバリスタが 私の着ていたGame Developers ConferenceのTシャツに目を止めて、 「ゲーム作るの?」と聞いてきた。そんで少し話したんだが、彼は スクウェアが昔ホノルルにスタジオを持っていたことを知らなかった。
もう5年になるのだから、まあ無理もない。当時彼がハワイにいたとしても 中学か高校だし、5年の間に州外から移ってきた可能性だって高い。 歴史になったということだねぇ。
(2007/07/01 01:22:18 PDT Shakespeare)
Kumu Kahua Theatre の夏期コースの "Body & Voice for Actors" クラスに週一で通っているのだけど、 これがとても面白い。講師はかつてShakespeare Conservatoryで 学んだ人。課題としてShakespeareのモノローグをやってるんだけど、 各セッションで舞台上の役者から血の通ったキャラクターが「彫り出されてゆく」 のがわかる。Shakespeareってこんなに面白かったのか。
rio orange