過去の日記

2006-01-26 オープンソースとエンタープライズアプリにおける選択責任と [長年日記]

htmlコメント [tech]

はてなダイアリーのソースを見ると、

<!-- google_ad_section_start -->

  <div class="section">
  :
  :
  </div>

<!-- google_ad_section_end -->

ってあるんですが、このhtmlコメントは一体何なのでしょう?
教えてはてなダイアリー!
……って、google adsenseの対象にするソースの部分の指定なのか?
googleのヘルプを読んでもでてこなかったのだけど、単なる見落としでしょうか。


追記
見落とし、というかちょっとした勘違いでした。簡単に情報が出てきました。

What is section targeting and how do I implement it? - AdSense Help

ゲロッパ! [movie]

結構楽しめた。
が!
なんで日本のコメディ映画って、最後に"泣き"が入って、かつハッピーエンドになってしまうのか。
いや、それはそれでもいいんだ。西田敏行オンステージのシーンで盛り上がって、"泣き"のシーンに入って、そこまではよい。
でもそこから後のテンポがもっさりしているのが残念。その部分がもうちょっとテンポよく進むか、その当たりのカットを一部分でも前の方に持っていくかしていればよかったのになぁ。
しっかり面白かっただけに、残念! という感じ。

ゲロッパ ! GET UP スペシャル・エディション [DVD]

  • 監督: 井筒和幸
  • 出演: 西田敏行,常盤貴子,山本太郎,岸部一徳,桐谷健太
  • 出版社/メーカー: ハピネット・ピクチャーズ
  • ASIN: B0000C7P8A
  • 発売: 2004-04-09
  • amazon.co.jp詳細へ

オープンソースとエンタープライズアプリにおける選択責任と [tech]

2つが変に組み合わさるとひどい事態を引き起こす。
「オープンソースの恩恵は受けて」いて、かつ「ライブラリの改造は避けたい」なんていうケース。

Javaをメインとする会社は、きっちりしていたいと思う指向が強く、それこそPerlのライブラリのようなのを適当で、うさんくさいものとして見ている。後のバージョン管理も含めて、できればライブラリの改造は避けたいと思う。(フリーのライブラリを使いたくないのは、「いい加減ワールド」に入りたくないという。これはエンタープライズアプリにおける選択責任の重さにも繋がるので、一概に否定はできない。)

実はJakartaがあるので、結局、誰もかれもオープンソースの恩恵は受けているんだけど、永遠のベータ版みたいなモジュールで許されることが嫌とか、そういう発想はあるみたいだ。

F's Garage:Java圏とPHP,Perl圏の断絶について。


まず、これは相当に古い話であり、現在出荷されているものとは全然別モノ,別の話である、ということを書いておく。あと、憶測が混じっていてそのウラを取っていない(というかソースが手に入らない以上ウラの取りようがない)、ということも書いておく。
富士通にINTERSTAGEというアプリケーションサーバがある。
こいつの上でservletを動かしたり、servletでチョンボをやってしまってExceptionを発生させたりすると、ログファイルを見るわけだ。
今はどうだか判らないが、こんなJavaパッケージ名をそこに見ることになる。

com.fujitsu.interstage.jservlet.tomcat

へー……。


それ以前に、Tomcatを使ってservletを実行していて、ある機能がどうしても有効に動いてくれない、という目にあっていた。ソースは間違っていないはず、というプログラマにありがちな無根拠な自信のもと、Tomcatの情報を検索していた。
あった。
確かに該当するバグがあった。正式に修正されたリリースは無いが、MLのアーカイブ(だったと思う。ちょっと記憶が曖昧だ)にパッチソースが書いてあった。
その時点では社内のサーバで動けばいい、という状況だったのでTomcatのソースを持ってきて、パッチをあて、ビルドした。期待通り動いた。


それからしばらくして、INTERSTAGEを使っていて同様の現象に出会った。com.fujitsu.interstage.jservlet.tomcat というパッケージ名を見ていたので、これはおそらくTomcat由来のバグが修正されないで残っているのだろう、と思った。ここが憶測の部分。実際はどうなのか、それは判らない。なぜなら、ソースが手の届かない所にあるからだ。
ともあれ、正式なパッチも無いらしいので、サポートセンター経由で問い合わせてもらうことにする。パッチソースを入手したWebページのURLといった情報も付け加えておいた。
当然、時間をおかずにパッチが準備されるだろう、と高をくくっていた。
回答は……、

その機能は機能制限により使えません。マニュアルにもその様に記しています。

は?
確かに書いてあった。
でも……どういうこと?
その何ヶ月も前にTomcatを使っていた時には、数時間でバグ情報に辿り着いてパッチソースを手に入れて、動かせたのに?
パッケージ名にtomcatと付いてはいるがTomcat由来では無いというのか? いやいや、そんな馬鹿な。パッケージ名にtomcatと付ける意味が無い。


ま、とりあえずその機能は使わずにやり過ごしたわけだが。


もっとも、サポートセンターの対応も判らないではない。
「富士通」の「INTERSTAGE」の、正式なパッチとして公開するにはおそらくは、様々な文書を書き、テスト仕様書を書き、テストをし、また様々な人のハンコをもらって、と言うような手続きが必要なんだろう。そのバグがそこまでしてパッチを出すほどのものでは無い、という判断だったのだろう、きっと。事実、それは使わないでやり過ごしたわけだし。

でも、ソースを入手できないプロプライエタリなミドルウェアの歯がゆさ、そのために解法が判っているのにどうにもならない腹立たしさ、そんなことを感じた一件だった。
もっとも、後になってから考え直してみると、「判りました。じゃすぐにパッチ出しますから」と言われて30分ぐらいでパッチが届いたりしていたら、それはそれで「エンタープライズサーバのサポートセンターの対応としてそれはまずいんじゃないか?」と思うようになったわけだけど。