YAPC::Asia 2013セッションメモ9/21分
後でちゃんと編集します。
乱文でごめんなさい。
Perlで書く結合テスト
- @ikasam_a
- Testing Casual Talks #2 11月ごろで調整中
SWET, TE
Developer Productivity
- 2つの役割
- (後でスライド見て補完)
- Testingにかかわる活動
- SWET Group Mission Statement
- テストをしやすくして、生産性を上げる
- エンジニアリングとしてtesting活動をしていく
- 自動化など
テストの分類
- 4つの分類軸
Perspective Target
How What
Integration Testing
- 結合テスト: 「何と何が結合している状態」なのか?
- 単体の裏返し
- 「モジュールが結合」してコンポーネントを作る
- 「コンポーネントが結合」してシステムになる
- ユニット間のインタラクション/オーケストレーションをテストしていく
結合テストのケーススタディー
- Web API
- HTTP JSON-RPC API
- interaction & integration
- テスト用クライアントからAPIサーバーにリクエストを出し、レスポンスを見る
- APIサーバ内のモジュール間結合、バックエンドサーバー群との連携
- 入力: HTTPリクエスト、出力: JSONレスポンス
- HTTPクライアントには
- JSON validation
- gray box fixture
- DB/Cache manipulation
- テストケースに依存したデータを作成
- 継続的テストのためにキャッシュを消したりとか
- 普通のオペレーションで生成できないデータを用意する
- 特定サーバー向けリクエスト
- HTTP Messageを見る
- Web Application
- UIのWebアプリ
- interaction & integration
- Web Appモジュール: MVC的な
- Web APPとバックエンドサーバーとの間の連携
- 入力: HTTPリクエスト、出力: HTMLレスポンス
- ブラウザ、user agentを使う: JavaScriptが解釈できることが重要
- Switch Browser
- テストの中でJSを使えるブラウザとJSを使えないブラウザを切りかえたいというニーズがたまにある
- ブラウザはHTTPヘッダをさわれない
- エミュレータはJS実行できない
- ブラウザのpseudo state(セッションなど)をセーブ/リストアする
- ヘルパーとしてまとめておく
役立つモジュール
これからのPerlプロダクトのかたち
- @goccy54
- 自己紹介
gperl
Compiler::Lexer
Compiler::Parser
Compiler::CodeGenerator::LLVM
使い方
PerlをiOSやOSXで動かす
静的解析ツールとして使う
Lexerを使っているモジュール
- Perl::MinimumVersion::Fast
- Test::LocalFunctions::Fast
今後
gperlは生まれかわるよ!
- gperlから派生したCompiler::* をgperlに還元
- static typingを入れてみたい。型推論エンジンに興味がある
「Rubyの良いところ語ってください 〜そんなPerlで大丈夫か？〜」
- 司会 @naoya_ito
- パネラー @tokuhirom, secondlife (@hotchpotch), @shyouhei, @masuidrive
- 本メモでは発言者を示すプレフィクスとして n, t, h, s, m を使っています
自己紹介
- @syouhei: Ruby committer
- secondlife (@hotchpotch): Cookpad
- @masuidrive: 風呂グラマー
- @tokuhirom: Shibuya.pm, Amon2
言語の比較
- なぜPerl, Ruby?
- m: Rubyは日本語でいろいろできる
- s: ブログブームのときt-diaryを使ったのがRubyの始まり
- 十分満足していたらコミッターにはならない。不満があるのでパッチを送っていたらコミッターに
- h: t-diaryから。Railsの回りのコミュニティー形成の流れ → Cookpad
- t: 15歳くらいからRubyとPythonを使っていた。Rubyist Magazineに寄稿した。LLの実行委員をやったときにPerlの会社に行って書くようになった
- t: 当時naoyaさん、miyagawaさんがblog hacksをやっていて楽しそうだった。言語そのものに興味があったので、それまで使ったことのないPerlをやってみた
- いちばん好きな言語はRubyだと思うが、こういうところが好き、とかある?
- h: Perlとの比較では、標準ライブラリのセンスがすごくいい。PerlだとList::Util使わないといけなかったりという部分が、そのままサポートされている
- n: やろうと思えばできるというのと、処理系がサポートされていることには違いがあるのか?
- h: 学習のしきいが高かったと思う
- s: ごく最近Perlをさわりはじめた。違うところより似ているところが多かった。仕事の中でpr出したら何も問題なくマージされた。差分よりは似ているところのほうが多いと思う
- m: RubyはMatz Rubyの他に処理系のバリエーションが多い。JRubyとか。最近だとmrubyが出たりしている。こういうのはPerlにはあまりない
- h: Perlとの比較では、標準ライブラリのセンスがすごくいい。PerlだとList::Util使わないといけなかったりという部分が、そのままサポートされている
- n 言語を変えて生産性は変わる?
- m: 言語を変えると変わってくるが、肌に合うか合わないかのほうが強いかと思う。引数の順番とか覚えなきゃいけないことが多いのはつらい
- s: 適材適所がある。Rubyのいいところはあるけど、全部をRubyでやろうとするのは間違い。CapystranoでRubyで書いているコマンドは本当はshellの方がいい。なんでもやろうとしないほうがいい。
- n: webアプリケーションでPPPRと並べたときはどうか
- s: ツールや言語による違いよりもプログラマーのスキルによるところが大きいだろう
- h: 現状を切りとると、何の・誰の生産性かというのでも違ってくる。Rubyは道具としてそろっているので何かを作るときにスピードは速い。ただしハッカーは何でもできてしまうのでPerlに足りないところはすぐ作ってしまう。Railsの批判としてはでかすぎるというものがあるが、Amon2作ったりして補ってしまう。普通のところでは道具とコミュニティーが現状Rubyにはそろっていると思う。社内で助言が得られるかというのは難しく、Web回りでコミュニティーができているのは大きい
- t: PPPRの言語レベルの生産性の違いと言えるほどのことはないと思う。上のレイヤでツール・ライブラリなどが問題。行列計算のライブラリはPerlよりPythonのほうが充実している。Perlの場合は自分で使いたいライブラリは自分で書いているので、ぼくのユースケースと似ているところには合っていると思う。
- n: フレームワークやライブラリということでRailsが勢力を変えたということがあるか
- h: bundlerなど、コミュニティーの範囲が広く、うまいやり方がgithubを中心に広がっている。課題を考えたときに育つということがある。
- h: Rubyはファッションの流れみたいなことがあって、それに乗ってる人もいる。node.jsのコミュニティーのでき方といま乗ればデファクトになれるというのに熱い風を感じる
- s: 回りでPerlをやってた人がRubyに行ったという話を聞くと、Railsから転びましたという人はあまりいない。Rubyにはthreadがあったという人とstructがあったという人がいる
- n: threadはね、Perlではいまだにちゃんと使えているとは言えない
- m: RubyはRails以前から使っているが本格的に使うようになったのはRails。Railsはビジネスとつながって経済圏ができているのがすごい。herokuとかNewRelicとか。RubyはOSSコミュニティーだけでなくお金が出るコミュニティーもしっかりしている
- s: RubyがすごかったというよりRailsが切り開いた面がある
- n: Rubyが良かったのかRailsが良かったのか、そのへんはどう?
- m: コミッタの視点でどう?
- s: いろんな分野のいろんな専門化の人が来て、こんなところが気になっているんだけど、みたいな話をしてくれる。特にusabilityについて。いろんな人が来ることがRubyの開発をドライブしている面がある
- n: PerlとビジネスということでSaaSサービスのサポート状況とかどうですか
- t: SaaS的なところで言うとherokuとdotcloudくらいしか使えない。積極的にサポートしてくれる/サポートしてくれという動きがないのはよくないかなあ
- n: travisでperlが検証できるようになったのはコミュニティーが主導していったのかな
- n: エコシステムとしてPerlはCPANからという流れがありますが、Rubyはrubygemsにコミュニティーがあるというよりも、github上にあるような感じですが
- h: rubygemsも最初はrubyforgeというPHP上のサービスだった。いまはgithubではあるけど、最初からスムーズだったというよりは、githubが出てからそっちに移った感じ
- s: lighthouseからgithubに移っていった。単に新し物好きというのもあるが、新しいものが出たときにどんどん流れて行くような人が多いという特性があると思う。これは古いチケットが放置されたり悪い面もあるけど。
- t: CPANの中にbug tracking systemがあってみんなメールで登録したりしているけど、最近はgithub上でやる人が多い。意外とgithubに移ってきている人も多い
- m: Perlの人ってgithubでやらないの?
- n: CPANが機能をたくさん持っているので、そってちでやっている人が多かったということかな
- m: githubの良さはコードとコミュニケーションが近づいたということ。コミュニケーション主体で大きくなってきたという流れがある
- t: rtが重要で、なかなかとじることができなかったという面がある
- n: DevOpsとしてRubyでこんなことやってるよ、みたいのある? 基本puppet使ってとか
- h: SaaSとかアーキテクチャの話ではPerlとの差が出ると思うが、puppetのようなツールのレベルでは違いがないのかな。単にpuppetがRubyで書かれているだけというか
- n: Rubyの人はツールもRubyで書かれているものが多い。そういう力が働くのかな
- h: 道具を作ろうと思って書くからじゃない?
- n: Railsから広がるというのとDevOpsの話と似たところがあるような
- h: DevOpsというのはインフラができてソフトが書ける人がやっている印象。Rubyの方が学習コストが低いということがもしあるとすれば、関係しているのかも
- m: ひと昔前だとRubyをサーバーに入れるのがイヤがられた。Perlは必ず入っていた。5年前に同じことをやろうとしたらPerlになったのでは
- n: コミッタのコミュニティーについてどうか
- m: シアトルにコミュニティーがあって英語が十分でなくても理解してくれる。Matz is nice so we are niceという標語があって、Matzを中心としたコミュニティーがある気がする
- n: 海外コミュニティーとの関わりってどうですか
- m: (聞きのがした)
- n 組織とコミュニティーとの関わりはどうですか?
- h: 言語のバージョンアップで速くなるとか会社がビジネス面でもコミットしているところが違うと思う
- t 日本にはPerlのコミッターがあまりいないし、committerをあがめるような文化がない。弾さんが持っているかなーってことくらい。言語コアよりはCPAN authorの方を大事にする文化があるように思う。コミュニティーに還元などはCPANを中心に回っていると思う
- s: コミュニティーってどこにあるんだという話をしてみたい。Rubyコミュニティーに入るには羊の心臓をささげる、みたいなことはない。分断されていて敵対心をあおるのはよくないと思っていて、自分の所属意識があるのはいいが、排斥しないでほしいと思う
Perlリスク論
- どう思うか、どう行動したらいいか
- s: ブログで「まああるんじゃないですか」と書いた件について。去年まではRubyを作る会社にいて、いまはPerlを使う会社に転職してきました。Rubyを使うだけで終わりたくなかったという面はある。いまRubyはバーっともり上がっててカッコイイけど、10年後そうとも思わない。ゆるやかに使われなくなっていくのかな。Rubyを使い続けるのは得策ではなく、もっといい言語が出てきて、それにRubyが影響を与えればいいかなと。ぼくのゴールはRubyを良くすることではなくみなさんを、プログラミングをハッピーにすること。RubyがPerlがというよりもっと大事なことがあるんじゃないかな、と。
- h: ぼくらはユーザーに価値をどれだけ速くとどけられるか、そこに適したRubyをいま使っている。Perlのコミュニティーを見ると他の言語やコミュニティーをすごくよく見ていて、Perlに取り込んだりしている。miyagawaさんはあっという間にRubyとRubyコミュニティーの文化を吸収して、またPerlに輸出している。そういうことができる人がいることが大事かなーと思う
- t: ぼくが言っていることは10年前と同じで変わっていない。Perl6も出ないしもうダメーと言っている。その状況も変わらず。変わらないながら進んでいくんだろうなーと思っている。言語ってのは仕事の一部でしかない。要素技術のひとつを取りかえたくらいで自分のスキルが役立たなくならないようにするのがエンジニアとして大事だろうと思います
- n: Perlリスクに対してPerlでもこんなことできるよと反論していくのも手であるとは思うけど、他の言語の世界を見て学ぶ機会を得ていくほうが大事。みんなで未来を見ていきましょうと思います。
本当にあったレガシーな話
- @lestrrat
コードベース
ログを取ってください
- Log::Minimal
- 本番では最適化したい
- 必要ないところではログの出力コードをそもそも消したい
- 定数たたみ込みしましょう
- if (LDBLOGNG_DEBUG) { ... } コンパイル時に定数たたみ込みで消える
- 巨大なアプリではめんどうでもすべての分岐に入れるべき
- ifの条件式が複雑な場合も、条件ごとにログを入れると後で得
- 「x == 1なので離脱します」のように書く
- コンポーネントが多いときはマーカーをつける
- enter/leaveログ
- guard objectつけるとインデントしたログを出せる
- やっとコードの実行結果を追える
- リファクタリング
- 「$r」の追放。$rは邪悪そのもの
- Apache::Request->instanceはさらに悪
- $r->status(...); $r->send_http_headers()があちこちにある
- → $class->not_found($r), $class->output_data($r)のような書き方に直す
- ひと目見て何をやっているかわかる
- クラス関係の見直し
- mod_perlハンドラはクラスベース(オブジェクトを作らない)
- 初期化コードが大変になる
- フラグ・スイッチを親クラスに集約
Phase2: 配信システム → PSGI
- ApacheハンドラをPSGIに
- 直す → 走らせる → 直す → 走らせる →
- RubyのKageをAnyEventで
-
- metacpan.rog/release/Geest (ヘイスト)
- 出力の差分を見る
-
- やっとPerlのバージョンを上げられる
- せっかくならcpanfile + carton
- セットアップ
- 数台だけ入れかえたら、パフォーマンスが30%落ちる
- Devel::NYTProfを使う
- → mountを多用していた。数が多すぎると遅くなる
- → パッチ書いた
- query_parameters()がやたら重い
- uri()をキャッシュするようにしたら10〜15%速くなった → マージ済
- 再デプロイ
- 全て落ち着く… svc -hするまでは
- → 突然load averageが上がる
- Server::Starterで管理していても-hでやると一気に上がってリソース食う
- → 既知の問題: 前の世代を殺すタイミングと次の世代が立ち上がるタイミングが同じになってしまう → kazuhoブログ
tips
- plackup多すぎ問題
- $0に代入してpsで見える名前を変更。リクエスト情報やハンドラ・日時を入れるのも便利
スマフォアプリ開発を支える認証認可アーキテクチャ
- 今日のメイン: OAuth 2.0 Grouped Client拡張について
前提知識: OAuth 2.0
- OAuth2.0の基本 (略)
- Glossary
- Access Token, Refresh Token, client_id, client_secret
OAuth 2.0 Grouped Client extension
シングルサインオンの実現方法
- ID・パスワード共有
- 最初に起動したアプリから後のアプリにID/パスワードを教える
- OSの機能でKeychain, Account Managerが提供されている。これを使って共有する
- mixi製でない他社製アプリとは共有できないので安全
- 絶対の安全はない。root取られるくらいのイキオイでhackされると取られちゃう
- パスワードが漏洩するとすべての情報がもれる
- パスワード無効化すると影響が大きい
- Grouping Refresh Tokenの共有
- Refresh Tokenは通常アプリごとに異なる
- Grouping Refresh TokenをOSの機能を使ってアプリグループ間で共有する
- 不正アクセスに対して、client_id, client_secretが必要なので少し守れる
-
-
- refresh_tokenだけをrevokeすればいい
- 無効化した場合、grouping refresh tokenを共有している範囲だけで使えなくなる
-
おまけ
- 共通アカウント管理機能を持ったBaaSを作ろうとしています
- push通知機能、その他のBaaSの基本的な機能
- scopeの違いは? → @ritou と @mad_p のtwitterログをここに入れる
Vagrant と Chef でプログラマブルな開発環境をつくる
- @aereal
- アプリを作るにはモジュールがいろいろ必要
- 某Webアプリ3万コミット
とりあえず cpanm --installdeps
-
- だいたい失敗する、オプション変えてみる。やっぱり失敗する。なんども失敗する
- 2〜3日も開発環境のセットアップにかけるとか気が狂ってる
- モチベーションも消費する
- やることは単純な作業の積み重ね
- → ログが残ることが大切。cpanmの引数とか
- こわれたらすぐわかる。ドキュメントが陳腐化しているか調べるのは難しいが、プログラムがこわれているのはすぐわかる
vagrantを使う
- 開発用にVMを立ち上げるのは以前からもやられていた
- 単純な回帰ではない。Chefのようなソフト面での進化が大きい
- 丹精こめて作ったVMイメージを大事に大事に使う → 壊れることを前提に環境を作っていく
- NFSでゲストとリポジトリを共有する
- Virtualboxのshared folderは遅い
- perl-buildで5.8.8を入れる (tokuhirom/perl-build)
- CPANモジュールはcookbookに記述
- ChefのLWRPを使う
- carton化も進めている
- ./bin/server
- git.io/PBG-og にて公開予定
課題
- 二重管理なのはそのまま → 問題をすりかえただけ
- 本番環境のchefと共有したい
- メンテしているのは自分だけ
p2
- Reini Urban
- 5 + 6 = 11
- perl11.org/p2
- Parrot performanceはイマイチ
- perl11 = prel5 + 6
- 「Perl is not dead, it is a Deadend」
- Perl8.org pugs in scala
Perl 11
- Parser
- Complier
- 設計方針
- Learn from the good
- POTION
- potion: フラミンゴをマスコットにした。P 2 の姿をしている
- potion / P2
- common number interfaces
- int, double: automatic promotion, 遅いけど最適化はカンタン
- common hash/array interface
- hash とarrayの自動キャスト
- everything is an object, overy object is a word
- data, vairables, functions, blocks, class, types, metaclasses, ...
- 全部はlambdaである。変数もそう
- every op is a word size: Perlでは4〜7ワード
- 64bitの中にはopタイプに少しのビット、残りをオペランドに回す余裕がある
- common number interfaces
- parser
- peg, enhanced to greg
- 最大3ノードのASTを作成
- compiler
- ifはただのブロックつきのリストのメッセージ
- control structureはマクロのように処理できる
- VM
- everything is an object, every object is a function
- MOP
- data
- primitive vs extended object (vt, uniq, size, data)
- INT, BOOL, NIL as primitives everything else is an object
- tags LSB2桁
- 00: foreign ptr or our obj
- 10: bool
- _1: int
- calling convention
- Native C cdecl (32bit) and fastcall (64bit)
- GC
- いろいろ
- threading
- まだ決めてない
キーノート: management and Perl culture
- 池辺さん LINE Corp
- Career
- on the Edge → EDGE → livedoor → NHN Japan → LINE
- 実は転職していない
- Products
- LINE ○○
- livedoor ポータル
- livedoor Blog
- naverまとめ
- livedoor Blog
- 10周年
- mod_perl 1で動いてるサイトの中でさばいてるPVは1位だったと思うけど、一気に返済していただいた
- お仕様: software development
- ソフトウエアの開発ってPCに向かってカタカタやってウフフって感じなんでしょ、なんて個人技っぽく思われてる
- いいソフトウエアってのはすごい少ない人数のちょっとオカシイくらいのすごい人が作ったモノが流行ると思っていたが違う
- ソフトウエアは人間が作る。いまだに人間が作っている。人間が集まって作っている
- → Team
- management
- management != 管理
- 上から目線で管理すればいいというものではない
- 心がけていることを紹介します
- as is ではなく to be ですよ
- work environment
- 働く環境ってみなさんまあまあウルサイというか非常に大事でしょう
- PCは速くなくちゃとか、椅子がつらいとか、朝起きれないとか、ワークライフバランスとか
- 環境をちゃんと備えるために、人事とか総務に通していく仕事がある
- human resources
- 人事
- 自分よりデキル人を雇えないとダメだとか言われる
- 優秀すぎてどうしよう、取ってかわられるんじゃないかと思ってコワイ
- ちゃんとやらないとチームとしてのcapがマネージャーのそれになってしまう
- SKE48の写真、16人みんな色が違う。みんな違うのがいいことで均質化する必要はない。みんな好きキライがあってもいい
- ビジネスよりに興味があって売上あがるのがいい、細かいチューニングで貢献、いやいや技術的負債は許せない、など、みんなが自分の特性を発揮してくれればいい
- ユーザーが近いのが得意な人と苦手な人は割とハッキリ分かれているかも。ユーザーからの辛辣な指摘に耐性のある人に大規模な改修してもらうといいかな、とか
- 将来どうすんの?
- management or engineer
- 35歳定年説
- 人事制度もちゃんと考えないといけない
- ダメだと思うのは「デキルエンジニアをおまえマネージャーな」とやること
- 向いている人、向いていない人いると思うし、マネージャーできないとダメだよというのはおかしい。エンジニアはエンジニアのまま給料ももらえるような人事制度にするようハックしていくべき
- マネージメントとリーダーシップはまた違う。数人でゴールさせるリーダーシップを持っているエンジニアは結構いると思う
- 「マネージャーならないといけないんですよね、そろそろ」という価値観でやらない方がいいと思う
- direction: 方向づけ
- marketing
- マーケティングというとアレっすかみたいな話になりがちだけど
- チームがちゃんとがんばっているということを、技術がわからない人、決裁権を持っている技術のわからない人に伝えていくこと。これをやならないと損したりする
- 牧さんのmod_perlからの脱却という話があるけど、自分はApache使いたい、でもCは書きたくないという感じでやった。そして脱却した牧さんはすごいんです。だからもっとお金をくださいとか、フレックスにしてくださいとか、そういう社内政治を、社内政治って悪い言葉っぽく聞こえるけどそうじゃなくて、ちゃんとやっていくことは必要
- ちょっとずつ社内にうちの部署++みたいなカルマがたまっていって良くなるので、そういうスパイラルを回していけることが大事だと思います
- our team
- 80人強いる AKBの研究員を全部含めたくらい
- サーバーサイドはだいたいPerl
- 最近はアプリを作っているのでObjective-C, Java, JavaScript, Ruby…
- Rubyも実は使ってたり
- Why we use Perl?
- 入ったときには弾さんがもうそうしてた
- dan: ぼくが入るまえに@takapon_jpさんが使ってた
- 変えようとすれば変えられる
- Perlリスクという話の中で面接してるときにPerlできませんと言ってすぐお引きとりください、なんて言われてたけどそんなことはない
- いまPerlができないからってできるようにならないことはない
- Webの仕事をしていてプログラミング言語で勝負が決まるようなことはない
- 10年動いているものをRailsで書き直しましょうなんてコストは見合わない
- タイミングを逃した? まあそうかもw
- Perlって言語の側面というよりはカルチャーの側面、TIMTOWTDIとか多様性を認めるカルチャーとか大事
- CPANソムリエという職がうちにはあって、CPANに乗ろうという気持ちがすごく大事
- 入ったときには弾さんがもうそうしてた
LT2日目
すいませんログ取ってません
