Leo's Chronicle

以前、「Leo's Chronicle: Fat Jar: Jarファイルの中にJarを埋め込む」で、JavaでFatJar plug-inを使って、Jarファイルの中にJarを埋め込む使う方法を紹介したのですが、最近は事情が変わってきています。

たとえば、Eclipse3.4からは、Runnable Jarの作成がサポートされ、依存関係にあるすべてのJARファイルの中身を展開して、1つのJARにまとめてくれる機能が標準装備だったり、Mavenユーザーなら、assembly pluginを使って、jar-with-dependenciesを指定する方法もあります。

ぱっと試したいなら、Runnable Jarを作成するのが速くて楽。このようなJARを頻繁に作成するなら、Mavenのassemblyで書いてしまうのが良いです。

関連記事：JARファイルの作成方法

三浦しをんさんのブログを眺めていたところ、彼女の原稿ファイルが壊れてしまったという話がありました。小説家にはとっても痛い話でしょう。そんな悲劇を少しでも防ぐために、ファイルの変更履歴を管理するためのシステムSubversionについて、以前に僕が書いた簡単な使い方のページを紹介します。

http://www.xerial.org/trac/Xerial/wiki/Subversion

情報系学生向けの内容なので、英語で、しかもコマンド入力形式を前提に書いているので、一般のパソコン利用者には読んで理解するのは大変かと思うのですが、こういうものがあるんだよということをぜひ知ってもらいたいです。

Windowsなら、TortoiseSVNという、マウスクリックで使えるSubversionもあるので、こちらをインストールして使ってください。

簡単な概念の説明

• 適当な位置に、リポジトリ(repository)と呼ばれるものを作ります。これは、あなたのファイルとその変更履歴を保存するデータベースのようなものです。
• 普段の執筆作業、ファイルの編集等は、ワーキングコピー(working copy)と呼ばれる、リポジトリの中身のコピーに対して行います。ワーキングコピー内のファイルをいくら編集したり、削除しようと、リポジトリには影響を与えません。
• ワーキングコピーを作成するには、まず、チェックアウト(checkout)という操作を行い、リポジトリからあなたのファイルのコピーを取り出します。
  
• ワーキングコピー上のファイルの編集結果を、リポジトリに反映させてもいいと判断したら、コミット(commit)と呼ばれる操作を行い、ワーキングコピー上での編集内容を、リポジトリに送ります。
• ワーキングコピー上の新しいファイルは、自分でリポジトリに追加(add)する、と選択しない限り、リポジトリには送られません。
• リポジトリには、コミットする前と後のファイルの内容がすべて記録されています。従って、一ヶ月前の原稿を取り出したい、という要求にもこたえることができます。1回のコミットごとに、リビジョン(revision)の番号が更新されていきます。
  
• ファイルを元に戻したい、というときには、リポジトリから復元(revert)操作を行います。誤って消してしまったファイルや、修正結果などを元に（リポジトリに保存されている状態に）戻せます。
  
• 定期的にリポジトリのエクスポート(export)を行って、最新の状態のファイルのバックアップをDVDなどの外部メディアに保存しておくと良いでしょう。更新履歴を含めたリポジトリ全体のバックアップが必要なときは、svnadmin dumpコマンドを使えるように設定する必要があります（詳細は公式ページや、onlineのsubversion解説書で）。

（サーバーに設置するとき）

• リポジトリは、Webサーバー上に作成するといたるところで自分のファイルにアクセスできるようになるので、利便性が高まります（Apache + mod_dav_svnなど）。あるいは、sshログインできるサーバー上に、リポジトリを作っておくと設定要らずで簡単です（svn+ssh://(server address)/home/leo/svn/repository というようなURLでアクセスできる）。
• Webサーバーなんて設置できない、という人は、最近はUSBメモリが大容量化しているので、こちらにリポジトリを作成してもよいのかもしれません。ただ、盗難、紛失によってデータを失うリスクが高いので、あまりお勧めできません。
  
• 複数の人（自分一人の場合でも、自宅、会社のPCなど）のコミット後の更新結果を手元のワーキングコピーに反映させるには、更新(update)を実行します。自宅と会社で同じファイルを編集してしまった場合は、コミットや、更新を行ったときに警告が出されます。両者の変更を簡単に合成(G: merGed)できるときもありますが、そうでないときはC（Conflict）マークが出ます。その際は、手作業で更新がぶつかった箇所を編集して、conflict resolvedという操作を行わないと、そのファイルはコミットできなくなります。人の更新結果を使って、手元の更新結果を無視して上書き、なんてこともできます。

何箇所かのPCにワーキングコピーが残っていれば、いざリポジトリが入っているディスクが故障したときでも、ワーキングコピーから新しいリポジトリを作ればいいだけなので、完全ではないとは言え、ラフなバックアップ効果があります。

文章やプログラムを書くという作業は、もうSubversionがないと怖くてできません。でも、世の中の大半の人は、まだこの恩恵にあずかれていないのかと思うと、少し悲しくなってきます。リポジトリの置き場所、バージョン管理って何？という面で、やや敷居が高いのですが、 あなたの大切な「パートナー」のことですので、真剣に考えてあげてくださいね。

Leo's Chronicle: SQLite JDBC Driver

本家のsqlitejdbcドライバーがupdateされていたので、こちらもv038 (sqlite3.5.4)に対応させました。
http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC

ちょっとした改善点は、jarファイルから抽出した*.dll等のファイルを、目立たない場所に置くようにした、という点。SWT3.3から導入されたテクニックと一緒ですね。Win, Linux, Macに完全対応なので、動作が極端に遅くなるPure Java版を敢えて使う必要がなくなると思います。

ライセンスもApache License 2.0に対応させました。ビジネス、私用、共に自由に使えます。時間ができたときに、本家を完全に取り込むとよいかなぁ。僕的に、これはあまり優先度は高くないけれど。

OSごとにpackageを作って、v037, v038を別々にreleaseする作業って、mavenを使っていると、わりと楽にできます。ただ、いつも思うことですが、必ずしも「便利になる」イコール「楽になる」ということではないんですよね。

便利になるということは、仕事の敷居が低くなるということ。つまり、できることが増えるわけえす。そうすると、今までやろうともしなかったことをすることになるので、仕事量はあまり変わりません。mavenの仕組みを学んで、慣れるまでに、相当の時間を費やしているので、結果として、まったく楽にはなっていないです。

次にどれだけプロジェクトを作るか次第で、ここで払った勉強コストが有益かどうかが変わります。たぶんプロジェクトは、今後どんどん増えていくのですが、そうとわかっていても、苦労するのは今なわけですから、長期的な価値判断に基づいて行動するのは、人間にはなかなか難しいものですね。

「喉もと過ぎれば熱さを忘れる」　ということわざにもありますが、後になって、初期の投資がどれだけ大変だったか評価するのも難しい。さてさて。

sshでサーバーをいくつか経由して、目的のサーバーに接続する方法です。

sshで、server(Bとする)に接続したいけれど、severBは、serverAを経由しないとアクセスできない位置に設置されているとします。

　　localhost -> serverA -> serverB

ssh serverA ssh serverB

と実行すれば一応接続できるのですが、ssh (remote host) (command ...)という構文で、コマンドを実行するだけなので、serverBにログインした後、すぐconnectionが切断されてしまいます。

rsyncなどは、この形式でも、以下のように使えば、serverBのデータを取得できます。

rsync -av -e 'ssh serverA ssh' serverB:./(src) (dest)

本題のsshですが、

ssh -t serverA ssh serverB

とすると、仮想ttyを作ってくれて、serverBにログイン後、shellでの作業を続けられます。

sshのkey agentを使う設定にしておけば、パスワード認証要らずで、サーバーをどんどん経由して、ログインできるようになります。

Eclipseでsubversion plug-in (Subclipse)を使っていると、日本語のメニューになったり、$Date$タグの置換が、日本語の日付（何月何日、何曜日）などとなってしまって、英語中心の開発では、困ることが多いです。

localeの設定は、実は、
> eclipse.exe -nl "en_US"
というコマンドラインオプションでできることを発見。これでメニューが全部英語になって、和訳や誤訳などに惑わされないですみます。

日本語で書かれたプログラミング言語の解説書やマニュアルが何故分かりにくいかというと、英語で書かれている用語や概念が、それと１対１に対応しない日本語に訳されているという点。

最初から全部日本語なら、問題ないのだけれど、日本語の文書はたいてい後発だし、上手に訳せて、かつ技術に明るい人なんて、そうはいないだろうから、開発環境は全部英語にするのが実は、労力が少ないのです。

この組み合わせ、とってもいいです。

僕は、ブラウザ用のブックマークは既に100％del.icio.us（Web上で管理されるブックマーク）を使っています。この内容を、QuickSilver (キーボードで操作できるMacのコマンドランチャー）から呼び出す方法がわかりました。

Social Bookmark plug-inというのがあって、それを使うと、Catalogに、del.icio.usの内容を登録できるようになります。

好きなページを開くのに、Tagとかページの名前の断片を入力するだけで良くなりました。こういう機能があると、パソコンを使いこなしている気分になれます。

データベースもこの感覚で使えるようにしたいなぁ。
僕は、そういう研究をしています。

写真の画像を一括変換してPDFにするとします。ImageMagickを使って、例えばデジカメで取った写真photo1.jpg, photo2.jpg, ..., photo10.jpgのコントラストを上げて、色を調整して、１つのPDFファイルにするコマンドは以下の通り：

> convert -adjoin -sigmoidal-contrast 3,0% -normalize photo<1-10>.jpg out.pdf

convert -thumbnail 100 'out.pdf[5]'
なんて書き方で、pdfの６ページ目（0 origin)だけを取り出してthumbnailをつくるなんてこともできます。

Fat Jar Eclipse Plug-In

Javaで開発していて、他のライブラリのアーカイブ(Jar)を使っている場合、自分のプログラムもJarとして配布するときに、manifestファイルに適切に外部のJarへのreferenceを書いておかないと正しく動作しません。

通常は、classpathの設定を含めた実行スクリプトを一緒に配布することが多いみたいです。でも、スクリプトを用意するのは面倒ですよね。

そんな煩わしさを取り除くのが、Fat Jar。Jarの中にJarファイルを埋め込んでプロジェクト全体を１つのファイルとすることができます。

Fat Jarは、通常は、外部で参照しているJarを展開してJarの中に埋め込むのですが、One-Jarオプションを選ぶと、jarファイルを展開せずにそのままjarの中に埋め込みます。こちらの方が、構成内容がよくわかります。

Fat Jarを使うと、今まで、
java -cp lib/somelibrary.jar -jar myprogram.jar
などとしていたところを、

java -jar myprogram.jar

と実行するだけでよくなります。意外と知らない人がいると思うので、紹介しました。おすすめです。

最近はJARの作り方も事情が変わっています。2008年８月 http://leoclock.blogspot.com/2008/08/jarjar.html

僕自身、文書作成には、プログラマ御用達のEmacs (Meadow)を使ってテキストを作成することがほとんどなのですが、見た目にスタイリッシュな文章を作成しなくてはいけないこともあります。

ただ、一般に使われるMicrosoft Office製品は、英語を書くときには文法間違いやスペルミスを発見してくれて強力なツールなのですが、日本語文書を作成するときには、ソフトウェアの価格ほどメリットを感じないことが多いです。それでも、周りのみんなが使っているから、自分も使わなくてはという強迫めいたものがあります。重要な事務書類をWord/Excelで作成してください、ということが多く、使わざるをえないのです。

以前、ＮＨＫの特集で、官公庁がMicrosoft OfficeとWindowsから、コスト削減のため無料でまかなえるOpenOfficeとLinuxに乗り換えようとしているという話がありました。 でも、既存の文書のレイアウトが崩れてしまうなどの理由で、Windowsマシンも残しているとか。

特定のOSを選ぶ理由は、やはりアプリケーションにあります。今まで使えたアプリケーションが使えなくなるなら、それを上回る新しい魅力がないと、OSを切り替える気も起きません。

つまり、もうひとつ重要な観点があって、データを何年残しておくか？ということ考える必要があります。Microsoftは財務体力を得た会社だから、Vistaの普及が思うように進まなくて失敗したとしても、数年でつぶれるような会社ではないです。だから、Office製品が突如死に絶えてOfficeのデータが使えなくなることはないでしょう。でも、SunのCEOであるJonathan Schwaltz氏が指摘しているように、Web上で使えるGoogle Docsや、フリーのOpen Officeのように他に魅力的な文書作成ソフトが出てきたときに、Open Document Format (ODF)のような公開されている仕様で、文章を作成しておくと切り替えがスムーズにできます。OSが代わってもデータを生かしておくことができるのです。

スタイル（自分で登録したデザイン）を作成できて、アウトラインを作成できるという意味では、もう、無料のOpenOfficeでも、Wordと同等、あるいはそれ以上の機能が備わっていて、問題なく使用できます。PDFに変換することもできるので、PDF形式で相手に渡せば、Wordや OpenOfficeをインストールしてなくてもメッセージを伝えることができます。プレゼンテーション資料も、Open Office Impressで、見た目に遜色のないもの作れるので、PowerPointいらずです。今の段階では、PowerPointの方が動作が軽いのですが、スライドをPDFに変換してAcrobatでプレゼンすれば、動作も軽快ですし、ＯＳ依存部分を減らせるので、配布するときも喜ばれます。

MacOS Xでは、X上で動作するOpenOfficeを使うより、NeoOfficeを使うほうが動作が快適なようです。1万円を払う気があるなら、iWorkを購入して、PagesやKeynoteを使う方が最初から見た目のよいものが作れるし快適です。ただ、こちらは残念ながらODFには対応していないし、連携する表計算やデータベースソフトがないので、OpenOffice/NeoOffice、あるいはMicrosoft Excel, Accessのお世話になります。PDFやRTF(rich text format), Word形式の文書は作成できるんですけど。

表計算に関しては、簡単な計算式が書けて、ピボットテーブルが作成できればいいと思うのですが、それも、Excel, Open Office Calcのどちらでもできるようになりました。

ただ、Excelが断然優れているのは、グラフ作成機能でしょう。世の中には、グラフを作成する無料のツール（GnuPlotなど）もありますが、使いこなすまでの労力を考えるとExcelに軍配が上がってしまうのは残念。MacのPagesもなかなかきれいなグラフは作れます。

僕のパソコンの活用法を少し紹介。一般の利用者向けです。

最近、毎日持ち歩いても苦にならない大きさのノートブックＰＣが手軽に買えるようになりました。Windows XPはHome Editionでいいやとか（リモートデスクトップの機能が使えないですが、大きな違いはそれだけかも）、Office製品はいらないなどとあれこれ切り詰めてカスタマイズすると、20万円以下でも十分実用的なマシンになります。昨年にそういった構成でVAIOのType-Tを購入しました。液晶の解像度も高く、バッテリーの持ちも良い（７～９時間）のでかなり重宝しています。

そんなノートパソコンを、僕は、電子書籍代わりに使っています。デジカメで本を1ページ毎に撮影して、画像ファイルをまとめてPDFにしてしまいます。（Adobe Acrobatを使うと簡単ですが、画像をアルバムのようにPDFにするだけなら他にもいろいろツールがあるようです。） スキャナとかも試してみたのですが、デジカメの方が本のサイズにかかわらず撮れるし、１ページあたりに費やす時間が数秒で済むので、速いです。GoogleのPicasaなどの写真編集ソフトで紙の色などを調整すると良いかもしれません。PDF文書を読むときは、Acrobat Reader(こちらは無料）のショートカットキーを覚えると吉です。

Ctrl + 1, 2, ... ページの表示方法の切り替え
Ctrl + +(プラス）、-(マイナス） で、ページの拡大縮小。
Ctrl + L (全画面表示）

などなど。気が向いたときに本を撮影して、必要なときにじっくり読めるように持ち歩いています。職業柄分厚い本を読むことが多いので、本当に助かっています。


本当はもう１つ、ファイルのバージョン管理ソフト、Subversionについても書きたいのですが、とてもブログ１つに収まる内容ではないのが辛いところ。もはや僕のＰＣ作業に欠かせないものになっています。USBメモリでも使えるはずなので、あまりパソコンに詳しくない人でも使いこなせるんじゃないかと思っています。その話題はまた後日。

Meadow3を導入するとウィンドウをMacのCarbon Emacsのように半透明にできると知って早速試してみました。動作速度もさほど落ちないし、満足のいく結果。rxvtのようなシェルも半透明にできるともっと快適なんだけどな。

開発者として一番がっかりしているのは、EclipseのMac版がどうにも洗練されていないこと。フォントも思ったように指定できないし、半透明色が使えなくてMacらしさがでなかったり…。なにより、動作がやや重い。Boot Campで、別パーティションのWindowsからEclipseを使っている分には、そのような不快さは感じないので、まだEclipseのコミュニティがMac版の開発に力をいれていないのかと思います。　

逆にすごいと感じたのは、OS自体の言語環境切り換えがスムーズなこと。普段英語圏のアプリケーションを使用することが多いので、OSのインターフェースを英語に切り替えたくなったりするのですが、 Windowsでは英語版をインストールしなくてはいけないのと違って、Macでは設定一つで瞬時に使用言語を切り替えることができます。過去の遺産をあまり引きずっていないから、最初から他言語に対応できるようにするなど、柔軟な設計ができているのかもしれませんね。

このブログに使っているBlogger がupdateされました。更新が反映されるまで時間がかかったりと、やや不安定なのですが、レイアウトの変更などCSS を触らずにできるようになったので便利になりました。ようやくブログにタグもつけられるようになりました。これで、一通りの機能はそろったのかな。

いろいろためしてみたけれど、どうやら、TeXで論文を作成するときは、PDF形式でpreviewするのが最速のようです(Windows環境において）。

こんな発見があったのも、今まで使っていたMikTexのYap(DVI viewer)が、最新版のものでは過去のものより処理が遅くなってしまって、版を確認するのに時間がかかるようになってしまったから。

texを書いてはdvi形式で確認していたところを、代わりにPDFを生成するようにしたら、かなり快適になりました。キー１つでtexをコンパイルして、PDFを一発表示できます。

ポイントは、

• pdflatexで、texからpdfの生成
• pdflatexはeps形式の画像ファイルを扱えないので、epstopdfを使うか、distill（角藤さん作成）でコマンドラインからAcrobat Distillerを呼び出して、eps->pdfへの変換をする
• というか、画像は最初からPDF形式で作ればいい
• eps、pdfの画像形式を両刀で使えるようにするには、\includegraphics{filename} と書けば、latexのときはfilename.epsが、pdflatexのときはfilename.pdfが読まれます。
• Acrobat Readerは、ファイルを開くとロックしてしまうので、pdfopen, pdfcloseコマンドでpdfファイルの開け閉めをする
• pdflatex, bibtex, pdflatex, pdflatexというサイクルを1度実行したら、次回は、pdflatex一回で済ませる
  
• これらの作業をまとめて行うMakefileを書く
• PDFを閉じる - pdflatex - PDFを開く
• 以前見ていたページに戻るために、Acrobat Readerの方で、以前表示したページを開く、という設定にする
• Emacsを使っているなら、smart-compile.elなどを活用して、makeコマンドを簡単に呼び出せるようにする。
• TexnicCenterなどを使うともっと簡単に、使用するコマンドの定義ができるでしょう。

tex file -> latex -> dvipdfm -> PDF fileという流れ（10秒以上はかかるかも）よりは、もちろん高速。2秒くらいでPDFを表示できます（数十ページの文章なら）。ただし、dvipidfmを使ったほうがコンパクトなPDFができます。

これでWISYWIG(What You See is What You Get)でないTeXの欠点が補えます。dvioutやyapは、画像の表示が遅いし、gsviewはPDFも表示できるけれど、viewew自体があまり使いやすくないのです。

長年の悩みの種がようやく解決して、とっても快適になりました。おすすめの方法です。

Leo's Chronicle: Ruby on Rails 30分 Hacking の日時、会場が決まりました。

Seminar: Ruby on Rails 30 分 Hacking
日時 平成 18 年 6月６日（火）午後 4 時 30 分～
場所 東京大学本郷キャンパス 理学部 7 号館 102 室

どのような人が集まってくるのかな。まぁ、頑張ります。

Official Google Blog: Picture this: Picasa for Linux

とっても快適に使える写真管理ソフトPicasaのLinux版が公開されているようです。

でも、それよりも、WINEというソフトウェアの存在の方が驚き。WindowsアプリケーションをLinuxで動作させるためのlayer(program loader)なのですが、プロジェクトは1993年（！）から続いているようです。

VMWareで仮想OSを走らせるのも手ですが、これでExcelやPowerPointなどをLinuxで動作させられるようなので、楽しいですね。