[rNote]

rNoteの日付の扱い方 / 2005-09-25 (日)

のりさんから、「rNoteでDateタグなしでアップしてるのにRSSの日付が、YYYY-MM-DDT00:00:00+0900 みたいになって、うまくタイムスタンプが取れてないみたいんだけど、なんでや?」って話をされて、ちょいと調査してみました。

まず、skinの内容を見てみましょう。 rss_item.skinファイルを覗いてみます。

<dc:date><%=$Date fmt="%Y-%m-%dT%H:%M:%S%z"%></dc:date>
    

Dateタグってのが使われていて、fmtでフォーマット指定がされていると解釈ができます。 では、Dateタグの定義を見てみましょう。

define(TAG_DATE,'Date');                               // 日付のタグ名
    

これでTAG_DATEを調べればよいというのがわかります。 GetContentsEach関数内で、以下の処理が行われています。

while($tagstr=SkinTagChk(TAG_DATE,$a,$opt)){
        $a=str_replace($tagstr,MakeDateStr($g_filelist[$fname][FILELIST_DATE],$opt),$a);
}      
    

MakeDateStrは単純に日付をフォーマットして返すだけです。 という事は、$g_filelist[$fname][FILELIST_DATE]があやしいです。 これはReadFileCache関数で作成される変数で、単純にキャッシュから日付をとってきているだけです。 と、ここまで来たらキャッシュを生成する部分があやしいとなります。

キャッシュの生成時にはファイルのリストを作ります。 ファイルリストはファイル名のハッシュテーブルとなっていて、値には問題となる日付が入ります。 値でソートをかければ、日付順にキャッシュが生成できるというわけです。 そして、そのファイルリストの日付がキャッシュに入るという処理をしています。 つまり、ファイルリスト生成時が問題となるわけです。 では該当のコードを見ていきましょう。

 
$date=get_XMLTag(TAG_DATE,$datafile);
if(!$date){
        $filelist[$dir.$file] = filectime($fullpath);
}else{
        $filelist[$dir.$file] = w3cdtf_to_time($date);
}
    

さて、このコードを見て正直困りました。 Dateタグが存在しない場合は、ファイルの生成日付を取っているのです。 これではのりさんの「Dateタグを入れずにアップしているのに」という前提条件から、0埋めになるのは考えられないのです。 それを証明するために簡単にテストしてみましょう。

<?php
$date = filectime('/Users/btm/develop/php/filectimesample.php');
$format = "%Y-%m-%dT%H:%M:%S%z";
$ret = strftime($format, $date);
print $ret . "\n";
?>
    

こんなサンプルを用意して実行してみます。

$ php filectimesample.php 
2005-09-24T19:22:03+0900
    

正しく時間もとれています。 というわけで、コードから考えられるのはrNoteは悪くないという事ぐらいです。 なにかしら運用の方でおかしくなっているのではないでしょうか? 例えばFTPが変で、日付情報だけアップしてるとか。 まぁ、そんな謎な動作はしないと思うんだけど...どうなんでしょ? というわけで人柱になるため、このエントリはDateなしで(w どきどき、わくわく。

ちゃんと 2005-09-25T02:00:49+09:00 って出てきました。 というわけで、問題なさそうだなーと思ったら、 のりさんもなんか直してるっぽいですね。 うは、俺時間の無駄じゃんwwww まぁ、空港での暇つぶしに調べただけだからいいんですけどね。

[ ツッコミの受付は終了しています ]
1: のり (09/25 18:11)
検証ご苦労様です。かなり参考になりました。ありがとうございます。
Date 無しだと、元 xml(何)のフォーマット変更などを行うと恐ろしいことになったりするような気がして、元 xml に、初出の日付を示す <publish> というのと、あとで記事の修正をした日時を示す <update> なる語彙を追加導入したんですが、そこ等あたりとスキンの不備が相まって私のところではえらいことになってしまっていたようです。
現在は、極力 Date に頼らず、自前で持っている時間情報を使うように変更しています。が、最終更新日時あたりは、どこから引っ張ってくるかというあたりが解決できないので、$last_modified のお世話にならざるを得ないといった状態ですね。
この記事のリンク元 | 4 | 1 |

[Mozilla]

C Magazine 2005年10月号特集2 / 2005-09-22 (木)

C Magazine 2005年10月号(2005/09/17発売)の特集2「Firefoxのすべて」のPart1, Part3の執筆を担当しました。

きっかけ

最初はたしか6月にMozilla Japan兼もじら組のkambeさんと飲んでた時、C Magazineから依頼があるんだけどどうよ?って話が来ました。 その時は仕事が忙しく、またC/C++の知識が足りないだろう(さすがにポインタが理解できてないのはまずいでしょ)と思って執筆自体は無理だと返事をしました。 ちなみに、その段階でXUL自体の解説はあまり念頭に入れていなかったらしく、さらに推薦できる人がなかなか居ないねって話になりました。

それから数週間後、Mozilla Japan理事の瀧田さんから僕とゆきちさん宛てに誰か推薦できる人いませんか?とメールが来ました。 僕ら二人はXULの解説記事を含めるならPiroさんを推薦するとしましたが、ソース自体の解説する人がまだ居ませんでした。 これはまずい。せっかくのチャンスなのに。 その時ひらめきました。 今から勉強すりゃいいじゃん。 そんなわけで自薦の意思を伝えてから文字通りがんばりました。 ...そんな記事なんでちょっと危険かも(汗

はじめてのライター経験

Part1の方は現在ある自分の知識+αぐらいでほぼ中身を埋める事ができました。 まぁ、参考文献が絶版物だったりするのは気にしないでください。

Part3の方はものすごく苦労しました。 もともとMozillaのソースを読む事は学生時代にちょっとだけやってたんですが、 そもそもそんなのちゃんと覚えているわけもなく、ほとんど仕切り直しという感じでした。 ただ、インターフェイスの使い方、XPCOMの実装の仕方が頭の中に少し残ってて助かりました。 ディレクトリ配置なんかもばっちり覚えていたし、まぁ、長年使っていたから勘もかなり働いていましたし。 しかし、昔monyoさんに言われた「若いうちにコード読んでおかないとだめだよ」って言葉が今となってずーんと響いてきます。しくしく。

コードリーディング中はGNU GLOBALにとにかく頼り切りでした。 ソースツリーを静的なHTMLとして出力してくれるので、ひたすらコードを読むのが楽になります。 エディタと違って、読みたい関数をどんどんタブで開いていって、ある程度まとまったらタブを一式保存して名前を付ける。 そんな感じでグループ化していくと一つの流れの単位ができてすごく便利。 また、作業のほとんどがオフラインだったので、とにかく静的である事が個人的に重要でした。 とにかく惚れ込んで、導入の方法をコラムに書いてしまうほど(元々書く気だったけどね)。 ちなみにGNU GLOBAL自体は動的なHTMLもサポートしているようです。

全体的につらかったのはとにかく時間が取れない事。 いや、現実逃避の時間は除いてね。それが無かったら確実に何かを失ってるから(何) 執筆はほとんど会社の往復のバスの中で行いました。 ソースの検証のためビルドしたりとかするんですが、 それも寝る前にビルドかけて、帰宅後に検証していじってという感じでした。 また、土日が仕事でつぶれて記事が書けない週とかもありましたし、 本気で落とすかとがくがくぶるぶるしてました。 ふたを開けたら20ページ以上書いてて自分でびっくりしましたががが。

唯一の救いは、自分がMozillaに関われるという事に対する幸福感でしょうか。 ここ一年ほど仕事でMozillaの事をほっぽりすぎていて、 自分が組長である事の自信を失いかけていたんです。 今回の記事がきっかけで失いかけていたものを取り戻した気がしますし、 ひさびさにワクワク感を感じたり、 そのモチベーションがちょっと仕事にも影響がでてたりと、 まー、端的に言えば若返ったような感じ(ぉ ほんと良い体験をさせていただきました。

記事紹介

今回の記事は以下の構成になっております。

  1. Part1. Firefoxを理解する
  2. Part2. Firefoxのユーザインターフェイス
  3. Part3. ソースからみるFirefox

今回は自分が担当した部分を軽く紹介します。

Part1. Firefoxを理解する

Part1. ではMozilla Firefoxの簡単な説明、Mosaicからの歴史的な話、Firefox 1.5の紹介、XULの仕組みの簡単な紹介を行っています。 コラムには子(とネトランのふぉくす子)を紹介したりと、かなり暴走した感があります。 ちなみに、p 37のFirefox子の絵は、inugamixさんに書き下ろしていただいたC Magazineオリジナル絵だったりします。 ええ、ちゃんと依頼しました。 打ち合わせの段階で編集者の方と入れられるといいかもーみたいな話をしていたのですが、 実際に入ってしまうと... なんか、C Magazineの硬派なイメージががらがらと崩れているような気がしますw ってか、組長の暴走とかひどいなぁ。 共謀ですよ(ここ重要

Firefox 1.5の説明では、一つすでに情報が古くなっているものがあります。 サニタイズ機能は名前が変更になり、 Clear Private Data(個人情報消去)機能となりました。 Firefox 1.5のリリース予定は11月なので、8月の情報を元に書いているため他にも古くなる情報があるかもしれません。

XULの簡単な説明は Part.2とかぶるのを覚悟で書きました。 (Piroさんが僕の原稿見てからPart2書いたみたいなので、違和感はほとんど無かったです。ほっとしました) 友達から説明がすくねーとか言われたのですが、それはPart.2を見て勘弁してください(逃

Part.3 ソースからみたFirefox

Part.3 では一気に内容が濃くなります。 予備知識として、C/C++の構文ぐらいは把握してください。

Windowsでのビルド方法、インターフェイスとかのMozillaで使われている一般的な知識と入っていき、後はコードの説明。 コードの説明と言っても、起動時のコード、クロスプラットフォームの実現方法、インターフェイスの国際化関係と、あまりつっこんだ内容にはなっていません。 まぁ、つっこんだ内容なんて書けないですけどねw スタンスとしては、一般的なユーザがこれどうなってるの?って思うところを意識したのですが、はたして自分が一般的なユーザなのかが疑問です。 まぁ、忙しすぎて拡張も入れず、毎日見てるサイトは/.jpぐらいなんで、 一般ユーザ以下かもしれません(汗 とまぁ、なんか説明になってないですが、そんな内容です。 飾り文句とか苦手ですから(てへ

個人的に感じてほしいのは、起動時ですらJavascriptが主役級になるという事。 たぶん、C Magazineの読者層から、Javascriptという言語に対して、結構嫌悪感とかが強いと思う。 所詮Web用の言語でしょ?とか。 でも、Mozilla Firefoxではちゃんと主役になるっていう事、Javascript無くしてMozilla Firefoxを解読しようなんて100年早い(何)とか言いたい訳ですよ。 そういう意味でいい刺激になればなーと思います。

誤記、修正など

いちおう、このブログで誤記、修正などのサポートを行うつもりです。 ある程度溜まったらエントリーを作ろうかと思います。 今のところわかってるのは以下の部分です。

  • 表紙 - FireFoxと表記されていますが、Firefoxの間違いです。これ、日向さんにつっこまれて気づきました(汗
  • p 37 - IE が E になっています。IEには愛が足りないんですよ、きっと
  • p 39 - サニタイズ機能は現在Clear Private Data機能となっております

他ありましたら、教えていただくと助かります。

感想とか

宣伝しまくって結構いろんな人に見てもらいました。 中でも元上司でTlug元サブプレジデントのばびーには「Firefox使ってる人なら当然わかるでしょうみたいなくだり、全然わからんぞー」とおしかりをうけました。 たしかに、こういう書き方まずいですね。以後気をつけます。

あと、出版後にちょうど実家に帰ったので、両親や姉妹に見せたのですが、 母親から強烈な感想をいただきました。 「(最後の一文を読んで)ちゃんと社交辞令書けるようになったんだ」 母親は自分の息子をなんだと思ってるのでしょうかorz

そんなわけで何かご感想がありましたら、コメント等ください。

[ ツッコミの受付は終了しています ]
1: のり (09/22 11:58)
お疲れ様でした。
まだ読んでいませんが、なんとかゲットして読みたいです。近所に売ってないのよ。:p)
2: NPK (09/22 15:00)
立ち読みしました(買えよ)

Cマガジンの読者層でもJavaScriptに嫌悪感を持ってる人は一部じゃないですかねぇ?
今はAjaxとかもありますし、十分Cマガで特集できるレベルだと思いますよ。
3: Piro (09/22 15:44)
見本誌がまだ届かないわけだが……orz
4: おりゃ (09/25 17:09)
OSC2005前日に
ソフトバンクの編集者から10月号の見本誌をもらいました。
10ページ以上書いてますね。8ページ書くだけでも大変でした。
トラックバック (1)
この記事のリンク元 | 48 | 18 | 14 | 2 | 1 | 1 | 1 | 1 | 1 | 1 |

[OpenSource]

OpenSourceConference 2005 Tokyo/Fall / 2005-09-19 (月)

一昨日参加してきました。 睡眠時間がやっぱり少なくて結構テンション高かったです。 今回も楽しかったよー。

出展参加

もじら組として今回も出展参加をしました。 毎回毎回出展内容をどうするかすごく悩んでいたのですが、 今回はFirefox本のリリースラッシュという事で、 結構的が絞れた出展が出来たかと思います。 出展自体は次のような内容で行いました。

  • Firefox関連書籍の紹介
    • Firefox Hacks(オライリージャパン)
    • ブラウザ選択の時代を読み解く(オライリージャパン)
    • C Magazine 2005年10月号(ソフトバンクパブリッシング)
  • デモ機出展
    • ZetaOS版Firefox(Yellow TAB社提供)
    • iBook + Virtual PC上でWindows版Firefox
    • Windows版Firefox
    • iBookでプレゼンテーションオートデモ
  • ふぉくす子グッツ
    • ふぉくす子フィギュア(ネットランナー付録)
    • ふぉくす子Tシャツ(非売品)
    • ふぉくす子マウスパッド(非売品)
  • その他チラシやSpread Firefoxで見つけたフライヤー

出展ブースには甲府方旦那さん、pswfさん、Makotoさん、池田さん、そしてカズさんが参加してくれました。 カズさんは会うのはもう四年ぶり(!)。元気そうでなによりです。 また、Mozilla Japanの瀧田さん、日向さんが遊びにきてくれました。 両者には記事で大変お世話になったので、直接お礼が言えてよかったです。 あ、ぺんちゃんにはお礼言ってないな(汗 あと、後輩のhajimeにも多謝。 本屋が開く前にC Magazine貸してくれたり、本屋まで買いにいってもらったり、なんかパシリみたいな感じになってしまいました。 悪い先輩ですいません;;;

今まで、出展していて、よく「Mozilla って何?」という質問があったのだが、 今回はそれがまったくというほど無かった。 それどころか、どのブラウザ使ってます?って聞いて、かなりの人がFirefoxと答えて、 なんつーか、自分の知らない世界に居る気分でした。

ネットワークが入らなかったというトラブルもあり、ほとんど本や雑誌の紹介にしぼったので、ブースで混雑する事があまり無く、結構いい流れが作れたと思います。 また、下の階ではオライリージャパンが販売を行ってて結構な部数が売れてました。 甲府方さんがかなり大きな声で宣伝を行っていたおかげだと思います。

あと、今回はちゃんともじら組用名刺を作ってかなり存在感がアピールできたかと思います。 というかインパクトでは負ける気がしません。 インパクトがありすぎて、2Fのブースに四、五人ぐらい組長の名刺をつけた人が歩いていましたが(汗

ZetaOS 教室

kokiさんと友達だからというわけではなく、純粋にBeOSというものに興味があったので参加。 ZetaOSの初心者向けセッションという事で、他のOSには無い特徴、特に属性の解説とコンバータ(というかフィルタ?)の解説が中心でした。 属性機能は他OSでは使えないというのがちょっと残念な所だが、機能としてはすごく面白い。 Tracker(MacでいうFinder)とメーラの関係が結構面白いのだが、アプリ依存というのがちょっと厳しい所。 ThunderbirdでZetaOSの属性をサポートさせたら結構面白いのではないかなーとか妄想してみたり。

コンバータの説明はかなりビビりました。ビューアから範囲選択してそのままファイル作る流れなんてものすごくBeらしい何かを感じるもので、 これだけでZeta触ってなくて損した気分。 OCRフィルタなんて発狂ものですね。 具体的に言うと、PDFを開いたときに範囲選択をして、 Trackerにドラッグアンドドロップをすると、テキストファイルが出来上がるというもの。 PDFは画像のように扱われてしまうので、画像として一回取り出してOCRかましてテキストファイルにしているんです。 (もちろん画像のままひっぱってくる事もできます。) 当然、日本語は対応していませんが、OSとファイルそのものに対する考え方にいい刺激が来る機能で、まじで惚れます。

来月アップデートがリリースされてSATAに対応するようなので、 そのときはぜひ購入してみようかと思います。 あと、最後に気づきましたが、kokiさんずっと組長名刺つけたまま説明してた(汗 気に入りすぎですwww

OpenOffice.org BOF

みっしーに拉致されて何も聞かされずに参戦。 会場に来た奴全員しゃべれというもので、自分は無難に開発系の話とかしてました。それしかないんかとか思いましたが(汗

今回特に痛烈に響いたのが中田さんのフィードバックが無い話。 「Macにまったく興味がないのに、MacOSXのパッケージ作って提供しているんですが、まったくというほどフィードバックが無いんですよ」 ぐさ、ぐさぐさ。 俺、OOo MacOSX版のユーザーです。中田さんのパッケージ使ってます。フィードバックした事無いorz 快適に使わせていただいてる身として、申し訳ない気持ちでいっぱいです。しくしく。

懇親会

乾杯の音頭を取らせていただきました。 しっかり外しました(げらげら いや、本番に弱いんだって(汗

会場内ではタバコ仲間を作って話しまくったり、 hajimeを連れ回していろんな人に挨拶させたり。 特にYLUGのカーネル読書会に参加してかなり感動したらしいので、そこらへんの人には若いのがいるよーと宣伝してみたり。 自分も若いときはいろんな人に紹介してもらったので、今度は自分が紹介できるというのがすごくうれしかった。 あと、びっくりしたのが大学のOBを発見。まぁ、理系の大学だから居ても当たり前だとは思うけど、前から話してた人が実はってパターンは一番びっくりする。 まぁ、学部違うので関係ないんですけどね(とかいう どうせ我らは埼玉の田舎の引きこもりですよ(何

あと、CSSの話で盛り上がったのもうれしかった。 HTMLベースで帳票を作るときに、印刷時のコンボボックスの表現の仕方には問題は無いだろうかって話で、 コンボボックスは中身を展開しないと他の答えが見えないのに、印刷するときは選択した物だけを印刷してしまい、 アンケート等を印刷するときに問題にならないかという事。 印刷物を受け取ったときに答えのリストを知っている必要があるので、単体の印刷物として機能しないというのが問題で、 コンボボックスの中身がちゃんと一覧出ててきていればちゃんと機能するよねって。 で、それをCSSで印刷用にリスト表示をサポートできれば幸せになれるだろうなーって。 実際に話をしてくださった方は、災害時のアンケートとかでWEBを使ったシステムとかを考えていて、この問題を認識したとの事。 あまりにその話が面白かったので、可知さんとこに連れて行ってみんなで提案するプロセスを考えたりとかして、めちゃくちゃ面白かった。 例えばOOoでフォームを使って帳票を作るときにそういうレイアウトで印刷できて、でもXSLTかましたらそっちでは出来ないとかだと不便になるし、 そもそもそういうレイアウトが使えるってW3Cに証明するのにOOoも巻き込めないだろうかとか他のコミュニティーを巻き込んだ形で提案とかなんかすごくねーみたいな何かが(一人興奮しすぎ) ってなわけで久々にこんな話ができていろんなうっぷんを晴らしたわけです(何) あー、楽しかった。

二次会@びぎねっと

いつものルートですね(w 酒買い込んで会議室で今日のイベントの内容見たり、DVD見たりゲームやったり。 sakusakuすげーなぁ(謎 OOoの人たちと話してるとやっぱりアレ(謎)の話になり、事情を知らないhajimeにMLのアーカイブ見せてありえねーとか言わせてみたり(謎 モノポリーは遠くから見ていたのだが、空気の読めないみっしーが大勝ちをしていたようで、誰か諭せよとか思いつつ床に就寝。 朝起きたら人が全然いなくてびっくりしましたwww

[ ツッコミの受付は終了しています ]
1: Piro (09/20 12:00)
いいなあ。たのしそうだなあ。
2: catch (09/21 16:20)
いろいろお楽しみ頂けて、何よりでございます(^^
また、やりましょう。
3: hiroya (09/22 21:41)
お話させていただいた,くぼ@SQSです(TrackBackさせていただきました).
OSC2005Tokyoは,参加してよかった…とココロから思うようなイベントでした.
また,よろしくお願いします.
トラックバック (1)
この記事のリンク元 | 7 | 7 | 3 | 1 | 1 |

[Mozilla]

EcmaScript for XML(1) / 2005-09-06 (火)

DeerPark Alpha1からEcmaScript for XML(E4X)がサポートされました。 DeerParkが出たときあたりからちょくちょく触っていたのでものすごく今更感がありますが、まぁ、ネタないのでレポートを。

EcmaScript for XML(以下E4X)はEcmaで現在ドラフト状態になっているEcmaScriptの言語仕様の一つです。 特徴はその名が表すようにXMLの処理が従来のDOMに比べて格段に簡単に行えるようになっているという点です。

まず、適当なXMLファイルとそれを処理するDOMを考えてみましょう。

      <company>
	<employee id="taro">
	  <name>
	    Taro Matsuzawa
	  </name>
	  <age>
	    24
	  </age>
	</employee>
	<employee id="jiro">
	  <name>
	    Jiro Yoshioka
	  </name>
	  <age>
	    32
	  </age>
	</employee>
      </company>
    

上記のようなXMLがあり、 "$name さん、$age 歳" という文字列をemployeeの数だけ作りたいとします。 DOMを使うと以下のようなコードになります。

      var docs = ...; //(XMLをDOM Objectへ)
      var str = "";
      for (var employee in docs.getElementsByTagName("employee")) {
        var name = employee.getElementsByTagName("name").item(0).firstChild.nodeValue;
        var age = employee.getElementsByTagName("age").item(0).firstChild.nodeValue;
        str = str + name + " さん、" + age + " 歳";
      }
      ...
    

こんな感じになります。 では同じ様な記述をE4Xで行ってみましょう。

      var docs = new XML(...); //XML
      var str = "";
      for each(var p in docs..employee) {
        str = str + p.name + " さん、" + p.age + " 歳";
      }
      ...
    

見ての通り、ものすごくシンプルになりました。(そもそも変数名短くするなよとかいう突っ込みはなしね) でも、シンプルすぎてなにがなんだかわかりません(w

とりあえず解説はまた今度という事で、簡単なサンプルを2つほどこしらえました。 適当にソース読んでほほーとか思ってください(逃げ

[ ツッコミの受付は終了しています ]
この記事のリンク元 | 3 | 1 |

[Mozilla]

xulアプリをantでビルドしてみる / 2005-09-04 (日)

ずっとやりたかったXULアプリのant対応。 実に構想二年というかなんでいままでやってなかったんだってネタですががが。 まぁ、デスマ終了記念って事で。

たぶん、のりさんあたりからantってなんだい?って質問が来そうなんであらかじめ答えておこう(ぉぃ antはApache Foundationが提供しているビルドツールで、 javaで動作するためプラットフォームに依存していないという特徴があります。 (javaが動かないプラットフォームはあるけどね) 何がいいかって、Makefileよりも見通しがよい(主観)のと、 makeではzipコマンドとか自前で用意しないといけないので、 antの方が負担が少ないと思われるからです。

今回のターゲットは一年ぐらい放置プレイをかましているCupRamenTimerです。 なんで扱うかというと、そろそろメンテナンスしようと思っているからです。 すげー自己中心的ですね(わら

手順は以下のようになります。

  1. ソースコードのツリーを用意する。今回はxpiファイルを解答して用意します。
  2. build.xmlを作る。
  3. antを実行。

ではまずソースコードのツリーを用意します。 cuptimer-0.7.xpi(2005/09/04 修正、全然違うバージョンを指してました) を適当なディレクトリに解凍し、 出てきたディレクトリのchromeディレクトリに入り、 中にある cuptimer.jar を同じディレクトリへ解凍します。 これで次のような状態になるはずです。

  • /chrome
    • /content
    • /locale
    • /skin
    • cuptimer.jar
  • install.js
  • install.rdf

次にソースツリーのトップ(install.rdfとかがある場所)にbuild.xmlを作成します。まずは次の例を見てください。

<?xml version="1.0"?> 
<project name="xul-cuptimer" default="all" basedir=".">
    <description>XUL CupRamenTimer</description>
    
    <property name="build.path" location="build" />
    <property name="build.chrome.path" location="build/chrome" />
    <property name="chrome.path" location="chrome" />
    
    <property name="jar.file" value="cuptimer.jar" />
    <property name="xpi.file" value="cuptimer.xpi" />
    
    <target name="clean">
        <delete dir="${build.path}" />
        <mkdir dir="${build.path}" />
        <mkdir dir="${build.path}/chrome" />
    </target>
    
    <target name="locale">
        <native2ascii src="${chrome.path}" dest="${chrome.path}"
            encoding="EUC_JP" includes="**/*.properties.euc" ext="" />
    </target>
    
    <target name="makejar" depends="locale">
        <zip destfile="${build.chrome.path}/${jar.file}" basedir="${chrome.path}" 
            excludes="*.jar **/*.*~ **/*.properties.euc" />
    </target>
    
    <target name="makexpi" depends="makejar">
        <copy todir="${build.path}">
            <fileset dir="." includes="*.js" />
            <fileset dir="." includes="*.rdf" />
        </copy>
        <zip destfile="./${xpi.file}" basedir="${build.path}" />
    </target>
    <target name="all" depends="clean, makexpi" />
</project>
    

あとはbuild.xmlがあるディレクトリでantを実行します。

$ ant
    

ではbuild.xmlの説明をしましょう。 まず2行目のprojectではプロジェクトの名前(name)、ベースとなるディレクトリ(basedir)、そして標準で動作するターゲット(default)を指定します。 今回はdefaultで"all"を指定しているので、単純にantを実行した場合"all"ターゲットが実行される事になります。 3行目以降では、プロジェクトの内容と、プロパティの設定が数行あります。 propertyタグでは名称(name)をキーにファイルやディレクトリに位置(location)や任意の値(value)を与える事ができます。 propertyタグで指定したものは、${hoge} という形で参照する事ができます。

targetタグは一つの作業セットを構築するものです。 今回のbuild.xmlでは"clean"、"locale"、"makejar"、"makexpi"、"all"のターゲットがあります。

"clean"ターゲットではビルド用のディレクトリ(./build)を削除と作成を行います。 作業用のディレクトリを作る事で、実際のソースツリーを汚さないようにしています。

"locale"ターゲットではnative2asciiコマンドを実行し、propertiesファイルのエンコードをしています。 includesで **/*.properties.euc と指定しているのは、native2asciiの対象を明確にするためです。 今回のツリーには chrome/locale/ja-JP/cuptimer.properties.euc というファイルがあるので、このファイルだけがnative2asciiにかけられ、cuptimer.propertiesを上書きします。 ちなみに、native2asciiは最近のMozilla/Firefoxでは必要ないらしいのですが、確認取ってないのでこのまんま行きます。動くし。

"makejar"ターゲットではchrome以下のファイルをzipで固めてbuild/chrome/cuptimer.jar として配置させます。 destfileはファイルの出力先を、basedirは固める対象のディレクトリを指します。 excludesでは逆にjarファイルに含めたくないファイルを指定しています。 ここでは *.jar (jarファイルをjarファイルに含めても意味がない)、 **/*.*~ (emacsが作成するバックアップファイル)、 **/*.properties.euc (エンコードする前のファイル)をそれぞれ外しています。 あともう一点 depends というのを指定しているのに注目してください。 これはターゲットの依存関係を示しており、 "makejar"ターゲットが実行されると先に"locale"ターゲットが実行される事になります。 なぜならjarファイルを作る前にnative2asciiを実行しなければ、 正しい.propertiesファイルをjarファイルに含める事ができないからです。

"makexpi"ターゲットでは単にinstall.jsとinstall.rdfをビルド用ディレクトリにコピーし、 そのディレクトリをまるごとzipで固めてxpiファイルを作成します。 また、このターゲットは"makejar"に依存していると記述されています。 そりゃ先にjarファイル作っておかなきゃ元も子もないですからね。

最後の"all"ターゲットは依存関係だけを記述したターゲットです。 antをターゲットの指定なしに実行した場合は、"clean"と"makexpi"を順番に実行します。 "makexpi"は"makejar"に依存し、"makejar"は"locale"に依存しているので、結局のところ"all"はすべてのターゲットを実行する事になります。

以上でantの解説は終わりです。 たいした事は無いのですが、手作業でやるとどうしても固めるのにミスがあったり、よけいな物まで含めてしまったりして結構面倒だったんです。 KENZたんあたりはMakefileを作っていたようですが、 windowsな環境だと構築がやや面倒かなと思って、 わりとどこでも使えるだろうという意味でもantで作るのは意味があるかと思います。 まーライセンスがらみで使いづらい環境もあるかもしれませんが(汗

[ ツッコミの受付は終了しています ]
トラックバック (1)
この記事のリンク元 | 63 | 2 | 1 | 1 | 1 | 1 | 1 |