開発環境を Mac から EC2 に移行してみた話

この記事は 裏freee developers Advent Calendar 2018 の6日目です。 freeeでは会計の開発をしている傍ら、開発環境の改善をいろいろやっている、ソフトウェアエンジニアの @kompiro と申します。

数年放置していたこのブログですが、Advent Calendarも裏モードということで、ゆるゆるやっていきましょう。

さて、どこかで見た感じのタイトルですが、TechRachoさんのAdventCalendarにて Web開発環境をMacBook ProからWindows機に移行してみた話という記事がありました。開発環境としてのMacは、徐々に離れられているのでしょうか？栄枯盛衰ですね。

前職ではJavaのデスクトップアプリケーションを開発していました。サポートしているOSはWindows、MacだけでなくLinuxも・・・、ということだったので普段の開発環境はLinuxでした。OSに依存しない形でプラグインをパッケージングしておいたEclipseを準備しておき、僕はLinux上にそれをインストールし、その上で開発をしていました。(他のメンバーはMacやWindowsにパッケージングしておいたEclipseを使っていました。)

現職は Ruby on Rails ベースのアプリケーションを開発しています。RubyMine上に開発環境を構築し、開発していました。3年前の10月に転職したので、ちょうど11月にRubyMineのライセンスが切れます。なにか他によい環境はないものか、思案してみてEC2に開発環境を移行してみました。

Q. なぜMacからEC2に移行するのか？

はやい・やすい・うまい からです。

（お客様に業務システムのクラウド化を推進する手前、ぼくらの開発環境が各々のマシンにある、というのもなんだかなぁ、と思ったりもします。）

はやい

freeeでは開発メンバー情報を管理するデータベースがあり、そこに公開鍵を登録済みであればすぐに開発用のインスタンスが立ち上がるようになっています。

今はまだできていませんが、開発用のAMIイメージを用意すれば少なくとも半日かかっていた開発環境の構築が1時間以内に終わるようになるでしょう。

やすい

開発で利用しているインスタンスタイプは t3.large の環境です。これは、Macbook Pro に立ててる docker engine に設定しているものと同等のインスタンスサイズです。このサイズだと

0.0832 USD/ h * 8h * 20 day * ≒ 13 USD / month ≒ 1500円 / month

くらいに収まります。アプリエンジニアなのでほとんどAWS触ったことがなかったので研究中ですが、 AWS Instance Scheduler というので起動・停止を制御できるみたいです。

うまい

AWSの環境にログインして操作するので、AWS_ACCESS_KEY等の払い出しは不要です。また、実行環境としてLinuxを選べるのでDockerを実行する場合のオーバーヘッドはほぼありません。

そして仮にリソースが足らないときはより大きなインスタンスに切り替えることができたり、DBを介さない処理用のサービスであればチームメンバーで共有できたり、ちょっとしたサービスであればインスタンスを立ち上げなくてもサーバレスに開発ができたり、というAWSの利点をフルに使うことができます。

昨年のre:Invent で AWS Cloud9 がリリースされ、開発環境としての EC2 に俄然興味が出てきました。今年は1年を通して開発リソースのコンテナ化と開発環境のクラウド化を進めてきました。その経験をこのAdventCalendarで共有します。

開発環境のクラウド化へと向かう道のり

表freee developers Advent Calendarで @terashi が取り上げているとおり、freeeでもマイクロサービス化を推進しています。連携するマイクロサービスの数がかなり増え、起動するのも大変になってきたので、実行にはコンテナを使うようになりました。連携サービスを Docker イメージにしておくことで、特定のバージョンをいつでも同じ環境で起動させることができます。

こうして出来上がったDockerイメージをMacで実行するには Docker for Mac を入れればOKです。Mac上に開発環境を立ち上げるのであれば Docker for Mac を入れていますが、人によってはDocker for Mac が不安定だ、という意見がありました。大抵は Docker for Mac に与えるリソースが少なすぎだったり、Docker for Macに向いていない使い方をしていたりします。

Docker for Mac は macOS 上で Docker Engine が動くのではなく、 HyperKit というハイパーバイザー上で動作する、Linuxの上で動作します。 このHyperKitに与えるCPUやメモリが少なすぎたり、大量にホスト側のファイルを参照するような設定をすれば、HyperKitで動かしているコンテナは不安定になります。

Q: Docker for Mac の Docker Engineは 本当に Linux Kernel 上で動いているのか？

試しに Docker for Mac が起動する Mac 上で下記のように screen を叩いてみましょう。

$ screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty

すると

linuxkit-025000000001:~#

というような文字列が表示されます。ここでおもむろに CTRL+D を叩いてみると

Welcome to LinuxKit

                        ##         .
                  ## ## ##        ==
               ## ## ## ## ##    ===
           /"""""""""""""""""___/ ===
          {                       /  ===-
           ______ O           __/
                          __/
              ___________/

linuxkit-025000000001 login: root (automatic login)

Welcome to LinuxKit!

NOTE: This system is namespaced.
The namespace you are currently in may not be the root.
login[2738]: root login on 'ttyS0'
linuxkit-025000000001:~

ハロー、クジラさん、という感じで LinuxKit でビルドされたLinux imageのシリアルコンソールに接続できます。 終了は CTRL-A CTRL-K yes の順に叩きましょう。

Mac 上で docker コマンドを叩いたらこのLinux上で動いている docker engine に接続し、コンテナを起動します。

開発環境のコンテナ化をしたいのであれば、Macでのファイル編集を諦めなければならなかった

話を戻すと、大量にホスト側のファイルを参照する使い方の代表例は、開発環境のコンテナ化です。

freeeではサービスごとに開発チームがあります。それぞれの開発チームが独立した進化をするため、yarnなどのバージョンが開発チームごとに異なることがありました。普段の開発には問題ありません。しかし、隣のチームとの連携部分を開発するときに、よく支障が出ていました。

コンテナは独立した環境なので、コンテナの中に開発環境を作ることができればこの問題は起きません。一時期試していましたが結局のところMacのファイルシステムをマウントするのは重すぎて断念しました。

コンテナの起動時に、Macのファイルシステムをマウントしたとしましょう。すると、Mac上のファイル変更を検知したら先述したLinux側にファイルを転送します。このファイルの変更検知とファイル転送が結構な負荷をかけます。

開発環境自体をコンテナ化するにあたり、docker-sync も試しました。これもMac側のファイルシステムに大量のファイルがあるパスでは期待した高速化はできませんでした。docker-syncはあくまでDockerコンテナ内でのファイル操作を高速化するためのツールであり、Macから Linux への転送を高速化するものではありませんでした。

もし開発環境自体をコンテナ化するのであれば、ファイル転送はしないほうがいい。ということがキッカケで、僕は開発環境をLinuxベースに移行することを検討し始めました。(話が長くて申し訳ない。やっと本題に来たぞ。)

まずは Docker for Mac を引き続き使うつもりで、Linux上でファイル編集をする手段を考えてみたところ、1年前は AWS Cloud9 が出たての頃でした。買収される前のCloud9の開発用のSDKがGitHubで公開されていたのでそれを使ってみたら普通に編集ができます。 これはあくまでCloud9の拡張を開発するためのものであって、普段の開発用途で使うものではありません。しかし、発想としてこれはよさそう、と思い、 AWS Cloud9 上に開発環境を構築してみたら思いの外普通に使えそうでした。

ただ、今普段使いしているのは AWS Cloud9 ではなく、ただの tmux & vim のCUI環境です。ブラウザIDEに思いを馳せてないわけじゃないんだよ。

Q, なぜAWS Cloud9(ブラウザIDE)ではないのか？

A. 東京リージョンに来てないから

え？東京リージョン来てないん・・？

... というだけじゃないんだ。

ブラウザIDEへの希望と現実

ブラウザIDEへの希望

  • どんな環境でも開発できる、たとえ iPad でもね
  • AWSにログインできればどこでも開発できる、今朝腰を痛めたから今日は家のマシンでリモート開発してもいいよね
  • 実際に実行されるコードは EC2 インスタンスだから軽い！
  • いつでも最新の環境が使える！コード補完とか名前の変更とかコードジャンプとかサクサクやろ

ブラウザIDEの現実

  • AWS Cloud9 はサードパーティクッキーがないと動かないんだ。だからそもそも iPad Pro で開発できない。ごめんね。
  • 会社のコードをいろんなところで触れたらヤバイでしょ。接続できる方法は限定しないと
  • そもそもブラウザで動いているから、ブラウザのショートカットが優先されることも多々あるんだ。例えばターミナルの上で単語を消そうと思って <CTRL+W> とか押すでしょ。するとタブごと消えるんだ・・・。

  • 例えばファイルツリーがあるでしょ？あれを描画するにはどうやってると思う？ちょっと考えてみよう

    1. ブラウザ側でツリーを開く
    2. サーバーにリクエストが飛ぶ
    3. サーバー側で指定されたツリーを ls する
    4. レスポンスを返す

    この仕組みをブラウザIDEで実現するのは結構難しい。ちょっと考えただけでもこんな課題がある。

    • 特定のフォルダの配下にいくつファイルおけるんだっけ…？
    • ファイルがたくさんある場合はブラウザにキャッシュさせればいいんじゃね？でもサーバー上のファイル名が変わってたらどう扱うんだろう。

    むずかしい。

AWS Cloud9はそんな微妙なの？

f:id:kompiro:20181205231728p:plain

微妙ではないけど、既存のプロジェクトの開発環境に使うのには向いてなさそうに思いました。なぜなら、ここ1年くらいはAWSとの統合に力を入れてたようで、基本的なIDEとしての編集機能に進化は見られませんでした。もともとあった編集環境の共有や編集履歴のトレースは強力です。AWSのアカウントで編集環境を共有できるし、IAMで権限も制限できるし、LambdaだけでなくCodeBuild等とも連携できるようになりました。でも Language Server Protocol を使ったリファクタリングや コードハイライト、プラグインみたいなIDEとしての基本機能のアップデートはあまりなかったようです。反面、AWS Lambdaのコード編集画面は Cloud9 になっててびっくりしますが。

注目のブラウザIDE: theia

f:id:kompiro:20181205231622p:plain

他にも注目しているブラウザIDEにtheia ideがあります。

これはVSCodeをベースにしているのでVSCodeの拡張をそのまま使え、Language Server Protocol にも対応しているらしいです。また、GitHubのリポジトリから開発環境を立ち上げられるGitPodのベースになっているので、試してみたい方はtheia ide を開き、「try theia in theia」ボタンを押してみましょう。しばらくするとtheiaの開発環境がtheia上に開きます。

theia の面白いところはVSCodeベースというだけでなく、開発を始めるときのセットアップも自動で行えたり、パッケージング方式にElectronがあるのでデスクトップアプリにできたり、というあたりです。冒頭にちょろっと「独自にパッケージしたEclipseを使ってた」と書きましたが、theiaだとVSCodeで似たようなことができそうです。

このIDEもファイルツリーが遅かったりブラウザのショートカットに殺られるという点があり、またユーザー認証は手付かずという課題はありますが、まだ0.3です。長い目で見ていきます。

Eclipse Che はどうなの？

f:id:kompiro:20181205231529p:plain
Eclipse Che

結構いい感じですよね。Eclipse Che。 正直今回はあんまり触ってないので、dockerベースで環境が立ち上がるのはよいな、としか今は言えない。このブログがEclipse扱ってたブログだったので、思い出した、という記録は残したい。

ブラウザIDEへの移行を踏まえたCUI環境の構築

とはいえ、Play with Dockerというブラウザ上でdockerに慣れるための環境があります。こいつはブラウザのショートカット以外、なんの違和感もなく使うことができます。それを実現しているのはxterm.jsです。ブラウザの上でターミナルを動かすくらいは全く苦にならない時代になりました。

Chrome AppにGoogle謹製Secure Shell App というChrome Appがあります。ブラウザでSSHするのはセキュリティの問題が残るので使っていませんが、CUIで開発できる身になればブラウザで開発できるようになるのは近い未来にできるようになりそうです。

ブラウザで開発できるようになればMacだWindowsだなんだ言うことは減っていくでしょう。もっと軽くて薄いなにがしを使えるようになるでしょう。こちとら腰を痛めてるんだ、もうちょっと(物理的に)軽くなってよ、開発環境。

かくして、Eclipse改めRubyMineおじさんは CUI に再入門し、tmux & vimってこんな便利やったんや…、とかLanguage Server Protocolをおっかけているのです。

こういう開発環境や、エンジニアの開発生産性に興味があるエンジニアのみなさま、来週イベントをやるので遊びにきてくださいな。最初書くつもりだった生産性を高めるredash活用術の話をします。

明日の裏freee developers Advent Calendarはぼくらエンジニアチームを支えてくれてる yoyo さんです。

Coderetreat in KIT を開催しました

2014/05/31に金沢工業大学でCoderetreatを開催しました。

みんなで

今回は大学ということもあり、学生さんが多いと見込み、いつものCoderetreatとは異なる形で開催しました。 テーマは「楽しくプログラミング！」

想定していた以上に1,2年生の学生さんが多く、大丈夫か？？と思ってたんですが、みなさん優秀でした。プログラミングの本を持ち込んでる子も多く、言語を学び、学んだことを生かしつつ次に行けたんじゃないでしょうか。学生さん、社会人の別け隔てなくプログラミング。みなさんほんとうに楽しそうに過ごせてよかったです。

当日の導入資料

工夫したこと

ライフゲーム以外の課題を用意した

ライフゲームって相当奥深い課題なので、あれはとてもいい課題なのだけど、取っ掛かりが相当大変で、プログラミングと言うのは難しいものだ、と思われてしまうと悲しい。ということで、初心者でも45分で解ける課題としてうるう年の判定を準備しました。また、ライフゲームだと、ルール自体は単純ですが、UIを作る部分が大変に思われがちです。ということで、実際はライフゲームよりも難しいボーリングスコア計算をチャレンジ課題として用意しました。

1年生同士がペアを組んだ時、どうにも解けなさそうであれば、自分が後ろに入り、デモをしてみたりアドバイスをしてみたりしていました。

ペアプログラミングのやり方を軽く解説

プログラミングに不慣れなペアで課題に取り組めばなんとかなるもの、という感じてほしい。ということで、いつもであれば「良いコードとはどんなコードか？」に重点を置いて始めるところを、「ペアプログラミングとはどんな感じでやるものか？」を簡単に紹介し、最初のセッションはペアプロになれるために「うるう年判定」をすべてのペアにやってもらいました。

ペアプロは3人でもできますよ、と言ったところ、3人で2ペア作り、将棋の二人指しみたいな強者もいましたが、最初のセッションがあったお陰でスムーズにプログラミングをやり始められたように思えました。

6セッションのところを5セッションにし、クロージングを最後に書いたコードをふりかえるセッションに。

一日中ペアプログラミングでコードを書き続けるのはなかなかハード。と言うことで、4セッション目以降、だらだらし始めたので、休憩を長めにとったり、6セッション目を諦めて、5セッション目を60分にして、クロージングにみんなにどういうコードを書いたのか、共有する時間にしてみました。

たぶん大学1年生の方たちは、人前で発表する経験はそんなになかったんじゃないかな。そういうことも含め、いい経験になったのではないでしょうか。

発表の様子

クロージングセッションの発表

セッションごとに書いてもらった付箋もこんなに

セッション毎に書いてもらった付箋

開催してみて感じたことをKPT

Keep

  • 大学でのCoderetreat
  • あまり捗っていないペアの間に入り、ファシリテーション。
  • 軽く「オブジェクト指向とは、コードを分かりやすくするため、仕事を役割ごとに分離したり、概念を表現できるようにしたもの」と説明してみる。
  • 「犬」や「猫」に「鳴く()」なんてメソッドを定義したり、共通の親に「動物」って定義したりするなんていうオブジェクト指向をいずれ訳の分からない役立たずにしてしまう考え方は一切説明しない。
  • TDDやユニットテストを知らないペアのところでおもむろにやり始める。(ドヤァ)
  • ただドヤァはしたくてしてるわけではない。なんかわけのわからんことをデモされてるぞ？と、若人の好奇心をくすぐることが目的。目を輝かせていた方もいたようで、これはうまく行ったと思う。
  • ただし、「TDD」や「ユニットテスト」という単語は使わずに。昼食や終了後、参加者間での情報交換で話に出てきてくれるといいな。
  • 先生方を巻き込んだこと。講義(今は授業としか言わんのかな…。)にくる学生に声をかけてもらうことで、通常時にはなかなか足を運んでくれなさそうな、プログラミングには興味はあるけど次の一歩を踏み出せない方の背中を押せたと思います。
  • 最後に「俺とCoderetreat in KIT」というタイトルでLTをしてくださった加藤さん。加藤さん、マジ「俺と○○」というタイトルが似合いますね。
  • 大学の先生には面白い方が多いようで。私は大学には行っていないのでわかりませんでしたが、多種多様な経歴の方が集まるのが大学。今回も面白い先生が集まりました。
  • 1人でライフゲームを組みきって「ドヤァ」してくださった、中野先生ありがとうございました。
  • うるう年の判定なんて、「100で割り切れたらうるう年じゃない」とか「400で割り切れたらうるう年」とかは、そういうの組み込み機器に組み込んでも、組み込み機器の製品寿命はせいぜい10数年なので、バグになる可能性があるからいれない、と言い切ってくださった、西川先生ありがとうございました。
  • 河並先生のご尽力があってこそのCoderetreat in K.I.T. でした。本当にありがとうございました。

Problem

  • 申し込みの波が読めない。社会人を主なターゲットにしたCoderetreatを福井で開催した時は、2ヶ月前に募集を始めてやっと集まったくらいだった。今回もGWが明けた段階で12,3人の申し込みだったため、追い込みの意味で学内での募集を強化していただいたところ、それだけで20人集まってしまって、急遽増員することに。
  • 会場ではお菓子が食べられず、少し移動したところなら飲食OKという会場だったため、お菓子があまり気味に。おみやげができたのはいいけれど、この辺りの調整はほんとうに難しい。
  • 昼食中、スポンサーのスライドを連結して流していたけど、繰り返し流す方法がわからず手動で巻き戻す事に。こういう準備はほんと大事。
  • ホワイトボードに書いたハッシュタグがバグってた模様。
  • タスクの分担をうまくできてなかった。というか、タスクを見えるようにしてなかったので、周りに迷惑をかけてしまった。
  • 8:00受付8:30開始は参加者にもスタッフにも負担をかけてしまった模様。でもこればっかりは会場の都合もあるのでしょうがない。

Try

  • 社会人と学生と別々に申し込みを受け付けるようにする。
  • 会場の制約を考え、昼食とお菓子の量を考える。
  • スライドの流し方は前もって準備する
  • Trelloなどでタスク管理

ブログやスライドを書いてくださった方

Coderetreatの開催に興味がある方は、Qiitaにまとめてますので、参照してみてください。

http://qiita.com/search?utf8=%E2%9C%93&sort=&q=coderetreat

今回のスポンサー

スポンサーの皆様にはこんな感じでランチタイム終了後に会社説明をしていただきました。

永和システムマネジメント様発表

永和システムマネジメント様発表

金沢総合研究所様発表

金沢総合研究所様発表

株式会社KCC様発表

株式会社KCC様発表

スポンサー資料

株式会社永和システムマネジメント

永和システムマネジメント

株式会社金沢総合研究所

金沢総合研究所

株式会社KCC

永和システムマネジメント

金沢工業大学

金沢工業大学

株式会社チェンジビジョン

株式会社チェンジビジョン

デブサミ2014に参加した！(2日目)

デブサミ2014

続いて2日目のレポートです。

Team GeekによるFearless Change

資料: http://www.slideshare.net/kdmsnr/20140214-teamgeekfearlesschange

講演者の角さんは、Team GeekとFearless Changeの翻訳に携われた方。本当に様々な本を翻訳されている方で、リーダブルコードの翻訳もされました。

ちなみにリーダブルコードについても講演されています。

Fearless Changeは組織にアイデアを広める方法を48のパタンを使ってまとめられた本です。パタンを使ってまとめられたもので有名なのは、デザインパターンがあります。

@hyukiさんの定義によるち、大抵のパターンには、下記の4つの要素が含まれるそうです。

  • 文脈
  • 問題
  • 解決
  • 制約

パターンはそれぞれこれらの要素が関連しあっているので、全体象を記述する表記法がほしいです。それらしいものを今度書いてみようと思ってます。

越境する開発～あの日開発していたサービスの名前を僕たちはまだ知らない～

資料: 非公開

講演者の市谷さんこと@papandaはDevLOVE等で非常にお世話になっていたのですが、最後のデブサミと言っていたので、行かずにはおれませんでした。

市谷さんは基本的に資料は公開されるのですが、新たに自分のビジネスを立ち上げる事も含めてお話されたため、今回は非公開にされているようです。

ベースになっている話はこちらです。 http://www.slideshare.net/papanda/ss-28080078

非公開ということで、あんまり詳しく書けないですが良い話でした。

モーションセンサーの現状と2014年の予測

資料: http://www.slideshare.net/kaorun55/devsumi-201414c5

講演者は0日めのセンサー&デバイス祭りのオーガナイザーの @kaorun55 さんでした。裏番組が@kawagutiさんという、よくあるバッティングでした。ざんねん。で、Kinectに代表されるモーションセンサー以外にもOculus RiftというヘッドマウントディスプレーやリコーのTHETAという、360度撮れるカメラの紹介がありました。

このOculus Riftは、0日目のレポートにも書きましたが、ほんと素晴らしい没入感のディスプレーで、首を回す角度に合わせ、ディスプレイの可視領域も変わります。それが全天球全て対象に変わるため、THETAと組み合わせるとあたかもその場にいるかのような印象を受けます。これは正直、体験しないとわからないです。機会があればぜひ体験してください。

Kinect等のモーションセンサーデバイスもPCへの組み込みが始まっています。これまではデジタルサイネージに良く使われたモーションセンサーですが、わざわざアプリを使うためにこれらのデバイスを購入する人は稀ででした。既に組み込まれているのであれば、話は違います。そういったアプリが今後増えていくだろう、というのが2014年の予測でした。

ちなみにですが、こういったデバイスの補助アクセサリは、3Dプリンタで印刷できるデータで配布されることが増えているそうです。

その他面白かったデブサミの資料

デブサミの資料は、 http://codezine.jp/article/detail/7640 にまとめられています。 この中で面白そうな資料をピックアップします。

Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所

http://www.slideshare.net/sifue/developers-summit-2014-play2scalaweb

ドワンゴさんのサービス、ニコニコ生放送をPHPからScalaに置き換えている際、ドメイン駆動設計をフル活用し、柔軟性、拡張性の高いシステムを構築しているという話です。

ドメイン駆動設計は、数年前から流行してますが、コード側にモデリングを寄せた設計手法ととらえてもいいと思います。1日目の方にちょいちょい書いていましたが、インフラ、テスト、モデリングそれぞれコード側に寄せ、集約するように発展してきたのが2000年代だったんじゃないかな、と思ってます。関連する技術を調べてまとめてみたいところ。

新卒エンジニア研修ですべきことできること

https://speakerdeck.com/ryopeko/devsumi2014-dena-bootcamp2014

DeNAの新卒エンジニア研修の話です。Twitterでとても良かった、と評判だったので、共有します。

最後に

デブサミのオーガナイザー(代表責任者)の@iwakiriさんこと岩切さんは、後継者を育てるため、今年のデブサミを最後にオーガナイザーから退くそうです。デブサミは今年で12回目で、岩切さんはデブサミの立ち上げから一貫してオーガナイザーを続けられていました。

岩切さんがデブサミを始めたのは35歳の時で、35歳定年説なんて嘘だ！と主張されていましたが、今回のデブサミは前夜祭を含め、本当に面白いセッションが多く有意義に過ごすことができました。

岩切さんがデブサミを始める時、会社からデブサミのようなイベントができないか相談され、また仲間から背中を押されていたのですが、一週間ほど悩んで決めたそうです。

僕は今32歳なのですが、35歳になるまでに、そういう風に仲間に背中を押されて新しい事を始められる人になれるよう、頑張ります！

デブサミ2014に参加した！(1日目)

デブサミ2014

ということで、引き続き1日目のレポートです。

サーバプロビジョニングのこれまでとこれから

資料: https://speakerdeck.com/mizzy/future-of-server-provisioning-at-developers-summit-2014

2013年に非常に流行し、発展した技術は、VagrantやPacker、Chef、Docker、serverspec等、数ステップで予め設定したサーバーを立ち上げ、検証できるツールです。このセッションはserverspecを開発しているpaperboy&co.宮下さんのお話でした。

それぞれどんなツールか簡単に紹介すると、

Vagrant

仮想マシンを簡単に作成、管理するツール。各OSをインストールしたイメージを作成しておき、再利用できるツール。プラグイン機構を持ち、VirtualBoxだけでなく、VMWareやEC2、さくらクラウドや後述するDockerに仮想マシンを作成できる。

Packer

仮想マシンのひな形を作成するツール。各OSのインストール、セットアップを自動化するツール。JSONで設定値を書いて実行。VirtualBoxを使って試したところ、キーボード入力なども自動で行ってくれました。過去veeweeというツールもありましたが、Packerの作者はVagrantの作者と同じ方なので、こちらがメインになりつつある。

Docker

Linux上に別のLinuxの仮想マシンを立ち上げるLXCという技術をベースに、より利用しやすくしたツール。

Chef

ミドルウェアのセットアップをcookbookという形式でセットアップできるツール。cookbookはRubyスクリプトで書く。

serverspec

仮想マシンのテストをできるツール。設定が壊れていないか、テストで繰り返し検証できることや、同一の設定のサーバーを一度に展開した時に、自動的に確認できる。

こんな感じのツールが雨後の竹の子のように生まれ、流行したのが、2013年でした。(間違ってたらコメントを頂けるとうれしいです。)

実際は2013年よりも前からこういったツールがあり、AWSの流行と共により使われるようになり、流行し始めたようです。この流行の流れで、Infrastructure as Codeとか、Immutable Infrastructure とか、 Disposable Component といった言葉が生まれました。インフラを作るのもコードで済むようになり、既存のサーバーの設定をいじくるのではなく、コードを変更して、新たにサーバーを作成し、ロードバランサーの設定を変更することで接続先を変更する、と言った辺りを表現したのがこれらの言葉です。

インフラ周りのセットアップがコードに寄せられると、バージョン管理とかもしやすくなるので、便利ですよね！

テスト自動化を見直そう！自動化への投資が開発チームをクリエイティブにする

資料: 非公開 (代わりにtogetter http://togetter.com/li/628619 )

このセッションはランチセッションでした。いつの間にか、デブサミでも昼ごはんが提供されるようになってました。このセッションは、静的解析ツールベンダーのコベリティさんの中で行われているテスト自動化の取り組みの発表でした。

コベリティさんは、6ヶ月ごとのリリースサイクル、3ヶ月毎に次期リリース計画を練り直し、リリース直前のテストに6週間。スクラムで回しています。サポートするプラットフォームは非常に多く、215の仮想マシンインスタンス上でテストをしています。これだけのサポートプラットフォームを人力でテストすることの方が非効率なため、数年前からテスト自動化に投資し、現在はSelenium(ブラウザテスト自動化ツール)で3000以上のテストケースを自動実行しています。

とはいえ、テスト自動化を行うにもスキルが必要です。一年目は外注した事で失敗したので、現在は社内に専門のチームを設けているそうです。

別のセッションでDeNAのテストチームの話( http://www.slideshare.net/masaki/test-engineering-on-mobage )を聞いたのですが、DeNAも専門のチームがあり、MSやGoogleもそういった部署があります。また、楽天にいる友人は、社内にTDD(ユニットテスト)の文化を根付かせる部隊で仕事をしているそうです。テストの自動化には相応のコストがかかるのですが、大きな会社では自動化に投資を始めています。

スマホアプリのテストも、Seleniumと同一のAPIで実行ができるAppiumというライブラリが出てきています。(Seleniumの開発者がスマホ向けに開発を始めたのがAppiumです。)Seleniumのユーザーグループもできたそうです。

こういった流れを見てみると、2014年は、テストケース自体の管理を、インフラ同様、よりコードの方に寄せていきそうな印象を受けました。

何故クックパッドのサービス開発は日々進化しているのか

資料: https://speakerdeck.com/yoshiori/how-we-cook-cookpad-dot-com

2年ほど前にドワンゴからクックパッドに転職した庄司嘉織(通称@yoshiori)さんの講演です。一言で言うと、クックパッドの文化の話でした。

クックパッドでは、ユーザーに向いた仕事をする事を全社員に課せられており、クックパッドのエンジニアは、社外で講演したり、成果を公開することが義務付けられています。それが人事評価の指標にもなっており、今まで講演してきた資料は、会社サイトにまとめられ、公開されてます。 (これを作成するスクリプトもGitHubで公開されています。 https://github.com/cookpad/presentations )

クックパッドでは、ユーザーサポートの管理もGitHubのIssueで行っています。これによりエンジニアとしては、どういう内容が今サポートに来ているのか把握でき、サポートとしては、ユーザーサポートで必要になったコードの変更などの進捗も、コメントで見えるようになったそうです。

そういった取り組みを始めたのがヨシオリさんで、30分程度サポートの人に、GitHubの使い方やMarkdownの書き方(GitHubのWiki記法)を伝えたらサポートの人もGitHubを使えるようになったそうです。それができたのも、サポートの人もユーザーに向いた仕事をすることが求められているため、GitHubを使うことでよりエンジニアと密にコミュニケーションが取れ、よりよい仕事ができるのなら新しいツールを覚えることに抵抗がないという、「文化」があればこそできたことだろう、と言う話でした。

その他にも、クックパッドのシステムは1000以上のモデル（テーブル）を持つシステムですが、2ヶ月で50以上新たにモデルが追加されるなど、活発に開発が行われています。基本的にmasterの内容をGitHubにpushするとそのままシステムにデプロイされるため、 日に多い時は10回システムの更新が行われます。システムの更新時には当然CIが走り、壊れていない事を検証します。今、クックパッドのシステムには16000件以上のテストケースがあるので、毎回16000件のテストが実行されます。この16000件を超えるテストケースの実行を10分以内に終えるために専門のチームがあるそうです。デプロイの早さがシステムの更新回数に影響するため、10分以内に終える事を目指しているのだと思います。

1日目の終わりにはアンオフィシャルパーティーがありました。会場の隣はアマゾンジャパンの本社があり、そこの2階で開催されました。アマゾンジャパンの玉川さんにお話を伺う機会がありました。

アマゾンの文化は、Work Hard, Have Fun, Make History というスローガンに現されるとおり、まず「一生懸命働く事」が第一だ、と笑っていらっしゃいましたが、僕は、ユーザーにとって何が一番いいか、ということに向けて一生懸命に働く文化がある、という風に感じました。そのため、特にAWSを利用しているユーザーと共に必要な機能を考え、優先度付けをする会議を設けたりしているそうです。 これから作るツールはどうあるべきか、二日目に考えた事があるので、二日目のレポートにまとめます。

デブサミ2014に参加した！(0日目:センサー&デバイス祭り)

デブサミ2014

デブサミ2014に参加した目的

福井に引っ越してきてそろそろ3年。そして、今年で社会人になり10年が経とうとしてます。福井に引っ越す前に携わっていた翻訳書の出版の話がなくなり、同時期に翻訳を始めていた仲間の翻訳書であるFearless Changeが無事形になるなど、自分のキャリアを考える事がありました。このまま淡々と福井で開発をしていていいのか？と、迷いが出てきてました。そこで Business Model You のワークをやってみたりして、自分の強みが何で、どういう価値があって、それがどう人に役に立つのか、考えてみようと思って、やってみたりしました。こういうワークは独りでやってても効果がないのか、あまり霧が晴れるような効果はなかったんですが。

ビジネスモデルYOU

ビジネスモデルYOU

丁度そんなタイミングでデブサミが開催されるという事を思い出し、開催の大体10日前に急遽デブサミに参加することに決め、上司に休みをもらい、コーヒースポンサーに申し込んで行ってきました。(コーヒースポンサーについては後述します。) 本来ならばデブサミは、予めセッションを申し込む必要があるのですが、コーヒースポンサーのお陰で飛び込みでセッションを聞く事ができるようになりました。コーヒースポンサーは、非常に良い制度だと思います。 @iwakiri さんありがとうございます。

デブサミには東京に住んでいたころの仲間がいます。Fearless Changeの日本語訳の監訳者の@kawaguti さんや、 shibuya.tracとかでよく会っていて、最近はKinectなどセンサーデバイスを使ったアプリ開発の本を書いている @kaorun55 さんに会いたいと思ったのです。

コーヒースポンサーというウルトラな制度

コーヒースポンサーは、スピーカーの皆さんにコーヒーを提供したい、という @iwakiri さんの思いが実現したものですが、スポンサーになった時の特典がすごいです。

こんな感じで超お得！コーヒースポンサーになるには協賛金1万円が必要ですが、それだけの価値が十分にありました。

0日目:センサー&デバイス祭り

今回のデブサミは、@kaorun55 さんの企画で前夜祭、「センサー&デバイス祭り」が開催されました。 @kaorun55 は今年もセッションを持ち込んでたり、精力的に活躍してるからすごいです。「センサー&デバイス祭り」は、体験型のデモが中心だと思い込んでいましたが、セッションもありました。「うげ。申し込んでいない」と思いましたが、会場に行くと、コーヒースポンサーの力なのか、中にいれていただけました。マジごいす。

センサー&デバイス祭りでは、KinectやPerCなど、カメラデバイスとセンサーを使ったアプリや、Oculus RiftというVRを追求したヘッドマウントディスプレイなんかがデモされていました。Oculus Riftは頭の動きに合わせて映像も調整してくれたりするんですが、これは体験しないと凄さがわかりません。機会があったらぜひ体験すべきです。そんなに高くないから欲しい。製品版はよ！

で、特に面白かったのは、このレポートにもある、しくみデザインのデザイナー兼社長の中村氏とエンジニア中茂氏の「日本的キモチイイインタラクションは、世界に通じるコンテンツ！テクノロジーに縛られるな！」と題した講演でした。

http://codezine.jp/article/detail/7637

Kagura for PerCのデモ http://www.youtube.com/watch?v=gEt8e701w-c

中茂さんの「プログラマーにとって楽しいのは、美しいコードを書いたり、よいアルゴリズムを書いて高速化したりといった部分だと思うが、それらは大抵ユーザーには伝わらず、さも当然のものとしてその上が求められる。アルゴリズムなどの部分はチャチャッと済ませてしまい、本当にこだわるべき部分にきちんとリソースを費やすことが大事」という言葉に、同じプログラマとして深く共感しました。

しくみデザインさんのビジネスはデジタル広告が主戦場です。お客さんが楽しむ事で、そのコンテンツが記憶に残り、来客効果を上げ、ユーザーのビジネスに貢献するのが仕事です。

「すごいは1度だけ、楽しいは何度でも」ということをスローガンに、

  • とにかく単純に
  • 音をちゃんと作る
  • 失敗自体存在させない
  • 正確さより曖昧さを活かす
  • テクノロジーを感じさせない

広告を作っているそうです。

その他のセッションの中でも面白かったのは、落合陽一さんの、情報の流れの話です。どういうことかというと、20世紀はコンピュータの発展に伴い、情報が「現実→仮想」に流れていたのが、21世紀になると「仮想→現実」に情報が流れている、という話でした。(落合さんが開発されているディスプレイの話は、イマイチよくわからなかったですが、ホリエモンとのインタビュー記事を読むと理解が進みました。)

Tokyo MotionControl Networkすごい

@kaorun55 さんも所属するTokyo MotionControl Networkがセンサー&デバイス祭りの共催でした。このコミュニティの面白いところは、参加者の中にミュージシャンや声優など、モーションコントロールを使って面白い事をしたいユーザーまで巻き込んでいるところです。開発者だけだとニッチな方面に行き過ぎるのですが、実際に「使いたい！」と思うユーザーを巻き込んでいるところが素晴らしいです。

ということで、0日目のレポートはこのへんで。

Global Day of Coderetreat 2013 - Fukui, Japan を開催しました。

2013/12/14にGlobal Day of Coderetreat 2013が世界中で開催されました。今回、福井から初めてGlobal版に参戦しました！

f:id:kompiro:20131224222620j:plain

丁度1年前、 @haradakiro さんからGlobal Day of Coderetreatの開催の報を聞き、福井で開催できないか調整してきました。しかし、2週間の準備期間では間に合わず、今年の2月に福井で初めて開催しました。その時も盛り上がりましたが、今回も大変盛り上がりました！参加者の方がレポートを書いてくださったのでまとめました。

参加者の方のレポートまとめ

id:pobo380さんのレポート
りりぃさんのレポート

こういうレポートを書いてくださると、『やってよかった！』ととても励みになりますね！誠にありがとうございます！

さて、私は主催なので、ファシリテーターとして参加全体の流れの仕切り等をやらせていただきましたが、いくつかのセッションは参加者として取り組みました。最初は見学だけのつもりで途中で帰る若いエンジニアもいたので、主に課題に対しどう取り組むか、実演するためでした。しかし、やってみると他の方とも取り組みたくなり、逆に色々と学ばせていただくことになりました。

1人KPTを記録しておきましょう。

Keep
  • 無事に開催できた
  • 若いエンジニアの方が多数参加された
  • 今回は金沢からの参加者が特に多かった
  • テストコードを書くことの価値を共有できた
  • Java/Ruby/C#/Pythonの書ける開発者が集まったことで、異なるプログラミング言語環境との交流を産む刺激があった
  • サインペンや付箋などを十分に準備できていた
  • テストコードを書く練習場としてとてもうまく機能していた
  • 参加者の意識を「ライフゲームの完成」から「より良い設計」により向けられていた
  • GDCRの事務局本部の連絡が的確で文章化もとても行われていたので、スライド等の準備は非常にスムーズに行えた
    Problem
  • Global版という事で、ハングアウトを準備してみたが、当日のスケジュールの伝達不足であまりやりとりができなかった
  • live.coderetreat.orgの更新をすっかり忘れていた
  • 少人数で運営する事に無理があり、舞台裏では各所に迷惑をかけてしまった。いつもK氏には頭が上がらない
  • 遠方からいらしたシニアエンジニアの方がいらしゃったので、ご飯を食べに行きたかったが家庭の事情で実現できなかった
  • ふりかえりで付箋を貼ってもらっていたが、徐々に張り出す枚数が減っていた。
  • 参加者の負荷が少なかったかもしれない。今回はping-pong(ぶつかり稽古)のみだったが、Baby StepやSCMとの組み合わせなど、もうちょっと負荷をかける取り組みを追加してもいいかも。
  • 東京がGDCRに参加していないなど、会場が神戸、大阪、福井とちょっと寂しい感じになっていた
    Try
  • スタッフ/ファシリテーターを募集する
  • GDCR以外での金沢での開催(2月か3月)
  • 深く知らない言語環境について知る良い機会のため、できるだけたくさんのプログラミング言語が登場する会にしたい(scalaやJavaScript、Haskell等)
  • ぺんてるのサインペンと3Mの付箋の手配を怠らない
  • 休憩も兼ねて、参加者に他のペアのペアプロを促進するようなファシリテーターを勧めてみる
  • ファシリテーターはセッションへの参加は積極的に行わないようにして、ふりかえり等で参加者にもっと考えてもらうようにする
  • 8月くらいから他に参加したい会場がないか呼びかけてみる
  • TDD as you meant it をやってみる。