Fringeneer's Tech blog

Fringe81の開発者ブログ

de:code2018 に参加しました #decode2018

Fringe81エンジニアの小紫@petitvioletです。

2018年5月22日、23日に開催されたde:code2018にエンジニアの森本と共に両日とも参加してきました!

de:codeとは?

Microsoft社(以下MS)が開催するイベントで、MSが提供する最新技術や実際の活用事例を紹介する、日本では最大級のイベントになります。 AI/MR(Mixed Reality)、クラウド、開発ツール全般と技術範囲も広く、MSの提供する技術に興味がある人には参加必須のイベントです。 私は今回が初参加で主にクラウド領域、つまりAzureの最新技術に興味があり参加しました。

de:code (decode) 2018 | 開発者をはじめとする IT に携わる全てのエンジニアのためのイベント

以下、Keynote及び印象に残ったセッションについて紹介したいと思います。

Keynote

今回のKeynoteでは「Transforming Intelligence」と題し、AI/クラウド、開発環境、最後はMR(Mixed Reality)の3つのトピックをそれぞれのSpeakerが話すスタイルで、講演時間はなんと3時間!

最初に日本MSの伊藤かつらさんから今後の技術動向とそれがビジネスとどう関わっていくかの話がありました。今回が初参加の為、知りませんでしたが、この方は毎年de:codeのホスト役をされているとのことで、さすがの話術で、この時点で講演に引き込まれていきました。

次にJulia WhiteさんによるAzure Stackのお話。IOT周りをサポートする為のサービスを特に強調していた印象でした。 特に興味を惹かれたのが、Cosmos DBのお話で、グローバル規模でレプリケーションを実現する機能は素晴らしいと思います。 ライブデモとして、Cosmos DBを利用したお絵かきサイトの紹介がありました。日米でほぼレイテンシなしで双方書き込むデモで、こちらも面白かったです。

PxDraw - Microsoft

2番目のSpeakerはJulia Liusonさん。主にMS Stackにおける開発環境の最新技術のお話でした。 弊社はC#等のMS Stackを利用していない為、ところどころ分からない箇所がありましたが、Visual Stadio Codeを利用したライブコーディング(こちらもリモートでの共同での作業機能!)等、大変面白かったです。 特にCI/CD周りの「Azure DevOps Projects」や「DevOps project with AKS」は機会があれば、是非利用したいと思いました。

最後のSpeakerはLorraine BardeenさんによるMRのお話。 弊社の昨年度の開発合宿のテーマがAR/VR/MRであった(社内にはHololensもあります!)為、少し知識がありましたが、Hololensが既に産業領域で利用されている事例の紹介があり、驚きました。日本でも建設分野での導入が進んでおり、現場での工数削減に活躍しているそうです。

Keynoteの締めくくりとして、日本MSの社長である平野拓也さんが登場されました。 こちらも興味を引く語り口で、りんなを始めとする日本MS独自の取り組みやそれらの学術分野やNPOとの連携のお話等、最後を締めくくるに相応しいお話でした。

講演を聞く前は途中で集中力が途切れそうだなと思っていましたが、それぞれのトピックが興味深かったこと、またそれぞれについて、ライブデモやライブコーディングがあり、終わってしまえばあっという間の3時間でした。

ワタシハ Azure Functions チョットデキル

www.slideshare.net

MS 牛尾 剛さんによるAzure Functionsの概要から内部構造、コントリビュート方法までと、このセッションを聞けばFunctionsに関するほぼ全てのことが把握できるのではないかと思う程の内容で、今回のNo1セッションというのも頷きです。

Serverlessの利用は、従来の開発に比べて比較にならない程の開発速度を提供してくれる一方、ベンダーロックインの危険性が伴います。 上記の状況をコントロールにするには、内部構造を把握すること、最終的には開発者になってしまえば良いのではないかという趣旨のもと、痛快にFunctionsの内部構造を説明し、とても面白かったです。

またFunctionsと連携する機会が多いQueue・Pub/Subサービスにおけるそれぞれの特徴・使い分けの説明があり、Azureについて、あまり知識がなかった為、非常に参考になりました。

最後にはFunctionsがGitHub上で開発されていることを牛尾さんの実際のPRを元に紹介してくれました。 Functions等のクラウドサービスがGitHub上で開発されていることをこれまで知らなかった為、これは驚きました。 コードも公開されている為、内部実装を理解するのにとても役に立つと思います。

github.com

※実際には複数のrepositoryに分かれており、それぞれの役割は上記のスライドに説明があります。

牛尾さんの話術もあり、とても面白くかつ為になるセッションで非常に満足度が高かったです!

Cosmos DB performance Tuning

Principal Software development engineerのDavid Makogon氏によるチョークトーク

github.com

内容はCosmos DBのRead/Writeに使用するRequest Unit(RU)の観点でのチューニングについてでした。

Cosmos DBはグローバルスケールでクロスリージョン、マルチマスタ書き込みにマルチデータモデルなど、かなり高機能なフルマネージドNoSQLデータベースで、可用性だけでなくレイテンシにもSLAが設定されている使いやすいサービスです。

そのCosmos DBを実運用するにあたって避けては通れないRUの設計に非常に重要な話をいくつも聞くことが出来ました。

参考になるドキュメントも公式から提供されています。

docs.microsoft.com

クエリの内容によって消費するRUがどの程度違うかというのをわかりやすくデモしていました。
他にも、RUを節約するためのテクニックとしてクエリに使用しないプロパティからindexを削除することや、アプリケーションが要求するデータの整合性に合わせてCosmos DBの整合性レベルを調整することでパフォーマンスが変わる、といった話もありました。

高機能なCosmos DBではありますが、ちゃんと設計せずに使用するとそのパフォーマンスを活かしきれないばかりか費用も嵩んでしまう可能性もあるため、開発するアプリケーションに応じた使い方をする必要があるという認識を強めるいいきっかけとなりました。

内容はもちろんですが、英語も聞きやすい上に逐次通訳がついていて満足度の高いセッションでした!

まとめ

2日間、主にクラウド領域のセッションを中心に参加してきましたが、Azureの最新の技術に触れることができ、とても楽しかったです。 またセッション以外でもミスタードーナツの食べ放題コーナー、MSのステッカーシートが貰えるスタンプラリー等、展示ブースでの企画も盛りだくさんでした。

AzureはGartnerのレポートでも既にAWSに次いでLEADERSの位置にあるため、Serverless、Container Service等の充実についても、他のクラウドベンダーに引けをとらないレベルに達していると思います。

特にCosmos DBは他のクラウドベンダーが提供するサービスに比べて、一歩先を行っている印象で、是非利用したいと思いました。

Scala Matsuri 2018 OSS ハッカソンに参加しました! #ScalaMatsuri

Fringe81エンジニアの森本です。

Scala Matsuri 2018 OSS ハッカソンに参加しましたので、その詳細及び感想について紹介します。

OSS ハッカソンとは?

blog.scalamatsuri.org

Scala Matsuriに合わせて、Scala界隈の著名なメンテナが来日されるので、そのメンテナに直接サポートを頂きながら、コントリビュート(Pull Request)を目指すという、なんとも豪華なイベントです。 Scala Matsuriでは今年が初の試みとなるようですが、運営の方のお話では海外では同様の取り組みが実施されているようです。

今回の対象ライブラリは上記のリンク先にもある通り、下記になります。

  • twitter4s(Daniela Sfregolaさん)
  • aeron, agrona, simple-binary-encoding(Martin Thompsonさん)
  • akka, akka-http, alpakka(Konrad Malawskiさん)
  • sbt, sbt-plugin, zinc(Eugene Yokotaさん)
  • ScalikeJDBC, Skinny Framework(瀬良 和弘さん)

Scalaプログラマであれば普段利用しているライブラリにコントリビュートできるチャンスということで、募集が開始された際に、我先にと応募しました。 運良く抽選に受かり、当日はakka, akka-http, alpakkaに取り組むことになりました。

issue 探し

当日までの準備として、まず取り組むissueを探します。 大体のプロジェクトにおいてContirubuting Guideが用意されていると思うので、まずはそれを読みます。 akkaプロジェクトの場合、おおよそ下記のようにissueがタグ分けされています。

moduleの中のどのcategoryに関連するtopicなのかを示すもの

  • t:core
  • t:stream

初めてコントリビュートする人向けに最適なもの

  • good first issue
  • help wanted
  • nice-to-have (low-priority)

issueのステータスを示すもの

  • 0 - new : まだ議論中でPRを受け付ける状態になっていないもの
  • 1 - triaged : PRを受付中のもの
  • 2 - pick next : 次回のリリースに含めたいと思っているもの
  • 3 - in progress : 既に誰かが着手中のもの

運営の方からも開催数日前にhelp wantedのものを対象にissueを探しておくと当日スムーズに作業に移れますよと案内が来た為、help wanted, 1 - triagedのタグが打たれているものを中心に、取り組むissueを探しました。

初心者向けのタグとはいえ、ある程度内部構造を知らないと修正方法が分からなかったり、1 - triagedとタグが打たれているものの、既にPRが作成されているものもある為、根気強く自分でも修正できそうなissueを探しました。

最終的に私が選んだissueは下記になります。issue中でおおよその修正方法が議論されており、取り掛かりやすそうだったのが理由です。

github.com

また当日までに、対象となるライブラリをGithubからcloneしておくと良いと思います。会場にはwifiが用意されていますが、やはり大きなものをダウンロードすると会場のwifiに負荷がかかりますし、IntelliJに読み込む際にもそれなりに時間が掛かってしまうので。

ハッカソン当日

ハッカソン当日は、事前に選んだissueを元に作業を進めていきます。またissueを決めていなくとも、メンテナの方と相談しながら、取り組むissueを探すことができます。

修正方針に問題がないか、メンテナの方に直接相談しながら、進めます。どのように実装してよいか分からない時は、メンテナの方がペアプロまでして直接指導してくれます。

私のメンテナはKonrad Malawskiさんでしたが、とても良い方で懇切丁寧に教えて頂き、ここまで丁寧に教えていただけるのかと非常に感激しました。

修正方法が決まり、実装が完了した後、メンテナの方に確認して頂き問題なければ、PRを作成します。Konradさんのサポートもあり、私もなんかと当日にPRを作成することができました。

github.com

英語が不安な方(私もそうです!)の為に、運営の方が通訳の方まで用意してくれており、ここまで至れり尽くせりのイベントはそうそう無いのではないかと思います。

PR

無事PRが作成できれば、Github上で他のメンテナの方がレビューしてくれます。Konradさんがすぐに他のレビューの方にメンションしてくれたので、おそらく普段よりも早くレビューして頂けたのではないかと思います。

Github上でも不明点や分からないことを相談したら、直ぐにレビュアーの方が丁寧に回答してくれ、修正方法を指導してくれます。

残念ながらBinary Compatibleの修正で手こずっており、現時点でまだ私のPRは取り込まれていませんが、引き続き、取り込まれるように頑張りたいと思います。

感想

普段利用しているライブラリの方と直接お話できる機会ということで、参加を非常に楽しみにしていました。 参加してみた結果、想像以上に楽しい時間を過ごせたと思います。 当日は四苦八苦しながらも、なんとかPRを作成できた時は謎の感動が湧き上がりました笑

当日は12のPRが作成されたとのことで、運営の方の想定以上の結果だったようです。

来年も実施が検討されているようなので、興味がある方は是非参加して頂ければと思います。

最後に貴重な機会を設けていただいたScala Matsuriの運営の方々、指導して頂いたメンテナの方々、本当にありがとうございました!

「GCPを活用した戦略的な新サービス開発の裏側」を開催しました! #fringe81_gcp

こんにちは、小紫です。

最近弊社では新規事業開発のインフラとしてGoogle Cloud Platformを使う機会が増えております。
そこで色々と知見が溜まってきていたので何かしらの形で公開しようということで、2018/3/27に表題のイベントをGoogle様と共催しました!

イベントページはこちらです。

fringe81.connpass.com

大変ありがたいことに想像を超える沢山の方にご応募いただき、ぎりぎりまで会場を広げての開催となりました。
ご参加いただいた方、ありがとうございました!

写真はCTOの東山がイベントテーマの新サービス開発についてイントロを行っているところです。

f:id:fringeneer:20180328102804j:plain

こちらは発表者の様子です。

f:id:fringeneer:20180328160234j:plain

発表について

Fringe81で新サービス開発に携わっている4名に加えて、Googleの村上様にもご発表いただきました。

弊社社員の発表資料は公開してありますのでこちらにも貼っておきます。

www.slideshare.net

speakerdeck.com

speakerdeck.com

speakerdeck.com

懇親会

最後の発表が終わってからは懇親会も行いました。
発表内容についてのディスカッションやGCPの使い方などについて盛り上がった会となって良かったです!

また、アルコールとお菓子に加えて軽食としてサブウェイのサンドイッチを用意してみましたが、ヘルシーで美味しくて満足感ありました。

f:id:fringeneer:20180328102534j:plain

絵面がいいですね。

最後に

新しい事業を立ち上げるのに興味のあるエンジニアの方、ぜひ一緒に新サービスを開発しましょう!

www.fringe81.com

第三回 Google Cloud INSIDEにて登壇してきました。

豊島です。

2/28に開催された第三回 Google Cloud INSIDEに登壇してきました。 テーマは 「GCP x マイクロサービス x アプリ開発の裏側」というものです。

今回は私達が開発しているUniposというサービスの開発の裏側についてお話させていただきました。 GCPを本格採用して遭遇した課題のうちマイクロサービス的なものをピックアップしてみました。

資料はこちらです。

冒頭で企業が子会社を作るのってマイクロサービス的だよね、みたいな話をしましたが、他の例だと我々の人体(臓器)もマイクロサービス的だよねとよく言ってます。
というのもこの番組見ているとそうとしか思えないw

人体 神秘の巨大ネットワーク|NHKスペシャル

そもそも各臓器はなんらかの機能に特化している時点でマイクロサービスっぽいですし、各臓器は(番組の言葉を借りると)"メッセージ物質" なるものを出しているそうです。ある臓器から出たメッセージ物質が腎臓に届いたり骨に届いたりするわけですが今度は受け取ったそれらの臓器で反応が起こるそう(またそこから別のメッセージ物質が出たり)、また脳が受け付けるメッセージ物質は非常に限られるとか。

つまりこれはメッセージまたは臓器内で起きた変更をイベントとしてPublishして臓器側で関心のあるものをSubscribeしてるってことじゃないか、脳が全てをコントロールするオーケストレーションスタイルかと思ってたらコレオグラフィスタイルのアーキテクチャじゃないかっていう変な視点で番組を楽しんでます♪
こういう視点面白いかなーと思って、冒頭で紹介してみました。臓器の話はさすがに脱線しすぎるのでしなかったですけどね。

あと、クラウドサービス(GAE FlexibleもStandard)も、プログラミング言語(GoもScala)も得意・不得意があるので、得意がしっかり活きて不得意が必ずしも即デメリットにならないような使い方をするというのが出来ると適材適所感が出ていいな、というのをいつも考えているので今回はその辺を事例として紹介させていただきました。
ここも視点をもう少し一般化すれば、人も同じですよね。皆得意・不得意がある。教育して頑張るとかよりも先に適切な人事配置を検討した方がよりハッピーな解決になることが多いのではないでしょうか(システムほど簡単じゃない、、とは思いますが)。

さてさて次に会場の様子です。Googleさんの27Fにある立派なカンファレンスルームで200名の方を前にお話するのはなかなか貴重な経験でした。 会場の様子はこんな感じです。

f:id:fringeneer:20180301183808j:plain

普段、勉強会などで登壇する場合はPCを置いている台の前で喋る感じですが、こちらの会場は海外などでよく見るようなオープンなスペースで喋るスタイル。 イイ感じに歩き回ったりすると海外のそれっぽい感じになるのですが、多分ずっと突っ立っていたと思いますw

f:id:fringeneer:20180301184218j:plain

懇親会は会場を移動し、有名なGoogleさんの社食で行われました。

f:id:fringeneer:20180301184433j:plain

何名かの方に発表内容について質問もお受けしました。 なかでもCloud Pub/Subに関するものが多かったように思います。 自分のスライドの中でCommand系からCloud Pub/Subを経由してQ用データを作る場合はEventual Consistencyになることに注意と書いてしまったせいか、PublishされたメッセージがSubscriberに伝搬されるまで結構delayが大きいと思われている方が多いようでした。ちょっとミスリードしてしまったかもしれません。実際は瞬時にSubscriberで受け取ることが出来るのでほぼほぼdelayを感じることは無いだろうと思います。

その他、当日の雰囲気はこちらのハッシュタグのタイムラインを見てもらえればと思います。 結構、勉強になりましたといった感想もいただきお役に立てたようで嬉しく思います。

#gc_inside - Twitter検索

自社勉強会開催(3/27 火)

さて、Fringe81ではこのUniposをきっかけにGCPを本格的に使ってアプリケーション開発を進めております。 私以外のメンバーもGCPについてアウトプットできる知見が溜まってきたこともあり来月自社でGoogleの方を1名ゲストにお招きしてGCP勉強会を開催したいと思います。

詳細はこちらです。 お時間ありましたら遊びに来ていただければと思います。

fringe81.connpass.com

最後に

GCP利用を本格化させたので今年はGoogle Cloud Nextへ行きたいと思います!まだRegistration始まってないですけど^^;

cloud.withgoogle.com

Fringe81ではエンジニアの募集も随時行っております。 我々と一緒に地球の未来を作っていく仲間になりませんか!

www.fringe81.com

Elmのハンズオンイベントを行いました!

Fringe81エンジニアの古渕です。
このブログに登場するのは初めてということで頑張っていかなあきません。

タイトルの通り、先日1月27日にElmのハンズオンイベントを開催しまして、弊社の浅沼とともに講師を務めました。
レバレジーズさんのご協力のもと約20人の方に参加いただき、協力をいただいたメンター陣もとても豪華で!

会場のメインスライドの横には、Twitterで #elm_tokyo ラインを表示していて、 「〇〇まで完成!」「これって△△っぽいのでは?」などのツイートで盛り上がりました。思わず返信したくなってしまう。

f:id:fringeneer:20180130152550p:plain

これはElmモテる説が否定されたところ。

当日の資料

概要の資料と、 https://gist.github.com/asmasa/a6d3b17d327ad74216b644e1772b593b

ハンズオンで使った課題と。 GitHub - heartscry4423/elm-chat

今回はElmでチャットアプリを作成しました。

様子

Elmの概要説明をする浅沼

f:id:fringeneer:20180130114840j:plain

両手をお膝に置いて、お行儀がよいですね。

f:id:fringeneer:20180130114912j:plain

ん〜これはなんのときか、プロジェクターも繋がずに。わたしです。

振り返り

まず大勢の方がElmに興味があって、イベントに足を運んでくださってという状況がとても楽しくて、 あれほど多くの方と一緒になってElmを書いている場は初めてで興奮しました。(緊張もしました)

ただ懇親会の挨拶でも申しましたが、今回設定した課題の難易度は高かったようです。
問題作りで色々盛り込んでしまった結果、難易度が上がってしまいました、、設定は難しいですね。

社内のプロダクトにElmを導入してから一年以上が経ち、そういえば「Elmやべえ」を感じるポイントも 次第に変わってきていたことを自覚しました。そもそも何が嬉しいんだっけを改めて見つめ直すいい機会になったと感じています。

進め方のところなど反省するところは色々とありましたので、次の機会にはしっかりそれを還元したいと思っとります。
ぜひまた次回のイベントでもよろしくお願いします!

f:id:fringeneer:20180130143613j:plain

懇親会の最後まで残った人でパシャリ。
そう、「E」lmです。

2018年大新年Fringeneer勉強会を開催しました

こんにちは、エンジニアの小紫です。
少し前の話になりますが2018/01/11(木)にFringe81のエンジニア(Fringeneer)で大新年勉強会を開催しました。

なぜ開催したのか

Fringe81には現在40名ほどのエンジニアがいて得意分野も興味も様々です。
さらに同時進行で5つくらいのプロダクト開発が走っていると技術スタックも違うしで、技術的な共有をする場というのが非常に重要になってきます。
そのため弊社では1週間に2回の定例勉強会があり、業務に関係ある内容/関係ない内容とわけて開催されています。

年末年始は人によっては学習に充てる時間が多く、そういった共有会だけではエンジニアみんなの技術的欲求を満たしきれないはず!というのと、学習するにも何かマイルストーンがあった方が効率が上がるはず!と思って今回の大新年勉強会を企画してみました。
ちなみにこの日は16時から21時前まで5時間ほどのイベントとして、定時前は真面目な発表スタイル、定時後は飲み食いしながらLTでわいわいやりました。

どんな発表があったのか

当日のタイムスケジュールを公開してみます。
一部2トラックで発表を行ったのでA/B会場としてあります。

16:00-16:50

@A会場

17:00-18:00

@A会場

  • shapeless超入門
  • Try cats
  • オンプレ環境とSaaSを繋ぐために強引にトンネル引いた話

@B会場

  • フロントエンドとツール
  • ライブラリ開発を肴に開発を高速化する話をしてみる
  • はじめてのCSVダウンロード

18:10-19:15

@A会場

19:25-20:30

飲み食い開始してLT9連発 @A会場

  • もし新卒一年目が社長のプレゼンをつくったら~聴き手の心を動かす3のポイント~
  • Vim初心者がVimを使いこなすためにやったこと
  • ScalikeJDBC streams
  • embulkのプラグイン開発
  • ReactNativeでAR
  • chrome拡張で、slackの監視ツール作ってるなう
  • hyperapp紹介
  • 5分でわかるインターネット広告の歴史
  • Uniposで振り返るFringeneer2017!

様子

f:id:fringeneer:20180128234948j:plain

f:id:fringeneer:20180128234035j:plain

f:id:fringeneer:20180128234151j:plain

f:id:fringeneer:20180128234145j:plain

f:id:fringeneer:20180128234403j:plain

f:id:fringeneer:20180129105013j:plain

開催してみてどうだったか

当日の発表ではFringe81で使用している技術はもちろん、導入していないものやプライベートで触ってみたものに数学まで、かなり幅広いトピックが並びました。
Slackに用意した会話用のスレッドにも多くの投稿もあり、大盛り上がりな会となって非常に楽しかったです!

ちなみに2017年12月はFringe81でQiitaアドベントカレンダーに参加していたため、技術的に活発な2ヶ月でした。

最後に

一緒にわいわい勉強したい仲間を募集しています!

DeepAnalyticsのデータ分析コンテストで優勝しました!

本記事はFringe81 アドベントカレンダー2017の6日目の投稿です。

こんにちは。Fringe81データサイエンティストの貫井です。 今年9月まではプライベートでやっていた競馬AIの開発を専業としており、10月からFringe81に正式ジョインしました。 業務では主に広告配信ロジックの最適化を取り組んでいます。 2017/10/30まで開催されていたDeepAnalytics主催のレコメンドエンジン作成コンテストに参加し、見事優勝することができました! 今回はそのコンペ参加の取り組みについて紹介します。

▽DeepAnalyticsについて

参加の背景

これまで自分は機械学習を競馬予測以外のタスクで試した経験がほぼなく、10月からの業務でどれくらいやれるのか一抹の不安を抱えていました。 そんなとき、データ分析チームの先輩社員から本コンペの参加を勧められ、腕試しのためにまずやってみようと参加を決めました。

コンテストについて

今回のコンテストでは、オプト社が提供する2017年4月の行動履歴から、2017年5月1週目においてユーザーが関心を示す商品を予測して、その精度を競います。

行動履歴には人材、旅行、不動産、アパレルと異なる4業種が与えられ、それぞれ個別にモデリングをします。 ユーザの行動は、CV、クリック、ページ閲覧、カートに入れるの4種類のevent_typeがあり、各履歴にはタイムスタンプがついています。

予測精度の評価は、nDCG(normalized discounted cumulative gain)が使用され、閲覧=1点、クリック=2点、CV=3点として計算されます。

開催期間は2017/8/28-2017/10/30の約2ヶ月間で、優勝賞金は30万円です。

本コンテストの詳細はこちらをご覧下さい。

精度を上げるための工夫

今回作成したレコメンドエンジンの精度を上げるのにした工夫は以下の3点です。

  • 特徴量大量生産の仕組み
  • 最近の行動をより重要視
  • 最後の最後にアンサンブル

特徴量大量生産の仕組み

まず、他の参加者との一番の差になったのはおそらく特徴量を大量生産できたことだと思います。 本コンテストに限った話ではありませんが、基本的に予測タスクを解くときは1特徴量=1Featureクラスとして定義しています。 今回の問題におけるイメージは以下の図のようになります。

f:id:fringeneer:20171201131510p:plain
特徴量クラスのイメージ

特徴量を作っていくと、作成過程で似たような処理がよく出てくることがあります。 例えば、ユーザの"閲覧"回数と"クリック"回数は、集計対象のevent_typeが異なるだけで、回数集計する処理は共通化できるはずです。 また、X曜日のイベント回数となると、掛け合わせが7曜日×4イベント種類=28パターンにもなるので、それをベタ書きしていくのはかなり辛いです。 そこで上図のように共通化できる処理は抽象クラスを設けてそこに記述することで、実特徴量クラスでは属性だけを指定すればよくなり、格段に特徴量定義の手間を抑えることができる上に、テストも楽に書くことができます。

また他の工夫としては、特徴量のクラス名を日本語で定義したことです。 日本語特徴量名を採用した理由は以下の3点です。

  • 良い英名を考える時間が無駄
  • 日本語の方が情報密度が高いので特徴量名を短く的確に表現しやすい
  • Python3では識別子にUnicodeが使える

コード内に日本語が入るのは気持ち悪い感じもしますが、名前を考えるのが億劫になって特徴量が作れなくなるよりはマシなんじゃないかと思います。

こうした工夫の結果、最終的に約400個もの特徴量を作成することができました。

最近の行動をより重要視

レコメンドエンジンでユーザのある商品についての興味を示す指標としてその商品に対する閲覧回数やクリック数がすぐに思いつくかと思います。 しかし、単純に閲覧回数やクリック回数のように時間軸を無視して集約してしまうと、「いつ行動したのか?」という情報が潰れてしまいます。 ユーザの関心や需要は時間ともに変化するはずなので、3日前の閲覧1回と30日前の閲覧1回は3日前の閲覧1回の方が価値が高いということが予想されます。

その直感を特徴量に落とし込むために、減衰率をrとして、X日前の行動の重みW(X)を指数関数で以下のように定量化しました。

W(X) = r^X \ \ (0 < r < 1)

減衰率rを変化させたときの過去1〜30日前の重みは以下の図のようになります。

f:id:fringeneer:20171201133235p:plain
減衰率を変化させたときの過去X日の時間減衰

回数の合計値を計算するときに、減衰関数で計算した重みを掛けることによって、最近の行動を強調できるようになります。 減衰率は複数の設定を変えたものを別の特徴量として追加していき、結果として時間減衰に関わる特徴量だけでも80個近い個数になりました。 この特徴量は締め切り2日前に追加して、1ヶ月近く超えられなかったnDCG=0.27の壁を突破する鍵となりました。

最後の最後にアンサンブル

集団(アンサンブル)学習は複数の学習モデルを組み合わせて強力な1つのモデルを構築する手法です。 アンサンブル学習はコンテストで勝つためには必須と言っても過言ではない強い手法ですが、モデルの訓練に時間がかかるというデメリットがあります。 約2ヶ月という制限時間の中で精度を競うのには、実験サイクルの回転効率は競争力を上げるための重要な要素となるため、早々からアンサンブル学習に手を出すのは筋が良くないだろうと考えていました。 そこで今回のコンペでは、データの前処理方法や特徴量追加などオリジナリティが出る部分での実験の効率を上げるため、締め切り2日前までは線形モデルの1種であるElasticNetと中間層1層のシンプルなニューラルネットを予測モデルとして採用していました。 その結果、最終日まで精度を伸ばし続けることができて、2位以下に大きな差をつけて勝つことができました。 ちなみに最終的にはGBDTを予測モデルとして採用しました。 GBDTの学習自体はxgboostlightgbmなどの洗練された実装があるので高速ですが、パラメータチューニングまで含めると線形モデルに比べて時間がかかるため、正しい選択だったと思います。

祝勝会@ニクアザブ

弊社のデータ分析チームみんなでニクアザブ本店にて祝勝会!! 次はKaggleで世界のデータサイエンティストと戦っていこう思います!!

f:id:fringeneer:20171206111953j:plain
白飛びしているのが私(貫井)です