My External Storage

ソフトウェアエンジニア向けTips。Qiitaにもメモ

Developers Summit2014[13-A-6] Mobageを支えるテストエンジニアリング

[13-A-6] Mobageを支えるテストエンジニアリング

Mobage Open Platformについて

Mobageでゲームを公開できる仕組み。 複数デバイスに対応

  • Feature Phone
  • Smartphone
  • PC

2009年夏にスタート。国内プラットフォームとしては、
ガラケーからY!、スマホMixiなどに対応していった。

SWETグループを作った背景

立ち上げ背景

  • プラットフォームのグローバル展開
  • 大規模システムの拡張とリファクタリング
  • デリバリーのスピードを落とさない。
  • 懸賞属人性の解消

日本と同じ品質を提供、かつ大規模システムとしてのリファクタリングが必要。
当時はテスターに属人化していた。一人のテスターの勤怠にリリースが左右される状態。

立ち上げの方針

  • End to Endテストを確立する
  • 徹底的なテスト自動化
  • テストしやすい環境を提供する

テストしやすい環境

  • 単体テストのREDが消えない問題
  • リリース頻度・速度・影響範囲のバランス
  • テスト時間のコスト問題
  • CIの必要性

割り切りや、時間的制約に直面することがあり、CIの必要性を痛感していた。

立ち上げ

当初はQAチームとして3人。2年間で16人で仕事。

なぜ独立したチームなのか?
→横串チームによる「戦略的横展開」を狙う。

SWETって何?

SoftWare Engineer Testの略。SETのDeNa版。

SETの役割

テスタビリティに特化した開発者の役割。レビューもする。テストに適したリファクタリングも行う。
テストエンジニアの役割ではない。テストエンジニアはテストの分析。
実行推進。自動化など。

SETは開発者にフォーカスしている。個々の機能を見たり、開発者がテストしやすい環境を作る。
DeveloperProductivityにフォーカスしている。

SWET = SET + TE

DeveloperProductivityも。Quality Assuranceを両立したい!

Mission Statement

  • Keep the quality of platform
  • improve the quality and prodauctivity of platform

あくまでエンジニア。
テスト対象を開発することができる。テスターではなく、テストエンジニアであること。

SWETグループって何やってるの?

サーバサイドのテスト
クライアントのテスト

全方位的なテストをしても無尽蔵なテストが必要になるだけ。
テストの分類などをして有効なテストを考える。

Who

デブテストなのか受け入れテストなのか

Which

システムテストなのか、ユニットテストなのか

How

ブラックボックス・ホワイトボックス・グレイボックステスト

What

機能テスト、非機能テスト。

RESfulAPI(WebAPI) Mobage Developers(webアプリ)

mbga.jp Proxy serverモバイルウェブ
Mobage SDK (クライアント)

直接開発社、ユーザーにふれる外部インターフェースのテストを重視。

WebAPIに対するテスト

HTTP.JSONレスポンス、UIなしが条件。
同じセグメントの中にテストクライアントを置く。テストクライアントからDBやキャッシュの中も参照、編集できる。
ブラックボックス的に内部的な情報にアクセスしない。
ホワイトボックス的にE2Eではない。
グレイボックス!ホワイトボックス的な操作をしながらブラックボックステストを行う
事前条件として、キャッシュ情報やDBの状態を操作しておく。

特定の機能、Mdに対するテスト、ドメインに特化したクライアントを作成してテストを行う。

メッセージダンピングを行なって、レスポンシブなテストも行う。

WebApp/MobileWebに対するテスト

HTTP送信、HTTPレスポンス、ブラウザ上でのテスト。
SeleniumWebDriverを利用して、RSpec、headLessBrowserを利用。

エミュレーターとブラウザを使いわけしながらテストしている。
ブラウザはHTTPヘッターにタッチできない。エミュレータJavaScriptを解釈できない。

DomainSpecificClientとしてモバゲーブラウザを利用している。Page Object Paternは使っていない。

Client SDKのテスト

アプリ実際に作ってSDKを叩いみてテスト

UI Auth 複数デバイスでも共通のテストケースを流せるように。carabashなどを利用している。

Developers Summit2014[13-A-5] 成功と失敗の狭間に横たわる2つのマネジメント

[13-A-5] 成功と失敗の狭間に横たわる2つのマネジメント

フリーランスアジャイル導入。チームビルディング。認定スクラムマスター。DevLove関西所属

なぜ自分がここにいるのか

去年のDevSumiで来年の公募に応募してみようとAction!してみた。そしたら登壇できた!

自分のコンテキスト

マネージメントとは 自分としては「特定の誰かだけでなく、全員が何らかのマネジメントに関わる」のが大事。

背景

正解がわからない。。。意思決定が遅れると置いていけぼりになる。

タスクではなく、課題発見をするところが大事になる。

偉い人が全ての課題を知っているわけではない。 経験が邪魔になることも。。。

もっとうまく出来る方法も必要ではないのか?

品質・タスク・リスク。マネジメントには多くの種類がある。 今回はヒューマンマネージメントの2つに焦点をあてる。

期待マネジメント

関係者が互いに持っている期待を明らかにし、適切に調整する。

「ここまでやってくれるはず」

それってお互い話し合っている? ソレっておお互い同じ思い? ソレっておお互い確認している?

認識違いは防げるはず。

ドラッカー風エクササイズ

  • 自分は何が得意か
    • プログラミングなどにかぎらず、積極性などの自分の武器
    • 得意なもの浮かばないならプロフェッショナルとして何かみつけよう!
  • どうやって貢献するのか
    • プロジェクトやサービスに対してどう貢献するのか。具体的に。「テストの◯◯で貢献する」
    • これは必然的にゴールを理解している必要がある。
  • 自分が大切にする価値観とは何か?
    • 家族、お金、キャリア、綺麗なコードなどのこだわり。
  • チームメンバに何を期待するのか
    • お互いの期待を表明してすり合わせる
    • 野球の場合。ホームラン打ってほしい?キャプテンとして指揮してほしい?

誰とすり合わせるのか→関係者全員。 一度やればOKなのか→ずっと期待が同じではない。定期的に確認しないと期待は変わっていく。

事例1 顧客との期待マネジメント

工場稼働の絶対納期

前提として過去の仕事経験より信頼があった。

良い意味でお互い線を引いた。「ここはやる。ここは出来ない、苦手」と線を引いた。 相手の立場を考える

事例2 上司との期待マネジメント

同じ会社だと、シンプルな期待でやる。ひとつ期待を決める。 チーム内に自分の価値を説明した。 やっていることではなく、どう貢献できるか? 「自動化の推進をします」→「このプロジェクトにこういうインパクトを与える」まで深堀り

事例3 組織との期待マネジメント

「言わなくてもわかってくれる」はない。 ちょっと離れた上司、顧客にはわからない。アクションだけでは伝わらない。 実際に結果として何が変わったのか。を説明できないと。

モチベーションマネジメント

関係者のやる気(士気)を安定して目標に向かわせる。

モチベーションは何気ない一言で乱高下する。 そして人によってその鍵穴は違う。ボーナス?業務内容? 他人がそのカギを持っているものではない。

他人は手助け。モチベーションマネジメントするのは自分自身。

成長しやすい土壌を作るには

自分たちのモチベーションをどうやって上げていくのか。

無理なときは諦める。自分の調子と相談

日によってパフォーマンスは違う。ただし良いプレイヤーは不調な時期が短い。

褒めるのではなく一緒に喜ぶ

褒めるというのは上から目線。一緒に喜ぶ視線が大事。(子育てより)

その先にある光景を一緒に見に行く、語る

否定形の話ではなく、超えた先にある喜びを一緒に語る。

物事に対して共感できている?

共感できていないと目標があっていない可能性。 メンバも話しづらくなる。

サーバントリーダーシップ

事例

若手のチームで頻繁に振り返り。Good!を出しまくった。 個人に対してフィードバックをする。プロジェクトに対して貢献していることをフィードバックする。 シンプルな承認欲求を満たして上げる。

今は成功体験が少ない。歯車の一部になると、顧客の声も聞こえない。 プロジェクトからの声もなかなか聞こえない。 まずは打席に数多く立つことが大事。一緒に打席にたつ。

指示待ちだった。 上からの命令ばかりで指示待ちのチームになっていた。 「自分たちでやることを考える」 習慣を変えると。。。プロジェクトの「why」を知ることになる。 「how」や「what」しか知らないとモチベーションや目標がうまく定まらない。 前のめりの失敗は不問とすることを上司と掛け合い、チームに安心感を。

まずは少しだけやってみる。二週間だけやってみるとか。 「私が提出用に旧来の方法をやるので、みなさんは新しいほうを使ってみてください。」 そうすると。。。「もっと続けてみよう」とかいう気持ちも出てくる。 自分たちで改善するクセがついてくる。 (3ヶ月位かかるけどね!)

お客の顔が見えない 紙とハンコしか無い。チームとしてうまく行っても別要件で結局無駄になる。。 組織の外にロールモデルを求めても良い。 ヤバい人に触れ合ってみる。

まとめ

期待マネジメント 人にはっきりと表明するのは難しい。言われたこともなかなかないと思う。 コミットする覚悟があるのか?

目標に向かうようにする。 各人で鍵穴は違う。それぞれにあった最適なカギをみつける。

周囲への期待を明らかにしてみてください。 周囲からの期待を明らかにしてみてください。 飲み会とかじゃなくて真剣にね! 驚くギャップがあるはず。それをすり合わせることでプロジェクトはうまくいくはず

自分を含めたメンバーそれぞれのモチベーションの源泉を考えてみてください。

Developers Summit2014[13-B-3] 社内システムの構造と設計、実装の話

[13-B-3] 社内システムの構造と設計、実装の話

開発支援Gに所属。サービス提供、分析など社内サービス全般。
livedoor BlogなどLINE以外も幅広くサービス提供

Dev of Ops,by Ops, for Ops.

アジェンダ

  • 社内システムほど他システムとの連携を考えよう。
  • 社内システムはJSON APIを使おう。 

Web2.0 マッシュアップ全盛期

OAuth流行で支配的に(認証を連携して「来ました」とかツイートしたりとか)
しかし、WebAPIの制限が多くなってきている。プログラムからのCall制限などもあった。
オープンなWebAPIではトラフィック、レスポンスタイムが重要になる。
そしてその大規模サービスのバックエンドサービスとなった場合、誰がコストを払うのか?
互換性も依存先にAPIに変更が入ると困る。公開元が納得できなくてAPI変更することも。。。ていうかみなさんしますよね!

では社内システムは

だいたいが社内イントラネットを利用したClosed Webシステム。
機能>性能。有限社員なので、性能が問題になることはない。
社内システムは長生きする。欠点はわかっているが、放置されがち。
社内システムなので、ターゲットユーザーはまず自分自身。自分が使う。
人事システムだったら、人事が設計するが、結局はヘビーユーザーは勤怠を入力する人である。
そして、機能は多岐にわたる。

では何が問題なのか?

情報と権限の分断

情報を入力・管理する人と、情報の権限を持っているが異なっている。(認証とか人事情報とか)

情報と機能の冗長化

社員名簿が何種類もあったり、同期が遅かったり、パスワードが一元化されてなかったり

UXの欠如

インターフェースがクソ!

自動化の障壁

既存のシステムの古い部分が壁となる。(いちいち認証したりとか)

全部入り:アップデート不可能

IE8しか動かないとか!!

解決策としてはDBを直接編集、SOAPCOBRASOAなどあったが。。。
RPCプロトコルも社内というよりも、大規模サービルに対する方法。

社内システム連携:Make it simple!

権限:分断を最小限に

閲覧権限にどれだけ階層があるのか?参照に関してフラットにしていけばよい(大企業はべつだろうが)

機能:情報には複数の参照方法を

例えばブラウザで見る。WebシステムならばAPIが必ずあるはず。
参照元が公開APIを叩く仕組みになっていれば、WebUIとデータが結びつくことはない。

モジュール化:単機能システムを連携させる。アップデートが容易な状態を保つ

オブジェクト志向のようなもの。無意識な巨大化はメンテが不可能になる。

社内システムほど他システムとの連携を考えよう。機能をAPIとして公開しよう

最初からAPIとして作成しておけば、インターフェースだけみて連携操作ができる。自動化などができる。
APIを守っていれば、他のシステムとの連携に不備なくアップデートができる。保守性があがる。

トラフィック、レスポンスタイム

なかなか無いので、割愛。

コスト

会社が払うので割愛。

互換性

疎結合で小さいビューならば変更が容易。ひとつのビューに複数の機能がマージされているとひとつの変更が大きく影響をおよぼす

API互換性

プロトコル、データ構造、意味の一貫性、クライアント要件の不変性/普遍性
ドキュメントに頼ると長生きシステムなので、腐敗化していく。

プロトコルクロースドウェブAPI

HHTPプロトコルならば、浸透しているし、しばらくなくならないだろう。
データの書式はどうするのか?JSONが一番いいんじゃないのか。

長期運用

データの所在や管理情報の一番安全な管理方法はベタに自分で確認できること。ドキュメントは陳腐化する
個人的な感覚だとJSONの書式がベストなのでは。XMLとかは見た目がわかりにくい。

きちんとしてアップデート、容易さ、データ内容の把握

移行時にどう確認するのか。

テストの容易さ

コマンドラインから直接手で容易に確認できるデータ形式はあまりない。
RESTなどならわかりやすい。

百聞は一見にしかず

  • 1 time curl >>> 100 pages docs
  • ease to try >>> performance
  • losely coupled >>> strict protocol(疎結合の重要性)

社内システムではJSON APIを使おう

社内システムの実装

社内システムは動くことが大事。
ドキュメントよりはわかりやすい動作のほうが大事。
利益がないので「こんなこともあろうかと」はいらない。
利用率調査をするだけでもマイナスになる。

社内案件なので、優先度ハックが可能。
自分たちで優先度を考えることができる。
機能を切り刻むことができる。
修正単位を最小化する。
切り刻まれた機能追加のタスクを個別に片付けることで、柔軟な開発、後回しにすることもできる。

JSONならあとでDB叩けばできるはず。それならば、あとでも対応できる。
ただ、後回しにできるものは結局不要なことが多い。。。

必要なものを必要なときにだけ作ればいいのではないか

アーキテクチャを割り切ることで開発・運用を加速する。

いつでもだれでも使えるAPI,細分化されたタスクのほうが、多少見栄えが悪くても運用効率はよい。
開発・運用の前提がアーキテクチャをシンプルにする。

ビジネスへのインパクトとしては社内システムほど試しやすい場はないので、実験には最適である。

まとめ

まず自らの環境でシンプルなものを試す、自分たちが使いやすいものをつくる。
開発・運用の前提が、アーキテクチャをシンプルにする。


Developers Summit2014# [13-A-L] ビジネスアプリケーションにとつながる「Heroku1」のご紹介

[13-A-L] ビジネスアプリケーションにとつながる「Heroku1」のご紹介

Heroku提供のお弁当はマイセン。。。これだけで懐柔されてしまう。

日本HerokuはまつもとさんなどRubyコミッタ5名で活動している。 国別利用者で日本は3位。 2007年にスタートアップとして企業、2011年にSalesForceに買収された。 HerokuはSalesForceのプラットフォームも担っている。 Heroku1の構成コンポーネントはForrce.com CLI

Force.com CLI

セールスフォースは開発社用の環境を無料で提供している。 開発をGUIベースでできる。 その代わりターミナルで開発するような開発者にはあまり向いていない。 そのため、CUI開発者向けのAPIを作成した。

Force.com Client Library

特定の言語に依存しないようなフレームワーク利用者が多い。 Heroku上の開発者とForce.com上の開発者の間にスタイルが違う。 その間を埋めるライブラリがクライアントライブラリ。

Rubyだったら、dotenvというgemファイルを作成しておけば、Forceインスタンスを作成し、セールスフォースにCUIでアクセスすることができる。

Heroku Connect

Heroku PostgresとForce.comのデータコネクタ 14年7月までにリリース予定の機能。

  • 非同期連携
  • カスタムオブジェクト対応
  • カスタムデータ対応
  • 双方向・一方向のデータ同期をノンプログラミングで実現

Heroku Connectが出荷された暁には、Herokuはよりスケーラブルな開発が出来、ビジネスデータとしてForce.comに取り込める。

デモ

Heroku Postgresにセールスフォースのデータを取り込む。 ブラウザ上の操作で、ノンプログラミング!

Developers Summit2014[13-B-2] グリーにおけるChef導入事例 〜既存の資産を活かし新しい技術を導入する〜

[13-B-2] グリーにおけるChef導入事例 〜既存の資産を活かし新しい技術を導入する〜

荒井良

Chefとはなにか

  • サーバ構築・設定更新を自動化するツール
  • あるべき姿をRubyで記述しておくと、その姿にセットアップしてくれる
  • 重要な特徴として、冪等性(何度実行しても同じ)が挙げられる

導入背景

よくある光景

プロダクト担当者は運用担当者が手動で用意するサーバを利用するしかなかった。
手順書があるならばルーチンワークである→非効率。自動化したい

  • 非効率を自動化して効率化
  • オペレーションミスの危険を減らし、安定運用を目指す。
  • サーバのデリバリを素早く行うことでリードタイムを得る。

導入前

  • Debianパッケージ(役割ごとにメタパッケージ)
  • 設定ファイルはスクリプトで生成
  • 設定値についてはパッケージ内にあるもの、サーバ管理システムに問い合わせ

Chefを導入するが、サーバ管理システムはそのまま利用したい。

サーバ管理システム

社内サーバ情報を管理しているシステム。サーバ名、データセンター、サーバの状態などを記録

導入方針

  • 新規のサーバをChefで構築していく
    • 構築済みサーバは状態不明なのでChefで更新するのは危険と判断
  • 既存のサーバもChefで並行運用する
  • 既存のツール・スクリプトが動く状態で移行する。

Chefサーバをやめた理由

  • 単一障害点になる
    • 冗長構成はサポートされていない(有償だとできる)
  • サーバ管理が重複する
    • Chef Serverはサーバ管理の役割を担う。
    • 既存のサーバ管理システムと役割が重複する
  • 運用
    • 多数のソフトウェアを使っている(結構ヘビー)
    • Erlangを使える人がいない。

Cheff Solo + αで運用をすることに

Cheff Solo + αの構成

ノード(構築対象サーバ)とサーバ管理システムを連携させる。
Chefサーバ代わりの内作Chef Bridge、ノード側にGREE Chef Clientを作成。
サーバ管理システム→Chef Bridge→GREE Chef Client(Chef Soloラッパー)という構成にした。

Chef Bridge

  • Railsアプリ
  • ノードの設定、クックブック、ロールを管理
  • HTTP API
    • 最小限
    • 読み取りのみ
  • サーバ管理システムへの問い合わせを行う

Chef Client

  • Soloのラッパー
  • Chef Bridgeから必要な物を取得
  • Chef Solo実行
  • 自動テスト

開発編

作る必要があるモノ

クックブック

  • オープンソースなクックブック
  • 非常に汎用的に作られている
    • 汎用的な結果複雑になりがち、使いこなすのは難しい
  • 異本的に自社でクックブックを作成している。

Chefは学習コストがタック、Chef使いを育てる必要がある。

Chef使いを育てる

クックブックの開発手順

テストを書く

なぜテストを書くのか
  • 開発を後押しする
    • TDD的な
  • リグレッションを防ぐ
  • ドキュメント代わり
    • 構築後の姿がわかりやすい
  • 本番サーバの構築テスト

問題1 Jenkinsに繋がらなくなった

原因:ネットワークのルーティングが変わった。。。VBのHostOnlyNetwork
VMだけのネットワークが作れたら。。。

問題2 Mutable Infrasturucture

ゼロからChefでセットアップしたサーバと同じ保証はない。
serverspecを本番用サーバにも実行している。

問題3 テストに時間が掛かる

  • 細かくテストを回さなくなる
  • テストケースを絞るようになる
  • デプロイに時間が掛かる

VMの準備はロールバックで対応。ただCheffの実行部分が一番時間がかかっているので、今後の課題。。。

Chefspec

Foodcritic

  • クックブックのLintツール
  • クックブックに統一感を持たせる

GitHub/Pull Req

  • 変更に対するテストをパスしていることを確認
  • プルリク上でレビュー

CI

Jenkins上でテスト、デプロイまで自動で実施。

ノードの属性

バリデーションすることで必要なノードの設定値を検証している。
共通化をして、共通部分を一箇所に賭けるようにしている。
ノード設定はYAMLで書くようにいしている

Github Push→Jenkins→Chef Bridge→cheff soloという運用フローができる。

障害対応

Chef実行時のログは自動でDB保存、CheffのReportHandlerを利用してFluentdに投げている。

Developers Summit2014 [13-B-1] サーバプロビジョニングのこれまでとこれから

[13-B-1] サーバプロビジョニングのこれまでとこれから

宮下剛輔氏

アプリケーションをのせるための、OS以上のレイヤーの話。

サーバプロビジョニングとは

Orchestration, Configuration, Bootstrappingという3レイヤーで考える。

  • Bootstrapping OSインストールを指すレイヤー。
  • Configuration ミドルウェアレイヤー
  • Orchestration システム全体をサービスとして動かすレイヤー。概念的に難しいので、このレイヤーおおざっぱな認識で良い

Bootstrapping

Bootはスコープ外なので今回は割愛

Configuration

このレイヤーをプロビジョニングと指すことが多い。Chef、Puppetなどの構成管理ツールを利用するのが最近の流れ。

Orchestration

広範囲を占めるので後述。

Infrastructure as Code

インフラ構成のコード化。2008年ほどからChefの製作者などが使い始めた。
源流は1993年登場のCFEngine。

CFEngineにより提唱された構成管理の要件

  • 宣言的 「何をするかを記述して、具体的なことは記述しない」
  • 抽象化 
  • 寡等性 「常に同じ結果が得られるか」
  • 収束化

ビジネスをぜロから再構築できるようにすることがInfra as Code
サーバ構築・運用におけるワークフローに変革をもたらすもの

テスト駆動インフラへ

コードで記述されることでアプリ開発と同じようにインフラ構築もできるようになった。

Chefがらみから流行ってきた。オライリーから書籍も出ていて、Test Kitchenというテスト・ツールも出てきた。

Chefが更に「コードでのインフラの記述」を推し進めた。
Chefは独自言語ではなくて、Rubyで記述できるのが大きい。
AmazonEC2などの台頭で簡単にインフラを構築、破棄できるようになった環境の影響も大きい。

みんながみんなChefを使っているわけではないので、SeverSpecを作った。JTF2013などの資料を見れば詳細が乗っている。

テスト駆動インフラが駆動するのはインフラそのものではなくインフラを記述したコードを書くことと捉えるのが重要!

よってリファクタリング対象はインフラの状態を記述したコードであってインフラそのものではない。
インフラの状況をテストするという解釈を宮下氏はしていない。インフラの状態を記述した「コード」をテストするためのツール

インフラCI

コード化、テスト自動化ときたら次はCIでしょ!

GitHub Flowによるインフラワークフロー

GitHubとCIツールを連携して表はレビュー、裏でテストを通す。Github上なので、テストやレビューをクリアできていれば、そのままマージ。

Immutable Infurastructure(Disposable Components)

ブログエントリがきっかけになって話題になったワード。
ImmutableよりもDisposableのほうが重要と考える。

動いているサーバには変更を加えない(Immutable)
→全く新しいサーバを構築してロードバランサ等で切り替える。
うまく切り替え成功したら元のサーバは「破棄」。失敗したら元のまま。
ロードバランサによる切り替えはimmutable...という言葉が出る前に存在した手法。(Blue-Green Devlopment)
EC2のようなIaaSによってこのような運用が容易に。

メリット 変更に伴うトラブルが起こりにくい。新規のサーバで1から構成するのでトラブルが起こりにくい。
メリット 継続的改善がしやすい。トラブルばかりだとビビるようになる。トラブルが発生しにくいので、変更しやすい。
設計への良い影響は「The Twelve-Factor App IX. Disposability」9章を参照すること。

メリット ChefやPuppetのようなツールがよりシンプルになる。
クリーンインストール前提の構築になるので、構成がシンプル、
もっと言えばシェルスクリプトでも十分になるかも

Immutableに出来ない部分(永続的なもの、画像ストレージ、データベース)はどうするか?
例としては、外部サービスに任せるとか!

コンテナベースデベロップメント

コンテナ?=単機能・軽量なVMと便宜上定義。
コンテナまるごとアップロードして差し替える。

Dockerの持つポータビリティにより実現可能性が高まった。
メリット ポータブルなので、ローカル環境と本番環境で同じに出来る。
ローカルで十分テストしたままそのままデプロイできる。

テスト駆動→CI→デプロイという流れができそう。

1コンテナ1機能と単純化し、組み合わせでサーバ構成。サーバ部品のコンポーネント化ができるのでは?
個別に差し替えやすくなり継続的改善に寄与。
単機能化するこtでテスタビリティも向上。オブジェクト志向的な。

IaaS上じゃなくても、Blue-GreenDeploymentができる。

Mesos/YARN等との組み合わせで自動的なリソース配置最適化もできる。

Orchestration

複数のサーバが関連するものと捉えるとわかりやすいかも?

  • ロードバランサにノードついか
  • MuninやNagiosへのノード追加
  • アプリケーショデプロイ

旧来のOrchestration

Immutable前提ではなかったので、サーバの増減が頻繁ではないので、
Configuration領域でもやれてしまう。Command & Controlとなる。

新しいOrchestration

はImmutable選定 サーバの増減が頻繁なので、Configuration領域での対応はキツイ。
Autonomy/自立協調となる。

Serfの登場

サーバが追加されたというイベントがロードバランサに通知される。クラスタリングと通知しかまだ機能はない。

Serfでやれること/やるべきことをOrchestrationと捉えるといいかも

これから

  • テスト駆動でインフラ構築
  • インフラCIで継続的インフラテスト
  • テストが通ったらコンテナをまるごとデプロイ
  • ...とはいえまだ課題はある

Reveal.js、Markdown、Githubでスライドを作成する。

PowerPoint2003から2013になってちょっと戸惑いを隠せない。。。
ありきたりなスライドテンプレートもなんか嫌だし。。。

と思っていたところ、markdownでWebスライドが作れることを発見しました。
GithubでWebページを公開する方法を発見、SublimeTextも入れたので、ちょっとWebスライドを作ってみます。

完成サンプル
http://budougumi0617.github.io/reveal.js-myMaster/

slide.png

作り方

Reveal.jsというJavaScriptライブラリを利用します。

  • GitHubからreveal.jsのプロジェクトzipをGET
  • index.htmlをテキストエディタで開く。
  • <div class="slides">タグ内の<section>内容を削除
  • 後述のオプション付き<section>を記載する
  • <section>内にMarkdownでゴリゴリ書く

これだけ!!


Markdown用のsection定義。

以下の<section>定義でmarkdownを使用してスライドが書けます。
もちろん、通常の<section>定義でHTMLを利用してスライドを作成することも可能です。
---を入れることで右に次のページを作成。
--を入れることで下に次のページを作成。

<section data-markdown
    data-separator="\n---\n$"
    data-vertical="\n--\n">
    <script type="text/template">
ここにmarkdownを記載していく。
    </script>
</sectin>

たとえコードタグ内でも、markdown記載中に</script>がでるとバグる点だけ気をつけてください。

Markdown記述部分を別ファイルにしておけばindex.htmlは使いまわすことも可能です。

<section data-markdown="./md/firstpage.md"
    data-separator="\n---\n$"
    data-vertical="\n--\n">
    <script type="text/template">
    </script>
</section>

編集後はGithubで公開

あとはGithubで新規のリポジトリ作成。
clone,init後にzipの中身を全てコピーして、gh-pagesブランチにpushすればGithub上にスライドが公開できます。
#今回コミットはSourceTreeで行なったので、コマンドログは割愛。


その他

<iframe>で埋め込みしたいときなどはおとなしくHTML使う必要があります。
その他Reveal.jsの詳細な使い方はGitHubREADME.mdを参照してください。

ちなみにブラウザでスライド確認中は、escoでスライドを一覧表示にできるのですが、
ViChrome使っていると競合して動かないので注意。
Ctrl + escでViChromeをエマージェンシーモードにしてからoで一覧表示ができます。


参考

今回は以下の情報を参考にさせていただきました!

本家のデモ
http://lab.hakim.se/reveal-js/#/

なんかかっこいいプレゼンテーションテンプレートを探しているならreveal.js使ってみろって
http://qiita.com/ryurock/items/9c6de36b9d6a716e7992

reveal.js+Markdown
http://qiita.com/siguremon/items/c717eca388070215712c

reveal.jsで格好いいプレゼンを作ってみた
http://d.hatena.ne.jp/zebevogue/20121110/1352521622