FiNC Developers Blog @finc-developers - Tumblr Blog

Posts

ブログ移転のお知らせ

『FiNC Developers Blog』を読んでくださっている皆様へ。

いつもご愛読いただきありがとうございます。

この度、ブログを移転することになりました！

こちらが、新たな弊社エンジニアブログとなります。

https://medium.com/finc-engineering

今後ともよろしくお願い致します。

FiNC 第1回インターンハッカソン

はじめに

あけましておめでとうございます。 FiNCでエンジニアインターンをしています安達です。皆様、年末は何をして過ごされましたか？ FiNCでは、FiNC史上初の試みとして第1回インターンハッカソンが開かれました！ FiNCのエンジニアインターンは5期に突入し、現在約20人ものエンジニアインターン生が働いています。未経験からエンジニアインターンを始めたにもかかわらず、FiNCのコアサービスを1人で作りあげたインターン生やFiNCで初めてAI技術を実際のサービスに応用させたインターン生もおり、FiNCのインターン生は社員に負けじと活躍しています。今回のハッカソンはそんな活発なインターン生が主体となって、発案から企画、実行まですべて行いました。この記事ではこのインターンハッカソンの様子や成果についてお話します。

インターンハッカソンのテーマ

今回ハッカソンを開くに至った目的は4つあります。

インターン生同士の交流

今後大規模なハッカソンを開く上での予行練習

習得してきた技術の復習

新インターン生の歓迎

これらを踏まえ、今回掲げたテーマは「インターン生活をよくするBOT-THON」です。自分たちが送ってきたインターン生活を踏まえ、あったら便利だな、面白いなと思えるようなBOTを作ろうということになりました。

12月30日 -ハッカソン1日目-

今回の参加者は、たくさんいるインターン生の中でも年末暇だった開発意識の高いインターン生8人です。

キックオフ

AM10:00。ハッカソンのキックオフです！審査項目が発表され、簡単なBOT講座が開かれました。BOT講座はFiNCにジョインして間もない新人インターン生が開いてくれました。チームはお馴染みのチーム分けアルゴリズムで3チームに振り分けられました。第1回インターンハッカソンの頼れるボスです。発案&主催をしてくれました。

開発①

オフィスの思い思いの場所で、チームごとに開発が始まりました。今回のBOTはslackのReal Time Messaging APIを使って作成しました。使ったgemはslack-ruby-client, eventmachine, faye-websocketです。発案、データベースとの連携など試行錯誤しながら、どのチームもお昼ご飯の時間を忘れるくらい没頭しました。

プログラミングコンテスト

今回のハッカソンのサブ企画、チーム対抗プログラミングコンテストです。 paizaというサイトのスキルチェック問題にみんなで挑戦しました。しかし、たまたま選択した問題があまりにも難しく、見事に全員滅多打ちにされてしまいました。

開発②

プログラミングコンテストの後はBOTの開発を再開しました。どのチームもある程度形になってきました。

ディナー

夜はみんなでピザを食べました。ピザが到着した絶妙なタイミングで遅刻してきたインターン生が1人。強者です。気の利くディナー担当は、ちゃんとサラダも注文してくれていました。流石です。

開発③

ピザを食べた後は開発を再開。当初予定していた1日目終了時刻を大幅にオーバーしてみんな開発に熱中しました。なんと翌日の朝5時まで開発していたチームも。タフです。

12月31日 -ハッカソン2日目-

2日目は発表日のため、評価者としてさらに3人の社員が参加しました。今回のハッカソンの審査基準は有用性、技術力、おもしろさの3つです。

成果物発表

完成したBOTの発表です！まずは唯一の女子ペアAチーム。 AチームはPDCAを回すことの大事さに注目し、

出社時刻と退社時刻を記録してくれるBOT

タスクと見積もり時間を入力すると、タスク終了予定時刻にメンションを飛ばしてくれるタイマーBOT

を作成しました。どうしても面倒臭いと思ってしまう勤怠管理や見積もり。BOTを使って簡単に習慣化できれば開発スピードも上がりそうです。〜Aチーム談〜

頑張ったところはBOTの割にDB設計を複雑にしたことです。 railsアプリを0から作成することが久しぶりだったので良い復習になりました。BOTを作成するにあたってrailsを活かしてactive recordを利用した仕様にしようとしましたが、複数のtableを読み込むことができずにハマりました。slackとBOTの連携では指定ファイルしか読み込まれないため、生mysql文をつらつら書くことが正解だったようです。ファイルの読み込みの関係を理解する良い機会でした。

次にBチーム。 Bチームはエンジニア研修生を教えるメンターの手間を省くために、

研修生のステータスや課題の〆切を教えてくれるBOT

課題の〆切のリマインドをしてくれるBOT

を作成しました。時間はできる限り無駄なく使いたいもの。メンターだけでなく研修生にも役立ちそうです。〜Bチーム談〜

作りたい機能を1つずつmoduleのmethodとして切り分けました。理想としてはslackで研修が完結する予定だったのですが、研修の情報量が多く、実際は研修の載っているリンクを載せる方向にしました。 BOTの画面とコードはこんなかんじです↓

module MessageEvent def message_events(data) if data['text'] == 'a' @real_time_client.message channel: data['channel'], text: "aaa" end return unless data['text'].include?('kenshu_bot') if data['text'].include?('いまどこ？') confirm_status(data) elsif data['text'].include?('new intern') create_intern(data) elsif data['text'].include?('index') show_index(data) elsif data['text'].include?('remind!!!') remind_deadline elsif data['text'].include?('start') update_status(data) elsif data['text'].include?('finish') finish_status(data) end end end

最後はCチーム。 CチームはFiNCに入ったばかりのエンジニア研修生が早く会社に馴染めるように、

この写真は誰？エンジニアクイズBOT

を作成しました。クイズに答えるとその人の詳しい情報を教えてくれます。どんな人でも会社に入ると最初に課題となる人の名前。ちょっとした息抜きにも役立ちそうです。〜Cチーム談〜

今回のBOT作成にあたって特に苦労したことはクイズの回答によって表示させるメッセージを変える条件分岐と、画像の表示です。画像を表示させるために最初はgyazoを使って画像のリンクを表示させるようにしました。しかしリンクと一緒にslackに画像が表示されるときとされないときがあり、次に画像そのものをDBに保存する方法を試しました。しかしこれも上手くいかず、最終的にslackのstampとして呼び出すようにしました。試行錯誤しながらrailsを復習する良い機会でした。

結果発表

結果は・・・・・ Bチームの優勝です！なんと2位との点差はわずか1点。惜しい。終わった後はみんなでお疲れランチをしました。

まとめ

今回のハッカソンでは技術の復習・習得だけでなく、目的・スケジュールの決定、役割分担といったイベント運営力、そしてチームで協力して目的に合った仕様を決め、開発するというエンジニアとして大切なモノ作りの基本も学ぶことができました。普段は黙々と開発することがどうしても多くなってしまうインターン生にとってとても実りの多い2日間となりました。次回の開催は未定ですが、今回の経験を活かして社員や外部の方を巻き込んだもっと大規模なイベントを今後開催したいと思います。

おまけ

FiNCのエンジニアインターンについて過去に取材を受けた記事です。

マイナビ「現役インターン生が考える本気の企業選び - ベンチャー系エンジニアインターンの座談会」エンジニアtype「Railsを教える前にPHP研修をはさむ理由は？FiNCの「エンジニア育成インターン」が興味深い」最後に、FiNCではエンジニアインターン5期生を募集しています！今回のイベントに参加したインターン生は未経験からスタートした人がほとんど。ご応募お待ちしています。 https://www.wantedly.com/projects/77932 安達

#インターン #ハッカソン

Microservices Meetup Vol.4 を開催しました

こんにちは、サーバサイドエンジニアの @qsona (森) です。

先日11/22(火)に、4回目となるMicroservices Meetupを弊社FiNCにて開催いたしました。多くの方にご参加いただき、大変盛況となりました。

当日の資料・リンク集及びタイムラインの様子は、全てこちらの togetter にまとめておりますので、ぜひご参照ください。

メインとなる発表は、以下のお三方に行っていただきました。(カッコ内は社名/プロダクト名)

西尾亮太さん (AbemaTV / AbemaTV)

Yves-Eric Martin さん (MediWeb / 3Bees)

春山誠さん (DeNA / Sakasho)

また、@yudppp さん, @ovrmrw さんのお二方にLTを行っていただきました。

ブログまとめ枠としてご参加いただいた @moomooya さんには、当日終了直後にまとめ記事をご投稿いただきました。

資料等のリンクはこちらから(togetter)

ご協力いただいた皆様、本当にありがとうございました。

感想

聞いていてそれぞれ印象的だった部分について述べたいと思います。

AbemaTV

Google Cloud Platform(GCP) / Kubernetes / gRPCを利用し、マイクロサービスをやる上での物理的な難しさを極力排除しているという話がありました。スケーリングやロギングなど10種類の課題を挙げられながら、それに対して上記のスタックがどう対応しているかの話は大変参考になりました。

また、今起きている問題点として、「管理画面を担当するサービスが、他のサービスのデータベースを直接叩いてしまっている」状況になっているとのこと。

マイクロサービスアーキテクチャにおいては、データベースは実装の詳細であるため、サービス間で共有してしまうことは基本的に避けるべきとされています。もちろんそのことは発表者の西尾さんも重々承知でありながら、そうせざるを得なかった理由は以下のようなものです。

もともとtoB向けとtoC向けで開発チームが分かれていた

(筆者の推測ですが、チームが分かれることで意思疎通のコストが上がるので、サービスのインターフェースを定義するのをよりカッチリとやる必要が生じ、リリース前のようにスピード感が求められる時には難しかったのではと思います)

サービスの特性上、管理画面の納期が他のサービスよりもずっと早い必要があり、他サービスのAPIインターフェイスが決まるのを待てなかった

このような問題への対応を、西尾さんは「負債の管理」という言葉で説明されていました。すなわち、今現在の状態と、正しくあるべき状態を認識し、同じことを積み重ねないようにすることです。

様々な制約から完璧なアーキテクチャにするのは難しい中で、「負債を管理」というのは常に持っておくべき非常に大事な考え方だと思いました。

3Bees

3Beesにはいくつかのサービスがあり、それぞれユーザやクリニックに提供されています。これについて、発表者のMartinさんは「マイクロサービスだと意識して作ったわけではない」と話されていました。つまり、初めから全く別々のサービスとして作り出して、そこから必要に応じて各サービスをAPI経由で連携したということです。

これは、サービスの境界が初めから明確になるため、マイクロサービスとしてみると最も理想的な始まり方と言えるかもしれないと感じました。このように、複数のアプリケーションを有しつつ、プラットフォームとして連携された体験を提供するケースでは、非常に自然な形でマイクロサービスになりやすいと言えそうです。

懇親会では、Martinさんからいくつか詳しい話をお伺いすることができました。その中の一つで、マイクロサービスのリリース順の問題で苦労した、という話は非常に親近感を覚えました。ステージング環境まででは正しく動いていても、いざ本番リリースしてみると、まだ他のサービスが本番リリースされておらず、エラーに・・・という問題です。これに対し、例えば自サービスの開発ブランチに対応する環境からは、他サービスの安定(master)ブランチの環境に繋ぐ、というように対応させることで、他のサービスに機能がまだ入っていない時はすぐに気づくことができるようになった、とのことでした。

上記は、3Beesがフロントエンドまで含めたサービスとして分かれているために可能であり、フロントエンドが複数のバックエンドを参照するようなケースでは、また別の解決策が必要になるかもしれません。リリース順問題はマイクロサービスの意外な落とし穴と言えます。

Sakasho

Sakashoは、ネイティブアプリのゲームに対して共通の機能を提供する基盤で、それぞれ提供する機能ごとにマイクロサービスに切り出すという方針で開発されました。他のAPIへの影響を考えずに独立にデプロイできる、など一定のメリットを享受しつつも、

チームの規模が想定以上に増えなかった(少人数で十分回った)

1人で複数のサービスを見ることになる

チームにjoinした際の学習コストが高い

トランザクションをはる必要性のある箇所が多い

などの理由から、コードベースを1つにマージするという判断に至り、そのために結合テストを準備して移行を進めたという話がありました。

これは3つの発表の中でも、特に難しい判断をされたように感じました。1つのものを後から分割するのはよくありますが、分けて作ったものを1つに統合する判断は、なかなかしづらいように思います。

しかし、状況が最初の想定と違うことはプロジェクトを進める上ではままあり、その時にサンクコストのバイアスにかからずに判断することの重要さを非常に強く感じました。特にマイクロサービスは組織論とも結びつき、ビジネス状況の変化によってその価値も変化します。そういった変化があることに対する覚悟も、マイクロサービスを進めるときは必要と言えるかもしれません。

まとめ

3つの発表ではいずれも、プロダクトそれぞれの課題に対してのアプローチとしてマイクロサービスがあり、またデメリットも認識しながら、どう向き合うかという観点がありました。

マイクロサービスという言葉にややバズワード感があった登場当時に比べると、マイクロサービスを銀の弾丸と見なす向きはすでにほとんどなく、むしろ最近ではマイクロサービスの辛い部分の話を多く見かけるようになりました。分散システムを構築することは、単純な1つのサービスを作ることに比べて難易度が高く、その点での苦労も多く存在します。もちろんFiNCにおいても例外ではなく、サービスの切り分け方に失敗して運用を難しくしてしまった事例などもいくつかあります。

マイクロサービスを進める上では、むしろうまくいかないことがあるのは当然で、だからといって全てを否定するわけではなく、受ける恩恵や目指すシステムの将来像を見極めながら冷静に判断していくことが必要だと思います。そういった点でも、今回の発表からは、マイクロサービスを運用していく上で非常に参考になることが多くありました。

最後に

株式会社FiNCでは、マイクロサービスアーキテクチャに興味があるエンジニアを募集しています。

https://www.wantedly.com/projects/30872

ご応募お待ちしております。気軽にお声がけください！

#microservices

RABLを捨てつつActiveModelSerializersに移行する

こんにちは、技術開発部の太田です。

FiNCではサーバーサイドにはRuby/Railsを採用し、クライアントからのリクエストに対してJSONを返すAPIを用意しています。これまではJSONの出力にRABLを使っていましたが、新たに作成するAPIはActiveModelSerializersを使うように移行しました。

要約

ActiveModelSerializersの良いところ

rubyのコードなので学習コストが比較的低い

エラーもrubyの普通のエラーになるのでわかりやすい

リソース志向に沿うことをある程度強制される

悪いところ

Modelを少し加工したJSONを返しにくい

情報が少ない

RABLと共存する時期をどうするか

新しいエンドポイントだけ書き直す

シリアライザで部分的にRABLを使う

背景

従来使用していたRABLは記法が独特なため学習の必要があるのと、ドキュメントが整備されていないため学習コストがもの凄く高く、かつ制約がないため好き勝手できてしまうので、ある程度強制され、基本的にrubyで記述することのできるactive_model_seralizersへと移行しました。

また、これまでFiNCでは、各エンドポイントでいい感じに必要なデータを返すように作っており、場所によって形式が違ったり、共通でアクセスするエンドポイントに色々詰め込んで処理が重くなり、かつ後方互換性のために整理するのが難しくなる…といった問題が起きていました。そこで現在、クライアントからのアクセスを一手に引き受けるフロントエンドサーバを立て、バックエンドはリソースを返すだけにし、クライアントからの要求に応じてフロントエンドサーバがリソースを取ってきて返す形へ移行をしています。 active_model_serializerはある程度リソースに紐付いたレスポンス形式を強制されるため、導入に踏み切ったという背景もあります。

導入方法

インストール

Gemfileに書いてインストールするだけです。

gem 'active_model_serializers', '~> 0.10.0'

使い方

ActiveModelSerializersの基本的な考え方は、ActiveModelを継承したクラスに対して対応するシリアライザークラスを定義し、json render時にシリアライザーに書かれた通りに出力するというものです。

サンプルコード

以下のようなPostモデルがあると仮定します。

# == Schema Information # # Table name: posts # # id :integer not null, primary key # user_id :integer # title :string # body :string # created_at :datetime not null # updated_at :datetime not null # class Post < ApplicationRecord def first_letter title[0] end end

ActiveModelSerializersはXXXモデルに対してXXXSerializerを探しに行くので、以下のようにPostSerializerを定義します。

class PostSerializer < ActiveModel::Serializer attributes :title, :body, :first_letter end

あとはJSONでレンダリングすると、attributesに指定したものだけが出力されます。

def show render json: Post.first end => {"title":"test","body":"text body","first_letter":"t"}

その他

Q. シリアライザーは1対1対応が必須ですか

A. 自動で検索する場合はそうですが、指定する場合は好きな物を使えます。

render json: Post.first, serializer: PostWithUserSerializer

Q. 配列の中の要素に対してシリアライザーを適応できますか

A. できます。配列に要素を積めた場合、配列のシリアライザーを定義する必要は無く、以下のようにeach_serailizerを指定することで、配列内の要素に対してシリアライズ方法を指定できます。

render json: Post.all, each_serializer: PostWithUserSerializer

Q. モデルのカラム以外も出力できますか

A. できます。シリアライザーのattributesに指定したものと同名のメソッドをシリアライザークラスやモデルクラスに定義すればそれが使われます。（上記サンプル参照）また、has_manyやbelongs_toをシリアライザーに書くことで、関連先のデータも出力することができます。

class UserSerializer < ActiveModel::Serializer has_many :posts, serializer: PostSerializer end render json: User.first, serializer: UserSerializer, include: '**'

移行方法

残念ながら、FiNCには大量のエンドポイントが既に存在するため、一度に移行するのは不可能でした。 (クライアントアプリからアクセスされるもので700以上)

さらに、既存のAPIを新たに書き直すには既存の形式を調べてリソースに分割、フロントエンドサーバ・クライアント側での対応などが必要になるため、現実的にはしばらくの間は既存の形式との併用が必要になります。その場合に問題になるのが、大半を新しく作る一方で部分的に既存形式と揃えたい場合です。 RABLで書かれているのを全てActiveModelSerializersで書き直すにはコストがかかりますが、複雑なRABLだけどそもそもアクセス回数は少ない場合や、将来的にその機能は消すけど当面は使う…といった風に、実装し直すコストに見合わない場合があります。

この場合、以下のようにシリアライザ中でRABLのrenderを呼び出すことで、既存のRABLとの互換性を維持しつつActiveModelSerializersに移行することができます。これを利用することで、エンドポイント単位ではなく、さらになだらかにRABLを捨てていくことができます。

class UserPostSerializer < ActiveModel::Serializer attributes :id, :old_post_data def old_post_data Rabl.render(object.posts, 'v1/posts/index', view_path: 'app/views/api', format: 'hash', locals: { username: object.name, next_page: true} ) end end

未解決課題

現在、以下の課題は良い解決方法を模索中です

シリアライザーのバージョニング

構造が同じだけど少し違うオブジェクトのシリアライザ

{page: 1, data: [ {username: 'aaa'...と{page: 1, data: [ {post_title: 'test'...

いい感じに共通化したい

動的にシリアライズ対象を切り替えるとか…？

最後に

FiNCではエンジニアを募集しています！ドキュメントがまともにないDSLを滅ぼしたい人や、それ以外にも興味がある人はお気軽にご連絡ください！

Android → https://www.wantedly.com/projects/54470 iOS → https://www.wantedly.com/projects/59939 Webフロント → https://www.wantedly.com/projects/63233 インフラ/SRE → https://www.wantedly.com/projects/57858 AI/機械学習 → https://www.wantedly.com/projects/57462 分析/データアナリスト → https://www.wantedly.com/projects/57201 QA/テストエンジニア → https://www.wantedly.com/projects/64774 Rubyエンジニア → https://www.wantedly.com/projects/30872

#ruby #rabl #active model #serializer

t-wadaさんとのSQLアンチパターン勉強会

はじめに

こんにちは、技術開発部の中森です。社内で4ヶ月に渡り、SQLアンチパターン勉強会を開催してきました。そして、最後の締めとして、SQLアンチパターン監訳者であるt-wadaさんをお迎えし、今までの勉強会で疑問として上がった点について、討論会を行いました。今回のエントリではその討論会の内容を紹介します。

ファントムファイルについて

勉強会の中で最も議論となったのは11章のファントムファイルでした。この章で紹介されているアンチパターンは、ファイルのバイナリ情報をDBの内部に保存するのではなく、外部のファイルに置くというものです。

t-wadaさん曰く、他の場所でも最も批判の対象となる箇所です。

ここで最も大切なことは「盲目的にアンチパターンを避けない」ということです。最近のWebアプリケーションでは画像や動画のバイナリデータは頻繁にやりとりがされます。それらをDBで読み出しや保存を行うと、オーバーヘッドとしてつきまとい、アプリケーションのパフォーマンスに関わってきます。また、近年ではAmazon S3に代表される信頼性の高いストレージサービスが存在し、それらを使う方がDBでファイルを扱うより信頼性が期待できます。この点からDBの外部にファイルにバイナリ情報を置くことは有効な選択肢となります。

ただ、扱うファイルの数やサイズが小規模なものであれば、DBのトランザクションを利用して処理した方が、信頼性が高く実装コストも低くなることが期待できます。

このように、自分たちが構築するWebアプリケーションの規模や設計を考慮し、ファイルデータをどこに保存するかを決定するのが大切だ、ということがこの章でのポイントとなります。

ActiveRecordのモデルとDBが切り離せない状況におけるベストプラクティスは？

Railsアプリケーションがある程度成長してくるとドメインロジックをどこに置くかに迷いが出てきます。 RailsのモデルではActiveRecordを使っていますが、ここにドメインロジックを書いていくと、最終的にインフラ層とドメインロジックがごちゃごちゃになった、いわゆるFat Model状態になりがちです。これを回避するため、Serviceクラスを作って、その中にドメインロジックを全て記述するという方法があります。また、別の方法としてActiveRecordとは別のドメインモデルを作ってそこにドメインロジックを記述する方法も考えられます。このように、ドメインロジックを押し込める方法や場所は何が正しいのか？という質問をt-wadaさんにぶつけてみました。

t-wadaさんからは、以下のようなお答えをいただきました。

基本的には、ActiveRecordにドメインロジックを書いていく。

モデルにはドメインロジックを集約させたほうがいいものと、あまりドメインロジックを持たせる必要がないものがあり、前者にドメインモデルとしての振る舞いを集中させ、後者にはscopeのみ記述する。

Railsのサービスを大きくしすぎないこと。大きくなったらマイクロサービスとして別のサービスとして切り分けるのがよい。

RailsのActiveRecordはPoEAAに出てくるアクティブレコードパターンに比べて多くの機能を持っています。これは短時間に小さな規模のサービスを構築するのには非常に適しています。しかし、長い時間をかけてサービスが大規模になる場合では、ActiveRecordがカバーしていないレイヤーの機能群を自分たちで作る必要が出てきて、コストがかかります。そのため、Railsで扱える規模にサービスをコントロールして大きくしすぎないのが良いです。

ドメインロジックをどこに記述するかについては、色々と迷うところです。テーブルに関するロジックであれば、そのテーブルに対応したモデルに記述すれば良いです。しかし、どのテーブルにも属さないようなロジックが出てきた場合、サービスクラスにするのか、別のモデルを作るのか、という選択肢が出てきます。

よくある例としては銀行の2つの口座間の送金の問題があります。これは、引き落とし先の口座から送金額を減算し、振込先の口座に同額分を加算する一連の処理を、1つのトランザクション内で完結させる必要があります。このときのロジックをどこに書くかははっきりしてません。しかし、1つの考えとして、どこに書くかに迷っていれば、永続化対象となるテーブル設計が漏れているかもしれない、というものです。この場合であれば、「送金する」というイベントを永続化対象として捉えることもできます。この場合、送金を司るモデルを作り、その中に送金に必要なドメインロジックを記述することができます。このように1つの内で完結する方針で対応すれば、既存のRailsの作法に則ることができます。

STIか？CTIか？

弊社ではFiNCインサイトというサービスで健診データを取り扱っています。健診データの特徴としては少ししか違いのないデータセットがたくさんあるということです。直近では50以上のデータセットがあり、それに対応したテーブルを作りました。

このようなケースで、NULLを許容しながら1つのテーブルを作成するSTIか、NULLを可能な限り排除すべくデータセットごとにテーブルを作成するCTIか、どちらを採用すべきかという議論になりました。

t-wadaさんの見解としては、NULLを消そうとしてテーブルを分けて行くこと自体は教科書通りの対応で悪いことではない、見解でした。

判断基準となるのは物理設計にかかる要件で、例えば串刺し検索がある場合にはSTIの方を、そうでない場合はCTIを採用するといった決定をします。例えば、野球選手やサッカー選手の情報を扱っていて全スポーツ選手の中から給料が特定の範囲にいる選手を抽出したいという場合に、抽象的なスポーツ選手のテーブルを作って両方のスポーツ選手を格納しておけば、検索時には1つのカラムを見るだけで達成できます。ただし、片方にしかない属性が多ければ多いほど、NULLが増えて疎なデータセットになって空間的には無駄が生じてしまいます。一方、テーブルを分割してる場合には、各テーブルを参照して回らないといけなくなるため、1つのクエリだけでは解決できません。ただし、NULLを排除できるため空間的には節約できます。

また、正規化してデータを保持しようとすると、ある程度の頻度でデータを集計してレポートを高いパフォーマンスでやることは難しくなり、これらはなかなか両立しません。このようなケースでは中小規模であればSTIを、より大規模でデータの正しさを意識するのであればレポート専用のDBを採用し、冗長ではありますが、集計に特化した形でデータを持つのが望ましいです。また、RDBに捉われず、RedishiftやBigQueryなど集計専用のサービスを利用するのもよいです。

２章のナイーブツリーが消える？

t-wadaさんにパンくずリストをどう実装するかも伺いました。ツリー構造を表現する場合は検索頻度と更新頻度を考慮して、どの代替ツリーモデルを採用するか考えることになります。ちなみにRailsにはすべての代替ツリーモデルのgemがあります。

コメントツリーのような狭く深く発展する傾向があるものについては経路列挙を用いるのが良いです。一方、人事構造のような広くて浅く、また、更新頻度がそれほど高くないが検索頻度が非常に高いケースについてはネスティッドセットを用いるのが良いです。

そして、パンくずリストであれば経路列挙を用いるのが簡単ということでした。

ちなみに、MySQL以外のプロダクトであれば再帰SQLを利用できるものがあり、それにより代替ツリーモデル採用することなく実現可能になります。そして、最近発表されたMySQL8.0では、まだLaboではありますがCTEが採用され再帰クエリが利用できるため、もしかしたらSQLアンチパターンの第２章ナイーブツリーが消えるかもね、というコメントをいただきました。

まとめ

今回、t-wadaさんをお招きしたSQLアンチパターン討論会を紹介しました。

筆者がこの勉強会を通して最も勉強になった部分は、「盲目的にアンチパターンを避けるのではなく、サービスにどのような設計が最適であるかを常に考えることが大切」というメッセージでした。

設計や実装において、良いと判断するためには、何が悪いかを知る必要があります。そのため、何も考えず「これはアンチパターンだから避けよう」という考えは別のアンチパターンに陥ってると思います。また、物事の良し悪しは、サービス規模や流行っている技術などそのときの状況によって変わります。サービスの設計や実装をする際に、それらの必要な情報をかき集め、そのときに最適だと思うものを採用していく姿勢が重要です。

FiNCではエンジニアを募集しています！興味のある方はお気軽にご連絡ください！

Redis を使って応答時間を半分にした話

はじめに

はじめまして。 5月にFiNCに入社し、サーバーサイドの Rails エンジニアをやっている亀田と申します。

今回は、Redis を使ってチャットのパフォーマンスを改善した話について書きたいと思います。

チャットで起きていたパフォーマンス問題

FiNCアプリにはチャット機能があります。ユーザー同士のコミュニケーションにも使えますし、お得情報の配信やユーザーのサポートなどでも利用しています。

その中で、ユーザーサポートの社内オペレーション用ツールに、（業務に支障が出るレベルではないものの）表示が重いという問題が発生していました。具体的には、対象となるルームのレコードを取得するために数百ミリ秒かかっており、レスポンスを返すまでに合計で1秒前後かかっているという状況でした。

分析をしてみたところ、インデックスを使って対象となるレコードを取得した後、下記のような処理を行うため、ファイルソートした上でオフセットを指定したレコードの取得を行っているのが原因であることが分かりました。

オペレーション用のステータスを条件にソートをする

ステータスが同じなら最終投稿時間が最近のものから並ぶようソート

全部を1ページに表示できる数ではないので、ページングも行う

（MySQLを使っているので）インデックスヒントを使うことで改善するという方法も考えたのですが、全体のレコードの構成・数によっては今後は逆に遅くなる可能性もあります。加えて、先々のことを考えてノウハウをためる機会にもしたいと考え、Redis を使うことにしました。

Redis とは？

Redis は、インメモリのいわゆるキー・バリュー・ストア（KVS）です。下記のような特徴を持っています。

RDB に比べて高速

一定の条件を満たしたデータを永続化（ストレージに書き出す）できる

いくつかのデータタイプをサポートしている（List、Hash、Set、Sorted set）

今回は、この Redis の Sorted set を使うことでパフォーマンスを改善させることにしました。

詳細は Redis の公式ドキュメントをご覧頂きたいのですが、Sorted set は、全てのvalueにスコアを付けて保存することができる「集合」です。よく使われるのが、アクセスランキングなどのランキングです。

例えば、各要素を url-rank という Sorted set に入れるとすると、下記のようなコマンドを実行します。

redis > ZADD url-rank 1 "facebook" redis > ZADD url-rank 2 "google" redis > ZADD url-rank 3 "finc"

数字の部分がスコアで、アクセス数などになります。そして、スコアの降順にならべて Sorted set の要素を取得したいは場合は、以下のようになります。

redis> ZREVRANGE url-rank 0 -1 1) "finc" 2) "google" 3) "facebook"

先ほどのソートに関する要件を、スコアとして表現できれば、この Sorted set の機能が使えます。

Redis の Sorted set を使った実装

まずソートに関わる部分の要件を少し詳細に書きます。

ステータスは複数存在する（仮に新着、対応中、対応済みとする）

ステータスは、最終的には対応済みになる

必ずステータス順に並べる

ステータスが同じなら、最終投稿時間が最近のものから並べる

以上を満たす簡単な方法としては、ステータス毎に Sorted set を作成する設計が考えられます。しかし、その設計ですと、ページ内で複数ステータスの Sorted set を参照することを考慮しないといけないので、コードが非常に読みづらいものになってしまいます。

そこで、最終的に必ず対応済みになるというところをもう少し詳しく聞いたところ、同一ステータスのまま長期間滞在することは基本的に存在しないということも分かりました。

それを踏まえて、並べたい順になるようステータス毎のオフセットを計算し、一つの Sorted set で表現することにしました。

Rubyのコードで書くと、このような感じになります（実際のコードを元に少し書き換えています）。なお、Redis へのアクセスは、Redis::Objects を使っています。

class ChatRoomSortedSet include Redis::Objects sorted_set :sorted_room_ids def update(chat_room) sorted_room_ids[chat_room.id] = chat_room.last_posted_at.tv_sec - calc_sort_offset(chat_room) end private def calc_sort_offset(chat_room) if chat_room.status == '新着' 0 elsif chat_room.status == '対応中' (60 * 60 * 24 * 365) * 1 elsif chat_room.status == '対応済み' (60 * 60 * 24 * 365) * 2 end end end

この update メソッドの中身は、イメージとしては下記のようなコマンドと同じです。

redis > ZADD chat_room_sorted_set #{chat_room.last_posted_at.tv_sec - calc_sort_offset(chat_room)} #{chat_room.id}

つまり、最終投稿時間の秒からオフセットを引いたものをスコアとして、チャットルームのIDをSorted set に登録しています。

Sorted set の各値は binary safe な string なので、チャットルームのデータをシリアライズして直接入れることも、レスポンス用の JSON を入れることもできますが、ルームのIDにしています。理由は、テーブル構造やレスポンスの構造を変えるときに Redis のデータまで変更が必要になり、バージョンアップなどが煩雑になるためです。

この Sorted set を使って対象となるルームを取得する場合には、

chat_room_ids = sorted_room_ids.revrange(start_index, end_index)

というようなコードを使って対象となるルームのIDリストを取得し、それを使って RDB からレコードを取得すればOKとなります。

Redis を使うことでどれだけ速くなったか

最後に、Redis を使うコードに移行したことで、どれだけレスポンスタイムの短縮になったか、ご紹介します。

だいたい 40〜60%くらいのパフォーマンス改善になっています。元々ルームのデータをRDBから取得するのに数百ミリ秒掛かっていたものが、数ミリ秒程度（ここだけ見ると100分の1以下）になったのが大きく効いています。

さいごに

FiNCでは、このように Redis などの様々なミドルウェアを組み合わせて、パフォーマンス改善など、ユーザー体験をより良くすることに取り組んでいます。

ミドルウェアをどう活用するかということも含めて Rails アプリケーションを開発したいという方は、こちらから是非ご応募ください。

FiNCアプリの4つの機能

はじめに

初めまして、去年の4月からFiNCでAndroidエンジニアをやっているLeeと申します。

この記事では日々更新されているFiNCのアプリ(Android)について紹介できればなと思っております。

FiNCのアプリの画面の構成や機能について説明しますので興味のある方は是非読んでください。

FiNCアプリとは

FiNCが提供するアプリケーションを総称して「FiNCアプリ」と呼んでいます。『FiNCアプリ』は、あなたの"健康的な生活をサポート"し、"病気の予防や改善"に役立つ要素が詰まったウェルネスアプリです。ヘルスケアの専門家のアドバイスを受けたり、健康に気を使う著名人の生活習慣を覗くことで、日常を楽しみながら、将来の健康リスクを解消することができます。

ではこれからFiNCアプリの画面や機能について説明したいと思います。

FiNCの機能

FiNCのアプリには健康をサポートするための様々な機能がありますが、その中でも大きく4つの特徴を持った機能が存在しております。

オンボーディング

マイコーチ(ダッシュボード)

チャット

タイムライン＋その他

オンボーディング

オンボーディングでは、初期設定に必要なユーザー情報などをチュートリアルを通して入力できるようになっています。チュートリアルはチャット形式で次々と進められるため、ユーザーは会話をしているうちに、迷わず楽しく情報を入力できるところがポイントです。

マイコーチ(ダッシュボード)

マイコーチでは、ユーザーのライフログを、グラフ（上記のキャプチャー参考）で確認することができます。体重や食事、歩数など健康に深く関わる情報を毎日入力し自分でチェックしながら体調管理ができます。最近はウェアラブルデバイスとも連携したので、自動入力もできるようになりました。それぞれの画面はスワイプでサクサク変えることができ、タッチで投稿できるようになっております。右下の「＋」ボタンからも各投稿ができます。

チャット

チャットではFiNCで提供する人工知能を活用した「Aiチャット」をはじめ、「専門家への相談チャット」、「公式チャット」、「フォローしたユーザー同士のチャット」もできるようになっております。特に「Aiチャット」では、ユーザーがの投稿忘れに対しリマインドをしてくれたり、健康や食材料などに関して突然のクイズを出してくれたりします。

普段のチャット機能では写真やかわいいスタンプも使えるので是非試してみてください！

タイムライン

タイムラインでは自分の投稿を含め、フォローしたユーザーの投稿も見られます。「いいね」や「コメント」、「つぶやき」、「フォロー」など他のユーザーとのコミュニケーションのための機能がいっぱいあるのでどんどん健康について交流できます！

その他

・アンケート画面

様々なアンケートに回答し、自分の健康状態を正確に知ることができます。

チュートリアルでのユーザー情報入力が終わった後、すぐアンケートに回答ができるようになっています。

・タスク画面

FiNCでは健康な毎日を過ごせるように、アンケートの結果等を基に個人に合わせて選定したタスクを提供しています。

不健康な生活習慣を改善したい、または理想の自分に近付きたいと思う方々のために「習慣タスク」と「フィットネスタスク」を行うことができます。選択したタスクは、最初の画面である「マイコーチ」でその進捗を一目で確認できます。

毎日自分にぴったりなタスクを行うことにより、もっと健康に近づくとこができます。

・FiNCモール

FiNCアプリの中にはポイントが存在し、そのポイントをヘルスケアに特化したECサイト「FiNCモール」や、フィットネスジムなどの施設等で使うことができます。

ポイントは食事や体重等のライフログを投稿したり、タスクを完了したりすることで取得します。毎日の投稿とタスクを頑張って身体も健康になり、ポイントで商品も買うことができます！

さいごに

FiNCアプリは「一生に一度のかけがいのない人生の成功をサポートする」ためにこれからもアップグレードし続けていきます。

FiNCでエンジニアを募集しています！興味のある方はお気軽にご連絡ください！

Microservices Meetup vol.3

(Author: Shinji OTANI)

2016/9/8に弊社にて、Microservices Meetup vol.3を開催しました。今回は、Googleの Ian Lewis さん、同じくGoogleの Sandeep Dinesh さんにお声がけいただき、FiNCとの共同で開催させていただきました。イベントページはこちら。

登壇内容

発表

“Microservices, Mobile, Machines and More with Kubernetes, gRPC and Containers” by Sandeep Dineshさん

“コンテナを利用したマイクロサービスのリソース管理” by Ian Lewisさん

FiNCにおけるコンテナ活用事例 by 鈴木さん

AWS loves Docker by 中丸さん

5分でそれとなくわかる Docker採用状況2016版 by 服部さん

“Kubernetes v1.3 Cloud Federationデモ” by 中井さん

Microservices, Mobile, Machines and More with Kubernetes, gRPC and Containers

１番手はDeveloper and Advocate@Google Cloud PlatormのSandeepさんに登壇いただきました。

Googleでは1週間に20億個のコンテナをlaunchしているとのことで、Googleならではのノウハウも踏まえて知見をお話しいただきました。 Kubernetesの基本的な役割はDockerを管理するところにあります。シンプルなdocker runコマンドだけでは管理しきれないほどのコンテナ数を持つようになる際に、Kubernetesが使われます。 Sandeepさんには、Kubernetesで実際にコンテナを立ち上げサービスを動かすところまでデモを踏まえてご説明いただきました。

また、同時に2015年2月にGoogleが発表したRPCフレームワークであるgRPCについてもご説明をいただきました。gRPCは標準でHTTP/2を標準でサポートしており、マイクロサービスの作成を強くサポートします。

コンテナを利用したマイクロサービスのリソース管理

２番手はGoogle Cloud Platform の Developer Advocate、Ianさんに登壇いただきました。 Sandeepさんのセクションでも少し説明があったKubernatesによるリソースの管理方法を詳細に解説いただき、さらにはマイクロサービスのサンプルアプリによるデモを行っていただきました。デモではとくに、Kubernetesを用いるとクイックに多くのサービスが立ち上がることが強調されていました。

ウェルネスタイム（一休み）

FiNCでのミートアップではウェルネスタイムと呼ばれるストレッチ・体操を行う時間を設けています。血流を改善しすっきりとして臨んでいただきたい、という思いからスタートいたしました。弊社トレーナーによるセッションを参加者のみなさまにも体験いただきました。

FiNCにおけるコンテナ活用事例

３番手は弊社FiNCのSRE manager・鈴木よりFiNCではどのようにコンテナを活用しているかの発表がありました（資料はこちら）。 FiNCでは昨年からDockerの利用を開始しました。現在ではサーバー上に環境を構築し、必要な検証が終わればコンテナを捨てる、という運用をdocker-composeを用いながら目指しています。

また、新しく構築しているフロントエンドサーバ（オーケストレーション層）でdocker-swarmの利用を検討しており、スケーリングやログの収集、監視など含めたdocker-swarmでの運用に関して言及しました。

AWS loves Docker

本ミートアップ最後の発表はSUPINF社の中丸さんに行なっていただきました（資料はこちら）。中丸さんには特にAWSのコンテナ支援機能についてお話しいただきました。AWSにはECS（EC2 Container Service）があり、タスクごとに適切な権限設定を実現できます。ECSを用いた最小構成や、EB(Elastic Beanstalk)を用いた複数コンテナ環境、CodeDeployを用いたDeployなどについてご説明いただきました。

また、AWSと他のプラットフォームとのコンテナ管理の比較についてもお話しがありました。AWSがECSというサービス名をタスク単位で管理しているのに対し、Google Cloud PratformがGKE (Google Container Engine)を Kubernetes上でPod単位で管理し、Microsoft AzureがACS (Azure Container Service) をDC/OSもしくはDocker swarm上にてService単位で管理するなど、それぞれに特色があることをご説明いただきました。

Docker adoption in Datadog users/ Datadog ユーザーに見るDocker採用状況2016版

Datadogの服部さんよりDocker利用者などの分析に関するLTをいただきました（資料はこちら）。Docker利用者は1年で2.5ポイント増加していること・Dockerの採用は法人など大規模ユーザが牽引していること・Dockerを検証した2/3のユーザが採用に至っていること、などを実データを踏まえてご説明いただきました。

Kubernetes v1.3 Cloud Federation

Googleの中井さんよりKubernetes バージョン1.3 から追加されたフェデレーション機能（資料はこちら）についてのLTをいただきました。Cloud Federationとは、複数のクラウド環境下で特定のワークロードをオンデマンドで移行させるものであり、オンプレミスやクラウドをまたいでのサービス発見が可能となります。デモ動画では、アクセスを受けながらのライブバージョンアップ（デプロイ）やアクセスを受けるリージョンのライブ追加などを行なっていただきました。

懇親会

懇親会では軽食・ドリンクとともに、参加者・登壇者のみなさまで交流をしていただきました！

おわりに

Microservices Meetupは今回で３回目の開催となりました。引き続き、Microservicesをキーワードに様々な分野を巻き込んで勉強会を開催していく予定です。みなさま、引き続き奮ってご応募ください。登壇者のみなさま、ご参加いただきましたみなさま、ご足労いただきありがとうございました。 FiNCでは様々なポジションでエンジニアを募集しています。ご興味をお持ちいただけましたら、ぜひ一度お話しをさせていただけますと幸いです。

3年間日本語のみで運用してきたサービスを、3ヶ月で新人が多言語化した話

はじめに

はじめまして。FiNCで今年の4月からサーバーサイドエンジニアをやっている澤井です。

先日プレスリリースがありましたとおり、FiNCで提供している法人向けサービスFiNCプラスが日本語以外にも対応し、この度英語版がリリースされました。

入社直後に携わった最初のプロジェクトということで、個人的には非常に感慨深いのですが、今回はこのプロジェクトの舞台裏を見ていきたいと思います。

多言語化とは

サービスの多言語対応と言っても、そのスコープは様々ですし、サービスが提供しているデータは多岐にわたります。ざっくりカテゴライズするだけでも、

タイムラインなどユーザー投稿によるデータ

おすすめのタスクなどのマスターデータ

があり、それぞれテキストのものと画像データがあります。

またこれらに紐付いて、

ユーザー使用言語の判定

があります。

ユーザーからポストされたデータを翻訳することは、もちろんは可能なのですが、ユーザーの意図を損なう可能性が高いので、何もしないという方針を採用し、それ以外のUIおよび提供しているマスターデータについては多言語対応することで、多言語環境下で十分なUXを提供するということになりました。

マイクロサービスにおける多言語化

FiNCのサービスはマイクロサービスという形で運用されています。サーバーは基本的にRuby on Railsで運用されていて、クライアントがiOS、AndroidおよびWebブラウザ(React.js)でそれぞれアプリが提供されています。

基本多言語化方針（サーバーサイド）

サーバーサイドで多言語化対応するものは主に下記の3つです。

コード内の日本語 (Web Viewなど）

マスターデータ

画像

1.ソースコード内の日本語

Railsはデフォルトでi18n APIを提供しています。Web Viewをはじめ、コード内に実装されている日本語については、全てi18n APIを使用することにしました。ただし、i18n APIは1点だけ難しい点があります。それは、規約を重視するRailsにおいて、この部分だけはほとんど規約がないという点です。いかようにでもファイルを配置できてしまいます。ViewではLazy Lookupという機能が提供されており、ファイルのディレクトリ構成と翻訳ファイルの階層構造をあわせることでビュー内部に長い階層を書かなくても参照できるようになっています。

Railsガイドの例そのままですが、

en: movies: index: title: "Frozen"

という辞書ファイルをyaml形式で用意しておき、app/views/movies/index.html.erb内で、以下のように書くだけでmovies.index.titleを参照できます。

<%= t '.title' %>

viewでは

<p>Frozen</p>

となります。この形式を参考にして翻訳ファイル配置の構成は、config/locale以下にアプリケーションコードと同じファイル階層を作成することにしました。

app ├─api │ └─v1 │ └─users_api.rb config └─locales └─api └─v1 └─users ├─ja.yml └─en.yml

en: api: v1: users: name: 'Name'

2. マスターデータ

DB内に保存されているマスターデータを英語化するには、日本語と対応するデータをDB内のどこかに保存しなければなりません。ぱっと議論して出てきた方針は、以下の2つでした。

各テーブル内で日本語の隣に英語用のカラムを作成する。

多言語対応用に別テーブルを作成する。

少し考えればわかりますが、将来言語を追加した場合、1の方針ではカラムが1つずつ増えていくというアンチパターンが発生します。そのため、今回は2の別テーブルを作成する方針を採用しました。RailsではDBの多言語対応用にglobalizeという有名なgem（Rubyライブラリ）が用意されているのでこちらを採用しました。

mysql> select * from jobs; +----+--------------+ | id | name | +----+--------------+ | 1 | アスリート | | 2 | 専門家 | +----+--------------+ 2 rows in set (0.00 sec)

mysql> select * from job_translations; +----+--------+--------+---------------------+ | id | job_id | locale | name | +----+--------+--------+---------------------+ | 1 | 1 | en | Athlete | | 2 | 2 | en | Specialist | +----+--------+--------+---------------------+ 2 rows in set (0.01 sec)

ただし、この方針は翻訳対象のテーブルが自動的にassociationのテーブルを新たに持つことになりますので、なにもしないでおくと大量のN+1クエリが発生します。

例えば上の例だと、翻訳テーブルがなしの場合、次のようなクエリが走ります。

[1] pry(main)> Job.all Job Load (0.3ms) SELECT `jobs`.* FROM `jobs`

しかし、翻訳テーブルを作成しasscociteさせていると以下のようなクエリが走ります。一行で済んでいたクエリがテーブルの行数分走っているのです。

[1] pry(main)> Job.all Job Load (2.9ms) SELECT `jobs`.* FROM `jobs` Job::Translation Load (0.5ms) SELECT `job_translations`.* FROM `job_translations` WHERE `job_translations`.`job_id` = 1 Job::Translation Load (0.5ms) SELECT `job_translations`.* FROM `job_translations` WHERE `job_translations`.`job_id` = 2

これを解決するにはrailsが提供しているeager loadingの機能を使うことで実現できます。

[1] pry(main)> Job.includes(:translations).all Job Load (0.5ms) SELECT `jobs`.* FROM `jobs` Job::Translation Load (0.4ms) SELECT `job_translations`.* FROM `job_translations` WHERE `job_translations`.`job_id` IN (1, 2)

コード内にincludesを追加していくには2種類の方法があります。1つはdefault scopeというrailsが提供している機能、もう一つは個別に必要な箇所にincludesを追加していく方法です。

defaut scopeを使うと、1行で簡単に全てのクエリでデフォルトで発行したい検索条件を設定することができます。例えば上の例だと

class Job < ActiveRecord::Base default_scope -> { includes(:translations) } end

のように設定できます。ただし、この方法ではincludesではなくpreloadやeager_loadなどの別のメソッドでテーブルのEager loadingの機能を使いたいときにも、必ずdefault scopeで設定したクエリが余計に走ってしまうという問題があります。

今回は上記のようなメリット・デメリットを比較した結果、default scopeは用いずに翻訳テーブルを呼んでいる箇所にincludesを追加していくことにしました。（20個ほど翻訳テーブルがありましたが、全部で70箇所ぐらい修正しました。）

3. 画像データ

少ないのですがチュートリアルなど用に画像で提供しているマスターデータがあります。現在画像のデータについては、2種類の方法で管理されています。

外部ストレージに保存し、そのURLをDBに保持する。

ソースコードと同じリポジトリに配置し、Railsのasset管理の仕組みを使って呼び出す。

1については、マスターデータの例と同じく各言語に対応した画像を外部ストレージに保存し、それぞれのURLをglobalizeのgemを用いて出し分けることで対応しました。 2については、アプリケーションのコード内で多言語化が必要な画像のパスのルールを設定し、locale情報を参照して画像の読み込み先を変更することで対応しました。

app/assets/images/apis/v1/onboarding ├─ en │ └─ recommended.png └─ ja └─ recommended.png

def contents { image_url: ActionController::Base.helpers.image_url("apis/v1/onboarding/#{I18n.locale}/recommended.png") } end

基本多言語化方針（クライアントサイド）

 クライアントの翻訳はUI部分に関わるものだけです。

言語設定の方法は、

端末の言語設定を使用

アプリ側で別に設定できるようにする

の2種類がありえるのですが、今回は一番簡単な端末言語情報を利用する方針を採用しました。

使用言語管理方針

ユーザーの使用言語をどう管理するかというのはマイクロサービスで運用しているFiNCにとって非常に重要な問題です。各サービス間の整合性を保ちユーザに統一した体験を与える必要が有るため、各サービスはユーザーの使用言語を何らかの方法できちんと知っておく必要があります。しかし各サービスから不用意にユーザーの使用言語を変更してしまうとおかしくなってしまいます。複数デバイスを持っているユーザーの想定など、色々と議論した結果下記の方針を採用しました。

言語設定は基本的に端末の使用言語を正とする

使用言語設定の設定を変更できるのは端末のクライアントのみ

ユーザーが現在端末で設定している言語情報はユーザー情報のサービス内でも保存しておく（使用言語設定を変更できるAPIがあってユーザーが使用言語を変更した後アプリを開いた際に更新用のAPIが叩かれる）

各サービスは使用言語を下記2種類のいずれかの方法で取得する

端末はAPIおよびweb_viewにアクセスする際に使用言語情報をヘッダで送る。

各サービスはヘッダをみて言語情報を取得する。ヘッダがなければユーザー情報からメイン使用言語情報を取得する。

どちらも見つからなけれデフォルトで日本語を取得する。

ブラウザベースのサービスはブラウザの使用言語から取得する。

通知など使ってるユーザーではなく、飛び先のユーザーの使用言語が必要な物は、送信先のユーザー情報をテーブルから取得する。

ユーザー情報管理もマイクロサービスとして切り出されているのですが、各サービスがユーザ認証サービスにアクセスして使用言語を取得する部分は、全サービス共通で必要な処理なので、社内gemとして作成・配布を行いました。

運用

多言語化については、技術的な改修以外に文言の翻訳依頼と継続的なブラッシュアップが必要です。そのためにはエンジニアだけではなく、Product Developmentと呼ばれるProject Mangement(PM)レイヤーのチームからの直接のコントリビュートが重要になってきます。今回多言語対応で採用したこうした取り組みについて以下に紹介します。

Gengo webapp 今回の翻訳では株式会社Gengoの翻訳サービスを使用しました。Gengo社の翻訳サービスは、ウェブサイト経由で注文するのと、API経由で注文をするのと2種類の方法が用意されているのですが、APIの方が15%ほど価格が安く設定されています。今回はAPI経由の発注にしたのですが、コマンドから叩くのではエンジニアしか発注できなくなってしまいます。そのため今回はGengo発注用に社内ツールを作成し、GUIを用いてAPI経由で発注できるようにしました。社内的にも過去の翻訳事例がDBに保存できるので非常に安心ですし、PMレイヤーの人間が発注を行えるようになって非常に便利になりました。

XLIFFによる運用クライアントサイドについてはXLIFFというファイルフォーマットで運用を行うことにしました。 XLIFF(XML Localization Interchange File Format)はXcode6からサポートされた翻訳のための標準規格で、Android Studioでも使用可能です。FiNCではクライアントの文言管理用にXLIFFファイル単体をgit管理しています。XLIFF自体はエンジニアだけでなくProduct DevelopmentチームもPRをだして更新していく形にしており、リリースしたのちも定常的に不自然な表現の修正などが行われています。また、XLIFF1つでiOSもAndroidも両方を管理することにより、デバイスを問わずクライアントの文言を同一にすることができ、iOS、Androidで共通のユーザー体験を提供できるようになりました。

Server 多言語対応をリリースしたことにより、日本語文字列をハードコードされることは、ほとんどなくなりましたが開発者の増えてきているFiNCではそれでも誰かが日本語ハードコードを混入させてしまう可能性は常にあります。運用の仕組み的にこれを排除するため、CI時に日本語のハードコードがあるかをチェックするテストを追加し、テストレベルハードコードの混入をさける仕組みを導入しました。

require 'find' # i18nを使わずにslimテンプレートを作った場合に検知するテスト # コメントは許容している # 新規に作ったテンプレートでこのテストが失敗する場合は # 対象のテンプレートでi18nを使うように修正してください # 既存から使っているものはblacklistに定義しているが、 # 新規に作ったテンプレートをblacklistに追加するのはNG blacklist = %w( app/views/index.html.slim ... ... ... ) blacklist_map = {} blacklist.each do |file| blacklist_map[file] = true end describe 'i18n view' do Find.find('app/views') do |file| next if file.match(/\Aapp\/views\/admins/) next unless file.match(/\.slim\z/) next if blacklist_map[file] context "when #{file} is found" do it 'the file does not have multibyte string' do expect(has_multibyte_string(file)).to be false end end end private def has_multibyte_string(file) File.foreach(file) do |line| if is_multibyte_line(line) return true end end false end def is_multibyte_line(line) # コメントはスルー if line.match(%r{\A\s*/}) return false end # 日本語を含んでいるか return line.match(/[ぁ-んァ-ヴ一-龠]/u) end end

おまけ（OSSへの貢献）

今回globalizeのgemを導入したのですが、使用する中でglobalizeのassign_attributesメソッドに引数を破壊するバグが有ることがわかりました。FiNCでは積極的にOSSへの貢献を意識しており、このバグに対してもPRを送りマージされました。

Wanted

FiNCでは入社すぐにでもこのような責任ある大きな仕事を任せてもらうことができますし、プロジェクトを通じて成長してくことができます。（FiNCでは、全てのプロダクトに誇りを持っているので、新人の仕事でも徹底的にレビューされ、ブラッシュアップされます。こうしたプロセスを経て新人でも成長していくことができます。）

FiNCでは継続的にエンジニアを募集しています！興味のある方はお気軽にご連絡ください！

iOS -> https://www.wantedly.com/projects/59939 Android -> https://www.wantedly.com/projects/54470 Webフロント -> https://www.wantedly.com/projects/63233 インフラ/SRE -> https://www.wantedly.com/projects/57858 AI/機械学習 -> https://www.wantedly.com/projects/57462 分析/データアナリスト -> https://www.wantedly.com/projects/57201 QA/テストエンジニア -> https://www.wantedly.com/projects/64774

#rails #i18n #ruby on rails

FiNC 開発合宿 in 箱根！

はじめに

今年の夏は殆どのエンジニア勢で箱根で開発合宿開きました。

テーマは「KPIハッカソン」です。

開発合宿の様子や、成果について述べたいと思います。

開発合宿のコンセプト

FiNCの合宿は去年から行っています。合宿では、「重要かつ普段なかなか着手できないテーマに取り組む。」といった目的が有ります。

昨年度の北海道での開発合宿のテーマは「リファクタリング」でしたが、今年は「KPIハッカソン」といったテーマを掲げました。

FiNCのサービスをより良いものとするために、各チーム毎にKPIを設置して、それに基づいたUX改善やKPIの可視化等を行いました。

去年の開発合宿の記事

http://ameblo.jp/finc-spirit/entry-12043425122.html

合宿の様子

それでは、合宿の様子について書きたいと思います。今年はインターン生と社員、業務委託の方も含めて27名のエンジニアが参加しました。去年は11名でしたので、2倍以上の規模になりました。旅先は箱根です。「ホテルおかだ」という大きなホテルに宿泊しました。株式会社Loco PartnersのReluxのコンシェルジュデスクというサービスを利用して見つけました。

出発

集合は金曜日のAM 7:00新宿駅です。前日夜遅くまで仕事している方もいましたが、思ったより皆さん元気でした。 FiNCのエンジニアのタフさにはいつも脱帽します。

新宿発箱根行のロマンスカーに乗りました。

開発①

思ったよりも豪華な会議室でした。

コンセントやWi-Fiも十分にそろっていて不自由なく開発できました。

会議室はほぼ埋まりました。

ランチ

ランチは豪華なバイキングでした。サラダやおかずやお肉の他に、お寿司やおそばなどもあり満足できました。

ランチの写真は撮り忘れてしまいましたのでホテルのHPの写真を載せておきます。

開発②

ランチの後はまた開発をします。足湯開発をしているエンジニアを発見しました。

事前に用意した部屋割りアルゴリズムによって部屋が決まりました。

温泉

箱根といえば。。　お待ちかねの温泉です。

温泉の写真は取れませんでしたので、またHPから拝借致します。

大浴場と露天風呂に虜になり、3回も温泉に入っていたエンジニアもいました。

宴会

宴会後は開発をしなくても済むように、あえて21時から開始しました。

宴会場も非常に大きいです。 FiNCの宴会は特に関西勢エンジニアが声がでかい盛り上げてくれます。

浴衣姿の女性エンジニア陣です。

彼女たちが来てくれたおかげで、更に盛り上がりました。

宴会から来た菅谷さん。仕事して下さい。

最終的にはこんな感じになりました。

ランチ

二日目のランチは、いくつかの箱根のお店のラインナップを用意して、好きな場所に行きました。

私は蕎麦をたべました。

成果発表

1泊2日の開発合宿が終わり、ついに発表です。

全10チームほど有りますが、各自出来上がったプロダクトのデモをしたり、分析ツールのライブコーディングを見せたりしました。

中にはエラー画面を見せてしまった人もいましたが、今まで触っていたプロダクトのUXが明らかに良くなった結果を見ることが出来たり、他のチームでの取り組みを自分のチームにも取り入れよう等といった多くの気づきを得ることが出来ました。

プロジェクターやマイク、スピーカーなどもホテルに用意してもらいました。

解散

集合写真です。改めて人数増えたなと感じました。

来年は更にこの2倍の人数が集合写真に映るんじゃないかと思っています。

ノスタルジックになっているようです。

二泊目 go to 熱海！

実は、開発合宿だけじゃ体力が有り余るエンジニア達と一緒に箱根の次は熱海に遊びに行きました！熱海では開発なしです！

写真は少ないですが、お寿司を食べたり、温泉に入ったり、海で遊んだり、山で遊んだり。非常にアクティブな2泊3日の旅でした。

熱海でお寿司とお酒。

弊社のCTOです。

インターン生が企画してくれました。

開発の成果

一例としてアプリのチュートリアル突破率向上チームの成果を紹介したいと思います。

FiNCアプリは健康に関する興味や、ユーザーの生活習慣に関する情報を入力していますが、よりユーザーがアプリとインタラクティブなコミュニケーションをしている感を出すために、今までのアンケートスタイルをやめて、チャットと対話するようなUIにアップデートしました。

まだリリースしたばかりですが、今後もKPIを追って改善していく模様です。

アプリチュートリアル(Before)

アプリチュートリアル(After)

よりインタラクティブなUI/UXに変わっており、ユーザーが情報を入力する際の心理的な抵抗を軽減しています。

他にも様々な開発に取り組みました。

ウェアラブル連携

店舗検索機能

Deployの高速化

KPIの可視化

ABテストの仕組み

ランキングサーバーの実装

AWSの管理ツール

等など、各サービスのUXを改善する機能やKPIを可視化するツールが一度に出来上がりました。

普段は一つのプロジェクトだけでなく、マルチタスクを求められることも多かったり、コミュニケーションに時間をとられることも多い日々の中で、こういった集中できる環境で開発と、心身ともにリフレッシュできるこのような機会はチームビルディングの観点でも、成果を生み出すという観点からも貴重な機会となりました。

また、来年の開発合宿を楽しみにしたいと思います。

重村

#開発合宿

FiNC iOSエンジニアの1日

今年の2月からFiNCでiOSのエンジニアをやっている小島(@kotala_b)です。

今回はFiNCでのアプリ開発について、iOSエンジニア目線で1日を振り返りながらご紹介します。

朝会 10:00~

iOSチームの1日は朝会から始まります。エンジニアは基本的には始業時間は10時からとなっていて、iOSチームでは10時からオフィスの窓際にある席(通称ファミレス席)に集まり朝会をしています。

朝会は15分〜20分程度の時間で、進捗確認や今日やること、何か問題が起きていないかなどのシェアを行っています。

開発 10:20~

快適な開発環境

FiNCではエンジニア専用にハーマンミラーのエンボディチェアというオフィスチェアが用意されています。

エンボディチェアは背もたれのカーブやリクライニングの倒れ具合などを細かく調整ができ体の負担をかなり軽減してくれるので、一日中ほとんど座りっぱなしのエンジニアにとってはとても素晴らしいアイテムです。

デスクは同社のエンベロップデスクというデスクを使っていて、天板の傾きを調節することができたりカラダがすっぽりはまるような形になっています。

エンボディチェアとエンベロップデスクという組み合わせのすごく快適な開発環境が整っています！

開発ツール

FiNCではGithub/JIRA/Slackという3つのツールを主に使って開発を進めています。

エンジニアはGithubを使い、PullRequestベースで開発を進めています。

プロジェクト運用にはスクラムを採用していて、エンジニアだけでなく企画やデザインなどの工程も管理できるよう、チケット管理にはJIRAを使っています。

コミュニケーションツールはSlackを導入していて、エンジニアだけでなく社長も副社長もインターンも全員が使っています。話しかける相手が目の前にいてもSlackで話しかけることもあれば、少し離れた席に人に大きめの声で声をかけたり、その時々によって臨機応変にコミュニケーションを取っています。

ランチ 12:00~

iOSチームでは毎週月曜にWWDCの動画を見ながらランチを食べる、WWDC動画鑑賞会を行っています。

近くの弁当屋さんで買ってきた弁当を食べながら、各々が気になるセッションビデオを持ち寄ってみることにしています。基本的には自由参加なのですが、だいたいみんな参加しています。

ミーティング XX:00~

大きな粒度のものでは2週間に1度、サーバーサイド/Android/iOS/デザイナー/ディレクター/QAのように開発に関わる全ての人が集まり、オープンなスペースでミーティングを行っています。このミーティングでは、スクラムの次のスプリントでどんな機能を開発していくかを話し合っています。

30分や1時間単位のミーティング以外にも小さなミーティングをすることが結構あり、ホワイトボードの周りに集まり設計について話し合ったり、企画と実装で認識にずれがないかコミュニケーションを取りながら開発を進めています。

さいごに

FiNCではエンジニアを募集しています！興味のある方はお気軽にご連絡ください！

Nativeエンジニアにとっての大胆な共通化と細部へのこだわり

はじめに

FiNCでAndroidエンジニアをやっているKENです。

今回はクライアントエンジニアとしてアプリを作る上で感じるデザインの"共通化と細部へのこだわり"の重要性について書きたいと思います。

- Less is more (より少ないことは、より豊かである) -

これはミース・ファン・デル・ローエという建築家の有名な言葉です。ファンズワース邸やバルセロナチェアといった大胆にシンプルかつ細部機能的なデザインを多く行った建築家です。

"共通化"のデザイン的有用性は "Less is more" の考え方に詰まっています。

"Less is more"で僕が思い出すのがiPhone4sです。 iPhone4sのデザインが僕にとっては非常にしっくりきます。日本ではiPhoneの普及率が高いので、iPhone端末に同じ様な感情を抱く方も少なくはないのではないかと思います。

なぜiPhoneのデザインがこんなにしっくりくるのか。僕の好きな4sを例にちょっと分解してみました。

実はiPhone4s ４種類の形しか構成要素がない！

もっと言うとグレーの3つは縦横縮めた結果とも言えるので極端な話もはや２種類の要素です！

たった2つの共通コンポーネントの組み合わせによって世界的に受け入れられるiPhoneという素晴らしいプロダクトができています。

各コンポーネントの機能の違いは配置やサイズなどの差で十分に理解できます。

洗練された共通要素で構成されれいることで次のメリットが得られます。 - 少しの違いが際立ちわかりやすさを生みます。 - 作る方も余計なことを考えずに概形が整えられます。 - 細かいところにこだわる時間が作れます。

これは相当 Less is more !!!

"Less is more" をAndroidやiOSのアプリで考えると

よく使う画面やコンポーネントのパターンは大体決まってますよね。各コンポーネントが共通で使える洗練されたものになっていることがアプリにおいても非常に重要だと思います。

"だいたい一緒なんだけど割と違う"みたいな複数のコンポーネントがあったとしたら「本当にその違いがないとユーザーは理解できないのか？」と疑うべきだと思っています。

FiNCではよくエンジニアがデザインレビューにも参加して議論します。その際、デザインに含まれる各コンポーネントに下記が備わっているかをチェックしてあげることで ”Less is more” なデザインとソースコードにすることが可能なのではないかと考えています。

そのコンポーネントはアプリ内の様々なケースに使えるか？ (再利用性)

そのコンポーネントが使われる共通の用途を短い言葉で説明できるか？ (UIの明瞭性)

そのコンポーネントが使われるであろうその他のケースを多くイメージできているか？ (カスタマイズ性)

そのコンポーネントは既存のコンポーネントで代用不可能か？ (統一性)

上記４つを網羅できているコンポーネントであればユーザーが変に迷わず、見てすぐ取るべきアクションがわかる UXとしても良いアプリができると思います。

さらには将来的に工数を削れ、車輪の再発明ではなくもっと重要なことにデザイナーとエンジニアのリソースを割くことができます。

共通化から生まれる細部へのこだわりの重要性

ここまでは共通化によりシンプルにすることのメリットについてでした。次は細部の作り込みの重要性についてです。

- God is in detail -

ミースはこうも言っています。神は細部に宿る。

無駄なUIや機能を削りに削って洗練された共通化がなされたプロダクトには神が宿る細部を見つけやすいという効果があると思います。

冒頭で出したiPhone4sのデザインで言えば

端末側部のマナーモード or 音声ONを設定するバーには、よく見ると下図の赤の部分のような線が入っています。

右にスライドすると音声がONになることを示しています。

ちょっと考えてみてください。別に、こんな赤い点でもいいですよね。

でも赤い点だと実際の端末の大きさだと小さくてそれがこのコンポーネントの右寄りなのか左寄りなのか伝わりづらいかも？点だとさすがに小さすぎて気づけないかも？

ONという文字にしたらどうでしょう？

onを視認性を保ったサイズで実現するには領域が狭すぎる？

おそらくiPhoneの一つ一つのデザインは相当数のケーススタディーを各コンポーネントの位置や色素材感など細部に対して何度も繰り返した結果できたものなのではないかと思います。

一度、大胆に単純な丸や四角で表現しきってしまうと、強烈なシンプルさ故にそれだけでは解決できなかった細かいけれど大きな問題が必ず出てきます。

そこに当てられた解決策こそ細部に宿る神を引き出すと思います。

まとめ

共通化はUX的にも開発工数的にも良い影響が大きい

共通化によって本当にこだわるべき細部は見えてくる

影ながらインパクトのあるこだわり(細部)を炙り出せる共通化をデザインにもソースコードにも適応していくことでいいプロダクトを作っていきたいと思います！

FiNCのAndroidチームではMVPを採用したストラクチャーの構築や UIコンポーネントの共通化を推進しており、一緒にアプリを根本から良くしたいという思いのある仲間を募集しています！

https://www.wantedly.com/projects/54470

サーバーエンジニアがクライアントアプリを書くにあたって知っておくと良かったこと

自己紹介

初めまして、今年の4月からFiNCでエンジニアをやっている高見(@sukesan1984)と申します。

前職では、ソーシャルゲームの会社でサーバーサイドとクライアントサイドを半々ぐらいやっていて、 FiNCでは、サーバーサイドを少しやった後、Androidチームに入って今全力でキャッチアップしているところです。

この記事ではサーバーエンジニアだった自分がクライアントエンジニアになるにあたってどういうところで苦労したか、何を知っていれば楽だったのかなどをお伝えできればと思っています。

異なる点と難しさ

難しいと感じる部分もありますが、知識的なところがほとんどなので、知っていればさくっと入れたりします。恐れず両方やっていきましょう！

言語・フレームワークの違い

まず、多くの場合、サーバーサイドとクライアントサイドで、プログラミング言語が違うケースが多いです。中にはサーバー、クライアントで同じコード使いまわせるといった理由で同じ言語を選ぶケースがあると思いますが、大方のケースでは異なる言語であることが多いのではないでしょうか？これに関してはあまり問題になることはなく、一つの言語をある程度深く理解できていれば、異なる言語はすぐ使えるようになります（＊使いこなせるようになるというと少し時間がかかるかもしれませんが）その言語の全体像が見える入門書を何か一冊ざっと読めば書けるようにはなるでしょう。(web上に転がるリファレンスを見ながらでも十分です）

どちらかというと、言語それ自体よりもフレームワークが採用している思想を理解するというところのほうが厄介なところです。例えば、AndroidでいうとJavaは大丈夫でもAndroid独特のライフサイクルだったりというのはまだまだ深く理解できておらず苦労する部分が多いです。どちらかというとキャッチアップに関しては、言語自体はほどほどに、フレームワークの理解に重きをおくのが良いです。

コードリーディングの難しさ

例えば、ある機能を追加しようと思った時に、サーバーであれば、（特にバックエンドのシンプルなAPIに限って言えば、）処理の開始は、リクエストから始まり、最終的にはレスポンスを返して一連の処理の流れは一本道で、エンドポイントさえ分かれば、処理の流れは追いやすく、理解もしやすいです。

一方クライアントに関しては、mainループが回っていて、ユーザーからのインプットは種々様々で画面のタッチであったり、キーダウンだったりといったところから処理が始まります。なので、ユーザーのインプットを受けているところはどこなのか？というところが一見わかりにくい時があります。処理の流れを追うというところに関しても、非同期で割り込みが入ってきたり、イベント駆動で何らかの処理をobserveしているようなケースもあったりして、（コードの書き方にもよると思いますが）一見して追いにくいということがあるように思えます。こういったところに関しては、プロジェクトに依存する部分が多いと思いますが、最初にdirectoryの切り方、各クラスの依存関係、イベント駆動するときのルール、非同期処理をどうしているかなどの説明を最初に受けておければ比較的スムーズに入ることができるのではないでしょうか？

時間がかかる処理を分割するという考え方

サーバーサイドにおいて、処理速度というと、リクエストからレスポンスをとにかく早くするというところを意識することが多いです。クライアントサイドにおいても同じように一つ一つの処理の速度を上げていくというのはある一方で、同じ時間処理がかかるのだけれど、体感として処理の時間を短くするということが結構重要になってきます（例えば、ローディングインジケータを出す。その間にアニメーションさせるといったこと）。その体感時間を削減するような処理自体を止めないように気を使う必要があります。上記で少し述べましたが、mainループの中でupdate/renderが毎フレーム走るのでスムーズに描画がされるためには、維持したいfpsによって、1フレームあたりにかけられる処理時間が限られてきます。例えば、60fpsをキープしようとした場合、1フレームの処理時間を16.67ms以内に収めないといけません。そうした中で、簡単な例でいくと、どうしても1000msかかってしまう処理をこなそうと思った時に、1フレーム内で処理してしまうと、1秒間の間に描画(render)が一回しか呼ばれないために、画面が固まったように見えてしまいます。一方で、1000msを60分割してあげれば、同じ1000msかかる処理も見た目上では描画が進んでいるので、体感としてはわからないということがあります。サーバーサイドからクライアントサイドに移行した時に最初にミスしたのがこの部分でした。 1フレームの間にデータロードの処理を詰め込み過ぎてしまい、ローディングインジケータを出していてもそのローディングインジケータ自体のアニメーションすら止まってしまう。ということがありました。これでは、ユーザーにとってカクカクして気持ち悪い処理になってしまいます。各フレームに処理を分散させるという概念が結構重要になるなと感じています。

スケールさせようにも、使えるリソースに限界があるということ

サーバーサイドであれば、サーバーの台数を増やすなどして、力技でスケールすることが可能です。（コストはもちろんかかるので、意識しないわけにはいかないですが）一方で、クライアントサイドは、使用している端末に大きく依存するということがあります。特定端末でパフォーマンスが悪いからといって、端末を配るということは現実的ではないかと思います。なので、最初にどの端末までをターゲット端末とするのかを決めていくことが重要になります。その端末をミニマムとして、どこにリソースを配分するか、使えるメモリはどれくらいなのか？アセットのサイズは初期DLサイズ、追加DLサイズ含めてどれくらいに抑えなければいけないか。最初から未来を見越して考えておかないと、スケールできなくなり詰むということがありえます。最初にあまり考えていなくて、どうしても無理みたいなことが起きうるのがクライアント開発の怖いところだなと感じます。

画面（見た目）を作るのが８割ぐらい

クライアントサイドの実装においては、見た目に関わる部分が相当な量を占めると実感しています。ロジック自体は簡単でも、見た目を作り込むということは、思っている以上に難しく、時間的な割合で言うと８割ぐらいが見た目に関わる部分を作っているのではないかという印象です。サーバーサイドでフロントエンドをほとんど触ったことのなかった自分にとっては、かなり苦戦した部分になります。 UIを画面に出すというだけでも・オブジェクトのライフサイクル・リソース・データのロード・キャッシュ・レンダリング順序や効率・アニメーション・モデルとの紐付け・状態遷移の管理・インプット制御など考えないといけないことが結構多いのですが、知らないと全く考慮せずに作ってしまうので後々苦労するということがあります。特にアニメーションの部分に関しては、エンジニアが考える粒度とデザイナが考えるかっこいいアニメーションというのは度々一致しないことが多かったりするので、あまり明確に固まる前から走り出すのも危険だなという部分を感じていたりします。

何が嬉しいの？

では、そうやってサーバーとクライアントどっちもできたら何が嬉しいのかというところですが、割とメリットは大きいのかなと思っています。

リソースの流動性

開発をしていて、よく直面する場面としては、「サーバーサイド（クライアントサイド）はできているんですが、もう一方が遅れていて」といった場面です。そういう時に、どっちもできるエンジニアがいれば、足りなくなっている部分にささっと入ることができます。また、採用の面でも、全領域の人を満遍なく取るというのは難しいです。アプリを作っていく上では、サーバーとクライアントの速度を合わせていかないと一方だけ、人数が多すぎてもなかなか速度が上がってこないということがあると思います。そうした時に、コンバートできる人材がいれば、多少偏った採用をしてしまったとしても、バランスをとることができ、重宝されます。

責務をうまく分けられる

この処理はサーバーでやるべきか、あるいはクライアントでやるべきか？というところをどちらも知っているとより適切に答えが出せる気がします。画像をURLを返して都度取得するのか、あるいはアセットとして初回にダウンロードしてキャッシュする形式にするのか？返すべきレスポンスの形式をどうするか？モデルとしての一単位をクライアントとしてはどう持ちたいか？そういったことも実際のお互いの実装を考えながら作っていけるということは、クライアント・サーバーの責務をうまく分離できることにつながります。つまり、お互いのかゆいところがわかるので、ここはサーバーがやってくれたら嬉しいんだけど・・みたいなところもコミュニケーションさくっと取れたりします。

一人で完結する

リソースの流動性というところと絡みますが、一人でサーバー作ってクライアント作って完結するので、ちょっとした機能・アプリであれば、一人でできてしまいます。これは圧倒的にスピードが早いです。全部自分で作るので、クラサバ間での議論もなし、APIの型のやり取りも最小限で済みます。会社という組織で考えると、あまりメリットを感じにくいかもしれませんが、個人的にアプリを作ったりするときは自由に作れるようになるので楽しいです。話が逸れますが、一人で全部やってリリースすると、インフラについても触れることになるので、それもマルチ領域人材への一歩かもしれません。

まとめ

まとめると、難しいと感じる部分も多いですが、それぞれパラダイムが違い新鮮で面白いので、機会があれば積極的にサーバー、クライアントに限らず他領域に挑戦してみると良いと思います。一度、別領域に行きその後にまた戻ってくると異なる発見があったりするのも面白いところです。

FiNCでは、多領域を見れるエンジニアをどんどん増やしていきたいと思っています。自分の専門領域以外の様々な領域にチャレンジしたいエンジニアを募集しています！

FRPを用いた開発に興味があるAndroidエンジニアを募集！

iOS10を利用したヘルスケアアプリを作りたいSwiftエンジニア募集！

＜有楽町Newオフィス！＞ヘルスケアサービスのRailsエンジニアを募集！

余談ですが、最近恐ろしく姿勢が悪いということで、FiNCのパーソナルトレーニングを業務の合間に受けていて、少しずつ体が柔軟になると共に、引き締まってきた感じがします。

Microservices Meetup Vol.1 を開催しました

こんにちは、技術開発本部の森 ( @qsona ) と申します。これを書いているのは開発合宿へ向かう小田急ロマンスカーの中です。楽しみです。

さて、2016/7/7 (木) に、Microservices Meetup vol.1 (connpass) を開催いたしました。本記事ではその様子をレポートします。

当日のTwitterのタイムラインの様子は、こちらのtogetterにまとめております。

Basic LT by @qsona

資料

マイクロサービスに関する基礎的な話題を1つ提供するコーナーです。今回は「データベース結合を避ける」ことについて話しました。

「ニュースパスのサーバレスなマイクロサービス」 by @y_matsuwitter

資料

無料ニュース配信アプリ「ニュースパス」のアーキテクチャについて話してくださいました。

マイクロサービスとして非常に貴重な実例紹介で、ニュースアプリの特徴を生かし、AWSの上手に活かした構成で、とても勉強になりました。資料も非常によくまとめて下さっていています。

「API Gatewayの話」 by @charlier_shoe

資料

API Gateway(APIサーバのフロント寄りに置く層)についての話をして下さいました。

一口にAPI GatewayあるいはBFFと言ってもその役割は様々で、その役割を丁寧に分解しながら、事例紹介をしてくださいました。

特に個人的には、API GatewayがAPIアグリゲーションを前提としていない(実際にAPI Gatewayを謳ったライブラリでアグリゲートの機能がないものが複数ある)ということに驚きましたが、それだけ多くの役割が期待される層と言えることになります。

弊社FiNCにおいても、クライアントとバックエンドサーバの中間に位置するサーバを導入すべく技術検討をしております。

「Microservicesのフロントエンドどうしてるの？」 by @teppeis

資料

Webフロントエンドからの視点で、マイクロサービスへの問題提起をして下さいました。

「マイクロサービスは組織論である」、すなわちチームが独立して動けるようにするためのマイクロサービスであるが、そこにUIも含まれなければ真に目的は達成できない、とするとそれはどう実現するのか? or UXと相反するのではないか? という、非常に考えさせられる内容でした。

パネルディスカッション「マイクロサービスとフロントエンド」

パネリスト @teppeis, @yosuke_furukawa, @axross_

お三方とも、Webフロントエンジニアであり、かつ幅広い知識を有して活躍されているエンジニアです。非常に濃密な議論を聞くことができました。

togetterのこのあたりで議論の様子が伺えます。

懇親会

懇親会の前に、弊社管理栄養士の高木(たかき)より、今日のメニューについての説明と、健康的な食事法についてのレクチャーです。今日のメニューでは、「ピンチョスから食べましょう」。

おかげさまで、大変内容が濃く、盛り上がった良い会にすることができました。個人的にも、パネリストの方々と事前に打ち合わせさせて頂いたり、当日も発表を聴いたり司会進行する中で、様々な事柄に触れ、勉強させていただきました。発表・パネルディスカッションに参加いただいた5人の方々には特に感謝しております。また足を運んでくださった皆様、会を盛り上げて頂き、ありがとうございました。

最後に

次回 vol.2 は2016/8/9(火)です (connpass)。マイクロサービスについてさらに議論を深めていきたいと考えております。またご報告いたします。

また、株式会社FiNCでは、マイクロサービスに興味があるエンジニアを募集しております。皆様のご応募お待ちしております。

#microservices

Separate the What from the How

(Author: Daniel Lopez)

Introduction

Like most of us, the discipline of software development started as a hobby before becoming my profession. Also, in my case, during a long part of my career I was a Linux systems engineer and because of that, even if writing code was a part of my daily tasks, I was not exactly what people call a developer.

I explain this because I want to talk about something I realized when software development became my main occupation.

Before becoming a developer, I always wrote code to make the computer do what I wanted. I wanted my backups to run on time, I wanted to parse logs to get meaningful information about errors and performance, I wanted some processes run automatically under certain circumstances, etc. The scripts I used to write where made to perform a specific task and --to say it in a certain way-- they where a private matter between the computer and I.

Then, I became full time software developer and I started to work in a codebase that was maintained by many other developers; and it was in that moment when I understood something really important: although the end goal of the code I was writing was to instruct the machine on how to do its job, I was not writing code for the machine, I was writing code for my fellow developers!

My job had become to describe, with code, the processes that composed the daily operation of our company. Our code was the manual of instructions that described what our company was! That day I became aware that the first priority of a developer is to write clear code that is easy to understand by any other developer.

Writing clear code is art, craft and science. Many books have been written about this discipline, and there innumerable techniques that can help us to achieve this goal but, I would like to talk about one basic technique that, in my opinion, can make a big difference in a codebase. This technique consists in understanding the difference between the What and the How and write code according to this difference.

From now I will use the terms "What Layer" and "How Layer". This names refer to the intent of each of the layers. Also, when I talk about layers I refer to any logical level in the code. It can be methods in a class, a class hierarchy or even a module that is extracted from the main logic.

The What layer

The What layer contains all the set of rules that determine the function of a module, a class, or an application: what we call business logic. The What is the reason why we are building this code and we must make it stand out in order to make it understandable by anyone reading our codebase. The What can be, for instance, that a discount coupon can be only used once by a customer; or the content of the email that we will send to this customer after buying one of our products. On another level, the What can be as well the URL of an API endpoint we want to connect to, the information we want to extract from the response and, maybe, if we need to validate it in a particular way.

If we think on our code as a set of layers, the What should always be the top one. We must keep in mind, though, that systems are most of the times composed by other subsystems, and those other subsystems will have as well their own top layer (What) that describes its purpose, and so on in a kind of fractal schema.

The How layer

The How is the rest of the code. The implementation details. The How is where we deal with the technical stuff that makes the program work: connect to the database, extract the information from an array, the REGEX that will validate a telephone number.

The How layer is composed by all those pieces of code that describe processes that are not exclusive to our company. Processes that a lot of times can be reused elsewhere, to the point that sometimes it will make sense to extract that code to an external library.

The purpose of this layer is to serve the What layer on top and it and, therefore, it is not bad to add a bit more complexity to this layer if this will make the upper layers easier to understand. For those programming in Ruby, if using metaprogramming at all, it should only be used in the How layer.

Conclusion

Code clarity is one of the most important characteristics that we should pursue in software development. It will not only make it easier for new developers to be able to start to be productive in less time, but it will also allow us to develop faster and with less bugs.

A developer that reads a codebase for the first time, needs to be able to read the code layer by layer, one level of abstraction as a time, in order to make sense of it. And a really good way to write code that meets this goal is to write declarative code that stand out our main intention for every level of the application.

Enjoy coding!

エンジニアが分析をする上で心得たいこと〜初歩編

分析が必要になる時がくる

ベンチャーのエンジニアは、プロダクトがスタートアップフェーズをなんとか乗り越えると、ユーザー数がある程度落ち着き、各KPIを上げていくぞ！という段階に移っていきます。そのような中で、あまり分析に気を使っていなかった状態から、徐々にどういったことに意識していくべきかをイメージして書きました。

プロダクトの成長線に合わせ、分析にフォーカスしていく

エンジニアの仕事とは

普段僕らが使っている時間を振り返ると、多くの時間はコードを書き、それをメンテナンスする作業が多くを占めているかもしれません。しかしそれらの作業は全て、「プロダクトを作ることを通してユーザーに価値を届けること」のためにあるはずです。普段している作業はあくまでそのステップのひとつに過ぎません。エンジニアの業種業態で異なることがあるかもしれませんが、少なくともFiNCのエンジニアは「プロダクトを通して世界を変える」ことに向けて努力しています。

ユーザーの価値があいまいな機能はそもそも作ってはいけない

グロースフェーズになると、中長期的にプロダクトの改善を行う必要性が高まります。なので、「なんとなくこれあれば便利そう」と気ままに機能をつけていくとPDCAができなくなるので、やるべきではないでしょう。また、機能改善をしている中で「これはどう考えても必須」のように見える機能追加もあるかと思いますが、当たり前だとしても言語化・定義化することがPDCAのスタートラインです。うまく言語化できない場合もあるとは思いますが、それでもよいと思います。何かしら言葉にしておきましょう。直感を否定するわけではありません。

ユーザーへの提供価値が暗黙の了解になると、仕様も何が正しいかわからず、おのずと仕様が単なる好き嫌いの争いになりやすいです。「どんな価値を届けたいか？」がわかると説得力が増し、意思決定のスピードも早まると思います。

ユーザーに提供できた価値を確かめるのも、エンジニアの仕事になる

機能の追加・改善はリリースするだけでは、本当に価値を届けられたのかはわかりません。もしかしたら気付かないうちに改悪していることすらありえます。プロダクト開発をする中で「この新しく追加した機能はどういった変化をもたらしたか？」ということを確かめる必要が出てきます。その結果によって、その機能をCloseすることもあるし、厚くしていくこともあります。

ユーザーのポインターや画面タップの動きを映像的にトラッキングできるツールなどもありますが、まず最初は豪華なツールはいらないので、基本的な数値をみれるようにしていきましょう。

分析を考慮した実装ステップを取り入れる

この4つのステップを踏めば、まずは十分だと思います。

1.作ろうとしているアイディアの提供価値を確認する

2.どの数値がどのように変化するかを仮説を立てる

3.現状の数値感を見る

4.実装するときに改善の数値が取れるように仕掛けておく

1.作ろうとしているアイディアの提供価値を確認する

そのアイディアが上がってきたということは、何かしらの課題に対して解決できるという期待があるはずです。まずはそのアイディアが何を解決をするのかを、定性的な言葉で書いてみます。

例: アプリ内のお知らせ機能に、画像サムネイルの表示を加える文字だけで視認できる情報が少ないため、ほとんど開かれていない。お知らせ内にお得なキャンペーンを配信することがあるが、その訴求を強められるようにしたい。など

上記は例ですが、もっとしっかり書くやり方はあります。これをどこまでしっかりやるべきかは、人員や施策のスコープを見てきめましょう。リニューアルなどの大きな改善は重厚にやるべきだし、小さめの課題解決ならシンプルに書くだけでもよいと思います。

2.どの数値がどのように変化するかを仮説を立てる

定性的な価値定義から、その価値を享受していると言えそうな数字を探していきます。

まず、ユーザーに価値を届けるまでのバリューチェーンを簡単にでも書きましょう。

例: お知らせ配信のバリューチェーンお知らせを受け取る → お知らせ一覧を開く → お知らせを選択して遷移する → 内容を見る

今回は、このバリューチェーンにおける「お知らせを選択して遷移する」という部分にフォーカスした開発になるので、見るべき数字はひとまず「サムネイル付きのお知らせ遷移数/お知らせに来た回数」だとざっくり見積もれます。

3.現状の数値感を見る

もし数字が取れているものがあった場合は、出しておきましょう。数値を出してみて、そもそもお知らせ一覧に全くアクセスがないとわかれば、優先順位をバリューチェーンの前方に移した方が得策かもしれません。（少し話は逸れますが、こういった際の優先順位を決める際には「インパクトx工数」をもとにして決めることが多いです。インパクトが少なくても、工数が相当小さかったら先にやってしまうのもアリです。）

数字が取れてなかった場合は、バリューチェーンにおけるどの部分が欠落しているのかを確認して入れていきます。

4.実装するときに改善の数値が取れるように仕掛けておく

機能改善・機能追加をする上で、作りたいものの機能要件（使用定義・完成イメージ）があると思います。分析をできる環境を整えるためには、機能要件を満たすだけでなく、「分析要件」も満たす必要があります。場合によっては機能要件で作ったDBで事足りることもありますが、例えば今回の例の場合では機能要件を満たす以上のことをする必要があるからです。

例: お知らせ機能改善の最低限の分析要件（前提：ユーザーテーブルとお知らせテーブルが存在していること）・お知らせ一覧が表示されたログを、ユーザーID、datetimeで残す・お知らせを開封したログを、ユーザーID、お知らせID、datetimeで残す

こうした数値を貯める手段をごく簡単ににまとめますが、結論から言うと「2」が分析の幅が広く対応しやすいので、オススメです。

方法1: アプリケーションのDBに分析用テーブル/カラムをとりあえずつけてしまう

今回の場合でいうと、お知らせのテーブルが存在すると仮定して、そのテーブルに read_at などのカラムを追加する、という方法などです。そのイベントのタイミング（お知らせ遷移したタイミング）で、そのカラムを更新する処理をつける、といった具合です。しかし、もしその read_at がアプリケーションロジックに全く関係なく、本当に分析にしか使われないとしたら、あまりベストな方法ではないでしょう。

方法2: アクセスログ/任意のアクションログを記録できる環境を整える

ユーザーのアクセスログを溜め込んでおき、クエリで抽出できるデータウェアハウスなどがあれば便利に分析ができます。（AWSのRedshift、TreasureDataなどがあります）これで全てのログを残せる環境を整えれば、特定の機能に限らず汎用的に分析をすることができます。また、分析のために任意のイベントのタイミングでログを吐くようにすることで、取りたい数値を自由に設定することもできます。

方法3: 分析専用のSDK/ツールを使う

Google AnalyticsやFireBaseなどは、管理コンソールから非エンジニアでも使えるようなUIで簡単な数値を見れることができます。ただ、より詳細な込み入った分析をする際には、エンジニア側でフラグをつけてあげたりする必要はあります。

取れた数値を見える化する

最初はテンポラリーで数値を出す

もし充実した可視化ツールをお持ちであればここはあまり気を使う必要はないのですが、まだ利用ユーザーが安定しないお試しの機能追加・改善であれば数値のビジュアライゼーションにそこまで多くの時間を割く必要はないと思います。まずはcsvなどにraw dataを吐いて、そこから簡単に集計してみて、まずは結果を確認することが大事です。

機能が安定したらいつでも見れるようにする

もしその機能がプロダクトUXのベースをなしており、継続的に数値を監視していきたいものになれば、数値を集計して表示するアプリケーションを用意すると、テンポラリーで数値を出すよりコスパが上がります。データのビジュアライゼーションツールは数多く存在しますが、やはりどれもコストがつきます。ただ、そこまでコストがかからなくとも利用できるものもあります。参考: データ可視化に大金を使う必要なし-最強biツールpowerbiを導入してみた

まとめ

プロダクトのスタートアップフェーズを終えたら、PDCAを回せるように数値を取りましょう

数値が取れているかを意識して実装をしましょう

現在FiNCでは基本数値の見える化が終わり、これからはその数値を「どう見るか」を踏まえてプロダクトの改善をするフェーズにいます。ヘルスケアアプリのグロースハックをこれだけふんだんにできる環境はないと思います！ FiNCでグロースハックをする人を募集しています！「データは分析するだけじゃ意味が無い！」そんなデータアナリストWanted!

FiNCでの機械学習の使われ方 ~ 数学からUI、そしてインフラまで

はじめに

FiNCでエンジニアインターンをしております、栗栖です。

現在AIチームに所属しており、画像認識の調査や、機械学習を使ったモデルのアプリケーションへの応用を担当しています。

今回は、アプリ上の課題を機械学習を使って解決した実例を、ご紹介したいと思います。

それでは、本記事のアジェンダです。

生活習慣アンケートとその課題

生活習慣の予測モデルとそのUI

Rails + Pythonによるアプリケーションの運用

まとめ

1. 生活習慣アンケートとその課題

FiNCのアプリでは、お客様の健康増進のソリューションを提供するために、生活習慣アンケートがあります。

このような生活習慣アンケートは、ベストなソリューション提供のためには必要不可欠なのですが、一定量の質問を答えなければならないため、ユーザーの負担がやや大きいということが課題でした。

そこで、設問数を減らせないのか？という問題に取り組むことになりました。

2. 生活習慣の予測モデルとそのUI

機械学習による解決策の考案

この課題（生活習慣アンケートの設問数の削減）をどのように解決するかなのですが、結論から言うと、

情報量の多い質問を抽出する

他の質問は機械学習によって回答結果を予測する

予測が間違っている場合は、ユーザーがフィードバックして簡単に修正できるようにする

という方向性で検討しました。

なぜこの考えに行き着いたのかというと、

多くの生活習慣の中には、他の生活習慣に影響を与えるような、情報量の大きな生活習慣があるはず

例えば4択の質問を5問聞くだけでも、1024通りの回答パターンがあり、十分な情報量を得られるはず

といった仮説があったからです。

仮説1に関しては、一例として、20代の女性で「間食をよくする」という情報があれば、自ずと「お菓子をよく食べる」という可能性が高いことは容易に想像できます。

仮説2には書いたそのままですが、実際、人の生活習慣は多様であるとは言え、ある程度パターンがあるため、1024通りは十分な情報量であるとも考えました。

主成分分析による、重要な質問の抽出

主成分分析は簡単に言うと「複数のベクトルから、分散が最大化されるようなベクトルを作成する」手法です。

以下はwikipediaから拝借した図です。

この図のデータセットの場合、右斜め上の矢印方向に沿ってデータが集中していることが見て取れます。

そうすると、x方向の(1, 0)ベクトルと、y方向の(0, 1)ベクトルの2つによって各座標を表すのではなく、図中の2本の矢印方向の単位ベクトルを使ったほうが、データを効率的に表現できます。

今回であれば、複数の質問の回答結果を多次元空間の座標として表せるため、そこで主成分分析を行い、抽出されたベクトルに対して寄与度の高い質問を順に選びました。

サポートベクターマシンによる回答結果の予測

サポートベクターマシン（SVM）は、特徴量を入力し、カテゴリ等の分類を行うアルゴリズムです。

今回のケースは、

年齢、性別、BMIのようなユーザーの基本情報

いくつかの質問の回答結果

を入力して、他のある質問について、回答結果をアウトプットとしました。質問は基本的に択一式なので、分類問題に帰着されます。

SVM以外のアルゴリズム、例えばランダムフォレストなども試しましたが、今回はSVMの精度が最も高かったため、採用しました。

3. Rails + Pythonによるアプリケーションの運用

運用上の課題とシステム全体像

企画が出来たところで、最後は実装についてですが、大きく分けて2つの課題がありました。

ひとつは、FiNCのアプリケーションの大半はRailsにより実装されていますが、数理統計・機械学習のライブラリはPythonを利用したかったため、これらを共存させなければいけない、ということです。

もうひとつは、機械学習の場合、Trainingという過去のデータからモデルを作成するプロセスと、Testという実際にそのモデルで予測等を行うプロセスとの2つがあり、これらのサーバー間の連携です。

結果的に、システムの全体像は以下のようになりました。

以下の点がポイントに絞ってご紹介したいと思います。

定期的に立ち上げるTrainingサーバ

S3を介したスクリプトの配布

Railsからpythonのプロセスを作動

定期的に立ち上げるTrainingサーバ

予測モデルを生成するには、過去のデータを使ってTrainingを行う必要があります。

理論上、データが増えれば増えるほど、モデルの精度は良くなるので、定期的にTrainingを行う必要があります。とはいえ、データがあまり増えていなければそれほどモデルに変化が無いため、実際にはTrainingは週に1回や月に数回程度行います。ですので、Trainingサーバーは定期的に立ち上げて運用するようにしています。

執筆時点ではモデルの頻繁な改良もあるため、手動での作業がメインですが、運用が安定化してくれば、cronサーバから自動で立ち上げ・シャットダウンに完全に移行予定です。また、コスト削減のためにスポットインスタンスの利用も検討しています。

S3を介したスクリプトの配付

Training用のサーバーで出来たモデルのスクリプトを、実際に動かすTestサーバーに転送しなければいけないのですが、このファイルのやり取りにはS3を経由させています。

S3を経由させる以外にも、

scp、rsyncコマンドによるスクリプトの転送

自動でGithubにforce push & CI経由によるデプロイ

などの手段が考えましたが、最終的にS3に一旦アップロードする運用が安全であると結論付けました。 Testサーバーのスクリプトはデプロイ時に自動でS3からダウンロードするようにしています。

Railsからpythonのプロセスを作動

Trainingによって生成されたモデルスクリプトを実際にどのように動かすのかが問題です。やり方として、

Python専用のサーバーを作成しAPIで連携する

Rubyを運用しているサーバーでPythonも動かす

の2通りの方法が考えられますが、結果的に2を採用しました。

1の方法の場合、サーバー構成管理は楽になのですが、サーバーを増やしたりPythonのアプリケーションを作成しなければいけないので、手間はかかります。

一方2の方法の場合、Rubyを動かしているサーバーにPythonのモジュール等もインストールしなければならず、Ansibleによるサーバー構成管理は多少、煩雑になります。しかし、シェルスクリプト経由でPythonを動作させるだけなので、アプリケーションレイヤーの開発は非常に楽になります。

この両者を比較した時、今回の場合、スクリプトを動かすためだけに別のサービスを立ち上げることの手間の方が大きいと考えました。また、FiNCはマイクロサービスを採用しているため、このような特殊なサーバー構成も気軽に行える状況にありました。こうして、方法2のRubyのサーバーでPythonを動かす方法を採用するに至りました。

4. まとめ

ご紹介したように、FiNCのAIチームは、サービス上の課題発見から、機械学習による解決策の提示、UIまで含めた企画、実装・運用までを広く担っています。

今回行った改善では、必須質問数は従来の6分の1程度になり、回答率も15%程度向上しました。

この他にも、

ソリューションのパーソナライズ

食事画像の認識

SNSでのユーザー推薦

タイムラインの最適化

など、様々なプロジェクトが動いております。ご興味ある方は是非、気軽にFiNCに遊びに来ていただければと思います

AIエンジニア募集中です。

Trending Blogs

Recently Viewed Blogs

FiNC Developers Blog