bloggalleryaboutcontact

Fukuoka Perl Workshop #14に行ってきた

牧さん(id:lestrrat)ご来福の巻。
http://fukuoka.pm.org/2009/10/fukuoak-perl-workshop-14.html
fukuoka.pmのIRCに垂れ流したやつを取り急ぎ貼っておきますね。

・dragon3: Cacoo-Deployerの話
Cacoo紹介 -> http://cacoo.com/
buildは一発でできるので、複数台サーバへのdeploy作業をツールで -> 自作
要求 -> 1つのサーバにファイル置いたら他のサーバに勝手に展開してサーバ再起動やら何やらやってくれる
ディレクトリ監視 -> Linux::Inotify2 -> inotifyのperlインタフェース
サーバ(Tomcat)操作 -> コマンド投げる
他 -> Moose使ってる
MooseX::ConfigFromfileもいいよ -> 最近SimpleFileばっか使ってる(牧さん)
Cacooもうちょっと: Wordpressのplugin作ってるよ

・s-aska: 使いやすいWebMail
windowsアプリっぽいWebMailほしい -> クロスブラウザ対応死ねる -> ExtJSみつけた
サーバから受け取るデータ -> JS側でJSONなりXMLなりで処理する
ExtJSいいよーいいよー
ExtJSのライセンスってどうなの -> デュアルライセンス -> http://extjs.co.jp/products/license.php


・lestrrat: Fukuoka.pm #14
Moose, Catalyst, DBIx::Classでどうテスト開発してんの的質問が事前にあった
-> ビジネスな話やろう -> endeworksな話するよ
今: 100% Perl案件 (8割は僕ですとの弁)
2008年: Perlコード5万行. Moose, Catalyst, DBIC -> 初めてプロジェクトにMoose採用
EBP2009 -> endeworks best practice 2009
Moose -> 全面的に採用 -> OOPやる以上は使う
使う使わないはほとんど宗教戦争の域 -> pjに合ったツールを使うべき
「最適化は後で」YMMV
Moose本体については長いので次の機会に
[Mooseお作法]
- lazy_build シンプルな値の時以外はdefaultのattribute使わない -> 継承とかするときに困る
 has foo => ( lazy_build => 1, );
- BUILDARGS: around modifyを使う -> 親クラスのBUILDARGSを使ってくれる -> 親クラスのほうが実装がきれい
 BUILDARGSで変なエラー出すと後でわかりにくい
- namespace::clean -> 推奨モジュール
 DSLは「ゴミ」を残す -> use Mooseした時点でhasが使えるようになる -> ちゃんと処理しなきゃ
 -> namespace::clean使うとscope内に閉じてくれる
 -> 裏で関数の出所を調べてくれる
[DBIx::Class]
DBIより重いとか勉強コストかかるとか -> 覚えてしまえば全てオブジェクトで扱えるので便利
-> 特にDBICには拘っていない -> 開発者に対する信頼で使っている -> 今日(11/14)新バージョンでたよ!
注意点: Catalyst等からは直接使わないようにしている -> 「便利なハッシュ」状態 -> 基本的には主キーだけで操作
[Catalyst, API]
APIレベルでの抽象化を守ってる(後述)
-> コメントしっかり書いてから壊してもいいルールですよ
スピード: DBICを使い続けながら一部で高速化したい場合 -> HashRefInflactor
API: Web等、環境から切り離したアプリケーションロジックとして作成する
APIを独立させる -> Modelに対してAPIコールを要求 -> とか
なので: Catalyst::Modelほとんど使ってない -> アクセサとして使ってる
APIの理由 -> あるアクションにはDB挿入以外の操作があるかも(キャッシュを追加削除するかも、とか)
問題点: API単体で動かしたいのに他のリソースへの依存関係があったりするので設定が面倒
[DI]
DI -> 依存関係を外出し
Bread::Boardを使いたかった -> パッチ適用してくれない -> 自分で作った -> Orochi
普通に書くとめんどくさい -> MooseX::Orochi書いた -> http://search.cpan.org/~dmaki/Orochi-0.00005/lib/MooseX/Orochi.pm
Orochi用途: API部分のbootstrap
Catalystとは別のレイヤでオブジェクト生成
# 参考 http://blog.eorzea.asia/2009/10/post_74.html
注意点: 循環依存の解決は実装できない
Constructorの代わりにSetterを使う
[テストの話]
「やっぱ嫌いですね」
自動セットアップ: テストで一番面倒なとこ -> がんばると後が楽 -> Fixtures, Text::mysqld
CPAN形式 -> Makefile.PL書いておけばmake test
MyApp::Text -> 環境の設定とかテスト中によく使うidiomをモジュールにまとめる
Test:: mysqld -> mysqldを起動してくれる -> 普通に使うと.tファイルごとにmysqldが起動してしまう
-> 1回だけ起動するようにした -> 多分後でモジュール化するよ -> Makefile書き変えてる
基本的にAPIをテスト: APIとCatalystを切り離した状態でテスト -> ブラウザを介する必要がなく、機能に集中してテストできる
統合テスト: まだ手作業 -> テンプレート変更とアプリ開発が同時だと難しい -> JSTAPd(JSをPerlからTestする by Yappo)とか使ってみたい
「使えるなら使いたいけどYappoさんだしなー」 -> Yappo: 「ひどいひどい」「すっげーちゃんと仕事で使ってるというのに!」
[git]
git使ってます
svn: 完全に捨てました -> pj大きくなるとレイアウトがひどくなる -> branch管理/mergeが面倒
「10コミットくらいあるとmergeしたくなくなる」
git: branch/mergeがすばらしい -> セットアップ簡単/小さいpjでもOK -> pjが大きいほどgit++
質問:「速いの?」->「すごく速いよ!」
Deplloy: サーバの数が多い -> rpmなど / 少数 -> git cloneが簡単
デプロイ後 -> ついやっちゃうproduction側でのちょっとした変更 -> 開発ブランチと別ブランチを切っておく
-> 万が一pushしてしまわないように
git pull --rebase -> pullと変更がステキにバッティングしない(conflictしない前提なら)
git stash -> 一旦pullしてあとでstash apply -> 他の人のbug fixとかと仲良くできる
git++ -> commitにしろpullにしろコピーしたクローンから簡単に試せる
[ドキュメント]
一番最後にやってます。。。 -> マネジャー向けのドキュメントのほうを優先しちゃいます。。。
コードのドキュメント -> POD -> 納品用にはPod::XhtmlでHTMLに変換したものを出力
[Pixisの話]
「no コピペ主義」
あれもこれも継承 -> i18nもデフォルト装備。継承
ベースアプリ -> git submoduleでアプリのリポジトリ内にlocal clone作成 -> baseの変更に惑わされずにカスタマイズ可能
-> 「このcloneだけの変更」
オレオレware -> CatalystX::AppBuilder, CatalystX::VirtualComponents, Data::Localize, Orochi, ...
Pixisデモ
- rootディレクトリがない
- テンプレも継承
- Catalystのpluginとかあらかじめ入れてる
- カスタマイズするならControllerのSubClass作る
現在 -> endeworks以外のユーザがいないので汎用ではないと思う -> documentがない -> endeworksではこれ使って開発効率が大幅にup
[おまけ]
スライドのコード部分 -> github(gist)++
本当はAnyEvent+Mooseなプロダクトが今のHot topic
次回は 8時間
[質問]
Q.最適なチーム編成像は? A.5人くらいかなー
Q.開発環境 A.うちはvimしか使わない
今のところvimとemacsだけでなんとかなってる
- .vimrcが意外とシンプルだった
perl -Ilocal::lib でpjに含めたperlを使う -> バージョン違いな問題を回避できる
OS -> CentOS最近使ってる -> コード書くときはmac
Orochi -> 裏方で勝手にobjectを作ってくれるkey-value storeな風味

てな感じで懇親会へGO。2次会まで全員参加のステキな参加率。
Perl界隈の人はサーバとかも普通に触りまくってる人が多いので、非常に喋りやすいです。
あと経験値の高い人が多いので、歴史をひもとくような話を聞けて大変貴重。
僕は僕で昔の先輩様とかと大量再会したりして恐縮でございました。
とりあえず、誤解してもらえるような福岡懇親会風景を貼って締めときます。

fukuoka-pm-with-beer

Fukuoka.pmまとめのsugmakさん、懇親会他まとめていただいたZAIONさん、発表者のお二人、そして牧さんありがとうございましたー。
そんなこんなで皆様おつかれさまでした。
 Permalink

Comments

No new comments allowed (anymore) on this post.