BlogJavaを中心にした技術ネタなど。VISTA)ついにPCを買い換えました。あれこれ迷ったのですが、結局以前と同じThinkPad。ビジネスユース向けのR61です。ThinkPadが安心するんですよね。Ultimateなんですが。遅い!VISTAが悪いのか、ThinkPad固有ユーティリティが重いのか、ノートン先生が邪魔してるのか原因はさだかではないですが、とにかく遅いです。操作の反応も悪いし、シャットダウンにやたら時間がかかるし。次に、プログラムや機能を実行しようとするたびに、いちいち実行して良いか確認してくるのがかなりうっとおしい。アプリケーションのVISTA未対応。BlasterがVISTA未対応(?)なのか、一部機能が動きません。MDで録音したバンドの練習曲をPCに取込んで、iTunesやiPodで聞いていたのですが、それができない。うーん、これはかなり困るな。ついでに、目玉(?)のウィンドウが3D表示される機能はいらないです。言うディレクトリに変わったくらいかなぁ。JavaとかUnixを意識したプログラムでは、パスにスペースが入ってるのは何かと面倒ですからね。何とかしてほしかった。XPってのももったいないので、VISTAで良かったんですけど。細かいことで何箇所かつまずきました。ルートパッケージ名を、実際のパッケージ名にあわせて修正していませんでした。その為、PageやActionがDIコンテナに自動登録されていませんでした。当初、「そういえば、diconにコンポーネント登録してないなぁ」と思ったのですが、サンプルを見てもPageやActionをコンポーネント登録している気配がない。Creatorが働いていて、パッケージ構成とクラスの命名規則を守っていれば、自動的にコンポーネント登録されるのでした。2.アクションメソッドが呼び出されないSUBMITボタンを作って、Pageクラスのアクションメソッドを呼び出すようにしたのですが、どういうわけか呼び出されない。Pageクラスのプロパティに値は設定されているので、HTMLとPageクラスの関連付けは正しく行なわれているようですが。原因は、HTMLのformのidの命名ミスでした。Extensionを使う場合、HTMLの各要素に色々と規約があるのですが、この規定に従ったidを付与していませんでした。以前に、S2StrutsやS2Daoを使った際も、ちょっとした命名ミスで結構ハマったことがあり、これはCoCでの注意点だと思います。動いているように見えたりして調査が難しいことが多いです。Seasarのソースを読まないと、原因特定できないことも少なくありません。気づくのに時間がかかることもしばしば。実プロジェクトで使う時は、アーキテクトが命名規則一覧のようなものを作成・配布したほうが良さそうな気がします。3.ActionからServiceやLogicを呼び出すと、NoSuchMethodErrorActionにインジェクトしたServiceやLogicを呼び出そうとすると、NoSuchMethodErrorが発生しました。呼び出そうとしているメソッドは存在するように見えます。原因は...これまたServiceとLogicのクラス名の命名ミスでした。Deployの規約(?)とあっていませんでした。・インターフェース・・・HogeHoge・実装クラス・・・HogeHogeImplです。org.seasar.teeda.extension.interceptor.ActionSupportInterceptor.invoke(ActionSupportInterceptor.java:73)<以下略>が発生しました。原因は、Actionクラスに、PageインスタンスのGetterメソッドがないことでした。Actionクラスには、画面の入力値を保持したPageインスタンスがインジェクトされますが、インジェクトしてもらうだけなので、Setterだけで良いか、と思ってGetterを作成していませんでした。S2AOPで拡張されたActionクラスが、オリジナルのActionクラスのフィールドにアクセスする際、Getterメソッド経由でアクセスするっぽいです。(S2AOPが、サブクラス化によってアスペクトをウィービングしているから...かな)5.PageとActionのアクションメソッドの呼び出し優先順Teedaでは、アクションメソッドをPageクラスとActionクラスどちらにでも定義できるようですが、その呼び出される優先順は、(1)Pageクラス(2)Actionクラスのようです。・アクションメソッドをPageだけ定義し、Acitonには定義しない→Pageのアクションメソッドが呼び出される・アクションメソッドをActionだけ定義し、Pageには定義しない→Actionのアクションメソッドが呼び出される・アクションメソッドをPageとAciton両方に定義する→Pageのアクションメソッドが呼び出される(Actionに定義したアクションメソッドは意味がない)と言う事になります。今日1日でいろいろ勉強になりました。ほとんどが命名規約違反によるもので、それはSeasarサイトのドキュメントをしっかり読めば回避できるものがほとんどです。実際のプロジェクトでは、実装者全員がこのような問題に対処できるわけではないので、やはりSeasarプロダクトを理解したアーキテクトなりがサポートする必要があるように思います。自分がアーキテクトをできる場合は、積極的に採用(してもらえるように提案)したいと思います。5.0.xで環境を作って、簡単なプログラミングをしたのですが、ちょっとハマりました。単純なHTMLを作成。Beanと連携するわけでもない、本当にただのHTMLです。PlugIn+DevLoaderを使ってTomcat上で実行。作成したHTMLにアクセスしてみると...あらら例外発生org.seasar.teeda.core.exception.UriNotFoundRuntimeException:[ETDA0026]URI(http://www.seasar.org/teeda/extension)が見つかりませんorg.seasar.teeda.extension.config.taglib.impl.AbstractTaglibManager.getTaglibElement(AbstractTaglibManager.java:68)<以下略>うーむ、TeedaのタグライブラリのURIが見つからん、と言われています。結論から言うと、原因はDevLoaderを使っていることに起因していました。・DevLoaderを使用しているので、J2EE規定のWebアプリケーションのディレクトリ構造にしていない(※)。(WEB-INF/classesやWEB-INF/libがない)・タグライブラリのクラスやTLDファイルは、Jarファイルにまとめられていて、TLDファイルを明示的に配置していない。・Teedaその他の稼動に必要なJarファイルは、Mavenのローカルリポジトリ上にある。※DevLoaderを使うと、Webアプリ構成になっていなくてもTomcatにクラスやJarをロードさせ、Webアプリとして稼動させることができます。下にJarを置かないとTLDファイルを見つけてくれないようです。上述の通り、今回はTLDファイルを含むJarファイルが、Maven2のローカルリポジトリ上に存在するので、TLDファイルが見つからず、エラーになっているのでした。対処の方法はいくつかありそうです。PlugInDevLoader評価1TLDファイルを、WEB-INF下に配置するJarからTLDファイルを取り出し、WEB-INF下に配置します。PlugIn+DevLoaderによる効率的な開発が可能です。本来必要のないTLDファイルを配置することになってしまうのがタマに傷な気がします。使用する使用する○2TLDファイルを含むJarを、WEB-INF/lib下に配置するTLDファイルを含むJarを、Maven2ローカルリポジトリから、WEB-INF/lib下にコピーします。PlugIn+DevLoaderによる効率的な開発が可能です。Maven2でJarを一元管理しているのに、それとは別にJarを配置・管理することになり、ちょっと頂けません。PlugInのWebアプリケーションルートとして指定します。この場合は、DevLoaderを使わないので、Javaソース等を修正したらリアルタイムにTomcatに自動反映ができず、Tomcatに反映するにはWebアプリ構成を更新する必要があります。Webアプリ構成の作成・更新は、Maven2のwar:explodedゴールを使えば簡単にできますし、逆に言えば「ちょっと直しただけでいちいちTomcatがリロードしてうっとおしい」と言う事がなくなるので、むしろ利点と言えるかもしれません。PlugInはあきらめて、普通にWarモジュールを作成・デプロイします。この場合は、修正したソースを反映させるためには、Warの生成とTomcatへのデプロイが毎回ともなうので、開発効率が低下してしまいます。個人的には、3.の方法が好みかなと思います。PlugIn+DevLoaderでロードしている場合には、常に問題になるはずです。それにしても、Teeda良くできてるなぁ...素にJSFを使うと、faces-config.xmlがかなり問題になりそうですが、それもS2Containerの自動登録機能で解決。コメント:0JSF+Ajaxを学ぼう!しかし。(遅っ)いや、Rubyもやろうと思ってるんですけど、案件の多さからするとまだRubyは少なくて...少ないうちにやっとけ、って気もしますが、まだまだJava。問題があるなと思っていたわけです。何かないやろか?と言う事で、まずはJSF。とある人がJSFがイイ!と言っていたし、J2EE標準だから今後使用頻度が多くなる可能性は高いと見た。実際調べてみても、Strutsより開発しやすい印象です。あと、昨今はリッチクライアントと言うか、HTMLオンリーのUIに不満が聞かれるようになってきたので、Ajax。思っていたのですが...まぁそうも言ってられないかなと。調べてみると、JSFとAjaxの組み合わせはなかなか良さそう。ここしばらく学習を怠けていたツケは大きかった。そもそもJSFがわからん。Worldの記事を読んで概要を押さえているくらいなので、いざやろうと思うと結構手ごわい。いうわけか書籍が少ない。あれ?JSFって駄目なの??さらにAjaxもわからん。前に「うぉーAjaxすげー!」と巷が賑わっていた頃には手をつけなかったので、今更基本からやらんと駄目。動作原理もしっかり押さえておかないといけない。Beanに色々DIできるって!?しかもfaces-config.xmlを書かなくてもいい!?それは良いなぁ~ってかSeasarプロダクトも、S2Container+S2Struts+S2Dao止まりだ。うーむ、やはり日々地道な学習が必要だなぁ。申し込み秋期情報処理試験を申し込みました。アプリケーションエンジニア試験です。一昨年も受験したのですが、全く事前学習せずに受けたわりに結構手ごたえがありました。午前が駄目だったみたいです。午前は単純な知識問題なので、知ってるか知らないかなんですよね。知らなきゃどうしようもない。逆に午後は、応用問題なので、常識的に考えればある程度できます。逆に業務経験のない学生なんかには難しいのかもしれませんね。一昨年の反省を踏まえて、今回は過去問くらいはやっておこうと思います。(特に午前)ところで、なんでまた情報処理試験を受けようと思い立ったかと言うと、このブログ中でもたびたび書いているように、フリーランスでやっていくことへの不安が大きくなってきていて、再就職を真剣に考え始めているからです。要は、再就職する際の+αとして、資格を取っておこう、と言う事ですね。昔は年1~2本のペースで資格を取ってましたが、ここのところはからっきし。コメント:2懐かしい風景お盆で実家に帰ってきました。お墓参りに行く途中、天気も良かったので写真を。見る人が見たら、どこかわかっちゃいそうだなぁ。見ての通り、実家は猟師町なのです。言っても、ウチは猟師の家系ではないんですけども。昔とは港の様子も随分変わりました。奥に見える橋なんかはなかったですからね。子供の頃は毎日のように港で遊んだものです。釣りをしたり、泳いだり、火遊びしたり、いたずらしたり。何度か防波堤から海に落ちたこともあったなぁ。活動していると、こんな風景も目新しく感じて良いものだと思いました。コメント:0正確なドキュメントより、迅速なフィードバックループの構築を日頃の業務で感じたことシリーズ(?)。迅速・細かなフィードバックループを構築することに注力すべき」です。)を作成し、それを下流工程のインプットとします。ドキュメントを媒体として、肯定間の情報をやり取りすること自体は、(それが最善の方法なのであれば)それはそれで良いのですが、ここで欠けている、と言うか誤った前提があるのではないかと思っています。「人間とは誤りを犯すもの」と言うことです。形がなく、しかもとてつもなく複雑怪奇なものを表現していて、しかも大抵は自然文で記述されます。個々の事項について、今見えていない部分まで明確にし、かつそれらの事項の間に矛盾がなく、さらに、それを誰が読んでも同じ解釈ができるような完璧なドキュメントを作成するなんてことは不可能だと思います。現実的ではありません。「上流工程の成果物は完璧で、下流肯定ではその通りに作業すべし」となっていると、ドキュメントの誤りをそのまま下流に流してしまいます。なると、修正コストカーブ(下流に行くほど、修正コストが増大する)に従って、事態がどんどん悪化していき、最悪プロジェクトが破綻します。するか?むしろ「ドキュメントには漏れ抜け誤りがあって当たり前」と言う前提に立つのが自然です。・下流工程でも「ドキュメントの内容に漏れ抜け誤りがないか?」を常に気にする。(個人的には、ドキュメントに書かれている通りに作業するだけでは、はっきり言って開発会社・エンジニアとしてアマチュアだと思う)・ドキュメントに漏れ抜け誤りを発見した場合に、1ただちにそれを上流工程にフィードバックし、2正しい内容に修正したドキュメントを関係各所に展開し、3関係各所がそれを受けて適切なアクションを取ると言うフィードバックループが迅速に周る環境を構築する。具体的には、ステークホルダ間の情報連携の仕組・ルールの確立です。意外と手薄で、情報が関係者に伝わっておらず問題になることは少なくありません。(「そんな話聞いていないよ~」「勝手に変えやがって~」とか良く耳にしますよね)だと思います。・誤った仕様・設計のままシステムを構築ししてしまい、ユーザに価値を提供できない。・誤っているとわかっていても、それを是正する手段がなく、そのまま目をつぶらざるを得ない。なると、ユーザに誤ったシステムを提供してしまうだけでなく、プロジェクトチームのモラルハザードが起こる。(「どうせムチャクチャだし、どうでもいいや」)と言った事態に陥ります。工程ごとに会社が分かれている場合等、フィードバックループを構築するのが難しいケースも多々あるとは思いますが、そこは各開発会社が連携していかないといけない(連携するよう、元請け会社がイニシアチブを取る)と思います。年金の納付記録を確認してみました。勝手にリンクはって良いんやろか...公共のサイトだし大丈夫か。結果、ちゃんと記録が残っているようです。僕ぐらいの年代だと大丈夫なようですけども。言われないかと不安になりますね...尚、このサービスは申し込み殺到のため、ID・パスワードの発行に時間(3週間くらいかかった)がかかるそうです。社保庁は信用できませんが、自分で貯蓄しておくよりは、やっぱり年金として納めた方が得なんじゃないかと思います。月1.4万円が月6万(くらい?)になるわけで。納付した年金分は、所得から控除できて節税にもなりますしね。所得税率が去年までの最低税率の10%としても、約1.7万円の節税です。今リリースから、Mylynと言うプラグインがバンドルされるようになりました。何て発音するんだろう。??Mylynと言うのは、Eclipse上でタスク管理するためのプラグインです。僕もつい最近まで知らなかったのですが、主な機能としては、1.Eclipse上でタスクを作成・管理できる。タスクを作成し、そのライフサイクル(未着手~着手~完了)を管理できます。開発作業を行なう際は、タスクの内1つをアクティブにしてそのタスクの完了に注力します。他の作業をしたいときは、アクティブなタスクを切り替えなければなりません。作業のコンテキスト(考える範囲)や、ゴールを明確化することができます。「リファクタリングと機能変更は同時に行なってはならない。みたいな事が書いてあったと思いますが、まさにそれですね。タスクはカテゴリで分類したり、クエリで絞りこんだりすることも可能です。2.タスクにリソースを関連付けできる。タスクをアクティブにした状態でリソース(Javaのソースとか)を開くと、自動的にそのリソースがタスクに関連付けされます。(手動で関連付け、逆に関連の解除も可能です)関連付けられたリソースは、タスクがアクティブになった時に自動的にエディタで開かれます。関連するリソースがパッと開いてわかりやすい、と言うことですね。これがなかなか便利で、「えーっと、このタスクはどのソースを直してたんだっけ?」なんてことが無くなります。3.既存のチケット管理システムと連携できる。ようなチケット管理システムと連携できます。逆にチケット管理システム上で作成・更新したタスクの自動ダウンロードが可能です。開発メンバ間でタスクを共有することが大前提になると思います。同梱されてませんので、Mylynのアップデートサイトからインストールする必要があります。ちなみに、Mylyn自体は日本語化されていないようですが、タスク内容への日本語の記述等は問題なく扱えます。個人的に現場でTracとMylynを使って一人チケット管理を実践しているのですが、なかなか良い感じです。タスクを意識した作業になるので、自己管理がしやすくなります。やらないといけないことは優先順位を付けてTracにチケット登録しておけば、忘れることもありません。Tracにタスクの履歴も残るので、後から「あれはいつ対応したっけ?」と言ったこともわかりやすいです。タスク駆動ならTracだけでも良いんですが、前述の2.で挙げたタスクにリソースを関連付けられる、と言うのがMylyn最大のメリットかな、と思います。ツールとしてのデキは非常に良いと思うので、あとは使い方次第ですね。タスクを起こして、サインアップして、作業して、タスクを完了させると言うリズムに乗れないと、かえって手間が増えるだけにもなりかねません。忘れているとタスクに関係のないリソースがやたらと関連付いてしまったりします。縦割り組織のチームでは十分な効果は期待できないかもしれませんね。言うわけで、「使うだけで劇的に効果がある」ものではなく、タスク駆動、タスク共同所有と言うチームの文化がある前提で、それをサポートするプラグイン、だと言えると思います。いう意味では、アジャイル開発向けかな。コメント:0最近、スコッチが高いここのところ、スコッチをめっきり飲まなくなりました。ビールにはまっちゃった、と言うのもあるのですが、もうひとつの理由はウィスキーがちょっと高くなったことです。最近はディスカウントストアでも4000円近くもする。以前は3300円くらいだったと思うんですが。4000円と言ったら、マッカラン(10年)より高いじゃないか。安いシングルモルト...となると、ボウモア(12年)か。人気があるのかことごとく売り切れ。あと比較的安いのはマクレランズ。飲んだことないからいきなりボトルを買う勇気はないし。安さで言えば、北杜50度なら1000円弱。おいしいし、カーッとすぐに酔えるしで、悪くはない。知人のバーにでも言って、新しいのを試してみようかな。コメント:0プロフィールAuthor:crossroad関西在住。フリーランスのソフトウェアエンジニア。エレキベース(Rock&Roll)とお酒が好物でございます。