こちらでustされますので、早めにテレビの前に集まりましょう！
QudoｘSkinny / nekokakさん
Qudo
- TheSchwartzにかわるJobQueueシステム
- Skinnyをベースにしたかった
- githubの練習がしたかった
- TheSchwartzのスペルが覚えにく過ぎる。拡張がむずい。挙動を知りたい
- QueueDoでクドー
- 特定のO/Rマッパに依存しない
- 拡張しやすい → HookPointがある。欲しければ足す。
- 設計: Master → Manager*2 → Worker → Job
- エラーをどこまでも溜めれる
- TheSchwartzはエラーを一定数以上保持しない
- reenqueue(リトライ)しやすい
- 監視系のメソッドの準備
- Qudo::Test でテストしやすい
- Qudoの開発で最初に書いた部分
- Plugin作成可能
- Qudoの使い方
- Workerを実装 (workを実装)
- enqueue用Qudoオブジェクトの作成
- Manager用のQudoオブジェクトの起動
- Qudo::Hookを継承してフックを作る
- 登録周りは調整予定
- Qudo::Pluginを継承してPluginを作る
- register_pluginsする
- こっちも調整予定
- デモ
- 実績: 社内で1案件あり。今後はTheShwartzと置き換える
- githubにあり。目標はCPANうp
- 質疑応答
- Q. 自分で描いたWorkerとかもテスト可能？
- A. 見るDBさえ変えれば、テスト可能
DI x Perl / lestrratさん
- DI = Dependency Injection
- オブジェクトの自動組み立て
- 依存関係を満たして初期化
- 手動組立の問題
- 書き直し、依存関係、オブジェクトが多い、面倒
- DIの仕組み: Assembler + クラス定義 + 依存関係定義 → オブジェクト群
- PerlのDIコンテナ → Bread::Board*3
- 本番で使ってるユーザは恐らく一人(作者談)
- と、33rpm
- dannさん
- 今までのBread::Board
- 牧さんが3月頃にBread::Boardをforkしたとのこと
- 現在、APIを踏襲してport中
- 新しいbread::Board
- 注意: 以下は牧さんが提案した段階のものなので、まだ決定ではない
- inject, param, get ←これだけだとService Locator
- Mooseと融合してDIになる
- MooseX::Bread::Board
- bind_param で、Bread::Boardに設定する
- Bread::Boardが持つ情報は、 param:// と言う名前で指定
- bind_constructor → new以外のコンストラクタを使える
- inject_namespace で、依存関係を読み込み、 getでオブジェクトを取得する
- 1クラスについて複数インスタンスを使う場合は、直接BreadBoard APIを叩く
- 他の言語のDIとの差
- プログラム可能、クラス定義に埋め込み可能、XML不要
- 質疑応答
- Q. MooseX::Bread::Board してるクラスはBread::Board経由じゃなくても普通に使えるのか？
- A. 普通に使える。metaクラスに情報を入れてるだけ
Angelosによる優しいWAFの作り方 / dannさん
- 各言語のWAF
- WAFの構成要素
- Engine,Dispatcher,Component Loder
- Engineをnew,run
- Engine -> Dispatcher
- Dispatcher -> Component Loader でコンポーネントを探し、Controlerを実行
- Angelosの構成要素
- HTTP::Engine
- HTTP::Router
- Bread::Board
- conf/routes.pl → Railsっぽい定義
- シンプルなWAFはこれだけ！
- プラグインの種類
- ライフサイクルへHook系
- Class::Trigger
- MouseX::Object::Pluggable (Role + method modifier)
- メソッド生やす系
- Exproler
- 多重継承
- Mouse::Role
- ライフサイクルへHook系
- Angelosでは
- hook → Role + Method modifier
- 生やす系 → Role
- コアは小さく
- Hookポイントをわかりやすく → メソッドの命名規約 (大文字にする)
- "適切に"拡張箇所を限定。
- beforeやafterで、ACTION(等)にHookをかける
- 良: before,after,aroundが使える。シンプル。
- 悪: メソッドがバッティングするかも
- 適切なデフォルトセットの提供が大事
- WAF作りは簡単になってる。githubにて開発中！
- 質疑応答
- Q. どこでDI使うの？
- A. コンポネーンとの組み立てで使うのが一般的。DIするとテストしやすい
Perl With Amazon Elastic MapReduce / lopnorさん
- MapReduce(hadoop)
- cat | mapper.pl | reducer.pl のイメージ
- elasticmapreduce → amazonのWEBサービス
- CPANは使えるのか？ → local::lib
- "jar"で固めてs3nに上げれば、--cache-archive にて指定できる
- 指定の最後に#perl5 とすれば、perl5と言う名前でシンボリックリンクが張られる
- use libで利用できる
- お値段は、インスタンス1個分で1時間。ちょうど1時間に終わるように横に並べるのがお得。
- outputディレクトリが重複してると、エラーとなるので注意。
- 質疑応答
- Q. Hadoopを使ってて、止めたい時はどうするの？(reducer間違ってた、とか)
- A. WEBインタフェースから terminate 可能
かんたんオブジェクト指向Simo入門 / perlcodesampleさん
- Simo : Class::AccessorとMooseの中間
- アクセサ定義、new、デフォルト値、制約
- 制約違反時に例外を投げる
- オブジェクト操作用のメソッド
- use Simo;
- 継承: use Simo base => 'Super';
- mixin → 実際は多重継承。コードの読み手に伝える
- Simo::Util::o → オブジェクトを作る
- まとめ: 短いコードでモジュールを記述可能
CAPとBASEとEventually Consistent / yoheiさん
- Perlとの出逢い: 1995年 jperl → 訪問者リスト
- 赤ラクダ本 ← ネット上に画像がないらしい
- 複数サーバの必要性。分散重要。
- しかし、分散は難しい → 遅延、整合性、可用性
- CAP定理: 形式的に証明される
- Consistency 他の人の更新が見える
- Availability いつでもデータにアクセスできる
- Partition tolerance データを複数のサーバに保管できる
- 同時に満たすことができない
- 最近のWEBサービスではAとPが必須 → Consistencyを妥協
- Consistency
- Strong Consistency → すぐに他人の更新が見える
- Weak Consistency → すぐに他人の更新が見えるとは限らない
- Eventual Consistency → データ複製の時間が過ぎれば、更新にアクセスできる(更新前であれば)
- 「結果整合性」でググれ
- MySQL のレプリケーションでの例
- 最新のトピック
- 注意点
- ACIDよりBASEがいいってわけじゃない。CAPが全てってわけじゃない
- 最適な整合性モデルを採用するのが重要
- 続きはWebで。blogを見て下さいとのこと
- 質疑応答
- Q. モデル分けは何種類？
- A. 3種類。Strong (課金系), Eventual(ブログ系), Weak(個人重視)的な分け方だと思う。
perl-completion.elの紹介 / IMAKADOさん
Memcache-Queue / masartzさん*4
HTML::AAFindの紹介 / komoriyaさん
- HTML::AAFind → アスキーアートを探す
- AAはケータイから見れん → 画像化するといい
- AAだけを洗い出す必要性。法則を探る
- br区切り
- スペースが多い
- その他、eucとか
- AAだけを洗い出す必要性。法則を探る
- AAの画像変換は、後日！
- CodeReposにソース
閉会の挨拶。お疲れ様でした!!
懇親会
ゴーヤチャンプルー美味かったです。
