コネヒト開発者ブログ

コネヒト開発者ブログ

「やさしいかんしのご提案」をしました 〜コネヒトなりの「監視の民主化」入門〜

こんにちは! @o0h_です。
3月は・・・王様ランキング!!!!おめでとうございます🎉

王様ランキング 1巻

https://cdn-mamari.imgix.net/authorized/5c92686d-9b58-410f-8b54-0037ac110003.jpg

さて、唐突に本題なのですが
先日、入門監視を読んで思ったこと・感じたことを当ブログに投稿しました。

tech.connehito.com

今回は、ちょっとした続編のようなものになります。

先の記事では、自分自身に生じた内省や「べき論」「目指すべき地点」を中心に取り扱いました。
具体的な「私や他のメンバーが取るアクション」や「変更されていく内容」についてはスコープにしておりません。

当然、こうもデカい口を叩いた以上は、実践をしていく必要があります。
でないと・・・ダサダサ君になってしまいますよね。
そんな訳で、「実際に組織を変えていくぞ」と、その最初の一歩目として 監視の民主化に向けたキックオフ を行いました。*1

先日のブログのような内容が「概念」「抽象」だとするなら、こちらは「実践」「具体」に相当するものでもあります。
折角ですので、私と同じような課題感を持った人と共闘すべく、この場で公開してみます!

あくまで社内向けに企画・作成した内容なので、「内輪ならコンテキストがあるから、ちゃんと伝わるだろうけどさ」な部分も少なくありません。
それでも、今回の内容はある程度の一般性を保てているのではないか〜なんて考えています。

*1:先日、弊社にて開催した勉強会での私の発表内容もこの内容を想起しながらまとめたものになります

続きを読む

Slack Block Kitを使って既存ツールをカッコよくしてみた

こんにちは、 BLUE GIANT SUPREME (7) (ビッグコミックススペシャル)を読みました。金城(@o0h_)です。
読後、へーしゃで称賛が発生していました。

f:id:o0h:20190303130444p:plain
こちら、社長と私です

そんな感じで色々にSlackを利用している身のものですが、先月「新しい機能をリリースしたよ!」という発表がありました。
「Block Kit」です。

Block Kitは、「Slack投稿の表現力を上げる」「ユーザーと、より気の利いたインタラクションをつなぐことを支援する」ための新UI(のためのAPI)です。
これを利用すると、いつものSlackの投稿がとても高機能になります。

実際に触ってみたので、使い方やハマったポイントなどを共有していきます。

https://cdn-mamari.imgix.net/authorized/5c7ccc81-7170-439c-8949-0034ac110003.jpg

続きを読む

React HooksとContextAPIでFluxをやってみる

f:id:dachi023:20190226162905p:plain

CTO室エンジニアの安達 (@dachi_023) です。React v16.8で待ちに待ったHooksが (20日前に) リリースされました。そんなHooksを使ってFluxやる時ってどうするんだろう?と思ったので調べて写経してみました。

reactjs.org

書いたコード

create-react-app して出てきたものをいじって作りました。Flux化するまでに書いたコードだけを見たい場合は コミットログ が分かりやすいかもしれません。

github.com

余談: 実際書いてみて「Hooksちゃんと理解してなかったなぁ、9割くらい写経だとしても覚えるために書くというのは良いことだ」と感じられました。

やってみる

  • お題: +1 / -1 ができるカウンターの実装
  • useReducer() とContextでStoreをつくる
  • Actionの発行 → dispatch → Stateの更新 → 再描画 をやる

Context

ContextがStateを管理するための入れ物 & 伝搬役になります。とりあえず createContext() して返します。今回はdispatchも同じContext内で管理します。

import { createContext } from 'react'

export default createContext({
  count: 0,
  dispatch: null
})

Reducer

Actionを受け取って新しいStateを返します。Actionの中身は redux-utilities/flux-standard-action と同様です。Reducerの定義は Reactのドキュメント にも書いてありますが (state, action) => newState です。

export default function CounterReducer(state, action) {
  switch (action.type) {
    case 'increment':
      return { count: state.count + 1 }
    case 'decrement':
      return { count: state.count - 1 }
    default:
      return state
  }
}

ActionCreator

外部通信やビジネスロジックがないのでほぼ無意味な感じになってますが前述したflux-standard-actionに倣ってActionを生成して dispatch() します。

export function increment(dispatch) {
  dispatch({
    type: 'increment',
    payload: {}
  })
}

export function decrement(dispatch) {
  dispatch({
    type: 'decrement',
    payload: {}
  })
}

Component

作ったものをつなげていきます。

App.js

useReducer() にCounterReducerとStateの初期値を渡してstateとdispatchを取り出しProviderに突っ込めばStateの生成と値の伝搬作業が完了します。

import React, { useReducer } from 'react'
import Counter from './Counter'
import CounterContext from './contexts/CounterContext'
import CounterReducer from './reducers/CounterReducer'
import './App.css'

export default function App() {
  const [state, dispatch] = useReducer(CounterReducer, { count: 0 })
  return (
    <div className="App">
      <header className="App-header">
        <CounterContext.Provider value={{ ...state, dispatch }}>
          <Counter />
        </CounterContext.Provider>
      </header>
    </div>
  )
}

Counter.js

の処理でProviderにセットしたStateを useContext() で取り出し表示します。Stateと一緒に入れてあるdispatchを取り出してクリックイベントに仕込めばStateの更新処理までが完了です。

import React, { useContext } from 'react'
import CounterContext from './contexts/CounterContext'
import { increment, decrement } from './actions/CounterActions'

export default function Counter() {
  const { count, dispatch } = useContext(CounterContext)
  return (
    <>
      <h2>{count}</h2>
      <button onClick={() => increment(dispatch)}>Increment</button>
      <button onClick={() => decrement(dispatch)}>Decrement</button>
    </>
  )
}

できあがったのがこれ

ちゃんと増えたり減ったりするようになりました!

f:id:dachi023:20190226160647g:plain

まとめ

  • 今までのClassベースのComponentとは書きっぷりがだいぶ異なるので最初とっつきづらいのかもなと思いました、1回でも真面目にやると「なんだ全然できるじゃん!」という感じですが。
  • 複雑なことしないのであればFluxライブラリなど使わずにHooksで実装しちゃってもいいかもしれないですね。結構使えそうじゃないかな?と思ってます。

参考記事

AmazonAurora カスタムエンドポイントのフェールオーバー時の挙動についての検証

こんにちは。インフラエンジニアの永井(shnagai)です。

昨年11月にリリースされたAmazon Auroraのカスタムエンドポイントを運用していて、先日ある検証環境でフェールオーバーが起きた際に考慮していなかった事態が起きたので、仕様を確認するがてらカスタムエンドポイントのタイプ別にフェールオーバー時の挙動をまとめてみました。

カスタムエンドポイントについては下記をご参照ください。 自由にAuroraインスタンスを組み合わせて、用途別にAuroraのエンドポイントを管理出来る機能で、これまで泣く泣く続けていたmysqlのbinlogレプリ運用から解放されるようなうれしさがあります。 docs.aws.amazon.com

起きた事象

Auroraクラスタにフェールオーバーが発生した際に、当然リードレプリカがマスター昇格します。その際に、カスタムエンドポイントのノードが0になりカスタムエンドポイントへのDB接続が不可となりました。

これは、下記環境の説明にあるようにREADER TYPEでカスタムエンドポイントを作成していたので、登録していたリーダーインスタンスがREADER TYPEの条件不一致になりメンバから外れたのが原因でした。 リーダーエンドポイントだと、よくあるLBのSorry設定のように、ノードが0になればマスターが一時的にメンバに入りノード0を防ぐような挙動をしてくれますがカスタムエンドポイントではそのような挙動はありません。 今回の検証では、リードレプリカに降格したインスタンス(旧ライターインスタンス)が、自動的にカスタムエンドポイントに登録するような設定を見つけるのがゴールとなります。

問題が起きたカスタムエンドポイントの環境

  • Auroraクラスタで、ライターインスタンス1台、リーダーインスタンス1台構成で運用
  • カスタムエンドポイントは下記条件で作成し運用
    • READER TYPE
    • メンバシップルール内の[今後追加されたインスタンスをこのクラスターにアタッチ]はDisable ※この設定はAuroraレプリカを追加する際に意図せずエンドポイントに追加されるのを防ぐ意図で入れたのですがこれが仇になりました。。
    • 静的リストで、リーダーインスタンス1台を登録

Auroraのカスタムエンドポイントの主な設定値

はじめに前提知識としてAuroraのカスタムエンドポイントに主な設定値の内容を確認しておきます。 主な設定値は2つです

タイプ指定

Any or READERでカスタムエンドポイントのルールを指定する

type 説明
READER 読み取り専用の Aurora レプリカである DB インスタンスのみが、READER カスタムエンドポイントの一部となることができる
ANY 読み取り専用の Aurora レプリカと読み取り/書き込みのプライマリインスタンスの両方が ANY カスタムエンドポイントの一部となることができる

メンバーシップルール

  • 静的リストか除外リストを用いて、カスタムエンドポイントに所属するインスタンスを指定する
  • [今後追加されたインスタンスをこのクラスターにアタッチ]するか否かを選択する ※今回の検証ではここが肝だった

検証

6つのパターンからフェイルオーバー時に降格したマスターノードがカスタムエンドポイントのメンバに自動的に追加される設定を探りました。

検証

  • テスト用のAuroraクラスターを作成
  • クラスタには、1台のライターノード(test-custom-endpoint)と1台のリーダーインスタンス(test-custom-endpoint-ap-northeast-1c)を用意
  • 6パターンのカスタムエンドポイントを作成し、フェイルオーバー時の挙動を確認

結果

②の構成でカスタムエンドポイントを作ることで、フェイルオーバー時に降格したインスタンスがカスタムエンドポイントに追加されることが確認出来ました。

また、⑤⑥の構成であれば静的リストの中からレプリカのみがカスタムエンドポイントのメンバーとして管理されることがわかりました。

※はてブでコメントいただき「ライターインスタンスは静的リストに入れておいてもライターのうちはREADER TYPEのメンバにはならないからそれをうまく使うという」気づきを得ました。

No TYPE 追加インスタンスのアタッチ 静的リストに登録するメンバ 予想 結果
READER Disable レプリカのみ メンバいなくなる メンバいなくなる
READER Enable レプリカのみ メンバいなくなる or 降格したインスタンスがメンバイン 降格したインスタンスがメンバイン
ANY Disable レプリカのみ そのまま(昇格したライターのみ) そのまま
ANY Enable レプリカのみ そのまま or 降格したインスタンスがメンバイン そのまま
READER Disable レプリカとライター 降格したインスタンスのみ 降格したインスタンスのみ
READER Enable レプリカとライター 降格したインスタンスのみ 降格したインスタンスのみ

最終的にどんな構成にすればいいのか

カスタムエンドポイントを使いたいよくあるケースは下記のようなパターンかと思います。

  • マスターにはサービスからの書き込みトラフィックが流れる
  • 複数台あるレプリカを束ねるカスタムエンドポイントにサービスの読み取りトラフィックが流れる
    • フェイルオーバー時は、このサービス用のカスタムエンドポイントのいずれかがマスタ昇格
  • 分析用にAuroraのレプリカを作ってそこは分析のSQLだけが流れるような構成

下記のような構成を取ることで、カスタムエンドポイントの本来の良さを生かしてAuroraレプリカへのトラフィック分散が出来るのではないかと思います。(さらばbinlogレプリ)

  • レプリカのスケールアウトはあまり行われず、別用途のレプリカが追加される可能性の高い環境で運用したい場合は⑤の構成
  • レプリカのスケールアウトを行う可能性があり、その際にシームレスにカスタムエンドポイントに追加されてほしい場合は⑥の構成

※カスタムエンドポイントはGUIから作るとAny typeになるので、READER typeのエンドポイントを作るにはAWS CLI等からの作成が必要

サービス用のカスタムエンドポイント

READER type + 新規インスタンスのアタッチ有or無 + 静的リストにライターとサービス用のレプリカを登録 + 所属するリードレプリカのFailOver優先度を0(最優先)にしこの中からフェイルオーバー時のマスター昇格が行われるようにする

分析用のカスタムエンドポイント

READER type + 新規インスタンスのアタッチ無し + 静的リストには分析用のレプリカを登録 + 所属するリードレプリカのFailOver優先度を15(優先度最も低い)にしてフェイルオーバー時のマスタ昇格は行われないようにする

f:id:nagais:20190222174722j:plain

参考までに画面キャプチャ

f:id:nagais:20190218163647p:plain f:id:nagais:20190218163659p:plain

f:id:nagais:20190218163715p:plain f:id:nagais:20190218163723p:plain

f:id:nagais:20190218163740p:plain f:id:nagais:20190218163749p:plain

f:id:nagais:20190218163801p:plain f:id:nagais:20190218163812p:plain

f:id:nagais:20190222174642p:plain f:id:nagais:20190222174656p:plain

コネヒトでは変化を恐れずに良いものを取り入れながらサービスの信頼性向上をミッションに一緒に働く仲間を探しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。

www.wantedly.com

入門監視を読んで、「監視の民主化」に本気で向き合おうと思った話

こんにちは!待ちに待った2月です。
何を待っていたか? フットボールネーション(13) (ビッグコミックス)ブルーピリオド(4) (アフタヌーンコミックス)BLUE GIANT SUPREME(7) (ビッグコミックススペシャル)が発売される月ということになります。
嬉しい〜!の金城(@o0h_)です。

https://cdn-mamari.imgix.net/item/500x0_5c6a9464-96b0-4fc9-8ee2-0034ac110002.jpg.jpg

さて。
(ほぼ)ちょうど1ヵ月前に出た「入門 監視」は、いろいろな方面で話題になりました。
既に色々な書評やまとめが出回っていて、反響の大きさが感じられますね!

www.oreilly.co.jp

弊社でも、会社の書籍購入補助を利用して即予約 & 入手をしました。
この本からは非常に多くの学びや示唆を得られたと感じています。

先日、その内容・感じたことを、社内LT会で共有しました。
発表内容を踏まえつつ、読後に自分なりに考えさせられたことをまとめてみたいと思います。
ただしスライドに含まれる全ての内容を扱うと広範になりすぎるため、今回は「組織」側面のトピックに絞って取り上げます。

また、本稿では「入門 監視」に関する「まとめ」はあえて避けていきます。
その代り、その内容を踏まえて痛感した、我々のチームにおける「これまでの失敗」と「何を反省したか」を記します。
(そのため、既に一読されている方が対象になるかもしれません。)

TL; DR

  • この本を読んで、「監視の民主化」をしたい!と非常に強く感じた。
    うちのチームは、少なくとも形式的にはアラートへの対応を全員でやっているが、見えない壁があった。
  • 「監視をできるようにする」ために必要なのは、「知っている人」「慣れている人」からの歩み寄りが大事だと思う。
  • 「監視はスキル」。誰でも出来るように、インプットとトレーニングを用意する。

発表資料

こちらが、発表した内容です。
公開に当たり、実際に利用した資料を一部編集しています。

続きを読む

DroidKaigi 2019に行ってきました!

f:id:tommy_kw:20190211202916p:plain

はじめに

こんにちは!Androidエンジニアの富田です。先日開催されたAndroidカンファレンスのDroidKaigi 2019に参加しましたので、簡単に参加した感想を共有したいと思います。

カンファレンス全般について

カンファレンスへの支援

f:id:tommy_kw:20190209075031j:plain
オープニングでコネヒトを紹介していただく

DroidKaigiは5回も開催されている大規模なAndroidカンファレンスですが、今年初めてコネヒトはサポーター枠として支援させていただきました。僕がコネヒトにジョインして2年半で初めてAndroidカンファレンスに支援することができたので、とても感慨深かったです。

f:id:tommy_kw:20190209085232j:plain
カンファレンスアプリに記念コントリビュート
最早毎年恒例となっているカンファレンスアプリですが、昨年に引き続き、今年もtakahiromさんが開発リーダーとしてカンファレンスアプリの開発からリリースまで担当されていました。そんなカンファレンスアプリですが、約140名の方がカンファレンスアプリにコントリビュートされており、僕も簡単なIssueにコントリビュートさせていただきました!たくさんのPRがあったにも拘わらず、圧倒的なスピードでのレビューありがとうございました。

セッションの同時通訳

昨年くらいのDroidKaigiから海外の登壇者も増えてグローバルな大規模Androidカンファレンスになった印象です。海外のスピーカーのセッションだと英語になるので、どうしても聴講者数が日本語セッションと比べて少なくなりやすいです。ですが、今回からいくつかの英語セッションで同時通訳が採用されて、聴講者数が増えたと思いますし、逆に海外からの参加者の方も同時通訳を利用して日本語セッションを気兼ねなく聴講することができたと思いますので、素敵な取り組みだったと思います。

簡単にフィードバックしやすいアンケート

各セッションに対するフィードバックはとても重要なものだと考えます。なぜならフィードバックをもらって刺激を受けたり、さらに改善に繋げることができるからです。ただ、アンケートするの忘れてしまったり、ちょっとめんどくさくなってアンケートをやらないなどのご経験は誰にでもあるのではないでしょうか?今回のDroidKaigiのアプリUIはその課題をうまく解決できていたと思います。

セッションが終わるとアンケートリンクが表示される 簡単にアンケートに答えやすいUI
f:id:tommy_kw:20190209080406j:plain f:id:tommy_kw:20190209080452j:plain

またアプリだけでなく、セッションとセッションの間の休憩時間が20分と長くなっていて、その隙間時間に余裕を持ってアンケートに回答することができました。各セッションの司会者の方がアンケートについてのリマインドをして下さったおかげて全てのアンケートに回答することができました。全体を通してもとてもアンケートの回答率が高かったのでないでしょうか。

心地よい疲労感

正直にお伝えすると、昨年までのDroidKaigiでは疲れて寝そうになってしまうことが少しだけありました。体力にあまり自信のない僕にとって、1日8セッションくらいを聴講することはちょっとハードなことです。ですが、今年のDroidKaigiでは眠気に襲われることもなく、心地よい疲労感に包まれながら楽しむことができました。振り返ってみると、以下のジャンルのセッションを聴講しました。

  • Flutter
  • Gradle
  • Server-side Kotlin
  • アーキテクチャー
  • TensorFlow
  • Jetpack
  • マルチモジュール
  • Androidプラットフォーム
  • Dex R8
  • Android Studio設定
  • Codelabs

Androidのカンファレンスではありますが、本当にジャンルが豊富であることがわかります。この豊富なジャンルのおかげで全く飽きなかったことや、Codelabsで実際に手を動かし、コードを書いていたことも大きな要因かなと思います。Codelabsは今まで一度もトライしたことなかったので、新鮮で本当に面白かったです。以下がCodelabsのリファクタリングに関する内容になっていますので、ご興味のある方はご覧ください。

github.com

セッションやカンファレンスアプリについて

DroidKaigiのスタッフの皆さんのおかげで、すでにDroidKaigiのセッション動画が公開されています。また、まとめ記事もありますので気になる方はご覧ください。今回は特に気になったセッションやカンファレンスアプリについて紹介させていただきます。

www.youtube.com qiita.com qiita.com

Server-side Kotlin for Frontend: 複雑なAndroidアプリ開発に対するアプローチ @qsonaさん

FiNCさんのKotlinを用いたBFFの紹介で、BFFとは、ClientとBackend Serverの間にServerを配置するパターンです。コネヒトで運営しているママリでも画面によっては、APIを10個くらい叩いている画面が存在します。そのような画面においてBFFは有効で、AWSサーバ間との通信であれば10msくらい*1でレスポンスが返ってきて、クライアント側では1つAPIを叩くだけで必要なレスポンスを取得することができます。ただ、BFFのサーバを挟むことによって管理対象が増えるため適切な設計が必要となります。こちらのセッションでは、FiNCさんの貴重な導入事例が紹介されていますので、ご興味のある方はぜひご覧ください。

All About Test of Flutter @kikuchyさん

docs.google.com

実はFlutterを全く触ったことがなかったのですが、ユニットテスト、Widgetテスト、結合テストとわかりやすく説明していただきセッションが終わった頃には、「なんかテストが書けるような気がする!」という思いになっていました。とはいえ、FlutterもDartも全く触ったことがなかったので、DroidKaigi後にGoogle Codelabsで簡単なアプリを触ってみました。

codelabs.developers.google.com codelabs.developers.google.com

Dartの文法に関しては、こちらもkikuchyさんの資料で勉強させていただきました。 qiita.com

改めて、kikuchyさんの登壇資料のユニットテスト、Widgetテスト、結合テストまで一通り試してみるとめちゃくちゃ理解しやすかったです。なんだか、FlutterやDartを好きになりました。テストの書き方はわかったのですが、実際のアプリではどんな風にテストを書いているんだろうとふと考え、メルカリさんのカンファレンスアプリで勉強させていただきました!ご興味のある方はこちらも覗いてみると良いかもしれません。

github.com

Android Studio設定見直してみませんか? @shirajiさん

shiraji.hatenablog.com

僕が見た中で一番盛り上がっていたセッションで、スピーカーと聴講者が一体になって楽しむことができた聴講者参加型のセッションでした。Android Studio設定の便利機能をたくさん紹介していただき、早速利用させてもらっています。さらにどうやって機能実装しているんだろうと気になることばかりだったので、IDEやPlugin周りのコードを漁ってみようと思いました。

カンファレンスアプリ

github.com

カンファレンスアプリは知見の塊です。実際のコードやPRやIssueを覗いてみると参考になる情報がたくさん詰まっています。今回はその中で気になったPRを紹介します。

メモリーリークの対応ってどうやっているか気になりませんか?こちらのPRではRecyclerViewの利用に関するメモリーリーク対応でした。 github.com

gzip対応することによってトラフィック量を減らすことができたというまさにawesomeな内容でした。 github.com

Android Studioで、変数名に「favorited」、「okhttp」、「ktor」を利用するとIDEのスペルチェッカーに引っ掛かりTypoしてますよと警告される経験はありますよね。.idea/dictionaries以下に辞書ファイルを定義することによって警告を制御することができるという内容でした。 github.com

build.gradleでリソース変数のresValueをうまく利用されていてとても参考になりました。 github.com

PR自体はSafeArgsに関する内容ですが、初期化のタイミングについてコメントされており、改めて初期化のタイミングを意識しないといけないなと考えさせられる内容でした。 github.com

他にもたくさん参考になるPRがありますが、 awesomeラベルが貼ってあるPRもあるのでそれらを見るだけでも面白いと思います。ご興味のある方はご覧ください。

最後に

運営の皆さん、登壇された皆さん、参加者の皆さんのおかげで今年も楽しい時間を過ごすことができました!Flutterを全く触ってこなかったのですが、DroidKaigiのおかげでFlutter、Dartが好きになりました!DroidKaigiに参加させてもらってたくさんの知見を得ることができたので、今度はそれをプロダクトに反映してユーザに還元していきたいなと思っています。それではありがとうございました!

*1:サーバーの処理にかかる時間に依存しますが、ネットワーク間でかかる時間は長くみても10ms以内

忘年会コンテンツをFirebaseとHerokuを使って3日で実装しました

こんにちは、CTO室エンジニアの安達 (@dachi_023) です。少し時間が経ってしまいましたが、弊社の2018年忘年会で実施した催し物についての話をします。

やったこと

社員同士で写真をたくさん撮った人の勝ち というサービスを作りました。

サービス名は写真を撮る擬音「パシャリ」と競技的な意味で「オリンピック」をくっつけて パシャりんピック となりました。もともと、社内で「〜ピック」みたいなオリンピックをもじった名前をつける文化があり、そこに乗っかりました。

コンセプト

ご歓談タイムをバージョンアップする

たくさんの人と写真を撮る、という行為を選んだ理由ですが、ただゲーム性があって内輪で盛り上がれるだけなのではなくて、 一緒に働く人たちと美味しいお酒を飲み、美味しいものを食べながらのご歓談タイム をもっと良い形にできるのでは?と思ったからです。

  • 社内のメンバー全員が一斉に集まるタイミングは貴重
  • 同じメンツで話し込んじゃったりして、いろんな人と話せなかったなぁとなりがち
  • そこで、自然といろんな人と話せる機会を作れるような企画がいいのではないか?

上記のような考えから忘年会と相性が良さそう!となり、採用されました。

f:id:dachi023:20190123223620j:plain

開発について

パシャりんピックを実現するために必要なものは2つです。

  • 写真を撮ったり見たりするもの
  • 最後に集計して結果発表するもの

開発体制など

  • メンバー:エンジニア2名
  • 与えられた期間:約3日

インフラ

メンバーは私ともう1名でしたが、得意なことがそれぞれ異なったので (私はJSだし、もう1名はPHPなので) システムを完全に分けて、それぞれ得意技かつ並行で進めることにしました。ので、インフラもそれぞれがやりやすいように分割しました。

Firebase

  • コネヒトの社員のみがログイン・閲覧できる
  • なにかで使えるかもなので写真をクラウドストレージにアップロードできる
  • 最後に順位をつけて表彰したいので誰が誰と撮ったかをDBに格納できる
  • 上記を実現するwebサービスを公開する場所がある

これらの要件を1サービスでサクッと実現できるためFirebaseを選びました。本当は無料枠でどうにかなる予定でしたが、忘年会前日の夜に実装をミスって無料枠を食いつぶしてしまったので結局課金しました...。

f:id:dachi023:20190123161736p:plain
Firebaseの開発メニュー。AuthもDBもStorageもHostingもあるので全部Firebaseでできる

Heroku

  • Dockerコンテナが使える
  • Firebaseからデータを吸い上げて集計処理ができる
  • 慣れていて、とにかくやりたいことをサクッと実現できる

HerokuはPaaSサービスでもかなり使い勝手がよい素敵なサービスです。対応している言語も多く、弊社でもチャットボットなどのツールでの実績があったりなどして「使いやすい・慣れてる」というのが大きな理由になりました。ちなみに、Firebaseからデータを取り出してくるのはFirebase SDKがあるのでどこからやってもサクッとできちゃいます。

f:id:dachi023:20190123183221p:plain
Herokuなら無料!

コード管理

GitLab

コネヒトではGitHubを使っていますが今回はGitLabを使いました。GitLabちゃんと使ったことないから試しに使ってみるか!という思いと、本当はGitHubのorgにリポジトリを置きたかったけど置くと忘年会のサプライズコンテンツなのにバレちゃうよね、という理由からでした。

結局git pushくらいしかしてないのでGitLabの良さを発見できなかったのですがその後に個人開発で使ってみたりなどしているので、とっかかりとしては良かったかな〜と今は思っています。

構成図

全体で見てみるとこんな感じになりました。

f:id:dachi023:20190123185827p:plain

フロントエンドの実装

技術選定

  • material-ui
  • firebase
  • react
  • styled-components

今回は3日間という長くはない期間の中でいかにちゃんと動くものが作れるか、という状況だったのでとにかく乗っかれるものには乗っかって体験づくりにフォーカスできるようにしました。なので、なるべく手に馴染んでいる技術を選ぼうということで私の場合は上記のような構成になりました。

f:id:dachi023:20190123195040p:plain
こんな感じで自分の撮った写真で画面が埋まっていく

やってみてどうだったか

f:id:dachi023:20190123223025j:plain
パシャパシャしている様子
f:id:dachi023:20190124132747j:plain
写真を撮るとスクリーンに映した画面に流れてくる

想像以上に盛り上がりました!

  • 参加者:約50名
  • 歓談タイム:約40分
  • 撮影総枚数:約550枚

ご歓談コンテンツとして受け入れられたようで、がんばって作ってよかったなぁエンジニア日和だなぁ、と感動しつつ忘年会を終えることができました。積極的に写真を撮って盛り上げてくれたみなさんにとても感謝しています。

後日談

一緒に制作してくれたエンジニアの @o0h_ が振り返りページを作ってくれました!このページで自分以外の撮影した写真を眺めたりできるようになりました。

f:id:dachi023:20190124144712p:plain
優勝はCEOでした (笑)

さいごに

はじめて忘年会をハックしてみましたが楽しかったです。作るのはもちろんですが、目の前で自分がつくったもので楽しんでいるのを見れたのが最高でした!