ライブストリーミングHack #3 にて登壇しました

こんにちは。
SHOWROOMエンジニアの齋藤です。

11/15(木)にMirrativさんとSHOWROOMの合同イベント「ライブストリーミングHack #3」が行われました。

mirrativ.connpass.com

ご参加いただいた方々、ありがとうございました。
今回は「ライブ配信を支えるサーバーエンジニア」をテーマに、Mirrativさんと弊社でそれぞれ2名ずつお話しさせていただきました。
簡単ではありますがイベントの様子をお送りします。

登壇内容

弊社からは私齋藤とシミズの2名が登壇させていただきました。
スライドと簡単な内容をご紹介します。

カスタマーサービス品質向上へのエンジニア的アプローチ

speakerdeck.com

サーバーサイドエンジニアとは「当たり前品質」を向上させるのが役割である
という点から、「当たり前品質」の1つであるカスタマーサービスに対して
エンジニアとしてどう関わっているのか?
何を意識しているのか?
という点をお話しさせていただきました。

あまりテクニカルな内容ではないですが、サービスの信頼度を上げていくためには避けて通れない場所だと思っています。

同じような問題に向き合ってる方とも懇親会でお話しさせていただき、非常に勉強になりました。
また、今までよりもここに注力して、次の機会ではもっと大きな成果をご報告できるようにしなければ…!と決意を新たに固める機会にもなりました。
お話しさせていただいた方々、どうもありがとうございました。

SHOWROOMのDB負荷に対するキャッシュ運用のカクカクシカジカ

speakerdeck.com

こちらはシミズの登壇スライドになります。
DB負荷対策してるとはいうけれど、実際はどのような対策を行っているのか、
具体的な事例も紹介しながらの内容でした。

スライドの中にもありますが、ライブ配信サービスならではの大変さに
「いきなり人気配信が始まる」
というものがあります。

当然ながらいきなり始まった配信に対して
常にその場でアドリブ対応が出来るわけではないので、日頃から負荷対策を意識しておくことはもちろん重要ですし 、万が一の時に焦らないよう、十分な心構えをしておく必要もあります。
ユーザーのみなさまが楽しみにしている配信を無事にお届けするためにも、こういう地道な作業を1つずつ追求していくんだ、というメッセージは、同じサーバーサイドエンジニアとして、思うところの多い内容でした。

ちなみにスライド冒頭にて紹介されている
「Streaming Conference #4」の様子は以下のページにて公開されています。

tech.showroom.co.jp

終わりに

改めて「サーバーサイドエンジニア」という括りで考えると、その仕事はやはりフロントやアプリと比べたら地味になりがちです。
それでもここがサービスの土台なんだ、
という意識は常に持っておきたいですし、
今回はそういう話ができたのではないかな、と思います。

Mirrativさんのお話も非常に興味深い内容で
次の機会では自分ももう少しテクニカルな内容だったりとか
「〇〇を導入した理由とハマりポイント」
みたいな話をしてみたいな、とも思いました。
そのためには何かを導入しないといけないですね。
ネタ探しをしなければ…!

さて、 そんなSHOWROOMでは
情熱を持って一緒にお仕事ができるエンジニアを募集しております。
ご興味がある方はぜひ一度来ていただければ!

www.wantedly.com

LINEのMessaging APIのアカウント連携機能を使ってSHOWROOMとLINEを連携させて見た

こんにちわ。 SHOWROOMエンジニアのシミズです。
業務の合間をぬって、ひっそりとLINEのMessaging APIで遊んでいましたがそれがそこそこ形になってきました。

それがこちらです。

SHOWROOMのライブ開始をLINEに通知する

これは何かというと

  1. SHOWROOMのユーザーIDとLINEのユーザーIDを連携する
  2. SHOWROOMのお気に入りルーム情報を取得する
  3. LINEにSHOWROOMのお気に入りルームのライブ開始を通知する

というボットアプリです。(リリースするかは未定です。)

この投稿では「SHOWROOMのユーザーIDとLINEのユーザーIDを連携する」という部分について実際の画面のキャプチャを用いて解説したいと思います。

LINEのMessaging APIにはよりセキュアにLINEユーザーのアカウントとSHOWROOMなど既存サービスのユーザーアカウントを連携する仕組みが提供されており、今回はそれを利用しました。
公式のドキュメントと合わせてお読みいただければと思います。
https://developers.line.me/ja/docs/messaging-api/linking-accounts/

全体のシーケンス

f:id:otto13:20181109010648p:plain

アカウント連携開始URLを取得する

f:id:otto13:20181109000501p:plain

アカウント連携開始URLを要求するのに、リッチメニューからポストバックアクションを利用しました。
リッチメニューの「アカウント連携」ボタンを押下すると、LINEプラットフォームを経由して、我々のBotServerにリクエストが到達します。
するとBotServerはLINEプラットフォームにaccount_link_tokenを要求します。

require 'line/bot/request'
require 'line/bot/api/errors'
require 'line/bot'
class MyLineBotClient < Line::Bot::Client
  def apply_account_link_token(user_id)
    raise Line::Bot::API::InvalidCredentialsError, 'Invalidates credentials' unless credentials?

    request = Line::Bot::Request.new do |config|
      config.httpclient     = httpclient
      config.endpoint       = endpoint
      config.endpoint_path  = "/bot/user/#{user_id}/linkToken"
      config.credentials    = credentials
    end
    request.post
  end
end

rubyでこんな感じのメソッド用意してlink_tokenを取得しています。
取得したlink_tokenを組み込んで、showroomのOAuth認証ページへのURLを作成しLINEクライアントに返します。
このURLはテンプレートメッセージを利用してLINEクライアントに返し、表示しています。

SHOWROOMログイン

f:id:otto13:20181109002902p:plain

返されたURLからSHOWROOMのOAuth認証に遷移します。
SHOWROOMのログインが成功すると認可コードがBotServerに伝わって、 その認可コードを利用してaccess_tokenを取得し〜というのは一般的なOAuth2.0の認証のフロー通りです。
このOAuth2.0の仕組みをSHOWROOMに作ろうと思ったきっかけは2018年のDeNA TechConでLTさせていただきました。

SHOWROOMのイノベーションを加速させるためのマイクロサービスの取り組み

nonceを生成してLINEプラットフォームにリダイレクトさせる

LINEのドキュメントにしたがって、nonceがkeyで、SHOWROOMのユーザーIDがvalueのペアを保存しています。
ユーザーのすり替えなどを検知できるのがlink_tokenの強みなのだと思います。
ざっくりですが下記のような実装です。

Rails.cache.write("lineAccountLink:#{nonce}", sr_user_id, expires_in: expire_seconds)
redirect_to "https://access.line.me/dialog/bot/accountLink?linkToken=#{link_token}&nonce=#{nonce}

LINEプラットフォームからaccountLinkのWebhookイベントを受信する

LINEプラットフォームにリダイレクトされると、LINEプラットフォームからBotServerにaccountLinkのWebhookイベントが届きます。
このメッセージにはLINEのユーザーIDとBotServerで生成したnonceが含まれます。
nonceからSHOWROOMのユーザーIDを引き出し、そのSHOWROOMユーザーIDとLINEのユーザーIDを紐付けます。

line_user_id = event['source']['type'] == 'user' && event['source']['userId']
nonce = event['link']['result'] == 'ok' && event['link']['nonce']
if (line_user_id && nonce)
  showroom_user_id = Rails.cache.read("lineAccountLink:#{nonce}")
  User.create!(showroom_user_id: showroom_user_id, line_user_id: line_user_id)
  bot_client.link_user_rich_menu(line_user_id, account_linked_rich_menu_id) 
end

f:id:otto13:20181109010240p:plain

この連携の仕組みとは直接関係ないですが、連携完了時にリッチメニューのスイッチも行なっています。
こうすることで、連携後に利用可能となるメニューを表示させることができます。

総括

このアプリですが、はじめは一人で作っていましたが、途中からインターンとしてSHOWROOMで働いているいとう君にも参加してもらって今の状態まで持ってくることができました。 ボットプログラミング、特にLINEのボットプログラミングはクライアントのデザイン面の実装が不要なのに、ユーザービリティを追求する実装ができるのは面白かったです。
いとう君にはリッチメニュー周りの実装をまるっとやってもらいましたが、テキストメッセージのリプライによる動作から、ポストバックメッセージに変更して劇的にそっれぽいアプリになったなという印象です。
最終的に我々のBotServerは一度もHTMLを返さずに今の機能を実現できております。(アカウント連携機能が提供されてないと難しかったと思います)

途中でも述べましたが、本アプリのリリース予定は未定となります。
もしこのアプリに興味をもたれた方はどこかの現場でお声かけ下さい。
下記の現場には出現する予定です。

mirrativ.connpass.com

linedevday.linecorp.com

techcon.dena.com

最後に

SHOWROOMではエンジニアを募集しています。
SHOWROOMの機能やSHOWROOMの持つ情報を使って面白いことをしてみたいと思った人、お待ちしております。

www.wantedly.com

ライブ配信 Meet up 〜メルカリ × SHOWROOM〜で登壇をキメました

SHOWROOM Tech Studioの牧野です

先日、メルカリさんとSHOWROOMの合同イベントが行われました。

mercaridev.connpass.com

参加いただいた方、お疲れ様でした!

テーマは今流行りのライブコマースについてでした!

ざっくり説明すると、生配信中に、商品を購入することができるヤツです!

SHOWROOMのライブコマース機能の「SHOPROOM」ですが、 バックエンド側はScalaを使用して、主に私が開発したので、 そのことについて、登壇させていただきました。

ライブコマース開発秘話

こちらが登壇した際の資料です。

内容としては以下の構成です。

  • SHOWROOMの紹介
  • SHOPROOMの紹介
  • マイクロサービスっぽくなった理由とScala採用理由
  • Akka HTTPを使う上で苦労したこと

当日は80人ほどの方がお越しくださいました。 メルカリさんのオフィスをお借りしてイベントを行ったのですが、めちゃ広々で綺麗でした。

f:id:poisonotter:20181026184104j:plain

また、開始時に弁当と酒が無料で配られていて、最高でしたね。

f:id:poisonotter:20181026185820j:plain

メルカリのジョニーさんの発表内容について、メルカリさんはもともとECなので、どのようにECに対してLIVE機能を開発したのかを発表したのに対して、弊社はもともとLIVEなので、どのようにLIVEに対してECを追加したのかと言う対象的な内容でした。

f:id:poisonotter:20181026190624j:plain

SHOWROOMは稼働してから数年経過しており、どうしても中身にオレオレな部分や、運用のためにその場しのぎで作られたコードなどが発生しており、そのための課題解決の一例としてマイクロサービスっぽいことを行いました。結果、一部疎結合にEC機能を開発できたので、モノリシック脱却の第一歩を踏み出せたのかなと思います。

f:id:poisonotter:20181026190646j:plain

スライドの後には、パネルディスカッションというコーナーがあり、1問1答形式で、各社のLIVE ECについての質問や議論が交わされました。 中でも安室奈美恵さんが、仮にLIVE ECを始めるとしたらどう対策する?というのが好評でした。

石川さん(メルカリ)
「もし安室ちゃんがLIVE配信するとなったらどうする?」

ジョニーさん(メルカリ)
「そうですねえ。。事前に時間がわかってる場合は、対策ができるんですが、もし、アマチュア枠で突然配信を開始したとしたらあらゆるサービスが即死ですね。」

†村上†(SHOWROOM)
「じゃあ安室ちゃん検知システムを作って、検知した場合は各所に緊急警報アラームを鳴らしましょう!!」

ゴジラか!

このような和やかな空気の中でディスカッションしました。

最後に懇親会をやって、来場者同士で語り合って解散しました。

個人的な感想

エンジニアを始めてから5年くらいですが、人生初登壇な上に、このような大きい場での登壇だったので、非常に緊張しました。 ただ、酒という魔法のアイテムがあったので乗り切れました(登壇時には缶ビール二本開けていた) SHOWROOMでは酒が好きなエンジニアを募集しています(違う)

最後に

SHOWROOMではエンジニアを募集しています。BARスペースもあるので、ぜひ一度お酒を飲みに来てください!

www.wantedly.com

Mercari Tech Conf 2018に行ってきました

Mercari Tech Conf 2018に行ってきました

こんにちは。 SHOWROOMエンジニアの齋藤です。

10/4(木)にMercari Tech Conf 2018に行ってきました。
ちょっと時間経ってしまいましたが、感想書きたいと思います。

techconf.mercari.com

ところでアカデミーヒルズ(六本木ヒルズ・森タワー49階)の入り口って
ちょっと分かりにくくないですか?
毎回オフィスエントランスに行って迷子になってる気がします…

今回のTech Confですが印象に残ったテーマが3つあるので
それぞれについてまとめたいと思います。

経営課題をテクノロジーで解決すること

Introduction to the Corporate Solutions Engineering

speakerdeck.com

「経営課題を解決する」ためにテクノロジーを使うCSEという組織、
そのスタンスがすごく好きでセッションを聞いただけでなく、
ブースにもお邪魔させていただきました。

目標設定→達成度合いによる評価が一般的な世の中において
結果や成果ではなく、その人の実力を徹底的に評価するために
文化や制度が作られていて、それを実現するためのシステムを作る、
とても素晴らしいチームとプロダクトだと感じました。

あまりに出来がよかったので「SaaSとして世に出して欲しい」みたいなツイートをしてしまったのですが
セッションの最後にその辺を匂わせることもおっしゃっていたので
いつか来るその時を密かに期待しています。

とはいえあのシステム、メルカリ社の文化や制度に最適化されているので
文化ごと導入しないとうまくハマらないかもしれませんね。

モノリシック->Microservicesへの移行

Mercari API: from Monolithic to Microservices

speakerdeck.com

Listing Service: モノリスからマイクロサービスへ

speakerdeck.com

Web Application as a Microservice

speakerdeck.com

この他にもメルペイのMicroservicec化に関するセッションもあったのですが
満員御礼にて視聴を断念しました…

どのセッションでも試行錯誤しながら
Microservices化を進めていることが伝わって来ました。
ここを突き詰めていくと結局欲しくなるのがAPIGatewayとBFFだと思うのですが
どのプロダクトでもやはりそういう方式になってました。

また、データベースを先に移行するか、システムを先に移行するのかについて
書籍「マイクロサービスアーキテクチャ」では
データベースの移行からやるべき、というスタンスになっているのですが
どのプロダクトも基本的にはシステム(DAOレイヤー)を部分的に移行しつつ、
データベースは後追い方式を取っていて非常に興味深かったです。
書籍とは異なるケースの事例として参考になるのではないかと。

Customer Serviceとエンジニアリング

Customer Experience Improvement

speakerdeck.com

CSAT Score - 極度改善(しなさい) -

speakerdeck.com

個人的に一番いいと思ったのは実はここです。
ユーザーエクスペリエンスとしての顧客体験はどこでも重要視されていますが
長く使ってもらうサービスにおいて最も重要なのは
Customer Support(メルカリ社においてはCustomer Service)
なのではないか、と常々思っていたためです。

特にCSチーム用のツールなどは
実際のカスタマーから見える部分ではないため
どうしても後回しになりがちですが
ここの使い勝手を妥協せずにきちんと作り込むチームがいて、
それをフル活用するチームがいるのは素晴らしいと思います。

さらにはお問い合わせ対応の品質もスコアリングして
改善のサイクルが回るようにしているところも
CSとしての顧客体験に力を入れている何よりの証拠として
非常に感銘を受けました。

終わりに

CSE、Microservices、CS強化。
どれも自分たちもやっていかなければならないキーワードばかりで
非常にいい刺激をもらえた1日でした。
運営の方々、登壇者の方々、貴重な時間をありがとうございました!

僕たちもやれることを1つずつやっていこうと思いますが
あれこれやるにはまだまだ人手が足りていないので
SHOWROOMでは一緒にサービスの改善に取り組んでくれるエンジニアを募集しています!
ご興味ある方はぜひぜひ一度遊びに来てください! www.wantedly.com

Streaming Conference #4 にて登壇しました

こんにちわ。

SHOWROOMエンジニアのシミズです。

先日「Streaming Conference #4」に参加し登壇しましたのでその報告です

streaming-lab.connpass.com

当日の様子はFRESH LIVEでも放送されました。

freshlive.tv

今回はDeNAのオフィスでの開催ということでしたので、 カメラなど一部機材はSHOWROOMの物を提供させていただきました。



speakerdeck.com

"最近"の負荷対策というか、障害報告をさせていただきました。

今回、我々のサービスの事例を紹介しましたが、他のサービスではどうしているのか、どう考えているのかもとても興味ありますので、差し支えなければ是非お話聞かせてください。

懇親会でお話させていただいた皆様、ありがとうございました。貴重な学びでした。


そして、賛否両論あるとは思いましたが、「サーバーはダウンするものなので、ダウンした場合の考慮をするべき」という考えも述べさせていただきました。

当然、ダウンさせないべきです。ダウンさせないように全力を尽くします。

それでも想定外の自体が起きることはありえます。

そんな想定外の時にどう動けるかこそが、エンジニアの腕の見せ所ではないでしょうか。

復旧方法がしっかり確立されているので、サーバーダウンを恐れないということとは決して違うので履き違えないようにだけお願いいたします。

安定化の話をするとどうしても守備的というか、既存の仕組みを変えるのを恐れがちですが、少なくとも我々は新しいことへのチャレンジも実施しています。

その例がCDN配信への取り組みです。

既存の仕組みで安定稼働しているのだから、そのまま進めるだと、既存の仕組みで対応しきれない場面に出くわした時に脆いです。

我々はより強固な安定を求める為に新しい施策にチャレンジする、そのチャレンジでもトラブルが起きないように全力を尽くす。

全力を尽くしてもトラブルが起きてしまうときは起きてしまうので、そんな時でも、冷静、丁寧、正確に対応できる組織を目指したいなと考えています。



Streaming Conference #1, #4と運用の話をさせていただきました。 でも、他の方の技術的な登壇も憧れます。 次は自分も技術的な話をしてみたいです。「xxxxをやってみた!」的な。 みんながあっと驚くすごい内容は難しいかもしれませんが、LT枠なら暖かい目で聞いていただけるのではとハードルは下げさせてください。

13日の金曜日

13日の金曜日ということで、

弊社では、Live Blu-rayの鑑賞会をやりました。

その様子をシミズが簡単にレポートします。

(*本投稿は技術的な話は一切ありません!)

f:id:otto13:20180717174501p:plain

今回は、SHOWROOM以外のエンジニアもお招きしました。

以前から、久しぶりに交流会(飲み会)しましょうとお話をしており、

  • 13日の金曜日ありますね!
  • Blu-ray発売しますね!

っていう絶好の機会だったのでやっちゃいました。

(SHOWROOMの休憩室は勉強会や交流会などに活用できます)

f:id:otto13:20180717175124p:plain

Hey, Hey, Hey, Hey♪

Hey♪

f:id:otto13:20180717175445p:plain

以前ノベルティで配ったサイリウム。
 

再生終了後も、この夏の予定だったり、最近の活動の話だったりしながら親睦を深めました。

お集まりいただいた皆様、ありがとうございましたmm

今回の目的は、

「親睦を深めて、勉強会とかで会った時に気楽に話せる仲間づくり」

だったのですが、ライブ会場で会った時も気楽に話せるような気がします。

次の展開はどうなるの?

良き会だったのでまた別のテーマでやれたらなーなんて思ってます。

  • サッカー観戦
  • ゲーム大会
  • etc...

今回は知り合いづてでの開催でしたがcompassとかでパブリックに募集なんかも検討中です。 (IT界隈の人間のドメイン特化型勉強会という体裁)

いっしょに働きませんか!

SHOWROOMでは現在採用に力を入れており、
一緒にプロダクトを作り上げていく仲間を大募集しています!
興味が湧いた方は一度遊びに来てください! www.wantedly.com

SHOWROOMの新規開発にHyperappを採用した話

こんにちわ、エンジニアのきむらです。現在は主にフロントエンドを担当しています。

今回は、SHOWROOMの新規機能開発にHyperappというJavaScriptフレームワークを採用したので、そのお話をします。

はじめに

SHOWROOMは、ターゲットのプラットフォームをPC / iOS / Androidとしていますが、 iOS / Androidではアプリ内でWebViewコンポーネントを利用しWebページを表示している画面がまだ数多くあります。

既存のページは以下のJavaScriptフレームワーク / ライブラリを使用しています。

数年前に流行ったBackbone.jsからなるクライアントサイドMVCを構成するためのモジュール群です。 ですが、今の世の中の流れは完全に仮想DOM一色、SHOWROOMもこの流れに乗り より機能の変更に柔軟に耐えうる、低コストかつ高速描画の可能なフレームワークを採用することにしました。

f:id:hkmn:20180707121817p:plain:w256 < 乗るしかない このビッグウェーブに!

仮想DOMとは

仮想DOMは、VirtualDOM、VirtualNode、VDOM、VNodeなどとも呼ばれます。 もうすでに数年前から仮想DOMに関しての記事は山程出ているため、いまさらこの記事で紹介するまでもないのですが

ものすごく簡単にご説明すると

「ブラウザ自体が画面の変更に対して行っていた処理を、JavaScriptで肩代わりすることで高速にレンダリングする技術」

です。

ブラウザは画面の構成要素をDOMという単位で管理しますが、これをJavaScriptで「仮想のオブジェクト」として管理することで ブラウザ内で行われているDOMを直接操作することをせず、モデルとビューのデータバインディングを行うことができます。

仮想DOMを採用しているライブラリ

有名なものとして以下が挙げられます。

f:id:hkmn:20180710194228p:plain:w128

React.js(Facebook社製ライブラリ https://reactjs.org/

f:id:hkmn:20180710193746p:plain:w128

Vue.js(Google社のEvan Youさん個人が開発したライブラリ https://jp.vuejs.org/index.html

今回の開発で採用するにあたって

ここで一旦SHOWROOM自体の機能について一度ご説明すると、大きく分けて以下の2つで成り立っています。

  • 配信を視聴するための画面(様々な画面要素が存在し、通信が頻繁に発生する)
  • それ以外の画面(簡単な設定変更のみを行うページや検索や記事的なページ)

今回新規で開発する画面は、後者であったため、複雑な処理は行う必要がありませんでした(実際に開発した画面の詳細は後述)。

そのため以下の点から、上記2つのライブラリは今回の開発には利用しないことにしました。

  • 要件を満たすにはすこしオーバースペックである(機能は充実しているが、そこまで利用しない)

  • 学習コストが高い(ライブラリ独自のお作法、周辺ライブラリの選定等、導入にあたって学習・検討しなくてはいけない内容が多い)

  • 一度採用すると、そのライブラリを剥がしにくい(がっつりフレームワークに依存した処理が多ければ多いほど、書き換えコストも増大)

Hyperappについて

f:id:hkmn:20180710194336j:plain:w128

Hyperappは、JorgeBucaran(https://github.com/jorgebucaran)さんが開発している仮想DOMを実現しているライブラリです。

https://github.com/hyperapp/hyperapp

昨年末にIncrements社が運営するプログラマーコミュニティ「Qiita」において、ReactからHyperappに置き換えたことで話題になりました。 JorgeBucaranさんは、Qiitaの中のひと(2018年現在)で、独自に開発していたHyperappをオープン化しています。

今回、Hyperappを採用したのは以下の理由からです。

  • ライブラリ自体がとても軽量
  • 学習コストが低い
  • ビューの管理にJSXをサポートしている

ライブラリ自体がとても軽量

ライブラリは1ファイルのみ、行数も400行未満、とてもシンプルな実装で軽量です。 自分で1からコードを読むのも全く苦ではないレベル、仮想DOMの考え方や実装を学ぶにもとてもよいライブラリだと思います。

学習コストが低い

先に述べた通りReactやVueは、学習・検討しなくてはいけない内容が多いのですが、Hyperappはこのライブラリ固有の考え方がとても少ないため導入が容易で、プロジェクトにあとから参加するメンバーがいても学習コストを低く抑えられます。

ビューの管理にJSXをサポートしている

同様にJSXをサポートしているReactに仮に置き換える必要がでたり、今後Reactで開発する必要がでてきて場合でも 書き換えが容易であり、モジュールの共有がしやすいと考えました。

(JSXについて:https://facebook.github.io/jsx/

以上から、Hyperappを今回採用しました。 Hyperappの利点は、QiitaにJorgeBucaranさんが記事をあげていますのでそちらも参照するとさらにわかりやすいかと思います。

Hyperappのアーキテクチャ

Hyperappは以下の3つのモジュールで構成されています。

State

プレーンなJavaScriptオブジェクトであり、アプリケーション全体の状態を管理します。

Actions

Stateを更新するための処理群を管理します。このオブジェクト配下にある処理のみがStateを更新できます。

View

仮想DOMを実現します。ActionsによってStateが更新されるたびにViewが再描画される仕組みになっています。

以上がHyperapp独自の考え方のすべてなので、学習コストはとても低いといえます。

実際の開発について

ここからは、実際に開発した画面について、どんな構成にしたのか、どんなところでハマったのか、等を共有できればよいなと思っています。

(コストが低いのにハマったのかよ、というツッコミはまあ初期導入は得てしてそんなものだということでご理解ください。。。)

開発した画面

SHOWROOMは、ユーザの分身をアバターで表現しています。 仮想ライブ空間では、配信画面上にアバターがたくさん表示されており、いわゆる「ライブ感」を演出しています。

ユーザはアバターを頻繁に着替える機会があるのですが、着替えるための画面が使いにくいという声がユーザさんから多数上がっており、 この画面をより使いやすいように改修することになりました。

機能は以下の通りです。

  • アバターのリストをページ送りで確認できるようにした。
  • 条件で絞り込みできるようにした(使用した履歴 /「お気に入り」)。
  • アバターを「お気に入り」設定し、管理できるようにした。

画面イメージ:PC

f:id:hkmn:20180708005259p:plain:w512

画面イメージ:アプリ

f:id:hkmn:20180708001945p:plain:w256

実際の画面はログインが必要です。

(PCの場合)

https://www.showroom-live.com/

左メニューより、ログイン -> マイプロフィールアイコン -> アバター着替えはこちらバナーをクリック

(アプリの場合)

‎「SHOWROOM-ライブ配信ならショールーム」をApp Storeで

play.google.com

左メニューより、ログイン -> マイページ -> 編集 -> アバター着替えはこちらバナーをクリック

または、

配信画面で画面下自分のアバターをクリック -> アバター着替えはこちらバナーをクリック

ぜひ使ってみてください!

開発環境

以下のような構成にしました。

JavaScriptライブラリ

  • Hyperapp 1x(アプリケーション全体の管理)

  • Hyperapp router(ルーティングの管理、今回はページ送りで使用)

  • axios(非同期処理)

開発言語

Flowでもよいのですが、現状TSをサポートしているライブラリのほうが多いのでこちらを採用。

  • JSX(TSX)

スタイルライブラリ

Showroom独自のコンポネントとテーマを適用しています。

タスクランナー

(既存の画面もwebpack 4を使っています)

ディレクトリ構成

.
├── dev
│   └── pages (webpack-dev-serverのrouting)
├── src
│   ├── api (非同期処理まわり)
│   ├── components (共通コンポーネント)
│   ├── ext (外部ライブラリ)
│   ├── icon (SVGアイコン用tsx)
│   ├── img (静的画像)
│   ├── pages (ページ固有の処理)
│   │   └── UserAvatar
│   │       ├── actions
│   │       ├── components
│   │       ├── icon
│   │       ├── img
│   │       ├── index.tsx
│   │       ├── state
│   │       └── utils
│   ├── typings (TypeScript型定義ファイル)
│   └── utils
├── tsconfig.json
└── webpack.config.js

開発する上でのルール

以下のようなルールを最低限のコーディング規約としました。

  • Actionsの命名規則

とくにHyperappによらない話で、Fluxを使った場合でも決めたほうが複数人の開発がスムーズになります。

今回Actionsの命名規則を、

「誰が」「どこを」「何をしたか」

で定義するようにしています。 具体例は以下のような感じです。

// ユーザ操作
// ユーザが、アバター画像を、クリックした
userAvatarImageClicked: (id: number) => (state: State) => ActionResult<State>

// システム
// システムが、Appコンポーネントを、起動した
systemAppLaunched: () => (state: State, actions: Actions) => ActionResult<State>

ハマった点

以下のようなところでハマりました。。。

非同期処理まわり

「ActionsによってStateが更新されるたびにViewが再描画される仕組み」というアーキテクチャにおいて、ActionsがStateを更新し反映するタイミングは、「Actionsで定義される関数の戻り値がStateを返却したとき」です。

公式にちゃんと書いてはあるのですが、横着して読み飛ばすとだめな典型。。。

https://github.com/hyperapp/hyperapp#asynchronous-actions

ルーティングまわり

後々簡単なSPAもできるように検証も兼ねて導入したHyperapp routerは、ライブラリが絶賛更新されているタイミングだったため、使い方がよくわからなかったり、TS型定義ファイルが公式になかったりしてなかなかビルドが通らないという羽目に。。。

また、ie11をサポートするために、polyfillを使用しています。 (Hyperapp routerでは内部で、CustomEventが使われています。)

TypeScriptまわり

いきなりTSまで導入するのがそもそもいけない説あります。。。 が、せっかくなので新規環境で早く導入したほうが、途中で導入するより楽です。

ハマりポイントはやはり型定義ファイルが見つからなかったり、サーバのテンプレートから渡されるデータとのやりとり、ネイティブオブジェクトをどうするか、等です。

今回すべてのファイルでTSを導入したのですが、そもそも「型の恩恵を得たいファイルのみに限定する」という割り切りが必要だと思います。

開発コミュニテイ

Hyperappは、公式のSlackコミュニティが活発なので、ハマった場合思い切ってそこで質問をなげてみるのも手です。

https://hyperappjs.herokuapp.com/

JorgeBucaranさんが、頻繁に発信したりするので最新の情報はこちらを見ていると追えます。 基本は英語のコミュニティですが、日本語のチャンネルも用意してあって、JorgeBucaranさんが日本語で答えてくれたりします。

その節はありがとうございました!mm

まとめ

まだあまり日本でのHyperappプロダクト導入事例は見たことがないため、チャレンジの意味も込めて導入してみましたが、一度導入してしまえばかなり楽に開発していける印象を持ちました。

ライブラリがかなりシンプルなため、もしハマったとしても解決のために内部を読むのはかなり楽にできそうです。

また、コミュニティが活発なライブラリは、更新速度も速いですが、より良い機能追加やサポートも受けやすいメリットもあります。

少し前の技術書典4でついに書籍がでていました。

イヌでもわかるHyperapp - 犬テトラ+ - BOOTH

この記事で、Hyperappに少しでも興味を持たれた方がいれば、ぜひ試しに導入してみてください!

小規模、中規模の機能改修にはかなり向いているのではないかと思います。

いっしょに働きませんか!

SHOWROOMでは、一緒にプロダクトを作り上げていく仲間を絶賛大募集中です。

自分たちが楽しく働ける仕組み、ユーザさんに良いと思ってもらえる機能をボトムアップでどんどん作り上げていける会社ですが、まだまだ人が足りません!

今回のようなチャレンジも、許容される組織です。

興味が湧いた方は一度ぜひ遊びに来てください! www.wantedly.com