コネヒト開発者ブログ

コネヒト開発者ブログ

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

こんにちは!待ちに待った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でした (笑)

さいごに

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

コネヒトで実践しているチームビルディングのワークショップ4選

はじめに

本記事は コネヒト Advent Calendar 2018 の25日目のエントリーになります。遂に最終回!メリークリスマス!

こんにちは。アルバルク東京🏀を応援している @itosho です。バスケットボールと言えばチームスポーツ!と言うわけで、今日はいつもと趣向を変えてチームビルディングにフォーカスを当てたいと思います。

コネヒトでは開発手法としてスクラムを導入しているのですが、チーム一丸となって「スクラム」を組んで開発を進めていくためにはチームビルディングが不可欠です。

僕は約1年前からスクラムマスターをやらせてもらっているのですが、チームビルディングをしていくにあたって最初はとても苦労しました。*1それは、チームビルディングに「銀の弾丸」はなく組織 / 現場毎に課題や状況の変数が異なるため、教科書通りにやってみても上手くいかないケースが多いからだと考えています。*2

それでも1年間続けてみてある程度形になってきた部分もあるので、本エントリーでは書籍を読んだり勉強会に参加したり他社さんの事例を聞いたりして、実際に僕がコネヒトで実践しているチームビルディングのワークショップを4つ紹介したいと思います。なお、それぞれのワークショップ単体でも一つの記事が書けるほど奥深いワークショップですので、今回は概要のみに留めさせていただきます。

KPT

最初に紹介するのはKPT(読み方: ケプト、ケーピーティー)です。こちらは日本のスクラム開発現場でも多く取り入れられている手法ですので、ご存の方も多いかもしれません。

KPTは振り返りのためのフレームワークで、流れとしてはまず最初に「Keep」としてよかったことや今後も続けたいことを挙げます。次に「Problem」として、よくなかったことを挙げます。そして、最後にKeepをよりよくする、もしくはProblemを改善する「Try」を挙げます。なお、挙がったTryを全て取り組むのは難しいことが多いため、取り組むTryは話し合って決めます。

KPTはフレームワークに沿えば比較的容易にプロセス改善のPDCAを回すことができ、また導入している現場も多いため、振り返りをしたことがない現場へ最初に導入するワークショップとして非常にお勧めです。

コネヒトでの利用シーン

  • コネヒトでは最もよく利用されているワークショップで、主にスプリントの振り返りとして活用されています。
  • また、みらい会議*3という全従業員が参加するような開発以外の会議でも活用されています。

注意点

  • 取り組むTryについて、コネヒトでは多数決で決める*4ことが多いのですが、合議制で必ずしもよいとは限りません。ですので、Tryの優先度をきちんとチームで見極める必要があります。
  • これはKPTに問題があるわけではないのですが、毎回同じ方法で振り返りをしていると飽きたり惰性で行なったりするようになってしまいます。ですので、コネヒトでは気分転換に違うワークショップを取り入れたり、KPT自体をカスタマイズしています。

様子

KeepとProblemとTryが張り出された様子です

学習マトリックス

次に紹介するのは学習マトリックスという方法です。KPTと似ているのですが、名前の通りアウトプットがマトリックスとして表現されるのが特徴的です。

こちらも振り返りのためのフレームワークで、流れとしては最初に「Good」としてよかったことを挙げます。2つ目に「Change」として変えたほうがよいことを挙げます。3つ目に「Idea」として新しいアイディアを挙げます。そして、最後に「Thanks」としてメンバーなどに感謝したいことを挙げます。

プロセス改善のPDCAを回すという意味ではKPTと同様ですが、斬新なアイディアを出しやすいこととメンバーに感謝を伝えられるので、場が暖まりやすいワークショップでもあります。

コネヒトでの利用シーン

  • KPTがマンネリ化している時の振り返りのワークショップとして利用されることが多いです。
  • 具体的には Connehito Marché という社外向けの勉強会の振り返りによく利用されています。勉強会の振り返りは普段のスプリントでの振り返りとは異なり日々継続的に改善していくものではないので、労いや感謝の言葉を伝える「締め」の場にもなっています。

注意点

  • 場が暖まりやすいワークショップなので、ややもすれば「なんとなくやった感」や「なんかいい感じ」で終わることがあります。ですので、やりっ放しにせず、きちんと次のアクションが打てるようにしましょう。
  • KPTに比べると、あまり事例が多くない(少なくとも日本では)ので、振り返りに慣れていないと少し苦労するかもしれません。少なくとも、ファシリテーターは何故学習マトリックスを利用するのかを語れるようにしておくとよいと思います。

様子

学習マトリックスの完成図はこんな感じです

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

3つ目に紹介するのはドラッカー風エクササイズです。ちなみに、ドラッカー風のドラッカーはかの有名な ピーター・ドラッカーさん から取られています。ドラッカー風エクササイズは一言で言うと、期待値調整と相互理解のためのワークショップです。

コネヒトでは 原案 を少しアレンジして運用しており、具体的にはワークショップの参加メンバーは以下の質問に答えながらワークショップを進めていきます。

  1. 自分の得意なこと
  2. 自分が期待されていること
  3. ◯◯さんに期待していること(チームメンバー全員)

これらの質問に答えることで、みんなが思っていることと自分が思っていることのギャップを認識することが出来ます。そして、チームとしてそのギャップを埋めていくことがこのワークショップの目的です。

コネヒトでの利用シーン

  • コネヒトではまだお互いのことがあまり分かっていない新チームの結成時や新規プロジェクトの開始時によく利用されています。
  • チームビルディングとの文脈ではないので本エントリーでは触れませんが、インセプションデッキの作成と同じくらいのタイミングで実施するのが個人的には好きです。

注意点

  • 率直な発言を引き出すために、比較的心理的安全性の高さが求められるので、ファシリテーターは楽しくワイワイ出来るような場作りに努める必要があります。
  • また、やりっ放しにならないようにこのワークショップで出た付箋などは普段から見えるところに置いておきましょう。

様子

ワークショップで集まった付箋はみんなのデスク近くに置くようにしました

スタート・ストップ・コンティニュー

最後に紹介するのは、スタート・ストップ・コンティニューです。実はこのワークショップはまだ1回しか試したことがないのですが、けっこう面白かったので最後に取り上げたいと思います。コネヒトでは振り返りのワークショップとして導入しましたが、それ以外のシーンでも活用出来るのではないかと考えています。

元ネタは僕が大好きなNetflixなのですが*5、コネヒトでは個人にフォーカスした振り返りとして実施しました。

具体的には下記の3つの項目をチームメンバー全員にフィードバックします。

  1. 始めて欲しいこと
  2. 止めて欲しいこと
  3. とてもうまくいっているので続けて欲しいこと

一緒に頑張ったチームメンバーから率直なフィードバックを貰うことで、次の仕事に活かすのが狙いです。

コネヒトでの利用シーン

  • 先述の通りまだ1回しか試していないのですが、とある開発チームの最後の振り返りに利用しました。
  • Netflixでは相手に改善して欲しいことがあれば、上長ではなく本人に面と向かって言うという文化が根付いていて素晴らしいなと思うので、コネヒトでも利用頻度を上げていきたいなと思っています。

注意点

  • チームメンバーが充分にラポールを形成していたり信頼関係を築いていたりする必要があるので、プロジェクト初期では避けたほうが無難です。
  • つまり、ドラッカー風エクササイズより高い心理的安全性が必要になります。個人的な工夫としては、チームメンバーに遠慮がないことと思いやりがないことは違うよ、というようなことを事前に伝えています。

様子

最後はみんなのフィードバックをもとに最優先するスタート・ストップ・コンティニューを決めました

まとめ

さて、ここまで主にファシリテーターとして僕がよく実践しているワークショップを4つ紹介してきましたが、コネヒトではこれ以外のワークショップもたくさん実践しています。それは、コネヒトの開発メンバーが日々のプロセス改善をジブンゴト化しているからであり、その時々の状況にあった方法を模索しているからです。

冒頭でも述べたようにチームビルディングに「銀の弾丸」はありませんし、極論ですが、僕はチームビルディングの「How」は何でもいいと思っています。大切なのは、何故その「How」を取り入れるのか?その背後にどういう課題や問題意識があるのか?をきちんと自分で語れることだと思います。ただ有名な会社がやっているから真似してみたとか、教科書に載っていたから採用してみただけでは意味がありません。*6ですので、思考停止せず、自分たちに合った「How」を「Why」から考えることがよりよいチームをつくるための最初の「一歩」だと僕は考えています。

というようなことを、僕はスクラムマスターの経験を通じて、今年学ぶことが出来たので、2019年もコネヒトはよりよい開発組織になれるように引き続き試行錯誤していきたいと思います!

参考サイト / 文献

*1:今も試行錯誤の日々ですが、特に最初は慣れていなかったので大変でした。

*2:僕自身の力不足もあると思いますが…!

*3:コネヒトのちょっと先の未来についてみんなで課題抽出と解決案の検討を行う会議のこと。

*4:カラーコードドットという方法を採用しています。

*5:Netflix社が具体的にどういう方法で実践しているかは不明。ご存知の方がいましたら教えてください…!

*6:もちろん、最初の一歩として参考にするのはGoodだと思います。

Kotlin IDE Pluginに共通で定義管理できるplugin-common.xmlが出来ていた

f:id:tommy_kw:20181223172957p:plain

はじめに

本記事はコネヒト Advent Calendar 2018の24日目のエントリーです!

qiita.com

メリークリスマス!Androidエンジニアの富田です。今回はKotlin IDE PluginのKontributeに関する小話で、plugin-common.xmlが生まれてちょっとだけめんどくさい作業が減ったよという内容を紹介します。

Kotlin IDE PluginのKontributeって?

以下のようなCode InspectionIntentionなどの機能についてのKontributeを表します。 f:id:tommy_kw:20181223105545g:plain github.com

詳しい内容については割愛させていただきますが、Kotlin IDE PluginやKontributeについて興味を持った方はぜひ、しらじさんの下記資料をご覧ください! photos.google.com

Kontributeする上でここが煩わしかった

github.com

改めて上記のPRを見ていただくと、複数のplugin.xmlが存在することに気づきます。Kotlin IDE Pluginを開発する上でIntelliJ IDEAとAndroid Studioに対応しなければならないため設定情報(今回はInspection情報)を複数のplugin.xmlに記述する必要がありました。

gist.github.com

以前は上記の設定を下記全てのplugin.xmlに追加していました。ファイル数が多いため自動で追加するGradleタスクがないのかなと探してみたものの、結局なさそうだったのでどうしたものかなと悩んでいました。

  • plugin.xml
  • plugin.xml.173
  • plugin.xml.181
  • plugin.xml.183
  • plugin.xml.as31
  • plugin.xml.as32

KotlinConf 2018にて質問してみた

今年10月に開催されたKotlinConf 2018にて、JetBrainsの方に自動で生成するGradleタスクはありますか?と質問したところ、ないですよという回答を頂きました。それから引き続き愚直にコピペを繰り返していると、10/22にplugin.xmlがリファクタリングされて、plugin-common.xmlが生まれていたことに気づきました!

github.com

各plugin.xmlに以下のようにplugin-common.xmlをincludeすることで共通化されます。Gradleタスクを用いて自動で生成することしか考えていなかったので、なるほど!と勉強になりました! gist.github.com

さらにidea/src/META-INF以下で管理されていたplugin.xmlなどのリソース周りはidea/resources/META-INF以下に移動されていました。移行スクリプトってこう書くのねとコードを読むだけでも面白かったので興味のある方はぜひ! github.com

plugin-common.xmlが生まれてどうなったの?

github.com 上記は先月出したPRになりますが、plugin-common.xmlだけ設定していることがわかります。煩わしい作業が減ってちょっと楽になりましたね!

まとめ

簡単にではありますが、最近のKontribute事情を紹介しました。やっぱりわからないことはカジュアルに聞かないとダメだなと反省しつつ、引き続きKontributeを続けてアウトプットしていきます!

qiita.com

明日最終日のコネヒト Advent Calendar 2018はいとしょさんになります!お楽しみに!

プロダクション環境ですぐに活かせそうなAWS re:Invent 2018のSageMakerアップデート5選

f:id:tatsushim:20181223233656p:plain

時間のない方向けにざっくり言うと

  • 11月にSageMakerのお話で登壇したけど、12月のAWS re:Invent 2018でたくさんアップデートがあった
  • 既存機能の強化に留まらず、「データの準備」から「モデルの変換」もサポートされるようになり、SageMakerの守備範囲がグッと広がったアップデートだと感じた
  • この投稿はその中でもママリのプロダクションですぐに活用できそうな5つのアップデートについて内容をまとめた

この記事はコネヒトアドベントカレンダーの23日目の記事です。 qiita.com

こんにちは!

CTOの島田(@tatsushim)です。
先月11/1「AWS dev day」に登壇させていただきました。 そのときの資料はこちらです。

現場で用いたSageMakerについて発表させていただいたのですが、私の発表の翌月にre:Inventがあり、SageMakerも大きくアップデートがありました。
今回は、プロダクション環境ですぐに活かせそうなAWS re:Invent 2018のSageMakerアップデートを5つご紹介します。

5つのアップデート

1. データ準備サポートツールの追加( Amazon SageMaker Ground Truth )

  • 「この画像は犬の画像であるか、そうでないか」を分類するタスクがあるとします。これを機械学習によって分類するためには、まずはじめに「この画像は犬ある」というラベルが付いた画像と「この画像は犬ではない」とラベルが付いた画像が必要です。
  • こうした状況で、データ(この例では画像)に対してラベル付けを支援するのがAmazon SageMaker Ground Truthで、利用するメリットは下記の2つです。
    • ①: ラベリングツールがAmazon SageMaker Ground Truthで提供されるため、ラベルをつけるツールの購入・自作・管理が不要
    • ②: S3にラベル付けしたいデータをアップロードして、Amazon SageMaker Ground Truthでラベルをつけると結果がS3にあがるため、データの管理が明確
  • また、一部のデータを人の手でラベル付けした上で、その元データから自動で付与するような機能も存在しています。

2. Gitのインテグレーション

  • SageMaker上でGitリポジトリを登録しておけば、ノートブックインスタンス起動時にリポジトリがgit cloneされるようになりました。
  • 今まではコンソールからGitを利用するか、Jupyter Notebookで書いたコードを手動でGit管理する必要がありましたが、JupyterLabのGit extension設定がデフォルトでされる形になるので、視覚的な管理が可能になりました。

3. 学習・推論用コンテナのアップデート

  • TensorflowコンテナがPython3に対応しました。
    • (日本語処理をしてる側からすると嬉しいアップデート!)
  • scikit-learnのコンテナが追加されました。
    • ただしほとんどのアルゴリズムで分散学習に対応してないため、学習は単一インスタンスで行うことになると思います。

4. 学習ジョブモニタリングのサポート

  • 学習時のモデルの精度をグラフ化できるようになりました。
    • 正規表現でルールを書いて、標準出力から精度を抽出する必要があります。
  • ビルトインアルゴリズムの場合は最初から設定されているので正規表現は不要です。
  • 注意点としては、1分おきのメトリクスになっている点です。現状の仕様ではこれは1分未満はできないそうです。

5. 推論時にGPUの部分的な利用をサポート( Amazon Elastic Inference )

  • GPUリソースをEC2やSageMakerのインスタンスに一部割り当てることができるサービスのようです。
    • (最初何言ってるかわからなかった)
  • イメージとしては、PythonでボトルネックになってるところをCythonで書くみたいな感じで、コードとしてGPUを使用する箇所を明記することで、そこだけGPUを利用してくれるようです。
  • こちらにサンプルコードがありますので、イメージとしてはこちらをご覧になっていただくのが良いかと思います。
  • 画像分類の推論をリアルタイムで処理したいニーズには便利です。

終わりに

他にも強化学習、DeepRacer、AWS Marketplace for Machine Learningなど触れたい部分はたくさんあるのですが、今回は比較的すぐに実応用可能なアップデートに絞って内容を共有させていただきました。
機械学習の分野でますます活用が増えていくであろうSageMakerには今後も注目ですね。
以上、島田(@tatsushim)がお送りしました!
今年も、ここまで1日も切らさずにコネヒトアドベントカレンダーは続いております。ここまで継続してくれているメンバーに感謝です。
明日は富田(@tommykw)さんのターンです!

DockerとJavaScriptの付き合いかた

f:id:dachi023:20181220161955p:plain

こんにちは。エンジニアの安達 (@dachi_023) です。会社用アカウントとして @ry0_adachi を用意していましたが全然呟かなくなっちゃったので辞めました。複数アカウントの運用って面倒ですね...。はい、コネヒト Advent Calendar 2018 の20日目はDockerとJSです。

まえがき

DockerfileにJS (とかCSSとかHTMLとか) のビルド処理を書いてコンテナ立ち上げてブラウザで見えるところまでの話です。

本記事では最低限これができていればそんなに遅くならないよねってものをいくつか書いています。コードは GitHub に上がってますのでそちらを見ていただいてもOKです。このコードは create-react-app で生成したものをビルドしてコンテナ上のNginxで公開するという簡単なものですが、実際にママリのProduction環境に投入したものもJSに限って見てみればやってることはほとんど一緒になったので、この手の問題はあんまり難しく考えないほうがいいんだろうな、というのが現状の結論です。

今回はやってませんがSSRする場合は他にも考慮すべき点がありそうなのでもうちょい複雑かもなと思ってます。

Dockerfileを書くときに気にしてること

めちゃくちゃ普通なんですけど一応書いておきます。

  • キャッシュをなるべく使えるようにする
  • イメージのサイズを小さくする

JS起因でDockerのビルドが遅いのはだいたいインストールとビルドのせいなのでキャッシュが効くべき時に効くのが大事そうです。あとはイメージサイズを小さくするためにどのイメージを使うかとか、ビルドの過程で使ったツールなどをイメージに含まないかとか、そういうのを意識してます。

たとえば

上記は GitHub に上げたDockerファイルですがこの12行だけでも気にしてることを満たせているはずです。

  • yarn [install] でキャッシュを効かせたいので実行前にCOPYしてくるのは package.jsonyarn.lock だけにして、ビルド時に使うものはその後にCOPYしてくる
  • multi-stage build を使うことでnode_modulesやビルド前のファイルなどを最終イメージに残さない

実際にdocker buildした結果はこんな感じです。

キャッシュ無

$ time docker build -t dachi023/docker-create-react-app:test .
real    1m5.287s
user    0m0.375s
sys 0m0.249s

フルキャッシュ

real   0m2.172s
user    0m0.165s
sys 0m0.116s

一部キャッシュ (JSのコードを編集)

real   0m18.399s
user    0m0.229s
sys 0m0.147s

あとは $ docker run -itd --name docker-create-react-app -p 8080:80 dachi023/docker-create-react-app:test などとやると起動までちゃんとするのでサクッと何かを作りたい時などにご活用ください。

まとめ

キャッシュが効いててイメージが軽ければ開発時のストレス減りそうだね、というお話でした。アプリケーションが複雑になっても基本この2つがブレないようにしていればいいのではないかと思ってます。Dockerチューニングでやれることはまだあるかと思いますが、まずは効き目のある部分からやっていきましょう!

明日は nkuroda さんの引っ越し話です!技術が絡んでくるかもしれないし絡まないかもしれません、ご期待ください! 👋