こんにちは、 chappie です。
先日、 Developers Summit 2014 に１日目(2/13)だけ参加したので、個人的な見聞録を共有します。当然、自分が参加したセッションに限定されてしまいますが、それぞれのメモ＋自分や自分のチームに照らしての感想などを綴ります。
(なお、感想・意見は私個人の見解で、社を代表するものではありません)
今回、参加したセッションは以下のとおりです。
今回、参加したセッションは以下のとおりです。
- 【13-A-1】クラウドがもたらした多様な破壊と創造
- 【13-A-L】ビジネスアプリケーションとつながる「Heroku1」のご紹介
- 【13-C-3】Smashing Android UI, Androidデザインの極意
- 【13-A-4】新卒エンジニア研修ですべきことできること
- 【13-C-5】これからのネイティブアプリにおけるOpenID Connectの活用
- 【13-A-6】Mobageを支えるテストエンジニアリング
- 【13-A-7】プレゼンテーション・パターン・ワークショップ
各セッションのスライド等へのリンクは CodeZine のサイトにまとめられているので、そちらも参照ください。
雅叙園はひな祭りモードでした
【13-A-1】クラウドがもたらした多様な破壊と創造
基調講演的な位置づけで、「破壊と創造」をテーマに、クラウドによって今起きている＆これからのトレンドを概観するものでした。
Publickey の新野さんのお話:
- クラウドが破壊するもの ＝ 従来型SI や オンプレミス・パッケージ (クライアントアプリ)など
- 創造するもの
- 新しいサービスモデル
- マルチデバイス、モバイル環境
- 活発なコミュニティ
- 新しいサービスモデルの例として、給食メニュー作成アプリを作ってるところが、クラウドのおかげで物理的制約から開放された＝サポートのために現地に行かなくてよくなったというのがわかりやすかったです。
Amazon Web Services の 玉川さんのお話:
- Amazon 創業者ベゾス曰く「(10年後何が変わっているかよりも)10年経っても変わらないもののほうが大事」(例: 安くいいものが早くほしい)
- そういった本質にしたがって、自分たち自身のサービスも破壊する(本が売れなくなっても電子書籍やる)
- AWS も同様
- 低価格・フレキシビリティ・イノベーションを追求
- AWS のイノベーション:
- AWS新サービス、2013年は 248 以上
- C3インスタンスは スパコン 64位
- RedShift : 従来の DWH は初期コスト数億円。使ってみないとわからないものに数億円つっこめない
- リアルタイム分析 Kinesis
- 新しい仕組みに気づいたものが新しいサービスを作る
- 例: S3に気づいてサービスはじめた DropBox
以下、エンプラ界とスタートアップ界からそれぞれ３社ずつ、それぞれの「破壊と創造」について。
ハンズラボ
- 「つまらないIT」＝ただの電子化、売上に貢献しない、高品質とかいっても人間がミスってるほうが多い (等々、従来SIへの愚痴を関西弁でまくしたてるｗ)
- SI → SD
- 情シスは自分で作る
- 単価で売らない、一発納品でなくずっとお客さんとつきあってやっていく
サーバーワークス
- 従来SI は 手紙と電話で比較されて、手紙のほうがいいでしょう、といって売られるものだった ＝ コスト安いから、というだけで、スピードが軽視されていた
- つくらない技術、SIだけどスケールする
- 無駄を計測する (例: データセンターに駆けつける時間 ＝ エンジニア時間 180時間 をクラウド化で削減)
- 営業・技術関係なく、全員AWSの資格とったりプレゼン練習する
コンカー
出張経費管理SaaS → プラットフォームとして統合された出張サポートサービスへ
- IT部門主導から業務部門主導へ
- データ、プロセス から、 ユーザ、モバイル へ シフト
- スピード
ウォンテッドリー
- 採用プロセスを変える: 中の人がみえる、会いにいける
- お金から共感へ
- 条件検索からつながりへ
コイニー
- 決済ルールを変える
- つなぐ、インターネット化する。モバイル、ペイメント、ハードウェア
- モノを作る以上に、既存のルールを作ってる人と話していくのが大変
- 日本には決済方法がたくさんあるが、それぞれ使ってる人が少ない
クラウドワークス
- 国や組織の枠を超えたオープンな取引、情報のやりとりが一般化
- 価格は製造原価で決まらなくなった
- スターバックスアイデア、ウォルマート、ボンカレー → ユーザ参加により共感を価格の源泉に
- ありがとうボタン
感想:
クラウドが世の中の仕組みを変えているというのはもはや改めて言うまでもないですが、ハンズラボさんなどが新しい形態の SI をビジネスとして展開しているのを見ると実際にエンプラ業界における SI も変わってきているのだなと感じたし、スタートアップ系をみると、ヒト・カネ・モノの動き方が多様化してきているのを改めて実感しました。
【13-A-L】ビジネスアプリケーションとつながる「Heroku1」のご紹介
ランチセッションのひとつ。(お弁当が出ること知らなかった。食べに行かなくてよかった)
- Force.com CLI
- Force.com は GUIベース、Heroku はコンソールベース
- Force.com CLI 使えば、コンソールベースで Force.com のオブジェクト操作できる
- Ruby, Node の クライアントモジュールもある
- Heroku Connect
- Heroku Postgres と Force.com のデータコネクタ。同期するオブジェクト、フィールドを指定し、データ同期をノンプログラミングで。
- Force.com 上のデータを Heroku アプリから使いやすく
- Heroku 側で DB の URL を設定、 schema 名指定できる。
- read only にすると salesforce 側のデータを読み込むのみ。
- まだリリースされておらず、同期タイミングなどをテスト＆調整中。
感想:
当然ながら、Salesforce.com との統合を進めている印象。データ同期が楽に出来ると、 Salesforce.com を中心に Herokuアプリを周辺に構築していくインセンティブが強くなるだろうなというのは、企業向けサービスを展開する同業としてはなんとなく実感できるところ。
おまけ: お弁当はまい泉のカツサンドでした！個人的にポイント高かったです
【13-C-3】Smashing Android UI, Androidデザインの極意
Android の UI デザインについて。
- AKQA 社 ＝ 広告系、 Kinect Training など。
- 2008 年に G1 が Android 系スマホとしてはじめて出て以来、 Android UI のデザイン系の書籍が今までなかった。
- UI Pattern とかブログで書いてる人の本が出て、和訳したとのこと。
1. スケーラブルレイアウト → レスポンシブ
- なぜレスポンシブ？ → 様々なサイズの端末の存在＝時計からテレビまで
- コンテンツの統合
- Fragment : でかい画面では複数画面要素
- CompoundView : 表示内容変える
- PCでは ３列表示、タブレットでは２列、スマホは１列
- スマホの場合: リストから → 新規作成 or 詳細 に飛ぶ
- タブレットの場合: リスト＆詳細を同時に表示、新規作成はオーバーレイで表示
- Action Bar でナビゲーション、 3 〜 4 階層でどこでも行けるようシンプルに
2. 繰り返し使えるルール → デザインパターン
- UIのデザインパターン → 構成要素の整理に。ただし、必ずしもそのままあてはめればいいというわけではない
- 書籍では 解決策と結果をパターンごとに解説している。
- 例: Action Bar
- 上部に表示するメニューバー。新しいフレームワークで簡単に実装できるようサポートされている。
- コンテキスト対応のアクション提供
- ロゴ(ユーザは基本的に操作しか注目しない、その中でブランディング実現する手段)
- Home/Up ボタン (Upアフォーダンス) (iPhone は「戻る」と 「Up」が混同されてる)
- ただし、 6inch が今年主流になりつつある現状だと片手でしんどい場合も。非表示にもできる。
- 基本操作のアイコンは 50〜60種くらい提供されている
- その他のパターン:
- Pull-to-refresh 引っ張り下げて更新
- Swipe-to-dismiss
- Dashboard はもう使われない
- アンチデザインパターン
- 見た目を ◯◯チックにしても操作性悪いとダメなのでやめましょう
- スプラッシュ画面(リソースくう)、チュートリアル画面(たどれるならいいけど、必ず通過するのはよくない)、確認用ウィンドウ
- Pure Android ＝ 純粋な Android 体験：他のプラットフォームのUI要素を模倣しない (圧倒的多数になじみあるなら例外)
- 迷う前にデザインパターンでやってみましょう
- ただし例外はある、
- けれど、なるべくアンチパターンは避けましょう
感想:
個人的にはスマホも UI デザインも専門外なので(しかも iPhone ユーザなので)、ある意味新鮮な気持ちで聞いてました。とはいえ、レスポンシブ＝マルチデバイスでの見せ方は Web アプリ作るだけでも意識せざるを得ないところなので、モバイルの世界で現状、何が標準とされているのか知るのは意味があったと思います。
【13-A-4】新卒エンジニア研修ですべきことできること
DeNA の新卒研修について。
- 「研修」のイメージ
- 情報浴びせて、後は現場で → 現場も負担増 → 研修のせいにされる。メンターの力量に依存。
- DeNA では今年度、未経験者の新卒も多かった
- 教えることは無限にあるし、かといって絞っても難しい (例: 未経験者にオブジェクト指向って…)
- 現場のニーズも変化 ＝ サーバサイドだけやってればいい時代じゃない、もっと成長を
- 研修自体の問題とは？
- 技術レベルが必要水準に達してない: いいから引き上げる(絶対防衛ライン)、現場のエンジニアが直、(教える)工夫に注力する、諦めない (うまくいかなくても来年に)
- 研修での知識が現場でいきない: 最新知識は流動的、絞って教えるのはギャンブル。現場固有の事情は排除して、基本的なことや理想を刷り込む
- 現場で教える時間ないから研修で: 勝手にに学ぶような習慣、問題認識能力、観察眼・応用力、斜め上に進まないように、「水準・本質・応用力」
- → 「自走できるエンジニア」を目指す
- 研修フェーズ
- 座学、企画、設計、実装
- 早抜け方式 (２ヶ月〜最長９月)
- 各フェーズでレビュー: 1回1時間、１：１、各フェーズ 5 - 7 step
- レビューで大事なこと: 正しく論破してあげる (納得させる)・つきはなさない、信頼関係につなげる、相手に合わせた指摘の仕方、レビューでの内容・できごとを記録 (重要)
- 進捗は個人差ばらばら: 早めに気づく → 成長促す手をうつ、強みのばして弱点克服
- 気づくために計測第一
- 進捗、レビュー、何気ない会話の内容、いいもの悪いもの含めすべて記録
- Perl の筆記テスト
- 記録からアクションをとり、経過をみる
- 改善を促す: 最初は自力で、ダメそうなら手助け (フォローアップ)
- フォローアップ
- 毎日 or 確実で 30分間の 1on1 ハマり解消、問題解決の手法トレーニング、議論のトレーニング(ex: アツくなる癖があるから冷静に議論する練習するとか)、成長促進のための徹底した振り返り → KPT
- KPT: Problem を自分ではよく分かってないので、解きほぐしてあげる、 Keep、Try をふやしていく。Keep 出ないときはなんでもいいから(通勤電車で座れたとかでいい)だすように→モチベーションアップ優先
- ひとりひとり丁寧に、講師が諦めたら彼らは路頭に迷うんだくらい、最終的に自信もてるように
- フォローアップの効果大: 問題を切り分けて対処できるように、間違ったアプローチだと気づいたとき、ちゃんと元に戻って軌道修正できるように
- 弱い面と向き合うのは辛いことなので、ひとりひとりに合わせて。無理強いしない
- 研修の結果
- 基本的な技術力、マインド向上は非常に役立ってる
- 本質的な知識 (ex: Perl だと自分で作らないといけない、他の言語のオブジェクト指向的な仕組みなどがなんのためにあるのかその後に理解できる)
- 組織の型よりも人にフォーカスしたほうが、人材の柔軟性を高めて組織にフィットしやすくする。変化に強い人材に。
- 参考:
- DeNA での Perl 研修について: 大規模 Perl 初心者研修を支える技術
感想:
とにかくフォローアップが大事だということ。毎日 1:1 で、一人ひとりに合わせて KPT を回してあげるというのは、アジャイルプロセスと同じ考え方。そしてプロセス以上に、教える側が諦めない、とことん付きやってやるという覚悟が必要なのだなと感じた。
翻って弊社ではこれまで、どちらかというと放任主義的な体制が強く、新卒(or フォローが必要な中途)のポテンシャルを必ずしも十分に引き出してあげられなかったケースが多々あったなと、自分も含めて反省。
とりあえず、フォローアップは身近なところで後輩へのフォローからはじめてみようと思った。
【13-C-5】これからのネイティブアプリにおけるOpenID Connectの活用
- スマホアプリで Facebook ログインを利用する場合 (利用サービス例: lyft) OAuth 2.0 implicit flow を利用することになる。
- アプリのバックエンドにサーバを持っている場合、トークン置き換え脆弱性を生じる可能性がある
- ＝ 中間アプリがサーバに違う人のトークンでリクエストして、情報取得できてしまう
- → Audience Restriction が必要
- → ID Token を利用しよう
- OpenID Connect での id_token パラメータ
- ヘッダー＆ペイロード(Base64 エンコードされた JSON)、署名 (HMAC-SHA256) で構成
- ヘッダー例 typ: "JWT" (「ジョット」と読むらしい), alg: SHA256
- ペイロード部: issuer ＝ トークンの発行者、audience ＝クライアント識別子、subject ＝ ユーザ識別子、nonce
- → issuer が audience のために subject を認証する
- → nonce でリプレイアタックに対策
- バックエンドサーバには トークンをなげず、ID Token を投げる
- HMAC だと共通鍵暗号方式なのでネイティブアプリで署名チェックする場合、秘密鍵をアプリに埋め込まないといけない
- → RSA など公開鍵暗号も利用可
- OpenID Connect
- OAuth2.0 の authorization code フロー or implicit フローに加え、クライアントIDがダイナミックに変わる方式も
- デバイスID で端末を認証？
- Bearer Tokens ＝ お金みたいなもの ＝ 持ってれば使える ＝ 漏れたらオワリ
- OAuth 1.0 は署名、OAuth 2.0 は SSL 前提に bearer token に。どっちもそれぞれ、認証に対しては欠点ある (そもそも認証のための仕組みではないので)
- 公開鍵暗号: 秘密鍵を渡さずに、公開鍵だけ渡して秘密鍵を持ってるデバイスを認証できる
- そもそも認証とは？＝ registration したものと、その後使うものが同一か証明できればよい
- → Self-Issued IdP を利用しよう
- Self-Issued IdP
- デバイス(たとえば iPhone)自体が IdP になる。ID Token ベース。 subject は公開鍵のハッシュ値、公開鍵自体を ID Token に含める、秘密鍵使って署名
- iOS: KeyChain で鍵のペア生成＆ストレージ : SecKeyWrapper
- 2014.02.25 OpenID Connect 仕様最終版へ (ついにドラフトじゃなくなる)
感想:
OAuth の implicit flow の脆弱性についてはブログ記事など読んでなんとなく分かった気になっていましたが、説明を聞いて理解が深まった気がします。ネイティブアプリを作る予定は個人的にはないですが、とりあえず OpenID Connect に則ってやっとけば大丈夫！というのをしっかり啓蒙されてきました。
【13-A-6】Mobageを支えるテストエンジニアリング
http://www.slideshare.net/masaki/test-engineering-on-mobage
Mobage でのテストエンジニアリングの組織体制と方法論について。
Mobage でのテストエンジニアリングの組織体制と方法論について。
QAチーム から SWETグループに発展してきた経緯
- Mobage Open Platform がグローバル展開しようとしていた頃の課題:
- 大規模システムの拡張とリファクタリング(エンドツーエンドのテストの仕組みはなかった)、デリバリーの速度を落とさない、検証属人性の解消 (優秀なテスター依存、その人がいないとリリースできない)
- 単体テストの RED が消えない、オールグリーンじゃなくてもリリースせざるをえない
- → エンドツーエンド、徹底的に自動化、テストしやすい環境 を目指す
- 独立したチームにして、ヨコ展開を狙う
SWET とは
- SET ＝ Software Engineer in Test , a QA job title。 Microsoft だと SDET。
- Google での定義
- - SET: testability にフォーカス、review designs、 refactor code
- - TE: puts testing first (自動テスト書く、結果を分析、実行する)
- SET と TE の違い？ SET は developer focus、個々の機能の品質、開発者がテストしやすいように。 Developer Productivity に責任
- DeNA での定義
- SWET = SET + TE (Dev Productivity & QA)
- 品質維持＆品質と生産性の向上
- あくまで Engineer。いざとなれば対象プロダクトも変える
何をやってるのか
Test Classification に沿っていうと:
- Who, Which: Test Levels → UT or Integration Test
- How : Test Design (設計技法) → Black or white or gray box test
- What: Test types → Functional or Non-functional
Targets (テスト対象 ＝ エンドツーエンドを主眼としているので、ユーザ接点で分類):
- Web API
- Web App
- Mobile Web
- Client SDK
- A) 対 Web API
- Gray Box = API の口だけでなく、 DB/Cache も直接参照・操作する、 MyDNS や inet_aton エミュレートして特定対象に限定
- API クライアントライブラリを作って、テスト内容に集中できるように
- メッセージダンピング
- B) 対 Web App
- Selenium WebDriver (Ruby, RSpec, Capybara)
- 高速化のためヘッドレスブラウザ。ブラウザとヘッドレスの動的スイッチ(かたや HTTPヘッダさわれない、かたやJS 動かない)
- クライアントとして "mobage-browser"
- Page Object Pattern は使ってない(やり過ぎだと思っている)。 "Domain Agent Pattern" とでも呼ぶべきもの
- 対 Mobile: エミュレータから実機にシフト、 Appium など
- C) 対 SDK
- 実際にアプリを作る
- テストケース一貫性: Calabash、 Appium
- Cucumber は好きじゃないので Calabash やめたいらしい
Example:
- Domain Specific Client をシナリオ内で使い分ける
- → ゲーム側は API クライアント mobage-api-cient を利用、ユーザはブラウザ mobage-browser を利用
感想:
Selenium を利用した Web に対するテストで、 Page Object Pattern は使ってない、という点に少し驚いた。 Page Object にするとテストケースで指定するものが細かすぎるから、もう一段階、ラップして使うのがよいということだろうか。これから自分のプロジェクトでも同じようなものを導入していこうと考えているところなので、Web クライアントと API クライアントを同じシナリオ内で使うという視点は参考になった。
欲を言えば、後半の具体的なテスト方法について、特に Domain Sepecific Client の具体的な振る舞いについて、もう少し詳しく聞きたかったです。
欲を言えば、後半の具体的なテスト方法について、特に Domain Sepecific Client の具体的な振る舞いについて、もう少し詳しく聞きたかったです。
【13-A-7】プレゼンテーション・パターン・ワークショップ
パターン・ランゲージでプレゼンテーション技法を学ぶ、聴講者参加型のワークショップ。
これからのプレゼン
- 過去: Consumptive Society (消費社会)
- 現在: Communicative Society (コミュニケーション、情報)
- 未来: Creative Society (創造社会)
- 個人のアイデア、もの作りが社会変えていく時代。いろんな分野でオープンソース的な動きがでてくる
- 20年前は 自宅でパソコン操るのが特別なことのように新聞に載る時代
- これから20年でまた大きく変わる、工場で作ったものをみんな買ってた時代なんてあったの？と振り返るくらいになる可能性がある
- 情報の伝達・取得 (TV、新聞) → 発信・交流(パソコン、パワポでプレゼン) → 創造の誘発
- プレゼンは、正確・わかりやすいを超えて、刺激を与えるものへ。(例: TED)。
ワークショップ
実際に、自分が経験のあるパターンを伝える＆取り入れたいパターンを経験者に聞いてみるワークショップ。シートにリストされたパターンにそれぞれ印をつけて、お互いのシートを見ながら参加者同士で会話しました。
今後への指針
- 自分の今までやってることを土台に、他人のことを取り入れて少しずつ増強していく
- 「認識のメガネ」プレゼンを見る目が変わる。パターンで認識でき、分析できる。TEDなどを見て終わりにせず、自分ならどうするか
- 自分なりのプレパタを！ (例: 関西では「客をいじる」パターンが!)
- 他の分野にもパターン・ランゲージ展開中 (例: Survival Pattern ＝ 防災・減災パターン。家具を支えようとしない、など)
感想:
ワークショップのように能動的なセッションはやはり脳が活性化します。初対面のヒトと話すのは苦手ですが、ワークショップのフレームも良くてなんとかできました。話した人の中にはエステ経営してる方などもいて、ちょっと他のセッションとは毛色が違っていた点も刺激になりました。
対象はプレゼンテーションのパターンでしたが、いわゆるプレゼンだけでなく、開発レビューなど何かしら報告・発表する場には広く応用できそうです。
