2007/07/29
求職中マーク
キャリアエクスプローラーマーク。 応用物理学会の大会で、 求職中の学生はスライドやポスターにこのマークをつけてアピールできる、って話。
アイディアは別に悪くないと思うけれど、計算機系のいくつかのカンファレンスでは 特にアピールしなくても良さげな発表をした学生に企業がアプローチするとか、 学生側も企業の人と話してる時に "by the way, are you hiring?" とか言って レジュメをさっと出すとかってわりと普通のような気がする (いや、特に学生とは限らないな。会社名を出して発表しても後で「ところで うちに来る気無い?」と声をかけられることもあるし、転職のきっかけを 探すつもりでレジュメを持ってきてる社会人も少なくない。私自身も カンファレンスの場で誘われたことも誘ったこともある。)
これはやっぱり産業規模がでかくて就職口が多く、人間の流動も多い業界だからか、 それとも産業寄りのカンファレンスだからかなあ(SIGGRAPHとかGDCとか… SIGCHIで声をかけたこともあるか。) 計算機系でもPLDIとかPOPLとかICFPとかは雰囲気違うんだろうか。
Tag: Career
2007/07/29
どう書く.org, Haskell
どう書く.orgは、問題の大きさが ちょろっと書いてみるのにちょうどいいくらい (SchemeやHaskellで 「エディタ1画面に収まるくらい」の長さ) なこともあって、ついつい考えてしまう。 締切前なのに。
せっかくなのでHaskellの練習をしてみてるんだけど、このくらいの小さな 問題だと確かに型って全然考えないなあ。全部型推論任せ。便利だわ。 Schemeにも型推論欲しい。
遅延評価については、まだ頭の中で動作を展開している感じだなあ。 Haskellの関数やオペレータを「遅延評価つき高レベルライブラリ」みたいに 認識している感じで、組み合わせた時の動作は操作的に理解している。 ただ、それだとモナドを組み合わせてくようなところで途中でわからなくなるんで、 宣言的頭をもすこし強化せねば。
そんで、Haskellをぽちぽち書いてみての印象:
- 優先順位覚えるのが面倒。型エラーのほとんどは今のところ優先順位を 間違えてて思ってたのと違う結合になっちゃってるせいだ。慣れればいいんだろうけど 慣れちゃうのも癪なんだよなあ。
- ごちゃごちゃいじってる最中に、ソースが型的にinconsistentになるってことが 良くある。例えば下請け関数x,y,zを書いてghciで動作を確かめて、それを組み合わせた wを書いている途中でふと気づいてxの定義を直した、みたいな場合。 またさくっとソースをロードしてxの動作をインタラクティブに確かめたいんだけど、 xの型が変わってるのでwのコンパイル時にエラーになる。 Lisp/Schemeだとそこは全く気にしないでいいわけだが、Haskellerはどうするんだろう。 いまのところこういうケースではwの定義をいちいちコメントアウトして ロードしてる。
Tags: Programming, Haskell
2007/07/25
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してるかとかはわからない。 最初のうちは好奇心でクリックする人も多いだろうから、 しばらく続けてみないとなんとも言えないだろう。
Tag: YCombinator
2007/07/20
コードを書く人
アーキテクチャを決めて下の人に実装を任せたりだとか他人に仕事を振ったりだとかたくさんのサブコンを使って一定の品質のアウトプットを出すべく管理したりだとか複数の会社の係る仕事でお互いの進捗を管理しつつ予想外の事やらトラブルやらを調整したりだとか会社の方針を決めるような上の会議に参加して問題を根本から解決したりだとか業界の趨勢を決めるようなサービスの立案やら実現やらに力を注いだりだとか。
そういった仕事に関わっている天才プログラマよりも、現場の最前線で延々とコードを書いているコーダーの方が最後にはプログラマとしての「物を作る能力」は高くなる、という信念のような物を、私は持っています。 最後にはコードを書いている人が勝つ、と。
Googleでは偉い人ほど多くのコードを書いている、って中の人に聞いたことがある (さすがにSergeyとBrinレベルになっちゃうとそんな暇は無いそうだが)。
下にメモしたFlektorのJason RubinとAndy Gavinだとか、ZenterのWayne Crosbyだとか、 まあその流れならViawebを作った当時のPaulとRobertとTrevorにしたって、 やっぱり「天才プログラマ」という称号は誰よりもコードをたくさん書いて ゼロから何十Mっていう価値を生み出しちゃう人々にこそふさわしいのじゃないかなあ。 (IPAに認定されたぐらいじゃだめだよね。)
世の中というのは色々な人がいてこそ動いているので、コードを書かないでも 人をがんがん動かしてどんどんプロジェクトを回して行く人がいていい。 でも、技術ベンチャーをやるなら、コアメンバーはやっぱり誰よりも良いコードを たくさん書く人であって欲しいかなあ。少なくともプロトタイプ作成くらいまでは。
ところで、アウトプットの管理とか現場の調整とか方針の決定とか、 そういうのってプロデューサーの仕事だよね。コンテンツ製作現場では、 プロデューサから制作管理へのラインと、ディレクターから製作部隊への ラインとの役割分担がわりと明確で、うまく機能してると思うんだけど、 ソフト製作でもそういう分担があった方がいいんじゃないかなと思うことはある。
Tag: Programming
Comments (4)