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.

 最近は私生活の方が色々とあってゴタゴタしてますが、負けずにメモ行きます.

 今回はTracで複数のプロジェクトを管理する際に便利な(多分w)プラグイン「TraM」.
 Trac自体の事を教えてくれた知人が以前から「複数プロジェクト管理するのにTraMってのを入れている」と言う話を聞いていましたが、まだTracを使いきれていないlightmaterialには何の事やら意味不明 orz
 取り敢えず入れてみて把握しよう!と言う事に.

 ・TraM [ver 0.1]
  ※プロジェクト自体がVer0.1と若いので注意.

1. TraMをダウンロード.



 TraM自体、Subversion経由でチェックアウトする事を前提に配置されています.
 インストールするには、TraMのメインページに書かれているtrunkから全部ファイルをダウンロードするか、Svnクライアントで最新リビジョンをすべてチェックアウトする必要があります.
 まぁ、後者の方が賢いかと思います.
 今回は「/sources/TraM」と言うディレクトリにチェックアウトしました.


2. TraMをインストール.



 チェックアウトしたTraM用ディレクトリに入り、setup.pyでインストールします.
 インストールパスは、以前作成したテストプロジェクトのディレクトリである事を前提にしています.

[??@fedora]# cd /sources/TraM
python setup.py install

 非常に簡単です.
 多分ここまでは問題無いかと思います.
 もしエラーが出た場合は「Tracインストール手順メモ.」を参照.


3. mod_pythonの設定を変更.



 TraMのページでは、mod_pythonの前にtrac.iniの設定を変更するように書かれていますが、先にmod_pythonの設定を変更してしまった方が分かり易いかと思います.
 mod_pythonの設定と書いていますが、実際に編集するのは(trac用)apacheの設定ファイルです.

[??@fedora]# vi /usr/local/apache2/conf/extra/httpd-trac.conf
 <Location /trac>
  SetHandler mod_python
  PythonHandler tram.modpython_frontend
  #↑この1行を「trac.web.modpython_frontend」から変更
  PythonOption TracEnvParentDir /usr/local/trac
  PythonOption TracUriRoot /trac
  SetEnv PYTHON_EGG_CACHE /usr/local/trac/testprj/.python_eggs
 </Location>
 # 以下はパスワード制限する場合に必要.
 <LocationMatch "/trac/[^/]+/login">
  AuthType Basic
  AuthName "Test Project"
  AuthUserFile /usr/local/trac/testprj/.htpasswd
  Require valid-user
 </LocationMatch>

 ※編集ファイルが意味不明な場合は「Tracインストール手順メモ.」を参照.
 尚、PythonOptionでTracEnvDirでは無くTracEnvParentDirを指定している必要があります.
 これは何なのかと言うと、Tracのプロジェクトを複数持つために、Tracプロジェクトのディレクトリそのものでは無く、親のディレクトリを指定してあげる事を意味します.
 この親の下に各Trac用プロジェクトを保存しますよ、と言う指定です.


4. プロジェクトリスト用プロジェクトを作成.



 何のこっちゃ?w
 通常TracでTracEnvParentDirに設定したディレクトリ(今回の例の場合は「http://localhost/trac/」)をブラウザで表示すると、以下のような「味もそっけも無い」一覧が表示されます.

 確かに視認性はいいのですが、本当にそっけないリストです.

 これをTraMはグラフィカルにしてくれます.
 グラフィカルというか、TracでTracのプロジェクトを表示(管理)するイメージですかね?

 この管理用のプロジェクトを作成してあげる必要があります.
 尚、作成するプロジェクトのパスはTracEnvParentDirの直下に「all」と言う名前で作成する必要があります.

[??@fedora]# trac-admin /usr/local/trac/all initenv

 # 以下、「>」の右側はテストで作成した環境.
 # 空白の場合はデフォルト値(そのままEnter)
 Project Name [My Project]> TraM
 Database connection string [sqlite:db/trac.db]>
 Repository type [svn]>
 Path to repository [/path/to/repos]> /usr/local/svn/repos
 Templates directory [/usr/share/trac/templates]>

 作成した後は、Apacheから操作出来る様に、所有者を変更してあげます.

[??@fedora]# chown -R [apacheユーザー]:[apacheグループ] /usr/local/trac/all

 これで取り合えずTraMのインストール自体は完了です(後で各Tracプロジェクトの設定も必要です).
 このプロジェクトリスト用プロジェクトを作成しなかった場合、以下のようなエラーが出るでしょう.

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, xxx@xxx.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

 ちなみにログには

mod_python (pid=[pid id], interpreter='[server address]', phase='PythonHandler', handler='tram.modpython_frontend'): Application error
[以下ダラダラとエラー]

 と言った内容が記述されていました.

 ここまで来たら後一歩です.
 最後の仕上げとして、TraM用の各プロジェクト設定を行います.


5. TraM用プロジェクト設定.



 TraMを有効にするためには、各プロジェクトの設定ファイル(trac.ini)に以下のように記述する必要があります.

[??@fedora]# vi /usr/local/trac/all/conf/trac.ini
…[中略]…
[components]
webadmin.* = enable
#↑この行は以前導入したTrac Web Admin Plugin用の記述です.
# 導入していない場合は無視してください.
tramplugin.* = enabled
trac.ticket.report.* = disabled

 前回のWeb Admin Pluginが「enable」で、今回のTraMが「enabled」なのは意味が分かりませんが、「enable」では動きませんので注意が必要です.
 また、trac.ticket.reportを無効にする必要があるようです(詳細は分かりません orz).

 上記例では、プロジェクトリスト表示用プロジェクト「/trac/all」の設定ファイルを編集していますが、各プロジェクトの設定にも同様の設定をしておいた方が良いかと思います.
 理由は次項で.


6. プロジェクトリストを表示してみる.



 作成したプロジェクトリストを表示してみましょう.
 先ほど例に書いた「http://localhost/trac/」にアクセスすると「http://localhost/trac/all」にリダイレクトされ、以下のような画面が表示されます.


 インストール確認用のプロジェクトしか突っ込んでい無いので分かり難いかもしれませんが、プロジェクトリストが表示されています.
 プロジェクトリストの各プロジェクト名(赤い字で書かれた「Test Project!」の部分)をクリックすると、各プロジェクトのTracページを表示できます.
 メニューが英語のなのは仕方ありませんが、注目すべきはメニューの右端に「ProjectList」と言うメニューが追加されている事です.
 各プロジェクトの設定ファイルを編集する事で、各プロジェクトからもこのプロジェクトリストをメニューから表示できるようになる訳です.



 その他にも、TraMのプロジェクトリスト用プロジェクトからは、各プロジェクトのソース参照等々、複数プロジェクトの管理に有効な機能が提供されます.
 

 ふーん、なるほどね.
 知人の言っている意味が分かりました.
 複数プロジェクトを管理する場合、これは便利そうです.
 …んが、便利そうだけど自宅じゃほとんど使わないかも orz

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

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