Playframeworkについていろいろ - hagikuratakeshi's diary

Play! framework Advent Calendar 2011 jp #play_ja : ATNDの8日目です。
そしてこのBlogを開設して初めて書きます。

@hagikurというIDでTwitterやってます。どうぞよろしく。
Playframeworkで一番好きなModuleはSienaです。
Playframeworkとの馴れ初めを書く前に僕自身の事を少し書いてみようと思います。

前の会社のこと

まず今はERPパッケージを作る会社でソフトウェアエンジニアとして働いています。
その前は新卒としてSIerの会社で働いていました。

SIerの会社では仕様決めから、設計、開発、テスト、導入までと開発サイクルのひと通りを経験させてもらいました。(ただ、開発、テストの多くは協力会社と呼ばれる外注の方に発注することが多い)

今思い返してみても非常に厳しい現場だったので仕事をするとはこういうことなんだという意識を植え付けられたのはもちろん、ソフトウェアエンジニアリングとかインフラについてもたくさんのことを学べる場所でありました。
よく怒られたなーというのが懐かしい。

SIerというと、よくTLなどで技術力の低さなどを揶揄するハッシュタグが流れたりしていますがw、そのハッシュタグのTweetと照らしてみても幸運にも(?)そういう揶揄されるようなことは少ない、恵まれた場所であったと思います。

ただ、なんで転職を決意したかというとやっぱり開発を自分でできないというもどかしさがあったことが一番でした。
大学で情報工学を専攻してたり、仕事外でも趣味でプログラミングの勉強はしていたこともあって、(能力的に)プログラムが書けないということはなかったと思うのですが、SIerという仕組み自体が発注側がプログラムを書いてはいけないということを強制していました。

なぜなら、全ての工程は人月という単位に換算され誰が作業しても同じ効率で工程が終わるという前提のもと物事が進むからです。
そうすると、相対的に人月単価が高い発注側の人間は必然的に管理側に回ることが多くなります。
(ただ幸運だったのはさっきも書いた通りその中でも丸投げするだけのことはなく、技術的にも学べることは多かったことです)

で、漠然と転職を考えてた時に運良く今の会社に拾ってもらいました。

今の会社のこと

で、今の会社に入ってからはR&Dのようなところに配属になりました。
自分で開発ができるということを楽しく感じ、できればずっとソフトウェアエンジニアを続けていきたいと思うようになったのもここでの開発経験があったからだと思います。

と思うのと同時に社内社外問わずアウトプットをすること(つまりエンジニアとしてはプログラムを書くこと)を強く意識するようになりました。
考えるようになったいきさつは色々あるような気がしますが、多分こんなところです。

プログラムを書いてそれを誰かの為に役立たせるという体験が楽しく、それを本気でやって行きたいと思うようになったこと。
プログラムを書くことを今後の仕事にしていきたいと思うようになった一方、社外とか世界でみると自分はどれくらい通用するんだろうと思うようになったこと。

Playframework

で、そんな風にアウトプットを出さなきゃと思っていた時に偶然Playframeworkに出会いました。
最初見たときはJavaでRuby on Rails 的な開発とか言ってるけど何これ！
Controllerにrequest, responseがstatic フィールドであるし！
とかthrow Throwable をgoto文的に使っててキモい！
とか一般的にはJavaの書き方でしちゃいけないということをFramework内部のソースではやってたのにまず驚きました。

が、実際使ってみると直感的な開発ができることにもまた驚き、すぐにこのFrameworkが好きになりました。
だって開発中にサーバ一回立ち上げたらその日を終えるまでサーバ上げなおさなくていいんですよ。

僕も含めてプログラムを書く人は総じて面倒くさがりな人が多いです。
そういう人たちはなるべく無駄なことは無くしたいと思っているはずなんですよね。
開発中にサーバの上げ下げするの面倒だなあとか思ってる人は一回騙されたと思ってPlay! 使ってみてください。

でなんやかんやあってPlayframeworkを使って小さいながら自分のアプリケーションを公開できたり作った過程なりを第二回 #Playframework 勉強会 in Tokyo #play_ja : ATNDのような勉強会で発表させてもらったり、GAE -> Heroku に移行する際に必要になったSiena-MongoDBのPluginのpull request送れたりするようになったわけです。(残念ながらまだmergeされていないですが)

またこの頃からありがたいことに、エンジニアとしての職の紹介をちらほらいただくようになりました。
もちろん職探しをするためにアウトプットをしたかったわけではなかったのですが、エンジニアとして評価していただける方がいらっしゃるのはアウトプットが最も重要と考えたことと、そのアウトプットをするためになるべく無駄なことを排除してくれるPlayframeworkを選んだことはそんなに間違ってなかったのだろうとの励みになりました。

最後に

いいことばかり書いてきましたがもちろん全てメリットばかりというわけではありません。
例えば、Play! は生産性を重視するFrameworkであるためにController, Modelなどの書き方は自由に書かせるよりFrameworkに従った書き方を期待しています。なので、既存のWeb Application を移行するといった使い方にはあまり向いていないかもしれません。
(もちろん一概には言えませんが。既存のものが適切なクラス単位に分割されていれば大部分は再利用できるでしょう)

が、Javaでスクラッチで開発するのだったらまず検討しがいのあるFrameworkであると思います。いくつかJavaのFramework経験しましたがそれくらい開発しやすかったです。
そしてPlay2.0からはScalaについてもそういうポジションになれるように願ってます！

なんかPlay! の紹介というより使った上での心持ちみたいになっちゃったけどAdventCalendarにも一つくらいこんなのがあってもいいよね！
と言うわけで9日目は @teppei_tosa さんに担当していただきます。お楽しみに！