LTで二次元嫁botについて語った - YAPC 2015
さいです。YAPC 2015に行ってきました。 適当に発表まとめようかなと思います。
前夜祭
PHP帝国の逆襲！
・次のPHPは5.6から一気に7にバージョンアップされます
・PSR-7 がきまるよ！ PSRとはPHPer有志による設計のベストプラクティス的な仕様
・メルカリはサーバサイドはPHP! SlackもサーバサイドはPHP!
・HHVM ⇛ PHP7に速度で並ばれちゃった。
・Hack という言語を初めて知った。
Perlワンライナー入門
スライド Untitled - Swipe
perl ワンライナーに便利なコマンドラインオプション
-n オプション
while(<>) {
[PerlScript]
}
-l オプション
標準入力の行を事前にchompしてくれる
-M オプション
モジュールをuseしてくれる
perl ワンライナーが向いてること
1.テキストデータの中から
2.正規表現で文字列を抽出して
3.抽出したデータを関数、クラスに渡す
perl の出自はそもそもsed や awk あたりなわけで。
perl の謎言語仕様($_, <>, 謎変数, 頭のおかしい正規表現)はワンライナーのためにあるわけで。
いつの間にか web アプリケーションを記述する言語となったわけで。
perl の機能のうち、web アプリケーションに向いた部分だけ抽出したのが近年のLL言語なわけで。
Web アプリケーション用言語って視点から perl を語ることの視野の狭さを感じたわけでした。
入力と出力に真摯に向きあえば、perl ワンライナーを効率的に活用することができる。
技術ブログを書くことについて語るときに僕の語ること
・みんなが興味を持ちそうなワードをタイトルに入れる
・投稿時刻は平日の朝が無難
「Q.承認欲求ドリブンでブログを書くと、ブログ初期のブクマが伸びない時期とか辛くないですか？」
↓
「A.積極的に技術情報はブログに書いていくべきというエンジニア文化とか
そういう周囲の声もあってブログを書くことに辛さは感じなかった」
というやり取りがあって、「おぉ……(弊社ではそんな声聞いたことないぞ)」って思って、
そういう空気感とか文化的なところを弊社でも作っていきたいと思った。
個人の技術ブログは、当人にとっても活動が他人から明確にわかりやすくなるだけでなく、
所属を明らかにブログを書いてれば、その会社にとっても、採用活動等にメリットがあるってエライ人が言ってた。
1日目
メリークリスマス！
Perl6 が 2015年クリスマスに！！！！
Larry Wall がやたら指輪物語に絡めてPerlの話をしてくるのを聞きながら
「あー海外のナードってハリーポッターや指輪物語に熱狂的な人多いよなー。
日本のナードがアニメ好きな人多いのと一緒で、コンピュータ触ってると
現実世界に可能性見出さない人多いのかしら」
とか思ってた。
世界展開する大規模ウェブサービスのデプロイを支える技術
Miiverse はHTML5+CSS+ perl(!) のいわゆるオーソドックスなWeb技術で出来てるそうです。
Git pull でデプロイ ⇛ Gitレポジトリが一台 ⇛ 本番サーバーのリージョンが世界のあちこちにある
⇛ 海を跨いでGit pull ⇛ ヤバイ！
Gitレポジトリをmaster/slave に分けて、同期サーバーが片方からpull 片方へpush で
両方のHEADをあわせるとかやってて面白かった。
Consul の話も出てきた。
Consulと自作OSSを活用した100台規模のWebサービス運用
Consulの話。YAPC, Consulの話この後他の発表でも死ぬほど出てきて、
こりゃ〜トレンドについていかないといけませんな〜ってなった。
Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜
ソフトウェア開発だ……って思いながら聞いてた。
技術的負債ができるのは仕方ないからどんどん返していこうねってのは
既に当たり前のように思ってることだけれど、具体的にどう返していくのかってイメージ湧いた。
古いアーキテクチャ、クラス設計の部分はそのままに、新しく作る箇所、修正を加える箇所については
積極的に新しいアーキテクチャに置き換えていく。
発表で紹介された本 hitode909.hatenablog.com
実践ドメイン駆動設計はちょっと気になってたので読みたい。
esa.io - 趣味から育てたWebサービスで生きていく
スライド esa.io - 趣味から育てたWebサービスで生きていく // Speaker Deck
・esa.io ⇛ Markdown によるチーム内ドキュメント共有サービス
・もともと趣味で作ってたサービスを事業化&会社化
・仕事が終わってから毎日ハッカソン状態
・知人の会社が使ってくれることに
・楽しさやモチベーションは直接コントロールできない
・やれることを、やる
⇛楽しさやモチベーションを生み出す可能性のある行動をする
・毎日 Bundle Update
⇛ Botが毎日使用中のライブラリのバージョンを上げてPull Requestを上げてくる
・Bug fix タイムアタック
・開発スケジュールを決めない
⇛モチベーションの赴くままにやるのが最終的に効率が良い
⇛ユーザーからたくさん要望が来る⇛モチベーションが上がる⇛対応する
かの有名な小飼弾さんも言ってましたが
「アウトプットしない限りこの世にお前は存在しないのと一緒だ」
なのでエンジニアとして本を読んで勉強するのも大切ですが、
アウトプットしようという気になった。
趣味開発は、1. 何を、2. どう作って、3. どう使ってもらうかってとこが
だいたいみんな問題意識あるっぽいので、そのうち自分の拙い仮説をまとめたい。
LT
Slack + Hubot でお前の一番好きな二次元嫁キャラと一緒に仕事をする
www.slideshare.net
発表しました。
僕「二次元嫁botと2人でチームを作ります！！！」
会場「ざわざわ……」
僕「(二次元美少女は)クール」
会場「ざわざわ……」
僕「(二次元美少女は)最高」
会場「ざわざわ……」
稚拙なトーク内容でしたが、聞いてくださった方達、
ありがとうございました！
2日目
ISUCONの勝ち方
・コミュニケーション大事
・決まったことはメモで残す
・最初の1時間は課題の理解、プロファイリング
・最後の30分は再起動テストに残す
・事前に用意しとくと良いもの
プライベートなgitレポジトリ
wiki
メンバのSSH公開鍵
チャットルーム
技術選択についての簡単な打ち合わせ
過去問を解く
・まずブラウザで課題となるサイトへアクセスする。とりあえずベンチマークを動かす。
・見るべき点
プロファイリング
アクセスログ
MYSQL Slow Query
アプリケーションのプロファイリング
サーバ負荷の確認
・アクセスログ解析
ベンチマークツールがアクセスしてる先を知る
ツール
analyze apache logs
kataribe
・MySQL SlowLog 解析
クエリの実行回数と頻度の両方を見る
⇛ N+1 のようなSlowではないが発行回数が多いSQLを特定する
⇛ SlowLog=0 で全てのログを出力する
pt-query-digest ってツールが便利
・アプリケーションのプロファイリング
strace
tcpdump
・サーバの負荷
top 全体の負荷
iftop ネットワーク
iotop ディスクI/O
dstat
・参照を減らす
・通信を減らす
・プロセス・スレッドの数を減らす
・チューニングのヒント
Apache vs Nginx ⇛Nginx 有利
Nginx vs h2o ⇛h2oの方がスレッド型なのでh2oの方が有利か
外部プロセスの起動
HTMLテンプレート処理
テキスト／画像変換処理
RDBMS/Cacheの起動
N+1
・変更を都度記録し、壊れる前の状態に戻せるようにする
我々はどのように冗長化を失敗したのか
またConsulの話でてきた
MySQLで2億件のシリアルデータと格闘したチューニングの話
シーケンシャルな値でテストデータ作ると、本番時にランダムな値だった場合に
インデックスの再構築の負荷を見逃す。
実践nginxモジュール開発〜CとLua〜
nginxはモジュール指向アーキテクチャである
ビルド時に3rd partyモジュールも導入できる
nginx_http_hello_world くらいなら実装できそうだし実装してみよかな〜ッて思ったが
ぶっちゃけ、ngx-Luaやngx-mruby 触った方が楽しそう。
OpenRestyというのを初めて知った qiita.com
ソーシャルゲームにおける AWS 移行事例
辛いことをやめる！から始まる業務改善とInfrastructure as Code
技術寄りの話かと思ったら、人間の話かつ身に覚えのある話だったので
胸をキリキリさせながら聞いてた。
www.slideshare.net
組織の中で業務改善を進めていくには〜ってお話。
・スタッフには「メリットがあることを伝える」
・上長には「工数を減らせることを伝える」
・みんななかよく。⇛変革は敵を作ってはダメ。人を尊重する
・CTOの承認を得よう
⇛これは会社全体としてやるということをみんなに周知する
・トラブルはすぐ対応する
対応が遅いとみんながツールを使うのをやめてしまう
・布教
ドキュメンテーションは必須。
特にTipsを残す。
ハンズオン
具体的に理解してくれる
ハンズオンは何回もやる
・みんな変化は怖い
受け入れるといいことがあるということを洗い出して、人に誠意を持って伝える
ハンズオンはココロの障壁を下げます。俺でもできるんじゃんっていうことが伝えられる。
・CTOや上長に反対されたりするときは時間を置く。人は考えが変わる生き物
・CTOと事前に人間関係を作っておく
・仲間を増やして一緒に上長と掛け合う
・ボトムアップの場合は『おまえ(だけのの意見だよね』で蹴られることが多い
・変革のメリットを説明する時に、うまくいかなくても決して相手に対して怒ってはいけない。
終わり
思った以上に Consul の発表多くてびっくりした。
HashiCorp社製の製品が激アツ。
