まずはこの「ある物理学生の回答」をご覧ください。
普通に回答すると、気圧の違いで云々とかなるんでしょうか。
問題文より、求められている回答を示すことも一つの手段で、有効な手段。
でも、その観点だけにとらわれると本質を見逃すことも多い。
建物の高さを測るなら、ロープをたらすのが一番手っ取り早いですねぇ。
2005年6月アーカイブ
AccessLoggerのSpring管理化のつづき。
とりあえず、Commons-DBCP のコネクションプールを Springからもらえるように修正。
これで、Filterの呼び出し、logger Beanの取得、DBコネクションの取得をすべてSpringの管理下におくことができました。
ついでに、XDoclet を使って、Spring設定ファイルを自動生成できるように。
Ant起動で、DataSourceの設定以外がそろってしまうので、だいぶ楽チンになりました。
XDocletのマージ機能を使うことで、あらかじめ別ファイルに書いておいたDataSource設定も自動取り込みできるようになれば、今後の開発がかなり楽になります。
そろそろほんとに WikiParser に戻りますかね。。。
SpringFrameworkの練習がてら、こないだから作っている AccessLogFilter を Spring管理に作り直し中。
はじめはFilterに入った時点でBeanFactoryを作ってDI管理にしようかと思っていたんだけど、SpringFrameworkのAPIを探っていたらFilter自体を管理できそうなことを発見。
せっかくなのでやってみることに。
とりあえずログ取りBeanをインターフェイス抽出、Filterにsetterをつけて、生成はSpringにお任せ。
はて・・・？
どうやって Beanを抽入すんだべ？
org.springframework.web.filter.DelegatingFilterProxy というものを発見。
名前からして、Struts-Springの時に使う DelegatingActionProxy と同じような使い方だろうと推測。
設置場所は、web.xml だろうとあたりをつけて、早速設定してみた。
・・・・なにやらエラー。
java.lang.IllegalStateException: No WebApplicationContext found: no ContextLoaderListener registered?
うーん、何でだろうとエラーメッセージを頼りにいろいろググってみたところ、 Filterを SpringFramework で管理するのに ServletContextListener に ContextLoaderListener を登録しておく必要があることが判明。
Webアプリ用の ApplicationContextである、WebApplicationContext を呼び出すのに、内部的に WebApplicationContextUtils を使っているようで、これを使うのにはこの Listener を登録する必要があるみたいです。
というわけで、web.xmlに
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
をつけることで見事に動きました。
ついでだったので requestオブジェクトの文字コード設定フィルタも、Spring付属のものに変更。
これから AccessLogger の内部構造を Spring管理にしますかね～。
別件終わりました。
何をしていたかというと、アクセスログをDBに蓄えられるような Filter を作っていたのでした。
Servletでできる限り多くの情報を取得できるようになっているはず？
最近のAPI使うともっとコアな情報を集められるようになっているのかなぁ・・・？
バージョン１ということで作ったんだけど、不満たらたら。。。
集められるログの内容はAPIでの制限があるけど、ロジックやらアーキテクチャーは、もっともっと柔軟にしていけそう。
特に、目下調査中の SpringFremework を使えば、コネクションプーリングなどがお手軽にできそうなので、負荷も軽くなりそう。
＃今はJDBC経由で都度都度接続してます。
ま、今後少しずつ改善していくということで、現時点では良しとしましょう。
どうせそんなにたくさんのアクセスがあるわけではないし～～♪
そんな感じですが、WikiParserにも戻らないとね。
しばらくのご無沙汰でしたが、こちらは SpringFramework を調べておりました。
こないだ買った「実践Spring FrameworkJ2EE開発を変えるDIコンテナのすべて」が大変参考になって、とりあえず「HelloSpring」プログラムを作ってみました。
この本にはXDocletを使った設定ファイルの書き方～Antによる出力まで載ってるから、重宝しますな。
それにしても、Springはすごく使えるツールな気がしてきました。
いろんなクラスをインターフェイスやPOJOで書いて、各種依存関係はSpringにおまかせ。
電車で読んだ感じでは、HibernateやStrutsとの連携も楽チンにできそう。（懇切丁寧に解説してあるし！）
デザインパターンとかも、インターフェイスで作ってしまって、実装クラスは後で抽入！
うちã��WikiParserも設定ファイルという名目のSpring設定ファイルにしてしまおうかしら・・・。
あ、WikiParserに関連して(?)別案件を構築中なので、もうしばらくWikiParser自体は保留になるかもです。
ご容赦を。
ではまた～～
ユミルリンク株式会社(サイバーエージェント・グループ)の求人／リクナビＮＥＸＴ[転職サイト]
もはやネットアイドル。。。ぷ
なんか３人で対談してる風になってるけど、この３人で対談したことはないぞ～。
しゃべってることは以前何度か受けたインタビューで話した覚えあるけど。（ネタばらし。ｗ）
ま、内容が間違ってはいないので、良しとるするか！
こないだ決めた呼び出し側の仕様を変更。
WikiParser parser = WikiParser.getParser();
WikiNode node = parser.parse("あいうえお");
out.print(node.toString());
なんとなく、外部インターフェイス的にはこちらの方が自然な気がして。（プロジェクト名も WikiParser だし。。。）
またすぐ元に戻すかもしれないけど。
今回の目標であった「"\n\nあいうえお\nかきくけこ\n\n" を渡して "<p>あいうえお<br>かきくけこ</p>" を取得」はさらっと実装完了。
ここまではさらっと実装でいいんだけど、これから先の構文解析をどのように実装するかが問題。
以前のプロトタイプでは、正規表現でガシガシ分割、処理用のnodeを生成、委譲、と言う方針だったので、ソースはかな～りぐちゃぐちゃ。
拡張性も柔軟性もくそもない感じだったんだけど、今回はそうならないように良く考えなくては。
例によってデザパタ本をパラパラとめくってみて、今後使いそうなパターンをピックアップ。
- 構文解析に Chain of Responsibilityパターン
- 解析結果の出力に Visitorパターン
まだよく読んでみないと分からないけど、構文解析の時には
- 次の部分を処理するのはどなた？
- PreserveNode : 私じゃないよ
- BlockquoteNode : 僕じゃないよ
- ParagraphNode : じゃー、私が処理します。
みたいな流れで処理させればスッキリ書けそう。
出力は今は Object#toString() をオーバーライドして使ってるけど、Visitorを各自実装してもらうことで様々なフォーマットで出力ができるようになる気がするです。
この辺をAPIとしてしっかり仕様決めしてあげれば出力が柔軟になるかな？
＃とうぶんは toString() でしょうけど。。。(^_^;;
この２つを組み合わせることの問題は、Visitorが訪問する相手（構文解析を誰が行ったか？）を覚えておかなければならない、もしくは適切に訪問できるよう導いてあげないといけないこと、かな。
この部分を考えるとあんまりうまくいきそうな気がしない。。。
とりあえず次回、ちょろっとやってみますかね～。
でわまた～～。
今話題の DIコンテナ「Spring Framework」とやらを調査中。
良さげな本を２冊見つけました。
どっちが良いかわかんないので、とりあず１冊目をゲット。
また今度２冊目を買うかもですな。。。
 | 実践Spring FrameworkJ2EE開発を変えるDIコンテナのすべて 著者：河村嘉之 出版社：日経BP社／日経BP出版センター 本体価格：3,800円 |
楽天ブックスで購入する | |
 | Spring入門Java・J2EE・オープンソース 著者：長谷川裕一 出版社：技術評論社 本体価格：2,980円 |
| 楽天ブックスで購入する | |
これをつけるのが今日からということで。
かれこれ２～３ヶ月前にプロトタイプを構築して今日に至る（その間放置）わけですが、あの経験を生かして、再度構築していこうと思います。
まずは、最も基本的な呼び出しをどのようにするか？をここ数日間考えていたわけですが、やっぱし不正なクラス呼び出しなどをさせないよう、AbstractFactoryパターンで詳細情報を隠蔽化するのがいいかなと思うので、その部分を作ってみました。
結城浩さんのデザパタ本を片手に、奮闘して、これまであまりようとの分からなかったこのパターンに「なるほど！」と相槌を打ちながら進みました。
とりあえず "あいうえお" の文字列を渡したら "<p>あいうえお</p>" を取得できるように。
こんな感じ。
WikiNodeFactory factory = WikiNodeFactory.getFactory();
WikiNode node = factory.getWikiNode();
node.parse("あいうえお");
out.print(node.toString());
結果：
<p>あいうえお</p>
次の目標は "\n\nあいうえお\nかきくけこ\n\n" を渡して "<p>あいうえお<br>かきくけこ</p>" を取得することでしょうか。
というわけでまた～～。
今日から、WikiParser(仮) の構築日記をつけてみようかなと思います。
WikiParser(仮) とは？
世の中にたくさん存在する Wikiクローンですが、HTMLより遥かに単純な構造をした文書を作成するだけで、とてもキレイなHTMLとして出力ができて便利なことは言うまでもありません。
そのエントリーを解析してHTMLとして出力するエンジン部分のみを構築、配布することで、いろいろなところで「お手軽作成、きちんと体裁」が実現できればなと思っています。
これができたときには、この MovableType のエントリーをWiki形式で書いて WikiParser(仮) でHTML化することで、エントリーを書く気を萎えさせないようにしたいです。
Javaで構築しようと思っているので、もう一工夫必要ですが。
この WikiParser(仮) の目標。
・設定ファイルを利用することで、整形ルールを柔軟にしたい。
・APIを提供することで、プラグインを追加できるようにしたい。
・出力をHTML以外にも対応したい。
それでは、公開までこぎつけるか、僕が飽きるまでの間、お付き合いくださいませ。
Javaでデザインパターンをやるなら、この本が最適でしょう。
いままでうっかり紹介するのを忘れていました。
 | Java言語で学ぶデザインパターン入門増補改訂版 著者：結城浩 出版社：ソフトバンクパブリッシング 本体価格：3,800円 |
| 楽天ブックスで購入する | |
RDBMSの仕組みを勉強しておいたら何か得するかな？
 | ＲＤＢＭＳ解剖学よくわかるリレーショナルデータベースの仕組み 著者：鈴木幸市 / 藤塚勤也 出版社：翔泳社 本体価格：1,980円 |
| 楽天ブックスで購入する | |
