「【Sansan×エムスリー】自然言語処理勉強会」を開催しました

こんにちは、DSOC R&Dグループ研究員の奥田です。前回は名古屋でブログを書いてましたが、今回は京都のSansan Innovation Labからお送りしております。

今回は4/24(水)に開催された「【Sansan×エムスリー】自然言語処理勉強会」の様子を紹介したいと思います。

【Sansan×エムスリー】自然言語処理勉強会（ライブ配信あり） - connpass

実際にはこの会場がすべて埋まりました！

この勉強会はエムスリー株式会社さんと合同で開催したイベントです。自然言語処理に関する話題について、それぞれの会社から2名登壇する形で発表しました。

connpassでの事前参加者はなんと参加可能人数の2倍以上！勉強会の募集開始後にすぐ埋まってしまうなど、皆さんの興味の高さを感じさせられる人気具合でした。以前Sansan主催の自然言語処理勉強会を開催したときはそれほどでもなかったので、これもひとえにエムスリーさんの影響力の大きさのおかげですね！私たちSansanも、より皆さんに興味を持ってもらえるようプレゼンスを上げていきたいところです。

こんな感じで開催前から大盛況だったため、関係者の協議の上、急遽YouTubeによるライブ配信も行いました。今回のようなセッティングでは初めての試みのため、Switchのゲーム配信でその能力を磨いた弊社高橋が、万全の体制でライブ配信に取り組んでくれました。その甲斐もあってライブ配信は大成功だったのですが、逆に会場の方のプロジェクタの設備不良で参加者の方にご迷惑をおかけすることに……。参加者の皆様申し訳ありませんでした。この経験はぜひとも次に活かしたいと思います。

勉強会前の事前準備の様子

さて、ここからは各発表について軽く触れていきたいと思います。

状態を扱うモナド(前編)

はじめに

どうも、プロダクト開発部の自称社内関数型担当の福田です。社内でのHaskellの本を読む勉強会を運営しています。

今回は一風変わったモナド、逆状態(反転状態)モナドが面白かったのでHaskellにおける状態モナドと合わせて2部構成で紹介したいと思います。

すごいH本を読んだことのある方を想定していますが知らない方にも雰囲気だけ感じ取っていただけるように紹介したつもりです。状態モナドを知っている方は後編からお読みください。

状態計算

どのようなプログラミングパラダイムにおいても、状態をどのように取り扱うかは大きなテーマです。 プログラミング言語で利用する関数の実引数や関数内で利用する一時変数なども、一種の状態として見なせるものがあります。 状態を扱う際に直面する課題は「どこで状態を持っているのかが不明」「状態の取りうる値が不明」「どこで状態が変わったか不明」などがあると思います。

今回は一つの方法として、状態を用いながら変化させつつ値を計算するものを状態計算と呼び、状態モナドとして抽象化し安全にプログラミングを行う方法の紹介を行います。(恣意的な説明も多分に含まれていますのでご注意ください。)

RubyKaigi2019にLanyard Sponsorとして参加してきました

初めまして、DSOC Development Groupの村田です。

4/18(木)〜20(土)の3日間、福岡国際会議場で開催されたRubyKaigi2019にLanyard Sponsorとして参加させていただきました。私は普段はデータ統括部門であるDSOCで、サーバサイドをRuby on Railsで開発しています。今回初めて、RubyKaigiに参加してきたのでそのレポートをご紹介致します。

RubyKaigiとは？

プログラミング言語Rubyに関する国内最大のカンファレンスで、年に一度日本のどこかで複数日に渡って開催されています。このイベントには国内外から多くのRubyist たちが集まり、様々なセッションが行われます。Rubyコミッターの方々も多く参加し、そしてたくさんの企業が協賛しているイベントで、Rubyistにとっては年に一度のお祭りのようなものです。

rubykaigi.org

スポンサーブースで「RubyKaigiで楽しみにしているコト」を募集！

弊社は、RubyKaigi参加者の出会いのきっかけとなればとの思いを込めて、「RubyKaigiで楽しみにしているコト」を付箋に書いて投票してもらうという企画を行いました。参加者全員に配られるネームカードに、ルビーをかたどった付箋が挟まれていて、その付箋に「RubyKaigiで楽しみにしているコト」を書いてブースに用意したパネルに貼っていただくと、抽選でTシャツやお米などのノベルティが当たるというものです。

Rubyエンジニアの祭典「RubyKaigi 2019」に協賛します | Sansan公式メディア「mimi」

Rubyの生みの親であるMatzさんやRubyおよびRailsコミッターの松田さんもブースに遊びにきてくださいました。

3日間でとてもたくさんの方が企画に参加してくださり、パネルは皆さんの「RubyKaigiで楽しみにしているコト」でいっぱいになりました！
皆様ご参加いただきありがとうございました！！

セッションをいくつかご紹介！

たくさんのセッションがあった中で気になったセッション、興味深かったセッションをいくつかご紹介します。

Day1. 13:30-14:10「How to use OpenAPI3 for API developer」

まずは1日目の13:30-14:10にあった @ota42y さんのOpenAPI3についてのセッション。

speakerdeck.com

DSOCの開発チームでも、半年くらい前からAPI仕様書をAPI BlueprintからOpenAPI3に移行しつつあったので、聞きたかったセッションの一つでした。
大規模なマイクロサービスの場合APIの数も膨大になってきます。そんな時にまずAPI定義を取り決め、その定義に沿ってクライアントとサーバの開発を同時に進めることをSchema First Developmentというそうです。
クライアントとサーバの開発を同時に進めて結合するには、必ずどちらもAPI定義通りに実装する必要があります。そんな時 commitee.gem を使えば、リクエストとレスポンスのバリデーションをRack層でやってくれ、定義と実装が同じであることを担保できるそうです。便利！ さらに、アプリケーション側では to_s とか Time.parseとかしなくても定義通りに型変換してくれるという賢さ。すぐに導入してみたい！
定義からRubyオブジェクトにマッピングできるopenapi_parser.gemもご紹介いただき、大収穫でした。

Google Cloud Next 2019 @San Francisco に行ってきました！（前編）

DSOC Infrastructure Group の 大澤 です。

先週開催された、Google Cloud Next 2019 に参加してきました。
参加者はCTOの藤倉とR&D島、大澤の3名です。旅行記やイベントそのものについては島の記事を読んでいただくとして、今回は Next 中に発表があった内容や気にあるセッションの感想などをつらねていきたいと思います。
かなり長くなってしまったので前編、後編に分けました。 *1

会場のモスコーニセンターです。電柱が邪魔をして上手く撮れなかった。。。

Day 1 Opening Keynote

www.youtube.com

Day 1のオープンニングキーノートで発表された、Anthos が目玉だったと思います。昨年発表された、 Cloud Services Platform が正式サービスとしてされたローンチしたもので、オンプレミス・クラウドを意識することなく、 Kubernetes クラスタを一元管理できるようになります。VMWare から GCP への移行のデモがあり、ハイブリッドクラウド（オンプレミスとクラウド）の文脈かと思いきや、デモ中に AWS のエンドポイントもこっそり出てきていることから、マルチクラウド（ Google と Google 以外のクラウド）の利用もできるようです。ハイブリッドクラウド、マルチクラウドの利用を先駆けて促進していこうとする意思を感じました。

次に気になったのは、OSS ベンダとの提携です。
Elastic, MongoDB, Redis など大手の OSS ベンダが提供するマネージド版を GCP のマネジメントコンソールと統合され、リソース操作はもちろんのこと、請求やサポートも統合されるとのことです。デモ画面では Redis Enterprise が GCP のマネジメントコンソールに出てきていました。
Redis CEO が Keynote にでてきた他、その他 OSS ベンダの CEO も動画で出てきたあたり、Google と OSS の関係性を強くアピールしていましたね。Google では Google で採用していない他の OSS に対してもバグや脆弱性の発見、修正に対する報奨金を提供していることから、昔から OSS と向き合っていてお互いに良い関係を築いていっていることはとても素晴らしいと思いました。

*1:けっして執筆期限に間に合わなかったとかそういうわけではないですよ。ええ。

行ってきました Google Cloud Next '19 San Francisco [旅行記その1]

DSOC R&Dの島です。こちらで記事を書くのは2回目です。

Google Cloudの一大イベント Google Cloud Next '19 のためサンフランシスコに行って参りました。参加者はCTOの藤倉と大澤・島の3人です。セッションなど技術的な内容は大澤の記事にゆずり、私はこちらでは旅の記録を書きます。長いので2部に分けます。

さらに万一気が向けば、ML系その他、気になった情報について別で書くかもしれません。

レイヤードアーキテクチャを振り返る

こんにちは、Sansanプロダクト開発部の清水です。

ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。

そもそもレイヤードアーキテクチャって何?

概要

一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。 一般的に上記の 論理的な グループの事をレイヤー(Layer)と呼びます。*1

レイヤードアーキテクチャのメリット

アプリケーションは成長していくにしたがって、巨大で複雑なものになっていきます。 そうなってくるとコードが大量にある状態になり、開発を行う際に、どこに何をするものがあるのかを開発者が把握する事が困難になります。

なので、特定の責務によって整理し、何がどこにあるのかを把握しやすくすることで、保守性を高める事ができます。 例えばデータアクセスする処理があったとして、それがデータアクセスレイヤーに置かれているなら、開発者はそのレイヤー内を探せば簡単に見つける事ができます。

ただ、それだけなら単にコードのグループ化だけでも同じメリットが得られます。 グループ間のやり取りの仕方を決めて制限し層状にする事のメリットは、もしアプリケーションに対する変更があった場合に、その影響範囲を、層を直接参照している層のみに限定する事ができるようになります。 もしデータの永続化の方法が、最初はリレーショナルデータベースで行っていたのが様々な都合で KeyValueStore の方が適切になり変更を実施する事になった場合に、その変更の影響範囲はデータアクセスレイヤーとそれを参照するレイヤーのみに影響を抑える事ができます。

代表的なレイヤーの分割単位と、そのやりとりの仕方

レイヤードアーキテクチャではレイヤーを以下の3層に分ける事が多いかと思います。

名称	責務の概要	別名(その表記を見る書籍など)
プレゼンテーション	ユーザとシステムのやりとりに関するものが置かれる。通常のWebアプリケーションならUIとなるHTMLや、WebAPIならリクエスト、レスポンスのモデル。あるいはControllerなど表示を調整するプレゼンテーションロジックなど。	ユーザインターフェース(DDD *2 )
ビジネスロジック	そのシステムで業務を表現するモデルや処理が置かれる。業務的なバリデーションやルールの適応など。	ビジネス(MSAAG*3, ドメイン)(PoEAA*4, DDD)
データアクセス	データアクセスに対する技術的な手段を提供するものが置かれる。主にデータベースや外部サービスを直接的に叩く処理など。	データ(MSAAG), データソース(PoEAA), インフラストラクチャ(DDD)

この3層を取る場合、代表的な処理の流れは以下になります。

1. ユーザはプレゼンテーションレイヤーを介してシステムへの操作を行います。
2. プレゼンテーションレイヤーはビジネスロジックレイヤーとのみやり取りを行います。
3. ビジネスロジックレイヤーはデータアクセスのためにデータアクセスレイヤーを呼び出します。
4. データアクセスレイヤーでのデータアクセスの結果をビジネスロジックレイヤーに返します。
5. 4.の結果をプレゼンテーションレイヤーで加工しユーザへの表示を行います。

この時プレゼンテーションレイヤーは必ずビジネスロジックレイヤーを介してデータの取得や永続化を行い、直接データアクセスレイヤーとやり取りをする事は行いません。 このようにそれぞれのレイヤーに決められた責務以外の事は別のレイヤーに任せ、やり取りする相手を制限する事で処理の流れや依存関係を理解しやすくします。

Layred archtecture

*1:対称的にサーバへの配置場所など 物理的な配置 でグループを分ける場合はティアー(Tier)と呼ばれており、レイヤーとよく混同する事がありますが、意味合いが違うので注意してください。

*2:エリック・エヴァンスのドメイン駆動設計

*3:Microsoft Application Architecture Guide, 2nd Edition

*4:エンタープライズアプリケーションアーキテクチャパターン

DSOCブース：SIP2019

DSOC Creative Groupの山脇です。3/14.15に開催された「Sansan Innovation Project 2019」にクラウド名刺管理サービス「Sansan」と個人向け名刺アプリ「Eight」を支えるデータ統括部門であるDSOCが展示ブースを出展しました。

今年はDSOCが担う大きな二つの役割『DATA』と『RESEARCH』を表現したブースデザインにしました。当日限定で配布したパンフレットも白と黒のリバーシブルデザインにし、『DATA』と『RESEARCH』は表裏一体であるということを表現しています。

Tシャツ

当日ブースで案内したメンバーが着用していたTシャツのデザインも白と黒に分けました。白である『DATA』は、辺や角などが等しく正確なイメージを持つ図形である正方形で表されたデータの粒子で正確性を表現。そしてそのデータの粒子が黒の『RESEARCH』へと流れ、必要なデータで構成された大小の真円となり様々な可能性を秘めた未来を描いていくことを表現しています。『DATA』と『RESEARCH』のTシャツが繋がることでDSOCが持つ可能性をデータの流れにより表現しました。

RESEARCH側の展示

『RESEARCH』側では、壁面のモニターに会場入口で展示していたデータビジュアライゼーション 「Dawn of Innovation」のムービーを放映。「Dawn of Innovation」の詳細はDSOC研究員西田の記事をご覧ください。またDSOCに所属する研究員の研究成果である「Data Science Report」の表紙も新たなコンセプトに合わせたデザインにリニューアルし配布しました。そして「Sansan Labs」のデモ機設置。普段触れることのできない人たちをはじめ、様々な人たちにご使用いただき新たな気づきの声などもいただきとても有意義なものとなりました。

DATA側の展示

『DATA』側では、壁面に設置したパネルにて、独自の名刺データ化システムである 「GEES」を用いた名刺のデータ化フローを紹介。そして素晴らしい進化を遂げたスマートキャプチャーの体験コーナーも設置しました。ダミー名刺を用意し、従来のシステムでは撮影することが難しかったファイルに入ったままの名刺や、キーボード上での撮影、特殊な形状をした名刺の撮影など従来のシステムと比較しながら試せるようにしました。この機能は、Eightにすでに搭載されておりますのでぜひお試しください。機能詳細についてはこちらをご覧ください。

DSOCはこれからもサービスを通じて
新しい価値を提供し、
イノベーションを生み出し続けます。