「Heroku社エバンジェリスト相澤氏が語るDay1「What is Heroku?」APC勉強会#5」に参加してきました
全3回を予定しているHeroku勉強会の第1回目となります。アプリケーション開発者の生産性を最大化するプラットフォームクラウドの概要と機能について、米国Heroku, Inc.の相澤歩さんにお話頂きました。
Herokuとは
プロフェッショナルなアプリケーション開発者のための世界で最も先進的なプラットフォーム・クラウド
Herokuの特徴
- サーバーを意識しなくて良い
- あらゆる言語・フレームワークを利用可能
- アプリケーションの状況を全て可視化
- 信頼と実績
サーバーを意識しなくて良い
- 普通はサーバーの構成や調達方法を考えなくてはいけない
- Herokuはそれらを考える必要がない
Gitを使ったデプロイ
- Herokuがこの方式を導入した2008年くらいはバージョン管理環境とデプロイ環境を同じにするのは珍しかった
- バージョン管理はみんな使っているのでHerokuはみんな使える
- Herokuは全てのデプロイを保持している
- 全てのバージョンの復元が可能
継続的デプロイ
- Jenkins、Travis CIなどとの連携も可能
- Gitを使っているからインテグレーションが簡単にできる
アプリケーションのスケールが容易
- サーバーが1台だと同時アクセス数が限られる
- キャパシティを考えて、サーバーの構成を設計しなければいけない
- Herokuであればその必要がない
- 管理画面のスライドバーを動かすだけでスペックを変えることができる
- スケールはAWSでもできるが、他のアプリケーションサーバと矛盾なく設定するのはそれなりのスキルが必要
- アイディアが受けるかどうか分からなくてもとりあえずリリースして、その後で自由にスケールすることができる
アドオン
あらゆる言語・フレームワークを利用可能
- Ruby、Java、Python、PHP、Clojure、node.jsに対応している
- 言語のセキュリティ脆弱性の対応も全てHerokuで行っている
- Ubuntu上で稼働するプログラミング環境を立ち上げることもできる
- しかし公式サポートはしていない
アプリケーションの状況を全て可視化
- 一連の動きがログストリームというところに入っている
- アプリケーション、データベース、ルータのログを全て一連のログで出力している
- フィルタリングすれば見たいところで見られる
可視化のためのアドオン
New Relic
- アプリケーションのパフォーマンスを測定
- 何がパフォーマンスのボトルネックかを見ることができる
Librato
- プラットフォーム（メモリの状況、コネクションがどれくらい張られているかなど）の情報が見られる
- 購入履歴など独自の情報を可視化することも可能
Papertrail
- ログを貯めることができる
- 適当なタイミングでアーカイブも行ってくれる
- こういうツールは地味だが作るのが大変
- アドオンを使えば簡単に実現できる
デベロッパーはプロダクトの価値創造に集中することができる
信頼と実績
Herokuをはじめよう
書籍『プロフェッショナルのための実践Heroku入門』
- 本番として使うTipsはあまりWeb上にはないが本書には書いてある
- トラブルシューティングも書いてある
-
- 何かあればすぐにレポートが上がってくる
- 対応状況も分かる
- ここに何も書いていなければアプリケーションの問題と分かる
-
- 問い合わせチケットを投げることができる
- サポーターは世界で10人弱いる
- 色んな時差に対応したサポーターがいる
「NLP勉強会 #1 #NLPStudy」に参加してきました
初心者向けのセッションから、word2vecのような最先端のツールの紹介、また参加者同士の交流ができるワークショップなど、非常に実りの多い幅広い方向けの勉強会でした。
NLP勉強会 目的・進行方針について
（再）入門自然言語処理 #01
@yamano357さんによる発表。
自然言語処理の要素技術
- 形態素解析
- わかち書き：入力文を単語に分割
- 原形化：語形・活用変化している単語を原形に戻す
- 品詞タグ付け：単語の品詞を決定
- 統語解析
- 「綺麗な黒髪の女性」は「綺麗な」が「黒髪」にかかるのか「女性」にかかるのか分からない
- 「言語の文法」に従って文法構造を解析
- 意味解析
- 「単語自体の意味」と「単語間の意味関係」を解析して文の意味を同定
- 文脈解析
- 文の意味は文脈の中で決定されると考えるため、複数の文を解析の単位と見なす
- 省略解析、テキスト構造の構築
自然言語処理の周辺技術
- 機械学習
- 数理最適化
- ネットワーク分析
自然言語処理の応用技術
- テキスト分類
- 情報検索
- 機械翻訳
- 情報抽出
- 自動要約
- 質問応答
- 対話システム
すぐに始める自然言語処理
@yamano357さんによる発表
自然言語処理ツール
言語資源
使用状況（頻度が多いもの）
- 形態素解析器：MeCab
- 構文解析器：CaboCha
- 辞書：日本語語彙体系、京都大学各フレーム
- コーパス類：Wikipedia、Twitter
- ツール類：Moses、GIZA++
- 機械学習ツール：LIBLINEAR
word2vecのご紹介
@piroyoungさんによる発表。
Word2vec from Hiroki Mizukami
言語モデル入門
@akkikikiさんによる発表。
MeCab辞書作りについてのご相談
@nezuqさんによるアイディアソン。
ワークショップの結果はこちら
素人がTF-IDFでキーワード抽出やってみた
@smzkngさんによる発表。
言語処理本紹介
@yamano357さんによる発表。
「ReactiveCocoa Tokyo #rac_tokyo」に参加してきました
@ninjinkunさんが発起人の一人で、Cocoa勉強会関西の特別編としてReactiveCocoaの勉強会を行ったところ、東京でもやろうということで開催されたとのことです。
はじめてのReactiveCocoa
ChatWorkの@tinpayさんによる発表。6月からReactiveCocoaで開発を行っているとのこと。
ReactiveCocoaって
- リアクティブプログラミングをサポートするライブラリ
- MVVMを実現するために利用する
- CocoaPodsでインストールできる
リアクティブプログラミング
- 命令型プログラミングは直ちに評価される処理を記述する
- 対して、リアクティブプログラミングは関係性は関係性を記述する
a = 1; b = a + 2; a = 3; print(b);
- 命令型だと出力は3だが、リアクティブプログラミングだと5になる
MVVM
- Model: データ・ビジネスロジック
- View: 画面・UI
- ViewModel: Viewの値・動作を保持して、Modelとの情報伝達を行う
- ModelとViewの間を取り持ち、バインディングを行う
- ReactiveCocoaを使ってバインディングすれば幸せ
- ViewControllerのインスタンス生成時にViewとModelの関係性を書くだけで、値が変わったときにViewに反映させるための記述が必要がなくなる
- リアクティブプログラミングと命令型プログラミングを比較するためのサンプルソース
メリットとデメリット
メリット
- ViewControllerがスッキリした
- 処理はViewModelに記述される
- テストが書きやすい
- ビジネスロジックはModelに記述される
- 一時変数がなくなった
- バグが減る
デメリット
- 難しい。。。。。。。
- 1ヶ月くらいでは今までどおり書いたほうが何倍も早い
- まずはViewModelへのデータバインディングのみ使うのがいいかも
- Signalを連鎖し過ぎると見にくい
まとめ
- 難しい
- 直感的に書けない
- もどかしい
- でもソースは綺麗になる
- 頑張りましょう＼(^o^)／
FrilでのReacitiveCocoa事例
株式会社Fablicの@ninjinkunさんによる発表。
- あなたが求めていたリアクティブプログラミング入門
- リアクティブプログラミングは非同期データストリームを扱うプログラミングである
なぜ今ReactiveCocoaか
- アプリの複雑化
- Webサービス連携アプリの増加
- アプリが非常に多くの"状態"と"非同期処理"を持っている
- 多数のAPIと非同期に通信し、状態を適切に更新し、ユーザに表示する
- Modelの更新、通知、Viewの更新
RPの特徴
- イベント駆動、拡張性、障害への耐性、応答性
RPの用途
- サーバーでもクライアントでも使える
- Netflixではサーバとクライアントの中間レイヤーで使われている
ReactiveCocoaの段階的な採用
FrilのRAC利用ポリシー
段階的な採用
MVVMへの緩やかな移行
なぜMVVMが必要か
- SNSアプリでは状態をViewController間で共有することが多い
- エントリの情報の追加、編集、削除
- ViewModelをbindすればViewは自動更新にしたい
ReactiveCocoa本のMVVM
- Functional Reactive Programming on iOS
- HTTPリクエストの開始までVMが持つ
- RACSignal依存の設計になるので今のところ不採用
僕の考えるゆるいMVVM
Frilの商品VM
まとめ
- ReactiveCocoaの段階的な採用
- Validationでの仕様、delegateラッパー
- MVVMへの緩やかな移行
freee社でのReactiveCocoa活用例
freeeの@yo_wakaさんによる発表
freeeのiOSアプリ
- 確定申告や小規模法人決算をカンタンに
- 既にWeb版がある
- エンジニア2人で1ヶ月で開発
- ReactiveCocoaを採用
ReactiveCocoa採用の背景
- アプリを出して終了ではない
- 会計サービスはUIが複雑
- スタートアップで後から設計変更してる余裕ない
- 変更に強い設計が必要
- Viewの状態管理が複雑
- 複数のモデルを管理しないといけない
MVCの問題点
ReactiveCocoa
勉強し始めの頃
- GitHubのoctokit.objecがソースめっちゃ綺麗
- @ikehyoさんのQiita資料がまとまっている
Pros/Cons
- Pros
- 1つsignal設計すると使い回しがしやすい
- カテゴリ拡張がとにかく便利
- RACObserverサイコー
- Cons
- SubscriberやRACSignalのコードを理解するのが難しい
- RACが死ぬと我々も死ぬ
var RAC3 = ReactiveCocoa + Swift
ReactiveCocoaのコミッターである@ikesyoさんの発表。
New Concepts
- Generics Support
- ColdSignal
- Subscriber
- HotSignal
- ObservableProperty
- Action
Swift版のReactiveCocoaを組み込む方法
LT
CDEvents+ReactiveCocoa でファイル監視
@uasiさんによる発表。
ReactiveCocoa Pitfalls at freee
@yonekawaさんによる発表。
distinctUntilChangedの使いどころ
@at_akaさんによる発表。
Bolts-iOSを"ちょっと"駆使した非同期処理の例
@huinさんによる発表。
「nanapi勉強会 vol4」に参加してきました
nanapiさんとはてなさんが共同で主催された、開発フローや開発手法、継続的インテグレーションや継続的デリバリーなどDeveloper Productivityに関する勉強会、「nanapi勉強会 vol4 - 【nanapi x はてな】はてなとnanapiの開発フロー」に参加してきました。
オープニング
@wadapさんによる発表。
- 開催の経緯
- 来週京都でも近い内容でやる（はてなさんのオフィスで）
nanapi IGNITIONチームの開発フローとその構築 / nanapi
@vexus2さんによる発表。
自己紹介
- サーバサイドエンジニア
- PhpStorm Advent Calendarを24日分くらい書いた
- nanapiではnanapi、answer、IGNITIONをやっている
IGNITIONチームにおける開発フロー
- 社内外の起案でタスク発生
- スクラムでタスク化
- 開発
- リリース
スクラムについて
- 以前は物理カンバンに付箋でやっていた
- 物理カンバンを廃止を禁止した
- 付箋とIssuesとの二重管理に
- 物理看板の移動が面倒
- ログとして残せない
- PivotalTracker導入
基本はGitHub Flowに則る
- masterブランチは常にリリース可能に保つ
- masterへの取り込みはfeatureブランチからPull Request
- テストを書いてあるならリリースしてもOK
- CSSの細かい修正などはそのままリリースOK
- 型にまはりすぎない
デプロイ
- Pull Request経由で行う
- masterへのマージでCircleCIを介してAWSに自動デプロイ
- HubotでSlackに通知
- Hubot経由で手動デプロイも
CircleCIを選んだ理由
Jenkinsは使わない
- カスタマイズ性が高いがメンテコストも高い
- Jenkins職人が発生する
- チームでメンテし続けられるなら良いト
チームに最適なものを選択する
社内のエヴァンジェリストになる
現状に満足せず、モダンな環境を求め続ける
- アーリーアダプターである必要はないが、アーリーマジョリティーであるべき
PR
- エンジニア募集してます
- nanapod始めました
はてな Mackerel チームの開発フロー / はてな
Mackerelのチーフディレクターである@motemenさんによる発表。
Mackerelについて
なぜScalaを選んだのか
- Perlの次の言語
- 中規模開発に耐え、堅牢なもの
- リード開発者の趣味
- （本当はHaskellがよかった）
- 詳しくはScala in Perl Company参照
スクラムの導入
- スプリント開始時にタスクを入荷
- スプリント終了時に振り返り
- WEB+DBの特集でやりたいと思った
スプリントの開始：棚卸し会
タスクの検討
- 1Pull Requestにできるくらいの粒度にタスクを分割
スプリントの終了：振り返り会
- 金曜日の夕方１時間
- スプリントの達成度を振り返る
- 個人・チームのKPT
- 今後のスケジュールを確認
MackerelチームとScrum
- プロダクトもチームもゼロから
- やりたいことを着実に進めていく
- やりながら変化していった
タスクはGitHub Issue
- 1スプリント = 1マイルストーン
- はてなブログチームの開発フローとGitHubに詳しく書いてある
リモートワーク
PR
- はてな東京オフィスでリモートワークしたい人募集
開発フローパネルディスカッション
@vexus2さん, @wadapさん , @motemenさん, @songmuさんがご登壇。
以下、w:@wadapさん、 v: @vexus2さん、m: @motemenさん、s: @shiba_yu36さん。
w: 皆さん、自己紹介と自分のこだわりポイントを。
v：こだわりは早いものを重視すること。無駄なことを省きたい。私生活では自動化しきれてない。
m: こだわりは一人でつっぱしらない。みんなの様子をみる。意識をそろえる。
s: 1ヶ月前にはてなに入社。前職はソーシャルゲーム会社でリードエンジニア。35人チームでコミュニケーションに苦労したが、その中でスクラムや開発手法を学んだ。チームでの開発は最高に楽しいのでそれをブーストしたい。
w: 前職と違いは？
s: モチベーションが高くて、かっちりやってる。
w: 失敗経験をもとにこうなってるみたいな話をしたい。スクラムについてはどうですか？
m: スクラムでスプリント切ったら作業に集中できる。しかしスプリントを繋げることを考えてなかった。目の前のことをひたすらやっていて、どんなプロダクトにしたいかというマクロな視点が欠けてしまった。
w: 解決策は？
m: エンジニアとして楽しいからだけではなく、全体のプロダクトバックログを気にする。そういうことに対して意識的に時間をとる。
s: 自分の場合は、前職で大きいチームだったのでスクラムをそのまま適用するのが難しいと思った。エンジニアは新しいことをやりたがるが、それ以外がついてこれない。こちらがスクラムとか言ってもディレクター、デザイナーはピンとこない。Subversion、Redmineで満足してるのになぜ？そういうところをケアする。サポートする人を作る。
w: チームに編集長がいたvは？
v: 編集長はスクラム外。ディレクターは中にいた。コードを書かないがGitHubをコミュニケーションツールとして覚えてもらった。特に失敗はなかった。
w: nanapiは文化的にエンジニアがツールを決めて他の人に合わせてもらう。はてなさんは？
s: はてなもエンジニアが主導している。エンジニア以外の人も意外と技術に詳しい。node.js触ってたり。
w: お互いの会社ではいろんなプロダクトをやっている。サービス毎に開発手法を変えてるのかある程度決まったフォーマットがあるのか。
s: 前の会社もいろんなサービスをやっていたがリードエンジニアの裁量に任されていた。IRCでつながっているのでなんとなく把握している。毎週リードエンジニアが集まって共有会をしていた。
m: はてなでもSlackやIRCで流れてくる。リードエンジニアが集まる会もある。エンジニアの異動に伴ってツールが入ってきたりする。ブログチームが平均年齢が若くていろんなことを積極的に導入している。そこから引っ張ってる。
w: 会社共通のものはない？
s: GitHub使いましょう程度
w: vは？
v: nanapiはCakePHPでやってた。しかしIGNITIONではRailsを導入。CakePHPやRailsの知識の共有をどうするか。チャットだと流れてしまう。どうまとめるか。nanapiではナレッジをストックする場所を作っている。
w: はてなさんは？
m: はてなグループを使っている。ブログエントリーとして残している。それで情報が貯まっている。
w: 開発手法やツールは新しいのを導入して、固定化しすぎないのが重要。今気になってるものはありますか？
s: いいマイクが欲しい。リモートワークではそこが一番重要。長時間の会話だとノイズがストレスになってくる。リモートが強いチームを作ると思っている。
w: リモートワークには興味がある。マイクはアンサーで聞いてみたらいいのでは？
m: 自分はCircleCIを使ってみたい。今はJenkins。社内にあるからいいやとなっている。外部のものを使ってみたい。
w: Jenkinsおじさんがいる？
s: おじさん化する若者もいる
v: 自分はTaiga.io。プロジェクトマネージメントツール。バンダムチャートがかっこいい。
w: かっこいい？
v: かっこよさ重要。グラフィカルなツールだとテンション上がる。
w: さて、最後の質問。開発手法に正解はあると思いますか？
v: 王道はある。しかし王道に基づいているツールが最適解ではない。効率性を求めすぎてサービスが疎かになることは防ぎたい。
s: 開発手法はあくまで手段。最高のチームで最高の開発をしたい。 強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」』には自律的に働くことが書かれている。各々が自律的に働かなければいけない。それはOSSと似ていると思う。そういう開発をしたい。
今日のパネル、お互いが依存するのではなく自律的に動いて協調するチームのあり方が、(UNIX的な)ソフトウェアのきれいな設計にも近しい、みたいなことを言ったつもりだったけど、後から思うとちょっと違う受け取られ方をしそうだなとか思った #nanapi_study
— songmu (@songmu) 2014, 10月 2m: 手法はあくまで手法。チームが変われば手法も変わる。
質疑応答
皆さんは情報をどう集めていますか
v: はてぶ、RSSで情報を見ている。海外系のツールが多いので一次情報に触れられるように心がける。
m: はてぶを使ってます。お気に入りにいれておいて、その人がブックマークしたものをウォッチする。GitHubでもウォッチする。
s: はてぶ使ってます。RSSに出力してRSSリーダーで見るとか。naoyaさんなどホットな人を追いかける。OSS開発をやっているとツールに触れる機会が増える。
スマホアプリ開発とWebアプリの開発で違いについて
m: 隣のチームを見てると、プロトタイピング開発を行っている。画面作りがシビア。そこに注力している。
s: 前の会社でやっていた。慎重さがもとめられる。リリースサイクルが違う。サーバサイドのコードとクライアントサイドでリポジトリを分ける。そこでバージョンを合わせる必要がある。基本は変わらない。手法が確立されていない。テストが難しい。ロジックのテストはCIを回す。UIはわかっていない。
v: リリースに対する感覚が慎重になる。サーバサイドもクライアントも慎重になる。
海外でもリモートワークは可能か？通信速度や時差の問題は？
s: まだわからないが時差があるのは大変そう。レビューする時間を決めるなどを行っているらしい。まだ無理だとは思っていない。これから大変なことが起こるかも。
m:時差は大変。通信速度はあまり問題ではない。文字ベースなので。相手の顔が想像つかないと難しいかも。
v:リモートでやってる人。3人くらい。
今、5,6人のチームで開発を始めるところ。手法のとっかかりをどうするべきか。
s: 前の会社でスクラムでやろうというときにワークショップを受けた。みんながスクラムに対して前向きになる。まずは基本を抑える。テストの書き方を準備しておく。
m: 出来上がった場所がないと落ち着かない。リーダーが枠組みを先に決める。それから改善していく。
v: 最初にオーナー、リーダーが基盤を作る。方向性をメンバーに周知し、ブレないようにする。そこからブレークダウンしていく。
w: 自分はnanapiにスクラムを導入した。会社に周知しまくった。
どういうツールを入れたらいいか、時間も取りづらい
v: チームが不便に思っていることを考える。そこを自動化するツールを考える。時間をとるのは上司にコミットする。効果を明示する。
m: 仕事さぼってやればいい。それでみんなが良くなれば成功。CI回すくらいはやっておくといい。
s: Productivityはやってると楽しくなる。しかしすごく難しい。成長したWebサービスでも過去の負債に悩んでいるところはすごく多い。その状態をさらけだせるとこはさらけだして共有すればいいんじゃないか。オープンにしたら同じ悩みを抱えている会社は多いと思う。
「yidev 第１６回勉強会」に参加してきました
2014年9月27日(土)に開催されましたYokohama iPhone Developers 勉強会 第16回に参加してきました。
iOS界隈で著名な方々が集まる非常にハイレベルな勉強会でした。
Getting started with Handoff
2tchの中の人、『iOS SDK Hacks』の著者である@sonsonさんによる発表。
- Handoffでできること
- 必要要件
- UserInfoの中にオブジェクトを入れて、投げる
- NSUserActivityのインスタンスがスコープを外れると落ちる
- Streamを使えば大容量のファイルを通信可能
Custom Keyboard について
特殊文字の中の人である@haranicleさんによる発表
- Custom KeyboardはiOS8から導入されたApp Extensionの一つ
- システムキーボードの代わりに使用できる
- 機能
- NextKeyboardは絶対必要
- 他のキーボードに移れなくなるため
- ガイドラインではシステムキーボードみたいにしろって書かれている
- ホストアプリがカスタムキーボードの使用を拒否していたら使えない
- NextKeyboardは絶対必要
- UIInputViewControllerを使って実装していく
- 毎回initから呼ばれるので、initからviewDidAppearまでを出来る限り軽くすべき
- ボタンの表示はNextKeyboardボタンだけでも早く表示する
- StoryboardはUIInputViewControllerには使えない
- ハマりどころ
- シミュレータでキーボードが出ないときはToggleSoftwareKeyboardで出す
- コードでAutoLayout設定するのが大変
- その他
- viewDidAppear以降のタイミングならキーボードの高さを買えられる
- Info.plistからネットワークへの接続や位置情報収集の設定が可能
- In-App Purchaseも設定可能
UIテストの決定版
@kitasukeによる発表
Uiテスト@yidev from Yusuke Kita
- UIテストツールの決定版などない
- UIテストの目的
- 思わぬところで起こるUI関連の不具合を防ぐ
- あまり変わらないなところをUIテストすべき
- チュートリアル見た見ないあたりはテストすればいい
- UI操作はほとんどできる
- カメラロールから写真選択ができなかった
- Accessibilityを使っているツール
- 対応する箇所を埋めていく
- XCTestを継承しているのでほぼ一緒
- 全画面遷移のスクリーンショットを保存可能
- しかし画像をいちいち見てられない
- ImageMagickのmontageコマンドを使えばタイル状にできる
- ImageMagickのcompositeコマンドを使えば画像のdiffが取れる
- Travis CIでそのテストも可能
- UIテストの利点・欠点
- 良い点：運用コストが下がる
- 悪い点：UI実装者とテストケース実装者が異なる
スクショから始まるデバッグについて
@dealforestさんによる発表。
- シミュレーションでのデバッグは容易だが、AppStoreからインストールされたアプリでのデバッグが非常に困難
- アプリを配布した後は、print debugやbreak pointがほぼ不可能
- 情報が少なくてもバグが再現できればよい
- できることはあるにはある
- Crash Reportの収集
- Clashlitics、Bugsnagなど
- クラッシュしないとでてこない
- NSError、NSExceptionの収集
- スクショをとって共有
- その他
- Helpshiftとかでユーザからの問い合わせ
- レビューを見る、エゴサーチ
- Crash Reportの収集
- ユーザからこんなバグがあったとスクショが送られてきたとする
- スクショからバグを推測するのがたいへん
- デバッグに必要な情報が欲しい
- 画像としてそういう情報を出力すればいいじゃない
- DFTDebugScreenshotを作った
- スクリーンショットにオブジェクトを出力できる
- 考えられる応用
- AutoLayoutでConstraintsで出力できる
- UIWebViewでjsの情報を出力できる
- 今後
- UIViewControllerのdebugObjectをいつでも取得できるようなinterfaceを追加するつもり
- colorizeして画像にするつもり
- AccessTokenやcokieを出力したとき用に暗号化
SpriteKit ゲームを Swift で書いてみる
『Xcode5完全攻略』著者である@studioshinによる発表。
- WWDC行ってきた
- Swift登場した
- 忙しくて手が回せていなかったがキャッチアップした
- 著書に収録しているObjective-Cで書いたシューティングゲームをSwiftで書き直した
- ほとんど1対1で書いていける
- アクションもほぼ対でかける
- asを書くキャストが慣れない
- !、?のオプショナルが必須になり、そこでエラーがよくでる
- オプショナル大変
ドメイン駆動開発 入門編
cocominapさんによる発表。
「API Meetup Tokyo #3」に参加してきました
2014年9月26日(金)に開催されましたAPI Meetup Tokyo #3に参加してきました。
本勉強会はApigeeさんが主催するもので、Web API に携わる開発・企画担当者が、API まわりの様々な要素技術や適用事例を一緒に学ぶオープンな勉強会であり、今回はその3回目となります。
ヌーラボサービスにおけるAPI設計・運用のこれまでとこれから
最初は、株式会社ヌーラボ テクノロジー・エバンジェリスト 染田 貴志さん(@tksmd)の発表
API Meetup #1、#2の振り返りとAPIの概観から、ヌーラボにおける実際のAPI設計・運用のお話をして頂きました。
- なぜ今APIなのか
- APIエコシステム
- ヌーラボの事例1 - APIの世代交代
- Backlogでは2007年からAPIv1を提供していた
- 2014にv2を提供開始
- 移行ポリシー
- v1は廃止しないが新機能追加もせず、新規ユーザにはv2を推奨し、機能要望もv2のみ受け付ける
- アーキテクチャ
- ヌーラボの事例2 - エディタ機能の外部提供のアプローチ
- ヌーラボの事例3 - APIを核にしたサービス設計と実装
- APIのこれから
- 以前からYahoo! Pipesのようなマッシュアップツールがあった
- しかし最近はIFTTTの登場など、開発者以外でも手軽にAPIを組み合わせて価値を創造することができる
- APIそのものはサービスと同等の提供価値に
古すぎず新しすぎない技術をキャッチアップし続け、また既存のサービスがレガシーになり始めたら積極的に改善を行っている印象を受けました。
また、染田さんの発表も非常に分かりやすく丁寧で、APIそのものを取り巻く環境の変化を咀嚼することができました。
WebRTCにより可視化されるリアルタイムクラウド。求められるAPI
続いて、NTTコミュニケーションズ株式会社 小松 健作さん(@komasshu)の発表
カエルの格好で登場。 WebRTCの紹介と、そこから見えてくるAPIの潮流についてお話いただきました。
- 本当のWeb革命は、僕たちが自分たちのためにものを製造し、それを他の人も利用できるようになったことである（クリス・アンダーソン）
- APIの変遷
- 2004年からHTML5によってWebが大きく変わっている
- WebRTCを用いた事例
- ロボットのテレプレゼンス応用
- WebRTCでロボットを制御し、ロボットについてるカメラからリアルタイムで映像を取得できる
- ロボットのテレプレゼンス応用
- NTTコミュニケーションズさんのSkyWayを用いると、WebRTCによるビデオチャットシステムを簡単に構築できる
- 現在オープンβで利用可能
- 他にもNTTコミュニケーションズでは色んなAPIを提供しています
WebRTCで非常に有名な小松さんの発表を聞くことができ、非常に嬉しかったです。
自前でゼロからWebRTCによるテレプレゼンスを構築しようとすると非常に大変ではあるが、SkyWayのようなシステムを導入することで開発者は簡単にWebRTCを利用でき、それを用いた価値を提供できる。 そのような世界がついそこまで広がっている。
会議以外での応用も十分期待できると感じられました。
「Gunosyの急成長を支えた技術チームの取り組み実例を大公開！」に参加してきました
2014/09/24(水)にGunosyさんが主催するイベント、Gunosyの急成長を支えた技術チームの取り組み実例を大公開！に参加してきました。
1年で1台->100台まで増やした話
最初は、CTO 石橋雅和さんの発表。
1年で急激な成長を遂げたGunosyのインフラをどう支えていったかというお話でした。
変化していくユーザを検知し改善を行う分析基盤の話
続いて、吉田宏司さんの発表
DAUチームというのは、ユーザのリテンションに責任を持っているということで、この組織名がついているのだとか。
- 「数字は神より正しい」という方針のもと、開発を行っている
- 「迷ったら挑戦しよう」でどんどん進める
- 改善案は新規ユーザに対してテストする
- 既存ユーザだとバイアスがかかっているので効果が判定しづらい
- 新規ユーザの定着率を見る
- 人力でもいいからレコメンドロジックを組む
フルスクラッチで書いたアドサーバの開発運用史
続いて、印南聡志さんの発表
Gunosyの広告に関するお話。
- 広告による収益の最大化 → 良い広告を大量に配信する
- とにかくクリックされやすい広告を出す（第一の罠）
- ユーザはストレスを感じ、広告主はコンバージョンの低さに不満
- ユーザ、メディア、広告主の三者の利益を最大化するような広告を心がける
- 広告を大量に配信するためにサーバを横に並べる（第二の罠）
- レイテンシ増大
- たとえキャッシュでも1箇所を参照するような構成にしない
Gunosyを支える技術
最後は、執行役員 松本勇気さんの発表
推薦アルゴリズムとアド以外の全ての開発に責任を持っている部隊のお話。
- APIサーバにおける負荷対策
- インフラ管理
- ChefとOpsworksで管理
- AWSコンソールからポチポチクリックするだけで構成を作れるよう設計
- 海外向けは攻めた構成になっている
- Dockerを本番で使った経験あり（すぐに下げた）
- フロントエンド開発
全体的な印象として、積極的に改善を行っていき、常により良いものに変更し続けている姿が印象的でした。 また、非常に若い方が多く、その方々がどんどん経験を積みながら第一線で活躍しておられ、非常に感銘を受けました。
