2007年6月24日日曜日

.Net/PHPプログラマから見たJava.

 暑いです orz.

 それは置いておき、先週の火曜日から、帰宅後にビールを飲みつつ1〜2時間/日のスローペースでJavaの勉強を始めました.
 以前もJavaの勉強をしようとした事があるのですが、何故かクライアントアプリケーションから取りかかってしまい、敢え無く挫折 orz

 苦い経験(?)から、今回はWebアプリケーションから取りかかってみる事に.

 結果から言えば「最初からWebアプリケーションで始めていれば良かった」と激しく後悔中です orz
 これなら何とか勉強できそう.
 今はStruts/Struts2を使って遊んで 勉強してます.

 勉強する環境にしても、

  ・WindowsまたはLinuxまたはMacOS
  ・J2SE(JDK/J2 SDKとも呼ばれる…名前が変わりすぎw)
  ・Eclipse
  ・WTP(Web Tools Platform)
  ・Tomcat

 が整っていればOK.
 lightmaterialの場合Eclipse+WTPは既に入れていたので、J2SEとTomcatを入れるだけでした.
 今までWebアプリケーションはJ2EEを導入してないと開発出来ないものだと思っていましたが、そう言う訳では無く、本当にEnterpriseな環境を構築する際に必要(と言うか便利)なだけの様です.

 私がJavaを今まで敬遠してきた理由は、「なんか複雑そう」「EJBとかJavaBeansとかDIとか意味不明」等々、専門用語やら色々な要素が関連しあって動く複雑な物、と思っていたからです.
 ASP/ASP.NetにしろPHPにしろ、(PHP用のFrameworkは別として)ほとんど言語環境単体で動く事を考えると、どうしても敬遠しがちになります(あくまで個人的な感想).

 が、実際に触ってみると「初歩的な事は」意外とそうでもありません.
 初歩的な事を勉強するのに、EJBもDIも気にする必要はありませんでしたから.

 今の所Java(Webアプリケーション限定)について把握したのは、
 1. 完全にオブジェクト指向言語(あたりまえ)
 2. メモリの管理がちょっとだけ特殊?
 3. パッケージという概念がある
 4. 現状の標準的構成として、ページを描画するJSPとコードを担当するServletで構成するのが一般的
 5. Frameworkを使わないと死亡
 6. 描画を担当するJSPも初回アクセス時にビルド(?)される
 7. ファイル構成が少し特殊、各種設定がXML

 と言った所でしょうか(間違えてる可能性大).

 [1]は最初から分かっていた事なので、特に戸惑いはありません.
 .Netにしろ、正しくコードを書いていればオブジェクト指向な記述になりますし、PHPにしてもオブジェクト指向な記述の仕方が現状の標準的なコーディングかと思います.

 [2]のメモリ管理ですが、基本的にはオブジェクトが参照されなくなった段階で、メモリから破棄される様です(正確に言えば、ガベージコレクションの対象になるのかな?).
 その為、通常はC/C++の様に明示的に破棄する必要はありませんが、参照サイトによってはnullで参照されなくなった事を明示すべきだ、との記述が見受けられました.
 まぁ、この辺はVB/ASP.NetでもNothing指定すべきだ、とする傾向がありますので、これも戸惑いはありません.

 [3]のパッケージ.
 これはクラスライブラリの様なもの、と私はとらえてます(あってるかは不明).
 今まで「org.apache.xxxx.....」などと言うファイルを見かけた事がありましたが、何の事やらさっぱり不明でした.
 この「org.apache.xxxx.....」の部分がパッケージ名(?)にあたる様です.
 また、パッケージ名は配布や流用等を行う事が多いので、他のパッケージ名とかぶらないように、開発元のドメインを逆さにした名称を付けるのが一般的との事.
 それで「org.apache」だの「org.eclipse」だのと言うファイルがある訳ですね.
 すごく納得しました.

 [4]のJSPとServlet.
 これもASP.Netをやっていれば何も戸惑う事はありません.
 ASP.Netで言う所の、「xxx.aspx」ファイルと「xxx.vb」ファイルの関係と考えればあまり大きく間違える事は無いと思います(厳密には違いますが. JSPの場合Servletが無くても動きますので).
 現状のコーディング方法として、「JSPには極力コードは書くな」「コードはServletに書け」と言う傾向がある様です.

 [5]のFrameworkについては、PHPも結構同じ事が言えると思いますが、Javaの方がよりFrameworkに依存している様に思います.
 そのため、Frameworkを使わずにプログラムを書こうと思うと、非常に雑多なコーディングになりそうです.
 画面遷移ひとつとっても、ServletからJSPに渡す変数を一々setAttribute/getAttributeしたりDispatcher作ってページ呼び出したり…単に私が簡単な方法に気付いてないだけかもしれませんがw
 これらJavaの代表的なFrameworkとしてStruts/Struts2JSF(JavaServer Faces)があります.
 それ以外にもあるのかもしれませんが、今の所勉強の対象にするつもりなのは、この2つのFrameworkです.
 特にJSFは標準機能としての提供がされる予定らしく(?)、今後のJava開発環境では必須になるのかもしれません(StrutsはApacheプロジェクト).
 ただ、StrutsとJSFでは重点部分が異なる様で、StrutsはController部分、JSFはView部分(?)に重点を置かれたFrameworkらしく、今ではStruts+JSFで動作させる方向にも行きつつある様です(Struts2から?)ので、両方勉強しておいて損は無いだろう、と思ってます.

 [6]はよく分かりません.
 よく分かりませんが、初回アクセス時にビルドする事で、その後の処理を高速化する様です.
 この辺は後々触っていれば分かってくるだろうと勝手に妄想中.

 [7]のファイル構成については、どちらかと言うとTomcatの構成なのかもしれませんが、まだその辺は良く分かっていません.
 少し特殊と言うのは、「WEB-INF」や「META-INF」と言った設定用のディレクトリが最初から定義されていて、そこに設定ファイルやらライブラリやらビルドしたServletやらが設置される様に半分強制されている事です.
 これらのディレクトリには、ブラウザ経由で直接アクセス出来ない様になっています.
 まあ、まとめて放りこめるから便利と言えば便利ですが、WTPで作ったプロジェクトの標準ディレクトリ構成と少々あってないんですよね…これどうにかならないんだろうか orz
 また、基本的に各種設定はXMLファイルに記述する事になります.
 Frameworkの設定もXML.
 あれもこれもXMLです.


 その他JavaBeansなんてのもありますが、この正体が分からない.
 JavaBeansで検索すると、GUIなビルダーとの連携により云々と書かれているものもあれば、単純にProperty/Getter/Setterを持ったクラスファイルだよ、と言った書き方のサイトもありました.
 更にはStrutsのActionForm部分をBeanと書いている所もあり、現在かなり混乱中ですw

 取り敢えずひとしきり触ったら、Javaについてのメモを順次記述予定.

※下の画像は単にJSPのみでの動作例です. ServletもStrutsも何も使ってません.

2007年6月16日土曜日

コンデンサ破裂・液漏れ・膨張.

 某所でPCの電源を入れると、CPUファンやCDに通電している状態にも係わらず、まったく画面出力されない現象に出くわしました.
 出くわしましたと言うか、今出くわしてます orz

 つい1ヶ月くらい前まで普通に動いていたんですが、今日電源を入れてみると上記のような状態に.
 「何だろう?」とケースを開け、コネクタ類の接続を確認・抜き差しして、ケースを開けたまま電源ON.
 が、全然動く気配なし.
 何が原因かとマザーボードを眺めるlightmaterial.
 ん?
 コレ何だ?

 こ、これは噂でしか聞いたことが無い「コンデンサ破裂」ってやつじゃ?! orz
 ※後から分かりましたが、「コンデンサの液漏れ」ですね.

 確かにこのPCは2002年に購入した物なので、そろそろガタが来ててもおかしくないんですが、私の自宅にあるPCではコンデンサ破裂なんて今まで経験した事無いですし…
 正直参りました.

 マザボの修理と理想の電源 - ☆たるさんのパソコンフィールド

 上のサイトにコンデンサの破裂や液漏れについて詳しく書かれていますが、どうやら中学校以来ハンダゴテを見た事すら無い私には交換なんて無理そうです orz
 ここは素直に諦めましょう.
 どうせ私のじゃないですし、会社の費用で交換購入する事になるんだから.

 そう言えば、自宅には8年くらい前に購入した初代PC(EPSON DIRECTで買ったやつw)がありますが、未だにちゃんと動きます.
 ただ、マザーボードなんて最近ちゃんと見てないから、もしかしたらコンデンサが膨張してるかもしれません.
 今回みたいに使いたい時に使えなくなる前に、予めリタイアさせた方がいいかもしれません.

2007年6月12日火曜日

PHPからのPDF出力でハマる.

 また珍しく平日にメモ.

 PHPからPDF出力すると言えば

  ・PDFLib
  ・FPDF
  ・Zend Framework

 あたりが代表格かと思います.
 Zend FrameworkでのPDF出力はまだ試してませんが(正確には0.xの時に上手く動作させる事が出来ませんでした orz)、PDFLibもFPDFも基本的にはPHPのコードからPDFを吐き出す事に変わりありません.

 そして出力時の問題で有名なのがIEとsessionの問題.
 PHPでsessionを使っている場合、普通にPDF出力するとIEではまったく表示されない状態になります(画面真っ白).
 その為、IEを考慮する場合に於いて、sessionを使ってるコードからPDFを吐き出す時は

  session_cache_limiter('private')

 をsession_start前に宣言してやる必要があります.
 当たり前ですがここまでは知っています.

 んが!
 まさかOpera9でも同じ状況になるとは?! orz
 そんな事まったく知らず「あれ?何で?何で?何で出ないの?」と大ハマり.
 Opera8まではinlineで表示できなかったので、Operaの事はまったく気にしてませんでしたよ.
 まったく、相変わらずOperaは色々と面白い事をやらかしてくれます.
 Opera8→9で、JavaScriptからIFrame内をprintした時の挙動も違いますしw
 今更ですが、Opera9をもう少し触ってみる必要がありそうです.

 そしてもう一個.
 原因は良く分かりませんが、Safariで同じ様にPHP→PDF出力すると、場合によって

  ファイルの最初に%PDF- がありません。

 と言うエラーが出ます(Ver 1.3.2でしか確認してません).
 出ますと言うか出てしまって、またしてもハマりました orz
 未だに原因が分からないんですが、取り敢えず

  header('Content-Length: [バッファサイズ]')

 を送出しなければこのエラーが起きない事が判明.
 なんだかなぁ.
 対処出来てるのはいいんですが、非常に気持ち悪いです.
 どっかでコード間違えてるんだろうか?
 でもSafari以外で出ないんだよなぁ orz

 しかも、今日『Windows版のSafari』が開発中である事が発表されました.
 iPodでiTunesが普及した様に、抱き合わせ戦法でWindowsにSafariが普及した場合、無視できない存在になるかもしれません.
 正直もうブラウザは増えなくていいですから orz

※現状Windows版Safariはまともに動きません

2007年6月11日月曜日

送信前に宛先は良く確認しよう.

 先日痛恨のミスをやらかしました.
 詳しくは書きませんが…まぁ…タイトルのね…そんな感じの痛恨のミス orz

 恐いわぁ〜.
 最終的に問題なかった訳ですが、メール送信が恐ろしくなりました.

 と言う事で、現在Thunderbirdには↓コレを突っ込んでいます.

 Confirm-Address

 その他にも同類で

 Check and Send

 と言うExtensionがあるのですが、使い勝手の問題からConfirm-Addressを導入.
 それでも動作的に少々怪しげな部分があるので(失礼)、現在更に同類のExtensionを模索中.
 作り方が分かっていれば自分で作りたい所ですが…全然分かりゃしません orz

2007年6月10日日曜日

Tracのマルチプロジェクト管理用Plugin - TraM.

この概要は表示できません。投稿を閲覧するには ここをクリック してください。

2007年6月5日火曜日

Ajax loader icon.

 いつも週末だけ管理してるので、平日に投稿と言うのも珍しいですが、ちと忘れそうだったのでメモ.

 Ajaxload - Ajax loading gif generator

 AjaxなんかでAsynchronousにデータを読み込む時に表示するアイコンをFeeFree且つオンラインで生成してくれるサイト.

 こんな感じ.
 ※左の画像はbloggerでアップロードしてるので動いてませんが、通常はグルグル回ってます.

 この他にも、プログレスバーとか変わったのとか色々生成出来ます.

 しかしこのサイト、ライセンスについての記述がフッタの一文しか見当たらない訳ですが、これって商用で使ってもOKなんだろうか?

2007年6月3日日曜日

PDTとSubclipse.

 以前も書いたPHP Development Tools.
 実際に使ってみると、結構いい感じです.
 コメントで日本語なんか使うと、色分けや太字処理なんかで問題が出ますが、その辺が気にならなければ快適に使えます.

 ※使う日本語によって、現象が出る出ないがあります.

 ただ、私のやり方が悪いのか、Subclipseが悪いのか、Subversionで管理されたPHPのコードをPDTで編集しようと思うと、思い通りに行きません.
 前に書いた様に、PDTはPHP Projectとして作成したプロジェクト以外では、コードアシスタントもアウトラインも動いてくれませんので、SubclipseでチェックアウトしたプロジェクトをPDT用のプロジェクトにしないといけませんが、この方法が分からない.
 どうやればいいんだろう???

 結局今は力業で.projectファイルをPDT用の物に置き換えてSubclipseとPDTを共存させてますが、まさかこんな力業が正当な使いかたじゃないと思うんですよね.
 どうやったらいいんだろうか?

 うーん分かりません orz

Fedora7リリース.

数日前の話になりますが、Fedora7が正式リリース.

Fedora7からは、通常版のインストールイメージがDVD化されています.
つまり、今まではCD5枚分(レスキュー除く)のイメージが必要でしたが、今回からはDVDイメージ1枚分でOK!と言うことです.
…DVD-Rドライブもってない私はどうすれば? orz
と言う事で、貧乏マックスなlightmaterialはおとなしくLiveCD版をダウンロード.
LiveCD版なら普通にCDイメージですし、(会社の)CD-R/RWドライブを使えば焼けますので.
本当はダメなんですけどねw

LiveCD版には更にGnome版/KDE版が揃ってます.
この辺は好みの問題ですが、最近Xfceが気に入っている私としては、Xfce版も用意してもらいたかった所です.

 LiveCD起動直後はこんな感じです.
 ネットワーク接続通知が出ているのは、単にLANケーブルをルータに差し忘れていたからですw
 印象的には「何も変わってないじゃん」と言うのが第一印象.
 グラフィックはVistaに倣ってか、GDM/KDMともにOpacity的な処理がされていますが、それ以外はパッと見特にFC6と変わっていません.

 もちろん内部的にはリポジトリの統合やら、導入環境のバージョンアップ等々あるんですけど.

 それでも劇的な変化というのはありません.
 LiveCDとしての特徴は、以前書いたUbuntuと同様に、デスクトップにHDDへインストールするためのショートカットが用意されている点、デフォルトでは(当然)英語で起動するので、毎回毎回languageにJapanese選んだ上でキーボード設定を日本語にする必要がある点です.
 正直面倒です orz
 おまけに、lightmaterialのやり方がまずいのか、KDE版では結局日本語に出来ませんでしたw

 名称が変わった事も含め、もう少し劇的な変化があるのかと期待していただけに、少し拍子抜けした感があります.