•
•
•
•
 |
初めてのRuby Yugui オライリージャパン 2008-06-26 |
読んだ。
いやー、これはいいですね。
すでにある程度プログラミングの経験がある人が Ruby を学ぶ際に必要な情報が上手い具合にまとまってる。
Ruby 1.9 のことも書かれてるし。
本書を書くにあたって２つの選択肢がありました。プログラミング初心者をターゲットとするか、しないか。私は後者を選択しました。本書は、プログラミングというものを学んだことがある人に向けた、Ruby という言語の入門書です。プログラミングそのものについての解説は極めて限定的です。
−−「はじめに」より
この本をベースにして社内での Ruby 布教活動を進めていこう。そうしよう。
Ruby と Java についてあとで書く。
追記:
どっちもやってみたらいいと思うよ！
いやほんと、これにつきる。
とりあえずそれぞれの言語にどっぷりつかってみるべき。
どちらの言語が優れているとか、そういうレイヤーの話って不毛なんですよ。
Ruby という言語のことを知らずして Ruby のことをとやかく言うことはできないよね。
逆に Ruby やってる人間はだいたい Java のことはよくわかってる。
むしろ、Java やってる人以上によくわかってるかもしれない。
（想像だけど）
ていうか、適所適材ですよ。
Java を使うべき所で Java を使い、Ruby を使うべき所で Ruby を使う。
PHP を使うべき所では PHP を使う。
えーっと、だから逆に言うと、いくら Ruby がいいからといって、Ruby を使うべきではない所では Ruby を使うべきではないということ。
エンジニアたるもの、そのくらいの見極めができないとダメだと思う。
実際の所、Ruby を仕事でバリバリ使ってる人ってまだ結構少ないと思う。
Ruby が好きとは言っても、ほとんどの人が仕事では Ruby 以外の言語（Java, PHP, Perl とか？）をメインに使っているんじゃないかな。
だから例えば、Ruby を知らない Java 屋さんが、Ruby プログラマと何らかの形で張り合おうとした場合、Java 屋さんは圧倒的に不利。
Rubyist は相手のことをちゃーんと把握してるから。
それに比べて Java 屋さんは Ruby のことを何にもわかっちゃいない。
この状況でどちらが勝つか。
考えるまでもないですね？
冗談はさておき。
どのプログラミング言語を使えるのか、という程度のことで他人との間に軋轢が生まれてしまうような状況ってのが実にくだらないと思うのです。
自分の考えが正しくあるためには、相手の考えが間違っていなくてはならない、みたいなね。
…
ああ、
もうちょっとまともな文章かけるようにならないと。
RubyKaigi に行って yugui さんにサインもらいました。
あと、june29 さん、kei-s さん、colspan さんなんかとお近づきになれました。
こういうイベントに参加するといろんな人にあえていいですね！
懇親会でもっとたくさんいろんな人と喋れたらよかったなぁ、と思いました。
とりあえず今日はこんなところで。
…
[追記]
あ、そうそう。
gihyo.jp に掲載されていた RubyKaigi2008 の記事の写真に僕が写ってるのを発見しました。
RubyKaigi2008 スペシャル★レポート：RubyKaigi2008 1st day Photoレポート［随時更新］｜gihyo.jp … 技術評論社
gihyo.jp に載った！
…
[追記]
あ、そうそう。
Chad Fowler にもサインもらいました。
「国土数値情報 鉄道データ」ってのがあります。
全国の旅客鉄道・軌道の路線や駅について、形状（線）、鉄道区分（普通鉄道、鋼索鉄道、懸垂式モノレール、跨座式モノレール等）、事業者（新幹線、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
あとで書く。
![小飼弾のアルファギークに逢ってきた [WEB+DB PRESS plus] (WEB+DB PRESSプラスシリーズ)](http://ecx.images-amazon.com/images/I/51utUwM%2BN%2BL._SL160_.jpg) |
小飼弾のアルファギークに逢ってきた [WEB+DB PRESS plus] (WEB+DB PRESSプラスシリーズ) 小飼 弾 技術評論社 2008-04-15 |
これ読みましたよ！danさん！
YAPC で見かけたけどなんか怖くて声かけられなかった。
otsune さんも見かけたけど怖くて（ｒｙ
さくっと読めるわりに結構読み応えがありました。
社長がこれ読んですごく Ruby に興味を持ったみたいなことを言ってた。
結構 Ruby 好きな人が出てくる。
DHH（Rails 作った人） 曰く、
最初は Rails を PHP でやろうとしたんだ。でも、できなかった。PHP はそこまでの抽象化ができない。それで Ruby を使ったのだけれど、Ruby を使うことによって、抽象化は言語の側で持たせて、整合性（Consistency）をフレームワーク側で確保することができた。
なるほど。
まあ、PHP のことはよくわからないけど、Ruby は結構思った通りに書ける。
PHP や Java でプログラム書いてて「Ruby ならもっとスマートに書けるのに！」と思うことは多々あるけど、逆はまず無いよなぁ。
明日は社長とかとYAPCに行く予定だったんだけど、数年に一度くらいしか会えない友人に会う予定ができてしまったので中止。
あさっては行きます。
それと、RubyKaigi2008 なんだけど、チケットを予約したはいいけどいろいろ立て込んでて結局取れなかった。
懇親会のチケットはとれたけどね。
懇親会だけ参加ってなんだよそれって感じだよね。
ていうか何あのローソンチケットのシステム。
ほんと使えねー。
ネットで予約してから三日以内にローソンにチケット取りに行かないといけないって何それ。
あと、ロッピー使いにくい。
ダメあんなの。
まあ僕の考えが甘かったのがいけないんだよなあ。
あー、もう、自分にがっかり。
追記:
チケット取れました。
コメントで ogijun さんにチケットの追加発売があることを教えていただいて、無事買うことができました。
いやー、もう相当凹んでたんですよ、チケット逃して。
ogijun さんありがとうございます。
;.png)