Code readers daily

リンク: http://andymatuschak.org/articles/2008/05/07/more-on-launchpad-bazaar-vs-lighthouse-github/

最近、gpxviewerというアプリケーションをいじっている。これは、GPXファイルの管理を行う上で、容易に地図上でどこをトレースした物かを表示してくれる。
Python + GTKでかかれており、小さく、最低限必要な機能を満たしている。
多数のGPXファイルがあると、JOSMで開いて確認していくのでは、少々手間がかかりすぎる。また、できればファイル管理ソフトウエア(nautilus) から簡単に起動できた方がいい。

これは、まだリリースして日が浅く、コードベースも小さいので、こういった用途に向けて改良するには、ちょうどよかった。
わたしの改良点は、Githubリポジトリにおいてある。すでに、作者にパッチを送っており、gpxviewer on launchpadから最新のコードを入手できる。
５月に入ってから、７つのコミットに関わる貢献をしている。

さて、作者のAndrew Geeさんからは、BazaarをつかってLaunchpadにブランチを開いてくれ。そしたら、マージもレビューも簡単だ、といわれている。たしかに、bazaarを使ってlaunchpad からコードを入手して開発しているが、bazaarはその使い勝手が気持ち悪くて、git-bzrをつかって、(たとえば、git-bzrの使いかた),gitにインポートして開発し、ブランチの歴史をきれいにしてから、git format-patchを用いてパッチを生成して送っている。送ったパッチをそのままインポートしてくれれば、リポジトリに取り込むときに面倒はないのだけれども、Andrewは（bzrにそんな機能はないのかもしれないが）、パッチをあてて適当なコメントをつけてupstreamにマージをするので、パッチを送った後は、upstreamの最新から再度ブランチを切って作業をする羽目になる。

そもそも、プロジェクトのオーナーがlaunchpad+bazaarを使っているのだから、選択するのはオーナーだ。それに不満はない。けど、開発する方は、使いたい奴を使いたいではないか。

閑話休題

その選択にあたっても、プロジェクトオーナーは、pros/consがあって悩ましいはず。launchpadのサイトとしての機能はすばらしいが、bazaarよりgitのほうが使いやすいじゃん。という悩みをこの記事では吐露してくれているのである。

リンク: http://www.informit.com/store/product.aspx?isbn=0131492470

「実践デバッグ　技法」を眺めていて、改めて「DEBUG HACKS」を眺めていたところ、書棚に標記の「Linux(R) Debugging and Performance Tuning」が転がっていることに気がついた。本書は、大学院でのOSの授業で、参考書として紹介したことがある。

1. Bottleneck identification
2. Code coverage
3. Debuggers: gdb, kgdb, and KDB
4. Memory management
5. /proc kernel data analysis
6. System process monitoring
7. Network performance
8. Oops bug messages
9. Syslog and event logging
10. Execution traces
11. Profiling kernel behavior
12. Cache misses
13. User-Mode Linux
14. Dynamic probes
15. Crash dump analysis

といった内容で、ユーザプログラムとカーネルとバランスよく取り上げている。

• gprof, kprof
• gdb,ddd, insight
• electric fence, valgrind
• ps,pgrep,top,strace,lsof,tcpdump,ethereal
• syslogd,ksyslog,
• ksymoops,LTT,oprofile,crash,UML
• Kprobe,Dprobe
• kgdb,kdb,LKCD,NetDump,diskdump

など、幅広く網羅している。2005年の出版時点では、この網羅状況はすごいとおもう。現在であれば、
LKCD,NetDumpの代わりに、kexec/Kdumpははずせないし、Kprobeではなく、SystemTAPにふれたいところ。でも、このような内容では、事例ベースの「DEBUG HACKS」と双璧をなす、とおもう。
SAFARIで、オンラインで読めるので、興味が有ればお試しあれ。

リンク: http://www.oreilly.co.jp/books/9784873114064/

O'Rellyから、デバッグ最新刊、「実践　デバッグ技法」がでる。これは、The art of Debugging with GDB, DDD and Eclipseの訳本だ。
いわば、デバッグ三部作（？）の三部目だ。一部目は、「GDBハンドブック」とすれば、二部目は５月に刊行された「DEBUG HACKS」そして、「実践　デバッグ技法」である。なんと、いただきました。

推薦の辞を、DEBUG HACKSをまとめた吉岡氏が寄せている。

彼はふれていないが、DDDを取り上げているのに、XemacsでのGDB利用にほぼふれていない。でも、vimにふれているあたり、こだわりを感じる内容である。

興味を持った御仁には、１９９９年くらいのアスキー出版局「GDBデバッギング入門」やそのオンラインドキュメント、新バージョンなら、GDB6.8対応　９版を読まれると良い。折しも、このは、昨日２００９年６月１日にリリースされたばかりである。

リンク: http://www.fiveflavors.com/mt/pas_mal/archives/2008/02/post_1.html

昨年より、Nokia E61というSymbian OS 9.1/S60 3rd editionベースのスマートホンを使ってきた。ほとんど、PalmOSから乗り換えられるが、２つだけ今ひとつ乗り換えられないアプリケーションが２つある。

一つは、パスワード管理ソフトウエア。Keyring for palmOSを使ってきていて、その代替となるフリーソフトウエアがほとんどない。おしいのは、safeというアプリケーション。ただし、キーの生成機能がない。

二つ目は、辞書引きソフト。これまで、EIJIROとWDICの組み合わせで、ちょっと引きたいときに使ってきた。Linux distro上では、EBViewというアプリケーションを使っている。この辞書引きについては、EPWING形式を検索できるアプリケーションがS60上には存在していなくて、そんなQ&Aがインターネット検索をするとたくさんでてくる。MobilePocketというのを使うのが、今のところのworkaroundだが、変換が面倒。それは実は仕方なくて、EPWINGという規格がグローバルな標準ではなく、日本ローカルであって、Symbian OSベースのスマートホンを世界でもっとも出荷しているNokiaやモトローラの市場は、日本だけはその範囲外であったということだ。

EPWING形式を引くアプリケーションは作るのが面倒そうだな、と、思っていたのだが、じつはEBViewは、EB libraryを利用して作られている。そして、eb4jというEB libraryのjava実装があって、EPWING形式へのアクセスはライブラリに任せてしまえそう、ということに気がついた。
そして、このeb4jを使って、辞書引きソフトウエアを作った人がいて、LGPLで公開している。

Javaならば、Nokiaのスマートホンは、CLDC/MIDPアプリケーションを構築すれば、動かせるのだし、複雑な部分はライブラリ上にあるわけだから、GUIつまり、検索キーワードを受け取ってライブラリに渡して、結果をリスト表示する。程度のアプリケーションは、さほど難しくならなそうだな、ということで、作ってみたいとおもったのである

リンク: http://rubykaigi.tdiary.net/

１３：３０からMatzさんの梁山泊の話。基調講演。

プログラミング梁山泊 Sanctuary
LISPは梁山泊である。Fortranは梁山泊ではない。
UNIXは梁山泊である。yacc, awk, etc... perl, linux
ベストなテクノロジーである必要はない。便利である必要はある。
Smalltalk梁山泊。OOP.　Dynamic Language implementation
Java梁山泊。温故知新 learning from history. smalltalkのVMの技術やLISPのGCの技術を取り込んでいった。エンタープライズ技術。ビジネスに使えるCS。

Ruby kaigiの資料は、日本語と英語の併記。
梁山泊大事。技術者が集まる場所。求心力のある場所。それが大事だという話は、そのとおり。誰が作るか？人を集めたからといって梁山泊にならないよね。

コアになるネタがあるから、それが楽しいから結果として集まってきて梁山泊になっていくのだろう。

Ruby梁山泊。楽しさを重視。生産性を重視。

こうなる可能性はありそう。「楽しい」ことを重視しているから、ということだ。

リンク: http://www.da-cha.jp/?q=node/378

SafeというGPLのアプリケーションの改造を行っている。CLDC/MIDP上で動くJ2MEのアプリケーションだ。メインターゲットは、Symbian OSを採用しているNokiaやMotorolaの携帯電話。

このアプリケーションは、パスワード等の情報を暗号化して、携帯デバイス上で管理するソフトウエアである。類似のアプリケーションで、Palm OSでよく利用されるものに、Keyring for PalmOSがある。

Safeは、対称鍵暗号にIDEAを使用し、パスワードハッシュにMD5を利用している。現在アルファ版のKeyring for PalmOS v2.0を参考に、つぎのことをやろうとしている。

1. AESを使用
2. ハッシュにSHA利用
3. AESの利用に当たっては、Initial Vectorをきちんと使用し、データストアにもIVを保存する
4. データの構造としてtitle/contentという単純なデータ構造から、title, account, password, note, last modified dateという形にする。
5. プログラムの構造を整理する

このうち、AES利用やハッシュ、IVの処理あたりを片付けた。さてと、データ構造の変更をかけようとしたら、データ定義、export, data storeへの書き出しなど、多箇所の変更を余儀なくされる状況になった。
これは、プログラム設計がよくないということ。そこで、リファクタリングである。

暗号化されていないデータ要素（element)、その暗号化された要素、データストアへの書き出し（ファイル、XML、GUI）、データストアからの取り込み（ファイル、XML, GUI）といったものを、DecoratorやAbstractFactoryパターンで表現できそうな気がしてきたところで、就寝時間である。

リンク: http://adamklunick.com/2007/05/11/rails-error-to_date/

Check it OutというRailsでうごく家計簿ソフトがあるのだが、

NoMethodError in Admin#index

Showing app/views/account/_nav_show_small_balance.rhtml where line #1 raised:

private method `to_date' called for Sun Jun 10 16:05:34 +0900 2007:Time

Extracted source (around line #1):

1: total: <%= getTodayBalance(@account)%>

Trace of template inclusion: /app/views/account/_list.rhtml, /app/views/admin/partials/_nav.rhtml, /app/views/admin/index.rhtml

RAILS_ROOT: script/../config/..
Application Trace | Framework Trace | Full Trace

のようなエラーに遭遇。

どうやら、rails noのこのバグに遭遇しているようだ。
環境は、Debian Sid でRubyは1.8.6、Raisは1.2.3-2。チケットでは、Ruby 1.8.6で発生し、1.8.5では発生しないようす。

$ script/console
Loading development environment.
>> t = Time.now
=> Sun Jun 10 18:40:05 +0900 2007
>> t.to_date
NoMethodError: private method `to_date' called for Sun Jun 10 18:40:05 +0900 2007:Time
from (irb):2

チケットにあるのと同様、再現する。

このかたのブログでは、

So, dont make the same mistake as I did. Make sure to change the environment.rb file in the projects which you force to use a Rails version.

Hope this helps.

ということで助けになることを期待。

Ruby Forum
にあるDanielさんのコメントように、実際1.8.6ではto_dateがprivateになっているために、Railsとconlictすることが示されている

This is really really minor but it would be nice if Time#to_date and
Time#to_datetime (from date.rb) were made public. I don't know why they
are private (doesn't seem very useful) but that causes a conflict with
Rails' similarly-named helper methods.

Railsのほうで、to_dateを使わないで実装するのがいいのかな?