Hatena::ブログ(Diary)

masartz->log RSSフィード

2013-09-24

YAPC::Asia 2013に行ってきました 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 開催全般で言うと、運営の方々の安定感もあり、特に困る事はありませんでした。

メイン会場の電源が確保されていたり、ネットワーク環境が整備されていたり何不自由なく過ごせました。

スポンサー企業のご協力でサービスしていただけた部分(懇親会とか)、ボランティアの方々、

もろもろ含めてお疲れ様でした&ありがとうございました。


ここまで完成されたイベントが来年からどうなるか楽しみ以上に不安な部分も大きいですが、

ぜひとも継続して開催してほしい、いやしていくのに協力したい、と思いました。

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

2012-10-01

YAPC::Asia 2012に行ってきました 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!

f:id:masartz:20121001141801j:image:w360

2012-07-10

Params::Validate をuseする時「use Params::Validate qw//;」と書くのを推す理由 Params::Validate をuseする時「use Params::Validate qw//;」と書くのを推す理由を含むブックマーク

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

use Params::Validate qw//;

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


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


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

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今年も楽しみですね!

2012-07-03

gitで別のリポジトリにpushする 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する」というのは多分あんまりないので、書き残しておきます

2012-04-20

Qcon2012に行ってきた Qcon2012に行ってきたを含むブックマーク

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


カンファレンスもよく考えたらYAPCくらいしか行ってないので、そこそこ不思議な気分でした。

多分参加者は150人くらい。さすがに知り合いの人はいませんでした。。


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


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


よくあるカンファレンスの流れなのか、みんな淡々とセッションを聞き・移動する。ということで淡々と過ぎて行きました。

席から電源が取れなくて、休憩時間の度に充電する必要があったのがちょっとマイナス。。でも、周りの人もノートPCより紙のノートの人のが多かった。

あとはお菓子と少しの飲み物が提供されて、同時通訳が凄かった。とかが印象。


Keynote 1 怪しい都市伝説

 cloudのメリット

  小規模でも使える

  NASAではギガピクセルデータをhadoopで分析して、ipadで確認 なんてのができる

  火星->S3->みたいな流れ

  機密のためにはaws double cloud

  NASAamazon,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登場(翌日)

  スピード感が一番大事

  ニーズを検証するより、ニーズそのものがあるかわからない

 ※アプリ開発の壁

  3位:技術力の欠如

      やり続ける。調べる。わからないけど動く、でとめない

  2位:モチベーションの減退

      休憩大事。俺俺ミッションを作る。

  1位:ユーザーフィードバック

      正直キツい。お客こわい。

 個人のアプリ開発で大事な事

  技術/リード・マネジメント/デザイン/メンタルコントロール/語学力/その他

 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パターン

   キューの処理もシステム化されてる

 実装シナリオ

  5個ある

  CGMシナリオ

   動画をあげたい。→S3を使う。 dropboxも使ってる

   アクセス増えた。入力を仮想サーバー -> 出力をS3から

   cache distributionパターン。CDN化して海外対応

  Eコマース

   route53で独自ドメイン

   ソフト更新->floatingIPパターンでテストインスタンス立ち上げ、テストがOKだったらIPつけかえる

   multiserverパターン。冗長化DBもLBも設定可能なUI

   DBrepricationパターン。DBのレプリも設定でやってくれる

   multidatacenterパターン。web+dbサーバのセットで1つのDC

   nfsreplicaパターン

  クラウドアーキテクティング

   できるだけサービスを利用

   机上実験よりも実証実験

   スモールスタートからスケールアウト

   変化に対し全レイヤで対処

   故障のための設計

 (Q)見積もりしにくいんだけど?

  SMC simple monthly calcurator というのがある。データ量やIOの違いは誤差。

 (Q)ELBがよくわからないよ

  複数のDCに振り分けられるLBになってる

 ======感想=========

  AWS48。

  デザパタを用意するというのはクールだなーと思った。

  業務で運用している色んな手法デザパタに採用されてて、網羅性に説得力があった。

  言った通り、インフラをソフトにした。という説明がしっくり来た。

  各所でプレゼンされている資料がたくさんあがっているようです。

 ===================



ソーシャル・コンピューティングをスケールさせるには(facebook)

 700万人->8億人

 フェイルオーバー、エラーハンドリングの話をします

 ソーシャルアプリソーシャルデータとは

  繋がっているユーザーとやりとりをする=ソーシャル

  スケーリングはつながりのスケーリング

  容姿などの客観情報よりも興味=人のソーシャル

  faceの写真アプリ、できは良くない。リサイズできない、順番替えられなかった。

  でもfaceが世界最強の写真サイト。なぜか、ソーシャルだから。タグづけができる。

  クラスタリングとパーティショニング

   友達のデータをどのクラスタにのせるかっていうのは制御不能

  小さなオブジェクト

   メッセージの小ささは対話に繋がる。

  高い更新頻度

   対話が繋がるので

  データの一貫性

   銀行や宇宙船じゃないけど、一貫性は必要。対話が成立しなくなる

   エンターテイメントでもいい加減なものではなく、大事なものであるという認識を我々は持ってる

  全てのデータは暖かい

   ホットなデータは人と時によって、違う。どれも重要。

 リアルタイムでオブジェクトを扱う

  パーミッションも同期処理。シンクロナスコールがたくさん。

 水平スケーリング

  システムのオブジェクト全てをマシンにのせる

  LB->AppServer->Cache->DB

   ユーザーが友達とインタラクションすると、キャッシュが膨らむ

  App

  Cache

   memcachedに注力してる。秒間10億read

   NWのボトルネック

  DB

   DBではなくストレージだと思う

   インデックス効かないと話にならない

  NoSQL

   いいか悪いかの宗教論ではない

   NoSQLもMySQLも使ってる

 スケーリング

  ボトルネックを取り除く

  エラーハンドリング

 NWボトルネック

  起こりやすい

  帯域の問題ではない。

  1つの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でどかっと。

 問題点:1カ所に固まりすぎ。Rubyがそこまで爆速なわけではない。

 

 Modelを分割化。user service , tweet serviceなど。プロセスが別。実装が別。

 各serviceはJVMscalaで動いてる。

 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

 ======感想=========

 「twitterSNSではない、インタレストなぐラフ」を複数回繰り返していた。なるほど、そうですか。

 Railsでえいやで作ったものを、徐々に疎結合・別システム化していったとのこと。この辺は負荷とサービス規模が

 予想を遥かに超える感じで大きくなるサービスでよく進めていけているなぁと強く関心しした。

 サービスそのものの変化がそれほどない分リファクタ感覚が近いのかもしれないが。。

 1個前のfacebookプレゼント比較して、技術者集団っぽいなという印象。良い意味でベンチャー気質があって、

 エンジニア主導で進めていそうな雰囲気を感じた

 ===================




現場で使えるドメイン駆動設計

 casandraのコミッタのエリックエヴァンスとは別人

 2003年出版の本。原著は。javagenericsがない時代。

 

 顧客の仕事を理解すること

 顧客の言葉で理解する事

 モデルを共有すること

 モデルを基にソフトウェアを作る

 

 設計思想と実装方式

 実装方式としてのDDD

  ユーザーインターフェースを通じて、ユーザーとデータをやりとりする

  ユーザー-> UI -> ロジック -> 永続データ

  ロジック構成方針

   トランザクションスクリプト

    ユーザーの要求を満たす手続き

   ドメインモデル

    複雑なロジックオブジェクト指向で解決する

   ロジックが複雑化すると、トランザクションスクリプトのメンテコストが増大する

   分岐点はどこなのか

    慣れた人に任せるしかないよね

   手続きとは?

    入力チェック、DBアクセス演算、編集処理

   どういう時に使う?

    ドメインモデルが論理データモデルで表現しきれる場合、ロジックはほぼSQLで表現できる

    ->SQLを気持ちよく使う

   ドメインモデルが論理データモデルで表現しきれない場合とは?

    「暗黙的な概念」 制約・プロセス・組み合わせがあるルール

    制約

     制約は論理データモデル上に表現されず、手続きとけ込んで見えなくなる

     オーバーブッキングの概念がif文の条件に入る

   ただし、制約をすべてオブジェクトとして実装する必要はない

 設計思想としてのDDD

  ハイレベルのドメインモデル 業務の境界と関係を明確化

  各ドメインのモデルを詳細化し、実装方針を策定する

   トランザクションスクリプトが基本とする

  複雑化は囲い込み、適切なモデリングパラダイムを選択する

  Big Upfront design?

   考える事は重要。期限と予算

 実装方式と開発プロセス

  トランザクションスクリプトを基本にする理由

   基本設計をかきやすい

   ほとんどの開発者にわかりやすい

   ウォータフォール

    手戻りが許容範囲に収まればアジャイルよりも安いし早い

     3つの真実<->仕様変更した方が早い場合もある

    プロトタイプは当然作る、CIも重要

 複雑なドメインに対してはそれなりの戦術が必要

  基本設計が書き難い 要件が整理しにくい

  イテレーティブ、インクリメンタル

  シナリオはモデルに目的を与え、モデルはシナリオを実現させる

  実装方式の策定はメンバの力量や期間と相談

 まとめ

  業務を理解しよう

   業務を表現したモデルを共有しよう

  適切な方式とプロセスで実装しよう

   ウォータフォールの手堅さ、アジャイルの柔軟さ

  チームで実現できるアーキテクチャ

 ======感想=========

 ホントは、いかにしてドメイン駆動設計を行うかを聞きたかったのですが、内容としては

 「まぁまぁ落ち着いて。身の丈・状況にあった時だけ使いましょう」というものだった。

 確かにSIの現場を考えたら、現実解というか非常に的を射た答えだと思った。

 アジャイルと同様、言葉が先行してしまうのは確かに良くない。

 ===================



ソーシャルゲームにおけるAWSMongoDB利用事例

 MongoDB

  ドキュメント指向

  フルインデックスサポート

  レプリケーション

   replicaset セカンダリの自動昇格。その間自動リカバリ

  auto-sharding

   指定したshard keyで水平分割

 Animal Land

  町づくりゲーム

  S3 htmlや画像の配信

  CloudFront 海外対応

  Ehcache - javaプロセスキャッシュする

  RestFB facebookアクセスのため

 ======感想=========

 このまとめを書いていたので、軽く聞く程度で。。

 資料はサイトからDL可です。

 ===================



まとめると、オフィシャルというか大人な内容の発表が多かった。

聞く方も大人で、業務に活かせる部分があるかマッチングにしに来ている感じでした。

懇親会でほとんど絡めなかったのが反省点。