コネヒト開発者ブログ

コネヒト開発者ブログ

Connehito Marché #2 ~webフロントエンド市~ を開催しました!

f:id:dachi023:20180522145017j:plain

こんにちは。エンジニアの安達(@ry0_adachi)です。先週金曜日(2018.05.18)にコネヒトマルシェの第2回を無事開催することができました 🎉せっかくですのでイベントの様子やLTの内容などを本記事でレポート、ご紹介させていただきたいと思います。

connehito.connpass.com

今回のマルシェのテーマ

今回は「webフロントエンド」がテーマです。

ちなみにコネヒトマルシェでは毎回テーマを変えており、前回はAndroidでした。

発表内容

ママリのweb技術の今と未来

3行まとめ

  • ママリではいろんな機能でweb技術を活用している
  • ママリは負債と向き合いながらも前進している
  • 開発効率をあげてユーザーにたくさん還元していきたい

PWA概論

3行まとめ

  • PWAはネイティブアプリの代替手段ではない
  • ユーザーに浸透するまではまだかかりそう
  • PWA対応は機能ごとに1つずつやっていくことが可能

安全にデータを扱うコードの書き方

(資料公開なし)

3行まとめ

  • ES2015よりも前の時代はなんでもアクセスできちゃってた
  • constの登場によって取り扱いが容易になった
  • データはImmutableで扱うことでより安全にデータを扱えるようになる

Don't kill a dragon Rescue the princess (react + golang E2E TDD)

3行まとめ

  • APIが存在するアプリケーションでTDDを実践したい
  • 細かい改修のたびにモックの修正をしたくないのでユニットテストをやめてE2Eテストだけでやってみた
  • Client/API/DBなどのレイヤーで分けるのではなく機能ごとに分担して開発していくことでE2Eをやりやすく

30代から始めるwebフロントエンド入門

3行まとめ

  • 数年ぶりにJavaScript触ったら世界が変わってた
  • 初心にかえり、片手間でやらずに覚悟を持って向き合った
  • 何かを始めるのに年齢は関係ない!

懇親会

f:id:dachi023:20180522195102j:plainf:id:dachi023:20180522195109j:plain

今回は美味しいサンドイッチとお酒を手に乾杯しました。参加者の方々は登壇者の方に質問や感想を伝えていたり終始楽しそうな雰囲気で幕を閉じました!

次回開催は?

7〜8月頃の開催予定です。お題はまだ決まっていません!諸々決まったらconnpassTwitterなどで告知します 🙇

"@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_)です。

https://cdn.mamari.jp/authorized/amana_5ab65cf0-f200-4d16-a7b6-0017ac120004.jpg

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

マイホームヒーロー

マイホームヒーロー

コネヒトでは自由なソフトェアへの貢献活動に取り組んでいるメンバーも多いのですが、年末くらいから社内でもソフトウェアの開発を進めるなどしておりました。
そして、やっとこさ「最低限公開できる形にはなったかな〜」というとこまで進んだ次第です。
ということで、本日はそんな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です!」というテーマで、みなさんの新鮮なネタ(ナレッジやノウハウ)をおすそ分けしていただきました!

f:id:tommy_kw:20180206110633p:plain

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 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のソースコードも公開されています!
  • 利用したツールはPostmanCharlesChrome 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-corecoroutines-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に登壇しました!~ 日本のママをコンテナで支える ~

f:id:tatsushim:20180201184240j:plain

こんにちは!

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)がお送りしました!