AnsibleSpecを複数環境プロビジョニングに対応させてOSSに初Contributeした
この度、AnsibleSpecにコントリビュートして「複数環境プロビジョニング」のユースケースで便利にテストを実行できるようにしました。
私がやろうとした時に目の前にあった前提
最初に、私がこの対応をするにあたって目の前にあった前提をお伝えしておきます。
プロビジョン完了時に合わせてインフラの状態をテストしておきたかった理由としては、こんな感じです。
- 本番・検証など多くの環境ができてくるとインフラテストがやりきれない
- インフラテストを自動化してインクリメンタルに作業を進めたい
- よりよいプラクティスを追求したいという想い
その他、下記が決めてあったことです。
Ansibleのディレクトリ構成ベストプラクティスを採用
TerraformやCloudFormationなどで環境群自動構築のアプローチを採用
- 環境がProduciton、Staging、develop、demo、などセットをたくさん作る事を想定
- Immutable Infrastructureを意識し環境を使い捨て・切り替えしていく
- プライベートIPアドレスは任意のアドレスが割り当てられている
- Ansibleのプロビジョンコードをコミットする時点ではhostsは予測不能
各環境には基本的にSSHしない
- 運用的なセキュリティ強度を高める為にSSHをしなくても済むようにしたい
- 必要なログ情報は全てログコレクタを使って転送
- 障害やアラートの検索はElasticsearchやCloudWatch logsなどで実施
- 必要なログ情報は全てログコレクタを使って転送
AnsibleとAnsiblespecの組み合わせを選択
「Ansibleのテスト事情」も参考にさせて頂き、結果的にAnsible標準テスト方法ではなく、Serverspecを使う事にしました。左記のエントリーでは好みの問題でAnsibleSpecは避けられていましたが、最近「Dynamic Inventory」に対応された事もあり、統合的に使いたかったことも相まって、私はAnsibleSpecを選びました。
話しが少しそれますが、「Ansibleのテスト事情」エントリーで下記が言及されていました。
また、serverspecをrole単位で実行できるansiblespecという拡張モジュールもあります。 こちらも使ってみましたが、テスト単位がrole単位というのが好みに合いませんでした。 構成管理ツールは上から下まで流してナンボだと思うので、playbook単位に行うべきだと思います。 プログラムでいえばユニットテスト用で扱い難く、severspecでインテグレーションテストをすべきという考え方です。
これが示す意味としてはtest all的なものがないということかなと。私もplaybook単位で実行できる方が便利だと感じたので、デフォルトのRakefileでallというrakeタスクを追加し、"rake all"または"rake serverspec:all"でプロビジョニング対象になったタスク全部を一括で流せる形にしました。
この修正は、まだ現時点ではRubygemsとしてはまだリリースされていませんが、一緒に取り込んでもらえました。きっと、次のバージョンに含まれる事になると思います。
パッチが必要になった機能
AnsibleSpecの幾つかの機能がまだ未実装で自前でパッチを当てる必要がありました。
- AnsibleSpecではHostsに対して複数のホストを指定されたPlaybookに対応していない
- AnsibleではgroupのChildren指定で依存関係を書けばgroup_varsも依存を辿って参照してくれるがAnsibleSpecでは未対応
この2点は複数環境プロビジョニングにとって重要な要素でしたのでパッチをあてることにしました。パッチもAnsibleSpecを追従していくのはきついし、後からわかった事なのですが、GitHubを見るとアイディア・要望としてchildrenの依存でgroup_varsを参照したいというのを幾つかみたので、思い切ってプルリクすることに決めました。
プルリクするために自分以外のInventoryやhostsファイルの書き方でも正常に動く必要があるので、AnsibleSpecライブラリ自体のテストコードを修正したり、新しくテストを追記したりしました。
実例
実際にはAWS CLIなどを使って命名規則や条件に従ってhostsのアドレスを取得し埋め込み、JSON文字列を生成する必要があります。また、実行時に環境変数に環境名を置き換えれるようなスクリプトにすれば、環境名は容易に変更する事ができますね！
dynamic_inventory.sh
#!/bin/bash
cat << EOS
{
"database-servers": {
"hosts": [
"10.0.0.4"
]
},
"application-servers": {
"hosts": [
"10.0.0.2",
"10.0.0.3"
]
},
"web-servers": {
"hosts": [
"10.0.0.1"
]
},
"staging-database-servers": {
"children": [
"database-servers"
]
},
"staging-application-servers": {
"children": [
"application-servers"
]
},
"staging-web-servers": {
"children": [
"web-servers"
]
},
"staging": {
"children": [
"staging-web-servers",
"staging-application-servers",
"staging-database-servers"
]
}
}
EOS
group_varsは環境やグループ（サーバー群）毎に設定ファイルが配置します。
- all
- 環境に左右されない全てのホストに設定したい内容を記述
- staging（productionやdevelopなど環境名）
- 環境ごとに切り替えたい内容を記述
- サーバー群に依存しない共通設定を書く事を想定
- confファイルを環境毎にansilbe templateとして切り替えたいなど
- staging-web-servers（環境名+グループ名）
- サーバー群単位で環境毎に切り替えたい内容を記述
- 最新バージョンを試す場合などのversion番号など
- web-servers（グループ名）
- サーバー群単位で環境に左右されない内容を記述
- mysqlのport番号など
$ls ./ .ansiblespec dynamic_inventory.sh* group_vars/ Rakefile roles/ site.yml spec/ $ls ./group_vars all production-application-servers application-servers production-database-servers database-servers production-web-servers develop staging develop-application-servers staging-application-servers develop-database-servers staging-database-servers develop-web-servers staging-web-servers production web-servers
playbookでは下記のような書き方をします。
インベントリファイルで依存関係を指定してあるので、ホスト毎にgroup_varsが参照されます。 例えば、web-serversが参照するgroup_varsは「all, staging, staging-web-servers, web-servers」です。
site.yml
- name: install-common-libs
hosts:
- web-servers
- database-servers
- application-servers
roles:
- common
- name: install-nginx
hosts:
- web-servers
roles:
- nginx
- name: install-java
hosts:
- application-servers
roles:
- java
- name: install-mysql
hosts:
- database-servers
roles:
- mysql
うれしかった・よかったこと
- そっこー返事くれて・コードをレビューしてくれテストケースの抜けが1つあったことを指摘してくれた
- あまり自信がなかったが快くマージしてもらえた
- AnsibleSpecが裏でどんな事をやっているかわかった
気になっていること
他の方はどんな風にやっているのか？
実は当記事が、来月に行われる Ansible Meetup in Tokyo 2016.06のLT発表予定のtakuya_onda_3さんによる「Ansibleとterraformで実現するタグベース複数環境プロビジョニング実例」とすごく内容かぶっている気がします。
残念ながら申し込みをしようとした時にはLTも応募枠いっぱいで、抽選にもはずれてしまったのでお話を聞く事はできませんが、どうやってテストをされているか興味があります！
変数値は共有すべきか？
オライリー出版の「Serverspec」という書籍があり、「5.4 サーバ構成管理ツール」の項で、このようにServerspec作者は述べられています。
また、Node Attributes を使ってそのままテストすると、もし Node Attributesを間違った値に書き換えてしまっていても、Serverspecではそれに気づくことはできません。Serverspecの目的の1つは、Chef レシピ等のインフラコードが正しく書かれているかテストすることです。したたがって、Node Attributesを利用してテストを行うと、このようなミスにきづくことができず、本来の目的を果たせなくなってしまいます。
TDDでいう先にテストコードを書いて、テスト失敗で気づくというプラクティスに似ているのかもと。変数値を変数値を共用してしまうとその気づきが失われ、意図しないヒューマンエラーで修正に洩れや間違いがあった場合、実際の環境で問題がおきてから気づくことは、この項を読んで色々と思考を巡らせるきっかけになりました。
今回このような仕組みをAnsible+AnsibleSpecで実現させてはみたものの、上記のようなケースもあり、完璧に自動化・不用意なミスを防げたとは言い切れないなと思っています。ペアワークのレビューである程度失敗は防げますが、そもそも完璧というものを求めてしまうのが過ちなのかもしれません。
私自身、なぜImmutable Infrastructureにするのかの深ぼり、担保したい事やどういう状況にもっていきたいことは何か、運用経験も加味しながら考えていく必要があると感じました。
最後に
今回はすごくいい経験になり楽しかった...
考える事は幾つかあるものの、導入してみて開発・テストのサイクルがすごくスムーズになりましたし、導入の敷居も低いこともあって、AnsibleSpecはお勧めだと感じました！ Serverspec自体を使ったことない人にもぜひ使ってみて頂ければと思います。
2015年のふりかえり
今年は思い越せばアクティブに動いた年でした。 2〜3年前の家庭の事で大変だった時期から状況がかわって、勉強会に参加できる時間がとれるようになったのが大きかったのかも。
コミュニティ活動
よこはまクラウド勉強会
夏ごろまでの前半はよこはまクラウド勉強会で地域コミュニティ活動をアクティブにしていました。 今思えば、積み重ねる事によって秋から冬にかけての後半にモチベーションがあがったのかもしれません。
イベント開催ページを確認したら、こんなにも開催したのか...
- 第四回 よこはまクラウド勉強会 「AWSで簡単にWordPressサイトを立ち上げてみよう！」
- 第五回 よこはまクラウド勉強会 「そろそろGitを触ってみたいと思っている方に向けて」
- 第六回 Dockerでらくらく開発・運用を体感しよう
- 第七回 BigQueryでサクッとログ解析してみよう！
- 第八回 Amazon EC2 Container Serviceでスケーラブルなコンテナ管理の世界
- 野毛倶楽部 クラウド時代のソフトウェア開発を考える
- 第九回 Mackerelを使ってサーバーのモニタリングをしてクラウド時代の運用を体感してみよう！
- 野毛倶楽部「いま、なぜドメイン駆動設計か 現状と展望」
- 第十回 AWS LambdaとAPI Gatewayでサーバレスなシステム構築に踏み出してみる
- 野毛倶楽部「Reactiveの夜」
よこはまクラウド勉強会は「ふつうのソフトウェアエンジニアを対象とした勉強会」なので、はじめてみよう系が多かったですね。
このうち私が発表者およびハンズオンの進行者として担当したのが
のふたつ。幾つか予定が重なって参加できなかったものもあったのが残念でした。
通常回とは別開催の「野毛倶楽部」。こちらは主催者の私たちが話しを聞いてみたいと思うネタを肴にゲストを呼んで、野毛で飲みながら話しを聞いたり質疑応答・実際の所どうなの？と、野毛という街で繰り広げました。 私が唯一参加できた岡本さんをゲストに迎えて開催された「Reactiveの夜」は熱かったです！
11月、12月は失速してしまったので来年活動を再開できればと思っています。
Yokohama.vim
秋に2回開催しました。久しぶりにお逢いできた方もいたり、はじめてお逢いできたかたも一緒に楽しい時間を過ごせました。これをきっかけに11月に開催されたVimConf2015でLT発表してみようという気になりました。VimConf2015では大勢の聴衆の前で発表するという久々の経験でしたが、Twitterで頂いたコメントや懇親会で感想を聞いたりお話しをさせてもらったりで、これでまたモチベーションがあがったので、時間がなかなかとれない中でも応募して発表を実行できたのはよかったです。
お仕事
AWS周りのことをやっていた中心に印象です。プロダクトのコードを書く機会がグッと減ってしまいましたが、Ansible周りのスクリプト書いたり、自動化にいそしんだりしていました。また、システムの全体的な構成や方式や仕組みを考えたりして、ステークホルダーがたくさんいるなかでプロダクションへ持っていくまでの難しさも体験しました。
色々と新しい出逢いもあって、Scala先駆者インタビューの企画のインパクトは大きかったです。人間的にも成長できそうで、来年やりたいことがたくさんできました。
会社のことにもパワーをかなり使いました。会社が過渡期を迎えているなかで、ビジョンや方向性を立てて実行していく事と、理想に近い組織形成までの道のりの険しさを感じました。人との関わりを通して、おかれている立場や状況が違えばものの見方が異なり、主観や人の気持ちってそれぞれ違ってくるというのを目の当たりにして、「組織ってむずいけど興味深いなぁ」と。
個人的な興味
GTD
このブログであまり触れてこなかったGTD。Active InboxとThingsを組み合わせて実践しました。 マインドスイープの実行と、タスクの粒度がまだ課題です。
色んな所からストリームで流れてくるTODOを纏めて実行していけるというところまでの形はつくれたので、来年は実用的なプラクティスを確立させてGTDをより進めていきたいです。
Tumblr
Tumblrにはまりました。というより、Reblogを空気のように... 自分の好みや思考がわかるようになってきて、心に残ったフレーズもありました。
フレーズって面白いですね。画像もそうですけどｗ
来年にむけて
今年は公私ともに「人との関わり」が中心でした。新しい出逢いがここ数年家庭の事情で外への活動が滞っていた気持ちやモチベーションに火をつけてくれたので、来年は新しいMacを手に入れて、影響を受けた事を自分の中で消化したり体感できるように、手を動かす時間の割合を増やしていければと思います。
楽しい事したい。
Skinny Framework Meetup Tokyo 2 に参加しました
池袋のサムライズムさんオフィスで開催されたSkinny Framework Meetup Tokyo 2 へ行ってきました。
オフィス前でエレベーター入り口がわからずグルグルと建物の周りを回ってしまいましたが、建物名と入居社名プレートを発見し無事到着する事ができました。
@seratchさん発表
Skinny Framework 2.0 アップデートに関して発表です。と思ったら、
＿人人人人人人人人人人人＿ ＞ 突然の さだまさし ＜ ￣ＹＹＹＹＹＹＹＹＹＹ人￣
どうやら、私は会場を完全に間違えてしまったようで、
きっとこの会場に来ている方を含めほとんどの方が動作させた事がないと思うのでデモします
と、そして唐突に日本語名でコンパイル。「エラーが出ても大丈夫。規定ブラウザが開きGoogleで曲名検索できます」「Youtubeで曲が開きます。あっ、今日はハズレの日ですね。」など豪快な技術力の無駄遣いっぷりを目の当たりにして、会場を沸かせました。きっと池袋界隈で瞬間的に気温があがったのはこの為ですね。
続いて、Skinny Framework 2.0 アップデートの話し。会場は間違っていなくホっとしました。
Skinny MicroとScalatraの違いや特徴などをはじめ、OSSの事情なども聞きました。あるOSSのメインメンテナがVMWareに転職したら、違う言語でのOSS活動がアクティブになり元々やっていた事の活動力が落ちてきた話しや、メンテナに名乗りをあげてForkした話しなどとても興味深かったです。時間軸で物事を考えた場合に、どんな人も24時間と使える時間は同じで、「アクティブになれる事」「時間の使い方」「ウェイトのかけ方」などを考えると私自身の事も見つめ直したくなりました。
2.0に関する活動はほとんど一人でやっていたとのことで、構想を形にしたうえで、ドキュメントを始めユーザの事を考えたケアまで行き届いているのには感心するばかりです。
Skinny Frameworkはライブラリ群は単体でも使えるという話しを聞いたので、部分的に使って学習や実用にも役立ててみたいと思いました。
@roundropさん発表
このmeetupに参加しようと思ったきっかけの一つとして、roundropさんが発表すると聞いたからでもありました。 実はroundropさんとは同僚で、発表の中で触れられていた「社内ナレッジ共有ツール」は、立ち上がりから社内に根ざしていくまでの変遷を見てきたので、こうやって存在が事例として世に公表された事に感慨深い物がありました。
初心者の心理を描写したこのフレーズはグっときました。
「Playのドキュメント見ると"we are reactive"とか書いてあって、そういうのあとでいいから、と」 #skinnyjp pic.twitter.com/oULTOPdkeH
— でくのぼうは静かに暮らしたい (@garbagetown) 2015, 12月 22資料にもでてきた
http://www.slideshare.net/RyujiYamashita/skinny-framework-scala/26
初心者からみる下記は
- はじめやすさ
- わかりやすさ
- 生産性
私も実体験で体感し、Skinny Framework 1.0 Introduction in Japaneseが充実したわかりやすい構成で、数名で行った「社内ナレッジ共有ツール」開発合宿を開催した時に参考にさせて頂き、Skinny Frameworkが始めての人にとって、とても役立った事を思い出しました。
また、「オープンソースにしないの？」という質問に「GoogleApps利用前提などの社内独自仕様などを解消した後にOSSで公開したいです」と回答されていたので、これからがとても楽しみです。
懇親会
サムライズムさんのご好意で当初予定していた懇親会費が無料になり飲み物とピザを振る舞って頂きました！*1 テーブルクロスがとてもかわいくて、これうちの会社にも欲しいなと思いました。 :-)
懇親会では @garbagetown さんから Play Framework の日本語ドキュメント訳をしているという話しを聞きました。
「している」というのがポイントで「ドキュメントが追いついていないんです」とのこと。その理由がすごくて、「私のMacbook Airがメモリ4GBで最新のPlayを使うとファンが唸りをあげて、まともにドキュメント書きながら動作確認できないんです。」と... 「新しいMacbookにしたらファンレスだから大丈夫だね」と周りから冗談を突っ込まれてましたが、「家庭内稟議の関係でまだ新マシンにできてない！」と言われており、すごくリアル感がありました。コミュニティを支えていらっしゃる方も実は意外と私たちとそれほど変わりない家庭環境なんだと親近感をもつ反面、そういう方にメモリが16GBのMacbookを寄贈するだけで、世の中での会社利用の敷居や導入コストが下がったりするので面白いんじゃないかと思います。
これからPlay Frameworkを導入を検討していて「日本語ドキュメント」を切望している会社さん、是非。きっと元とれます（笑）
他にも始めてましてのいろいろな方とお話させていただき楽しい時間を過ごす事ができました。
最後に
Scala界隈のコミュニティへ行ったのは初めてでしたが、楽しかったです。 どうもありがとうございました。
VimConf2015にLT発表者枠で参加してきました
先日開催されたVimConf2015にLT発表者枠で参加してきましたので熱の冷めないうちにレポを書きたいと思います。
全体を通して
朝から10時30から夕方の18時までという丸一の有料カンファレンス。 去年はお昼からだった覚えがあり長丁場だなと思っていたのですが、いざ参加してみるとあっという間に時間は過ぎました。
当日の一つ一つのセッションについての様子は他の方が様子を書いてくださっているのでそちらに譲り（Togetterまとめは現時点で未作成だったので作成しました。）個人的な感想を中心に！
VimConf2015まとめ
感想
- VimConf2015のサイトが素敵だった
- kaoriyaさんの発表でマシントラブルで資料なしで決行されたのすごい
- GoogleCodeが閉鎖される期限が決められている中でできること
- vimアカウントの委譲の話しなど「前提で無理」と捕われず最善の為に何ができるかという考え方や動き方など着目して話されている視点がとても興味深かった
- Linda_ppさんのreact.jsを使ったBrowserへのVim埋め込みのインパクトでかかった
- 今後WYSIWYGエディタの代替えで使えるようになったらいいのになぁ
- 日本語さえ使えれば...
- みなさん「ただの...ですから」と謙遜力が半端なかった
- 茶番も含め面白かったです！
- すごく発表者自身が楽しんでいる感じがしました
- derisさんの発表を見て仕込みに地味に時間がかかっただろうなぁと感心
- その瞬間にでた最後のJobsを真似たフレーズ
- 懇親会で「実は発音もyoutubeみて素振りした。でも想定よりうまくできなかった。」と言っていたけど満足そうな顔してたのが印象的だった
- yoshiko_pgさんの発表自分の発表前で集中して見れなかったけどフロントエンドでの視点面白かった
- 帰り際にujihisaさんに「来年のVimConfにあわせて日本に来るのでその時にYokohama.vimが開催してもらえれば参加したい」と声をかけて言ってもらえたのがうれしかった。
- 懇親会であえてほとんどしゃべったことない人に声をかけてみたのですが、シャイ力を発揮したのと逆にしゃべろうとしてしまい自分の事ばかり話しすぎた感もあり、帰ってから少しヘコんだ。
- 最近導入したchoosewin作者のt9mdさんとお話したのにお礼をいいそびれた
- 名前と顔とプラグイン名の一致がしきれていなくて多分他にも多数いたはずなので次回の時にはお話しやご挨拶したい
- 運営の方々の配慮が行き届いて素晴らしかった。
- 全体をとおしてすごく楽しかった。これにつきる。
私自身の発表について
私のスケジュールで大きな所用2つと重なってしまっていまい参加を諦めてかけていた所、2つの所用がずれたのでキャンセル待ちということもあってLT枠で申し込みました。
10分ってあっという間ですね。VimConfということで少し緊張しタイマーを見ながら最後駆け足になっていましたがなんとか残り時間3秒あたりで発表を終えることができ、ほっとしました。
自分が大事にしてきたことや楽しむ事への想いやモチベーションが伝わっていたら幸いです。
自身の発表に関するツイート
今後の自分のためにTogetterでまとめてみました。 ツイートを見ると良かったと言ってもらえたので素直にうれしかったです。
最後に
発表者として参加するカンファレンスは久々でとても緊張してしまいましたが、発表者としてしゃべってみるとフィードバックや得る事も多くて結果的にやってとてもよかったです！
会場を提供してくださったmixiさんどうもありがとうございました。「福利厚生がすごいので興味がある人は聞いてください」と会場説明の時のアナウンスで聞いたのですが聞けずじまいで、どんなものがあるんだろうと単純な興味で聞けなかったのだけが心残りです。
また来年も参加したいと思います！みなさんお疲れさまでした！！
@haya14busaさんを基調講演で招き Yokohama.vim.osaka? #7を開催しました
今日はYokohama.vim.osaka? #7を開催しました。
Osaka.vim #5はkyotoで行われたらしいので、Osaka在住の今Vim界隈で最も熱いと話題の@haya14busaさんが東京へインターンに来るタイミングで基調講演をお願いして横浜でやったら面白いんじゃない？という軽いノリで前回の懇親会で話題にしていたら、その場で開催が決まったというのが今回開催の経緯です。
という感じで、haya14busaさん駆動で行いました。今回は発表セッション中心に1個ワークショップをひとつやりました。
また、発表セッション時には同日開催だったOsaka.vimの会場とappear.inで繋ぎました。突然の申し出にかかわらず一緒にできたのはうれしかったです。あまりコミュニケーションはできず申し訳なかったのですが、ありがとうございました。*1
アイスブレイク
今回も「私のVimキーワードはなんだ？」をやったのですが、場をほぐすのに盛り上がった気もします。そんなに難しくないキーワードでもハマるとなかなか抜け出せない所と、他の人のキーワードが見えているというのは面白いですね。
基調講演
@haya14busaさん
Vimと関わってhaya14busaさんがどういう風に影響を受けてきたのかという話しを聞きました。 プログラミング歴3年で、現在ははてなインターンやG社のインターンに参加されるまでに至った経緯はVim関係なくすごいと思いました。
技術力は意外と必要ない 初心者でも案外デキる 小さいことからだってよい 誰かに助けてもらったり 誰かを助けたりできると それはとっても最高っぽい
こういう事を言っていました。 活動量のパワーで押し切ったとのことでですが、インプットとアウトプットが伴うとすごい事になるんだということを改めて実感しました。
Vimはインタラクティブなソフトウェアだから目に見えて面白い機能を簡単に実装できる、という意味でいいなぁ。JSがよくそういう理由でプログラミング入門と言われるけど、これからはVim scriptでは？ #yokohamavim
— Takayuki Tsukitani (@tsukkee) October 24, 2015インプットというのが「人からの助言や助けを通じて、IssueやプルリクについてもVimで学べた。」ということなので、作ったものが動いて役に立った・人に使ってもらった以上の経験があったというのは想像できます。さすが基調講演、感極まりますね。
最後にこんな質問も
「なんでそもそもVimを触ろうと思ったんですか？」「単にかっこいいと思ったから」 #yokohamavim
— guyon (@gu4) 2015, 10月 24発表セッション
@basyura さん
VimExcelについて
これは、ExcelのマクロでVim的な操作ができるというもの。 会場のみなさんはExcelを使う人は多くなかったのですが、
仕様書を書く時便利
という所々でいれる@basyuraさんのフレーズに会場から、突っ込みや笑いが入ります。
デモでは地味に便利という機能を披露してくれました。そして、最後にtweet.vimに関して質問やリクエストがあると「プルリクエストお待ちしております！」と笑ってかえすあたり和やかでよかったです。プルリクエストの壁は高くないよという雰囲気がでてますね！
@yasuharu519 さん
haya14busaさんが発表者として参加されると聞いて惹かれて参加を決めたとの事。 Codic API を使ったプラグインで変数名を決めてくれるというプラグインを作った話しや、自分がPluginを作るにあたって感じた事を紹介してくださいました。
「help読むといいよ」と言っており、共通した鉄板的なベストプラクティスになってきましたね。
@Linda_ppさん
「NeoVimでプロセス間通信をMessagePack-RPCで書くことができ、調査して今わかった事」という資料なしの飛び込みLT。 Vimで外部プロセスをしていたところを、MessagePack-RPCで書く事ができることになったのはでかく、マルチプラットホームでNeoVim + Electronを使ったGUIアプリを作ることを模索しているそう。
Node.jsでやり取りするデモをみせていただき、未来を感じました。リモートペアプロも夢じゃなく面白かったです。
ワークショップ
以前に会社でやったプチワークショップをYokohama.vim向けにアレンジしてみました。
問題の質問が「何パーセント」かをあてるというもの。間違った差分が多いほど持ち点から減らすことになり、持ち点を競うゲームです。
前半5問は私からの問題で、後半はチーム毎に出し合ってもらい「Vimのアイコン中で”Vim”という文字が占める領域の割合は何%？」というようなものもでて、かなり熾烈を極めました。最終的にはかなり真剣に悩みつつもをかなり盛り上がって楽しかったです。
リモート発表＆懇親会
@kamichiduさん
@kamichiduさんから夕方くらいに「今起きた」と一報がはいり、2時間ほど移動にかかるので今から行くのは難しいとのこと。
こんな感じでやり取りはスムーズにすすんで、懇親会内でリモート発表実現に。
元々の発表は「クラウド破産」の話しをしようとしていたとの事でしたが、リモート発表では「libcall入門」という話しを聞きました。 Vim関数はcallはmicrosecくらいかかって遅いよということで、libcallを使ったらどうなるか、どうやって実現するかということを話してくださいました！
懇親会でお酒を飲みながら発表を聞くというのはこれはこれで面白かったです！対面でお逢いしたらぜひご挨拶しておれいを言いたいです :-)
懇親会
会場でビアバッシュしました。今回も近くのショッピング施設でテイクアウトしてわいわいと。 たくさんの方の参加（参加者全員）ありがとうございました！今回は寿司やチキンやカレーやナン加えて、チーズナンも買ってもりもり食べました。 Vimネタを肴に色々と話しをして、楽しい時間をすごせました。個人的には数年ぶりお逢いした @tsukkeeさんと身の上話をしたり「こういう場の提供をできるのはすごいことだよ」と言ってもらえたりして、純粋にうれしかったです。
自分が楽しくなる事を前提に毎回やることを考えていますが、結果的に参加してくださるみなさんも楽しめたと思って帰ってもらえたら嬉しい限りで、また足を運んでもらえるというのが、続けていけるモチベーションになります。参加してくださる皆さんありがとうございます。
来年くらいになると思いますが、またそう遠くないうちに開催したいと思います！
最後に
懇親会後のモクモクタイム。
それぞれが各々コード書いたり、私はこのブログエントリーを書いていました！
*1:ノリだけでOsakaの名前も勝手に使わせてもらってしまったり・・・
JDK9にReactive StreamsがJSR前のJEPの状態だがDoug Leaさん手腕で導入されるのか？
先日開催された野毛倶楽部「Reavtiveの夜」で話題になった、Reactive StreamsがGithubで仕様を決めてすごいという話をご紹介しましたが、もう少し当日あった話を深掘りしてご紹介したいと思います。
まず、Reactive Streamsについて簡単に言う下記の問題に対する解決方法の一つの仕様です。
Pub/Subを利用するときにSub側のノード数やトラフィックを監視して調整するのはキツイので、Sub側がバッファの余裕によってPub側にメッセージリクエストをしてメッセージをもらうという仕組みです。
詳細は岡本さんのブログや発表エントリーを参考にして頂くとよくわかります。
スライドをベース（22ページあたりからがReactive Streamsの話）に当日お話を聞いたのですが、仕様策定には
- Typesafe
- NETFLIX
- Pivotal
- Redhat
などのベンダーが関わっており、ベンダーだけでなく個人で関っている方もいます。 Javaを使っていてこの方の功績にあやかっていない人はいないと思うのですが、JSR166を主導しjava.util.concurrentを導入までリードした「Doug Lea」さんです。
彼が、JDK9でReactive Streamsをサポートできるように猛烈な勢いで進めているそうです。
JEP draft: Concurrency Updates for JDK 9
上記がJSRへ一定のプロセスを踏んで昇格する前のJEPです。岡本さんの話によるとDong Leaさんは3ヶ月でこのJEPを完了させようとしているとのこと。目標は2015年11月。もう来月の話ですね。記憶が曖昧ですが、すでに実装も進んでいて存在すると言っていたような。
当日も「2日前にも更新されてますねー」というような現状を見てみたり、岡本さんからJEPに関するディスカッションやり取りや経緯の話を聞いて勢いを感じました。
本当にJDK9に入っても不思議じゃありませんね。岡本さんが「ランタイムを制するものがReactiveを制する」と言っていたように、JDK9に入ったらReactive Streamsに関わる運用要素の全て賄えるというわけではなく、それによって普及が加速しライブラリやサービスやプラットホームなどの大きめの粒度でイケているランタイムが出揃い、世界ユーザーのプロダクション導入が実績が出揃ってきて、デファクトの流れになるんじゃないでしょうか。
この波はすぐ先ではなく、もう少し先になるかもしれません。 また、JavaだけでなくScalaの波もあるので何がどう主流で採用されていくのかは「こうなのかなー」という個人的な想いはあっても読めません。
当日メモを取っていたわけではなく間違っている事を書いている可能性もあるので、指摘や補足をもらえると嬉しいです！
他にも面白かった話題があったので、思い出せれば別エントリーでご紹介できればと思います。
岡本さんを招いて野毛倶楽部「Reactiveの夜」を開催しました
よこはまクラウド勉強会というコミュニティにはふたつの顔があり、昼の部と夜の部というのがあります。
最近は各月で
- 昼から始まる「ふつうの人たちによるふつうのエンジニアに向けた」勉強会
- 夜からはじまりこの人の話を聞いて見たいとテーマにあった人を招いてディープな話題を繰り広げる
という毛色が少し違う感じで2つの側面で主催者も楽しみにながらやっています。
そして、今日は下記イベント（夜の部）を開催しました。
「Reactive」の現状と技術的な方向性についてゆるふわで語り明かす
というコンセプトで岡本さんを招いてスライドを使い発表形式スタイルで座談も交えながら、Reactiveを軸にお話を聞いたり近い未来の話や動向や現状とのすり合わせなど、過去最大級の盛り上がりであっという間の4時間を過ごしました。
キーワードとスライド発表の様子を中心に今日のネタを紹介します。
Photos:
まずはReactiveという言葉が先行している所もあるので整理してから
リアクティブプログラミングを行う為のライブラリのひとつ。Javaで実装されています。 値を変更したらデータフローとしてメッセージパッシングで値がこういう風に変更されるよという。基礎的なこと。
このあたりから徐々に深い話しに入っていきます
会場のボルテージも高まります
近い将来の話や岡本さんが考える流れをいろいろとしていただき
Reactiveでコンポーネント化されている事により、データフローを表現する実装コードは一つでもバックで実行エンジンを切り替えて実行する事が可能だという実例をご紹介いただきました。
そして、このあたりに岡本さんからの本日の格言のひとつがでて「ランタイムを制するものがReactiveを制する」というフレーズ。 ランタイムがどれだけ重要な役割を果たしているのかという話。
Pub/Subでよくぶちあたる問題点とリソースを最大限に活かす事。ブローカーで全体を把握するという発想が引き起こす事。 Publisher側で送りすぎるとsubscriber側パンクするし、subscriber側のリソース確保しまくってメッセージバッファ領域を広げまくっておくとリソースもったいないよねってなる。
システムが破綻しない事が大事。Publisherに任せる事によって実現できるよね。Back-Pressureというキーワードはこの後もちょくちょくでてきました。
分散の話しからNetflix Hystrixに話題が広がって。本日の話しの中心のひとつとなりました。 ちなみにキャラクターは「ハリネズミ」だそうです。
マイクロサービスの視点で非同期処理という肴に、野毛の肴が相まって盛り上がり。 Scalaやモナディックプログラミングなど話しは広がりまくりです。 長時間戻ってこない場合の時やリトライのしくみ、Finagleのはなしなどキーワードは多すぎで紹介し切れないくらいありました。
話しの途中でこんなエントリー記事を紹介していただいたりも。
またまた、資料を使いながら新しい発表の肴に。
Reactiveマニフェストのあたりのはなし。用語が参考になったり、「このあたりについては〜？」みたいな気になるポイントについて質疑があった時に「実はReactiveマニフェストでも言及がありまして」というやりとも何度かありました。
私自身はアジャイルマニフェスト的なところや響きでのわかりやすさのマーケティング要素の面も気になっていましたが、今日話しを聞いてReactiveマニフェストに好感を持ちました。
Reactiveなんちゃらおおいですよね。名前があるってべんり。違いやどういう背景でこの呼び名がでてきたかというところまでお話してくださったので、わかりやすかったです。すごく説明上手で岡本さんすごいと心の中で感心しまくっていました。
とても分かりやすい図
Reactive Systemについてどんどん言及。従来の3層モデルとのちがいも。 GitHub上で仕様策定したというのはインパクト大きかった。IETFやRFCなどのように標準化するプロセスや決め方などをあえてとらず、こういう形で実現できたという事はすごいことでは。
三崎マグロが推しの居酒屋の個室を借りてプロジェクターを持ち込んでいるだけで簡素、裏に見えているのはホッピー！！ 10人未満がひとつの大きなテーブルですごく近い距離感で質問ができる空間でやってます。
reliableの話題からAeron。キーワードに結びつくフレームワークの紹介をその場でアクセスしながら話しました。
非同期と結果整合性の話しから、分散合意やパクソスやモノイドやCRDTなどがキーワードに。 委譲を行った場合にどうするといいのか。どういうことを考えなければいけないのかというわりと現場であるリアリティ度が高い話しをしました。
Scalaの話しをしていてClojureの話しになってDatomicにいきついたのか？どの流れでこの話しになったのか忘れてしまいました。
Clojureの作者が作ったデータベースDatomicが凄い
既に3回岡本さんのReactiveの発表を聞いている参加者の一人である田中さんがブログで言及していた「CRUD is Dead」について話題が及びます。データの扱いについてupdateではなくappendすることでの違いなど。Amazon Auroraの中の作りとRDBのはなし。アーキテクチャ選択とデータ量が増える事によりリソースコストが増大しユーザが負担するコストとのトレードオフの話しなどもありました。
tanakakoichi9230.hatenablog.com
こんな話題や
あの人は過去にこんな事やっていたんですねー。って話したり。
Playの話しからAkkaまで、ほぼ終盤でこの話題が登場。
入り口から出口まで。ストリームというのは今後ひとつのキーワードとなっていくという実感。
JDBCのスレッドプールあたりのわだいを混ぜつつ
InfoQでこんな事をいっていたよね。Reactiveマニフェスト2.0。イベント駆動からメッセージ駆動に言い方かえてたり。
ReactiveSocket。「asynchronous, binary boundary」について。Netflixは今日たくさんでてきたキーワードでした。エコシステムについても話題になりました。NetflixはRFCを狙わなくてもデファクトであれば自身サービスで困る事はないのでは。むしろデファクトでなくてもGoogleと同じで自身で必要なものを作っていけるし、そうしているのではと。
最後に
写真を並べたらこんなにあったのかーと改めてReactiveをキーに色々はなししたなーと実感。 ご紹介した写真以外にも幾つか話題が合ったのですが写真を撮って場面もあったり、三崎マグロに熱中していることもありました！えっ！？
岡本さんにはテリトリーの広さと見識の深さなど感心するばかりで、色々な質問もできて今日はたのしく過ごせました。 快く引き受けていただき本当にありがとうございました。
次回のよこはまクラウド勉強会の野毛倶楽部（平日の夜開催の部）では違うテーマでもこんな感じでふるゆわでやっていきたいと思いますので、興味のある方は是非ご参加ください！！キャパも小さくあまりおおっぴらに宣伝していませんが、告知ページで募集していきます。
本当にさいごは連投の写真を締めくくる写真締めで。
*1:両方とも懇親会を野毛という街飲み屋に繰り出し普段感じている事をざっくばらんに懇親をしています
