- aptでlibnotifyをinstall
- OAuthを利用するためにdev.twitter.comで自分用アプリを適当に登録する
- AnyEvent::Twitter::Stream, Gtk2::Notifyをcpanm等でinstall
- stream2libnotify.plを実行!
2010/10/24
libnotifyでTwitterのTimelineをデスクトップに通知
2010/10/17
YAPC::Asia Tokyo 2010 二日目
Web APIのすすめ
自己紹介
- Yuji Shimada
- DeNA
- xaicron
Web APIの例
- public
- Google Map
- 認証
- 内部向け
Publicなもの
- 認証が必要ないものは公開しづらい
- アクセス数が読めない
- 大手はできる
認証が必要なもの
- ユーザ登録が必要
- AccessTokenをもらう
- ユーザ数からアクセスが予想できる
- BANできる
内部向け
- 単一ドメイン
- ユーザが自分で使わない
Web APIについて
- Web API は速さが必要
- 遅くなるとアクセスが下がるので内部向けも速度は重要
- yusukebe 「使える」Web API はでそろっているのでマッシュアップは詰んだ
- 何が流行るかわからないのでとりあえず作る!
高速なWeb APIの作り方
既存WAFを使わない
- 問題が起こったときに内部構造がわからないとだめ
- Plackがあるので ore ore WAF を作ればいい
WAFの構造
- Web API はURL:機能は1:1がほとんど
- Catalyst ディスパッチャしか使っていない
- 無駄機能を削ぎ落とす
- ViewらしいViewがない
- JSONがあれば幸せ
- XML, YAMLを返しても誰もうれしくない
ここまでのまとめ
- Plack, Router::Simple, JSON
- ore ore WAF を書いてしまえばいい
実践編
- Dispatcherの全体で占める実行時間の割合は低い
- ここでがんばる必要はない
- method呼び出しを減らす
- Devel::NYTProfを使ってから減らすmmethodを選ぶ
- Objectの生成を減らすのが有効
- ORMがオブジェクトを生成するので,使わない
- 生のDBIはいやだ
- DBIx::Connector, DBIx::DBHResolver, DBIの順にラップ
- DBIx::Connector DB接続を局所化
- Object::Containerでsingletonにする
- preloadオプションがついたのでこれを使うといいかも
- patchを書いたのはxaicronさん
運用編
- 次のセッションを聞いてね
まとめ
- Amon2を読むといい
- 新しいものを追求すると楽しい
- ore ore WAFを書くのは怖くない
nginx & Perl
自己紹介
- fujiwara
about nginx
- ロシア製
- 英語のwikiあり
- だんだん使われるサイトが増えてきた
- Architecture
- multi processes + non blocking IO
- 1 master, x workers
nginx module
- Upstream
- mod_proxy_blancer
- memcached
- キャッシュにmemcachedを使う
- empty gif
- 1x1 gif
- X-Accel-Redirect
- X-Sendfile
- Rewrite
- mod_rewriteより見やすい
- PerlっぽいSyntax
embeded perl
- connfigureで--with_http_perl
- mod_perlぽいもの
- 例
- accept-encodingで振り分け
- Imlib2で画像を小さくする
- HMAC_SHA1
- blockingする処理は書いては駄目
- sleepだけはasync.使いどころは不明
- 組み込んでも誤差程度のベンチ
- 有効にすると1割減
- Test::Nginx(CPAN)にある
with Plack/PSGI servers
- Reverse Proxy
- P::M::ReverseProxy
- topディレクトリじゃない場合
- rewrite /^app(.*) $1 break;
- plack側はUrlMapをやる
- CGIは動かせないのでPlack::App::CGIBinを使う
バウンスメール解析システム BounceHammerの紹介
自己紹介
- azumakyuniyuki
- サーバ管理者 -
前置き
- バウンスメールの処理は結構めんどくさい
- BounceHammerでできるよ
- 解析したJSON, YANL, CSVで出力可能
BounceHammer
- バウンスメール解析システム
- CLIツール
- Perl
- 配信機能はないo
バウンスメールについて
- From
- Postmaster
- MailerDaemon
- Subject
- エラーっぽいことを英語でかいてある
できること
- エラー理由特定
- あて先分類
- DBに蓄積
- 解析したJSON, YANL, CSVで出力可能
エラー理由
- あて先不明
- ドメイン指定拒否
- メールボックス一杯
- メールが大きすぎる
- セキュリティ的なエラー
役立つ場面
- 一般的なMTAで配信
- 特別なMTAだと処理できないかも
対象者
- コンテンツプロバイダ
- メールマガジンスタンド
- メルマガ配信している人
- バウンス処理をしていない人
放置されると困ること
- 携帯宛はブロックされる
- 有効配信数がわからない
- 遅延がひどい
- 遅延で配信に時間がかかる
バウンス処理はやるべき
- 配信数が少なくてもやる
- 1通でもやる
処理すると
- バウンスの理由が正確にわかる
- バウンスの記録を構造化して保存
- ウェブ管理画面でアドレス管理
- メール配信の合理化と健全化
- 自前でバウンス処理実装不必要
インストール
- 手順通りやればOK
解析済みデータの利用
- CSV, YAML. JSON
- MTAでバウンス照合
- 配信プログラムで照合
動かす
- mbox || Maildirを引数に
- STDINからも読める(/etc/aliases)
解析速度
mbox 500通/秒
- Maildir 200通/秒
出力コマンド
- datadumperというコマンド
- 携帯だけとか条件指定できる
MTAと強調させる
- YAMLがでるので適当に処理
ウェブサイトに組み込む
- HTTPベースのAPIを使う
- ユーザ毎のページに状態を表示
HTTP API
- readのみ
今後
- 2.6.0でエラーの理由を+=4
- なるべく国産モジュールを使いたい
- ORMは国産化完了 Skinny
- CGI::Application::を何かに変更
- APIで書き込み可能にする
YATT Yet Another Template Toolkit, Designed for WebDesigners
自己紹介
- h小林
- HKOBA CPAN
- @hkoba
- Perl/Tkの日本語化
YATT, What?
- CPANにあり
- 顧客のみ使ってる
- 実績は2年程度
ガラパゴス
- 振るカスタムのネットアンケート屋
- MSワードで入稿
- 作成2週間 使用1週間
- 素人を戦力化しなくては生きていけない
戦力
- プログラマ兼サーバ管理者 1人
- テンプレートデザイナ 7人
- 多少プログラミングっぽい感じでもOK
Why New Tempalte System
- プログラマの視点で既存のモジュールは作られている
- ページの追加もプログラマが必要
- HTMLとして汚い
YATTのアプローチ
- 自分で部品を作れる
- 外部に計算を追い出せる
- テンプレートの書き間違いは先に判明してほしい
- XMLを拡張
- Widgetが関数を呼び出す
- ViewがModelをたたく形
- 変数の自動のエスケープ
- yatt lint
SYNTAX:LRXML
- yattのネームスペース
- yattが正しければ,xmlとして正しくなくてもOK
Componet Model
- yattファイルにマルチパートっぽく書くと,perlのPackageに展開される
Embedded Variable
- 型指定ができる
- x=text, y=html
namespace can be DIR or File
- yatt:mylib:mypart
- 継承もできる
- .yattはpublic, ytmplはprivate
Macro Tag
- my, if, for
DEMO
- emacs用のシンタックスファイルが配布されている
- 存在しない変数を作ると,そのエラー行に飛んでくれるのでわかりやすい
動作速度
- うまく動かなかったのでカット
YATT::Lite
- github/hkoba/yatt_lite
Perl5 is Alive
- Perl is Dead
- 時代遅れ 薬でもやっているんじゃないか
- CPANに面白モジュールが一杯ある
- cpanm
- Moose
- Plack
- AnyEvent
- Devel::NYTProf
- 6ヶ月前にperl5.12を出した
- 緊張したけど,結果は良好
- Perl6は?
- 別の言語だから関係ないよ
- すごい言語
- まだ設計中
- でもPerl5もこれからの言語
- Perl5,Perl6の5,6はversionじゃなくて,それを含めて言語名
5.12でかわったこと
- 5.10の機能が安心してつかえる
- use 5.12.0で自動でuse strictされる
- Y2038対応
- Unicode5.2に対応
- Pluggable Keywords
- 関数ルックアップがオーバーライド可能になった
- Dtrace support
- coreからはずされたモジュールもある
- yadda yadda ...
- perldoc perldelta512
リリースに関して
- Pumpkin
- patch pumpkin
- 変なリリースをしないように管理
- 5.10はリリースまでに5年
- 間に二人のPumpkinが燃え尽きた
- 35万行の変更
- メンテナンス作業が多すぎる
- 5.10.1ほPumpkinがしんどいと発言
- Pumpkinの仕事が多すぎる
Pumpkinになるには
- Hardcore C Hacker
- 強い責任感
- ハッカーをつれてきてマネージャーをやらせる
- 資源の無駄
- 燃え尽きて繰り返しやれる人はいない
システムの構築しなおし
- 役割をわける
- わけられるところは別の人に
リリース
- リリース感覚が一定になってきた
- 開発版はリリースマネージャがやる
- Pumpkinじゃない
- メンテナンスには機能はあまり追加しないようにした
- 悩むようなパッチは取り込まれない
- ポータビリティ
- セキュリティフィックス
- 5.13.xは3ヶ月ごとにリリース
5.14.0
- 2011/04
- 望むもの
- IPv6
- CPANを簡単に
- HTTP Client
- SSL
perbrew
- どんなバージョンのperlもホームディレクトリにインストールできる
Question
- Unicode6.0に対応するか?
- 追加したいけど,互換性も問題があるっぽい
- 問題を把握したい
- リリースを一定にしているとディストリビューションに新しいのが含まれやすい
- JSON::PPは入るけどJSON::XSはなんでコアに入らないの?
- ポータビリティを重視
- XSがなくても他のモジュールがはいる
- すげー速いJSONでなくてもいい
Perlで任意精度計算
自己紹介
- 牧大輔
- JPA
基本のおさらい
- float 整数部3桁,小数部7桁
- データ量がたりないよ
- エラー幅が大きくなる
- 1.1 * 1.1はOK
- 1.0999 * 1.0999だと誤差が大きいよね
- 整数はいいけど,小数は危ない
なぜ必要なのか
- DateTime.pmで旧暦をかいてみた
- CALENDRICAL CALCULATIONS
- いい本
- すげー眠くなる
旧暦
- 月と太陽の緯度
- 地球から観測した月・太陽の緯度で決まる
- 24節気
Lunar Phase
- 月の満ち欠け
- 定期的な観測
- 29.5日(平均)
Solar Phase
- 春夏秋冬
- 農業用
- 365.5日くらい
月と太陽の関係
- 時計の長針が太陽,短針が月
天体の位置計算
- 高精度が必要
- 0.000011574ずれると計算が1秒狂う
Perlで計算
- perlで1/86400をやっても小数の桁が足りない
- 実際は小数点以下59桁
- perlは19桁目で丸め込み
Math::BigInt(BigFloat)の問題点
- 文字列を与える必要がある
- 数字だとPerlがまるめることがある
- 1 value = 1 object
- 遅い!
- 700倍から600倍とか遅い
- Math::BigInt::GMPも遅い
Goodbye Perl
- Cでやる
MPFR
- GMPじゃなくてMPFR
- GMP+Higer Level Math
- 三角関数とか
MPFR vs BigInt
- 54倍!BigIntより速い!
- 実用可能なレベル
任意精度計算
- PerlやLL向きではない
- Cを使おう
- Perl側では常に文字列にすること
- 文字列で数値を返す
- 精度が高すぎてこまる
- 自分で丸める必要もある
XSからPPへ
自己紹介
- まかまか
- Acme大全 2010
- CPAN
- JSON, Text::CSV
- CPAN XSのもの
- Thread::State, JSON::PC(削除)
- github: makamaka
XS
- PerlとCのグルー
- メモリリーク
- 作るの大変
PP
- Pure Perl
- XS使ってない
- Cコンパイラは使わない
メリット
- 暇つぶし
- 勉強になる
- ポータビリティの向上
- Perl API, XSの知識
デメリット
- 遅い
- メンテが大変
- 車輪の再発明
PP化の流れ
- PP化するモジュールを選ぶ
- t/*ファイルがたくさんある
- テスト自体がAPIの一覧になっている
- typemapを確認
- やる気が出るか
- テストが通るように書く
- ブラッシュアップ
- パッケージ
PP化時によく使うかもしれないもの
- B
- 値のフラグを確認できる
- pack/unpack
- バイナリ操作
- 進数の変換
- perldoc perlpacktut
- Config
- perlのコンフィグを確認
パッケージング
- バックエンドの統合
- XSモジュールが使えればXS
- 駄目ならPP
- 環境変数の選びかた
- PERL_をつけるとぶつかりにくい
- PERL_ONLYとかいいよね
Unix Programming with Perl
正しいコードを書くために
- testは確認手段
- OS, Perlの知識が必要
- OSの話は少ないので今回扱う
エラーナンバーをチェックする
ディレクトリ作成の場合
- !-d $dirでチェックしてから作成するのは処理の間に別のプロセスが作っているかもしれない
- とりあえずmkdirしてみて,メッセージを確認
- まだ駄目.メッセージが異なる(OS, Local)
- Errnoを使う
$!
- dualvar
- 数値と文字列の両方を持っている
- Errnoが数値定数の一覧を定義
エラーコードを調べる
- manで調べる
- man 2 mkdir
- 2はシステムコードの意味
- POSIXのはOpenGroupのを参照するといい
forkとファイルハンドル
- forkしてもファイルハンドルは複製されない
- 親と子で共有
- forkしても同じ構造体を指しているため
- 開きなおせば,別の構造体を作ってもらえる
対策
- File handleだと単純に閉じればいい
- DBIはundefしちゃ駄目
- InactiveDestoryを使う
- 終了処理をせずにクローズだけする
- POSX::AtForkとかでforkをフックして処理することもできる
UNIXシグナル
SIGPIPE
- ファイルハンドルにデータを書こうとしたときに,書けない場合はとめる
- $SIG{PIPE} = 'IGNORE'
SIGALRM
- timeoutとか
- メリット
- 多くのシステムコールで使える ^ デメリット
- プロセス毎に1個しか使えない
シグナルで処理をする
- $SIG{TERM}とかでフラグを立てて,メインループでチェック
注意点
- waitと相性が悪いのでProc::Wait3をつかう
PMグループディスカッション
Hokkaido.pm
- onagatani
- 北海道 帯広
- Perl 5年
- とりあえずML作ってみた
- 人数が集まらない可能性がある
- JPA 牧さん助けて!
- メンバー
- 札幌多数
- CPAN Autor 4名
Yokohama.pm
- clouder
- 在住 世田谷
- 日本で7つ目
- 横浜中心のPerl Mongersがゆっくり参加する場がほしい
- 初心者トークで参加しやすい
- 開催規模 4,50名
- 飲み会の参加率が90%以上
NagoyaでPerlをゆるく語る会
- issm
- 名古屋在住
- 多言語の勉強会はあるけど,Perlのはあんまりない
- 月1回 定期的に
- 10名前後
- @yuruperl
- Nagoya.pmの申請を昨日した
Kansai.pm
- lapis25
- 兵庫
- 2000/03設立
- リーダーがいない
- 有志による運営
- ミーティング 年1,2回
- 土日開催
- 勉強会
- フレームワーク勉強会
- Perlベストプラクティス勉強会
- Perl翻訳フェスタ
- イベント
- OSC
- KOF
- その他
- 新年会
- 忘年会
- ぼたん鍋ツアー
Fukuoka.pm
- debility
- Satoshi Hirata
- 2007/11
- 懇親会がすごい
- すぎやまさんありがとう
Okayama.pm
- @canadie
- C/PHP/Perl
- 岡山にpmがないので設立
- 8人
- 人が集まらないので問題点もでない
ディスカッション
できること,できないこと
- 福岡 合同でイベント
- 横浜 Shibuya.pmから流れるので人は集まる
- 北海道 札幌以外は会場がない
地方PMのホンネ
- 名古屋 個人的にはPHPが多く,Perlが少ない
- 岡山 人がいない.車がメインなので飲み会がない
- 関西 人が定着しにくい.メンバーの固定化
- 名古屋 技術レベルは高くなくていいのか?
- 東京 飲み会がメインなので技術レベルは気にしていない. 二人で飲めばPMだ.気軽に参加できるのがあるべき姿
他のPMへの質問
会場の探し方
- 北海道 札幌はたくさんあるので苦労はない.地方に行くと会場がない.専門学校に掛け合った.平日は厳しい
- 関西 企業に借りたりする.借りた場合はお金がかかるので,学生向けに学割を用意する
- 福岡 誰かの会社
- 渋谷 miyagawa 会場を先に決めるとリミットが決まるので困るんでない
開催日
- 横浜 金曜日にやる
- 岡山 アンケートで平日が多いため
- 福岡 土曜が多い
他コミュニティとのかかわり
- 北海道 OSC, localがある
- 福岡 互いにフレームワークの話.Ruby, PHPとかと
- 岡山 他のコミュニティはあるので,今後やりたい
メンバーの平均年齢と男女比
- 男性がたいてい多い
- 女性は多くて2割
運営の仕方の工夫
- 北海道 初心者向けにやろうとはしている
省サーバ運用
自己紹介
- 小林
- nekokak
- DBIx::Skinny
きっかけ
- 退職
- 一人でシステム開発
- 大規模サーバ入門
- この技術が必要か?
- 圧縮とかいらねーよ
- NoSQL!!
- RDBMSを極めよ
- Mixi/DeNA/Gree/etc
- システムは大規模か?
- 情熱プログラマー
- エンジニアが持つべき意識を共有する場をつくりたい
- インフラとWebアプリ開発の両方をやってみての感想とか工夫
- 保守も地味
- 動いて当然
- 誰も評価しない
- でも大事
これからのエンジニア
- 開発能力
- インフラへの理解
- 自分がどれだけの利益を出しているか
- インフラの費用
基本エンジニアリングのお話
- サーバ6台
- 1/2ラック
- 前職の1/50くらい
- ベンチャーなのでお金がない
- 6台でもがんばった
- 値切りまくった
- 適正な価格で購入することが重要
- DB2, Web3, 開発1
- DBのメモリっが8GB, Webメモリ4GB
- SlaveのサーバではQudoのJobサーバも兼任
- LBにPerlbal
- 安定性抜群
- Perl製
- Pluginをかける
- なぜnginxじゃないのか
- x-reproxyさせたい
- x-reproxy-cacheがない
Perlbal
- シングルスレッドなソフトウェアロードバランサー
- SSLも使える
- 他のLBよりノウハウがある
- Webサーバの機能もある
App
- Starlet
- Apache/mod_perlは使ってない
- Server::Starter + Starlet
- kazuho製なので安心
画像の管理方法
- rsyncで動機
- ないわー
- ないわー
- ないわー
- Web 1.0
- DBのBLOBに格納
- 遅い
- Web 1.5
- MogileFS
- おすすめ
- NFS
- DRBD
MogileFS
- X-ReproxyヘッダをLBが解釈する必要がある
- PerlbalなんでOK
- 管理用のMySQLが必要
- 物理的に2台のサーバが必要
- App*2に同居はいやだ
- 将来的に移行できる形にすればいいや
- X-Reproxy-CacheはAppサーバへの問い合わせを回避できる
- X-Reproxyの先をPerlbal自身にすればいい
まとめ
- 大規模サービスの中身は気になる
- 自分の環境にマッチするかを立ち止まって確認する
- 技術的にとんがってないと生きていけない
- コスト意識をもって行動/提案できるエンジニアかどうか
Lightning Talk Day Two
Keynote
メモしてないです!!
YAPC::Asia Tokyo 2010 一日目
Moderl Perl Web Development on Amazon EC2
PSGI
- PSGI APP = coderef
- sub { [ $status, [ @Headers ], [ @Body ] ] }
Plack
- PSGIの実装
- plackupの使い方
- サーバ実装を切り替えられる
- Starman, Starlet
- gracefulに対応しているかどうか
- DelayedとShotgunどっちがいいのか
- ベンチとって使うといい
- miyagawaさんが解説が違うと突っ込み
- Server::Starter
- start_server
- --port
- --interval
PSGIアプリの書き方
- 自分で作るのがお勧め
- CPAN Moduleを使うと簡単にかける
- Plack::Request
- 継承して必要な部分を追加
- parametersをflagged utf8に変換
- DBIx::Skinny
- Router::Simple
- 昨日も紹介されていた(TODO 後で確認)
- JSON::XS
daemontoolsとは
- daemontoolsからstart_server
daemontoolsのコマンド
- svc
- -u 起動
- -h SIGHUPを送信
- -d 停止
daemontoolsの注意点
- runファイルでexecする
- runファイルの書き換え後は-dしてから-u
- サービス停止時はmvで.hogeにリネーム
cpanmの使い方
- cpanm -l extlib Starman
- アプリケーション用のユーザを作成してその$HOME以下でアプリ作成
Amazon EC2環境での構築
EC2のサーバ環境
- web
- small instance
- db
- large instance
- mysql5.1
構築の祇園
- IPアドレスが変わる
- Disk内容が保持されない
- 負荷分散
- アプリケーションのdeploy
IPアドレス
- Elastic IPでDNS, Global IPを固定
- webサーバはauto scale
- dbサーバは使ってる
- amazonのDNSに対して,ElasticIPで取得したDNS名を問い合わせ
DISKが消える
- instanceを消すと消える
- EBSブートを使ってる
負荷分散
- instanceを増やせばいい
- オートスケールを使えば自動で負荷分散
- CPU Usageなどで閾値を設定すると勝手に増減する
デプロイ
- オートスケールはイメージから起動なので,元のインスタンスイメージを更新する
- 何かツールは?
- テスト用にElasticIPをとる
- ここでテストして問題なければイメージ化
- 後はオートスケールにまかせる
- NAS, NFSを使う人もいるらしい
感想
- 開発作業に得に違いはない
- daemontools + Server::Sterter + Starman
- ElasticIP
- オートスケールが便利
まとめ
- Plack
- Starman
- cpanm
- daemontools
- amazon特有の環境に注意
最近のPerlなものづくりの事例
- RECRUIT
- Toshimasa Ishibashi
MTLProject
- 自前サービス運営
- 演劇ライフ
- コマーシャライザー
- ハモニナ(携帯系)
- docomo公式コンテンツ
- モバゲー SocialApp
- ATND
- 調整さん
個社ホームページサービス
- Perl CMS
- suumo.jpからcentury21.on.s-bs.jpとかにデータを抽出
- TypePad + 検索
- エントリー入力
- JavaScriptでごりごり
- お店のミカタ ほっとペッパーでも同様のサービス
- 10人前後を色々割り振って開発
VMwareで開発
- 各個人にVMwareをinstall
- subversionで管理
Test
- test code
- Model(ビジネスロジック) ここは100%にする
- View + Controller
- どう書いてるの?
- production, stagingでもsvn up後にprove -r .
- staging, productionのsvn upはリーダーが手動!
- リーダーがmergeをごりごり
- テスト専用のデータベースが環境ごとにある
CPAN
- cpan installしたモジュールは全部 svn addする
- $HOME/site_local_envにPERL5LIB等を追加する
- make installした*.soもsvn add
- 全環境でOS等をあわせる必要がある
*.conf
- ln -s /etc/my.cnf $HOME/etc/my.cnf
- my.cnf.personal, mmy.cnf.staging, my.cnf.productionを$HOME/etc/my.cnfにln -sする
サーバ環境
- ユーザ認証はRECRUITでシングルサインオン web apiを用意
- Perl FrameworkはPlack
- xen server
その他
- エンジニアは企画から参加
- backlogでリポジトリ等を管理
Mashup Awards
- llevalも使える
- R25 API
- mbga
- NHK
30days Albumの裏側
30daysの裏
- Web Ruby on Rails
- mogilefs
- gearmn
- schwartz
- HTTP APIを使用
- RESTを意識
MogileFSの障害対応
- コピーを確認
- file_on
- X-REPORXY-URLを確認
- Perlbalを再起動
- X-REPORXY-CACHE-FOR
MogileFSの利バランス
- データの平準化
- バックグランドで動作
- ストレージを追加・削除時に使う
FLVのストリーミング
- Perlbal pluginを作成
- FLVヘッダをボディに追加
- フックポイントを追加
ソーシャルアプリ向けのシステム監視運用の勘所
- tcpdumpで確認
- DBのチューニングが遅かった
- tcpdump + wiresharkでok
- リクエストの開始からなのでレイテンシを気にする程度
- 自宅 10ms
- EC2 100-200ms
Perl and C binding: new and upcoming ways
- c_ushort
- PerlDLL
- Libperl++
- goal c++
- for calling perl xs funxtions
- provides xs environmenent for called funciton
Libperl++
- Cからperl packageの呼び出しの例
- Ref
testr = universe.package('Tester').call('new',1); - Any Perl Variable have take_ref().
- custom type convertion
- structも作れるよ
ExtUtils::XSpp
- Module::Build::WithXSpp
- c++をtypemapを用意すればかなり普通に使えるっぽい
質疑
- crossplat form
- libffiに依存
Studying HTTP with Perl
PerlにおけるHTTPクライアントの紹介
並列じゃないもの
- LWP::UserAgent
- デファクトスタンダード
- LWP::Simple
- LWP::RobotUA
- Robot用
- URI::Fetch
- LWPのラッパー
- Etag, LastModifiedに対応
- キャッシュ対応
- HTTP::Lite
- 依存なし
- httpsに未対応
- LWPx::ParanoidAgent
- ローカルネットワークへのアクセスを拒絶
- DNSの検証
- WWW::Curl
- perl binding of libcurl
- 速い
- 癖がある
- ラッパーがいくつかある
並列リクエスト可能なもの
- お勧めじゃないもの
- HTTP::Async
- みのがした
- AnyEvent::HTTP
- Coro::LWP
- Coroとは
- Perlでコルーチンを実現するライブラリ
- お勧めだけど考えて使う必要がある
LLによるネットワーキングプログラミング
- 相手の処理待ちが多いからLLでもOK
- だけどLWPは遅い
- ベンチマークをとる
- LWPで200req/s
AnyEvent::Curl
- on github
- LWPの8倍速い
- WWW::Curlとの違い
- ブロッキングしていいのかどうか
- event駆動のサーバの場合
- LWP互換機能
- WWW::Curl::Multiがベース
並列処理
- thread バグってる
- forkによるマルチプロセス
- IO多重化+イベント駆動
- forkのメリット
- マルチコアの生かせる
- forkのデメリット
- 生成コスト
- メモリ
- イベント駆動
- 省メモリ
- Perlだとイベント駆動+prefork
Preforkの話
- prefork型はDoSに弱い
- フロントにイベント駆動のロードバランサをおく
- プロセス数を調節する
- ピークリクエストと処理時間がわかれば,必要なワーカーを計算できる
イベント駆動向きなもの
- 予想できなければイベント駆動が向いている
- フラグを使った強調動作
- 1ホストに対するリクエスト数の管理とか
- クローラは相手のスペックがわからないのでイベント駆動がいい
チューニング
- HTTP::Responseが遅い.HTTP::HeadersをXS化
- 名前解決のコスト
- WWW::Curlは非同期解決のオプションがある
- パフォーマンスが劣化する
- 外向けのクローラーはSquidを通すと楽
RPCのプロトコル
- HTTPでいいんでない
- HTTPのメリット
- みんな知っている
- HTTPは別に遅くない
テスト
- Test::TCP
- Plack/PSGIで簡単サーバを作る
- ローカル環境だけで動くようにする
非同期処理の通知処理 with Tatsumaki
CGI
- $|でautoflushをonにする
- long-polling
- multipart/mixedで送信
- クライアント側ではDUI.jsで処理
- 大量アクセスを裁けない
- C10K問題
PSGI/Plackストリーミング
- めんどくさい
- coderef coderef coderef ...
- 全部IO処理を非同期にしなければならない
どうやって簡単にするか
- Tastumaki::Handler
- Tatsumaki::Application
- Gearman
- jobはMyJobとか作ってその中にjob_hogeなメソッドを定義
- Class::InspectorでMyJobからジョブを読み出す
- AnyEvent::Gearmanがクライアントにはいい
- WebService::Async
Writing prefork job workers / servers
Parallel::ForkManager
- 便利
- shutdown方法がない
Parallel::Prefork
- シグナルで子プロセスを制御できる
- 親が受け取ったシグナルを子プロセスのシグナルに対応づける
- graceful
- dynamic scaling
- P::P::SpareWorkers
- 非推奨
Server::Starter
- 去年のLTと一緒
- 環境変数をみてfd_openですでに開いているソケットを使うだけでSS対応できる
Parallel::Scoreboard
- リソース監視
- mod_statsuっぽいものを作成しやすくする
- 監視側
- Paralle::Scoreboard::PSGI::App
- Paralle::Scoreboard::PSGI::App::JSON
2010/10/08
How to use App::CLI
App::CLIの使い方
前置き
Web Applicationを書いていると管理用だったり,集計用だったりのscriptが必要になります.
今まではこれをbatch/とかに書き散らかしていました
これはメンテナンス性も悪いし,svnとかgitみたいにサブコマンドでなんとかしたい
そこでApp::CLI.
メリット
- 簡潔にCLIプログラムを作成することが可能.
- 依存モジュールも少ないため気兼ねなくインストールもできる.
- SVKとかで使われてるようなので多分それなりに安定しているはず.
- コマンドラインオプションの書き方はGetopt::Long
デメリット
- ドキュメントが少ない
実際に使ってみる
大きなモジュールじゃないので使いながら覚える. とりあえずこんな感じになるようなCLIを作ります
$ myapp.pl help # なんかヘルプメッセージ表示 $ myapp.pl print hoge hoge $ myapp.pl print --uc hoge HOGE $ myapp.pl print --ucfirst hoge Hoge $ myapp.pl sum 1 2 3 Sum 6
できた!!
こんな感じのファイル構成.
yoshi@mb app-cli% tree . |-- lib | `-- MyApp | |-- Command | | |-- Help.pm | | |-- Print.pm | | `-- Sum.pm | `-- Command.pm `-- script `-- myapp.pl
解説
起動スクリプト
script/myapp.plの中身はすっきり
#!/usr/bin/env perl use strict; use warnings; use FindBin qw($Bin); use File::Spec::Functions qw/catfile/; use lib catfile($Bin,'../lib'); use MyApp::Command; MyApp::Command->dispatch;
Dispatcher
DispatcherのMyApp::Commandの中身もすっきり
App::CLIを継承して終了
package MyApp::Command; use strict; use warnings; use base qw(App::CLI); 1;
Command
では肝心のコマンド部分.
こちらはApp::CLI::Commandを継承して作成する
myapp.pl print hoge
このprint部分がucfirstされ,MyApp::Commandとあわせてクラス名を生成する.
結果,MyApp::Command::Print->run(@args)が実行されます.
runは固定.
MyApp::Command::Printはこちら.
package MyApp::Command::Print; use strict; use warnings; use base qw(App::CLI::Command); sub subcommands { qw/uc ucfirst/; } sub options { ( 'strings|s=s' => 'strings' ); } sub run { my $self = shift; my $strings = shift || $self->{strings} || $self->usage; print $strings, "\n"; } package MyApp::Command::Print::uc; use strict; use warnings; use base qw(App::CLI::Command); sub run { my $self = shift; my $strings = shift || $self->{strings} || $self->usage; print uc $strings, "\n"; } package MyApp::Command::Print::ucfirst; use strict; use warnings; use base qw(App::CLI::Command); sub run { my $self = shift; my $strings = shift || $self->{strings} || $self->usage; print ucfirst $strings, "\n"; } 1; __END__ =head1 NAME MyApp::Command::Print - apply uc(first)? to string and print it =head1 SYNOPSIS myapp.pl [--strings|-s STRINGS] [--uc] [--ucfirst] STRINGS =cut
順番に解説
- options
- subcomands
- pod
options
Getopt::Longに食わせるオプション設定を配列で定義する.
細かい使い方はGetopt::Longを参照すること
指定したオプションはモジュール内で$self->{$key}で利用できる.
subcommands
ここで定義したサブコマンドはそのままBool型のコマンドラインオプションになる.
この場合は--uc, --ucfirstがオプションに追加される.
定義したサブコマンドはMyApp::Command::Print::$subcommandとして実装する.
注意点はこのサブコマンド側でオプション定義等ができないこと.
必要であれば親コマンド側で定義しなければならない
pod
helpコマンドで表示されるのでNAME, SYNOPSISは書いておくといい感じ.
yoshi@mb app-cli% perl script/myapp.pl help help - show help message print - apply uc(first)? to string and print it sum - sum rest arguments yoshi@mb app-cli% perl script/myapp.pl help print NAME print - apply uc(first)? to string and print it SYNOPSIS myapp.pl [--strings|-s STRINGS] [--uc] [--ucfirst] STRINGS
最後にhelpコマンドの実装
これだけ特殊.
最初からApp::CLI::Command::Helpというモジュールがあるので,これを継承して終了.
MyApp::Command::Helpの中身
package MyApp::Command::Help; use strict; use warnings; use base qw(App::CLI::Command::Help); 1; __END__ =head1 NAME MyApp::Command::Help - show help message =head1 SYNOPSIS myapp.pl COMMAND =head1 COMMAND help, sum, print =cut
まとめ
思ったより小粒なモジュールなので楽に読めた.
依存が少ないのは利用しやすい.
App::Cmdよりわかりやすい.
他にお勧めフレームワークがあれば教えてください.
作成したコードはgithubにupしてあります.
URL: http://github.com/ysasaki/p5-testing-app-cli
2010/10/06
Test::Fixture::DBI::Console
作成の動機
Test::Fixture::DBIには既存のDBからテーブル定義と中身をdumpするツールが付属しています.
これを使うとさくっとテスト用のfixtureが生成できます.
生成したFixureを書き換えて使ってもいいのですが,yamlだと量が増えたときに閲覧性が低いと感じました.
そこで使い慣れたmysqlのconsoleっぽく見れると便利なんじゃないかと思い,Test::Fixutre::DBI::Consoleを作成しました.
追記
これは内部でTest::mysqldを使ってfixutre作成専門のmysqldを立ち上げます.
配布場所
現在はgithubのみです.PAUSE IDが貰えたらCPANも考えます.Test::Fixutre::DBI::Console
使い方
Test::Fixture::DBI::Consoleをinstallすると"test_fixture_console"コマンドもinstallされます.このコマンドでshellに入ります.
まずはテーブル定義とデータを生成します.
yoshi@mb yoshi% test_fixture_console mysql fixture> create table hoge (id int primary key auto_increment); Affected 0 rows fixture> show tables; +----------------+ | Tables_in_test | +----------------+ | hoge | +----------------+ Affected 1 rows fixture> insert hoge (id) values (1),(2),(3); Affected 3 rows fixture> select * from hoge; +----+ | id | +----+ | 1 | | 2 | | 3 | +----+ Affected 3 rows # DBと中身をyamlに書き出し fixture> make_database test1.yaml Create database schema file: test1.yaml fixture> make_fixture test1_fixture.yaml Create fixture file: test1_fixture.yaml
先ほど書き出したyamlの中身
yoshi@mb yoshi% cat test1.yaml --- - data: "CREATE TABLE `hoge` (\n `id` int(11) NOT NULL AUTO_INCREMENT,\n PRIMARY KEY (`id`)\n) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=latin1" schema: hoge yoshi@mb yoshi% cat test1_fixture.yaml --- - data: id: 1 name: 1 schema: hoge - data: id: 2 name: 2 schema: hoge - data: id: 3 name: 3 schema: hoge
test1.yamlとtest1_fixture.yamlをloadしてみます.
yoshi@mb yoshi% test_fixture_console mysql fixture> show tables; +----------------+ | Tables_in_test | +----------------+ +----------------+ Affected 0 rows fixture> construct_database test1.yaml Load database schema from test1.yaml fixture> show tables; +----------------+ | Tables_in_test | +----------------+ | hoge | +----------------+ Affected 1 rows fixture> construct_fixture test1_fixture.yaml Load fixture from test1_fixture.yaml fixture> select * from hoge; +----+ | id | +----+ | 1 | | 2 | | 3 | +----+ Affected 3 rows
TODO
- テスト足りなすぎ
- PODもちゃんと書く
- SQLiteでも動かしたい
- モジュール名はこれでいいのか
- 明らかにリファクタリングが必要
2010/10/03
Hokkaido.pm #2
今回は初めてスピーカーをやらせて頂いて大変勉強になりました.
需要があるかわかりませんが,一応slideshareにアップロードしましたので
興味のある方はご覧ください.