のらねこの気まま暮らし

技術系だけど、Qiita向きではないポエムとかを書くめったに更新されないヤツ

YAPCに行ってきた感想と思ったことを適当に

ブログ書くまでがYAPCとのことだったので、とりあえず。
トークのレビューというよりは、いろいろ聞いた結果、僕が何を思ってどうしようとおもったのかをずらっとまとめた感じ。

ちゃんとレビューしようかとも思ったけど大手がやってくれるので、あくまでここは個人の意見と思惑を書いとく。

そしていまリンクとか全然よういしてないので落ち着いたらちゃんとする。

効率化の話

Redmineに限らず、使いにくい、手間取ると思ったところは効率化しよう。
前々からRedmineは使いにくいと思っていて、しかも大したコトではないのに、やたらと手順を踏まなければならなかったり、よく間違えたりする。

Redmine::Chanは、おそらくいま面倒に思ってることの幾つかを解決してくれる。
チケットを思った時に切れて、わざわざページを開いてごにょごにょと操作して、IRCでも一報いれるという手間を、IRCの報告と確認だけで済ますことが可能になる。
それは嬉しい。

Redmineに限らず、同じように何度も余計な手順を踏まず、メモやちょっとしたタスク管理(大切なことではあるんだけどあまり頑張りすぎては本末転倒に思える事柄)程度のことで、やたらと時間をつかっているような気がする。

もっと直感的に、自然に、学習コスト低めでどうにかできる手段をもっと前向きに検討してもいいな、と思ったトークだった。

テストの話

いままでPerlのテストってよくわからなかった。
テストの大切は身にしみてわかっているんだけど、いかんせん上手い書き方がわからない。とりあえず書いてみてはいるものの、しっくりこないしコレで良いという指標が無かった。

RSpecでは、「仕様」をベースとしたテストの書き方を要求する。
なるほど、今まで仕様よりも、コードを意識していた。コードとして定義した挙動を確かめる意味でテストを書いていた。

仕様ベースであるならば「コードを書く前にテストを書く」というコーディングスタイルに納得が行くし、容易だ。

わりと僕はおかしなことを言っているけれど、だっていままで事前に提示された仕様書なるものが存在しなかったのだから仕方ない。
コードを書きながら僕自身が仕様を定義していて、そんなの先にテストかけるわけがない。

発表では、RSpecやxUnitを例にあげ、テストクラスを再定義していたが、PerlのテストモジュールにTest::Specなるものがあって、見た感じRSpecライクに書ける様子。

確かにdescriptionとかitとか、なんか直感的じゃないなぁと思う部分は合ったりするけど、そこにこだわれるほど余裕も無いので、Test::Specをベースに考え直して見ることにする。

プロジェクトを疎結合にして管理しやすく

少人数開発していると、大規模プロジェクトのメンテが非常にやりにくい。
新卒二年目==Perl経験年数みたいな新人には精神的負担が大きすぎる。

メンテしたり拡張したりと、運用を続けて奥からには、どこかのサービスの機能拡張やアップデートが他のサービスに影響を与えず、独立していて欲しい。
それが異なる機能や性質を持ったものであるなら尚更。

APIで提供し共通して使えるものであるなら、別の仕組みとして容易して、内部的にHTTPを叩いてごにょごにょしたい。
INとOUTの定義さえきちんとできていれば、中身がどうなろうと、仕組みてきにぶっ壊れて無ければ問題ない。

ちゃんとI/Fの仕様を定義し、プロジェクトを分けて管理すべきだと改めて思ったのだ。

Mouseとオブジェクト指向について

ちょいモテデザインパターンの話ではMooseを使って、の例があった。
Perlオブジェクト指向しようと思ったら、やはり避けては通れないのがMoose周りの仕組み。

じつは色々知らない機能とか発表の中であって、一人慌ててた。
目に見える範囲でしかMouseを追っていなかったけど、まさにそれは井の中の蛙。自分が「こうできたら便利なのに」とか「とりあえず自分で実装しちゃえ」とやって放置してたのとかちゃんと実装されてる。当然か。

デザインパターンの話は非常に参考になり、今後勉強したい項目のランキング上位に上がった。

「敵の動きが変わったからパターンBでいくぞ」「はい!」の下りは非常にわかりやすかった。
なるほど、「ここはこういうパターンでいきたいんですけど」と説明を抽象化できるのはすごく便利だ。

個人的に実装部分でもやっとしてたコトのヒントや解決策に辿り着けそうな予感がする。

Mouse(Moose)に関しても、デザインパターンにしても、オブジェクト指向にしても、今後まだまだ勉強の余地ありだと改めて痛感した。なるはやで。

プロジェクトに見合った技術を採用すること

どうにも大規模開発のすごいスケールの話を聞いていると、ウチもそれ対策したほうがいいかな、という気になってくる。
が、そんなことは実際ない。
キャッシュもNoSQLも、使いドコロを間違えればボトルネックにもリスクにもなり得る。

壮大なスケールを想定していないケースのサービスであるなら、それこそApp数台とMySQL2台と、サポート程度のMemcachedがあれば充分なんじゃないだろうか。

最近、やったことないことばかりのプロジェクトで、「こんな環境で大丈夫か?」と不安に陥っていたわけだけど、ゆうすけべさんの発表聞いて、少し安心したというか自信が持てた。

リリースして、ユーザの推移を見てからでも、構成を見直すのは遅くない。
うんぜん万PVなんて想定してないのだから、まずは様子を見て、最低限の調整をほどこせばいいのだ。

いまのMVCは間違っている

随分昔から思っていて、YAPCを通してちょっと形が見えつつあったので。
明確に見えてきたのはリクエストハンドリングとバリデーションの部分。

ゆうすけべさんも言っていたが、バリデーションの定義とコントローラは分けたいし、コントローラにバリデーション云々をずらずら書くのもなんか嫌な話。

コントローラはコンパクトに。
モデルの制御だけを行えば良い。

見せ方を買えただけの複数サイトや、API部分で使いまわせるように、適宜Modelは抽象化すべき。

結局はModelが問題なのだ。
コントローラを減らしてModelに埋めたはいいけど、他のコントローラから呼び出しにくくなってしまって使えない。そんなケースを生み出したこともあって、やっぱりモデルの切り方は微妙。

そこに光を照らしたのは、まんでぃさんのデザインパターン
見えてなかったものが見えたような気がして、ちょっと、いやかなり興味が湧いた。

やはりJavaもちゃんと勉強しなおすか。

よく知らないのにDISるのはいけない。
たとえ生理的嫌悪(言い過ぎ)でもちゃんと向きあってから答えを出すべきだ。

全体を通して

ひとまず感想。

面白かった!

これに尽きる。
興味深い話題もあれば、いますぐ試したい話題、正直どうでもいいんだけどでも熱意とロマンは伝わってくるので応援したいし絡みたいみたいな話題も。

結論からいってすごい得るものは多かった。
コードを書きたいっていうインスピレーションも受けたし、今まで悩んでいた問題を解決する糸口が見つかったような。

後半ちょっと力尽きてたけども、一休みしてスライド読みなおして、改めて仕事に取り掛かりたいと思う。

YAPC++