«前の日記(2007年01月09日) 最新 次の日記(2007年01月11日)» 編集

Matzにっき


2007年01月10日 [長年日記]

_ セキュリティキャンプ・キャラバン島根

なんと島根県でもセキュリティキャンプが開催される。1月27日。

本家キャンプとは違い、参加対象も限定されていないので セキュリティに関心のある人やWebサービスを公開している人は なるべく*1みんな参加した方がよい。

*1  ところで、私の周辺は「なるべく」の代わりに「なるたけ」とよく言うんだけど、これって方言じゃないよね、きっと

_ [Ruby] Ruby on Rails トレーニングプログラム

今回も初日午前中の講師。RubyとRailsの概要について。 会場がどの駅からも遠い。都会の人は歩くなあ。 私みたいな田舎者はドアツードアで車を使っちゃうから足が鈍ってて。

今回は出席者が多くて(25名)ちょっと緊張した。 Railsもろくに使えない私でいいのか、という気もしないでもないが、 言語設計者自身から講義を受ける機会はなかなかないということで、 土産話にはなるようだ。 優れた言語設計者が優れた講義を行うとは限らないのだが。

まあ、納得してもらえるならいいか。

_ [Ruby] 打ち合わせ

東京支社に移動。Rubyとコミュニティ支援などについて社外の人と打ち合わせ。 もしかしたら、本格的な支援が受けられるかもしれない。 ただ、我々「コミュニティ」側が組織体制が脆弱なので 経済的支援を受けても活用できないかもしれない点を改善する必要がある、かも。

その他にもいろいろと面白そうな話が出た。 今後はスケーラビリティ(いつも強調している生産性のではなく、性能の)も 重要になるかもしれないなあ。今のうちにいろいろ調査・研究しておく必要があるかも。 その辺は私(たち)では絶対的に経験値が足りないので、 いろんな人に聞いたり、教えてもらったりする必要があるだろう。

_ [Ruby] 懇親会

再びトレーニング会場へ。 立食形式で懇親会。

毎回トレーニング初日の夜に懇親会をするのだが、 きまってその後に質問が活発になったりして、 トレーニングが円滑になる。信頼関係は大事だ。

今回は会議室ひとつ借りて立食形式にしたのだが、 非常によかった。今までの居酒屋などでの懇親会も 食べ物はすごく良いのだけれど、席が固定されてしまうと 移動が面倒で話が進まない。立食形式だと いろいろな人と話はできるし、面白い話もたくさん飛び出すし、 今まで懇親会の中でも最良と言ってもよかったと思う。

担当の人に「次回からも立食にしましょう」とお願いしたのだが、 「会場の手配が難しくて、なかなか」とのことであった。 都内で立食形式で安くしあげられるところを調べる必要があるかな。

_ [言語] あるJava使いの場合 - Javaを学ぶ価値

「なぜJavaを学ぶ価値があるのか」という話。

プログラマ、システムエンジニアを職業とするならJavaは学んでおいて損はないでしょう。

「需要があり供給が不足しているから」

というのは理解できる。まったくもって正当な話だ。

しかし、その結果、

自分もそうしてジャバラーになったのです。

最初の現場には、経験2年以上のジャバラーはいませんでした。 それはそれは悲惨な開発になりました。

今考えるとバグだらけ、つくりもいい加減、 訳の分からないところでリフレクション。 もちろんまともにソースレビューできる人はいません。 それでも企業の基幹システムになってしまいました。

ということであれば、不幸なことだ。なにかが間違っていると思う。 おそらく間違っているのは個別のプログラマではなく、 もっと上の方で。

そのような不幸をこの世からなくせるか。 もし可能ならば、どうやって?

_ [Ruby] mapとreduce、あるいはマクロ不存在の理由

最上さんのところから。

最後のページより引用

今注目しているのはマルチコアへの対応です。これからプロセッサがコモディティになってきます。それほど遠くない将来に,机の上のパソコンでも64コアや 128コアのプロセッサが珍しくなくなる。そうすると,プロセッサコアへのタスクの割り当てはスレッドなんかでは不可能になる。自動化するしかなくなります。プログラミング言語で並列性をどこまで活用できるか。CやRubyのような手続き型言語ではなく,関数型言語が生きてくるかもしれません。

単にmapとreduceを加えれば良いのでは?と思ってしまった。

うーん、そうなのかなあ。Rubyのような言語においてmap/reduceが持つ可能性を あまり深く考察していないので、はっきりしたことは言えないんだけど。 それでできるっていうんなら、上記の発言は単なる私の不見識ですね。

もうちょっとmap/reduceについて勉強する必要があるかな。

もうひとつ、

マクロが無い言語ではプログラムしたくないと考える私のような人間からすると、Rubyにマクロを入れることを拒絶し続けることは前から不思議だった。マクロは言語作者の意図を超えてプログラミングのスタイルを変更してしまう可能性がある。これも同じくスタイルを破壊される事への忌避感が原因なのかも知れない。

こっちは当たりかも。マクロというのは要するに言語ジェネレータなわけで、 これを入れてしまうと言語はメタ言語になってしまい、 「その言語で書かれた」というプログラムを読解するヒントが少なくなってしまう。 それを嫌っているのは確かにある。

メタ言語が必要だったり便利だったりするケースは確かにあるけど、 日常的に使うものまでメタ言語だと、私の脳に優しくないので、 日常言語としてデザインされたRubyにはマクロは不要である、ということではないかと。

まあ、発言の背後の意図を憶測されることはまつもとさんにとっては迷惑かも知れないけど。だけど私も言語を作っている身としては、私のmap/reduce当然、マクロ当然という考え方のどこかに欠陥があるのかも知れないと、考えて理由が知りたいのだ。

理由は上の通り。繰り返すとmap/reduceについては不見識。 マクロについては日常的にメタ言語を扱うのは私が疲れるから。

背後の意図の憶測が迷惑なってことはない。どんどん憶測していただきたい。 違ってればそういうし。


«前の日記(2007年01月09日) 最新 次の日記(2007年01月11日)» 編集