Unofficial Planet WordPress Japan

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

全国の旅客鉄道・軌道の路線や駅について、形状（線）、鉄道区分（普通鉄道、鋼索鉄道、懸垂式モノレール、跨座式モノレール等）、事業者（新幹線、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 アプリケーションが何かしらのフレームワークを使って構築できるはず。
フレームワークの選択を誤ると無駄にコストがかかるかもしれないけど、ま、そうそう間違えないでしょ。

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

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

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

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

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

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

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

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

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

複数の情報筋からの情報：２年近くの間、高い頻度で発生していたスケーリング関連のトラブルで、TwitterはRuby on Railsのフレームワークを捨て、PHPないしJava（Rubyは使い続け、Railsのフレームワークのみを放棄する案もあるようだ）を使ってゼロから作り直すことにしたようだ。

— TechCrunch Japanese アーカイブ » Twitter、Ruby on Railsを放棄か

実際のところどういう問題があったのか知りたいな。
おそらく、Twitter のような膨大なトラフィックを集めるサイト特有の問題だと思われる。
以下のような話も関連してるんだろうな。

TwitterのスケーリングについてはCookがその任に当たっていたが、彼はこの作業をうまくこなすことに失敗した。
[略]
Twitterは今年になって、少なくとも３つ、キーとなる技術面での雇用を行っている。Lee MighdollはVPエンジニアおよび運用担当として１月から参加している。そして今週になってJohn Kaluckiと（「BloggerおよびBlogspotのスケーリング分野での働きでその名を知られる」）Steve Jensenという、２名のスケーリング分野のエキスパートを採用した。

— TechCrunch Japanese アーカイブ » Twitterにおける素人の前座は終わり？

というか、アレですよ。
Web アプリケーションをいかにスケールさせるか、という話になってくると、どのフレームワークが良いとかそういう話の重要度はきわめて低くなってくるんだろうな。
例えば、Java もしくは PHP に置き換えることによってシステムの負荷がほんのちょっと下がるだけでハードウェアにかかるコストがものすごく減る、なんてこともあるだろうし。
ごくごく一般の Web アプリケーションにおいてはこういう問題はそうそう起こらないと思う。

つまりは、「開発コスト」と「運用コスト」の二種類のコストがあって、サイトの規模や種類によってどちらの負担が大きくなるかが変わってくる、ということですね。
そういったことを考慮した上でシステムに採用する技術（言語やフレームワーク等）を決める必要があると。
なので、 Rails がダメだったから、とか早急に結論づけるのは問題の本質をとらえ損ねてるわけですよ。

いや、でも、Rails もしくは Ruby に致命的な問題があったとかだったらまた話は変わってくるけど。

うーん、アレですね。
Web アプリケーションをちゃんと作るのってくそ面倒くさい大変ですね。
というか、Web という基本ステートレスな環境でいろいろなことを表現しなくちゃいけないというのが、本当に、、、特殊。
慣れるまでは大変。

僕は今までは主に Windows 上で動く GUI アプリとか、RPC によるサーバークライアント型システムのサーバー側の処理とかを Java とか C# なんかで作ってたりしたんだけど、まあこういうシステムってそこそこ直感的ではあるんですね。
プログラミングとしては、特にマルチスレッドで動く部分とかがあるといろいろ大変になってくるけど、そういう部分さえ意識していればその他の部分はわりと作りたいように作れる。
そこそこ思い通りに表現できたり、無理のない実装、綺麗な実装にできたりとか、オブジェクト指向的に作れたりとか。
なんていうか、クラスを中心に物事を考えられるんですね。

こういう感覚に慣れているから、いや、こういう感覚にしか慣れていないから、Web アプリケーションの開発って非常に、とまどいます。
僕としては、アプリケーションの土台となるような部分に一本ビシーッと筋が通ってて欲しいんですね。
この処理はこれが面倒見て、ここに関してはこれが責任を持つ、とかそんなような。
Web アプリケーションにおいてはそういうのを一から作らないといけない。
ま、フレームワークってのがそういう役割を担うものなわけなんだけど。
で、巷には Rails とかいろいろあるわけですが、導入するにしても学習コストが馬鹿にならない。

ていうか、Web アプリケーションフレームワークって種類多すぎじゃね？
例えば、僕は Swing のような GUI ライブラリが何十種類も存在するなんてのを想像できない。
それだけ Web アプリケーションって特殊なんだな。
とか、簡単に結論づけちゃってるけど、これは結構切実な問題なんですよね。
今まさにそういうところで悩んでいるわけなので。
（GUI ライブラリと簡単に比較するのもどうかと思うけどね）

というわけで、いろんな Web アプリケーションフレームワークをザーッと眺めていこうと思ってます。
上手くまとめて社内勉強会なんかで発表できるといいなぁ。