"@connehito/eslint-config" をnpmで公開しました

こんにちは。エンジニアの安達(@ry0_adachi)です。

今回は社内で利用しているESLintの設定ファイルを @connehito/eslint-config という名前でnpmに公開したので、公開しようと思った理由なども含めて書いていきます。

ちなみに、これが初のコネヒトという会社名義でのnpmへの公開となります🎉 www.npmjs.com

公開する前のお話

公開しようと思った理由

npmに上げるまでは各リポジトリに同じような内容の .eslintrc が存在していて、どこかのリポジトリの設定を更新したら「あっちも同じように更新したいな」となり、それをまた別のリポジトリでやって...というような感じでとても面倒でした。そして各リポジトリにあった設定は「同じような内容」であって「全く同じ」わけではなかったのでこれもまた私の作業をより面倒にしていました。

面倒な作業を早く簡単にしたい！設定はどのリポジトリでも一緒でいいのでは！という思いが強くなっていき、それで今回npmに公開して各リポジトリでnpmから落としてくるだけのフローにしました。

公開するまでにやったこと

• ESLintの設定を見直す
• npmのOrgを作成する
• 会社名義でpublishするときのルールを決める

あたりが事前にやった作業です。

ESLintの設定を見直す

各リポジトリで微妙に設定が違ったりしていたのもありましたし、その時はPrettierのようにコードフォーマットをお任せできるようなものが入ってるわけではなく、rulesの中には2年前くらいに考えた大量のオレオレルールの記述がされていて、どれがどういうルールなのかを覚えているのも大変でした。

そんな理由から既存のオレオレルールはなくしたかったので、extendsだけでなるべく完結させることにして、あとはGitHubやエディタ上でいい感じの見え方になるような最低限の設定(1行の最大文字数、セミコロンつけるつけない、クォートの種類)だけにしました。

これでどんなルールを設定したか覚える必要もないですし、ESLint本体やpluginをアップデートすればextendsしているrecommendedな設定が更新されていくので最高です。

github.com

npmのOrgを作成する

https://www.npmjs.com/org/create からOrganizationの作成ができるのでぽちぽちやっていきます。実際作った時には間違えて通常アカウントで作ってしまったのですが、有難いことに通常アカウントをOrgに変換する機能がついていたのでなんとかなりました、よかったです。

会社名義でpublishするときのルールを決める

npmに公開したい〜！な人が現れた時のためにアカウント作成やscopeの統一(パッケージ名に@connehitoとか入ってるところ)、publishする時に気をつけることなどを社内ドキュメントにしました。私だけでなくいろんなメンバーに気軽にチャレンジしてもらいたい、という思いを込めて作成しています。

公開した後のお話

公開したあとは各リポジトリに @connehito/eslint-config をインストールして .eslintrc の内容を修正したのちに、各アプリケーションの実装や環境に合わせてenvやglobalsを上書きしました。

---
extends:
  - "@connehito"

公開後の各リポジトリのメンテナンス

@connehito/eslint-config を更新したら各リポジトリで yarn upgrade して eslint --fix するようになりました。設定いじらずにとりあえずコマンド打てば良い状況になったので、あとはCIで定期的に回すなどして自動化できると良いなぁと考えています。

さいごに

npmで公開した経験があまりないので今更ですがkeywordの設定とか依存関係の書き方とかもっとスマートな書き方があるんじゃないかという気がしてきました。気付いた点などあればissueなどでもらえるとものすごく嬉しいです！日本語でももちろんオッケーです！

たくさんの人に見てもらえる場所でたくさんフィードバックをしてもらえる方が作った側としては有難いし嬉しいので、今後も公開できそうな便利なものがあればどんどん公開していこうと思っています。

データ民主化の実現とRedash

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

今回は、ここ数ヶ月で進めていたコネヒト社でのデータ民主化について書こうと思います。 ※技術的な話はあまりなく、社内向けプレゼンに使った資料をベースにした内容です。

コネヒト社は、ママリというママ向けのアプリとWebを運営しており、 もちろん様々なデータを持っているのですが、データ活用に関して下記のような課題を抱えていました。

データに関する課題

1. データが色々なところに存在している

BigQuery,Mixpanel,GA,RDS等様々な場所にデータが点在しているので一望する事が難しく、どこに何があるのかも一部の人しかわからない。 tableau経由で様々なデータソースにアクセス出来る環境はありましたが、その一部のメンバにデータ抽出を依頼する事がコストとなっていました。

2. エンジニアやデータに詳しいディレクターに頼まないとデータが出せない

1と少し近いのですが、データの場所も出し方もわからないのでデータ抽出をしたい時はデータ抽出依頼が必要となっていて、気軽に思いつきのデータを出してもらうのは敷居が高い状況でした。 また、データ抽出の得意なディレクタの時間がデータ抽出業務で逼迫されるという状況も起きていました。

3. 抽出データの保存先が多種多様でストックが出来ない

スプレッドシートやそれぞれのデータソースにグラフやデータが点在していました。 新しくジョインしたメンバは、中々データの所在が把握出来ない歯がゆい状態でした。

一緒に、データ民主化を進めていたエンジニアと話していたところ社内で下記のような悪循環が起きているのではという仮説立てをしました。

データとか使って検証できたら良し悪しを判断しやすい！
but
データ出せないと「高度に詰めて考えなきゃいけない」
but
「データを出す」には、人に依頼しないといけないから、「依頼コストが高い」という悪循環・・・

理想の姿

• データを出すことに対する敷居を下げる↓(データの民主化)
• 各担当領域でのアイデア出し/提案/改善に定量的な側面をもたせやすくして、みんな仕事がしやすくなるといいな
• 非エンジニアがSQLをある程度使いこなせている状態にもっていきたい 　

「もしデータがかんたんに自分で出せる」と
↓
「考えまくる前にデータ出してサクッと確かめてみよ」ができるから
↓
「アタリ」っぽかったら深掘りすればよい！ハズレだったら、すぐ忘れる

=> データの民主化が達成された世界は素敵！！
(&「データで考える」は慣れでしかないので、やっているともっと感じがよくなっていく

Redash

データ民主化の切り札となるBIツールにはRedashを採用しました。 Redashは様々なところで事例も出ていますので詳細は説明しませんが、 下記のような利点から導入を決めました。

データ閲覧のインターフェースを出来るだけ、統一することが一番大事だと思っていて、 よりよいものが出てきたらRedashから乗り換える可能性は大いにあります。

Redashの良いところ

• 出したデータをそのままビジュアライズ出来る
• SQLの再利用が出来る
• URLをそのままシェア出来る
• 通知やCSVエクスポートも可能
• スケジュール機能を使って定期実行も出来る
• 無料！！

技術的な面

• AWSのAMIが提供されている構築コストはほぼゼロ
• Google認証のみにすることでセキュリティを担保出来る
• Pythonデータソースがあるので、エンジニアのアイデア次第で何でも出来る
• 開発も活発で便利な新機能が追加されている

TIPS

簡単にデータソース間のjoinが出来る

データ分析をしていると、例えばマスタDBのデータとアクセスログをjoinしたいというようなケースが頻繁に現れます。 Redashでは、Query Resultsという機能を使うことで簡単にデータソース間のjoinが出来ます。

SELECT a.name, b.count 
FROM query_123 a 
JOIN query_456 b ON a.id = b.id

参照: https://redash.io/help/user-guide/querying/query-results-data-source

slack botの活用

Redashは標準で、slackのインテグレーションがあります。 https://redash.io/slack

RedashのクエリURLをslackに貼り付けるとそのままRedashでグラフが表示されます。 これのおかげで、一々画像キャプチャを撮ってslackに貼り付けるといった手間が省略出来ます。 また、slackのリマインド機能と連携することでslack上で簡単に定点観測が出来たりします。

クエリの再利用

Redashの良いところにクエリのフォーク機能があります。 いきなり自分で一からクエリを書くのは敷居が高いですが、 他の人のクエリを見て勉強したりコピペから少し変えてみるといった事ができ気軽に始められます。

現在の状況

ちょうど振り返りのような機会があり、社内で下記のようなフィードバックをもらいました。

• Redashを導入したことで見れる数字がめちゃ増えてる
• 本当にデータが民主化され、職種問わずみな興味を持っている
• データにアクセスしやすくなったので、視野が広がり実務に役立っている

ちなみに、12月にRedashを導入したのですが、現在600クエリ&80ダッシュボードが運用されています。 ひとまずデータを見ることの敷居を下げることはRedashの導入で実現出来たのではないかと思っています。

新しくジョインしたメンバも、Redashにログインすればどのようなデータがあるのかを一望し即座に分析を行うことが出来る状態になりました。

また、社内で有志のSQL勉強会が開かれていて実データを元に日々非エンジニアもSQL力向上を図るという流れも生まれました。

まとめ

今回は、社内でRedashを導入してデータ民主化を実現した話について書きました。 私自身、営業やディレクターが作ったクエリを眺めていると、自分にはない発想に出会ったり気づきがありますし面白いです。 データが、オープンであることはとても大切だなと実感しています。 今後は、ETL周りを整備して、より早くデータを出せるような基盤を作っていこうと思っています。

コネヒトではコンテナ周りの基盤を整備したりサービス改善を行うエンジニアを募集しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。

www.wantedly.com

CakePHP3用のSentryプラグインをオープンソース化したのでご紹介させてくださいね

こんにちは。サーバーサイドやっております(@o0h_)です。

マイホームヒーロー、どんどん盛り上がっていきますね・・！この後どうなるでしょう。

マイホームヒーロー

コネヒトでは自由なソフトェアへの貢献活動に取り組んでいるメンバーも多いのですが、年末くらいから社内でもソフトウェアの開発を進めるなどしておりました。
そして、やっとこさ「最低限公開できる形にはなったかな〜」というとこまで進んだ次第です。
ということで、本日はそんなOSSのご紹介をしたいと思います。

CakePHP3用の、Sentryプラグインです。
packagist.org

CakePHP3.6.0のbeta1が出たのでおさらいしてみる

あけましておめでとうございます！からもう2ヵ月が経ちました。
最近はあまり新しい漫画を読んでいなかったのですが、ザ・ファブルに手を出し始めました！

ザ・ファブル

サーバー側開発をやっております金城 (o0h_)です。

弊社ではWebApplicationは主にCakePHPを用いて開発を行っていますが、次期バージョンである3.6のベータ版がリリースされました。(おめでとうございます！🎉)

bakery.cakephp.org

そんなCakePHP 3.6.0-beta1について、予習をかねて覗いて見たいと思います。

みんなの「知りたい」「知ってる」をおすそ分け！Connehito Marché #1〜Android市〜を開催しました！

こんにちは

こんにちは！Androidエンジニアの富田です。先日、Connehito Marché #1〜Android市〜という勉強会を開催しましたので、そのLT内容を簡単にですがレポートさせていただきます！今回は、「Androidに関することなら何でも発表してOKです！」というテーマで、みなさんの新鮮なネタ（ナレッジやノウハウ）をおすそ分けしていただきました！

LT内容

CDC Testingをためしてみた

katsutomuさんのおすそ分け！

CDC Testingとは、コンシューマドリブンコントラクトテストと呼ばれています。マイクロサービスのテスト手法の一つでサービス間の連携が壊れていないことをテストできます。ConsumerとProviderという登場人物がいて、ConsumerをAndroidクライアント、Providerをサーバサイドと表現してその実行サンプルのデモがありました。

• CDC Testingでは、Pactツールが有名
• Pactのモックサーバを利用できる
• API利用者はリクエストに対して期待するレスポンスをContractファイルに定義できる
• ContractファイルはJSON形式のファイルで、API提供者にContractファイルを共有できる
• クライアントの良い点は、実装と仕様が同期できてAPI設計仕様について主体感がある
• サーバサイドの良い点は、破壊的な変更を検知できる。さらにpact_brokerを使うネットワーク図も作成できる
• サービスが拡大する中で導入するのは難しいかもしれないので検証が必要

Android Developer Toolsのバグを見つけて直してもらった話

kikuchyさんのおすそ分け！

Android Developer Toolsのバグを見つけて直してもらった話 from Hiroshi Kikuchi

Android Lintのバグに遭遇。kotlin.collection.Map#forEachが、java.util.Map#forEachと勘違いされる影響でAndroid Lintに怒られるので、Google Issue Trackerデビューをしてバグを直してもらいました。

• AndroidのIssue Reportについてはこちらを参照
• 類似のバグ報告を真似すると楽にレポートを作れる
• Issueに対して星が多いと目に留まりやすく対応してもらえる可能性が高くなる！
• 問題を再現するために小さなプロジェクトをzip添付すると良い
• 2018/1/12にバグ修正された！
• SDKでバグを見つけたら、どんどん報告していきましょう！

Androidでスクレイピングした話

futaboooさんのおすそ分け！

本を読んだ後に記録したい！でも読書管理するためのWeb版読書メーターはあるけど、Androidアプリがない...自分でAndroidアプリを作ってGoogle Playストアに公開しました！

• なければ作ればいい！
• BookLifeを作りました！
• BookLifeのソースコードも公開されています！
• 利用したツールはPostman、 Charles、 Chrome DevTools
• ハマったところは突然の仕様変更！新しいセキュリティでリクエストにtokenが必要になって調査に一週間かかった

LiveData❤️ViewModel

tummyさんのおすそ分け！

AACのLiveDataとViewModelがめっちゃいいよ！LiveDataとViewModelの組み合わせについての紹介でした。

• YAPC::Okinawaにも「GraphQLをプロダクション導入した結果」というテーマで登壇します！
• LiveDataは監視することができるデータでActivity/Fragment生きているときにアクティブになる
• ViewModelはUIに関するデータを保持・管理できて空のFragmentを持っていそう
• LiveDataのObserver#onChangedの引数は、@Nullableから@NonNullになる予定
• AS3.1でDataBinding + LiveDataサポート！

Firebase Cloud Functionsを使ってみた話

jyeganさんのおすそ分け！

Firebase Cloud Functionsを使ってみたお話。Flamingo社ではエンジニアが二人しかおらず、Firebase Cloud Functionsの利用についての紹介でした。

• Firebaseとは、Googleが提供しているmBaaSで、モバイルアプリを使う時に便利なサービスが提供されている
• Firebase Cloud FunctionsはJavaScriptで書いてNode.jsで実行される。Firebaseの他のサービスのイベントをトリガーにできる
• バックエンドの処理が短時間で実装できる
• Firebaseのドキュメント充実している
• JavaScript/TypeScriptで雑に実装していた。エラーハンドリングが難しい
• Firebase Cloud Functionsはまだベータ版なので、大規模には難しいかも

OkHttp3とRetrofit2そしてコルーチンを組み合わせて非同期通信を実現するお話

Yoshihisaさんのおすそ分け！

APIを叩くAndroidアプリではOkHttp、Retrofit、ReactiveX(Rx)を使うとコールバック地獄に陥りやすい。Coroutineを用いてコールバックから脱したい...こんな感じで書きたい！

try {
    val info = api.getInfo()
} catch (e: Exception) {
    Toast.makeText(this, e.toString(), Toast.LENGTH_LONG).show()
}

• Coroutineは、中断・再開が可能な関数
• Coroutineは、現時点ではexperimentalだけど、1.3ではexperimentalが外れる予定
• gradleにcoroutines-core、coroutines-androidを導入すれば、kotlin.coroutines=enableは不要
• adapterはJake神のretrofit2-kotlin-coroutines-experimental-adapterを使うと良い
• Coroutine時代に備えて今から勉強しておこう！

Kotlin Issueを投げてみよう!

富田のおすそ分け！

Android版ママリのPRレビューの指摘からKotlin改善のヒントをもらい、それを基に初めてKotlinのIssueを投げて受理されました。

• KotlinのIssue管理はYouTrackで行われている
• Androidアプリ開発でKotlinを触っていると、意外と改善Issueが見つかる
• 実際に投げたKotlin Issueはこちらです
• 分からないことがあれば、Kotlin SlackチャンネルやStack Overflowで質問することが一般的なようです
• Kotlin Issueを投げてみよう！

最後に

コネヒトで初の社外勉強会でしたが、LT（知ってる）枠、オーディエンス（知りたい）枠のご参加のみなさんや運営に協力してくださった方々のおかげで無事開催できました！ありがとうございました！！Connehito Marché はAndroidのテーマだけではなく、いろいろなテーマで継続的に開催していきますので、ご興味があれば立ち寄ってみてください！

【資料公開】X-Tech JAWSに登壇しました！~ 日本のママをコンテナで支える ~

こんにちは！

CTOの島田(@tatsushim)です。 先日「X-Tech JAWS 【第2回】~9割のX-Techと1割の優しさで切り拓く未来~」に登壇させていただきました。 xtechjaws.doorkeeper.jp 約100名の参加者が集まり、他の方の発表もとても面白かったです！

発表資料

私の発表資料はこちらにアップロードさせていただきました。
ぜひ以下をご覧いただければと思います。

発表後の会場アンケート

X-Tech JAWSでは会場アンケートをとっていて、登壇するとその発表に対しての感想をいただけます。
発表者としてフィードバックをいただけるのはとても嬉しい仕組みですね。
以下のようなお声をいただき、とても嬉しかったです！

• 未だにEC2中心のレガシーな構成が多い弊社には刺激的な内容でした
• スタートアップ立ち上げ時の歴史と苦労点と解決までのアプローチが非常に興味深かった
• シングルEC2って漢の構成でビジネスをはじめて成功したって、なかなかすごいですね
• ECSに持って行くまでの現実の困りごとが丁寧に説明されていてとても参考になった
• コンテナをチームで育てるというのは自分の仕事にも使える考え方に感じました
• 自身はAWSの販売側の立場なのですが、Consumer向けアプリ業界における課題やその解決策としてAWSの効能について知識を得ることができとても参考になりました
• 情報共有の話が身にしみた

終わりに

発表資料でも触れましたが、2018年は「インフラエンジニアの仕事をなくす」をテーマにコンテナ・インフラ技術を「チームで育てる」ものにして自分たちの仕事をなくすところまでやり切りたいと思います。
X-Tech JAWS運営の皆様、会場にお越しいただいた皆様、有難うございました！

以上、島田(@tatsushim)がお送りしました！

みんなの「知りたい」「知ってる」をおすそ分け！ Connehito Marchéを開催します！

活気のあるマルシェのイメージ

おはようございます。こんにちは。こんばんは。

Good morning. Good afternoon. Good evening.

最近毎日Mr.Childrenの「here comes my love」を聴いているサーバーサイドエンジニアの @itosho です。

今日は勉強会のお知らせをさせていただきます。はい、宣伝です。

「なんだ、宣伝か（そっ閉じ）」と思ったそこのあなた！そう、あなたですよ！

取り立てて有益な情報は提供出来ないかもしれませんが、これも何かの縁だと思って最後まで読んでいただけると幸いです。

いつどこでなんの勉強会をやるの？

一言で言うと 2月1日、木曜日、19時から白金高輪にあるコネヒトのオフィスで、Androidの勉強会 を開催します！

勉強会の詳細については、下記のconnpassのページをご覧いただければと思いますが、せっかくなのでここでは、勉強会のタイトルにもある「Connehito Marché」（コネヒトマルシェ）に込めた想いについて、少しお話させていただければと思います。

connehito-marche.connpass.com

Connehito Marchéのコンセプト

タイトルにもある通りConnehito Marchéは、みんなの「知りたい」「知ってる」をおすそ分け！をコンセプトにした参加者が主役の勉強会です。

勉強会をマルシェ（市場）に見立てて、新鮮なネタ（ナレッジやノウハウ）を提供したり、仕入れたりしながら、みんなが和気あいあいと交流出来る活気に満ちた勉強会を目指しています。

ですので、基本的にはLT（Lightning Talks）を勉強会のメインコンテンツとし、参加者の方には普段の業務などで得た学びや苦労をみんなに「おすそ分け」していただきたいと考えています。

そして、また「おすそ分け」された人がまた誰かに「おすそ分け」をすることで、コミュニティが循環していけばいいな、なんてことも考えています。

ちなみに元々は、弊社サーバーサイドエンジニアの金城発案の元、チームのナレッジ共有の場として、お昼休みを利用しながら、社内LTという形で行っていたのですが、このたび、もっとたくさんの人と交流したいと考え、オープンな場として開催することになりました。*1

誰でも参加していいの？

はい、そのテーマに興味がある方でしたら、誰でもOKです！初心者の方も大歓迎ですし、LTの内容も仕事じゃないけど「趣味でこんなことやってます〜」といった内容でも構いません。個人的には、勉強会は話を聴くだけではなく、発表もしたほうが得るものは多いと思っているので、LT枠の方が増えると嬉しいなと思っています。

「こんなの誰でも知ってるだろうし、大したことないだろうなぁ」と思うことでも、あなたの「知ってる」を「知りたい」人は必ずいると思うので、ちょっとでも「LTしてみようかな…」と思った方は、是非LT枠でのご参加をお待ちしています。LT未経験でも全く問題ありません。むしろ、このマルシェをLTの練習に使ってください！*2

とは言え、いきなりLTなんて「怖いよおおお」「無理いいい」って方もいらっしゃると思うので、そういう方は無理せずオーディエンス枠で参加してください。一番寂しいのは人気のないマルシェなので、仕事帰りに「お、やってるやってる」みたいなテンションで、ふらっと気軽に寄っていただければと思います。

毎回Androidがテーマなの？

いえ、テーマは毎回変えます。まだ未定ですが今後は、iOS、Webのフロントエンド、サーバーサイド（アプリケーションレイヤー）、インフラ領域のテーマでも開催させていただく予定です。頻度も検討中ですが、最低でも四半期に1回くらいのペースでやっていきたいと考えています。

意気込み

…とここまで読んで「やっぱり有益な情報ねぇじゃねぇか！」と思ったそこのあなた！勉強会当日はきっと有益な情報だらけだと思うので、是非Connehito Marchéへの参加をお待ちしております！

connehito-marche.connpass.com

*1:余談ですが、都知事の「築地も豊洲も生かす」ではないですが、クローズドなマルシェも継続しています。

*2:社内で開催しているマルシェはLTの練習も兼ねています。