YAPC::Asia 2008 2日め
英語難しかったので聞き取れているか微妙
- TAKESAKOさんのセッションで記憶違いの部分があったようなので取り消し線をいれました.
You're Doing OO WRONG - Micael G Schwern
$thing->method(@arg); # method(\%thing, @args)
- a good object is a good janitor(用務員?)
- オブジェクトは誰が使うかとかどのように仕事をするのかではなく,仕事そのものにだけを注視すべき
# local host opendir $d; $dir = dir('/foo/bar'); $dir->open(); # remote host $dir = dir('user@host:/path'); $dir->open()
- inheritanceはよくない.
- 継承は木構造で表現されるが,そんなにうまい具合に木構造になるわけではない
- multi-inheritance
- diamond inheritance
- Class::DBI複雑過ぎ
- compositionがよい
- has_a
- traits/roles
- Moose
- コードが短くなり,かつオブジェクト指向
- こんだけ
use Moose; has 'thing', is => 'rw';
- extendsで継承できるが,やりすぎはよくない
extends 'IO::Socket::INET', 'JSON::Parser';
has 'socket', is => 'rw', isa => 'IO::Socket::INET', default => sub {IO::Socket::INET->new}; has 'parser', is => 'rw', ...
- これでオブジェクト生成時にnew(socket => $socket, parser => $parser)と指定する
Moose - Yuval Kogman (nothingmuch)
- charsbarさんによる翻訳
- Moose is not
- experimental
- toy
- accessor builder
- source filter
- black magic
- modern object framwork
- syntax sugar of Class::MOP
- CLOS, Smalltalk, Perl6の影響
- simple example
- 引き続きexample
- hasのdefaultsに指定するとnewで指定されない場合はsetされる
- lazy=1ならばこれを実際に必要になるまで送らせる
- isaで型指定
- type
- 階層構造を持っている
- Item -> Defined -> Ref -> Object
- 階層構造を持っている
- type coercion
- 型を強制的に変換する
- 引数にしてnewしてオブジェクトをsetするとか
- handles
- 属性に委譲する
- MooseX::AttributeHelpers
- push => add_employeesのように属性の配列に対する操作に委譲できる
- before/after/around
- メソッドの前後にフックをかける.
- augment/inner
- abstract method
- subtype
- 型の定義
- ArrayRef[Employee]やEnglish | Japaneseのような表現もできる
- whereで条件指定
- role
- interfaceよりもパワフルで,mixinよりも安全
- withでroleを追加する
- roleはinheritanceではなくcomposition
- MOP
- metaobject protocol
- Moose::Meta::Class->creat()で作成
- 属性やメソッドを追加して,クラスを制御する
- こんな仕事があったよ
- 欠点
- ロード時間がかかる
- MooseX::Compileがあるよ
- その他遅い部分がある
- non-hashbased class is tricky
- MooseX::GlobRef::Objectがあるよ
- ロード時間がかかる
- 利点
- 質疑応答
- use fields使ってもうまく動く
- うまく動きます.
- subtypeのチェック時にexceptionを投げることできる?
- オプションを設定すれば
- defaultsをオーバーライドできる?
- オプションを設定すれば
- use fields使ってもうまく動く
How to defend Apache/CGI against multibyte XSS attacks - Yoshinori TAKESAKO (takesako)
- Yet Another Profile - Yoshinori TAKESAKO
- YAPC::AsiaのパンフレットはHDRを利用している
- 最近はまっています
- 流行っているよ.町田周辺で
- サウンドハウス
- クレジットカードの情報漏洩した
- IPJの報告
- まあ,大人の事情がありますし
- 利用している商用ソフトのバグだったり
- OSSのバグだったり
- いつでもいじれると思っていたけどどこを修正すればいいのかわからない
- 作者に指摘したけど,聞いてくれない
- そこでわっふる
- セキュリティ関連でいろいろ試しているサイト
- mod_imagefight
- http://wafful.org/mod_imagefight/
- 昨日のGIF89aのように画像の中に攻撃コードが.
- ブラウザのバグなんでアプリ側が対応するのもなんだか
- apacheで攻撃コードを含む画像をフィルタする
- 以下のように指定できる
<Location /foo> AddOutputFilter imagefight .png </Location> <Location /bar> AddOutputFilter imagefight image/jpeg </Location>
- HTMLを
サニタイズ->escapeしてもだめなケース - マルチバイト文字をブライザが誤って解釈してXSSになる場合.
- IE6でshift-jisの文字列をeuc-jpとして表示させると,マッピングのない文字が誤解釈されて"となる
- これを応用して,以下のvalueのところにその文字列を入れるとスクリプトを入れることができる
... <input type="text" value="...."></input> ... <script> ... </script>
-
'<>'は表現できないのでinputの下にscriptの閉じタグがなければならない私の記憶違いのようでした.すみません.
- mod_wafful
WaffulInputFilter on <Location /foo> jsonp regex:^[A-Za-z_0-9]+$ </Location>
Introduction to DBIx::MoCo - Naoya Ito
- naoyaのはてなダイアリー
- O/R Mapperを自作した
- なぜ自作したのか
- パフォーマンス面を考えると泥臭いこともできるようにしたかったので
- なぜ自作したのか
- 特徴
- SQL操作はCDBI/ActiveRecord
- リスト操作はRubyのように
- Cache::Memchachedによる透過的なキャッシュ
- test fixture
- CPANにupしている
- forceが必要かも
- bookmarkの例
- データベースドライバとしてDBIx::MoCo::Databaseを継承したBookmark::Database
- 各モデルに対して,DBIx::MoCoを継承した基本クラスBookmark::MoCoを作成
- Bookmark::Mocoを継承して各モデルクラスを定義する
- retrieve
- AUTOLOADを用いてretrieve_by_(...)で()の部分をキーとしてを検索する
- search
- create/update/delete
- ActiveRecordっぽい
- リスト操作
- $entries->grep(...)->collect(...)->sum()のような操作
- 他にも使えそうなのでList::RubyLike
- relationships
- has_many,has_aがある
- DBからオブジェクトを取得するときにhas_aの先も取得したい場合は{with => [qw/owner/]}のように指定する
- 透過的なキャッシュ
- cache_object->($cache)と指定するだけで,自動的にキャッシュされるようになる
- start_session, end_sessionを明示的にしていしないとうまくいかないことがある
- テスト
- fixtureを使うことでテスト時にyamlファイルからデータをロードすることができる
- 名前をつけれるのでどのregressionテストのレコードかがわかる
- 利点
- シンプルで簡単
- リスト操作がかっこいい
- キャッシュ
- test fixture
- 欠点
- ドキュメント少ない
- テストのカバレージが低い
- バグもある
- 質疑応答
- 複合キーのキャッシュも可能?
- 可能.ただし,必要な所だけキャッシュしており,細かなコントロールはできない
- 複合キーのキャッシュも可能?
- スライドがupされていました
- Introduction To Moco
Perl Love for JavaScript Hackers - Ingy döt Net
Perlとリアルデバイスを繋げるって快感 - Kazuhiro Osawa (Yappo)
- なんか流れた
Perlの!数学!妄想夢芝居 - Shinya Hayakawa
- 芝居が始まる
- 私のuse strictをとらないで
- ひっとえんどら〜ん
- テラカオス
- Perlで書かれたコードのコード(表の世界)
- Cで書かれたコード(裏の世界)
- オイラーの公式
- 3次方程式の解の公式は虚数を扱う
- perlのバグ
- overload::constant
- エスケープ文字を正しく扱えない
- \,$,@,%の文字を扱えない
- P = {s ∈ S | syn(s)} ... Sは文字列の集合だったかな.synはperlとしてsyntaxが正しいという意味
- B = {Bop(p) | p in P} ... Bopはpのopecode
- G : P上の全ての置換
- O : B上の全ての置換
- 予想: Gの部分群にはOと同型になるものが存在する
- wakaran
Architecture of Pathtraq - building a computation-centric web service - Kazuho Oku
- Kazuho Oku's Weblog (跡地)
- PathTraq
- Alexaのようなアクセス解析サービス
- ユーザにツール(ブラウザ上)をインストールしてもらってアクセスしたサイトの統計情報を取得する
- どんなサイトをよくみているかのランキングを作る
- ニュースのページなどカテゴリに分けている
- キーワードで検索
- 日付をしてして表示できる
- 複数のサイトを比較できる
- ロングテール
- ヒット数が1/10になると,そのURLの数は2.75倍になる
- ユーザ数 6300
- スケールアウトするかどうか
- スケールアウトすることによるオーバーヘッドもある
- データサイズ vs. ムーアの法則
- ハードウェアのコストは下がる
- データサイズは増える
- データサイズに対してハードウェアのコストが高いうちはスケールアウトすべきでない
- 3年目以降はハードウェアのコストが下がる
- 構成
- 特徴
- 圧縮による省メモリと高速化
- innodbだと3MB/sec
- on-memoryにすべき
- キャッシュコントロール
- 信頼できる高速なキュー
- 圧縮による省メモリと高速化
- 圧縮
- データはurl, referer, いつアクセスしたかなど
- 短いデータなのでgzipを適用するのは効率的でない
- 事前知識を利用した圧縮アルゴリズム
- 圧縮した状態でインデックスを利用できる
- static PPM (Prediction by Partial Matching)
- used by 7-zip
- バックエンドにrange coder
- ソート可能
- mysqlにuser defined functionとして実装
- 4MBの事前知識
- 37%の圧縮率
- 以降よくわからない
- innodb plugin
- url 57% compression
- innodb 50%
- both 33%
- counter compression
- sparse array
- キャッシュ
- クエリキャッシュ
- mutex server for lock
- Swifty
- 70 times faster than Cache::Memcached
- Filter::SQL
- キュー
- 質疑応答
古今東西ORマッパー - Atsushi Kobayashi (nekokak)
- Hatena::Diary::Neko::kak 500 Internal Server Error
- ORマッパーの比較
- どのORマッパーをメインに使っているか
- DBIx::Class
- 2005/08/08から
- 条件をチェーンできる
- 柔軟にjoinできる
- ドキュメントがしっかりしている
- 新しいプロジェクトはDBICを利用している
- Data::ObjectDriver
- Fey::ORM
- まとめ
Gungho and cloud computing, a scalable crawling and processing framework - Jeff Kim
- クローラは難しい
- クロールするサイトやネットワークの帯域によってスピードの制限がある
- robot.txtなどを適切に処理しないといけない
- 読み書き多い
- 100万のドメインからクロールしたい
- gungho
- written by maki daisuke
- asynchronous http request and asynchronous DNS lookupa
- robots.txt handling
- gunghoの構成
- provider -(url)-> engine -(http response)-> handler
- provider
- limits to pages per domain
- engine
- Gungho::Engine::POE
- POEを利用
- spwan数と遅延時間を設定できる
- handler
- Gungho::Handler
- raw html to S3
- GunghoX::FollowLinks
- POE::Component::MessageQueue
- Swarmage
- クロール結果を保存
- EC2にインスタンスを置く
- gungho crawler
- message queue
- database
- S3にraw htmlを保存
- hardware
- 1 extra-large instance for queuing/messaging
- 1 extra-large instance for databaseにextra
- 20 small instances for gungho crawler
- coding cost 50%
- hosting cost 10%
- スケジュール前にクロールが終わった
What I've learned in Tokyo - José Castro (cog)
- Joséさんが日本で学んだこと.
Perl Is unDead - Michael Schwern (Schwern)
- zombie dayというのがあるらしい.
- zombie needs brains
- perl needs brains
- perl is like COBOL
- legacy language
- perl is not dead
- 700 uploads / month
- 21 conferences in 2008
- 90年代,Perlは速く,拡張しやすく,書きやすい言語だった.
- しかし,Web 2.0の時流に乗れなかった.Web 2.0ではjavascript, css, php, rubyのような言語が強くなってきた
- Folk programming
- 先生に習うことなく覚える言語
- 90年代のPerlはFolk Programmingだった
- ソースコードが読める
- シンプル
- 結果がビジュアルですぐに確認できる
- 現在では,シンプルはなくなったし,結果がビジュアルという点ではjavascriptやyahoo pipesなどに負けている
- perlはもはやfolkではない
- barcampに行ってきたのだが,そこにいる人たちはコードの話ではなく,何をするかを話していた
- ユーザにとってコードがpythonであるかperlであるかは関係ない
- Perlは自分たちだけで閉じていて,他との交流が少ないのではないか
- もっとユーザを,ソフトを使ってくれる人を意識しようということかな.
- もっと違うコミュニティと交流しよう.
Closing Ceremony - Yoshinori TAKESAKO (takesako)
- 569人登録して524が参加
- 12ヶ国,19のMongersから