<前の日記(2006-10-03) 次の日記(2006-11-05)> 最新

おおいわのこめんと (2006-10-04)


2006-10-04

[Comp] 職場 Web サイト改装

お気づきの方もいるかと思うが、職場の Web サイト を移転・改装した。 これまでのサイト は研究所全体の共用サーバで、 安全性は高いものの固定のファイルを置くことしかできずいろいろと不自由があった *1 ので、 共同研究先からリンクが張られたのを期に 移転したのであった。……というところまでが前置きの状況説明。

ま、この手のネタが僕に廻ってくるのはいつものことなのだが(笑)、 特にこの手のサイトで左側のメニューとかの更新の全ページへの反映とか、 英語版・日本語版をきちんと対応づけてメンテするのとかは大変骨が折れるので、 更新を裏で管理できる何らかの CMS みたいなものを入れたいなー、ということで、 「夏休み」と称して強制的に取らされる3日の休暇の間に自宅の環境でちょっと試してみた。 もともと夏休みは「仕事のプログラミング」はしないことに決めていたので、 もう開き直って堂々と趣味に走りまくりである。

丁度同じ時期に Ruby の公式サイトRadiant CMS という Rails ベースのシステムを 導入したとのことで、試してみよう……として、Debian sarge に Rails を入れるところで いきなりどはまりまくる。Debian において /usr/bin や /usr/lib が deb 管轄外で 汚れるのは却下なわけで、ちゃんと /usr/local の下に入ってくれよー、と Rake の ソースとか読みまくる羽目になるのだが、イマイチうまく行かないねぇ。

結局、パッケージ化された Rails を見つけてきて入れて、いざ試してみる……。 Rails わからん(笑)。とりあえず Radiant CMS は動くようになったのだが、 なんか Rails 面白そうなので早速本を買ってきた……が、忙しいので現状は積読状態 (;_;/。

で、Radiant CMS なんだが、まだまだ未完成という感じで、特定のページを公開・非公開にする 設定はできても、Draft 版を見る機能とか公開済のページの更新を裏で保存して review する機構とか、 必要な機能が全然実装されていない感じ。ドキュメントも殆んどないし、 まだちょっと自分のサイト以外では導入できない感じ。もちろんまだ version 0 台だから これくらいは当然だし、期待は高いけどね。

で、いじっているうちに、「なんだ、これなら Wiki でいいや」という感じになってきたので、 結局 Hiki になりますた。といっても、 もちろんそのままでは使えないので、表示周りから URL 生成からテンプレートから 複数スタイルのサイト内共存の扱いから日本語・英語の切り替えから とにかくいじりまくってあって、一番下のバージョン表示 (これも実は後から手で明示的に加えるようにした)を除けば多分ぱっと見 Hiki には見えないと思う。 ちなみに数ある Wiki の中でも Hiki になったのは、fast-cgi + suexec での動作が実績あったのと、 Wiki には珍しい「ページID(URL)」と「ページタイトル」を別に管理する仕様が CMS には却って向いていた、と言う理由。

では更新管理はどうなったかというと、実は別のサーバにまったく同じ内容の Hiki が 立ち上がっていて、その裏サーバから表サーバにページ単位で更新を自動的に同期できるような プラグインを自前で実装してあったりする。一旦 Hiki の内部のデータ管理の構造が判って しまえば僕的にはもうやりたい放題で、Unison で使われているような更新検知ロジックを組み込んで、ちゃんと2つのサイトのどちらが更新されてるかを 調べて正しい方向に更新するよう指示してくれるようなものにしてある*2

とにかくこれで「メンバーが誰でもコンテンツの草稿を書けて*3」 「必要に応じて peer review して」「Webmaster が整合性を持って更新できる」環境は できあがったので、あとは内容を増やすだけですね……ってこれが一番大変だったりする (^^;。 まぁがんばりまつ。システムの方も画像とかの扱いはまだまだ不自由なので更新していきたい感じ。

……ちなみに同期システムの方は Hiki ならほぼ汎用に使えるようにしてある *4 のだが、Wiki 2つ使ってコンテンツ管理するなんて粋狂なことを考える人は他にいるのだろうか。 *5

[Comp] Ruby is like Lisp (Scheme)

で、今回初めて1000行クラスの Ruby プログラムを書いたわけだが、書けば書くほど 少なくとも僕の実装スタイルでは Ruby は(いい意味でも悪い意味でも)Lisp*6 だなぁと思えてくる。 誰かが既に指摘していたことなのだが、改めて実感。

具体的にそう感じるのは、

  • 特に集合的なデータに関して、Array と Hash という少ないプリミティ ブ型を組み合わせて複雑なデータ表現を組み上げられるスタイル。Perl みたいに reference とかややこしい事考えなくてもいいし。
  • その時に each Iterator を頻繁に使うので map/iter 高階関数を使った 関数型プログラミングに近い感覚でプログラムを書くことになる。
  • Symbol があるので単純な有限集合型は極めて簡潔に表現できるのだが、 case 文では全通り尽くしているか、あるいはどこかでシンボル名を間違えていないか 神経を使いながらプログラムを書く羽目になる。
  • Proc.new の魔法に一旦染されてしまうと、クロージャ使いまくりの 楽しい(笑)感覚のプログラミングができる。

といった辺りで、プログラムを書くときに緊張している脳の部位が Scheme で 組んでいる時に割と近い気がする、ということだと思う。

ま、実際今回は OOP 的なものはほとんど出てきていないので、 その辺りのシナプスはまったく動いていなくて、評価としては不完全なのは承知なんだけど、 ここ数年の C、OCaml でのプログラミングとは違う脳細胞が反応した、 ってのは事実 :-)。ちょっと楽しかった :-)。

でもわけの判らないローカル変数とクラス定義・参照のスコープ規則は正直なんとかして欲しいぞ。

*1 共用する以上やむを得ない制限ばかりなので、理由は納得できるのだが。

*2 ……とか凝ってるうちに もう784行になってるんですけど……。その他のうちのサイト専用の細かい拡張プラグインが 別に321行あるんで、結局1000行以上書いてるのか……。

*3 Wiki は周辺では結構みんな慣らされているのでその点も有利。

*4 といっても汎用プラグインとして公開するにはサイト依存した部分を直さないといけないし、 セキュリティ周りとかいろいろとドキュメント書かないと使い物にならないのだが。

*5 興味ある人がいるようであれば公開のためのリリースワークを検討します。

*6 但し、Scheme みたいな static scope のやつ。

本日のTrackBacks(全1件) [TrackBack URL: http://www.oiwa.jp/~yutaka/tdiary/trackback.rb/20061004 (note: TrackBacks are moderated: spams will not be shown.) ]

いろいろ試したのですが unstableからパッケージ借りてきて入れる というのが一番Debian的に安定した運用になります。 Ruby on Rails(RoR)の問題点は、 ・MinorVersionによって、ActiveRecordsなどのCoreComponentの挙動が違うので出来るだけ最新を追従したい ・Pluginな..


大岩 寛 (おおいわ ゆたか) <yutaka@oiwa.jp.nospam ... remove .nospam> .

Copyright © 2005-2014 Yutaka OIWA. All rights reserved.
Posted comments and trackbacks are copyrighted by their respective posters.

記事の内容について (Disclaimer / Terms and Conditions)