ReproUserMeetup#1にて登壇してきました!

みなさんはじめまして! BUYMAiOSアプリのエンジニアを担当している、松本と申します!

先日6月2日に行われたRepro User Meetup #1に登壇してまいりましたので、その様子をお伝えします!!

Reproとは?

Reproとはアプリに特化した、アナリティクスツールです。従来のツールと大きく違う点は、ユーザーの行動を動画で確認をできる点とリテンション分析・ファネル分析といった機能によってユーザーの重要な行動を細かくトラッキングできる点です。詳しくは、ReproさんのHPをご覧ください

当日の様子

IMG_4506 当日はReproを活用されている10社様が登壇され、様々なReproの活用法や成功事例が発表されていました。各社様の発表内容はコチラから

BUYMAでのRepro活用

IMG_5837 新規ユーザーにまず継続的にアプリを使用していただくことは、どのアプリにおいても非常に重要な事と言えると思います。

Reproのリテンション分析では、特定のアクションを行ったユーザーのリテンションを測定するといったことも可能であり、今回のRepro User Meetupでは新規ユーザーに対して最も効果的なイベントをどう判断するかという事について発表を行わさせていただきました。

詳しい内容はこちらのスライドをご覧ください!

IMG_5472 Repro株式会社取締役CMOの中濱 康広様(中央)と弊社松本(左)と松永(右)

BUYMAの商品検索を支えるSolrCloud

お久しぶりです。アプリケーションエンジニアの木村です。

BUYMAでは、この記事を書いている時点で世界中から出品された約155万件の商品が検索可能となっていて、商品検索機能は世界中から自分の欲しい物を探すことを実現する、まさに「世界を買える」を実現するための重要な機能の1つとなっています。今日はそんなBUYMAの検索機能の裏側を支える基盤部分についてご紹介いたします。

BUYMAでは検索機能実現のためにはSolrを導入していて、さらにSolrCloudを構成しています。

SolrCloudとは

SolrCloudは、高信頼性、耐障害性、拡張性を運用コストを抑えつつ実現するSolrのクラスタリングの仕組みです。紙面の都合上あまりSolrCloudについて詳しく説明できませんが、下記リンクが参考になるのではないでしょうか。

あまりWeb上に詳説された記事がないので、下の書籍も参考にしつつ構築にとりかかりました。

-『Solr in Action』Trey Grainger-Timothy Potter (2014) Manning Publishing. -『改訂新板 Apache Solr 入門』大谷純-他(2013) 技術評論社. -『Scaling Apache Solr』Hrishikesh Vijay Karambelkar (2014) Packt Publishing. -『ZooKeeperによる分散システム管理』Flavio Junqueira-Benjamin Reed [著]、中田 秀基 [訳] (2014) オライリー-ジャパン

さらに、上の2つ目の本も監修されているロンウィットさんのトレーニングも受講しました。最後の本はSolrCloudに組み込まれるZookeeperの本です。

BUYMAでのSolrCloudの構成

BUYMAのでのSolrCloudの構成を表したものが下の図になります。

SolrCloud

更新のしくみですが、Solrを更新するバッチが常に動いていて、DBから更新がかかった商品情報を取得し、leaderのSolrノードへ更新リクエストを送ります。するとSolrCloudの仕組みとして、leaderノードが他のreplicaノードへ更新を伝えて全ノードが更新されます。

検索はRailsのWebサーバーから直接SolrCloud内のSolrノードへリクエストします。特にロードバランサー用のサーバー等は挟まず、SolrノードのIPをランダムに選び、そのIPへリクエストを飛ばすように、Railsアプリ側でロードバランシングしています。

耐障害性への取り組み

RailsのWebサーバーから直接SolrノードのIPへ検索リクエストが飛びますが、各SolrノードのIPアドレスはそれらを監視しているZookeeperから取得しています。したがって、いずれかのSolrノードで障害が起こった場合でもそれをZookeeperが感知し、リクエスト可能なIPの一覧からダウンノードのIPを外してくれ、ダウン中やリカバリ中のノードへは常にリクエストが振られない仕組みになっています。

更新時も更新バッチがZookeeperからleaderであるSolrノードのIPを取得し、それに対して更新リクエストを飛ばしています。もしleaderノードで障害が発生し、フェールオーバーして別のノードがleaderとなった場合でも、Zookeeperがそれを感知して更新バッチ側へleaderの変更が伝わる仕組みです。

実は、Zookeeperと連携してそこらへんの面倒な処理をやってくれるSolrJというSolrCloudにも対応したJava用のSolrクライアントがあるので、JVMのWebアプリではそれを使ったり、そうでない場合はSolrJを使ったAPIサーバーを検索クライアントとSolrとの間に挟む構成が通常なんだそうです。ただ、そのためのサーバーの運用保守もコストなので、RubyからZookeeperと連携するSolrCloud用のRubyクライアントを自分たちで作りました。gemとして公開していますので、ご自由にお使いいただいてフィードバック等をお待ちしております。

https://github.com/enigmo/rsolr-cloud

BUYMAの検索基盤クロニクル

BUYMAがシステム面で今の形に近いものに生まれ変わったのは2008年ごろ(らしいの)ですが、その当時公開されていたSolr 1.3系の時代から検索機能にはSolrが導入されていました。その後2011年に3.x系へとバージョンアップがなされ、2015年6月まで稼働していましたが、商品数の増加とマスキャンペーンにより大量のアクセスが予想されたため、マシンリプレースと合わせて2015年リリースされた5.x系へとバージョンアップしました。さらに、運用し易さを求めて、構成をSolrCloudとしました。

SolrCloud導入以前は、マスタースレーブ構成でもなく、Solrノードを並列にならべてそれぞれのIPアドレスを更新-検索クライアントとなる全サーバーに固定値で持たせていました。更新バッチは全Solrノードへ同じ更新リクエストを何度も送る必要があり、1ノードでも更新に失敗すれば検索結果がノードによってズレてしまいました。Solrノードでの障害発生時やメンテナンス時にもそれぞれのサーバーのSolrノードのIPを書き換えてやる必要がありました。商品数やアクセス数の増大に伴って、この先ノード数を増やす場合にこの構成では限界を感じていました。また、仮にマスタースレーブ構成にしたとしても、マスターが単一故障点になってしまったり、障害対応の時の手間は変わらないというのが難点で、マスタースレーブ構成への変更にも二の足を踏んでいました。

SolrCloudはそういった煩雑さから開放してくれ、まさに自分たちにとっては渡りに船でした。結果、スキーマ変更や設定ファイルのチューニング、ノードの障害発生時の対応やメンテナンスが圧倒的にやりやすくなりました。マシンリプレースの効果もありますが、パフォーマンスも、導入前より向上しました。

今後

Solrのバージョンが3.xから5.xとなり、機能面でも新たに使えるものが増えたので、BUYMAの検索の機能面としても向上していければと思います。

【ECサイトにおけるデザイン】キャンペーンページのデザインを考える

はじめましてデザイナーの篠原です。 ECサイトのデザイナーならではのトピックをお伝え出来ればと思います。

はじめに私の担当は主に運営しているサービス「BUYMA」に関してのデザインになります。 「BUYMA」でのデザイン業務は大きくわけて、

1.トレンドと連動したキャンペーンページやバナーの作成 2.機能改善・新規開発に伴うページやUIの作成

になります。

細かく分類すると他にもありますが、大きく分けるとこんな感じだと思います。

今回は「トレンドと連動したキャンペーンページの作成」時に気をつけている事を、順序立てて書いていければと思います。

ざっとページ作成の流れはこんな感じ

STEP1「構成」

STEP2「ヒアリング」

STEP3「デザインイメージを探す、集める」

STEP4「デザインを考える (頭の中で)」

STEP5「プロトタイピング→デザイン(グラフィックソフトを使ったデザイン)」

STEP6「コーディング」

STEP7「ブラッシュアップ(もうひと頑張り)」

STEP8「公開」

STEPを通して、それぞれどんな事を考えているのかを書いてみようと思います。

STEP1「構成」

STEP1

BUYMAでは日頃からトレンドをウォッチしているMD担当のスタッフがいるので、 企画概要やデザインへ盛り込む要素などは、そのスタッフがあらかじめ決めることが多いです。

企画の規模によっては最初からデザイナーも入り共に構成を考えたりもします。 キャンペーンページでは特に売れ筋や定番人気の商品をBUYMAとしてどう見せていくかを意識して考えていきます。

STEP2「ヒアリング」

STEP2 前STEPとほぼ同時の事は多いのですが、あらかじめ構成をもらっている場合にはこの段階で、

「テーマ」「ターゲット」「トレンド」「企画を考えた時に感じた事」「データからのユーザー分析」「スケジュール」

あたりをしっかりヒアリングします。 内容を整理しデザイン面で懸念があればしっかり認識合わせをしておきます。

STEP3「デザインイメージを探す、集める」

STEP3 ヒアリングで得たものから、同じテーマのデザインをネットで集めたり、 過去の経験から似たようなイメージを引っ張りだしたりします。

色が似ているとかフォントが似ているとか、なんでもヒットしたものを探して、 イメージを広げていきます。

印刷して実際にデスク上にバラバラと広げたり、 ホワイトボードとかにぺたぺた貼っていくとかも良いと思います。

企画を聞いてから色々と探してもいいのですが、 やはり普段から準備しておく事でスピードアップできます。

私の場合はとにかく「パッと見」でたくさんのものを見ておくことを大切にしています。 断片で覚えている方がよりクリエイティブな感覚をもたらすからと考えています。

ちなみにこの「パッと見」の際は、こちらのサイトとかよく見ます。 designspiration.netとかpinterestですね。

BUYMAというサービスは海外との繋がりを楽しむ、または感じてもらうサービスなので、 海外のデザインからインスピレーションを得ることも多いです。 特にファッション性の高い見せ方、トレンドなどは常にチェックしています。

ついでに、ファションだけでなくカルチャー、経済、ゴシップネタまで、ユーザーの取り巻く環境を幅広く把握しておく様に、雑多に情報収集するのも良いデザインに繋がったりすると思います。

STEP4「デザインを考える」

STEP4 前STEPで集めたものに対して、「自分だったらこうする」という軸で考えていきます。 自分の審美眼をあてにしながら、色々と感じるままに考えていきます。

自分の関わるサービスにしっかりとしたブランディングがある場合は、「サービスに似合うのは何か」と考えていきますBUYMAだとこちらの方が多いです。 この場合はサービスの審美眼をあてにしながら、という具合でしょうか。

STEP5「プロトタイピング→デザイン(グラフィックソフトを使ったデザイン)」

STEP5 イメージがある程度まとまったら手を動かしていきます。

徹頭徹尾まとめてからだとうまくいかない事が多いので、ある程度がいいと思います。 アイディアの鮮度を大切に。頭がフレッシュな朝に回して手を動かすのでも良いと思います。

ちなみに手を動かすという事は文字通り手書きじゃなくても良いと思いますが、 イメージを素早く出すのは手書きが良い場合が多いなと感じます。

大事なのはイメージをどんどん頭から出す事だと思っています、 頭からイメージを出していく事で新たなアイディアが入るスペースが出来るので、 短時間で様々なパターンを出す事が出来ると思います。 そもそもイメージが浮かばない場合はSTEP3に戻ってやり直します。

その後、 デザインが軽くまとまったらプレビューの場を設けます。

注意したいのはこのプレビュー時にデザインが出来上がりすぎている事です。 意見の入る余地がないものを仕上げてからだと、 デザインへのこだわりが強くなっていて引けなくなっちゃったりしますし、 その思いが伝わって良い意見ももらえなかったりします。。。 なので、批判を恐れずにプレビューする事を心がけると良いと感じます。

方向性を定めてデザイン的に問題ないものが出来たら、 そのデザインに合わせたバナー作成もこのタイミングで行っていきます。

STEP6「コーディング」

STEP6 ここは分業の場合も多いと思いますが、 僕らはデザイナーがコーディングまで担当する様にしています。

Webデザイナーは、各デバイス、ブラウザの特徴を把握し、 特性や利点を活かし、欠点を補うデザインが求められる職業だと考えています。

それはデバイス問わず成立するデザインを考えるということでもあると思います。 なので良いデザインをするためにコーディングの知識は必要と考え、極力担当をする様にしています。

またBUYMAではエンジニアと一緒になってページを作る機会も非常に多いので、 HTMLだけでなくPHPRubyについてもデザイナー側に知識がないと厳しい、 という経緯もあり普段からソースに触れる様にしているのもあります。

STEP7「ブラッシュアップ(もうひと頑張り)」

STEP7 実際にはこのタイミングなのか、もしくは途中のタイミングでもあり得ますが、ページ公開に向けてブラッシュアップをしていきます。

ここで良く考えるのは(というより言い聞かす様にしているのは)、 ここまで試行錯誤しながら作ったものであろうが、今の完成度は80%だと思う事です。 UI作成の場合はこの時点では改悪しないものが出来た、と思う様にしています。

誤解を恐れずに書くと、 ブランディングを考慮し、トンマナを守った上で出来たものはまだ完成度が80%程度なのだと思います。 ここからどこまでやるかは周りの反応だったり、それこそ個人の感覚が大きいと思いますが、 人を感動させるもの、気持ちを動かすもの、UIにおいての改善と呼べるレベルのものは、 ここからのブラッシュアップによって達成出来るものと考えています。

STEP8 「公開」

STEP8 BUYMAでは各担当者から公開依頼を一度システム管理者へ回します、 そこでサイトにクリティカルな問題がないかを確認した上で公開されます。 公開されたらもう一度自分が考えたデザインになっているかサイト上で確認を行い完了となります。

ページ公開後は、 良い反応があるかどうかをGAなどでチェックしたり、 実際にインタビューしたりなど、効果を追っていく流れになりますが、 こちらは担当Dirから共有してもらう事が多いので、デザイン作成としてはここで一旦完了となります。

という事で、だいぶ文字ばかりになってしまいましたが、 以上がデザインが出来るまでの基本的な流れです。

この様な基本となる流れを「素早く」「精度高く」こなす事で余裕が生まれ、 よりクリエイティブなキャンペーンページのデザインが出来る様になると思います。

最後になりますが、たまに休憩を取る事も大切なので、時折コーヒータイムでも挟みましょうね。 ではでは、良いデザイナーライフを。

Coffee

類似画像検索についての調査結果

はじめまして。エンジニアの小金澤です。

つい最近、類似画像検索という言葉がふと耳に入ってきたので、調査してみました。

意外と参考となる記事が少なかったので(というか...小難しい記事ばかりでした)、纏めるのに少々苦労しましたが、最終的には技術的検証まで行いたいと思います。

概要

画像検索には、TBIRとCBIRがあるらしい。

そしてTBIRとCBIRの両方を用いて画像検索を行うものがあるらしい...

また、この2つ、TBIRとCBIR両方を用いて検索する方法が最も目的の画像を抽出することができる...らしい......

ということで本当に類似検索できるのか、まずは簡単そうな??CBIRについて調査・検証してみたいと思います。

また、軽くTBIRにも触れていきます。

1. 類似画像検索ついて

  • TBIR (Text-Based Image Retrieval)

主にテキスト情報と画像を紐付けて画像を検索する手法のこと。つまり画像に対してテキスト情報を付け加えて情報を保持する必要がある。

  • CBIR(Content Based Image Retrieval)

画像の形状特徴や色特徴を基に類似する画像を分類し検索を行う。

 2. 検索アルゴリズム

  • Earth Mover's Distance (EMD)

2つユークリッド距離(ヒストグラム)を距離尺度を計算する。

EMDとは、A画像とB画像が持つ2次元ユークリッド距離(画像なので2次元としました。)比較しその距離間を計算します。 もっと簡単にちょー分かりやすくいうと、画像の特徴をハッシュ化しお互いのハッシュ値を比較する。※大分語弊ありありですが...

また、特徴としては、画像を決められたY/X座標毎に分割し、分割した画像のヒストグラムを計算しハッシュ化します。

そして分割したハッシュの総和を比較するというわけです。 ※ 画像に紐付いたテキスト情報も含めて、計算することもできるらしい。TBIR/CBIR2つの情報を元に計算することも可能。

  • Histogram Intersection

色の類似度を計算するアルゴリズム

こちらは、EMDに比べもう少しわかりやすいものとなってます。 色の比較です。単純ですね。赤(R)、緑(G)、青(B)の各成分が画像中に何ピクセルあるかを計算し、比較するというものです。

  • Average Hash(aHash)

Perceptual Hashを使い計算するアルゴリズム

Perceptual Hashの生成方法は以下のとおりです。

  1. 画像のリサイズする(8x8=64ビット/16×16=256ビット)
  2. 色を削減する(グレースケールに変換)
  3. ピクセル毎の色の平均値を算出
  4. ハッシュを構築(各ピクセル毎に平均値以下か以上かを設定しハッシュ化する)

以下、このアルゴリズムの作成者(Dr. Neal Krawetz)のブログです。 http://www.hackerfactor.com/blog/index.php?/archives/432-Looks-Like-It.html

本格的なPerceptive Hash(pHash)を使って計算する場合は、離散コサイン変換(DCT)をする必要があり、また、コストがとても高い(重い)ため、現在は、Average Hashが話題になっているようです。

 3. 次回予告

次回は、このAverage Hashを使い実際に以下のGemと画像を使いRubyで検証していきたいと思います

  • Gem

github.com

  • 画像

s01 s02 s03 h01 h02 h03 s13 z01 z02

 

 最終目標

  1. aHashより算出したハッシュ値をDBへ保存
  2. フロントから入力された画像のaHashよりハッシュ値を算出
  3. DBにある画像ハッシュ値と入力画像のハッシュ値を比較し類似画像を抽出!!

乞うご期待!!!

Backbone.jsでフロントエンド開発

はじめまして、エンジニアの高松です。 今回は先日リリースした、「色・サイズ改修」でのフロントエンド開発についてお話したいと思います。

概要

「色・サイズ改修」は、主に以下を目的としたプロジェクトです。

  • 購入可能な色やサイズが、ひと目で分かるようにする
  • 次期リリースで、色とサイズを選択して購入できるようにすることで、誤注文を減らす
  • 商品の色・サイズのデータを蓄積し、運営に活かす

リリース時のお知らせがこちらです。

BUYMAはC2Cのショッピングサイトなので、改修は大きく出品側と購入側に分かれます。 開発は私と部長の2人体制、さらにデザイナーのチームで制作しました。

私: 出品側開発 部長: 購入側開発 デザイナー: 全般的なデザイン

開発の始まり

部長が先行して開発した部分を引き継ぐことから、開発は始まりました。

引き継いだのは、500行ほどのJavaScriptでした。 検討中の画面の仕様と併せて見ると、動的な制御の多いポップアップ画面のコードの一部です。

$と_の量が多い事と、「ここはAjaxで取ってくるか?」というコメントが気になりましたが、続きを書き始めました。

ajax-mozaic

行き詰まり

少しずつ画面が動き始め、行数にして1300行を超えた頃でしょうか、開発が日に日に辛くなってきました。 ちょっとした修正にも時間がかかり、どこかを直せば、どこかが壊れます。 私(と部長)の書いたコードが読みづらく、子泣きじじいのように重くのしかかってくるのです。

「このまま作りきれるのか...」不安が募ってきたところで、一度書いたコードを捨て、Backbone.jsで書きなおすことを決めました。 一部ですが、既にBUYMAの中にはBackbone.jsで書かれた部分があったのが理由です。

Backbone.jsの導入

結果、Backbone.jsを使って書き直したコードは、以前よりずっと可読性が高いものに生まれ変わりました。

開発で使ったのは、View・Collection・Modelといった、Backbone.jsのベーシックな部分で、ルーターなどの機能は使っていません。 テンプレートエンジンには、Handlebars.jsを使いました。

Backbone.jsを利用して得られた、主なメリットは以下の部分です。

  • Viewとロジックが分離でき、イベントも所定の場所に書くので、処理が追いやすくなった。
  • CollectionがUnderscore.jsをラップしていて、使いやすい。eachやmapなどのコレクション系のメソッドや、findなどのファインダーメソッドがRubyRailsライクで馴染みやすかった。
  • フレームワークとしてコンパクトで、学習コストは低かった。
  • 結果として、ロジックの実装に集中できるようになったのが、一番のメリット。

逆にハマった部分です。

  • Backbone.jsのViewをappendすると、空のタグが入る。jQueryのappendと、Backbone.jsのView::setElementを使い分ける必要がありました。
  • ViewがGCに入らずメモリリークする。いわゆるゾンビビュー問題です。

ここは、ノウハウを貯めていかないといけないですね。

API

だいぶ調子が出てきたタイミングで、部長と立ち話がてら、実装の話をしました。

部長: 「APIってRailsだよね?」

私: 「いえ、出品側は既存もあるので、全部PHPでやってます。」

部長: 「いや、新規APIだからRailsで書けるじゃん。」

私: 「へっ???」

そうです、「ここはAjaxで取ってくるか?」のコメントを動かすために、APIを3本作りました。

以前の部長のポストに記載がありますが、BUYMAのコードは少しずつPHPからRailsに移行しています。 APIは独立して作りやすいので、Railsで書くのが社内では定石になっているのです。

新規でレガシーコードを増やしてしまいました、すみません...

まとめ

Backbone.jsの導入で、フロントエンド開発は随分捗りましたが、まだ課題は残ります。

  • 通化できる部分はexport、requireして読み込みたい
  • サーバ側のModelとBackbone.jsのModelがほぼ一緒になるので、重複をなくしたい
  • View -> Model、Model -> Viewの双方向のやりとりを多く書かなければいけない。
  • フロントエンドもテストが必要じゃないか?

そうです、どれも最近のライブラリやフレームワークが解決しようとしている問題ばかりです。 モダンなツールを導入して、解決していきたいですね。

アクセスログを可視化しました

Fluentdによるログ可視化が話題になってからだいぶ経ちますが、エニグモでも(念願の)ログの可視化を本番投入しましたのでその内容を紹介したいと思います。(完全系ではないですが、実用段階です!)

主な使用技術

  • Fluentd
  • Elasticsearch
  • Kibana
  • AWS

構成図

ログ可視化構成

構成の説明

各WEBサーバーが出力したログをFluentdが拾ってログ集約サーバーに転送、ログ集約サーバーがAWSにたてたElasticsearchサーバーにデータをPOSTするオーソドックスな構成となっています。

Kibana

またログの可視化ツールではKibanaを使ってます。 Kibana4を使ってますが、Kibana3より格段に分かりやすくて気に入っています。

グラフ

細かい話

使用しているFluentdのPlugin

使用しているElasticsaerchのPlugin

Elasticsaerchのスキーマ設定

Mapping Templateを使ってフィールドのデータ型や要素解析などを指定しています。

Elasticsaerchの定期的なSnapshotの作成/削除、定期的なIndexの削除

curatorという大変便利なツールがあるので、 それを使って、Elasticsaerchの定期的なSnapshotの作成/削除、定期的なIndexの削除をおこなってます。

ログ可視化をして捗ったこと

  • 平均レスポンスタイムの分析が容易。
  • レスポンスタイムが悪いURLが分かる。
  • 端末別(PC or スマホ or タブレット or ガラケー)のアクセス数が把握が容易。
  • 時間ごとのHTTPステータスコードの割合。
  • 特定の時間だけ500が多いとかが分かる。
  • ある会員がどの画面遷移をしたかがすぐに分かる。
  • 障害調査が素早くできる。特にこれまでは数十台のWebサーバーのログをgrepしていたので結果がでるまで何十秒もかかっていました。

等など

最後に

昔はログファイルをgrep&AWKで頑張って解析していたのが、今はlucene queryでサクッと特定が出来ますし、遅い画面の集計やステータスコードの集計も簡単にできるようになりました。

今後はもっとログ可視化システムを強化してもっと便利にしていきたいと思います。

EC Night #1 に参加しました。 #ecnight

こんにちは。

エンジニアの木村です。先日行われましたECNight#1に参加しました。

発表しました。

ああいった場で発表するのは初めてで、発表順はくじで決まってまさかのトップバッターでしたが、時間も10分ということでちょうど良かったです。 発表資料ですが、当日のものをよりスライドだけで伝わるように改変してあります。

かなりユルい感じの、しかも上手く行かなかった取り組みについての発表でしたが、発表中の皆さんのいいリアクションを見たり、Twitter上や後の懇親会で良いコメントをいただけたりすると、発表しといてよかったなと思いました。勉強会マジックかもしれませんが。

この発表で少しでも社内の雰囲気が伝わればと思いますが、もちろん、もっとしっかりした取り組みもやってますということを申し上げときます。

感想

ライトな感じのイベントだったとは思うのですが、その中でも物流や決済についてのコアな話、ファッションECの歴史についての発表もあり、自身の仕事に直に関わるテーマばかりで、割と得るものが密に詰まったイベントでした。

懇親会も同じような悩みを持つ同業者間でアイデアやノウハウを共有できた貴重な機会でした。

それから、過去の大川さんの記事の最後も同じようなことを言っていますが、勉強会ドリブンというか、そういった気持で日々の開発に取り組もうという気持ちになりました。