Cookpad と Zaim のオフィスにお邪魔してきました
東京に行く機会があったので Cookpad と Zaim のオフィスにお邪魔してきました。
場所は恵比寿ガーデンプレイスです。 (最近オフィスの移転がありました。) Google Maps で調べたら恵比寿駅から徒歩 8 分ぐらいでちょっと遠いかと思っていたのですが、実際に行ってみると駅からガーデンプレイスまで歩く歩道の設置された通路 (恵比寿スカイウォーク) があって、さほど距離は感じません。
おしゃれなレンガ造りの建物がある公園という感じで恵比寿ガーデンプレイスはなかなかいい場所でした!
Cookpad のオフィスは @rejaspotaro さんに案内してもらいました。 Cookpad のオフィスといえばキッチンがあることで有名ですが、話には聞いていても本物を見ると 「オフィスにこんなキッチンがあるのすごいなー」 と思わざるを得ませんでした。 開放的な広々した空間に大きな冷蔵庫やキッチンがどーんとあるのを見ると羨ましい限り! 家にもああいうキッチンが欲しいですねー。
オフィス内にはシャワールームやトレーニング器具もあって、あとは洗濯さえできればオフィスに住めるやん、って感じです。 開発者のいる部屋は間仕切りなしの広々した空間になっていて、そこにデスクがばーっと並んでいて人の多さを実感しました。 他に気になった場所は本棚のあるライブラリで、そこで勉強会などができるようになっていました。 本棚が結構小さかったので本は全部入るのかなーと心配したり。
Cookpad の見学の後は @rejaspotaro さんと一緒に Zaim のオフィスにお邪魔して閑歳さんやスタッフの方とお話させて頂きました。 働きだした年に閑歳さんのインタビュー記事を読んで、「働きながら個人プロジェクトを成功させている人もいるんだ!」 と思ったのが印象に残っているので、今回お会いできてうれしかったです。
Cookpad の会社内にオフィスがあるとは聞いていたのですが、思った以上に Cookpad との行き来が容易で驚きました。 人によるとのことでしたが、Cookpad の方との交流も多いようです。
その後は Cookpad と Zaim の Android アプリエンジニアの方々と技術交流。 私が Android アプリ開発からちょっと遠ざかっているのでこちらからあまり面白い話ができなかったのは申し訳ないところですが、トラッキング周りの課題の話やら、オーケストレーション層を設けて複数の HTTP リクエストをまとめたいというような話ができて参考になりました。 あと 「いやー、新しくやりたいことはあるんですけど人が足りなくてねー」、「奇遇ですねー、うちもですよー」 みたいな話をしたり。 「ソフトウェアエンジニアの転職は人づてになりがちだからそういう方向が良さそう?」、「とはいえソーシャル活動してない人で優秀な人もいるし、そういう人に興味を持ってもらうためには Wantedly なども効果があるかもしれない?」 とかとか。 難しいところです。
最後にお昼ご飯をご一緒させて頂きました。 ガーデンプレイスには食べるところがいろいろあっていいですね。 今回は 「関西から来てお好み焼きなんｗ」 と突っ込まれつつタワー最上階近くの千房でお好み焼き。 美味しゅうございました。
お世話になった皆様ありがとうございました。
ソフトウェアエンジニアを募集しています!
文中にも書きましたが、ソフトウェアエンジニア募集中とのことです! お世話になったので紹介します! 恵比寿ガーデンプレイスはなかなか働きやすそうな場所でしたよー。
もちろんはてなもソフトウェアエンジニアを募集しています! 京都だけでなく東京開発センターもあります! 興味のある方は是非お気軽に私にご連絡ください!!
発表資料: Android アプリ開発における Gradle ビルドシステム (京都 Android 勉強会 2014.08)
去る 8 月 23 日に株式会社はてな主催で行われた Android アプリ開発の勉強会 「京都 Android 勉強会 2014.08」 にて、Android アプリ開発と Gradle について喋ってきました。
Android Studio ではビルドシステムとして Gradle が採用されていますので、今後 Gradle を使う人は増えていくと思います。 Android Studio でビルドをするだけであればそれほど Gradle に詳しくなくても問題ないわけですが、せっかくなのでいろいろ便利に使っていきましょう、という主旨の発表でした。
発表内容は下のような感じで、Gradle を使ったことがない人にも 「Gradle でこういうことができる」 というのが伝わるように喋ったつもりです。 また、後半の方は Gradle を使って Android アプリのビルドをした人でも触ったことがない人もいると思いますので、Gradle を使っている人にも参考になったかもしれません。
- Gradle と Android アプリのビルド
- Gradle や Android Gradle plugin の機能の一部を紹介
- ここら辺は知らなくても問題なく開発できるはずではあります
- AAR パッケージについて
- Gradle プラグインについて
勉強会では、Cookpad の @rejaspotaro さんが 「debug ビルドの時だけデバッグに便利なメニューを表示するようにしている」 とか、「社内でいくつか Gradle プラグインを作って便利に使っている」 という話を先にされていたので、そこら辺とからめて Gradle の話ができたのも良かったところです。
質疑内容
会場で 2 つほど (確か 2 つ) 質問がありましたので、ここにも書いておきます。
Gradle wrapper の更新
Gradle wrapper を使う場合、Gradle のバージョン更新はした方がよいのか、という質問でした。
Android Studio のバージョンアップにともなって必要な Gradle のバージョンも変わってきますので、Android Studio のバージョンアップに合わせてプロジェクト内の Gradle (Gradle wrapper) のバージョンも更新する必要があります。 最近の Android Studio では、Gradle のバージョンが古い場合に警告を出してくれて、GUI 上でぽちぽち操作すると自動的にバージョンが更新されるはずです。
Gradle の欠点
発表資料の中で 「Groovy のことを理解するまでデバッグ等が大変」 と書いていますが、それ以外に不便な点などはあるか、という質問でした。
Gradle 自身の欠点というわけではないですが、Eclipse での Android アプリのビルドと比べて、一部を変更してビルドし直すというのが Android Studio でのビルド (あるいは直接コマンドライン上で Gradle を使った場合のビルド) では時間がかかってしまうというのがあります。 私は今のところあまり細かい変更でビルドし直すということをしないようにすることでなんとかしていますが、UI の変更などでは細かく調整したいということもあってなかなか不便ということでした。
Gradle をオフラインモードにすると速くなるという話もあります。 (ちゃんと試してません。)
Gradle のオフラインモードかー。 そんな変わらんでしょ、って思ってたけど効果あるっぽい。 / “Android Studioのgradleビルドを高速化する | KonifarPod” http://t.co/w3PWBeoPWo
— nobuoka (@nobuoka) 2014, 8月 27関連エントリ
勉強会での他の発表者の発表資料や参加者によるまとめです。 (後で追加します。)
Docker 入門 #1 — Windows に Boot2Docker をインストールして既存イメージを扱ってみる
Docker 使えるようにならないとなー、ということで、まずは Docker を使える環境を準備して、ユーザーガイドをちょっと読んでみた。 既存イメージを使ってコンテナの生成をするなどの操作をするところまで。 完全なる入門者向け (あるいは自分用) だけどメモしておく。
Docker のバージョンは 1.1.2 を使用した。
Docker についての参考文献
そもそもの Docker についての説明はこのエントリでは行わない。 次の記事が参考になる。
- Docker とは何か: 今からでも間に合うDockerの基礎。コンテナとは何か、Dockerfileとは何か。Docker Meetup Tokyo #2 － Publickey
- 背景 (ウェブシステムにおける Docker の立ち位置):
Windows での Docker 環境の構築
Windows ユーザーでない場合はそれぞれの環境用のインストールガイドを参照のこと。
- Windows 上への Docker 環境インストールガイド: Microsoft Windows - Docker Documentation
Docker Engine は Linux カーネルの機能を使用しているので、Windows の上に直接 Docker 環境を構築することはできない。 VirtualBox なりなんなりで仮想マシンとして Linux マシンを Windows 上に起動する必要がある。
Boot2Docker というアプリケーションが Docker より提供されているので、(Docker Engine 用の仮想マシンを立てるつもりなら) これを使うのが便利である。 Boot2Docker を使うことで、VirtualBox 上に Docker 環境用の仮想マシンをインストールし、Docker デーモンを走らせることができる。
- Boot2Docker: boot2docker/boot2docker · GitHub
Boot2Docker のインストールで VirtualBox もインストールできるようなので、まだ VirtualBox をインストールしていない人でもいきなり Boot2Docker をインストールして良い。 次のエントリも参考になる。
使い方
「Boot2Docker Start」 というのがスタート画面のアプリケーション一覧に追加されているはずなので、これをクリックする。 すると、VirtualBox に Docker 用の仮想マシンが登録されて、Linux のインストールなどが実行される。 そして仮想マシンが起動して、そこに SSH 接続される。
この仮想マシン上で docker コマンドを使い、Docker コンテナを作ったりする。
また、インストール時にパスを通すかどうかのオプションを選択できるが、パスを通しておけば boot2docker コマンドが使えるようになる。「Boot2Docker Start」 を使わなくても、PowerShell を開いて boot2docker コマンドを使うことで、仮想マシンの操作ができる。
他のコマンドは boot2docker --help で調べられる。
Docker を使ってみる
ユーザーガイドに従って Docker を使ってみる。 これ以降は、基本的に boot2docker ssh して、仮想マシン上でコマンドを実行するものとする。
ユーザーガイドとは別にオンラインチュートリアルもあって、こっちの方が最初は良いかもしれない。
アプリケーションの Docker 化 (?)
docker run コマンド
$ sudo docker run ubuntu:14.04 /bin/echo 'Hello world' Hello world
上のようなコマンドを実行すると、何やらダウンロードしてきて、最終的に 「Hello world」 が出力される。 何をしているかというと、「ubuntu:14.04」 というイメージからコンテナを新たに生成し、そのコンテナ上で 「/bin/echo 'Hello world'」 というコマンドを実行している。
指定されたイメージは、まず Docker ホスト上で探される。 そこで見つからなければ、Docker Hub 上で探される。 今回の場合、「ubuntu:14.04」 というイメージは Docker Hub からダウンロードされる。
新たに生成されたコンテナは、指定のコマンドを実行し終えると停止 (?) するようである。 (コンテナ自体は残っている。 後で出てくるが、docker ps コマンドに -a オプションを渡すと、停止しているコンテナも表示される。)
-t オプション *1 と -i オプション *2 を渡すことで、対話型コンテナを立ち上げることもできる。
-d オプションでコンテナのデーモン化ができる。 docker run -d ... コマンドを実行すると、長い文字列が表示される。 これはコンテナ ID である。 コンテナの名前は (明示的に指定しなければ) 自動的につけられる。
docker ps コマンド
docker ps コマンドで、実行中のコンテナの情報が表示される。 コンテナ ID やコンテナ名などが確認できる。
上で書いたように、-a オプションを付ければ停止中のコンテナも表示される。
docker logs コマンド
docker logs {container} コマンドを使えば、コンテナ内部の標準出力を表示できる。 {container} としては、コンテナ ID とコンテナ名のどちらかを指定できるっぽい。
docker stop コマンド
docker stop {container} コマンドを使えば、動いているコンテナを止めることができる。
コンテナの扱い方
バージョン確認
docker version コマンドで、Docker クライアントと Docker サーバーのバージョン情報が表示される。 Go のバージョンや Git コミットのリビジョンも表示される。
Docker クライアントのコマンド一覧
オプションなしの docker コマンドで、docker コマンドが受け付けるアクション一覧が表示される。 各アクションについては、docker {action} --help コマンドでヘルプを表示できる。
コマンド一覧については Web 上のヘルプを参照してもよい。
Web アプリケーションを Docker 内で動かす
$ sudo docker run -d -P training/webapp python app.py
上記コマンドで、トレーニング用の web アプリケーションを Docker 内で動かすことができる。 「training/webapp」 というイメージは Docker Hub からダウンロードされる。
-P オプションは、コンテナ内部で必要なネットワークポート (exposed port) をホストのそれにマップするように Docker に伝えるためのものである。 上のコマンドを実行した後、docker ps -l コマンド *3 を実行すると、PORTS の項に以下のような表示が出るはずである。
PORTS 0.0.0.0:49155->5000/tcp
ローカル Docker ホストの 49155 ポートが、コンテナの 5000 ポートにマップされていることがわかる。 コンテナ側のどのポートを露出させるかを指定する方法は、後で (イメージ作成方法のところ) で説明される。 ホスト側のポートは 49000 から 49900 の間 (high port と表現されている) から自動的に選ばれる。
-P オプションの代わりに、docker run コマンドに -p {container_port} オプションを渡すことで、コンテナの指定のポートをホスト側の high port にマップすることもできる。 -P オプションは、コンテナの exposed port をホストの high port にマップするものであるが、-p オプションはコンテナ側の指定のポートが exposed port かどうかは関係ないようである。
また、-p {host_port}:{container_port} という形式で、コンテナの指定のポートを、ホストの指定のポートにマップすることもできる。
ちなみに、Windows 上で Boot2Docker を使っている場合は、Windows の PowerShell 上で boot2docker ip コマンドを実行することで、Docker ホストの IP アドレスを取得できる。
docker port コマンド
docker port {container} {private_port} コマンドで、指定のコンテナの指定のポートがどのポートにマッピングされているかを知ることができる。
Web アプリケーションのログ表示
docker logs コマンドの -f オプションは、tail コマンドの -f オプションのようなものである。
コンテナのプロセス
docker top {container} コマンドで、指定のコンテナのプロセス一覧を見ることができる。
コンテナの詳細
docker inspect {container} コマンドで、指定のコンテナの詳細情報を JSON 形式で得ることができる。
さらに、-f オプションを使うことで、特定の情報のみを取りだすこともできる。
$ sudo docker inspect -f '{{ .NetworkSettings.IPAddress }}' nostalgic_morse
172.17.0.5
コンテナの再起動
停止されたコンテナは、docker start {container} コマンドで再度起動できる。 実行中のコンテナの再起動は docker restart {container} コマンド。
そういえばコンテナが停止される際に、コンテナ内のプロセスがどうなるのか、とか、再起動時にはどうなるのか、とかわかってない。
コンテナの削除
停止されたコンテナは docker rm {container} コマンドで削除できる。
そういえば同僚が 「要らなくなったコンテナのごみ掃除が大変だ!」 とか言ってたけど、これのことなのかなー。
今回はここまで
既存のイメージを使うところまではこんな感じ。 さらにイメージをビルドしたりする話が続くけど、それはまた別のエントリに。
Docker入門 Immutable Infrastructureを実現する
- 作者: 松原豊,米林正明
- 出版社/メーカー: 技術評論社
- 発売日: 2014/04/25
- メディア: Kindle版
- この商品を含むブログ (5件) を見る
【告知】 来週土曜日 「京都 Android 勉強会 2014.08」 開催 & Gradle のことを話します
来週土曜日 「京都 Android 勉強会 2014.08」 開催
来週土曜日 8 月 23 日の午後 3 時から 「京都 Android 勉強会 2014.08」 が開催されます! 株式会社はてな主催です。 タイトル通り Android アプリ開発に関する勉強会です。
- はてなの告知: 「京都 Android 勉強会」を8/23（土）に京都で開催します！ #kyotoandroid - Hatena Developer Blog
- 募集ページ: 京都 Android 勉強会 2014.08 - connpass
きしださんがいらっしゃいますし、Android アプリ開発に関する実践的な話もいくつもありますので、興味深い勉強会になると思います! 関西圏で Android アプリ開発をしている方は是非いらしてください!
Gradle のことを話します
私も Gradle や Android Gradle plugin などの話をする予定です!
先日 beta 版がリリースされた Android Studio では、ビルドシステムとして Gradle が採用されています。 Android アプリ開発でも Gradle を触る機会が増えた今、Gradle に関する知識はある程度持っておく必要があります。 「Gradle のことはよくわかんないけど、Android Studio が自動生成してくれるビルドスクリプトにちょっと追記して使ってるよー」 という人向けの入門的な話から、「Gradle のことはそこそこわかってるけど、そろそろ自分でプラグイン書いたりしたいなー」 といった人向けのプラグインの作成周りなどの話まで、ある程度広い範囲の話をしようと思っています!
再度になりますが、是非是非いらしてくださいっ!
読んだ: アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
開発手法としてスクラムを取り入れているチームに所属しているが、アジャイルやスクラムといった手法についてあまり知識を持っていないソフトウェアエンジニア、という立場で本書を読んだ。 本書のカバー袖には 『企業の経営層に向けてソフトウェア開発手法の 「アジャイル」 とその手法の一つである 「スクラム」 を体系的に解説する』 とあるのだが、経営層に限らず、アジャイル的な開発手法を採用して開発プロセスを改善していこうとする人であれば、誰にとっても有益だと思う。
アジャイル開発については、ウォーターフォールとの比較として 「小さなサイクルを回して変化に柔軟に対応しながら開発を進める」 という程度の理解しかなかったので、本書を読んで 「人が知識を運ぶ」 とか 「人と人のコミュニケーションで知識を伝える」、「顧客と協調して開発を進める」 といった、どちらかというと社会的な活動やその意義についての部分が非常に参考になった。
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- 作者: 平鍋健児,野中郁次郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/01/18
- メディア: 単行本（ソフトカバー）
- 購入: 1人 クリック: 12回
- この商品を含むブログ (18件) を見る
本書は 3 部構成になっている。 第 1 部 「アジャイル開発とは何か、スクラムとは何か」 では、ソフトウェア開発手法であるアジャイル開発について、どういうものなのか、なぜそれが必要とされたのか、といったことが説明される。 そして、アジャイル開発の枠組として、スクラムについても詳しく説明される。
アジャイル開発については、「ウォーターフォールのように要件定義や設計、実装という各作業で開発プロセスを分断するのではなく、小さなサイクルを回して完成を目指す」 (すなわち、包括的なドキュメントより動くソフトウェアを重視し、計画に従うだけでなく変化に柔軟に対応していくことを重視する) というものだと思っていたのだけれど、それだけでなく、「個人と対話」 や 「顧客との協調」 といったことにも価値を置く価値観が根底にある、ということを知れたのが良かった。 この価値観は、「アジャイル宣言」 に述べられている。
また、朝会 (デイリースクラム) やプランニングポーカー、アジャイル開発の各種プラクティスについても説明される。 プラクティスとしてはアジャイルの右翼 (開発環境) に属するものと左翼 (チーム環境) に属するものがあり、それらをうまく組み合わせてアジャイル開発の目的である 「ビジネス価値」、「顧客満足」、「市場創造」 といったことを達成する。 ここら辺のプラクティスについては、軽く紹介されるだけという感じなので、実際に現場で実践するのであれば詳細は別の書籍などで学ぶと良いと思う。 次のようなスライドもある。
2 部では、実際にアジャイル開発を導入した国内の 3 社 (リクルート、楽天、富士通) の事例が紹介される。
3 部では、現在のアジャイル開発では明示的に言及されないような、企業経営とリーダーシップの側面から、アジャイル開発の考察がなされる。
個人的に気になった内容
アジャイルの各種プラクティス
プランニングポーカーは 1 回やったことがあるけど、ちゃんとしたやり方を知らなかったので 「なるほどー」 という感じで読んだ。 他のプラクティスについては大体知ってたけれど、いくつか新しい発見があった。
- プランニングポーカー
- 最初にベースラインを決める。 メンバー全員が知っているあまり大きくないタスクを選ぶ。 → こないだプランニングポーカーやったとき、最初のタスクは適当に数字を出してて 「こんなんでいいのかなー」 と思ったりしてた。
- 見解は一番大きい数字と小さい数字の人が言う。 → 数字が合わなかったら全員が言うものだと思ってたけど、確かにそれだと時間かかりすぎるし、最大と最小の人が言えば良さそう。
- 3 回で切り上げ。 → まあそんなものか。
- 朝会でプロジェクトの外部の人の発言するタイミングを制限する。 → 外部の人が、自分がリスクを取るわけでもないのに気軽に口出しする、というのを防ぐ意味。
- プロジェクト内の人をブタ、外部の人をニワトリと呼ぶことがある話。 ハムエッグを作るのにブタは自分を生命をかけるが、ニワトリは自身の生命に関わらない貢献の仕方をする。
- ブタとニワトリの話、会社の人もしてた。
- タスクかんばんのタスクは 2、3 時間程度で終わる粒度が良い。
- 今のプロジェクトでもタスク粒度には悩んでる。
- タスクが動くことで進捗状況の共有。 さらに達成感にもつながる。 1 日で動くようなタスク粒度にすべきとのこと。
- バーンダウンチャート
- 進捗状況の確認のための質問は 「完了までにあと何ポイント (理想時間) 必要か」 にする。 「何パーセント完了したか」 や 「残り何パーセントか」 ではない。
- 作業が進むにつれて、見積もりよりも実際に必要な作業が多いことがわかったりするので、残り作業時間を把握すべき。
- スプリントで完了できたポイント数をベロシティとして、スプリントあたりに進めることができるタスク量の目安とする。
- 工数をポイントで見積もった場合に、実時間とどう変換するのがいいんだろうなーと思っていたけれど、実時間と変換するよりはスプリントあたりに進めることができるポイント数を把握してれば良い、という感じか。
- スプリントの成果物はリリース判断可能なもの。
- ユーザーストーリーには詳細な仕様は書かない。
- ペアプログラミング
- 15 分おきにぐらいでペアを交代する。 開発のメリハリやリズム。 → 15 分がいいのかどうかわからないけど、まあそれぐらいかなーという気はする。
- リスクが大きい作業や、クリエイティブな作業はペアで行った方が効率的。 → 設計とかも、設計をきっちり書いてレビューしてもらって大きな直しが発生する、というような状況になるぐらいなら最初からペアでやった方が良さそう。
事例
各社、それぞれ課題があったり良い取り組むをしていたりして興味深い。 他社がやってるからといって表面的に真似ても意味はないけど、どういう考えで各取り組みをしたのかが書かれているので、そこら辺がだいぶ参考になる。
リクルート
- バーンダウンチャートに上限線を引く。
- 予めバッファを持たせて、上限線を引いておく。 実績線が上限線を超えそうになったら要件の調整を行う。
- 上限線を引いておくことで、要件の調整に対して事業部側の理解を得やすい。
- 出世魚型のドキュメント。
- ドキュメントは開発フェーズをまたいで使いまわし、更新していく。
- ドキュメント作成の工数削減と、ドキュメントが分散して齟齬が発生することを防ぐ。
- 言葉で聞いたら、さもありなん、という気はするけど、実際のところドキュメントどうするかって結構難しい問題ではある。
- 最初はワンチームマインドの醸成に苦戦した。
- 見積もりのずれに対する認識。 事業部側は見積もりは初期から変わらないという認識。
- 意識の変革と共有。 地道な啓蒙や説得。
- 会議からの持ち帰りの禁止。
- 「持ち帰って検討」 が開発スピードを遅らせる。
- 持ち帰って 100 % の精度で回答するのではなく、80 % の精度でいいのでその場で回答する。
- 残り 20 % に起因する手戻りが発生しても、お互いに怒らないように。
- 精度を求めすぎて時間がかかる、というのは避けるように自分も意識してはいるけど、それでも時間をかけて検討することは結構多いので、もうちょっとスピード重視に振ってもいいかもなーとか思ったり。
アジャイル開発とスクラム
アジャイル開発で重要そうなトピック。
- 多層学習と多能力学習。
- 個人、チーム、部、会社、という様々な層で学習が起こる。
- チーム内にエンジニアやデザイナ、営業、といった様々な専門スキルを持つ人間がいるので、自分の専門外のことも学習する。
- 暗黙知と形式知、両方の形式が重要。
- 実践知リーダー。
- PDCA (計画、実行、検査、適応) サイクルの前に共同化。
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- 作者: 平鍋健児,野中郁次郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/01/18
- メディア: 単行本（ソフトカバー）
- 購入: 1人 クリック: 12回
- この商品を含むブログ (18件) を見る
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- 作者: 平鍋健児,野中郁次郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/06/20
- メディア: Kindle版
- この商品を含むブログを見る
