初参加で2日間参戦です。
無事閉幕しましたが、まだまだブログに書くまでがYAPCなので2日目の感想もぼちぼち書きます。
Mackerel開発におけるScalaとGo、そしてPerl
http://songmu.github.io/slides/yapc-asia2015/#0 (スライド)
Mackerelでは複数の言語を使い分けているので、どんな基準で使い分けているか、という内容。
- Scala + Playをサーバサイド
- がっちり作るものに向いているため
- 何でもかんでも全部Scalaだとビルドしてデプロイまで20分かかり、大変なので使い分け
- golangはmackerel-agentとmkrと、外部監視の仕組み
- Perlはmackerel-agentのリリース自動化
- どの環境にも大体入っているので、プロジェクトの脇役として
- 普通にWebアプリケーションを作るパワーはある
- Rubyはfluentdのプラグイン(fpluent-plugin-mackerel)など
- 既存のエコシステムに乗っかるために
- 手元のツールを作るのにも最適
- JavaScriptやHaskellも適材適所で
という使い分けをしているようでした。
適材適所で使い分けるというのは良いのですが、言語数が多くなればなるほど言語毎に人が別れて属人化してしまいそうだなと思ったり。
同じような質問が質疑応答が出てきてその答えが、「みんな何でも書く」らしいです。はえー・・・。
とはいえやはり属人化しがちなので、ScalaやGoはレビューをしながら進めているそうで、知見が無い人がレビューをする事で知識が身についていくらしいです。
分かんなかったら勉強しよう、との事。
自動化機構は負債になりやすい、という話も出ていました。どんどん肥大化してやがてメンテ不能に・・・というのはありがちな話です。
それを防ぐためにはちゃんとテストを書いたり、責務を分けるというのが大事なようです。
1個のツールには1個の役割だけ持たせたり、最悪ローカルでは動かせるようにしておく必要があります。
あと、はてなブログの記事をgitで管理するblogsyncが紹介されたのですが、かなり便利そうでした。
NASA主催の世界最大級ハッカソンSpaceAppsを運営した話
www.slideshare.net
NASAが世界規模でやっているハッカソンについて、運営している中で出た知見を共有して頂きました。
やはり運営するとなるとかなり大変で、場所決め・会計などなど・・・考えなければいけない事がかなり多いです。会計は色んな要素が組み合わされるので特に大変そうです。
スポンサーは、ただ単に集めまくるというのも良くなく、「趣旨に賛同してくれるスポンサー」を集めるというのが重要で、もちろんそれに見合ったリターンをする必要もあり・・・。
また、無断キャンセルをいかに防ぐかというのも重要で、「無断欠席すると今後お断りする場合があります」と書いたら一定の効果が出たようです。
進め方の中では、コミュニケーションとドキュメントが重要と仰っていました。
コミュニケーション不足は様々問題の元だし、とはいえオンラインでは不十分。打ち合わせの間に雑談するとか空気感が大事なので、とりあえずご飯は行ったほうがいいみたいです。
ドキュメントはただ書くだけではなく、「頭の中のものを書き出す」というのを忘れずに。
お願いとして「5回に1回ぐらい運営側に回りましょう」との事でした。やってみたいな〜感はすごいあります。
仲間や居場所ができて、段取り力も養えて達成感味わえるらしいです。
あまり関係無いですが、冒頭に出たキーボードにプロジェクションマッピングしてるのかっこ良かったです。
Docker３兄弟について〜そして4兄弟へ〜
Dockerのツールである、Docker Machine/Docker Compose/Docker Swarmの話。全部βらしいです。
最近はAWSとかでもDockerが使えるので、そこのサーバをDocker Machineで操作したり、複数のコンテナで構築されるサービスを1つのYAMLで定義してDocker Composeで構築管理したり、Docker Swarmでクラスタリングしたり・・・とDockerも簡単に色々できるようになってきたなーという印象でした。
しかも、やろうと思えばマルチクラウドでのクラスタリングもできるらしく、実現できればサービスが分散できるためかなり面白いのではないでしょうか。
最近、Windows/MacでDocker使うためのboot2dockerがDocker Toolboxというのに置き換わっていたのも初めて知りました。
この中にDocker Kitematicというのが内包されていて、GUIからDockerの操作ができる(バックエンドはVirtualBox)という嬉しいものになっていたので、boot2dockerよりかなり使いやすくなっていそうです。
(Kitematicが4人目の兄弟、という話だったような気がします)
まだDockerをあまり触れていないので、色々出そろってきた今がもう一度入門し直すチャンスなのではないかと思いました。
Adventures in Refactoring
GitHubの中の人による、リファクタリングをどうしているかという話。 かなりテクニカル(という予告があった)だったり、そこそこ早口で進んでいたので同時通訳大変だなーと思っていたのですが、代わり代わり頑張って頂けたようでこれもまた聞きやすかったです。
話では始めにリファクタリングの成功の基準が出てきましたが、こんな感じでした。
- コード数が減った
- コードカバレッジが上がった
- テストの表現性が増し、テストが何をしているか分かりやすくなったもの(オレオレルールらしい)
- パフォーマンスの向上
- 開発者がハッピーになったもの
これには若干思う所があって、コード数が減るのはもちろん良いけど、減らない場合もあるはずでそこはどうなんだろうという感じでした。 結果的にハッピーならそれで良い、という訳では無いはずなので、まだまだ検討する余地があるという所なのかもしれませんが・・・。
で、何故リファクタリングをするのか、というのはこんな感じ。
- 開発者がハッピーになるため
- 性能の向上のため
- 将来の作業に向けての自信を獲得するため
- 開発者の教育
(3)が重要で、新しく機能を追加する時などに既存のシステムについて恐怖心があると自信が無いという事になります。
過去の負債を返済する(paying off technical debt)ためにリファクタリングを行います。
開発者の教育というのもなるほどなーという感じで、システムのエッジの部分に目を行かせる事になるそうです。
振る舞いの変わらない所から触らせる(=リファクタリングさせる)事で教育にも繋がる、という感じです。
リファクタリングにおけるテクニックも紹介して頂きました。
- ちょこちょこハッピーを入れる(見つける？)
- スタイルガイドを得る
- 命名規則を整理する
- 使いやすい抽象化レイヤーを追加する
- 逆に、不要な抽象化レイヤーは取り除く
要するに整理整頓を欠かさず行う事で、改善に繋がるという事のようです。(そりゃそうかもしれませんが) (1)は、改善される事でコードが見やすくなったりネストが減って、泣きたくなるコードが減るのでハッピーになります！という事で。
まぁもちろんそんなリファクタリングにも落とし穴はあり・・・
- 既存のバグ
- パフォーマンスの変化
- リファクタリングの規模
に気を付けなければならないそうです。
既存のバグは重要な問題で、リファクタリング中にバグを直すべきでは無いと。挙動が変わるので、リファクタリングが原因かfixが原因か分からなくなります。
規模の問題は、大規模すぎるようなリファクタリングはリスクの元なので、細かく区切ってリファクタリングしましょうとの事でした。
質問も色々出ていて、メモしていた範囲ではこんな感じでした。
- リファクタリング中に意見が分かれたらどうするか
- スタイルガイドである程度解決されるので、後は話し合いで
- 機能を追加するべきか、リファクタリングをするべきか迷ったらどうするか
- 既存のものに自信があるかどうかで変え、自信が無ければリファクタリングすべき
- デザインパターンは使っているか
- 意識しすぎると「コードをテストに合わせてしまう」ので良くないので使っていない
- 良いテストからコードが生まれるというのを意識する
- テストもドキュメントも無いんだけどどうすれば良いか
- 簡単に良くする手段はない
- まずテストを書いて、リファクタリングはその後に始める
この中で「素晴らしい仕事をしたら褒めよう」とも言っていました。褒めるのに🔪(:hocho:)を使うのが流行ってるらしいです。 (褒める時じゃなった気もする)
最初から最後まで、1年目〜2年目のようなエンジニアなりたての人が聞くとかなりためになる気がする内容でした。
スライド公開されないですかね・・・。
ソーシャルゲームにおける AWS 移行事例
お題そのままですが、カヤックで運営しているソーシャルゲームをいかにしてオンプレからAWSに移行したか、という話。
中でも、RDS(MySQL)のタイムスタンプの問題は初耳でした。UTCに固定されてしまうため、移行元でJSTの運用をすると時間がずれてしまう場合があるとか。
また、MySQLの移行はかなり時間がかかるようで、いかに時間を短縮するか、というため色々探した結果、こんな資料があったようです。
dumpして再度importする機会がたまーにあるので、結構活用できそうでした。
他にも、Falloverの検証に手を焼いたり、証明書の問題もありと課題はそれなりにあったようです。
ここでもConsul+Stretcherの話が出てきて、移行後に採用したとの事なのでそこそこ盛り上がりつつあるんだなーと思いました。
あとは、レプリケーション可能なMemcached互換サーバのyrmcdsを移行のタイミングで使い始めたとの事。これも初耳でした。
移行作業の演習は、構築した本番でやって終わったらdropして・・・の繰り返しだったようなので、そんなもんでいいのかと思いました。 専用の環境立てたりするよりは楽ですし、確実に消せば良いのでそんなもんなのかもしれません。
辛いことをやめる！から始まる業務改善とInfrastructure as Code
www.slideshare.net
最終日というかYAPC最後のトークは、何をしようか迷った結果業務改善についての話を聞きに行きました。辛いことやめたい。 成功談だけではなく、そこに至るまでの経緯を詳しくご紹介頂いたのでかなり参考になりました。
何をするにもまず問題を理解する所から始め、ヒントを探したり現状とゴールのギャップ(goal-reality pairs)を把握する必要があるとの事。
人は変化を怖がるため、それを受け入れると良くなるというのを納得させる必要があるため、理解する必要があるようです。
しかもただ説明するだけでは良くなく、相手の立場に合わせてメリットを伝える必要もあります。
過程において重要な人(CTOとか)を巻き込んでトップダウンで行うのも効果的と仰っていました。
ボトムアップだと「お前の仕事だろ」と言われてしまうらしく・・・会社としての方針を統一でき、「付いていくように」と言って貰えるよう重要な人を巻き込む必要があります。この時に一緒に巻き込める仲間がいるとより進めやすくなるみたいです。
また、導入の間は少しでも動かなかったり「あれ？」という声がしたら即座に反応するというのも円滑に進めるために必要なステップのようです。
後はドキュメントを、導入中にあった問題と解決方もあわせてしっかり残したり、ハンズオンを何回も何回も繰り返しやって浸透させ、心の障壁を下げるのも重要です。
評価(効果測定)も忘れずに行います。 今回でた例だと3週間で開発して教育には3ヶ月かかったけど、作業に必要な時間が1/10になったのですぐに取り返せるレベルになったみたいです。 すると、結果的に残業も減って他の事も楽しめ、モチベーションも上がり・・・という良いサイクルが生まれそうです。 プログラミングによって生産性が上がった事で、プログラミングが楽しいというのを知ってもらえ、社内にプログラミング部が出来たとか。
ちゃんと調べてちゃんと変わるところを伝え、開発後の導入時のサポートは手厚く(特にハンズオン)行えば円滑に業務改善が進められそうです。 業務改善というと難しいイメージがありましたが、こうやって話を聞いてみるとシンプルだったな、と思いました。
クロージング
楽しい楽しいお祭り2日間も終わりの時が。
過去のYAPCを振り返ったり、今年の来場者数が発表されたり・・・。
ネットワークは常時100Mbps出てたしいので、CONBUの皆さんには足を向けて寝られません。
YAPCの名称は誰のものでも無いので、自由に使って貰って良いそうです。ありそうやな・・・。
他にも色んな所で色んな動きがあるらしいので、来年もまた何が起こるか期待しています。
お弁当
ランチセッションじゃないとお弁当貰えないと思ってる人たちがいたようで、あぶれた人は外へ食べに行き、その結果
6Fの無料弁当、なんとしてもみなさんたべてくれ頼む！！！！！！！なんなら二つ三つくってもよいのでは！！！！ #yapcasia
— 鶉 (@uzulla) 2015, 8月 22との事なので
— 太鼓 (@taiko19xx) 2015, 8月 22
消化してきました。お弁当2個食べられるとか幸せです。
(ランチセッションに行きそびれたので尚更)
#yapcasia 弁当配布終了しました！！！！！、！
— 鶉 (@uzulla) 2015, 8月 22食べてるそばからどんどん無くなっていましたが、無事に無くなったようで安心しました。
その他
- LTが面白すぎて腹筋が死んだ
- 無限コーヒーは幸せ
- 相変わらずMBPの電源はギリギリだった
- ビックサイトは意外と遠い(仕方ない)
- 同人誌買えなかった・・・
という訳で
皆さんお疲れさまでした。楽しい2日間でした。
また同じような機会があれば、自分のためにも参加したいです。
(スタッフ側とか・・・)
壇上に立つような人になりたいなとも思える良い機会でしたので、そのモチベーションを持ち続けられたらなと思います。
