ただ、風のために。6 (2004/December)

RETURN / TOP
Generated by nDiary version 0.9.3

2004/12/26 (Sun)

ミステリ系更新されてますリンク

が(この日記もどきともども)ずーっと放置状態だったのですが、気を取り直してメンテナンス中です。 ご迷惑をおかけしてすみません。

こっちとSF系日記更新時刻はずっと巡回できなくて、そうこうしている うちにSF系日記更新時刻はアクセスすらできなくなってしまいました。 うわーん。

Ruby 1.8.2

リリースされました。みなさまおつかれさまでした。

今後の課題としては、リリースノートでしょうか。

  • 少なくとも1ヶ月前くらいからリリース準備を始める。
  • 各ライブラリのリリースノートはライブラリメンテナが書かせる。
  • プレビュー版について、各プラットフォームでの検証を行う担当者を決め、検証期間を事前に打診する

あと、

  • リリースノートにはすべての変更点を記述するべき

とすると、結局今のChangeLog(の1.8.1から1.8.2まで)と同じくらいの ボリュームのリリースノートを作成せざるを得なくなるんですよね。 さすがにそれは多すぎる、ということであれば、

  • もっとこまめにリリースするべき

という結論になりそうです。そのためにももっと楽にリリースできる 体制を作らないと、ということでしょうか。

るびま4号

いまさらですが巻頭言を書いてます。今回はとうとう引用を使ってしまいました。 その甲斐あって?、おぎのさんにも感動していただけたようで何より。


2004/12/29 (Wed)

冬コミ

例によって甲影会で参加してきました。

久々の西館でしたが、 近くのシャッターが全開になっていて、 外からの空気がもろに入ってくる場所ですげー寒かったす……。

雪の中をお越しいただいたみなさま、どうもありがとうございました。

言語の「良さ」と「特化」

まつもとんの12/27の日記のコメントがちょっと盛り上がってきて、 コメントで続けるのは辛そうなのでこっちに移動します。

えーと、まつもとさんと私の分の話を整理すると。 まつもとさんの「「PHPの良さ」はどこにあるのだろうか」という疑問に対し、 業務でPHPを選択することがある私から、その選択について書いてみたのでした。 それがあのコメントです。 「選択している」ということは何かしらの「良さ」につながっているはずですよね。 それが相対的なものであれ、あるいは「悪くはない」程度であれ。

でもって、それに対してまつもとさんから、「PHPが人気を獲得した過程」を 考えたい、という コメントが。そこで、それについては 「特化」のせいではないか、と返してみたわけです。

結局のところ、ある言語が普及する(≒人気を獲得する)、ということと、 その言語の出来の相関はそんなに高くないんじゃないでしょうか。 なので、まつもとさんが何かに特化させてでも普及を目指すならともかく、 そういうつもりがないのであれば、人気獲得の理由の考察は、 言語そのものの設計には役に立たないのであんまりしても効果ないんじゃないかなと 思うのでした(だからそこを質問してみたのでした)。

もっとも、「特化」を原因だと考えているのは、単なる仮説というか、 私の印象にすぎません。 ただ、「人気獲得には特化が有効」という命題から導けるのは、 「大衆は自分の欲望に忠実」ということだと思います。 みんな、やりたいことが手軽にできそうなものを使う、と。 また、「便利」よりも「確実」を重視するのかもしれません。 他の方のコメントにあったような、「安心感」ですね。 そういうことだと思います。

言語の志向性

ついでに書くと。これは言語が普及する要因とかとは関係なさそうですが、 PHPとRubyの志向性の違いというのはあると思います。

まつもとさんは「るびま」のインタビューで、 言語設計者として最も気を配っていることとして、 「腐った仕様を入れないこと。」と 答えていました。 この発言、まさにまつもとさんらしいというか、Rubyらしいように思えます。 私もやっぱり、まつもとさんが目を光らせている限り、Rubyには絶対に腐った 仕様が入らないはずと確信しています。これはRubyという言語の大きな 魅力であるんじゃないかなあと(いやまあ多重代入とか、仕様として 私の理解を超えるものもありますが、それは少なくとも妥協の産物みたいな 意味での「腐った」仕様ではないですよね)。

ところが。PHPは、たぶん腐った仕様でも突っ込むんですよ。 それがWebアプリケーション開発に「便利」であれば。 もちろんそんな発言をPHP開発者の方から聞いたわけではないのですが、 そんな気がすごーくするのです。

腐った仕様を突っ込むことは、短期的には便利でも、長期的には 不便になることがあります。例えばPHPでは単純な配列やハッシュが なく、それらを順序つきのマップでこなしたりするとか、 またそのArrayの関数名には 「array_」がついたりつかなかったりするところとか、 どうにも美しくない仕様ががんがん入っています。 おかげで、実際に使っていて、これはどうしてくれようと思うときもあります。

だがしかし、その一方で、PHPのこのスタンスは、 Webアプリケーションに必要なものなら 手段を選ばず必ず提供しようとするんじゃないか、という 安心感にもつながっているような気がします。 どう見ても無様な修正であっても、必要とあらばほいほい入れる。 そういう安心感です。……って、ほめてるんだか けなしてるんだかよく分からないですが。ともかく、RubyとPHPの違いは そんな風に感じているのでした。


2004/12/30 (Thu)

Maple

PHPのプレゼンテーション層用フレームワーク、Mapleについてのメモ。

作者のkunitさんにはPHP関西セミナーでお会いした時にざっとお話し したのですが、あとでまとめてお伝えすることにしていて ずーっと先延ばしになっていたものです(_o_) というか、結局 まとめきれなくてメモになってしまってすみません……。

  • Convert_Dateで、値が違っている時にはwarningを出すべき?
  • Convert_*trimで、配列の時に先頭を取り出すのは一見便利だけど呼び出し元がバグっている可能性もあるので、せめてwarningは出した方がいいのでは。
  • Validator_Matchの「,」対策はちょっと……iniを使っている限界?
  • Validator_Dateはcheckdate()を使ってるけど、これは数値じゃないとwarningかnoticeが出るはずなので数値チェックしてほしい。
  • ていうか、$paramsがなんかへん? テスト書いてない?
  • Validator_Requiredで配列は再帰しなくてよい?
  • ページ間での設定の共有方法は?(エラーチェックは)
  • page controllerは使えない?
  • 設定ファイルを使うのとスクリプトで(別ファイルに切り分けて)書くのとの違いは?
  • デプロイについて(開発→テスト→本番)サンプルみたいなのがあれば。
  • アクセス制限の方法(一部にかけるとか)
  • クラスのファイル名が「〜.class.php」になるのはかっちょ悪いのでは。PEAR非互換だし。
  • SSL/非SSLでのセッション対応(クッキーを二つ使うやつ)があれば便利。
EAA for LL

昨日の続きのような、続きじゃないような。

こう言うとまつもとさんは納得しなさそうですが、 PHPにしろRubyにしろ、2万フィート上空から俯瞰すれば同じスクリプト言語、 あるいはLightweight Language(LL)で、 そんなに変わらないんじゃないかと思うわけですよ (やっぱり納得しなさそう……)。私としては、「Ruby VS PHP」とかいう 構図よりも、「RubyとかPerlとかPHPとかPythonとかのLL VS 非LL」の 方が興味があります。

もっというと、今一番興味があるのが、まさに 「Webアプリケーション(とか)の開発言語としてのLL」です。 もしくは、「LLによるEnterprise Application Architecture(EAA)とは いかなるものであり、またそれは非LL(特にJavaとC#)と比べてどのような 相違、そしてメリット・デメリットがあるのか」、でしょうか。

私の一押し言語はもちろんRubyなのですが、PHPもわりと好きです。 ですが、私の好きなのはあくまでばりばりオブジェクト指向なプログラミングをしているPHPです。 HTMLとPHPも合わせて全てを一個のファイルの中に突っ込んだようなプログラムとか、 ある程度行数があるにもかかわらず関数宣言が一個もないようなプログラムは 大嫌いです。ていうか敵だね。そういうのじゃ駄目でしょ。

と書くと、じゃあPHP4よりもオブジェクト指向を強化したと言われるPHP5の方が ずっとよいと考えているように思われるかもしれませんが、実はあんまりそう思っていません。 あれは変にJavaを意識しすぎているんじゃないでしょうか。 そのため、Javaに機能を導入しようとするあまり、 PHPのLLとしての良さを削ろうとしているように見えてしまって、 ちょっと警戒しています。むしろ、オブジェクト指向と直接関係がない、 例外の強化やリフレクションの強化の方を歓迎しています。

さて、PHPがJavaっぽい路線に行っちゃうのも、 その大元の原因は、LLのためのEAAの方法論がないからだと思うのです。 だから、 EAAについての研究や考察が先行しているJavaとかC#とかに安易に引きずられてしまうのです。 本来ならば、そこはJavaを真似するのではなく、 LLならではの、よりよいやり方を考えるべきなのに。 まあ、PHPでOOPをやること自体についても否定的な人が少なくない現状では、 いきなりEAAとかいっても、普通に このようになってしまっているのは仕方ないにせよ、 いつまでもそんな現状に甘んじていてはいけません。 それはLLの発展のためになりません。

であれば、いっそのことRubyとかPHPとかの区別をすることなく、同じLLとして、 EAA構築のためにどのような手法を取り入れるべきか、ということを考えて いってもいいんじゃないかと思っています。

……そんなわけで、PoEAAの読書会がやりたかったり、DDD難民だったりするのでした。

帰省

というわけで、これから羽田発6:30というすごい時間の飛行機に乗って帰省します。





written by TAKAHASHI 'Maki' Masayoshi (maki@rubycolor.org)
RETURN / TOP