System.Exit

Termtter の開発が楽しいです。

http://github.com/jugyo/termtter

初めの頃は僕一人で開発してて自分のプログラムという感覚が強かったのですが、今はもうまったくそんな風には思わないですね。
開発者全員が共同で所有してるものみたいな感じがします。
みんなで開発するのって楽しいですね。
ま、仕事とは違いますからね。

プラグインの仕組みを入れたのが良かったと思います。
初めは hook を追加する機能しかなかったのですが。
コマンドを追加できるようにしたあたりから、かなり楽しくなってきたように思います。
自分では絶対に思いつけないような素敵コマンドがたくさん実装されていきました。

僕自身は Termtter の開発が最終的にうまくいこうが失敗しようが正直どっちでもいいんですよね。
できればうまくいってほしいですけど、今みたいにみんなで議論したりアイデアを出したりしながら真剣に考えてプログラミングするというそのプロセスこそがなにより重要だと思うんです。
良いものを作るためにみんなで知恵を出し合うというのがいいですね。
なので、そういう雰囲気を維持できるように僕は頑張りたいと思います。
楽しめなければ意味ないですし、楽しくなければ誰も参加したいとは思わないですからね。

「検索くん」を作った – phaのニート日記

これ見て pha さんはほんとすごいなぁと思った。
僕とはタイプの違うエンジニアなんだろうなぁと思った。
僕はどっちかっていうと技術力を高めていけばそのうちなんか作れるだろう、と考えてる。
で、今だに大したものを作れずにいる。
pha さんの場合はたぶん逆で、「作りたいもの」がまず先にあるんだろうな。
そして、そのために必要な技術をつど習得していく。

ネットにおいては、まだまだアイデア次第で面白いものを比較的簡単に作り出すことができる。
そして、必要な情報はほとんどネット上で手に入る。
いい時代だ。
僕も頑張らないと。

ソフトウェア開発者採用ガイド 青木 靖 翔泳社 2008-03-20 売り上げランキング : 12836 Amazonで詳しく見る by G-Tools

これ読んだ。
いやー、Joel の文章はどれもいい。
書いてある内容もそうだけど、とにかく文章がいい。
例えるなら、めちゃくちゃいい絵を描く漫画家みたいな感じ。
こんなふうに書けたら（描けたら）いいなぁと思わせる。

印象に残ったところをいくつか引用。

この６年の間、友人のマイケルと私でソフトウェア会社を率いてきた。私たちは最初の最初から第一に優先することは優れた人を採用することだと考えていた。どんなソフトウェアを作るか考える前からだ。そうしてその年月の間、優れた人たちが私たちのところで働きたいと思うようにすることに注力し続けた −− まだ誰かを雇えるようになる前からだ。私たちはいくつか間違いをし、そこから多くを学んだ。今では優れた人を得るというのは Fog Creek にとって唯一問題を感じないことと思えるほどになった。

逆にいうと、すごいアイデアがあったとしても優秀な人間がいないと実現に至らないんだよなぁ。
金で技術は買えるかもしれないけど、見極める力がなくて間違った技術を買っちゃったらどうするの？、とかも思う。
A ランクの人は自分よりも能力のある人を雇い、B ランクの人は自分よりも能力が劣る人を雇う、みたいな話があったな。

ソフトウェア会社を作るのは、それまで解けなかった何かの問題を解決する巧妙なアイデアを見つけて実現し、それによって富を得るのが目的なのだ、と一般には信じられている。これを「より良いねずみ取り作りの信条」と呼ぶことにしよう。しかしソフトウェア会社の本当の目的は、資本を役立つソフトウェアへと変えることであるべきなのだ。

Joel が言いたかったことからは若干ずれるかもしれないけど、最近僕はこんなふうに考えてる。
「誰でもすごいアイデアを思いつけるわけじゃない」
というか、人間の発想なんてたかが知れてる。
すごいアイデアで何かを成し遂げたい！って思うのは、そうすることがすごく魅力的に見えるからだと思う。
なぜそれが魅力的に見えるかというと、すごいアイデアで何かを成し遂げるということができていない今の自分が全然魅力的に見えないからなんだよね。
状況を変える何かが欲しいんだよね。
とにかく努力あるのみ。
中途半端な努力で思いつくようなアイデアなんて誰もが思いつくようなものばかりだと思う。

開発者が現在の作業のために最適でないプログラミング言語を、それがボスの好みだからという理由で使うように言われることほど、彼らを憤慨させることはない。人々が厳格に能力によって昇進するのではなく、コネによって昇進することほど、彼らを怒らせることはない。組織で自分より上にいるか、より強いコネをもった人間が要求しているために、技術的に劣った方法でやらなければならないということほど、彼らをムカつかせることはない。

まあ、これはその通りですね。
プログラマじゃなくてもこういう事態になったら普通怒ると思うけど。
ただ、ちゃんとした根拠もなく最新の技術を使いたいとかお気に入りのフレームワークを使いたいとか言うのはちょっと違う。
あくまでその状況において最適な技術・ツールは何か、ということをちゃんと考える必要がある。

私たちの信条は長期的視点で採用するということだ。現在たまたま知っているどんな技術も、来年には古くなっている可能性がある。しかもそれらの技術の中にはいとも簡単に学べるものもある。 [略] 基本的に優れたソフトウェア開発者には、別なプログラミング言語を学ぶというのはまったくたいしたことではないのだ。彼らは２週間で非常に生産的になっていることだろう。２年後には、まだ発明されていないプログラミング言語でまったく違ったことをやってもらっているかもしれない。

これもその通り。
Joel の話からはちょっとそれるけど、僕が前から思っているのは「PHP しか知らない人は PHP すらも知らない」ということ。
他の言語を理解するということは、その言語の理解も深めることにもなる。
そもそもプログラミングを学ぶというのはそういうことだと思うんだけどなぁ。
あ、Lisp 勉強しないと。

問題のある開発者の多くは、単純に優れた開発者になるための素養を欠いているものだ。頭は良いがポインタや再帰を決して理解できない人がいるというのは私が強く思っていることだ。

そうかもしれない。

とりとめのない話。

個人的に取り組んでいること、やりたいなぁと思ってることってみんないろいろあると思う。
そういうのを一個一個のプロジェクトととらえて処理していけたらいいなぁ、と思ってる。
システム開発ではプロジェクト管理ツールとして Trac を使ったりとかよくするけど、個人プロジェクト向けにはああいうのはオーバースペックというか、方向性がちょっと違うなぁという気がする。

TODO リスト的なソフトっていろいろあるけど、TODO リストをそもそも僕はいまいち上手く使いこなせない。
だんだんリストを見るのが億劫になってくるんだよなぁ。
単にモチベーションの問題かもしれない。
TODO リストって、実際に作業を行っている時にはすごく有効なツールになるんですよね。
でも少し時間がたつとただのリストになってしまって、どういうタスクがあったのかとか確認するのがものすごく面倒くさく感じられてきてしまい、結局放置されていつか前全データごと消去されるのを待つだけ、みたいな状況になってしまう。

毎日見る気になれて、一目で各プロジェクトの進捗やステータスなんかが把握できて、かつ操作も面倒でない、そんなツールが欲しい。
というわけでなんか作ってみようかな。

なんか、うまくいかないことをなんでもツールに頼ってやろうとするのも良くない気がする。
ていうか、往々にしてツールじゃ解決しないし。

とか、いろいろ調べる為にもなんか作る必要があるような気がしてきた。

「国土数値情報 鉄道データ」ってのがあります。

全国の旅客鉄道・軌道の路線や駅について、形状（線）、鉄道区分（普通鉄道、鋼索鉄道、懸垂式モノレール、跨座式モノレール等）、事業者（新幹線、JR在来線、公営鉄道、民営鉄道、第三セクター）、路線名、運営会社等を整備したものである。駅は、鉄道路線の一部分として整備している。
国土数値情報　鉄道データの詳細

このデータを Webアプリなんかから使いやすいように加工するためのスクリプトを書きました。
というか、XML データをパースして DB （SQLite）にほとんどそのままの形で突っ込んでるだけです。
SQLite にデータを格納することで、いろいろなアプリケーションから利用しやすくなると思います。

そもそもこの「鉄道データ」というのがどういうデータ構造なのかというと、以下のような感じになってます。

「路線」や「駅」の「位置」が「曲線データ」によって表されています。
「曲線データ」は複数の「座標」を持っています。

ちなみに、元データ（XMLファイル）の構造は以下のようになっています。

「路線」「駅」「曲線」「座標」のそれぞれのデータがそのまんま並んでるだけです。

XML ファイル上では、「座標」は具体的な数値（ジオコード）で表されることもあれば、「座標データ」への参照で表されることもあります。
例えば以下のような感じです。

<curve>
  ...
  <point idref="pt20743_rr" />              # 座標ID
  <point>26.214740 127.679704</point>        # ジオコード
  <point>26.214795 127.679752</point>        # ジオコード
  <point>26.217280 127.682172</point>        # ジオコード
  <point idref="pt20737_rr" />            # 座標ID
  ...
</curve>

変換処理では、後々の利便性を考えて、上記の「座標ID」のところを実際の値（つまりジオコード）に置き換えるという、いわゆる非正規化的なことをやってます。
なので「座標データ」は一旦は DB に格納されますが、最終的には必要なくなります。

上記の通り「曲線データ」は配列的なデータなので、 DB にどういうかたちで格納すべきか迷ったのですが、YAML フォーマットに変換してひとつのカラムに突っ込むようにしました。

ソース

ソース類を以下に置きました。

http://github.com/jugyo/rail_data_converter/tree/master

実行手順ですが、git-clone でソース類をダウンロードした後、鉄道データをダウンロードしてきて rake コマンドを叩くだけです。

# ソース類の取得
$ git-clone git://github.com/jugyo/rail_data_converter.git rail_data_converter
$ cd rail_data_converter

# 鉄道データのダウンロード
# 以下のページからたどって鉄道データをダウンロードし、
# http://nlftp.mlit.go.jp/ksj/jpgis/datalist/KsjTmplt-N02-v1_1.html
# rail_data.xml という名前でカレントディレクトリに保存する

# 変換処理開始
$ rake

Rails で使用する際の手順

あとで書く。

Git とか Mercurial といった、いわゆる分散バージョン管理システムというのが実際どういうものなのかというのがいまいちよくわかっていなかった。
いろいろ調べたり実際に使ってみたりしてなんとなくわかってきたのでメモ。

まず、Subversion は以下のような感じ。

対して Git は以下のような感じ。

Subversion みたいなサーバーはなく、リポジトリしか存在しない。
運用の仕方としては、どれか一つのリポジトリを「中央リポジトリ」として、そこにみんなが変更を反映させていく、という感じなんだと思う。
結局その「中央レポジトリ」が Subversion における「サーバー」の役割を果たすことになるのか。

間違ってたらごめんなさい。

…

あと、全然関係ないけど、「リポジトリ」って言う人と「レポジトリ」っていう人がいるよね。

Web アプリケーションフレームワークを使うべきか否か。

当然使うべきでしょ。
開発効率が全然違ってくる。
ものすごく特殊なアプリケーションとかだったら適用するのは難しいかもしれないけど、ほとんどの Web アプリケーションが何かしらのフレームワークを使って構築できるはず。
フレームワークの選択を誤ると無駄にコストがかかるかもしれないけど、ま、そうそう間違えないでしょ。

メジャーなフレームワークには、たいていわかりやすいドキュメントがある。
ドキュメントがあるとシステムの見通しが良くなるので、メンテナンスがやりやすくなる。
例えば、独自のフレームワークを作ったとしてもドキュメントが無いと他の人がシステムを理解するのに余計な手間がかかる。
ドキュメント書くのって結構面倒くさい。

要は、どこにコストをかけるか、という話ですね。
自社の製品にめちゃくちゃ特化したフレームワークをはじめにコストをかけてドーンと作って、それを活用することで後々の開発のコストを下げるのか、メジャーなフレームワークを活用して開発コストを下げるのか、という。

図にすると以下のような感じ（状況によって違ってくることも多々あると思いますが）。

フレームワーク無しでいく場合

フレームワーク無しでいく場合、各開発において効率が相当悪くなることが予想されます。
似たような機能をそれぞれで実装したりするはめになるので。

独自フレームワークでいく場合

フレームワークを作るのにかなりのコストがかかります。
それに、そこそこ使い物になる良いフレームワークを作るにはかなりの技術力が要求されるので、優秀な技術者がいないと厳しいです。

メジャーなフレームワークを活用する場合

メジャーなフレームワークを使うと全てが上手くいきます！
（嘘）