YAPC::Asia 2013に行ってきました

blogに書くまでがYAPCです。
ここまで1個下のエントリと一緒。

結局1年間何も書かなかったということに・・・

各トークの内容は例によってgihyoさん記事とスピーカー自身によるエントリにお任せ。
自分のスライドもSlideShare経由でYAPCのトークページに埋め込んでおきました。

トークした経緯は去年に引き続きgoccyに「喋らないんですか！？」って突っ込まれたから。
今年も人様の作業を堂々とパクる、という芸を見せてきました。

時間がギリギリだったので質問のタイミングがなく、どのように伝わったかわかりませんが
感想・ご意見などありましたらご連絡いただければと思います。

懇親会で「Perlのバージョンアップはホントにあんなすんなり行ったのー？」と聞かれました。
多少過去の出来事 && 一部のみ関わってた立場 ということもあり、把握してない苦労など
あったとも思いますが、lestrratさんのトークからも「mod_perlからの脱却の方が大変」
と感じました。そしてそれは未知の部分なので、その差かもしれません。

他の方のトークで印象に残ったのはkazeburoさん、myfinderさん、yappoさん、lestrratさん、ikasam_aさん
と並べると見事にミーハーっぽいチョイスになってる。

kazeburoさんは昔からですが、話がわかりやすく、易しい所から難しい部分まで丁寧に触れられていて
すごく頭に入ってくる内容だった。近年のPerlにおける必須項目Plack周りを知りたい方はまずこちら、という内容でした。
ベストスピーカー賞第3位おめでとうございます。

myfinderさんのは、内容的には弊社内でも全く同じ取組をしています。
tech hills vol.6 においてgoccyが発表しているのでその資料を参考にしていただけると良いと思います。

発表のポイントとして「スケールしていく開発環境にどう対応するか」という所を触れられていて、
実は1日目の懇親会の時に「プロダクトや開発人員が膨らんでいくとテストがボトルネックになりがちですね」という話を
複数人でしていて、そこを重点的に話すというまさに作戦通りのベストスピーカー賞2位おめでとうございます。
bonnuさんの資金でお祝いにいきましょう。

yappoさんの「コピペイクナイ」のコンセプトは素直にステキで、コードレベルだと皆わかってることなのに、設計やプロジェクト運用などスコープが広がるとついついやってしまう事。新しい取り組みを始めた社内でも散見される事象かなと思います。もちろん確立された手法だったり、どうしてもスピードが求められるケースだったり、とか例外はあると思いますが。

lestrratさんのトークは、自分も似たような話をしたハズなのに、全然違う内容に感じるなど
発表方法として学ぶ部分もすごい多かった。mod_perl周りの話は前述のとおり。
発表時間がより短い中で、さらにその一部分で触れていただけなので厚みに差があるのはまぁ当たり前なのだけど、
どちらのが伝わりやすかったかと考えると明らかかなと。

ikasam_aさんのは何度か聞いているSWETグループの立ち位置と取り組みが興味深い。
Testをエンジニアリングするというのがクールだし、その過程で出る問題とかもっとあるだろうなと思うので、
その辺含めて今後も聞ける機会があると良いかと思いました。非機能要件にアプローチするという点では
今の仕事と通じる部分があると思っていて、それがおもしろかったです。

聞けなかったトークだと、soh335の話。
自分の発表の真裏だったので物理的に不可能でした。後夜祭でお話しさせていただいて、
改めて資料チェックしようと思います。

自分の発表資料の中で、Test::UselessModuleというのを紹介しましたが、
そのあとタイムライン見てたらたまたま Test::UsedModuleというのを知ったので見てみたら
完全に元々やりたかったことが実装されてる内容になってるっぽいですね。
作者のmoznionさんとお話しする機会を密かに狙ってたんですが開催中に会えなかったのが残念でした。

内容が被っているという意味では、nekokakさんのLTで出ていた共通モジュールの話もそう。
まさにたんぽぽ的な取り組みですね、という印象で他にも同じような取り組みをしているorこれからする
所はあるんじゃないかと思う。共通なものを作ったあとに、呼び箇所をスムーズに置き換える所にも
工夫してる部分あるんですが、その辺をどうしてるのかとかも気になりました。

YAPC::Asia 開催全般で言うと、運営の方々の安定感もあり、特に困る事はありませんでした。
メイン会場の電源が確保されていたり、ネットワーク環境が整備されていたり何不自由なく過ごせました。
スポンサー企業のご協力でサービスしていただけた部分（懇親会とか）、ボランティアの方々、
もろもろ含めてお疲れ様でした＆ありがとうございました。

ここまで完成されたイベントが来年からどうなるか楽しみ以上に不安な部分も大きいですが、
ぜひとも継続して開催してほしい、いやしていくのに協力したい、と思いました。

皆様お疲れ様でした、来年もお会いしましょう。

YAPC::Asia 2012に行ってきました

blogに書くまでがYAPCです。
今年もYAPC::Asia 2012に前夜祭含めて参加してきました。

例によってトークの細かい内容はgihyoさんの記事や
各スピーカーの方々が資料をアップしてくれるのにお任せしたいと思います。

今年は、2年ぶり2回目のスピーカーとしての参加でしたので、その辺メインで。

トークしようと思ったきっかけは、同じチームの人が喋るから、っていうのに
引っ張られただけで特に強い意図があったわけではなく・・・
ここ最近の会社の取り組みで、他人が頑張った事をさも自分の功績の如くエラそうに喋る。をしてきました。

資料はSlideShareにアップしましたが、YAPCのトークページからでも閲覧可能です。
（動画もそのうちあがるはず）

会場で質問いただいた中で、ちょっと上手く答えられなかったかなという部分について補足します。
「既存のuseして呼び出しているメソッドをServiceProcedure経由に置き換える場合にデグレをどう担保しているのか？」
という質問をいただいた（と記憶してます）

これにつきましては、ServiceProcedure呼び出しは新しいパブリックなI/Fの提供を行う、
という仕組みなので必ずしも既存の呼び箇所がすべて同時に置き換わる訳ではありません。
つまり「呼び換え漏れ」というものはなく、それはただ移行段階であると言えます。
既存のメソッドに手を入れる訳ではなくAdapter層を設けているため新旧I/Fの併用が可能なためです。

ここからは会場で返答した部分ですが、呼び換える際に、I/Fが変わる事はちょいちょい起きます。
特にレスポンスの部分は元々がオブジェクトを返すような形式だった場合、ServiceProcedureはplainなデータを扱うと規定しているため、呼び側でオブジェクトを期待しているコードは修正する必要があります。それに合わせてテストの修正が必要になることもあるかと思います。
plainデータに縛っているのは、そこでオブジェクトを返してしまうと結局呼び側が他の名前空間のモジュールを意識（=管理）することになってしまうためです。

2年前にトークした時には質問とかいっさいなかったので、質問をいただけるということは嬉しいことですね。
リハしたら毎回30分近くかかるものが、20分にきっかり収まってたので、どんだけ早口だったのかどんだけ言い漏れしてたのかは動画がアップされてから反省したいと思います。。

今年もいろんな方とお話しさせていただきまして、個人的に嬉しかったのは1日目の懇親会の時にlyokatoの計らいで、mizzyさんに通われている大学の授業について聞くことができました。
実は同じように大学に通いたいと考えていたので、どんな感じの授業なのかとても参考になりました。1日平均で4時間くらいは勉強されているということで、かなり甘く見てたのを思い知りましたが。。

YAPC全体としては、パネルディスカッションの時にも話が挙がっていましたが、ここ最近のYAPCでは技術的に新しくてみんなが「オォー」ってなるものは出ていない気がします。（2008年のMoose、2009年のPlackくらいまで）
例年ベストトーク賞などの優秀賞は会社の内容や業務に近い話をされている方が受賞されている傾向が多いようにも見えます。
（2日目の後夜祭で、「初めてYAPCに来た人とかだけが真面目に投票して、そういう人達に刺さるのが会社系トークなんジャマイカ」っていう会話をした記憶もありますが、それはさておき・・）
なので、まだ発表されてない方で、発表内容に困っている方でもどんどんトークすればいいんじゃないかと思いました。
かく言う俺も（賞とか貰ってないけど）まさにそれ系のトークですし。
逆にパネルの時に予見されていた「そろそろまた『新しい何か』が出てもいい頃」の方に踏み込むのももちろんアリではないかと。

いきなりYAPCは、と思った方は来月開催される予定のyokohama.pmに参加してみてはいかがでしょうか。

最後になりますが、牧さん・941さんをはじめとする運営スタッフ＆ボランティアの皆様お疲れ様でした。
慣れ親しんだ東工大から離れて大変な面もあったかと思いますが、例年に近いくらい快適でした。
お陰様で安田講堂を写真に収め、近くにあった生協で東大シャーペンと東大ノートも買えました。
経理担当のJPA理事さんもお疲れ様です。
来　年　も　楽　し　み　に　し　て　い　ま　す

今年もお土産写真を掲載して締めます。Thank you very much, Larry!

Params::Validate をuseする時「use Params::Validate qw//;」と書くのを推す理由

社内のコードレビューで、Params::Validateのuseの際に、

use Params::Validate qw//;

と後ろにおまけをつけてもらうようお願いしていました。

たまたま、「そういえばなんで qw//; をつけるんですか？」と質問されたので、口頭では簡単に説明したんですが、メモの意味でこちらにも書いておきます。

と言っても、コードがあった方が早いので、以下の３つのファイルを用意しました。

package YAPC::Asia2011;
use strict;
use warnings;

use Exporter qw/import/;
our @EXPORT_OK = qw/ is_hold /;

sub is_hold{
    print "YAPC::Asia 2011 has already held  2011/10/13 - 15 \n";
}

1;

package YAPC::Asia2012;
use strict;
use warnings;

use Exporter qw/import/;
our @EXPORT = qw/ is_hold /;

sub is_hold{
    print "YAPC::Asia 2012 will hold 2012/09/27 - 29 \n";
}

1;

#!/usr/bin/perl 
use strict;
use warnings;
use lib "./lib";

use YAPC::Asia2011 qw/is_hold/;
use YAPC::Asia2012;

is_hold();

exit;

これで、最後のplを実行してみると、

YAPC::Asia 2012 will hold 2012/09/27 - 29

と出力されるはずです。use の順番を2011と2012で逆にすると、

YAPC::Asia 2011 has already held  2011/10/13 - 15

になるはず。

useしたモジュールが@EXPORTに関数を突っ込んでると、自動的にその関数を使えます。
そんなモジュールはたくさんあるし、必ずしもそれが悪い事ではないのですが、
Params::Validateの場合は 「validateとvalidate_pos」が@EXPORTに入ってるので、
特に前者は思わぬところでバッティングしたらイヤだなぁという思いから、これを抑止したかったため
冒頭のお願いに繋がりました。

サンプルのplでも

use YAPC::Asia2012 qw//;

と書くことで、useが後だとしても

YAPC::Asia 2011 has already held  2011/10/13 - 15

になるはずです。

モジュールを作る際には、@EXPORTと@EXPORT_OKどちらに突っ込むかは考慮して作成する必要があると思いますし、使う側としても、適切なもののみ選んでimportする方が良い派です。

そんなこんなで、YAPC::Asia今年も楽しみですね！

gitで別のリポジトリにpushする

通常git push は git cloneしてきたリモートリポジトリに対して打つ事が多いので、
git push
とか
git push origin master
くらいしか打ったことがありませんでした。

とある対応で、my/hoge.gitのリポジトリで作業したあと、最終的にpublic/moge.gitのリポジトリとして公開したいという
場面があり、git merge あたりを軽く眺めたんですが、結局
init commitなので手動コピー -> git add , commit , push　でも
いいかというアナログ手抜き対応をしちゃいました。

すかさず突っ込みを貰い、非常にシンプルな正解を教わりました。。

my/hoge.git をcloneしたディレクトリで、↓の1行で一発

git push [リポジトリ名] master
（ 前述の例だと git push git@repos.com:public/moge master）

今回だと、既にアナログpushをしたあとだったので、

git push git@repos.com:public/moge +master

で 強制的に上書きしました。

「別リポジトリにpushする」というのは多分あんまりないので、書き残しておきます

Qcon2012に行ってきた

会社の人に誘われたので、Qcon2012(http://qcontokyo.com/)に行ってきました。

カンファレンスもよく考えたらYAPCくらいしか行ってないので、そこそこ不思議な気分でした。
多分参加者は150人くらい。さすがに知り合いの人はいませんでした。。

クラウドがテーマの１つ、ということでそれ系の話が多かったかなと。自分がそういうセッションを選んだからかもしれませんが・・・

以降はだーっとメモったものが基本。要所を編集しました。

よくあるカンファレンスの流れなのか、みんな淡々とセッションを聞き・移動する。ということで淡々と過ぎて行きました。
席から電源が取れなくて、休憩時間の度に充電する必要があったのがちょっとマイナス。。でも、周りの人もノートPCより紙のノートの人のが多かった。
あとはお菓子と少しの飲み物が提供されて、同時通訳が凄かった。とかが印象。

Keynote 1　怪しい都市伝説
　cloudのメリット
　　小規模でも使える
　　NASAではギガピクセルデータをhadoopで分析して、ipadで確認　なんてのができる
　　火星->S3->みたいな流れ
　　機密のためにはaws double cloud
　　NASAはamazon,google,MSあたりを使ってるよ
　　amazonの財務をどう見てる？
　　　2000年30億ドル規模だったものを今は毎日提供してる
　　　安定して提供してるよね。
　　　クラウドから別クラウドへ、データはどこででも保存されるべき
　　情報漏洩で工夫した点
　　　データが漏れてないことの確認のしかた
　　　暗号化によって対応。鍵はクラウド側には投げない。
　　　クラウドに投げる前に暗号化。
　======感想=========
途中から参加だったので、乗り遅れる
　===================

Keynote 2　Androidに関わるエンジニアの視点
　simeji買われたバイドゥの足立さん
　◎androidの歴史
　2007.11 android登場　Open handset aliance
　2007.12 blog書く。ターニングポイントだった
　2008.09 実機登場
　　野良アプリ入れて動かしてもらう
　　この時点でblog44本くらい
　2008.11 inJap登場　日本語入力機能
　　この時からユーザビリティを考えていた
　2008.11 Simeji登場（翌日）
　　スピード感が一番大事
　　ニーズを検証するより、ニーズそのものがあるかわからない
　※アプリ開発の壁
　　３位：技術力の欠如
　　　　　　やり続ける。調べる。わからないけど動く、でとめない
　　２位：モチベーションの減退
　　　　　　休憩大事。俺俺ミッションを作る。
　　１位：ユーザーフィードバック
　　　　　　正直キツい。お客こわい。
　個人のアプリ開発で大事な事
　　技術／リード・マネジメント／デザイン／メンタルコントロール／語学力／その他
　2009.04 IMF Input Mehotd Framework
　2009.04 android1.5リリース
　2009.05 ハードウェアキーボード対応、フリック対応、ポケベル対応
　2009.06 iWnn登場
　　ここから自分路線に切り替える
　2009.06 NDK登場　Native Development Tools AndroidでNativeコード開発ツール群
　2009.06　デザイナ矢野さんjoin
　※デザイナーと働く
　　お互いの認識の差を理解することから
　マッシュルーム
　　インテント。アプリ間の連携。RPC的なこと。
　　地図から住所の文字情報を引っ張ってくる
　2009.09　マッシュルーム公開
　2009.09　OpenWnn公開
　2009.09　冬眠
　2009.11　脱もっこり
　2009.12　WiFi経由でPCから入力
　2010.03　Android MIPS対応
　2010.05　上海
　2010.09　KDDI America　NY講演
　2011.05　渡米
　2011.05　ADK　Android open accessary kit
　2011.09　android x intel Multi-platform
　2011.12　売却
　◎大事なこと
　　完璧を目指すよりまず作る
　　人間は先を見通す能力なんてない
　　要するに、ちょっと考えて動いて試す
　　考えすぎた想像より、経験から導かれる予測の方が精度が高い
　（Q）android以外のプラットフォーム開発について
　　マルチプラットフォーム開発あるので、プラットフォームたくさんあるのでandroidにとらわれないほうがいいよ。
　　マルチ開発は開発者のエゴ。ユーザーの要望実現が重要
　（Q）考え方はリーンスタートアップ？
　　本は先週注文しました！
　======感想=========
androidとsimejiの歴史の話。
　とにかくスピードが早い、というのが印象的。機能リリース翌日に対応など。
　自分が欲しいもの、というコンセプトを崩さずに進めているのが理由とポイントなのだろうと感じた。
　逆に「冬眠」してたというのも大事なことなんだなと思った。
　リーンスタートアップは自分も先週注文しました！
　===================

美しさは見る人の目の中に宿る
　いけてないコード
　　略しすぎるコード
　　タトゥーにいれたコード
　いけてない定義
　　コードは芸術ではない。工芸的な職人ではない。機械の一部
　　コードの見かけはどうでもよくて、ソフトが低コストで動くことが求められる
　開発は氷山の一角。あとはたくさんのメンテナンス。
　メンテしにくい、複雑、変更に弱い。いけてないのはリスクの高いコード

　いけてないのにはいくつか種類がある
　　ぼろいコード。コメントで変更履歴がたくさんのコード
　　複雑とぐちゃぐちゃは違う。
　　maddening mishmash.ごちゃ混ぜなコード。依存が複雑。
　　破滅的にかき乱れた状態。これも依存が複雑
　　comprex & convoluted.　意味の分からない遠回りな処理
　いけてないのと古いのは違う。古いのはアリ
　freakishly foreign. 知らない珍しい言語とか。

　いけてない原因
　　・悪意はないけど、無知なエンジニア。本もblogも読まない人。関心がない。
　　・上司の親友。カウボーイコーダー。
　　・賢いエンジニア。マイケル・ジャクソン（という人が書いた本）が言ってる。

　いけないコードが現れない理由
　・アジャイルもウォータフォールも関係ない
　・テストの有無でもない
　・言語でもない
　現れないために
　・無知に知恵を授ける。昼飯をただで用意して、学ばせる。
　・カウボーイにはプロセスで囲い込む。手順を踏ませる。
　・賢い人、ソリューションが目の前にあるのに複雑化しようとする。セカンドオピニオンを求める。
　いけてないコードをなくすために
　・ホントにいいのか？ホントにいいのか？見難いだけで？
　・いけてないのはマイナスの一部。将来のメンテが楽になる「かも」。リスク導入を肝に銘じる
　コードは依存している。
　依存レベル
　　プライベートメソッドとパブリックだと違う
　　呼ばれ側を書き換えるのではなく、再実装する。
　deprecated,oboleteなどの警告を出す。移行を促す。
　（Q）どうやったら良いコードを書き吸収できるのか？
　　こういうMTGに出るのも重要。勉強も重要。やる気がない奴らにはピザおごれ。昼飯来ないならMTG形式ですかねー
　パフォーマンスとコードの美しさの関連性
　　コメントでhack , warningとか注意書きするといい
　======感想=========
　　コードの質とはメンテナンス性。
　　ダメな人のコードも良すぎる人のコードも課題があるっていうのは、凡人として激しく同意。でも誰にも悪気はないんですよねー
　　古いだけなのは悪い事じゃないけど、たくさんの人がいじってたり、その積み上げ方が悪かったりするといけてない、というのも納得。
　　古いけど安定して動いててそんなに触る機会ないんなら放っておく、っていうのは現実解だと強く思う
　　とりあえず取るべき策は
　　・deprecated警告しつつ、新しい方への移行促す。コンパチ大事。
　　・昼飯にピザをおごる余裕はないけど、勉強会に食事を持ち込むのは考えてみようと思った
　===================

クラウドデザインパターン -AWSを用いたシステム設計のベストプラクティス-
　インフラストラクチャはソフトウェアになった
　APIでコントロールできる
　日本でAWSを使いこなしている人は少ない。世界に比べても。
　なのでノウハウを形式知化したい。CDP。cloud design pattern。48個。近々総選挙予定。
　　froatingIPパターン
　　　IP のつけかえが簡単
　　clone serverパターン
　　　初期のサーバーの設定値やデータをコピーする手法
　　job observerパターン
　　　キューの処理もシステム化されてる
　実装シナリオ
　　５個ある
　　CGMシナリオ
　　　動画をあげたい。→S3を使う。 dropboxも使ってる
　　　アクセス増えた。入力を仮想サーバー -> 出力をS3から
　　　cache distributionパターン。CDN化して海外対応
　　Eコマース
　　　route53で独自ドメイン
　　　ソフト更新->floatingIPパターンでテストインスタンス立ち上げ、テストがOKだったらIPつけかえる
　　　multiserverパターン。冗長化。DBもLBも設定可能なUI。
　　　DBrepricationパターン。DBのレプリも設定でやってくれる
　　　multidatacenterパターン。web+dbサーバのセットで１つのDC。
　　　nfsreplicaパターン
　　クラウドアーキテクティング
　　　できるだけサービスを利用
　　　机上実験よりも実証実験
　　　スモールスタートからスケールアウト
　　　変化に対し全レイヤで対処
　　　故障のための設計
　（Q）見積もりしにくいんだけど？
　　SMC simple monthly calcurator というのがある。データ量やIOの違いは誤差。
　（Q）ELBがよくわからないよ
　　複数のDCに振り分けられるLBになってる
　======感想=========
　　AWS48。
　　デザパタを用意するというのはクールだなーと思った。
　　業務で運用している色んな手法がデザパタに採用されてて、網羅性に説得力があった。
　　言った通り、インフラをソフトにした。という説明がしっくり来た。
　　各所でプレゼンされている資料がたくさんあがっているようです。
　===================

ソーシャル・コンピューティングをスケールさせるには（facebook)
　700万人->８億人
　フェイルオーバー、エラーハンドリングの話をします
　ソーシャルアプリ、ソーシャルデータとは
　　繋がっているユーザーとやりとりをする＝ソーシャル
　　スケーリングはつながりのスケーリング
　　容姿などの客観情報よりも興味＝人のソーシャル性
　　faceの写真アプリ、できは良くない。リサイズできない、順番替えられなかった。
　　でもfaceが世界最強の写真サイト。なぜか、ソーシャルだから。タグづけができる。
　　クラスタリングとパーティショニング
　　　友達のデータをどのクラスタにのせるかっていうのは制御不能
　　小さなオブジェクト
　　　メッセージの小ささは対話に繋がる。
　　高い更新頻度
　　　対話が繋がるので
　　データの一貫性
　　　銀行や宇宙船じゃないけど、一貫性は必要。対話が成立しなくなる
　　　エンターテイメントでもいい加減なものではなく、大事なものであるという認識を我々は持ってる
　　全てのデータは暖かい
　　　ホットなデータは人と時によって、違う。どれも重要。
　リアルタイムでオブジェクトを扱う
　　パーミッションも同期処理。シンクロナスコールがたくさん。
　水平スケーリング
　　システムのオブジェクト全てをマシンにのせる
　　LB->AppServer->Cache->DB
　　　ユーザーが友達とインタラクションすると、キャッシュが膨らむ
　　App
　　Cache
　　　memcachedに注力してる。秒間１０億read
　　　NWのボトルネック
　　DB
　　　DBではなくストレージだと思う
　　　インデックス効かないと話にならない
　　NoSQL
　　　いいか悪いかの宗教論ではない
　　　NoSQLもMySQLも使ってる
　スケーリング
　　ボトルネックを取り除く
　　エラーハンドリング
　NWボトルネック
　　起こりやすい
　　帯域の問題ではない。
　　１つのAppからたくさんのCacheにリクエストをたくさん投げる。レスポンスで失敗するので、リトライを短くする。失敗するってことは多分過負荷。そんな時にリトライを短くすると助長する。
　　ー＞解決策は全てのキャッシュサーバーに同時にリクエストを投げない。分散する。

　「ミスをゼロにするのではなく、それにかけるコストを減らす」
　ミスをしないのはなにもしないこと。facebookはトライしてみる精神。
　スタートアップ企業の性質と一緒。

　小さな問題が大きな問題にかわるとき
　SPOF
　　ソフト自体がSPOFという問題はあまりでてこないが、結構ある
　　ハードの問題点という方が言われがち。
　　ソフトのリリースを段階的にしていくことが重要
　increaseing load under load
　　リトライをし続けないこと
　funnneling badness
　　ある問題によって、別の問題が顕在化してしまうこと？
　　問題のパーセンテージをトラッキングして、しきい値以上だったら対処する。
　everyone waitng
　　一台が遅くなると、他のものも全部遅くなる？
　　既に待っている状態で、行列を増やさない

　◎大事なこと
　・失敗をテストする。「夜も寝られない心配があるなら、そのソフトウェアは壊せ」
　・全てを監視する
　　　平均値は無意味。分布を見る。故障は少数のマシンで起こる
　・事後解析。何が起きたのかを十分時間かけて解析する。
　　　post-mortems

　MySQLの分散
　　数学的なマッピング。たくさんのバケツを用意する。
　　（要はマネージャ分散っぽい）
　　全てのマシンにキャッシュがある
　　細かくシャッフルしてるけど、問題ない
　（Q）ユーザーのアクティビティ性に応じて特殊対処してる？
　　友人数の上限があるのでパンピーは一緒
　　有名人アカウントは色々やってる
　　　更新頻度が高いので
　（Q）意図的になんかを壊すとは？
　　IPテーブルルールを用意して、NWをおかしくする。電プチするとか。
　　ツールがあったとかわけではない
　　カーネルがおかしいとか起こる
　======感想=========
　　SNSを作られているFacebookさんのセッション。
　　ソーシャルの説明もその通りですねと。
　　＞「ミスをゼロにするのではなく、それにかけるコストを減らす」
　　＞事後解析。何が起きたのかを十分時間かけて解析する。
　　とにかくミスは起きるもの、と捉える。同意。検証と再発防止も大事。
　　業務経験上、ミスの透明性が重要だと思っているけど、そこら辺の共有・周知のルールや考え方などどうしているのか気になった。
　　ソフトウェアがSPOFはなるほど！そういうものを自分達は扱っているし、作っている。新しいハードはテスト検証しながら導入するくせに、自分のコードは豪快にリリースする、っていうのは確かにおかしいなぁと思った。段階リリース大事。
　　NWのテストのために、電プチしてみるとか凄い。しかし、避難訓練としてやった方がいいかもしれないと感じた。お客のデータに障害が起きないようなレイヤならいいのかなと思う。
　===================

Twitterの最新アーキテクチャ
　ツイッターのミッション。
　ツイッターはSNSではない。リアルタイムコミュニケーションネットワーク
　7196tps　なでしこ優勝時。tweet per second
　25088tps　バルスの時。
　　バルス準備は特に何もしてない
　1.4億アクティブユーザー。1日3.4億ツイート。約70％のアカウントは米国外
　
　◎アーキテクチャ
　timelineDB、tweetDB,social graphDB,userDB
　
　最初はRailsでどかっと。
　問題点：１カ所に固まりすぎ。Rubyがそこまで爆速なわけではない。
　
　Modelを分割化。user service , tweet serviceなど。プロセスが別。実装が別。
　各serviceはJVM。scalaで動いてる。
　SOA的なアプローチ。
　SPOFにならない

　リバースプロキシ -> Rails -> DB
　ハードウェアバランシング。だった。
　今：HTTP Proxy -> API -> service -> DBのルートも。Railsルートもまだある。
　HTTP Proxy -> WebI -> service -> DBのルートも構築中。
　JVM化 = Off the Rails.

　膨大な同時接続数
　多量のIO
　ごく少量の永続化対象データ
　　ほとんどは読み込みデータ99%以上。readが鍵。
　※「ツイッターはinterest graph」
　必要なのは
　　サーバー負荷を適切にさばく。
　　言語対応の柔軟性。現時点ではJava,Scala.
　　成熟したコンカレンシーモデル
　javaのコンポーネント
　　検索周りでたくさん使ってる
　　トレンド／キーワードクラスタリング
　javaによりもたらされるもの
　　拡張可能な開発エコシステム
　　成熟したJIT
　　管理されたメモリモデル
　finagle
　　非同期にRPCを実行できるフレームワーク
　タイムラインのトラフィック
　　20万クエリ／秒
　　レイテンシー
　　　中央値1ms
　　　99パーセンタイル4ms
　秒間4kツイート
　ピーク時10kツイート／秒
　配信：　秒間1800万ツイート
　　　　100万のフォロワーに対して、3.5ms
　ツイート書き込みの流れ
　　HTTP Proxy -> tweetAPI -> Queue -> tweet Daemon-> fanout =>delivery
-> timeline cache -> redis
　　fanout : 4000人のフォロワーずつにわけて配信
　　　　　　レディーガがレベルだと、RTのが早いとか
　ツイート読み込み
　　Proxy -> timelineAPI -> timeline service -> timeline cache -> redis

　======感想=========
　「twitterはSNSではない、インタレストなぐラフ」を複数回繰り返していた。なるほど、そうですか。
　Railsでえいやで作ったものを、徐々に疎結合・別システム化していったとのこと。この辺は負荷とサービス規模が
　予想を遥かに超える感じで大きくなるサービスでよく進めていけているなぁと強く関心しした。
　サービスそのものの変化がそれほどない分リファクタ感覚が近いのかもしれないが。。
　1個前のfacebookのプレゼント比較して、技術者集団っぽいなという印象。良い意味でベンチャー気質があって、
　エンジニア主導で進めていそうな雰囲気を感じた
　===================

現場で使えるドメイン駆動設計
　casandraのコミッタのエリックエヴァンスとは別人
　2003年出版の本。原著は。javaにgenericsがない時代。
　
　顧客の仕事を理解すること
　顧客の言葉で理解する事
　モデルを共有すること
　モデルを基にソフトウェアを作る
　
　設計思想と実装方式
　実装方式としてのDDD
　　ユーザーインターフェースを通じて、ユーザーとデータをやりとりする
　　ユーザー-> UI -> ロジック -> 永続データ
　　ロジック構成方針
　　　トランザクションスクリプト
　　　　ユーザーの要求を満たす手続き
　　　ドメインモデル
　　　　複雑なロジックをオブジェクト指向で解決する
　　　ロジックが複雑化すると、トランザクションスクリプトのメンテコストが増大する
　　　分岐点はどこなのか
　　　　慣れた人に任せるしかないよね
　　　手続きとは？
　　　　入力チェック、DBアクセス、演算、編集処理
　　　どういう時に使う？
　　　　ドメインモデルが論理データモデルで表現しきれる場合、ロジックはほぼSQLで表現できる
　　　　->SQLを気持ちよく使う
　　　ドメインモデルが論理データモデルで表現しきれない場合とは？
　　　　「暗黙的な概念」　制約・プロセス・組み合わせがあるルール
　　　　制約
　　　　　制約は論理データモデル上に表現されず、手続きとけ込んで見えなくなる
　　　　　オーバーブッキングの概念がif文の条件に入る
　　　ただし、制約をすべてオブジェクトとして実装する必要はない

　設計思想としてのDDD
　　ハイレベルのドメインモデル　業務の境界と関係を明確化
　　各ドメインのモデルを詳細化し、実装方針を策定する
　　　トランザクションスクリプトが基本とする
　　複雑化は囲い込み、適切なモデリングパラダイムを選択する
　　Big Upfront design?
　　　考える事は重要。期限と予算

　実装方式と開発プロセス
　　トランザクションスクリプトを基本にする理由
　　　基本設計をかきやすい
　　　ほとんどの開発者にわかりやすい
　　　ウォータフォール
　　　　手戻りが許容範囲に収まればアジャイルよりも安いし早い
　　　　　３つの真実<->仕様変更した方が早い場合もある
　　　　プロトタイプは当然作る、CIも重要
　複雑なドメインに対してはそれなりの戦術が必要
　　基本設計が書き難い　要件が整理しにくい
　　イテレーティブ、インクリメンタル
　　シナリオはモデルに目的を与え、モデルはシナリオを実現させる
　　実装方式の策定はメンバの力量や期間と相談
　まとめ
　　業務を理解しよう
　　　業務を表現したモデルを共有しよう
　　適切な方式とプロセスで実装しよう
　　　ウォータフォールの手堅さ、アジャイルの柔軟さ
　　チームで実現できるアーキテクチャを

　======感想=========
　ホントは、いかにしてドメイン駆動設計を行うかを聞きたかったのですが、内容としては
　「まぁまぁ落ち着いて。身の丈・状況にあった時だけ使いましょう」というものだった。
　確かにSIの現場を考えたら、現実解というか非常に的を射た答えだと思った。
　アジャイルと同様、言葉が先行してしまうのは確かに良くない。
　===================

ソーシャルゲームにおけるAWS／MongoDB利用事例
　MongoDB
　　ドキュメント指向
　　フルインデックスサポート
　　レプリケーション
　　　replicaset　セカンダリの自動昇格。その間自動リカバリ
　　auto-sharding
　　　指定したshard keyで水平分割

　Animal Land
　　町づくりゲーム
　　S3　htmlや画像の配信
　　CloudFront　海外対応
　　Ehcache - javaプロセスでキャッシュする
　　RestFB　facebookにアクセスのため

　======感想=========
　このまとめを書いていたので、軽く聞く程度で。。
　資料はサイトからDL可です。
　===================

まとめると、オフィシャルというか大人な内容の発表が多かった。
聞く方も大人で、業務に活かせる部分があるかマッチングにしに来ている感じでした。
懇親会でほとんど絡めなかったのが反省点。

Yokohama.pm #8 に参加してきました

blogを書くまでがYokohama.pmです。たぶん。

金曜日はYokohama.pm #8に参加してきました。
今回は僭越ながら発表させていただきましたので、資料は以下に置きました。
http://masartz.github.com/presentation/yokohamapm-8/start.html

ustもどうやら下にアップされているようです。
http://www.ustream.tv/recorded/18590454

YAPC::Asia 2011で話せなかった後悔から勢いで申し込みましたが、なんとか喋りきりました。
練習では全然尺におさまってなかったんですが、本番は時間ぴったり。資料にも混ぜてますが、「ここで半分」みたいな区切り入れるのを真似して良かったです。

内容については、コードはほとんど出てこなくて、最近やってたお仕事の業務報告的な感じですが、今までとちょっと違う事をやったので色々と知る事が多かった点を話してみたいと思ってやってみました。

最後にも触れましたが、「大規模すげーわ、マジすげーわ」という事が言いたい訳でもなく、
「マネジメントキツいわ、マジキツいわー」という事が言いたい訳でもなく（というか俺リーダーじゃない・・・）、
日々黙々としている仕事について発言してみる事も自分や誰かのためになるんじゃないかなと思います。

個人的には、今後はまたちょっとやる事変わりそうなので、このように振り返って残しておけて良かったかなと。

一部でてきたコードの部分について、早くもその場でアイコンカッコ良い人から突っ込み入りましたが、その後オンライン／オフラインで話して、結論としては資料のサンプルが良くなかった。。

bindのミスならnamedプレースホルダを使えばおk、というご指摘はまさに仰る通りです。同じように突っ込む方もいるかもしれませんので、少しだけ補足すると、
bindはサンプルとも言えないただの例で、要は「実際にInsertメソッドをよびだしたあとの結果をdbから引き直して中身チェック」っていうことがしたかっただけで、bindに限ったアプローチという訳ではありません。
これは基本的に動的にSQL文を作らない開発フローにも起因するので、多分これでも説明できてない・・・、この辺についてはもうちょっと自分の中でも再検討が必要なようです。

事前にclouderさんにはご相談させていただいたのですが、今回実は会場の入り口に弊社のちょっとしたグッズを置かせていただきました。
前回に引き続き今回の会場も、livedoor社さんの技術部会が支援してくださった会場であり、その場に他社のグッズを置く事を快く承諾してくださったclouderさんとlivedoor社さんに改めてお礼申し上げます。ありがとうございました。
会場自体もWifi提供など充実しており、非常に快適でした。

直前まですったもんだした懇親会も見事に確保したmyfinderさんも++でした。あのもつ鍋は旨かった！

そんなこんなでお疲れさまでした。
また次回楽しみにしています！

YAPC::Asia 2011に行ってきました

blogを書くまでがYAPCです。
今年も行われたYAPC::Asia 2011に前夜祭含め参加してきました。

各トークの細かい内容とかは例によってhirataraさんの記事が一番詳しいのではないかと
思いますし、各スピーカーの方々が資料をアップされているので、そちらを参照すれば良いでしょう。

個人的には、去年はスピーカーとして発表させていただいてダメダメだったので、
今年はリベンジの意味でもう1回トークしたいと思っていたのに出来なかった事が
一番の反省要因です。

トークについては、ベストスピーカー賞に輝いたfujiwaraさんのトークは実際に聞いていて
実は投票もしていたのですが、話がすごく具体的かつ流れがある内容でおもしろかった。

zigorouさんの内容についてはdep-opsな同僚の人と聞いていて、アプローチや環境の違いについて
話したりしてました。課金に絡む部分だとトランザクションが多くなるのがその辺の違いに
現れてるかも、という見解には納得でした。

とかとかあるんですが、今年もたくさんの方と話す機会があって、もうトークよりそっち
メインだったんじゃないかという気もしてます。

印象に残っていること

• 前夜祭でkanさんに、懇親会で刺身さんに、空気読まずにRubyの話を聞いたけど、丁寧に教えてもらってすごく嬉しかったです
• 前夜祭LTのkamipoさん発表で、「最新20件を取る時、先にフォロワーの最新投稿者20人を絞り込む」というアプローチはなるほどと思った
• 大規模サイトを運営している某社では、デプロイタイミングが定期的ではないらしい&テストは通らないとコミットできない仕組みになってるとか。
• 2日目のyappoさんのLTで社内nopasteを作ったと言ってたので、これは確かに便利かも、あった方がいいかもと思った。それだけでなく、社内の情報をどう収集し、どう活かすかなどLTとは思えない密度だった。

今回発表できなかったのは残念ですが、この反省を活かさないとな。と思いました。
懇親会でclouderさんに「次のyokohama.pmいつですか？やりたいです」って話してたんですが、
近々開催しそうですね！YAPC熱が冷めないうちに「次のyokohama.pmではなんか喋ります！」ってここで言っておきます。

最後になりますが、運営スタッフの皆さん、ボランティアの皆さんお疲れ様でした。
会として過去最高の規模だったようですが、過去と比べても非常にスムーズな運営をされているように感じられました。
今回で最後と言わず、来年もぜひ開催してほしいです。

最後の最後におまけですが、今回一番の収穫。
milanoさんの豪腕で、とても貴重なダブルネームサイン入りTシャツになりました。
来年トークする機会があったら、これ着て喋りたいですね。（逆に普段着れない･･･）