kentana20 技忘録

技術ネタを中心に、セミナー、勉強会、書籍、会社での出来事を綴っていきます。不定期更新。

Cookpad Tech Conf 2016 に行ってきた

1.23 に恵比寿で開催されたCookpad Tech Conf 2016に行ってきました。 公式ページは こちら

f:id:kentana20:20160124025832p:plain

タイムテーブル

No Theme Speaker
1 基調講演: ユーザーのために、技術をどう活かすか 舘野 祐一 ( @hotchpotch )
2 おでかけスポット検索のむずかしさ - Holiday を支える検索技術 内藤 雄介 ( @Yu_7110 )
3 Railsアプリ開発環境の高速化 国分 崇志 ( @k0kubun )
4 R&D at Foodtech company 有賀 康顕 ( @chezou )
5 技術力を事業の強みするために必要なこと 大野 晋一
6 開発した新技術から、新しい価値を作るためのクックパッド検索チームのプロダクト開発手法 五十嵐 啓人
7 「今日なに作ろう?」を支えるデザイン 木村 真理 ( @mura24 )
8 確かめながら作るユーザー体験 出口 貴也 ( @dex1t )
9 モバイルアプリのインタラクションプロトタイピング 多田 圭佑
10 モバイルアプリ開発の"標準"を探る 藤 吾郎 ( @__gfx__ )
11 DWHに必要なこと 青木 峰郎 ( @mineroaoki )
12 基調講演: クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について 成田 一生 ( @mirakui )

その内、すべてのセッションの資料が公開されると思います。

セッションメモ

やはり、というか基調講演のお二方(セコンさんとmirakuiさん)の2名のセッションが全体感があって、スライドの内容もわかりやすくてとてもよかったので、この2つのセッションにフォーカスして紹介したいと思います。

ユーザのために技術をどう活かすか( @hotchpotch )

CTOであるセコンさんのセッション。 今日は 「ユーザファーストのための技術と組織」 という2つの点や情報共有についてのお話でした。

Cookpad社員数と構成、サービス規模

  • 社員数と構成

    • 250名(グループ会社含めて400名)
    • ものづくりに関わっているのはだいたい100名くらい
      • エンジニア80名
      • デザイナー10名
      • 企画・ディレクター10名
  • サービス規模

    • ユーザはだいたい5,500万人くらい

ユーザファースト

  • 他にもこういったことを言ってる会社は結構多いが、他社と比べてもCookpad徹底してやっている のではないかと思う

  • Cookpadでは↓の2つを意識している

    • ユーザファーストのための技術
      • 技術をユーザのためにどう使うのか
    • ユーザファーストのための組織
      • どうやったらユーザファーストを実践しやすい組織になるか

ユーザファーストのための技術

  • エンジニアにすべてが求められる時代
    • 求められる要素が多くなっている
    • フルスタックエンジニアという言葉だったり

s1.jpg

  • なんでもでやってくれ、と言わんばかりの要素
  • さらには技術だけじゃなくて、チーム作り、プロジェクトマネジメント、分析 etc...

ユーザのために技術をどう活かすか

  • 仮説・検証・実行をできるだけ早く回すために必要なもの
    • このサイクルを徹底的に磨くことを意識し続ける
    • 「打席に立つ回数を上げる」ために技術をうまく使う
    • 磨き続けることでユーザにとっての価値が何かを学習していく

このサイクルを高速化するための技術的取組みをいくつか。

  • 仮説・実行で使われている技術
    • Ex. Chanko
      • 一部のユーザに向けてプロトタイピングテストをするためのライブラリ(Gem)
      • OSSとして公開されている
  • 検証で使われている技術
    • Ex. Hakari
      • さまざまなメトリクスを図れる計測ツール
      • Kibanaっぽい感じのUIでした。こちらはOSSとしては公開されていない模様
  • ほかにもサイクルを早く回すための技術が数多くある

    • サービスの機能が多くなって、テストが多くなり、デプロイに時間がかかるようになった
      • RRRSpecという分散テストツール(gem)を開発
      • テスト時間を圧縮してデプロイを高速化
  • ネイティブ開発

    • アプリはサクッとリリースできない
    • リリースしなくても仮説・検証・実行サイクルをどう回すかを考える
    • Ex.
      • Flinto, Prottといったプロトタイピングツールを導入
  • Microservices

エンジニアに求められること

  • 変化を受け入れ、シーンに合った技術・開発を行う
    • 変化できる組織とエンジニアを目指す
  • エンジニアに求められる技術
    • ユーザ価値を提供するために何が必要かを考えて、技術を活かす
    • 技術に強みを持って何が必要か(何が価値なのか)を考え実行する
  • プログラミングができるとか、プロジェクトをリードできるとか、個々の要素は当たり前のスキルとして持つ
    • 当たり前のことを当たり前にやり続けることが大事

ユーザファーストのための組織

組織の形

  • 集約型
    • エンジニアだけの組織(チーム)をつくる
      • 事業部ごとにエンジニアを配置しない
    • メリット
      • 技術知見の共有をしやすい
      • リソースの配分、最適化がしやすい
  • 分散型
    • いろいろな部署にエンジニアが配属
      • 事業部ごとにエンジニアを配置する
    • メリット
      • チーム(事業)のビジョンを共有しやすい
      • 事業に対するナレッジを蓄積できる

会社や事業のステージ、方針などによってどっちが良いとかは全然異なるので、一概に「コッチのほうが良い」とは言えないと思っている。

Cookpadの組織

  • マトリクス型
    • 横串の技術部・インフラ部
      • 基盤整備、インフラなどを担当
    • 縦串の各部室・チーム
      • サービスや事業の背景共有(重要)をしつつ、集中して継続的な価値をつくる

いまはこの形になっているが、今後変わることもあると思っている。

情報共有

  • 掛け算の組織にしたい

    • 単純な人員数での成果ではなく、有機的にコラボレートして人員数以上の成果をあげたい
  • 対面での情報共有と非対面での情報共有

    • 対面: プロダクト編成会、技術リーダー会、デザイナー会など
    • 非対面: Groupad, GitHub Enterprise

どちらも重視している

Groupad

  • Blog + Wiki的なサービス

    • パッと見た感じ、はてなスターみたいな機能とか気軽にフィードバックできるような仕組みになっているっぽかったです
    • 社内のカメラで写真を撮ると自動でアップされたりする
  • 情報とコミュニケーション

    • 解りやすく情報を伝える
      • 誰に何をどう伝えるかを日頃から意識することもユーザファーストにつながっている
      • それを日常的に考えて動く仕組みも組織作りの一環で、重要なこと
    • 日々の情報発信
      • めちゃ大事
      • たとえば、開発者ブログ
        • 持ち回りでやっていて、効果もある

1人1人の成長の場をつくる

  • 設計・実装・フィードバック
    • GitHub Enterpriseを通したコードレビュー
      • 「デキる人」からのフィードバック
        • 詳しい人が1人いると、すごいスピードで伝搬していく
        • なんで?がすっきり解決する
  • 様々な視点を得る
    • 他の組織・開発を経験する
      • 自分が得たスキル・知見をさらに活用してチーム、組織にフィードバックする
      • 同時に他の組織に入ることで、自分が知らない視点のインプットにもつながる
    • 100を120にするより、10を50にする方が効果的
      • とある知見を持っている人が、知見を持たない人がたくさんいる組織に入っていくことで組織全体がレベルアップしていく

自発的な組織改善

個人的にはこの部分がかなり刺さりました。

  • Cookpad Lounge
    • 定期開催のキッチンでの料理&飲みイベント
    • 部門とのコミュニケーションの活性化
    • 自主的に企画&開催
    • エンジニアが始めたイベント
  • エンジニアも主体的に組織改善に関わる
    • ちゃんと組織改善を評価する(評価制度もセットでないと、続かない)
    • 社内外に良い影響を与えているか

質疑

  • ユーザファーストは創業当時から?
    • 考え方自体は創業当時からあったものだけど、言葉にするとユーザファーストだったという感じ

クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について

インフラ部長である @mirakui さんの発表。

今日のテーマ

  • 限られたリソースで、どうやって組織や事業の変化に強い開発をするか
  • 長寿化したアプリケーショとどう向き合っていくか

これは両方共、今の一休.comに当てはまる部分が多いテーマで、とても興味深く聞かせていただきました。

前提

  • 事業は変化する
  • 組織も変化する
  • プロダクトやコードには寿命がある
  • 開発リソースは有限である

事業やサービスの変化によって、コードも適切に変えていかなければいけない。

デカイアプリケーション

  • 起動に時間がかかる
  • テストに時間がかかる
  • 静的解析ツールが動かない
  • ライブラリが動かない
  • デプロイが大変
  • レールに乗れない

デカいだけで、いろいろなことがものすごく大変だったり、遅いせいで面倒になることが多いという話はとても共感できました。

コード、環境は老朽化

  • 人は書き直したくなる

    • 2010年頃にフルリニューアル計画
      • エンジニアは10名くらい
      • コードが巨大・複雑すぎて新機能の実装が困難
      • いまのサービスはこれでよいのか
      • コアな部分だけをつくって理想的なCookpadにしたい
  • サービスのコアバリューを抽出する

  • キレイなコードをスクラッチで書く

を2つを同時にやろうとして大失敗した。

学び: 仕様整理とリファクタリングは同時にやらないほうが良い

学び2: 手遅れになってからやらない

仕様整理とリファクタリングを同時にやり始めると、いつまで経っても仕様整理が落ち着かずに、効果的にリファクタリングできず、効率的に進めることができなくなる。 「ココがもうヤバいから、なんとかしよう」という状況まで引っ張ってしまった時点でもう手遅れで、そうなる前にアクションしないといけない。2つとも、めっちゃよく分かる話。

2007のリニューアルはうまくいった?

  • Coldfusion -> Rails

    • エンジニア5名くらい
  • 決してうまくいってなかった

    • サービス規模が小さかったからなんとかなった
    • すでに壊れかけてたから、それ以上悪くなることはなかった
    • 移行後、かなり不安定だった
    • 若さで乗り切った

なぜ、書き直したかったのか

  • サービスを継続的な改善 がしたかった
    • 謎のレガシーコードが多くて、機能追加・改善がめちゃやりづらく、継続的改善の支障となっていた

つまり、フルリニューアルでなくても

  • 開発速度を落とさず、継続的な改善 ができればよかった

Chanko

リニューアル失敗が生み出したプロトタイプテスト用Gem A/Bテストをキレイなコードで書ける。

2012年頃は多サービス時代

脱・"World's largest rails monolith"

  • プロジェクト分割方針
    • 本体と密結合にしなければいけないとき以外は新規サービスは別のRailsプロジェクト
    • 既存サービスも分離できるものは順次分割していった

ref. もう失敗しない!プロジェクト書きなおして、最高の開発環境を手に入れる

本当は何がしたいのかを見極める

  • シンプルな作りにしたい
  • 不要なコードが重なり、動作が遅くなっている部分を解消したい
  • 新しい技術、ライブラリを取り込めるように

大事なこと

  • 1つずつやる

おいしい健康を分離した話

  • 第一段階

    • forkして要らないコードを消す
    • テストを通して、健全性を担保
  • 第二段階

    • rails newしたプロジェクトにコードを移植
  • 注意

    • ロジック移動のみ実施する
    • リファクタリングしたくなっても我慢する
    • テストをパスすることを重視
  • 学び

    • フルスクラッチで描き直さない
    • 仕様、リファクタリングの変更をなるべくせずに分割していくと良いことがある
      • 小規模に少しずつ進めることで小さな成功体験(メリット)、事業的なメリットを享受できた

コード品質はビジネスに影響がある

  • Cookpadでは コード品質はビジネスに影響がある と考えている

  • コード品質が影響するもの

    • 開発効率
    • 属人性
    • コード

どこまでやるべきなのか

  • きれいなコードを書くことが目的ではない

    • 事業フェーズにとって必要な品質を目指す
  • コードレビューで担保する

    • 質の高いコードレビューで品質をそれなりに担保する
    • 負の遺産を残しにくくする
  • コードレビューアンチパターン

    • もめる
      • インデント、括弧
      • とにかく不毛
  • コード規約はコードレビューの効率・コード品質向上に役に立つ

    • GitHubに公開している
    • 最初は反対意見も多かった
      • mirakuiさん自身も反対派だったらしい
    • 重要なのはビジネスのコードレビュー
    • コード品質に直接的には寄与しないが、効果はある

ここまでが開発についての事例でした。

インフラの老朽化

2011年(AWS移行), 2012年(VPC移行)

  • 2度の移行

    • よくわからないサーバは淘汰された(使っていないサーバの炙り出し)
    • 全サーバは Infra as Code 化した
    • OSや各種パッケージをアップデートできた
  • インフラの課題

    • 存在しないサーバのmanifestファイルなど、不要なコードが残る
    • OS, ミドルウェアのバージョンが古い
  • インフラ老朽化の特徴

    • アプリケーションが動いていれば、老朽化問題が顕在化しない
    • 大幅なバージョンアップは大変で時間がかかるので、必要になってからでは遅い

老朽化しないための式年遷宮

  • 作りなおすことを前提にすることで、システムが長寿命化することを目指す

既に、Cookpadでもインフラの式年遷宮が計画されて、動き出している

まとめ

長生きする事業のために技術ができること・考えられること

  • 事業の変化、限られたリソースをどう活かすか
  • 品質や新しさを保つこと自体を仕組み化する
    • 難しくなる前から計画する
    • 少しずつやる
  • 手遅れになる前に少しずつやる
  • 小さな成功体験をつくり、アップデートの価値を組織に実感させる
    • 「これくらいのコストでここまで成果が出てるなら、次のXXXもやりましょう」という流れをつくる

所感

  • セコンさんの発表や、他の技術セッションの発表で出ていた、開発環境を良くする仕取り組みで一休でも実践できている点が何箇所かあって、うまくできていてる部分もあると感じた

    • Ex. 開発環境を自動構築する仕組み、開発環境から本番相当DBを参照する仕組み、CIを活かしてデプロイを高速化する仕組み etc..
  • エンジニア主体で社内のコミュニケーション活性化を図る取り組みと「エンジニアも組織改善に主体的に関わることを評価する文化・制度」が素晴らしいと思った

    • Groupad的なBlog, Wiki機能の社内活用や、共有イベントを企画したりといったアクションについても当たり前のように継続してやっている点がすごいと思った。この部分は一休でもこれから強化していこうと思っているので、できるところからやっていきたい
  • mirakuiさんの発表であった 品質や新しさを保つこと自体を仕組み化する ことはとても良いと思った

    • リソースは有限であり、「やりたいと思ってることが放置されっぱなし」という状態に陥りがちなので、ここは仕組み化しておくべきという話はとても共感できた

数年前にCookpadの発表を聞いたときは「はるか未来を行っていて、まるで異世界」という印象だったけど、いまの一休と同じような悩みや取組みもあったりして、自分たちの前進を少しでも感じることができて嬉しかったです。

これから、一休でも社内の取組みをどんどん発信していきたいと考えているので、今回のイベントで得た知識をしっかり社内にフィードバックしつつ、具体的なアクションを考えて実践しようと思います。

最後に素晴らしいイベントを開催していただいた、運営スタッフの方々、スピーカーの方々に御礼申し上げます。 ありがとうございました&お疲れ様でした。

会場の様子

恵比寿ガーデンホールというところでした。

f:id:kentana20:20160123152918j:plain

一休.com での ChatOps

はじめに

こんにちは @kentana20 です。一休.comの中で自動化や開発フローの整備・改善などを担当しています。

本エントリはChatOps Advent Calendar 2015の14日目の記事です。一昨日は @treby さんが

というタイトルで、趣味で作成されたBotを紹介いただきました。

今日は、 一休.com でのChatOps活用事例をいくつかご紹介したいと思います。

一休で使っているツール

一休では以下のツールを連携してChatOpsを整備しています。 比較的よくある組み合わせだと思います。

カテゴリ ツール
Chat Slack
Bot Hubot
CI Jenkins
E2Eテスト Selenium
VCS GitHub Enterprise
タスク管理 Redmine

一休.com でのChatOps

リリース運用はChatOps

業務効率化で一番よくあるケースの1つだと思います。リリースに絡む運用はChatOpsで行っています。

  • リリース用のプルリクエスト作成

一休.com ではProductionへのリリースを行う場合にmasterブランチからreleaseブランチにプルリクエストを出し、リリース内容の確認を行っており、このプルリク作成をBot+CIジョブで行っています。

f:id:kentana20:20151214124855j:plain

こんな感じで、コマンドを投げて

f:id:kentana20:20151214124907j:plain

こんな感じのプルリクを作っています。プルリク作成には ghqgore などでお馴染みの motemen さん作成の git-pr-release というGemを少しカスタマイズして使っています。

直近までは、その後のタグ作成などもSlack経由で行っていましたが、現在ではreleaseブランチへのmergeをトリガーに自動化しているので使うことはなくなりました。

ST/ProductionへのE2EテストもChatOps

一休.comではST/ProductionへのデプロイフローにSeleniumによるE2Eテストを組み込んでいます。 (E2Eテストについて、詳しくは↓のスライドをご覧ください)

これも、Slack+Hubot+Jenkinsを組み合わせて、いつでも誰でも実行できるようにしています。

f:id:kentana20:20151214124939j:plain

こんな感じですね。カンタンです。

チームの朝会もChatOps

開発チームはデイリースタンドアップ的な共有を毎朝やっており、その運用にもChatOpsを活用しています。

  • 朝会用のエントリ作成

一休.com では週に1回は形式を変えて、マネジメント的な共有事項や開発ユニット毎のアップデートの確認として30minくらい時間をかけて実施しています。この週1回の朝会はQiita Teamで事前エントリを書いて行うので、朝会エントリはHubotのcronを使って自動化し、作成したエントリのリンクをSlackに通知しています。

f:id:kentana20:20151214124953j:plain

週のうち、ほかの4日間は共有事項のみのデイリースタンドアップなので、Hubotを使って朝会通知とファシリテータのアサインを行っています。ファシリテータはユニット単位なのですが、そのユニットに合った画像を添えて賑やかに(?)朝会が始まります。

f:id:kentana20:20151214125011j:plain

日々の開発の中でもChatOps

少し変わった例としては、開発中のブランチを共用環境にデプロイするときにもChatOpsを活用しています。 これはSlack上で

  • 共用環境の番号
  • ブランチ名

を指定してデプロイコールをすると、指定した環境に、指定したブランチがデプロイされる、というもので主にプルリクのレビュー時に使ったり、マーケティングやカスタマーサービスといったエンジニア以外のメンバーにデモをするときに使っています。

f:id:kentana20:20151214125024j:plain

こんな感じでリリース前の環境を自分の手元ではない共用環境に気軽にデプロイできるようにしています。

おもしろ事例

開発ユニットによっては hubot-cron を利用して、ユニット内の運用をHubotとともに行っているケースがあるので、紹介します。

  • 休日当番のリマインド

休日の当番という制度があるのですが、その当番をBotがリマインドしてくれます。なんと占い、ラッキーアイテム、ラッキーカラーを添えてくれる、というなんとも気の利いた仕様です。

f:id:kentana20:20151214143939j:plain

  • とりとめのない話

朝会直後に来る、完全にムチャぶりBotです。ムチャぶり過ぎたためか、いまはこのBotはなくなってしまいました。。

f:id:kentana20:20151214143952j:plain

今後やりたいこと

グラフレポート

少し前に Kaizen Platform の Glide Noteさんが 「ChatOps + NightmareでメトリクスグラフとBIレポートをSlackに投げるようにした」 という記事を書かれていて、とても良さそうに感じたので

  • Kibanaのダッシュボード
  • 主要導線の平均レスポンスタイム

などをメトリクス化して、朝会の時間に通知するといったことを行いたいと思っています。

所感

ChatOpsについてこの1年半くらい開発・運用をしてきて思うのは

  • 「使いドコロによっては、開発者に負担をかける面もある」

ということです。自分はこういった仕組みはとても好きなのでChatOpsで運用を整備しがちなのですが、ヘビーに使わない開発者にとってはChatのコマンドは覚えづらいですし、運用の性質によってはChatOpsに載せたほうが良いものとそうでないものもあると思います。

たとえば、さきほど紹介した共用環境へのデプロイについて最近、簡易的なWebアプリから行えるようにしたのですが、その結果、活用頻度がさらに上がったように思います。

使いドコロによってはChatOpsは他の手段に置き換えた方が開発フロー全体の改善につながるのかもしれません。

おわりに

まだほかにも事例はいくつかありますが、 一休.com でのChatOps事例をいくつか紹介しました。

こうしてふりかえってみると「いろいろやっているな」ということを再認識できると同時に

  • 活用できているものとあまりできないかったものの棚卸しができる
  • 「こういったことができるかも」と思考の幅が広がる

といった面でとても有用でした。

昨年は別のAdvent Calendarに参加させていただいたのですが、年末にこういったイベントがあると年内に脳内の大掃除をしている感覚になってとっても良いです。こういった場を作ってくださっているQiitaやイベントを成立させている皆さまに、この場を借りて感謝申し上げます。

来年も前進を続けて、さらに良い現場を目指して行きたいですね。

明日は、参加登録がないので次回は 12/16(水) で @q_goma さんです。よろしくお願いします!

飛騨の古民家で開発合宿をしてきた

すごく久々の更新。最近はギョームでバタバタやっていたのと、インプットが少なくてネタがあまりなかったです。 けど、いろいろ進捗してるところもあるのでどっか機会があればまたご紹介したいですね。

前フリは良いとして、本題。

会社の有志メンバーで開発合宿に行ってきた

去年の夏に

kentana20.hatenablog.com

で書いて「開発合宿楽しいな〜」と思っていて、今年もやりたいと考えていたところ、10月末で一休を卒業した id:rei19 が「古民家でやりたいですね〜」とアイデアをくれたので企画して 11/7(土)~11/9(月) の2泊3日で id:naoya, id:rei19, id:minato128, id:RealFightProgrammer とあと1名の計6名で開発合宿に行ってきました。

f:id:kentana20:20151110002242j:plain

準備・企画

正直、あまりできませんでした。ただ、技術顧問である id:naoya にも話したら「開発合宿は2泊以上がオススメ ♪」とアドバイスをしてくれたので「2泊3日」を要素に追加しました。あと、箱根や熱海くらいだと近すぎて「出かけた感」が無いので

  • 古民家
  • 2泊3日
  • 近場過ぎないトコ

という感じで探して出てきた↓の古民家に泊まりました。

www.satoyama-office.com

結果として、この古民家は大当たりでかなり良かったです。備え付けのWi-Fiが遅かったこと、布団代がちょっと割高な点が残念ポイントでした。

また、古民家が飛騨だったので、企画に

古民家に70インチのプロジェクタが備え付けられていたので、「何を観るか」という議論の末、「やはり、聖地で氷菓を」という流れになりました。

スケジュール

ざっくりですが、こんな感じです。

11/7(土)

ポイントは開発開始時に自分のネタを共有しなかったことです。「コレをやります!」と共有してから始めてもよかったのですが、これも id:naoya のアドバイスから最終日の成果発表LTまでネタを共有せずに開催しました。

  • 9:00 東京駅集合
  • 9:30 北陸新幹線(かがやき)で富山へ
  • 12:00 富山でランチ(富山ブラック
  • 13:00 特急(ひだ)で飛騨古川へ
  • 14:20 飛騨古川から徒歩で古民家へ
  • 15:00 チェックインして近くのコンビニと酒屋へ買い出し
  • 15:30 3日目チェックアウトまでの予定を決めて開発開始!
  • 20:00 出前で夕飯
  • 23:00 初日開発をひと区切りつけて飲み会
    • 氷菓」「SHIROBAKO」などをちょこっとだけ鑑賞しました
  • あとは開発を続ける人は続けて、眠くなったら寝て終了
    • 自分は27:00頃までやっていた気がします

f:id:kentana20:20151110003942j:plainf:id:kentana20:20151110003945j:plain

11/8(日)

中日でかなり落ち着いて開発に集中できました。「2泊3日がオススメ」と言っていたことがよくわかりました。

  • 8:00~9:00頃 起床して開発開始
  • あとは食事以外は基本開発してましたが、 id:rei19 が持ってきた drone を操作して少しだけ遊んだりしていました

11/9(月)

昼までに成果発表LTとチェックアウトを済ませて、聖地へ寄り道してから帰宅しました。

  • 8:30~10:30 開発追い込み
  • 10:45~11:30 成果発表LT
  • 11:50 チェックアウトして撤収
  • 12:00 在来線で飛騨高山へ
  • 12:00~14:00 「氷菓」の聖地巡礼しつつ、高山観光
  • 14:30 高山→名古屋→東京というルートで帰路へ

f:id:kentana20:20151110010642j:plainf:id:kentana20:20151110010648j:plain f:id:kentana20:20151110010645j:plain

やったこと

自分は今回の合宿で、全然キャッチアップできてなかったネイティブアプリについて、学習を進めて、ネイテイブ開発の取っ掛かりにしたいと思っていたので

をテーマにして以下をやりました。

技術書は社内のアプリチームにオススメしてもらった以下をお借りして、写経しつつ、参考にしました。

Amazon.co.jp: Swiftではじめる iPhoneアプリ開発の教科書 【Swift 2&Xcode 7対応】【特典PDF付き】 (教科書シリーズ): 森 巧尚: 本

レポジトリ

  • 計算機アプリ
  • 氷菓検定クイズ
  • [WIP] ニュースリーダー

のアプリを作りました。

https://github.com/kentana20/

ここに収まっていますが、諸事情によりPrivateレポジトリなので、諸事情が済んだらPublicに上げます。

[WIP] 他のメンバーのやったこと

ここは順繰りに更新していきます。

まとめ

開発合宿はよい

約1年3ヶ月ぶりの開発合宿でしたが、やはり最高に楽しかったです。飛騨は遠いですが、日常から離れて開発に集中する時間は至福ですね。

といった要素も加わり、それも含めてとっても良い3日間でした。今回はちょっと準備不足もありましたが、開発合宿はうまく企画・運営できれば成果が出やすいイベントだと思います。次回は会社イベントでやりたいですね。

Swift 2/Xcode 7

今回初めてまともにSwift 2を触りましたが、記述の仕方や構文を見てもモダンな印象があります。関数型っぽく宣言的に書ける部分もあり、「最近の言語」という感じがして書いていて気持ち良いです。ネイティブアプリ開発、楽しいですね :)

何かアプリをつくりたい

Swfit 2 / Xcode 7 / iOSアプリの作り方については、今回の合宿で少しとっかかりになったので個人的にはアプリ開発を続けて公開するというところまでやりたいです。 ネタを探して年末を目処に頑張ってみようと思います。

YAPC::Asia 2015 に行ってきた

8/20(木)~22(土) に東京ビックサイトで開催された YAPC::Asia 2015 に行ってきました。3日でかなり多くのセッションがあったのですが、印象に残ったセッションをチョイスして技忘録。

f:id:kentana20:20150823234652p:plain

セッションの内容は こちら

Consulと自作OSSを活用した100台規模のWebサービス運用

カヤック藤原さんによる、Consulを使ったサービス運用のお話。

正直、「Consulって何ができるんだろ」って思ってたのですが

  • サービス監視(service discovery)
  • ヘルスチェック(health checking)
  • KVS(key value store)

など、サービス運用を自動化するための多くの機能があって、持っている機能をつかって何をするかは各サービスが抱えている課題次第でいかようにも、という印象でした。

カヤックでは

  • クラスタ内のノードに増減が合った場合のhostsの更新が面倒
    • 内部DNSは作りたくない
    • オートスケールしたい

ということで、Consulを使って内部DNSとして振る舞うようにした話や、ConsulをChefやStretcherといった他ツールと連携してオートスケールを実現している、というお話でした。

特にStretcherについては、pull型のオートデプロイを実現するツール

  • ビルドしたアプリケーションをtar.gzで固めてS3に配置
  • manifestファイル(手順書的な)も一緒にS3に

というお膳立てをした上で、Stretcherがmanifestファイルに書かれた手順でデプロイするという内容(だった...と思う)でした。

一休では、デプロイはpush型で実施しているし、自動化した後もしばらくはpushかなと思っていたので、ちょうど良いタイミングでモダンな事例を知ることができて、「試してみたい」と思う内容でした。

consulのサイトを見てみたのですが、Go製ツールらしくWindowsも普通に動きそうな感じで、しかも.net用のAPIも提供しているようで、マルチプラットフォームでの動作を考慮していることが見て取れました。

一旦、いまのデプロイフロー変更が一区切りついたタイミングで検証してみたいと思います。

Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術

はてなのhitodeくんさんによる、Perlはてなのサービスを作り続けている話。 このお話が、ベストトーク賞No.1に選ばれました。

といった、Webサービスのトレンドを追い続けた変遷を赤裸々に語っていました。

また

  • 用語集をmarkdownで管理して新メンバーへの教育に使う
  • ユビキタス言語はエンジニアだけでなく、サービスに関わる全員で共有する

など、どの現場でも参考になるお話もありました。

スライドも作りがとても良くて、ツラいこともたくさんあったと思いますが、前進を続けるサービス開発のお話をとても楽しく聞かせていただきました。

ちょうど一休で実施しているアーキテクチャ変更に通じる部分があって、とても参考になったというか、マインドの部分で見習う面もあり、刺激になりました。

HTTP/2 時代のWeb

mozaic.fm で有名なJxckさんによるHTTP/2についてのお話。 個人的には、このセッションが一番良かったです。

RFCが策定されたHTTP/2について、現状の整理とこれからをとてもわかりやすくお話されていて、興味深く聞いていました。

  • HTTP1.1環境下での高速化ノウハウは制限の中でうまれたバッドノウハウ
    • CSS Sprite、minifyして圧縮といった内容はとにかくリクエスト回数とサイズを少なくするための苦肉の策で、良い解決策ではない
  • HTTP/2で採用されているストリーム多重化や普及への道についての解説
    • 画像表示デモ
    • 各種ツールミドルウェアの対応状況
    • HTTPS化は最低限しておかないと、新しい仕組みの検証も難しくなるのでは

といったHTTP/2導入後のWebの未来を予測するような、素晴らしい発表でした。 HTTP/2を採用すれば、単純に速くなるという代物ではないし、いきなりサービスに組み込んでいくのはハードルが高いですが、採用しているアプライアンスミドルウェアの対応状況を見つつ、理解を深めて検証しておく、くらいの準備は必要だと感じました。

所感

今回は前回の慶応大学日吉キャンパスからビックサイトに場所を変えたYAPC::Asiaでしたが、変わらずに楽しむことができました。参加人数が2,000人を超える、国内ではかなり大規模なこのエンジニアのお祭りをオーガナイズした運営の方々に心から御礼申し上げます。楽しいイベントをありがとうございました!

発表内容を聞いていて思ったのは

  • 去年よりも、自分たちに置き換えて考えられることが多くなっている気がする

ということですね。去年は「こういう世界もあるんですね〜〜」と、ある意味異世界のように感じていたことも多かったのですが、今年は「あぁ、それはありますよね」とか「それは一休でも活用できそう」「同じ課題に当たりそうなので、アクションを検討したい」といった風に身近に感じることが多くて、ちょっとは前進しているのかなと思いました。

1つだけ、思ったことはクローズドキーノートでのmakiさんのお話がちょっと事務的だったこと。去年はyusukebeさんの事務的な報告以外でtypesterさんがとっても良いお話をされていたので、今年もクローズドキーノートは期待していたのですが、本当に事務的なカタチで終了してしまったのが残念でした。

来年以降でYAPCが開催されることがあれば、また参加したいと思います。

WWDCに行ってきた(セッションまとめ編)

6/8(月)~12(金)の5日間、アメリカのサンフランシスコで行われたAppleの開発者向けカンファレンス「WWDC (World Wide Developer Conference)」に参加してきました。今回、運良く参加することが出来たので

  • セッション内容
  • 自分が得た知見

について技忘録。今回はセッション編です。

セッション内容

MacOS X El Capitan

それほど、大きい変更は加えられず、細かい修正点の集合という印象です。

など、デフォルトアプリケーションを重用しているユーザにとっては、タブのピン止めやSpotlight強化などの「かゆいところに手が届く」機能アップデートが加えられていると感じました。

正直、使ってみないとなんとも、というところですね。週末にでも自分のMBAに入れて試してみようかなと思います。

iOS 9

初日のPlatforms State of the Unionというセッションで大体の概要が発表されています。

APIの変更は結構激しい模様

自分はiOS開発者ではないので、こちらも使ってみないと、なところではあるのですが、「iOS9向けにどうやって開発するの」的なセッションを聞いたときに各iOSバージョン毎に「アノテーションをうまく使ってコードをキレイにしましょう」的なことを言っていた気がするので、結構考慮しなければいけないところが出てくるのでは、と感じました。

DeepLinkingは良さそう

自分自身が昨年末にAndroidからiOSに乗り換えて感じたことですが、「Androidインテント機能は結構良かった」と思っていました。アプリ感での連携について、DeepLinkingで強化されるので、ユーザにとってはストレスが軽減されそうです。レストランアプリなどはDeepLinkingの仕様を提携先?に公開すれば、スマホ系広告・提携先からの流入時にレストランアプリを起動するみたいなことができるようになりそうです。早く試してみたい機能ですね。

iPad Multi Tasking

Demoを見る限り良さそうです。しかもアプリ側での考慮はいらないっぽいので、これも早く試してみたいと思いました。iPad持ってないので、購入を検討中です。

AppThinning / BitCode / AppSlicing / OnDemandResources

どういう仕組みなのか、よくわかってない部分もありますが

  • デバイスに最適化して必要な資材のみをダウンロードする
  • 初期ダウンロードを早くするために、アプリ起動後の任意のタイミングで追加資材を取得する

といった変更を加える事で、サイズの大きいアプリ(主にはゲーム?)のダウンロードスピードを上げる施策です。WatchOS向けのアプリではこの考慮が必須になるようなので、今後のスタンダードになると思います。

WatchOS 2

セッションビデオ

AppleWatchネイティブアプリが開発できるようになった。各種センサーやHealthKitなどをサポートしたことで、開発者はいろいろできるようになったと言えます。どんなアプリが出てくるのかはわかりませんが、ここから新しいビジネスが生まれる可能性も大いにあると思います。

Apple Music

残念の一言。秋の新製品の発表時にすればよかったのに。。まぁ、早くやりたかったのだと思います。開発者向けのニュースというよりはサービスの発表だったので、割愛。

ほか

あまり、大きくは取り上げられていませんが個人的にはCloudKit JSとMapKitにちょっと興味を引かれました。

CloudKit JS

iCloudへのアクセスをJSで行える≒Webアプリケーションで使えるということで、CDNなどに使えるようで、しかもコストは安いとセッションで言ってました。興味ある方はセッションビデオ見てみてください。

MapKit

MapはGoogleという見方が以前強いですが、どんなアプローチをしてくるのかが興味を引きました。その中では、Flyoverという3Dっぽいモードと、Transit(乗り換え)という2つのポイントでMap機能の強化を図るという意図が見えました。GoogleMapでいうところのStreetViewっぽい機能もこれから実装するというウワサもあるようですし、AppleのMapについての本気度が伺えました。こちらもセッションビデオが上がってるので興味ある方はどうぞ。 Transitについては、日本が未サポートなのが残念です。

所感

冒頭にも書いたように、今回のWWDCは大きなサプライズはそれほど多くはなく、堅実なアップデートをしてきたという印象でした。その中でSwiftOSS化やWatchKitなどについて、ネイティブ畑のエンジニアにとってはキャッチアップをし続けつつ、新しいビジネスチャンスを見つけることができるのでは、と感じました。特にSwiftについては、OSS+MultiPlatform化によってLinux上でも動くので、ちょっとしたスクリプトSwiftで書く、みたいなことがこれから起こる可能性もあるのかな、と思って聞いてました。

現地のmeetupでも早速WatchKit向けのハッカソンイベントがWWDCが終わった週末に開催されたりと、この変化を楽しむ環境がしっかり作られていると思いました。いきなりハッカソンだとちょっと敷居が高いかもしれないので、「WatchKitで何ができるのか」をドキュメントを読みつつ、アイデアソンみたいなカタチでWatchOS向けアプリを考えるというイベントも楽しい気がします。

今回、いろんな幸運が重なって、この大きなイベントに参加することができて、いろいろな知見を得ました。サンフランシスコのITサービスを使ってみたり、現地のエンジニアや日本から来ているエンジニアと交流したり、現地のmeetupに参加したり、という経験は技術者として大きな財産になると思いました。一休でも、会社として海外のカンファレンスに年1~2名は常時参加して、この経験を得ながら、新しいサービスを考えたり、既存サービスにフィードバックするみたいなループができると良いと感じました。

今回、参加を許可してくれた会社、チームのメンバーには本当に感謝しています。また継続的に成果を出して、次回は別のメンバーが参加できると良いなと思います。

次回は体験記的なカタチで現地で得た知見やWWDC Tipsについて書きたいと思います。