kakakakakku blog

Weekly Tech Blog: Keep on Learning!

The Go Blog : JSON and Go を読んだ

今さらながら The Go Blog : JSON and Go を読んで,Golang で JSON を扱う方法を学んでいた.Golang を実践的に書いている人にとっては初歩的すぎる内容だけど,個人的にメモを残しておく.

encoding/jsonjson.Unmarshal を使うと,JSON をパースすることができる.json.Unmarshal は引数に []byteinterface{} を受けるため,定義した Struct にマッピングすることができる.もし JSON のキー名と Struct のフィールド名が異なる場合も問題なくて,Struct にタグを書けば,問題なくマッピングできる.

json.Unmarshal

The Go Blog に書いてある例を参考にすると,以下のように実装できる.ここまでは特に違和感もなくシンプルだった.

package main

import (
    "encoding/json"
    "fmt"
)

type Message struct {
    Name string
    Body string
    Time int64
}

func main() {
    b := []byte(`{"Name":"Alice","Body":"Hello","Time":1294706395881547000}`)

    var m Message
    if err := json.Unmarshal(b, &m); err != nil {
        return
    }

    // Name: Alice, Body: Hello, Time: 1294706395881547000
    fmt.Printf("Name: %s, Body: %s, Time: %d", m.Name, m.Body, m.Time)
}

任意の JSON をパースする

The Go Blog を読んでいて,interface{} を使えば,データ構造がわからない場合など,任意の JSON をパースできることを知った.実際に試してみたところ,JSON をそのまま map[string]interface{}json.Unmarshal できて,さらに Type Switch で型ごとに処理を書くことができた.実際に仕事で構造が可変な JSON をパースする必要があり,Twitter でも map が使えるとヒントを頂いたりもして,最終的にはこの interface{} を使うことで解決できた.

package main

import (
    "encoding/json"
    "fmt"
)

func main() {
    b := []byte(`{"Name":"Wednesday","Age":6,"Parents":["Gomez","Morticia"]}`)

    var f interface{}
    if err := json.Unmarshal(b, &f); err != nil {
        return
    }

    m := f.(map[string]interface{})

    // map[Name:Wednesday Age:6 Parents:[Gomez Morticia]]
    fmt.Println(m)

    for k, v := range m {
        switch vv := v.(type) {
        case string:
            // Name is string Wednesday
            fmt.Println(k, "is string", vv)
        case int:
            // Age is of a type I don't know how to handle
            fmt.Println(k, "is int", vv)
        case []interface{}:
            // Parents is an array:
            fmt.Println(k, "is an array:")
            for i, u := range vv {
                // 0 Gomez
                // 1 Morticia
                fmt.Println(i, u)
            }
        default:
            fmt.Println(k, "is of a type I don't know how to handle")
        }
    }
}

タグ

Struct の部分を調べていたら,多くの記事でタグ付きの Struct が紹介されていたが,The Go Blog を読みながら実際に試してみて,理解が深まった.基本的に JSON のキー名と Struct のフィールド名が一致しているのであれば,あえてタグを書く必要はないし,大文字と小文字の区別もしないため,JSON のキー名が小文字で,Struct のフィールド名の1文字目が大文字でも問題ない.ちなみに Struct のフィールド名は1文字目を大文字 (exported) にしないとダメと書いてある.

以下にサンプルコードを載せた.JSON のキー名が message_title の場合,大文字も小文字も区別しないため,Struct のフィールド名は Message_title でも Message_Title でも良い.ただし MessageTitle にする場合は JSON のキー名を異なってしまうため, json:"message_title" とタグを書くことによって,マッピングすることができる.タグの記法は他にもあって,nil などを除外する omitempty や,フィールドを無視する - もある.

package main

import (
    "encoding/json"
    "fmt"
)

type Message1 struct {
    Message_title string
}

type Message2 struct {
    Message_Title string
}

type Message3 struct {
    MessageTitle string `json:"message_title"`
}

func main() {
    b := []byte(`{ "message_title": "Hello!" }`)

    var m1 Message1

    if err1 := json.Unmarshal(b, &m1); err1 != nil {
        return
    }

    // Hello!
    fmt.Println(m1.Message_title)

    var m2 Message2

    if err2 := json.Unmarshal(b, &m2); err2 != nil {
        return
    }

    // Hello!
    fmt.Println(m2.Message_Title)

    var m3 Message3

    if err3 := json.Unmarshal(b, &m3); err3 != nil {
        return
    }

    // Hello!
    fmt.Println(m3.MessageTitle)
}

json.NewDecoder

The Go Blog の最後には json.NewDecoder も紹介されていた.特に API からレスポンスを受ける場合などは io.Readerioutil.ReadAll[]byte に変換するよりも,直接 json.NewDecoder を使った方が良さそう.ここは実際にベンチマークを取って確認する.

package main

import (
    "encoding/json"
    "fmt"
    "os"
)

func main() {
    dec := json.NewDecoder(os.Stdin)
    enc := json.NewEncoder(os.Stdout)
    for {
        var v map[string]interface{}
        if err := dec.Decode(&v); err != nil {
            return
        }
        for k := range v {
            if k != "Name" {
                delete(v, k)
            }
        }
        if err := enc.Encode(&v); err != nil {
            fmt.Println(err)
        }
    }
}

まとめ

1年半以上も前に Togoo を実装して以来,全然 Golang を書いてなかったけど,最近仕事で書く機会ができたので,改めて基礎部分から勉強し直している.The Go Blog も読むだけだと理解が深まらないなと思って,積極的に写経して試した.エディタは Gogland 1.0 EAP を試してみてるけど,非常に便利!とりあえず goimports を ⌥⌘I に Keymap して使っている.Golang はまだまだビギナーだから積極的に勉強していくぞ!社内に質問できる人も多くて非常に助かってる.

(ちなみに Togoo は個人的に今もずっと使ってる!)

kakakakakku.hatenablog.com

「JAWS-UG コンテナ支部 #9」で「ECS x Mackerel」をテーマに LT をした

昨日は「JAWS-UG コンテナ支部 #9」に参加して,LT もしてきた.ECS を中心に移行の話,デプロイの話,モニタリングの話などを聞けたし,懇親会にも参加させてもらって,カジュアルに話せて楽しかった.僕もコンテナ支部の運営をお手伝いしたいな!

jawsug-container.connpass.com

発表資料

今回 LT 枠で応募したら採択してもらえたので「ECS x Mackerel ~ 動的ポートマッピングに対応したタスクのメトリクスを取得する ~」という話をしてきた.内容としては,前にブログに書いた記事を整理した感じ.時間も少なくシュッと話したので,詳しくはブログを見てもらえればなと!

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

他の発表でも似た話があったけど,やっぱりタスクのメトリクスも取得したい場合は Datadog 一択という雰囲気があるので,CloudWatch や Mackerel でも気軽に低コストに取得できるようになると嬉しいなと思う.

speakerdeck.com

感想

ECS アップデート情報 @riywo

ECS はサービスのアップデートが多く,どんどん便利になっていく印象がある.CloudWatch Events から ECS の RunTask が実行できるのであれば,バッチ基盤としても柔軟に使えそうですごく気になる.タスク定義を実行時に上書きできる機能は初耳だった.試してみよう.

www.slideshare.net

乗換 Navitime のバックエンドをオンプレから ecs に移行した時の話

  • ECS Agent の接続チェックを aws ecs describe-container-instances を叩く
  • ECS Introspection API
  • ECS ID Mapper
  • タスクのメトリクスを取得するために Datadog を使っている

www.slideshare.net

AWS ECS のサービスを slack bot でデプロイする話 @h3_poteto

ecs-goploy はパッケージ実装になっているとのことで,Capistrano のような印象を受けた.僕も ECS のデプロイツールを選定するためにいろいろ調査したけど,最終的には silinternational/ecs-deploy にした.完全にシェルで実装されていることと,タスク定義の更新とサービス反映が簡単に行えることがメリットだった.発表でも話があったけど,確かに master の実装を見るとタスク定義だけの変更ができそうに見えるんだけど,実際に使ってみるとエラーになる(もしかしたら今はもう直ってるかも).CloudFormation を使ったデプロイはまだ試したことがないので,近いうちに試してみようかなと.

speakerdeck.com

GitHub + ECS で快適 Review 環境 @pataiji

  • デプロイ環境(特にステージング)の渋滞があり,もっとスケールさせたいと考えていた
  • Heroku Review Apps も検討した
  • GitHub から WebHook を受ける
  • branch を clone して,Rails アプリケーションを起動させる

以下の記事を前に読んでいて,興味があったので「あの話かー!」という感じだった.まだ一部自動化できていない部分もあるみたいだったけど,それでも素晴らしい試みだと思う.少し気になったのは,データベース変更が伴うプルリクで,この場合も特に考慮せずに動作確認できるようになっているのかな?

tech.speee.jp

speakerdeck.com

AWS CodeBuild カスタム Docker イメージを使ってビルドする

  • CodeBuild で buildspec.yml に書く version は 0.2 にする
  • 管理コンソールの手順解説

AWS の Code 系は使ったことがなく,おおー!という感じだった.うまく自動化できれば良さそう.

speakerdeck.com

関連記事

「JAWS-UG コンテナ支部」の参加は今回が3回目だった.引き続き参加したいと思う.

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

参加レポート

h3poteto.hatenablog.com

発表中!

f:id:kakku22:20170722173425j:plain

AWS をフル活用して「サーバレス」な SPA を実装できる「サーバーレスシングルページアプリケーション」を読んだ

6月末に O'Reilly から出版された「サーバーレスシングルページアプリケーション」を読んだ.ただ読むだけじゃ理解度が浅くなってしまうかもしれないなと感じて,今回は全ての実装を写経してみた.そのため少し時間はかかってしまったけど,フロントエンドには苦手意識があったし,今まで SPA の実装もしたことがなかったので,前半部分は特にワクワクしながら楽しめた.今回,監訳者の id:yoshidashingo にご献本を頂き,本当に感謝しかありません.ありがとうございます!と同時に,ガッツリ読もうと意気込んだタイミングで仕事に忙殺されてしまったりして,書評のタイミングが遅れてしまったのはすみません!

どんなものを実装したのか?

まず最初に,本書でどんなものを実装したのか?を紹介したいと思う.本書の表紙に描かれてるようなダッシュボードサイトではなく(最初はちょっと期待してしまった笑),LearnJS という名前の「JavaScript プログラミングパズル」を実装する.僕が実際に実装したアプリケーションのキャプチャを以下に載せておく.

f:id:kakku22:20170716152327p:plain f:id:kakku22:20170716152335p:plain

ちゃんと SPA になっていて,ハッシュイベントの変更をトリガーして次のページが表示される.app.js で以下のようなルーティングを定義するため,実際に遷移する URL は /#problem-1/#profile になる.今までは Rails など一般的なウェブアプリケーションの経験が多かったので,実際に自分で実装した SPA が動くと「おおおー!」という感動があった.

var routes = {
  '#problem': learnjs.problemView,
  '#profile': learnjs.profileView,
  '#': learnjs.landingView,
  '': learnjs.landingView
};

実際に以下の公式アプリケーションをすぐに試せる.

技術スタック

本書のサブタイトルにもある通り,AWS を活用して「サーバレス」を実現している.具体的には S3 からアプリケーションを配信し,Google のソーシャルログインには Cognito を使う.さらに自分の解答を DynamoDB に保存し,既に正解している問題ページを表示したときには,その解答を初期表示できるようになっている.また API Gateway + Lambda から DynamoDB に接続してエンドポイントを提供するところも解説されている.

SPA の部分は,React や Vue.js などではなく jQuery 2.1 を使う.非同期処理が必要な部分は jQuery.Deferred を使う. JavaScript のテストには Jasmine + Spy を使って,テストがしにくい部分もモックでテストできるようになっている.

素晴らしかったこと

デプロイファースト

LearnJS の雛形を GitHub から取得して,ローカル起動が確認できたら,すぐに S3 に本番デプロイしよう!という流れから始まる.これは本当に素晴らしいと思う.僕が好きな「ThoughtWorks アンソロジー」に書かれている「ラストマイル」の話と同じで,デプロイなど運用系のタスクを最後まで残しておくと,潜在的な問題が最後に露見するというものだ.本書では最初にいきなりデプロイをして,その後も章ごとに必ずデプロイをする.ローカルで動いているものが,全く同じように S3 でも動くのは,当たり前だけど非常に重要だと思う.同時にそれを支えるのは,便利スクリプト sspa なので,ここも参考になった.

github.com

テストファースト

最初からテストファーストで進んでいくため,例えば learnjs.showView 関数を実行したときの期待値を先にテストコードとして実装し,エラーを確認し,次に関数を実装し,テストが通ることを確認する.まさに TDD を体験できるのも本書の良さだと思う.今回特に写経をしながら進めたため,ミスによって動かなくなったケースが多くあった.そういうときにも,テストを実行して,期待値と合わない部分を特定することによってミスの発見を効率化できたので,実体験としてもテストファーストの恩恵を受けることができた.

f:id:kakku22:20170716152459p:plain

ハッシュイベント

今回実装した SPA のキモはハッシュイベントだったと思う.window.location.hash に変更があったときに window.onhashchange でトリガーして,ルーティングに飛ばした.また2章ではブラウザバックしても何も動かなかった部分が,3章でエイリアスルートを追加することによって動くようになった.このあたりを知れたのも個人的には大きかった.

リファクタリング

本書ではとにかく「小さく作る」ことが重要視されているため,例えば,最初は /#problem-1 ためだけの実装をして,動作確認が終わったら問題番号の部分をパラメータ化して /#problem-* に対応するルーティングを実装していく.他にも Correct! と Incorrect! の表示を作って動作確認をしてからフェードインの効果を追加するなど,リファクタリングを繰り返し行なっていく.この流れも参考になる.よく仕事でも「過剰に汎用化しすぎて使えない」ものがあったりして,改めて「小さく作る」ことを意識したいとも思った.

Cognito

実は今まで Cognito を使ったことがなく,今回初体験だった.今回は Google+ API を使った IdP 接続を実装した.とにかく簡単に実現できたし,この部分をフルマネージドにできるのも効果的だなと思った.本書では使うことはなかったが,Cognito User Pools も検証してみたい.今まで機会がなく使ったことがなかった Cognito に少しでも触れられたのも良かった.

API Gateway + Lambda + DynamoDB

個人的には使ったことがあり,解説の部分はある程度流し読みをしたが,「サーバレスの概念は理解しているが,実際に実装したことがない」という人にとっては最高のテーマだと思う.無料枠もあるし,まず試してみるのが良いのではないかと思う.1点 sspa スクリプトが API Gateway に対応していなく,手動で /popularAnswers の POST リソースを作るところはちょっと笑った.

セキュリティとスケールアップ

最後にはセキュリティで気を付けるべき点と,スケールアップの方法,そして CloudWatch を使ってモニタリングをする話も紹介されていて非常に手厚かった.今回実装したアプリケーションが完璧ではなく,現実問題では様々な考慮が必要であることが伝わる.S3 のアクセスログを分析する部分は,今なら Athena でクエリを投げればもっとリッチな体験ができるし,サーバレスだと思うけど,原著の発売日が2016年6月なので,まだ発表されていなかった.

aws.amazon.com

ハマったこと

CSS の記述が一部書かれてなく,思った通りのデザインにならなかった.そこは実際に公式ページを Chrome DevTools で解析して調べた.具体的には以下なので,ここは気を付けてもらえればと.

3章

ツールバーを実装するときに,以下の CSS を追加しないと,LearnJS のフォントサイズが大きくならなかった.また,そのために margin-top を 30px から 60px に修正する必要もあり,ここは本書に書いてあるものの,コードとしては書かれてなく,見落としてしまった.

.text-lg {
  font-size: 32px;
}

4章

Cognito 連携をしたときにナビバーにログイン済のメールアドレスを表示するが,そこで使う以下の CSS を追加しないと,デザインが微妙に崩れてしまった.

.navbar-padding-lg {
  padding-top: 12px;
  display: inline-block;
}

正誤表

O'Reilly から正誤表が公開されていて,現時点だと1点だけある.今後増える可能性もあるので,見ておくと良さそう.この「マイナスが抜けてる」件は,写経していると「変だな?」とすぐ感じたので,特に困ることはなかった.

www.oreilly.co.jp

ソースコード一覧

今回は答えを見ずに頑張って写経することを目標にしていたので,1度もダウンロードすることはなかったけど,公式のソースコード一覧が公開されている.どうしても困った!という場合は見てみるのが良いのではないかと思う.

pragprog.com

エディタ

2章までは vim で写経をしていたけど,ミスが連発したり,app.js がもっと大きくなる気配を感じたので,途中からは使い慣れた RubyMine で写経をした.フォーマットもできるし,コードジャンプもできるし,シンタックスチェックもできるし,圧倒的に効率が良くなった.もし写経をするなら,エディタを用意してから取り組むのが良いと思う.

まとめ

  • 本書を写経しながら SPA を実装することができた
  • S3 / Cognito / DynamoDB / API Gateway / Lambda などを組み合わせることで,本当に「サーバレス」で実現できた
  • 写経 + 動かなくてデバッグした時間も含めると,約6.5時間(13 ポモドーロ)で終わった

関連記事

監訳お疲れさまでした!素晴らしかったです!

yoshidashingo.hatenablog.com

API Gateway + Lambda をもっと深く学ぶなら同じく6月に出版された「実践 AWS Lambda」がオススメ!

kakakakakku.hatenablog.com

新任リーダーにオススメする「ザ・ファシリテーター」を読み直した

リーダー,マネージャーと言っても役割はいろいろあって,組織のフェーズ,規模,目指すビジョンによっても求められるアクションが異なる.だからこそ難しいし,チャレンジングだと思う.また「リーダー論」をテーマにした本もたくさん出版されていて,最近だとオススメの本を聞かれることも増えてきたけど,僕は「ザ・ファシリテーター」をよくオススメしている.最初に読んだのはもう5年以上前のことだと思うけど,最近もう一度読み直してみて,今だからこそ感じることができる刺激もあった.本書の書評をまだブログに書いていなかったので,今さらながら書くことにした.

ザ・ファシリテーター

ザ・ファシリテーター

続編も出ていて,位置付け的には「実践応用編」となっているけど,個人的には「ザ・ファシリテーター」を読めば十分だと思う.

ザ・ファシリテーター2―理屈じゃ、誰も動かない!

ザ・ファシリテーター2―理屈じゃ、誰も動かない!

ファシリタティブ・リーダーシップ

「ファシリテーター」と聞くと,議論を中立的な立場から整理する役割のように感じる人が多いと思うけど,本書で描かれている「ファシリテーター」というのは「ファシリタティブ・リーダーシップ」と表現されていて,意見を引き出し,議論を促進し,個人や組織のパフォーマンスを最大化する「リーダーシップ」のことを意味している.僕はこの「ファシリタティブ・リーダーシップ」という表現が非常に好きで,リーダー,マネージャーに必要なスキルセットだと考えている.また,本書が素晴らしいのは小説形式になっていることで,自分の所属する組織に当てはめてみたりして,小説の世界でロールプレイングをしながら学ぶことができる.「ファシリタティブ・リーダーシップ」は理論だけ知っていても意味がなく,実践してこそ価値があるものだから.

構造化された議論

ファシリテーションフレームワークを使うことのメリットは「構造化された議論」ができることだと思う.本書でも「社長からの非現実的なビジネス目標」に絶望する場面が多く出てくるけど,「できない理由」を全て書き出して(これを発散と言う),次に「できるようにするには何ができるか」に置き換えていく(これを収束と言う)アプローチが紹介されていたりもした.どんなに非現実的な目標であっても,小さくブレイクダウンして「解決できそうな粒度」まで落とし込むことによって,可能性が見えてきてモチベーションが上がるという話は,メンタリング(自己達成)にも似ているし,スクラム開発にも似ているし,どんなシチュエーションにも応用可能なアプローチだと思う.僕はファシリテーションフレームワークを以下の本から学んだ.コンパクトにまとまっていて良いと思う.

ファシリテーターの道具箱―組織の問題解決に使えるパワーツール49

ファシリテーターの道具箱―組織の問題解決に使えるパワーツール49

  • 作者: 森時彦/ファシリテーターの道具研究会
  • 出版社/メーカー: ダイヤモンド社
  • 発売日: 2008/03/14
  • メディア: ペーパーバック
  • 購入: 47人 クリック: 385回
  • この商品を含むブログ (41件) を見る

やっぱり大切なのは腹を割って議論できる人間関係

本書の最初に「リーダーズ・インテグレーション」というフレームワークが紹介されている.リーダーと部下の関係を改善するために有効で,本音ベースの自己紹介をすることによって信頼関係を築くことができる.また「ジョハリの窓」の話も出てくる.また「緊張をほぐす質問」と表現される通り,空気を和らげるスキル(もしくは雰囲気・素質)が重要なのもリアルに描かれている.後半部分に出てくる「ウソつき自己紹介」というアイスブレークも面白いと思った.このあたりの話は,先月の勉強会で「組織パフォーマンス」の話をしたときにも引用したけど,やっぱり大切なのは人間関係だし,心理的安全だし,腹を割って議論できることだなというのが,個人的な結論だったりする.

kakakakakku.hatenablog.com

まとめ

  • 「ザ・ファシリテーター」は新任リーダーにオススメ
  • ファシリタティブ・リーダーシップ
  • 構造化された議論を促進するためにファシリテーションフレームワークをよく知っておく

関連記事

似たようなテーマだと「あなたのチームは、機能してますか?」もオススメ.同じく小説形式になっていて,反面教師的に読むことができる.

kakakakakku.hatenablog.com

少しテーマは異なるけど「1分間マネジャーの時間管理」もリーダー,マネージャーの心構えを学べるのでオススメ.

kakakakakku.hatenablog.com

読んだ!

f:id:kakku22:20170712011845j:plain

AWS Solution Days 2017「第2回 Aurora 事例祭り」で発表をしてきた

今日は「AWS Solution Days 2017 ~ AWS DB Day ~」に参加をして「第2回 Aurora 事例祭り」で発表もしてきた.すぐに資料公開をして良いとのことだったので,参加レポートをまとめる.

第2回 Aurora 事例祭り

今回は「Makuake の急成長を支える Aurora 移行事例」というタイトルで発表をした.特に MySQL 5.5 on EC2 から Aurora に移行したフェージングと,その効果を中心に話した.他の発表であったような,オンプレからの移行ほど複雑度は高くはないけど,全体感をギュッと凝縮した,良い発表ができたのではないかなと個人的には思っている.

今日の会場風景はこんな感じだった!運営側からの依頼もあり,今回は珍しく発表台の前から動かず発表をした(笑)

f:id:kakku22:20170705212546j:plain

クラウド上のデータ活用デザインパターン

午後のセッションにも参加してきた.

  • データ分析を実施する場合は,試行錯誤のサイクルを高速に回す必要がある
  • Amazon Redshift Spectrum を使うと,Redshift クラスタから直接 S3 にクエリを実行することができる
    • コールドデータを S3 に置いておくなどの工夫ができるようになる
  • パターン
    • BI パイプラインパターン
    • マルチクラスタパターン
    • ホットデータパターン
    • ラムダアーキテクチャパターン
    • マルチノードパターン
    • などなど

後半部分の発表では,参考になるパターンがたくさん紹介されていて勉強になった.特にストリーム処理(スピードレイヤー)とバッチ処理(バッチレイヤー)にレイヤーを分割した「ラムダアーキテクチャパターン」は興味があるので,資料を見たりして,もっと詳細に調べてみたいと思う.

www.slideshare.net

ETL をサーバーレスで実現する新サービス AWS Glue のご紹介

今日1番聞きたかった Glue のセッションにも参加した.

  • AWS Glue(現在,プレビュー中)
  • Glue はベース技術に Spark を採用している
  • データ量によって自動的にスケールアウトするフルマネージドサービス
  • EMR ほどの自由度はないが,PySpark で実装をすることで,ETL をカスタマイズすることができる
  • クローラーはデータソースのメタデータを収集して,データカタログ(Hive メタストア)に格納する
  • Gork でカスタマイズした Classifier を作成することもできる
  • 自動生成された Python コードを Glue 上で修正することもできるし,任意のエディタで修正することもできる
  • Glue のインスタンスは VPC の中に入るため,S3 にアクセスする場合は VPC Endpoint を使う必要がある

実際に試してみないとわからない部分も多いけど,基本的な ETL をフルマネージドでサーバレスな環境に任せられるのは良いなと感じた.東京リージョンで GA になるのを待とう.任意のエディタで実装したときにデプロイはどうするんだろう?と思ったけど,プルリクをマージしたタイミングで S3 に保存して,AWS CLI で S3 からデプロイすることはできそうなので,現実的な運用を考えると,そういう感じになりそうだなとは思った.

(資料公開待ち)

参考までに re:Invent 2016 の Glue のセッション動画を載せておく.

www.youtube.com

まとめ

  • 全体的にエンタープライズな参加者が多く,引き続きクラウドの注目度は高いんだなと感じた
  • 「第2回 Aurora 事例祭り」で発表ができて良かった!すごく楽しかった!
  • もっともっと Aurora を活用して,また違う事例を紹介できるように頑張っていきたいと思う

関連記事

今日の発表資料では割愛した技術的負債部分などは Developers Blog にまとめてあるので合わせて読んで頂ければと!

developers.cyberagent.co.jp

5月末にも Aurora 移行関連の LT をした!

kakakakakku.hatenablog.com

今日紹介した Fluentd でスロークエリを Amazon ES に転送する話は以下の記事に詳しくまとめてある!

kakakakakku.hatenablog.com