心のおもむくままにで“Java”タグの付いているブログ記事

ダウンロード・サーブレットの件、ftp4jを使ったのですが、お客様から、jakartaのcommons-net.jarを使ってほしいと。

修正は簡単だったのですが、今度は日本語ファイル名のファイルがダウンロードできない。

解決法はFTPClientのスーパークラスのFTPクラスにエンコーディングの設定がある。

Windowsサーバーなら、

client.setControlEncoding("Windows-31J");

あるいは、
client.setControlEncoding("SJIS");

ポイントは、コネクトの前に設定すること。

最初は単純に思えました。表示ページから、リンクをクリックして、添付資料をダウンロードする。

しかしよく仕様書を読むと、これをFTPで、しかもユーザとパスワードで接続して行う。

「ftp://username:password@server/directory」とかリンクを作ればできるけれど、これでは、パスワードが丸見え。

結局、FTPでテンポラリのファイルをダウンロードして、それをクライアントに返す、サーブレットを作ることに。

FTPはftp4jを使い問題なく、ダウンロードできる。

問題は、クライアント側でセーブするファイル名が日本語だと文字化けすること。

この問題の解決には、２段階のデバッグが必要でした。

まずは、URLEncodeされたファイル名を、サーブレットで正常に、getParameterで持って来れるか？

と、ファイル名をUTF-8で取得できたら、それを、「 response.setHeader( "Content-Disposition", "attachment; filename=\"" + cnv_filename + "\"" );」で正常に「cnv_filename」を設定できるか？

結論から言うと、前者は、「String filename=new String(request.getParameter("file_path").getBytes("8859_1"),"UTF-8");」、後者は、「 String cnv_filename = new String(org_filename.getBytes("SJIS"),"8859_1");
」で解決しました。

短納期のWEBアプリケーションのお仕事。
一番のリスクは、サーバーがWEBLOGICだということ。

OTNの開発ライセンスが30日ということなので、できるだけ試用版のインストールは遅らせて、TOMCATで開発。
画面デザインを除いてほぼ確認が終わり、最後に残ったリスクはWEBLOGICへの移行。

今日は、夕方から、情報収集して、明日から開発ライセンスでのインストール作業を始めます。

それと平行して、終結しようとしているお仕事が２つあり、これにもけりを付けないといけない。
また別に、iPhoneアプリ開発。昨日またひとつバグを取って、EINがくるのを待っている状態かな。

４月までは、なかなか忙しい時期が続きそうです。
うれしい悲鳴と言うか、貧乏暇なしというか、迷うところです。

以前の会社の同僚と、週に何回かメールのやり取りをしているのですが、この会社もついに、２万人の人員削減ということ。
何か元気づけてあげたかったのですが、送ったメールには、こんな、お話を。前にも書いたことがあるのですが、彼は気に入ってくれた模様。

天国の門をくぐり、神様の胸に引き寄せられ、自分の一生の出来事を振り返る機会が与えられた。そこで人生の出来事のひとつひとつが、浜辺の砂における足跡として記録されていた。人生を振り返り始めると、その人は浜辺にある足跡が二人分あるのを見て、驚いた。神様の顔を仰ぎみると、神様はにっこりと愛情に満ちた笑顔を返した。その瞬間、その人は悟った。神様は、人生の一歩一歩すべてに、側についていてくれたのだった。
しかし、人生の最も困難な場面に直面したとき、浜辺には、ひとり分の足跡しかなかった。苦悩した顔で神様を仰ぎながら言った。
「人生が最も困難だったとき、最も辛かったとき、あなたはどうして私を見捨てたのですか」
神様が答えて言われた。
「あなたを見捨てたのではない。そのとき、私はあなたを運んでいたのです」

神様を信じている訳ではないのですが、私にとってのこのお話の教訓は、一人でつらい思いをしていると思っても実際には、もっと大きな運命に庇護されて運ばれているのだと。それはみなさんの肩の上に乗っている見えない守護天使かもしれません。

UMLを描くツールがないか探していたのですが、リバースエンジニアリングなんていらないから、シンプルなものが欲しい。

どうせなら、前のプロジェクトで使っていたVisioを使えればベスト！

という方にお勧めなのが、Visio用のフリー（寄付金募集中）のUMLステンシル。

VisioはStandardだけでも、かなり使えて、お勧めです。

UMLではないのですが、ドキュメント作成ということで、Hot Documentのサンプルも見たのですが、コメントだけではなく、ソースも解析している、と謳っているいるわりには、ファイルの一覧とかメソッドの一覧とか、ソースの行数とか、単に数え上げているだけのように見えますけれど・・・。

納品物をJavaDocで作っているときに、問題が・・・。

JavaDoc以外のアノテーションの記述で、JavaDocがCrashします。

出来上がったドキュメントは、左側の「すべてのクラス」のフレームが正常に表示されません。

しばらく解決策を探った結果、コマンドプロンプトから、JavaDocを起動するのではなく、Eclipseから作成することで、正常に作成できることが分かりました。

JavaDocのバージョンの違い？

週末からずっと懸案だった問題が一段落し、このブログを書いています。

思ったのは、夜更かしをするより、睡眠をとって頭をリセットし、朝、問題を考える方が解決しやすい、ということです。

昨日、今日とそれを実感しました。

今回手伝ってくれたMさん、本質的にJavaプログラマなのですが、やはりコードがきれい。

私みたいに、Cから入った人のコードとは違います。

年齢は同じくらいなのに・・・少しうらやましい。

Mさんは、Null Pointer Exception を「ヌルポ」というのですよね。

業界用語でしょうか？

それで思い出したのが、オーケストラでヴァイオリンを弾いている弟がチャイコフスキーのことを「チャイコ」と言っていたこと。

なにか笑ってしまいました。

パフォーマンスが重要視される大規模システムのリサーチをしています。

トレーディングや、携帯のサイトなどのシステムですが、驚いたことに、このようなシステムでは、もうJ2EEではない。

分散キャッシュを使った、イン・メモリーな処理になるのですが、いくつかのメーカーが、このようなグリッド製品を出しています。

GigaSpaces、Tangosol (現在はOracle)、Gemstone、Terracottaなどです。

この文献が、参考になります。

GigaSpacesとGemFireについては、評価版をダウンロードして、動作させてみました。プアーなマシンの上ですが。

このようなソフトのアーキテクチャには、層すらないのです。カルチャー・ショックですね。

層は複雑さや、ロードをシェアするために必須と思っていたのですが・・・。

それから、イン・メモリのデータ・ストアも、かなり衝撃ですね。

前述の文献では、「メモリ内に保存されたデータの依存関係が、ディスク上では損なわれることがあり、数秒もしくは数分、数時間にわたってデータを保存するには、結局のところハッシュマップやJavaSpaceが最も良い方法だということです。データの元の形を保ったまま、普通は保存しておける (恐らくオブジェクトかXML) のに、なぜこれをリレーショナル構造にマップし直さなくてはならないのでしょう。」と述べています。

大変勉強になります。

リサーチの機会を与えてくださったＭさんに感謝です。

お仕事の関係で、ついにロッド・ジョンソンの「J2EE システムデザイン」を読もうと決心しました。

名著だということは、いろいろな人が言っていて、何年か前にJavaのお仕事をした時に、客先のKさんが強く勧めていたのです。

そのときには、J2EEでなかったことと、その分厚さ（800ページ）に怖気づいて、積読になったのですが、昨日、アットマークITのSpringの解説で、必読だと書いてあったことから、棚の奥の段ボールから引っ張り出して挑戦！

まだ1割も読んでいませんが、案の定「もっと早く読んでおくべきだった」と後悔することしきり。

HOW TOよりも、HOW NOT TOの方が量が多くて貴重だという感触です。

懸念は、少し（大分？）古いことでしょうか？

初版が2003年、本を買ったのは、2005年だったと思います。

他にも、Springの本と、J2EEアンチパターンの本を注文して、待っているところです。

新しいお仕事は、プロトタイプの作成なのですが、これが難題。

常日頃、「自分自身を時代遅れにする努力をしていかないといけない」と言っていますが、これは正にその姿勢が試されているような開発で、Javaの最先端のランナー群に放り込まれた気分です。

今日は、お仕事で使うかもしれないオープンソースのツールをダウンロードして、動かそうとしたのですが、動作せず。

基本的なところで躓いています。

1週間後に最初のマイルストーンがあるのですが、私の好きなメアリー・ケイの言葉、「できると思えば、あなたにはできます。できないと思えば、あなたの予想はあたりです。」を信じて、全力で取り組むだけです。

ということで、今のところ、時間が一番大切なのですが、木曜日は別件で、客先都合で延び延びになっていた、結合試験で1日つぶれそうです。間違っても翌日に繰り越さないように十分注意です。

今回のお仕事は非常にきついのですが、良いところは、新しい技術を学べるということ。

勉強させてもらって、報酬をいただけるとは、なんと贅沢な。

幸せ者です。

山田和夫
ソフトバンク クリエイティブ株式会社(2006)

去年買って、積読になっていた本です。次のお仕事に使うかも知れないということで予習しています。

EJBは敷居が高いと思っていた私にとって、3.0の登場は、福音となるかもしれません。

山田さんは、前書きで、そのメリットを力説する。

「彼ら（Web層を中心としたベンダー）は多くの場合PHPなどの簡便なスクリプト言語を使用したり、Web層のコンテナであるTomcatとJDBCを使って動的なサイトを構築していた。たいていはEJBを利用するメリットがないと判断されていたようだ。

　EJB 3.0は、そんな彼らにとっても福音となることは間違いないと確信する。なぜなら、ロジックとデータベースの物理設計が同時にコードにかけるアノテーションを使うと、１人で何役もこなさなければならない小規模案件にも強い機動力を与えることになるからだ。」

「これまでは、『分散しないのであればEJBでなくても』という論調をよく目にしたが、これからはEJBを使いたいがために、分散しなくてもEJBを使うというケースも出てくるだろう。」

「本書は、2.1までのEJBを使って内心うんざりしていた開発者、従来からWeb開発を行ってきたがEJBは敬遠していた開発者を対象として、EJB3.0の新しい部分を紹介する内容になっている。」

ここまで書かれたら、読むしかないです。

現在、1/4ほど読みましたが、なんとか理解はしているが、腑に落ちていない、といった状況。

サンプルのコードは非常に簡単なコードですが、複雑なアプリはどんな感じになるのか、想像するとちょっと怖いですが。

リファレンスを除いては、週末前になんとか読み切ります。

javaのお仕事が入りそうなので、開発環境の準備を。

SUNのSPARC Stationが必要になりそうなので、中古を確保。

ブレードサーバーなので、コンソールを接続するための、RJ-45とDB9のシリアル・ケーブルも注文。

それと同時に、お客様から、開発環境にアクセスできるようにしてほしいということで、ルータの設定のテストを。

固定のグローバルアドレスを持っているので、設定は簡単です。

ちょっと癖のあるルータですが、試験的に、SUNではないのですが、Linuxサーバーのwwwのポートを、ポートマッピングの設定と、フィルタリングで、wwwのポートに穴をあける（デフォルトではWANからのwww接続は全部拒否です）。

これをThinkPadとモバイルカードで確認しました。