Railsでモデル生成のお勉強中

今日はこの辺りRails Guide - Getting Started with Rails#Adding a Second Modelを参考にしてrailsでmodelの実装をしてました。あまりの簡単さにびっくりした。

とりあえずrake generate modelでモデルの定義をするとmodel classとそのUnit Testとdbのmigration fileをわんさか作ってくれます。DBのmigration手順はここ(Rails Guide - Active Record Migrations)に良くまとまっていますが、必要に応じてindexやrelationなんかを追加しつつrake commandで簡単にDBを作る事ができます。rake db:migrateでdb/migrate以下に作られたmigration fileを元にじゃんじゃかテーブルを作ります。以下の順序で行われるっぽい。

1. db/migrate以下のファイルからテーブルを作成
2. データベースからdb/schema.rbを作る

また、rake db:migrate:resetを実行するとmigration filesからテーブルを作成してseed.rbを作り直す。db:resetだとseed.rbからテーブルを作るのでmigration fileを何回変更しても変わらない。
少しハマった…。

rakeのコマンドとかもまだ全く覚えていないのですが、rake --tasksで他のタスクがぞろぞろでてきてくれます。rake -Pで親タスクやその依存関係とかも出力してくれるっぽい。

例えば上記のdb:migrate:resetは3つのタスクを組み合わせたものらしい。

rake db:migrate:reset
    db:drop
    db:create
    db:migrate

また、rake test:allでUnit Testの全実行をしてくれるっぽい。

db/seed.rbに開発環境用のデータを用意できる。rake consoleから実行するのと同じように$class.new(:$field1 => $value)みたいな感じで書ける。RubyのScriptなのでファイルから読み込んでLoopでオブジェクト生成とかも非常に簡単にできそう。rake db:seedだと単純にseed.rbからデータをLoadする。rake db:setupだとスキーマごと作り直してからデータをLoadする。ちょこちょこデータファイルを変更する時は後者を使う。

あ、後作ったModelやそのObjectはrails consoleから確認してったら超効率よくできた。こんな感じで一通りモデルを作って、DBに反映させて、テストして、開発用データの準備までが半日かからずにできちゃいました。DBとModelの定義を固定して厳しい命名規則を受け入れるだけでこれだけの恩恵をうけられるとは。明日はRSpecを導入する予定。Rails楽しいね。

昔のブログ「外資系投資銀行を選んだ理由(2006年03月20日)」

最近、大学の研究室のサーバで眠っていた僕の修士課程時代のブログを見つけたので救出して読んでみました。2005年〜2007年くらいまで書いていたのですが、特に就職活動やキャリアの考えたかに関して興味をもって貰えそうなエントリーがいくつか出てきたので、基本的にはそのまま転載する形でいくつか紹介していきたいと思っています。

僕は修士課程在籍中の2005年3月のにJPモルガン証券のシステム部門に内定して2007年の4月から新入社員として入社したのですが、以下のエントリーはその時にどうして僕が外資系投資銀行のシステム部門という特殊な職を選んだのかを説明したものです。

6年経った今ではソフトウェアエンジニアの争奪戦が起こっており、高度な知識や技術をもったエンジニアの価値や待遇がどんどん高まっているという点では、この時の僕の考えはかなり的を得ていたと自分でも思っています。このエントリーで述べている僕のITコンサルやSIerに関する見方はちょっとステレオタイプな部分もあるかもしれませんが、今でも自分のキャリアに対する考えはこの時と殆ど変わっていません。6年前のひよっこ時代にも、それなりに物事を考えていたんだなぁと昔の自分にちょっと感心 :)

---

2006年03月20日

外資系投資銀行を選んだ理由

初のトラックバックです。以下のブログを読んで思うところがあったので。
「Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている」
要約すると、日本のシステム開発は「上流→下流」とゼネコンみたいに階層化されていて、プログラムもろくに書かない上流コンサルタントの設計を下請けの下流プログラマが仕様書どおりにコーディングするという構造になっている。そんなの効率悪いし、品質のよいソフトウェアはできないよという話。

この問題は、就職活動をするにあたってソフトウェア・エンジニアとしてガリガリと開発ができる職種を求めていた僕が、外資系投資銀行のテクノロジー部を選んだ大きな理由の一つ。

日本のシステム開発は上記のような階層構造になっているため、価値の高いことをしようと思うと、ITコンサルタントという職を選ぶしかない。IBM、アクセンチュア、野村総研とかのね。こういう企業では入社しばらくはプログラマとして下働きをして、その後に「泥臭いコーディングなんてしないコンサルタント」としてステップアップするらしい。その後は、マネージメントやお客さんから仕事をとってくる営業活動がメイン。技術重視では出世できない。実装を行う下請けの会社では、プログラムを書かない人達が作ったガチガチの設計書を元に、就職して初めてプログラムを書くような経験の少ない人達がコーディングを行う。「プログラマ＝初心者」という感じで、プログラマの地位は低い。階層構造の上の方からしっかりと利抜きされて仕事が回ってくるため給料も低い。

この階層構造の中での仕事を回避するために、少数で効率の良い開発を行っている企業をターゲットにしてみた。初めに考えたのは外資系のソフトウェアベンダーやインターネット企業。ソフトウェアベンダーとしてはマイクロソフトやオラクルが挙げられるけど、開発の拠点はアメリカで、日本の支店はそのローカライズや顧客サポート、営業が大半を占める。やっぱり一番魅力的な会社はGoogleなのだが、さすがに敷居が高すぎるし、どうしようかなぁと悩んでいたときに出会ったのが外資系投資銀行のテクノロジー部門。

基本丸投げの日系金融機関と違って、外資系投資銀行ではITをとても重視している。開発は少数のエンジニア達により殆ど自社で行う。エンジニアには金融工学などの数学的センスも求められるみたいで、専門性が高い。ここで頑張ればコンピューター・サイエンスと金融数学を武器にできると思って、この業界に決めた。海外のエンジニアさん達との共同開発や、成果を重視する評価精度も魅力的だった。日本の会社って若いうちは安い給料で奉公って感じだから。まぁ、エンジニアが主役となる会社ではないっていうのがネックなんだけどね。

採用人数はとても少なく、面接は英語ばかりだし、いきなりプログラムを書かされたりと大変だったが、運良く内定を頂くことができた。という訳で外資系投資銀行のテクノロジー部門に就職する事になった。