読者です 読者をやめる 読者になる 読者になる

Microservice Meetup #5 参加ブログ2(Webサービスの初期開発とマイクロサービス・BFF)

前回の記事に引き続き、Microservice meetupの参加ブログになります。
microservices-meetup.connpass.com


前回の記事はこちらです
takahiro-fujii.hatenablog.com

発表項目

APIのことはすべてシーマンが教えてくれた。」 by @charlier_shoe さん

www.slideshare.net


「step by step BFF」 by @yosuke_furukawa さん
speakerdeck.com


Webサービスの初期開発とマイクロサービス・BFF」 by @shimpeiws さん
speakerdeck.com


Railsで作るBFFの功罪」 by @shotat_jp さん
engineer.recruit-lifestyle.co.jp

をベースにした話

Webサービスの初期開発とマイクロサービス・BFF

今回は、
株式会社アカツキ(Akatsuki Inc.) の@shimpeiws さんによる発表についてのまとめになります。

こちらも、"step by step BFF"と同じくSPA,BFFに関連するプレゼンテーションですが、

新規のアプリーケーション開発を通じて発生した課題と解決法、
これからのアクションを通じて、どのようにBFFを使おうと考えているかということが、
非常に分かりやすく説明されていました。
特に、これからSPA+Microserviceな構成で新規でアプリを作ることを検討されている方は見ておくと良いスライドだと思います。

発表は、大きく分けて、
1 - 要件とアーキテクチャ
2 - 開発初期での選択と集中と課題
3 - BFFのプロトタイプの実装
という三部構成でした。特に2を経て、どういう経緯でBFFを導入しようと思ったかという点が勉強になります。

1 - 要件とアーキテクチャ

要件
  • 今回はWEBからスタートするアプリだったそうです。(なんのアプリなんだろう、、)

後からネイティブアプリが出る可能性が高いとのこと

  • インタラクションが多いUI(ほんとにこれとSPAは相性いい)
  • 長期的な運用になる見込み(保守性とスケーラビリティ)
アーキテクチャ

Front-End

  • SPA(Single Page Application)

Server Side

Infrastructure

  • GCP
  • Kubernates

実際の構成も紹介されていました。(8~9スライド目)
一般的なSPA + API構成といった感じです。

2 - 開発初期での選択と集中と課題

まだまだ絶賛開発中な感じなのかもしれない。と話を聞いて思った。
短期間で結構色々変わっているな、という印象も。
このような組織のサイズと期間で、開発を進めているらしい。

立ち上げ期(2Month) 開発初期(4Month) 開発中期(これから)
チーム 1チーム(4名) 1チーム(5名) 4チーム
開発内容 - 開発フロー整備
- QA/Production環境構築
- 基本機能一通り
- アイテムタイプの追加
- 口コミの実装
- 全文検索
- バグ・負債を若干返済
- グロースハック施策
- 基盤となる機能の開発
- インフラ・ミドルウェア・デプロイの整備
ハイライト - アーキテクチャ・設計指針決定
- 開発ボリュームを抑えきれず混乱
- アーキテクチャに大きく手は入れてない
- スクラム開発の運用を手探り
- チームの分割
- マイクロサービス化の推進
- 中長期的な運用の開始
  • 開発中期に入っていきなり4チームになるとか結構ドラスティック。
  • 開発初期と呼んでいるフェーズで、ある程度なのかもしれないですが、きちんとバグ・負債を返している
  • 組織が別れたタイミングと、マイクロサービス化のタイミングが重なる

そして、この後のスライドが結構衝撃的だったんですが、

- Ruby(15,000行)
- React(60,000行!!!)
- JavaScript(25,000行)

上のスライドの期間をみても半年弱なので、期間に対してかなりのコード量だな、とは思いました。
とにかくガンガンコード書いた感じが伝わって来ますね。

初期の設計思想としては、

  • SPA + SSRすること
  • シンプルなAPIな設計

の2点に重きをおいているようでした。
ブレイクダウンしています。

SPA + SSRすること

なぜやったか?

  • 複雑なインタラクションとイニシャルビューの表示を早くしたい
  • -> SPA + SSR
  • -> React + Redux構成にした

Pros

  • ダイナミックなWebフロントエンドを作りやすい
  • SPAできる(ルーティング、State管理)

Cons

  • 開発工数が一時的にあがる
  • Node.js分が入って、開発全体でのデプロイ、管理コストが増えた
シンプルなAPI設計にすること

開発の初期段階では、API設計はとにかくシンプルにすることを意識、優先したということです。

具体的には、APIはRESTにしたそう。

  • ドメイン設計にかける時間を十分にとれないから一旦ある程度諦めたという話が考えさせられました。ドメイン設計は諦めたけど、RESTFulにはする、という点が特に。どれ位RESTなのか、という点が気になります。
  • 画面にべったりそったAPIで保守性をさげたくない(特定のアプリ用のAPIたくさん作りたくない)

ドメインは考えないものの、APIはRESTで作るから、ある程度リソースの粒度や認識が定義されていたということでしょうか。
いずれにしても、初期のレビューでチーム内の意識統一を進めて行ったという点が非常に共感できました。これがしっかり出来ないと、スケールしたりチーム分けた瞬間に崩れ去ります。。

Pros

  • SpecificなAPIは作られなかった(特定のプロダクト、機能に用途に限定されたような)
  • 設計・実装が楽でバグも少なかった(いいね)

Cons

  • フロントエンドが辛くなった(!!!)

"何が辛い?"
1.APIを呼ぶ回数が増える
オーケストレーション層がない状態でREST APIが増えると(設計次第な所はあると思いますが)ある操作をするのに、たくさんAPIを呼ばないといけないケースがあります。

2.APIを呼ぶのに、順番の依存が発生することがある
※これは、一概にRESTでAPIを作ったことだけが原因ではないと思いますが

APIを呼ぶのに依存が増えると、そのAPIの使い方が分かりにくくなるし、
リリースに結構厳しい依存ができて、結果的にRESTであるにも関わらず修正しにくくなる(フロントとの依存が結構強かったりして)とかもあります。

スライドでも

  • 6並列でAPIを呼んだ後で直接でAPIを2つ呼ぶ

という例が紹介されていました。(きっと実際にあるんだろうな、、)

これらの問題を"アーキテクチャ的な観点"で解決する為に、BFFを導入する流れになっているようです。

開発初期振り返り

3 - BFFのプロトタイプの実装

これからBFFを実装していく、というフェーズのよう。

  • I/Fは画面に必要なものをまとめて返す
  • レスポンス遅いのはダメ
  • フロントエンドと密結合するので、更新頻度は高い
    • フロントエンド側の人間が気軽に触れる方が良い
プロトタイプ
  • 一覧に商品と商品についたコメントを表示する
  • ログイン済のユーザのみ見れる(認証)

という例でBFFのプロトタイプの実装が紹介されていました。
基本的には、開発初期にシンプルなAPIを設計したことでフロントエンドが辛くなっていた部分を、BFFが引き受けているという印象です。

所感

  • SPAとしては割とベーシックで、SPAじゃないアプリでBFFやMicroserviceとやりとりする場合でも、共通して話せる話題が多かった気しました。
  • 新規でアプリケーションを作る際の流れにそって話が進んで行ったので、

直面されていた課題がイメージしやすく、自分だったらどうするのかな
ということを考えながら話を聞くことができました。

  • BFFをリアーキテクトとして使っている点は、前回のブログとも同じなのかなと。

ProxyとしてBFFを差し込む、という感じは、たとえ最初からSPA+Microserviceの構成で作ったとしても同じ、という印象を受けました
最初に裏をRestで作るところがうまく行ってるのか気になる、バックエンド側のリファクタリングとか今今発生しているのかとか

Microservice Meetup #5 参加ブログ1(step by step BFF)

Inside FrontEndに引き続き、ブログ書く枠で参加させて頂きました。
今回で5回目となるMicroservice meetupですが、中々都合がつかず、
個人としては今回が初めての参加になります。

microservices-meetup.connpass.com

発表項目

APIのことはすべてシーマンが教えてくれた。」 by @charlier_shoe さん

www.slideshare.net


「step by step BFF」 by @yosuke_furukawa さん
speakerdeck.com


Webサービスの初期開発とマイクロサービス・BFF」 by @shimpeiws さん
speakerdeck.com


Railsで作るBFFの功罪」 by @shotat_jp さん
engineer.recruit-lifestyle.co.jp

をベースにした話

step by step BFF

個人的には一番今構成について議論している環境に近く、参考になるセッションでした。
まずはこちらのセッションについてまとめます。

日本Node.jsユーザグループ代表,RecruitTechのFurukawaさんのお話

1 BFFとは

  • フロントエンドとバックエンドを明確に分ける、マイクロサービスを意識するためのもの
  • 皆さんがよく引用する、SamNewmanの記事も紹介

Sam Newman - Backends For Frontends

  • ドメインに特化したサービスとリッチなクライアントを繋ぐ調停役
    • 画面を作るための補佐
    • API Aggregation

2 BFFが担う役割

このパートが聞けたのよかった。

1 API Aggregation

Aggregation : 集約する、集合体、集合させる

ここは特に異論ないところだと思います。
非同期で複数のMicroserviceをCallし、フロントエンドが必要な形に整えて返す
という役割です。

2 Session Management

API Gatewayの観点からすれば、これも自然な役割だと思います。
セッションを元にtokenを取得して、tokenを利用して各APIにアクセスする部分をBFFでやります。

3 (Server Side) Rendering

これは、SPA(Single Page Application)が関連してきますね。
これをはっきりBFFの役割に入れてるのは面白かったです。

4 File Upload

これまた面白い話。
ファイルアップロードする機能そのものは、BFFに実装したという話。
これは同じような悩みをした経験が・・・。

・ファイルをアップロードする行為そのものはRestと相性が悪い
・BFFでAWSのS3みたいな所にファイルアップロードは済ませて、
そのfilepathをrequestに入れてファイルを管理するrestful apiにリクエストする
みたいなことをおっしゃっていたと思います。

5 WebSocket / LongPolling / SSE(Server Sent Events)

WebSocket / Long Polling / SSEも、BFF経由で行う。
Message QueとのやりとりもBFFが直接行う。

Cache

具体例の紹介があったわけではないですが、スライドには
CacheもBFFでやるとbackend-friendlyという話がありました。
色々な場所でキャッシュし始めるとヤバいので、同意

3 BFFが生まれた背景

Previous BFF pattern

  • 1990 ~ : 3tier Client-Server System
  • 1990 - 2000 : Monolitic Architecture
  • 2010 : Single Page Application
  • 2013 - ? : Single Page Application with Microservices
  • クライアント側にロジックがよりがち
  • フロントエンドはUIに集中したい
  • ということを考えるとBFFが必要

という流れだった。

  • BFFをNode.jsにするとFrontEnd(SPA)と作業を共通化できる

という話があったので、こんな疑問を思いました。


で、ここら辺で発言したことをパネルディスカッションの時に(恐らく)拾って頂いて、
確認したところ、やっぱりBFFはフロントエンド側で管理しているらしい。

4 BFFの利用事例(Twitter,Netflix,RecruitTech)

1 Twitter

何かと話題になったこの件笑


Mobile TwitterがNodeでアクセスを受け始めた。ということです。

29スライド目にあるような構成だと、まさにSPA+BFF(Node,Express,React)で構成されている感じみたいです。
Mobile Twitterというのはこっちのことですね。

https://mobile.twitter.com/home

2 Netflix

Microserviceの話になると大抵Netflixの話が上がります。ブログを読むと僕らが今直面してる課題が、
数年前のブログのっていたりして辛くなることがありうます笑

3 RecruitTech
  • BFFをNode.jsで構築
  • 上にあるような使い方をしている

例としてブッキングテーブルというサービスの構成が紹介されていました。
ブッキングテーブルではネイティブアプリとWEBでBFFを分けているみたいです。

bookingtable.jp


あとは、raicoというサービスも紹介されていました。(見つけられなかった

5 どのようなタイミングでBFFを導入する/しないのか

するとき
  • フロントエンドとバックエンドで開発者を分業して、疎結合にしたいとき
  • レガシーなシステムがすでに存在しており、段階的にリアーキテクトしたい
  • ユースケース上必要になる場合
しないとき
  • フルスタックエンジニアが多いとき
  • Monolithcに開発して最速でサービス出したい時
  • ユースケース上必要ない場合

6 どのように段階的にBFFを導入するか(Step by step BFF)

  • BFFをProxyとして構築する
  • 最初はレンダリングするところだけ
  • だんだんと内部の処理を置き換えていく

所感

  • まず、しっかりと実例が聞けたとき点において大変参考になった
  • Backend側の話はそんなに無かったが、綺麗なRestfulにする為にBFFが色々やってる(ファイルアップロードとか、websocketとか)というのもありそう。(フロントの為だけじゃなくて
  • そこが調停するっていう表現なのかな
  • エラーメッセージのハンドリングとか、聞けばよかった
  • このセッションに限ったことではないけど、BFFがAPI Gatwayを包含している感じだった

多国籍で多趣向なみんなと楽しく飲み会をするために

f:id:takahiro-f:20170303204152j:plain

まとめ

  • レンタルスペース×ケータリングを利用してコストを抑えた
  • レンタルスペース×ケータリングだと、直前に人数が変わっても割りと大丈夫!
  • 池尻セレクトハウスオシャレ!みどりえ、ドミノピザ、カクヤス最高!

難しさ

まず、多国籍、他趣向なみんなと飲み会をするのは、
何が難しいのか?という点について、僕なりに感じていることを。

食べられるものが違う

これは想像がつくと思いますが、
いろんな国の方と働いて改めて感じるのは、
日本の人は本当に割となんでも食べるな、ということです。
なんでも食べられるが故に、僕らはあまり困らないです。
それが故に、割と軽視しがちな所もあります。

どんなものが食べられない?

まずは、宗教的な理由で一部ないし、全てのお肉が食べられない人は割といます。

ベジタリアンの人もいます。また、ベジタリアンの中でもさらにビーガンの方や、
もう少し厳しい制約がある方もいます。

http://veganic.co.jp/veganism/

  • 牛肉×
  • 豚肉×
  • 肉全般×
  • 生肉×
  • 乳製品(チーズとか)×
  • etc..

あとは、宗教上の理由ではないけども、もともとの食生活で食べて来なかったものは、
あまり好きではない割合が多いと思います。

例えば、生肉を食べる習慣が無い所では生肉/ホルモンを敬遠する人はそれなりにいますし、
生魚を食べる習慣が無かった人の中では刺身/寿司があまり好きで無い人もいます。
卵がダメな人とかもいます。

食べられるものと食べたいものは違う!

さらに気をつけなければならないのは、食べられるものと食べたいものは違う、ということです。
最大公約数でみんなが食べられるものを選んでいると、必然的に行くタイプのお店が限定されます。

  • 牛肉、豚肉×の場合 -> 鶏肉系(焼き鳥など)
  • 肉全般× -> インド系料理屋(カレーなど),オーガニックレストラン等

東京は肉がダメな場合の対応パターンが相当限られる、、というのはあると思います。
そうすると、やっぱり飽きて来たりするんですよね。
「食べられるんだけど、それが食べたいわけじゃない!」
ってなると、段々と飲み会の参加者が減って行くこともあります。
あとは、日本人の感覚だとカレーとお酒とかあんまりイメージないかも。

また、本人の趣向として野菜があまり好きでは無い(野菜より肉!)、という人は結構いるので、
ベジタリアン向けのレストランもそういう点において大人数の飲み会には合わないことがあります。
オーガニックのレストランは、ややコストが高くなることが多いとも思います。(仕方ないのですが)
普段使いができる、安価なベジタリアン、ビーガン対応のレストランが増えるといいなって思います。
(現状はそういう趣向の割合が多いお店がそうなのかな(インド料理屋、メキシコ料理屋とか))

飲み会にかかるお金

飲み会にかけるお金の感覚も国によって違います。
これを気にしすぎるのは正直厳しいかなと思う(国には国の物価がある)ので、
必要以上に考慮する必要はないと思っていますが、

  • コストが原因で飲み会に参加しないという選択をする人がいる

ということを知っておいてもいいと思います。
「あの子、あんまり飲み会こないな」という人の中には、
そういう場が嫌いなだけではなく、
コストの面が原因となっていることもあるということです。

コース料理、飲み放題、予約の難しさ、飲み会の位置付け

飲み会に対する考え方の差、も色々とあるように思います。
幹事をやっている当初は、かなりこれに悩まされました笑

例えば、飲み会をコースで予約します。
とすると、大抵の場合、みんなに
「キャンセルの場合は開催2日前までに連絡をお願いします」
的な連絡をすることになります。

僕の感覚では、日本人だけで飲み会をするよりも直前キャンセル率があがります。
体調不良などであれば、まぁあることではありますが、
例えば、

  • 受け取りたい宅配物が今日来ることになった
  • 他に予定ができた
  • とにかく行けなくなった(!)

とか、一見そこらへん上手くやってよ!笑と思うような理由もあったります。
でも、そういうもんなのかもな、と思うところもあります。

コース料理でガチガチにキャンセルポリシーが確定するようなパターンは、
カジュアルなお店だと海外ではあまりないのかもしれません。
どっちかっていうと、飲める時に行ける人でみんなで飲みに行こうよ!
みたいな感じの方がしっくりくるんだろうなー

  • じゃあ、コース料理にしなければいいじゃん

は一理あります。が、少し注意することもあります。

コース料理と飲み放題
  • それは、飲み放題にするのにコース料理が必須となる

場合です。
お酒を飲む飲まないも、かなり個人差があります。
日本よりよく飲む人が多いようなイメージがある、欧米や、韓国の方とか
逆にインドや中国は比較的少ないイメージがあります。(あくまで平均として)
で、日本のお店の場合、飲み放題にしないと予算が見えなくなる怖さがあります。
飲み放題にしないほうが安くなるケースも多々あるのですが、そうでは無いケースもありますし、

  • 気づかずにいいお酒とか頼んでて会計の値段あがっちゃう

みたいなパターンもあります。
そういった理由から、飲み放題にしたいなーって思うことはあります。
そうすると、コース料理が必須です、というお店はわりとあります。
結果、キャンセルのコントロールが難しくなります。
(結果としてキャンセル料が発生したら、直前にキャンセルした方からキャンセル料は頂いてもちろんいいとは思うのですが)

多少融通を利かすケースとしては、事前に、直前キャンセルが発生した場合、

  • 飲み放題の料金だけ減らしてもらえるか

を確認しておくといいです。大抵の場合、キャンセル料が発生するのは食材の準備に影響される所が大きいので、料理は当初予定していた人数のままでも、飲み放題の人数だけ調整してくれる、というお店はあります。それで、1人あたりの料金を若干あげれば調整できるので、そういった方法もあります。
(限界ありますが)

予約の難しさ、飲み会の位置付け(人数の変動)

料理のメニューに関わらず、直前の人数の変動は難しいです。
直前で減るケースもありますが、直前で増えるケースもあったりします。
(やっぱり今日行きたい的な)

お店のタイプによりますが、ある程度の規模になってくると、
直前の人数の変更が、お店にとって迷惑になったり、そもそも不可の場合もあります。
全然仕方が無いことなんですが、比較的直前で参加人数が変動しがちなので、
難しいなと思うことがあります。

とまぁ、こんな感じで結構悩みはつきないわけです。笑

そこで今回の飲み会どうしたか

本題です笑

そこで、今回の飲み会をどうやってみたかということです。

  • 1.レストランを予約せずにレンタルスペースを借りた
  • 2.ケータリングでベジタリアン対応のメニューを頼んだ
  • 3.ドミノピザでピザいっぱい頼んだ!
  • 4.カクヤスでお酒,ソフトドリンク(+お菓子)も持って来てもらった(Webで注文)

です。割と普通ですかね笑

レンタルスペース×ケータリング

難しさの一部を解決するべく、レストランの予約ではなくレンタルスペースにしました。
レンタルスペースはスペースマーケット | 会議室から球場までレンタルスペースを簡単予約で予約しました!
今までも小規模のイベントなどで利用したことはありましたが、20,30人規模の飲み会で使うのは初めてでした。

今回は、池尻セレクトハウスさんを利用させていただきました!めちゃおしゃれ!

池尻セレクトハウス
spacemarket.com

f:id:takahiro-f:20170303181109j:plain

f:id:takahiro-f:20170303181120j:plain

f:id:takahiro-f:20170303181541j:plain

自分なりに感じたレンタルスペースの良い点、考慮点は下記です。

  • 良い点
    • 会場の規模の範囲内での人数の変動の影響が少ない
    • 1人1人の参加、不参加のキャンポリない
    • 立食パーティに近い感じで、気軽に席を変えたり、移動したりできる

f:id:takahiro-f:20170303185756j:plain

  • 良い点(池尻セレクトハウス)
    • アットホームで、落ち着ける
    • 許容できる人数の幅が広い
    • 立地、値段
    • オプションでゴミの廃棄をお願いできる
    • 人数に応じたレイアウトをしてくれる
    • 花見できる
  • 考慮点
    • あんまりどんちゃん騒ぎはできない
    • あまり遅い時間まではできない(今回借りた場所は21:00まで)

ケータリングでベジタリアン用のメニューとピザ頼んだ

今回は、参加するメンバーの中にビーガンの方が何人かいる予定でしたので、
この方法を選びました。
ビーガンの方でも食べられるものを頼みつつ、その他の人も満足できるものを用意したい。
という思いがあって、今回レンタルスペース×ケータリング形式にしました。

ただ、ベジタリアン・ビーガン対応のものを探すのにはちょっと苦労しました。
特に、値段の面が難しいです。東京にあるビーガン対応のお店は、
素材にこだわっているお店が多く、素敵なお店はあるのですが、反面価格も高く、
こういった飲み会で利用するにはやや敷居が高いという印象です。
人数が増えればもう少し選択肢が増えるかな、、というところです。
(ただ、僕の調べが足りない所も多々あるので、もしおすすめのお店があれば是非教えて頂きたいです)

今回は、みどりえ(Midorie)さんのベジタブルメニューからいくつかオーダーさせて頂きました!

オーガニックレストランみどりえの無添加宅配弁当・ケータリング|東京
ベジタリアン/マクロビオティック/ヴィーガンメニュー/宅配弁当・ケータリング 東京

  • 今回開催する場所(池尻セレクトハウス)から比較的近く、配送料無料の敷居が低かった
  • 最低発注金額の敷居が低かった(10,000円以上)
  • 美味しそう笑
  • 量がしっかりめ

最低発注金額は今回肝でした。
最低発注金額が50,000円とすると、20人の参加で1人あたり2,500円が抑えられてしまいます。
そうすると、今回の人数だとどうしても他のメニューを他のお店で頼む、ということがやりづらくなります。(予算を出来るだけ抑えたい、というのもあったので)
また、料理が足りないっていうことにならないようにするのが本当に毎回苦心する所なので、この点も嬉しい所です。

さらに、ドミノピザでピザを頼みました。
ピザは具材でいろんな人の要望を割と柔軟に対応できると思います。
今回は金曜日開催だったのですが、奇跡的にミステリーディールで

  • MYSTERY DEAL ピザ2枚で50%OFF

f:id:takahiro-f:20170305210603p:plain
一番欲しいやつを引き当てました笑
これはちょっと運要素が強すぎますが、使えない場合は直接受け取りにいくか、他のクーポンを探したりで、ある程度は安くできると思います。
今回はピザ7枚頼んで、-12,663円。アツすぎる・・・

プレーンピザからチーズを抜く + ウルトラクリスピー

あと、今回は頼んだピザも一工夫しました。

  • プレーンピザからチーズを抜いてウルトラクリスピーにして、原材料から乳製品を抜く

というテクニック。
プレーンピザはトマトソースとチーズだけの状態なんですが、
さらにそこからチーズを抜くことができます。

f:id:takahiro-f:20170305210537p:plain

f:id:takahiro-f:20170305210549p:plain

f:id:takahiro-f:20170305210528p:plain

これではれて乳製品をカットできた、、、と思って原材料を見たのですが、
まだ乳製品が入っています。

f:id:takahiro-f:20170305210519p:plain

確認したところ、生地に入ってるとのこと。確かにそうか、、
ただ、"ウルトラクリスピー"には使ってないとのこと。

ということで、ウルトラクリスピーを抜くことで、原材料から乳製品も抜くことができました!
あとは野菜をトッピングすることで、ベジ対応出来ました!

f:id:takahiro-f:20170305210509p:plain
f:id:takahiro-f:20170305210503p:plain

f:id:takahiro-f:20170305214224p:plain

※ただ、注意点なんですが、厳密に制作過程において混入しないことを保証しているわけではないようです。ここでいう▽に該当するものだと思います。(但し、このページにはプレーンピザからチーズを抜いた場合のものは書いてないですが)
www.dominos.jp


ビーガンの方でも、こういったことにどれほど神経質かは差があると思います。
ので、事前に説明して大丈夫かどうか聞いておくのがいいです。

追伸
そもそも美味しいのか?それ。って声を結構頂いて不安だったんですが、
食べてみてびっくり。
美味しい・・・!!
チーズ入ってない分、さっぱり食べられるし。
全然ありってことがわかりました。
これは大きな収穫…!!

飲み物はカクヤスで

お酒はカクヤスで頼みました。
当日発注でも配達してくれるフットワークの軽さが最高です。
ケータリングだと、飲み物代はかなり安く抑えられます。
どれくらい飲むかにもよりますが、今回は一人平均600~700円くらいですみました。
www.kakuyasu.co.jp


今回気をつけたこと

  • レンタルルームなので、部屋汚したくない
  • 赤ワインはこぼされるの怖いので、コスパ悪いけど200m位の小さい瓶のやつを少しだけ頼んで、瓶もってもらう形式に。(出来るだけグラスとか紙コップに注がない)
  • ソフトドリンクも出来るだけ500mlのペットボトルにして、2Lは水とお茶だけにしました

やってみて

今回かかったお金

  • レンタルスペース代 : 約18,000円
  • 食事代(ピザ) : 約13,000円
  • 食事代(ベジ) : 約17,000円
  • 飲み物代 : 約14,000円

合計、約62000円
参加者、約20名なので、だいたい一人あたり"3000円弱"の計算になります。
安い…!!

詳細

ピザ
みどりえ

商品名:天然酵母・フムスのベジタリアンサンド(10人分)

  • 数量:4個

商品名:テンペときのこのステーキ マスタード醤油ソース(10人分)

  • 数量:1個

商品名:ジェノベーゼ有機ポテト豆乳マヨサラダ(10人分)

  • 数量:1個
カクヤス

ビールはもうちょっと多めにすべきでした…

  • 商品名:ニッカ シードル・スイート 200ML
    • 数量:2本
  • 商品名:カルピス ウォーター 500ML
    • 数量:3本
  • 商品名:キリン 氷結グリーンアップル 350ml缶 350ML
    • 数量:3缶
  • 商品名:割り箸元禄 20膳 20ゼン
    • 数量:2個
  • 商品名:サンライズ カベルネS / コンチャ・イ・トロ (ベビー)スクリューキャップ 187ML
    • 数量:2本
  • 商品名:サントリー オールフリー 350ML缶 (ノンアルコール) 350ML
    • 数量:1缶
  • 商品名:綾鷹 上煎茶 2L 2L
    • 数量:1本
  • 商品名:サンナップ ホワイトプレート (20cm紙皿×10枚入り) 20cm*10マイ
    • 数量:4袋
  • 商品名:サンナップ プラストカップ (215ml×10個入り) 215ML*10コ
    • 数量:6袋
  • 商品名:グリコ ポッキー チョコレート 9袋 9フクロ
    • 数量:2個
  • 商品名:K-Price クリーン・アイス (ロックアイス・氷) 1.1KG
    • 数量:2個
  • 商品名:ゴミ袋 【45L用×10枚】 45L*10マイイリ
    • 数量:1個
  • 商品名:サントリー ほろよい 白ぶどう 350ml缶 350ML
    • 数量:2缶
  • 商品名:サントリー ブラッドオランジーナ PREMIUM 420ML
    • 数量:3本

合計:14,440円

良かったこと

  • 直前で結構な人数の変動があったが、基本的に1人あたりの料金が変動するだけで、かなり気軽に直前キャンセルを受け入れられる、平和な心でいられる笑
  • お酒とピザは当日発注が出来るので、ギリギリまで量の調整ができる
  • レンタルスペースが21:00までだったので、割り切って、かなり早めに開始して、かなり早めに終わった(18:45 - 21:00)のが良かったかも
  • こういう飲み会では、めちゃくちゃ美味しいものを頼むよりも、ある程度の価格で、みんなが満足できる方がいいかと(1次会として)
  • ベジタリアン、ビーガンの方でも食べられるものが全体的に多かったので、彼らには好評。
  • レンタルスペースがオシャレで、和室もあって、外国勢の皆さんは楽しんで頂けたようです。
  • 実は、1次会のあとでたまたま残ってた人たちと2次会に行きました。たまたま日本人だけだったので、ローストビーフ食べました笑。1次会はみんなでやって、少し早めに終わって、趣向の合う人たちで食べたいもの食べる、はいいかもしれません。
  • 普段のコース料理系の飲み会よりは安くなった!

課題

  • コスパの面で、ドミノピザに助けられた感すごい。毎回だと飽きるかも
  • スペースマーケットで予約して管理者の人とやりとりすることとか考えると、まだちょっと海外の人自身が同じような予約をして企画するのは難しい
  • 幹事の負担がまだ普通の飲み会よりちょっと多いかな(慣れればもうちょい楽かな
  • かならず会社の近くに、都合のいいスペースがあるわけではないの、、かも。(結構あるけど)
  • 早く始めて早く終わるという飲み会スタイルが必ずしもできるとは限らない。

せっかくの飲み会、みんなが気持ち良くコミュニケーションできる場になりますように。

InsideFrontEnd 参加レポート2(JsonSchema編)

InsideFrontEnd 参加レポート2(JsonSchema編)

はじめに。

2017/02/25に開催されたInsideFrontEndの参加レポートになります。
本当投稿で2つ目となります。
前回の投稿はこちらの記事を参照下さい。
http://takahiro-fujii.hatenablog.com/entry/2017/02/28/222958

レポート : JSON Schema in Web Frontend

www.slideshare.net

今回はYahooの穴井さんのセッションのレポートをさせていただきます。

お題はJson Schemaの話です。今回、Json Schemaのケーススタディが聞けたのは非常に収穫でした。
Json Schemaの話はあちこちで出ていますが、
実は"実際にこういう風に使っている"というケーススタディの共有は、まだあまりないように感じます。

今回のセッションでは、リッチラボというyahooからスピンアウトした
リッチ広告を提供する企業(リッチラボ)におけるJson Schemaの活用法についてです。

richlab.co.jp

主なトピックについて

Json Schema / Json Hyper Schemaの活用
FrontEndとBackEnd APIの意思疎通
入力フォームについて
(他にもシステム構成についての説明などもありました。)

Json Schema / Json Hyper Schemaの活用について

FroneEnd App <-> BackEnd App 間で、Json Hyper Schemaを活用しているということでした。

Json Hyper Schemaって??

こちらをみて頂くと記載がありますが、
http://json-schema.org/documentation.html

The latest Internet-Draft at the IETF is v5, published 2016-10-13. (Due to a change in authorship the I-D numbering has been reset). The specification is split into three parts, Core, Validation, and Hyper-Schema

Json Schemaの3つある仕様のうちの1つ。Hyperはhyper-mediaのhyperです。

Json

{
	"id" : "b94318c0-cc7f-11e3-9c1a-094jkd00c9a66"
	"name" : "Takahiro Fujii",
	"email" : "hogehoge@***.com"
}

Json Schema Core

{
	"$schema": "http://json-schema.org/draft-04/hyper-schema",
	"type" : "object",
	"difinitions" : {
		"id" : {
			"type" : "string",
			"format": "uuid"
		},
		"name" : {
		 "type" : "string"
		},
		"email" : {
			"type" : "string",
			"format" : "email"
		}
	},
	"properties" : {
		"name" : {
			"$ref" : "#/definitions/name"
		},
		"age" : {
			"$ref" : "#/definitions/age"
		},
		"email" : {
			"$ref" : "#/definitions/email"
		}
	}
}

Json Hyper-SchemaはURIの紐付けの部分の定義が記載されています。
英語で、ぱっと見読むのめんどくさそうな感じですが、そもそもそんなに難しい話ではないので、
一度腰を据えて読んでみるのがいいと思います。
http://json-schema.org/latest/json-schema-hypermedia.html#rfc.section.5

Json Schema Core + Hyper-Schema

{
	"$schema": "http://json-schema.org/draft-04/hyper-schema",
	"type" : "object",
	"difinitions" : { ... },
	"properties" : { ... },
	"links": [{
		"title": "Get User infomation",
		"description": "Get users resource information by id",
		"href": "/users/:id",
		"method": "GET",
		"rel": "self"
	},{
		"title": "Create User infomation",
		"description": "Create users resource",
		"href": "/users",
		"method": "POST",
		"rel": "create",
		"schema": {
			"type": "object",
			"properties": { ... }
		}		
	}]
}

linksの中の各要素については、公式ドキュメントを読んでみてください。
24スライド目を見たらわかると思いますが、
1つ目のオブジェクトがRest apiのgetの仕様にあたる部分、
2つ目がcreateの仕様にあたる部分になります。

このセッションでは、あるアプリのFrontEndとBackEndを作成する際に、
Json Hyper-Schemaを定義し、それを元に、

  • APIドキュメントの自動生成
  • HTTPクライアントの自動生成
  • モックの自動生成

を行い、お互いが(FrontEndとBackEnd)がお違いを気にせずに(疎な関係で)開発を進めることができる。
という実例を紹介されていました。

APIドキュメントの自動生成

APIドキュメントの自動生成(+多分json schemaの作成)
GitHub - interagent/prmd: JSON Schema tools and doc generation for HTTP APIsを使っているそうです。
有名ですね。が、使っていないので、使って見ました笑

 mkdir -p schemata
 prmd init user > schemata/user.json

これで、user resourceのrestful apiのサンプルjson schemaが生成されます。
最初からこれを例にして話をしてもよかったかもしれません。笑


あとはgithubのusageにそって進めていくと、、

markdownを生成

  prmd doc schema.json > schema.md

schema.mdが簡単に作れます。

f:id:takahiro-f:20170302020504p:plain

f:id:takahiro-f:20170302020519p:plain

開いてみると、こんな感じでapiドキュメントが生成されます。
非常に簡単です。

モックの自動生成

モックの生成は、自作のライブラリを使っているようです。

https://github.com/richlab-corp/schema-to-db-json

さっそく、先ほど作ったschema.jsonを食わせてみます。

  # Generate db.json from JSON Hyper-Schema
  schema-to-db-json schema.json > db.json

次のようなdb.jsonが作られました。

tf:tmp fujiitakahiro$ cat db.json
{
  "apps": [
    {
      "created_at": "2017-01-01T00:00:00+09:00",
      "id": "01234567-0123-0123-0123-0123456789ab",
      "name": "ABCDEFGHIJ",
      "updated_at": "2017-01-01T00:00:00+09:00"
    }
  ],
  "users": [
    {
      "created_at": "2017-01-01T00:00:00+09:00",
      "id": "01234567-0123-0123-0123-0123456789ab",
      "name": "ABCDEFGHIJ",
      "updated_at": "2017-01-01T00:00:00+09:00"
    }
  ]
}

次にjson-serverを立ち上げます。

tf:tmp fujiitakahiro$ json-server --watch db.json

  \{^_^}/ hi!

  Loading db.json
  Done

  Resources
  http://localhost:3000/apps
  http://localhost:3000/users

  Home
  http://localhost:3000

  Type s + enter at any time to create a snapshot of the database
  Watching...

mockを返してくれるAPIが立ち上がりました!

f:id:takahiro-f:20170302020459p:plain

簡単。
これでFrontEndはこのmock apiを使って開発が進められますね。

HTTPクライアントの自動生成

golangはherokuが作っているやつを使っているみたいです。
github.com


jsは自作中とのこと。
個人的にはクライアントライブラリはあったら便利かなぁ位なので、いいかなと。
クライアントライブラリの管理はbackend側がやるんでしょうか。
それか、一緒にメンテしていく感じなのかな。小さい規模なら特に問題なさそう。

ということで、簡単にmock apiを立ち上げて開発を進めていることがわかります。
さらに、仕様のドキュメントを作る過程が開発の過程の一部になることで、
プレゼンでもおっしゃってましたが、

仕様と実装がシンクする

というメリットがでてきますね…!いけてる。

FrontEndとBackEnd APIの意思疎通

プレゼンの中で、"合意"という言葉を使われていたのが気になりました。
おそらく、CDCのようなことなのかな、と思いました。
実際にはどのように合意をするのか結構気になります。
(自分に時間がなくあまりここらへんは聞けませんでした、、
(Pull requestのapproveが合意ってことなのかな

CDC
https://martinfowler.com/articles/consumerDrivenContracts.html


pull requestのapproveが合意だとすると、規模が大きくなってきたときに、
修正の妥当性をどのように担保していくのか、というのが気になりました。
お互いがjson schemaを元にテストを書く感じなのかな。
それか、pactやspring cloud contractのような仕組みを使うのか。

pact
techlife.cookpad.com


spring cloud contract
Spring Cloud Contract

入力フォームについて

リッチ広告は設定項目が非常に多く、複雑なフォームが多いらしい。
設定値が複雑だったり、入力値の検証だったり、動的に入力項目が変わったり、、
大変そう・・

react-jsonschema-form

というmozillaが作っているReact Componentを利用しているとのこと
知らなかった。。。

  • validationをjson schemaベースでやってくれる
  • カスタマイズが柔軟

というメリットがあげられていました。
バリデーションがjson schemaでやってくれるのいいし、
あとはreact componentはカスタマイズが本当に大事だと思う。
どんなにバリデーションの所がいけてても、出したいUIに変えられなかったら使えないですし。

react-jsonschema-formはここで試せます。
validationはかなりいけているので、どれくらい柔軟にカスタマイズできるのか、
近いうちに試してみようと思います。

react-jsonschema-form playground

まとめ

まずは、Json Schemaを使われている事例を聞けたのが何よりも参考になりました。
早く、課題をクリアして、Json SchemaをFrontEndとBackEndをつなぐのに使いたいなと思いました。
また、質問したところ、Json Schemaを直接BackEnd側のバリデーションで使っていないということでしたが、
ここは是非実現したいところです。
特に、自分が今携わっている環境だと、APIのConsumerが複数いることが多かったり、フロントエンド意外にAPIを直接呼ぶような(Gateway API経由とかで)が割とあります。
そうすると、validationを複数の箇所でそれぞれ実装してしまうと、何かのタイミングでvalidationがずれて、後で問題になる、、
みたいなことが起きやすいイメージがあります。

Json Schemaは少なくともFrontEnd / BackEndを疎にして開発を高速化するのに役立ちますが、
それだけではなく、1ResourceのValidationの定義を一箇所にまとめることができれば、特に中規模、大規模の開発においては大きな威力を発揮する、、と思います。(実現するにあたっての課題はあると思いますが

f:id:takahiro-f:20170302021049j:plain

あとは、更新する場合は穴井さんもおっしゃってましたが、versioningするのが開発のスピード落とさない為にはいい、、と思いますが、
これも同じくおっしゃっていたように、あまり多段でversion管理しまくるのも厳しいので、そういうのを防ぐ仕組みの元でしか出来ない方法なのかな、、とも思います。

schema-to-db-jsonは便利だった!個人的な開発でまずは使ってみたい。

課題があるけど使って見たい、、と思わせるJson Schema。
事例が聴けてよかった。次は自分達の事例が話せるといいな。

InsideFrontEnd 参加レポート1(コンポーネント化って?)

InsideFrontEnd 参加レポート(コンポーネント化って?)

はじめに。

2017/02/25に開催されたInsideFrontEndの参加レポートになります。
今回、このイベントに参加するにあたり、ブロク書く枠、という形で参加してみました。
イベントの参加レポートを書くことは今までもありましたが、
「ブログ書く枠」として参加したのは初めてなので、
ちょっとドキドキしています。

僕はどんな人か

実務でいうと、割とバックエンドないし、
フロントエンドとバックエンドの間に入るような仕事をすることが多いです。
フロントエンドばりばり!な感じでは全くないです。
ただ、フロントエンドの実装をやることもありますし、
シングルページアプリケーション(SPA)を実務で実装したこともありますし、、、
ただ、実務経験としてはバックエンドが多いかなぁ、という感じです

フロントエンド好きなので、個人でwebsiteを作ったり、

takahirofujii.com


仲間内のプロジェクトではフロントエンドやったりします。
比較的個人でしかやっていない分、技術的はまだしも、
実際のフロントエンドエンジニアの皆さんがどのように開発されているか、
という知見に疎いです笑

なので、今回の勉強会は非常に新鮮で、楽しませていただきました。

InsideFrontEndとは?

InsideFrontEnd
http://inside-frontend.com/

Opening Talkにて、InsideFrontEndというイベントがどのように開催される運びになったのか?という簡単な説明がありました。

本イベントは、
Yahoo Japan/Cyber Agent/日本経済新聞社
の三社で合同開催されていますが、
元々、各社それぞれフロントエンド系の勉強会を主催されていたそうです。(もしかして、知ってしかるべきだったのかもしれませんが、、w)

会社 イベント
Yahoo Japan SCRIPTY - イベント一覧 - connpass
CyberAgent Frontrend powered by CyberAgent, Inc.
日本経済新聞社 Frontend Meetup Tokyo - connpass

どのイベントも結構人がたくさん入っています。
個人的にはFrontEnd Meetup Tokyoで昨年開催された"W3C TAG デベロッパー・サミット"がすごく面白そうだなと、、(今更ながら)
今後、これらのイベント開催もきちんと見ておこう、と思いました。

また、個人的には今まで参加してきたカンファレンスで、
あまり日経さんがこういったスポンサーをされている会に参加したことがなく(知らなかっただけ?)、新鮮でした。
ただ、UIやフロントエンドと日経っていう結びつきは、たしかにすごく強いなって。新聞ってフロントエンドそのものだし。(もちろん新聞だけじゃなく、web版はvisual dataなど今では様々なものがありますが)

参加したセッション

結構聴きたいセッションが被っていて悩んだのですが、ひたすらセミナーBのセッションを聞きました。

B1 : Web over ServiceWorker
https://speakerdeck.com/jxck/web-over-serviceworker
B2 : Web フロントエンドにおけるコンポーネント化のアプローチ
https://speakerdeck.com/1000ch/component-of-web-frontend
B3 : Refactoring CSS: 管理されたカオスへの道のり
B4 : データビジュアライゼーションの作り方
http://shimz.me/slide/inside-frontend_1/#/
B5 : JSON Schema in Web Frontend

アメブロ2016: 実録、アメブロフロントリニューアル275日
がかなり面白そうなので、後で資料を読みこもうと思います。

今回、ちゃんと全セッションのレポートを最初からできれば良いのですが、自分の知見の無さや、コードをまず書いてからレポート書きたいものもあり、順次レポートとして公開する形にできれば幸いです。

レポート : Web フロントエンドにおけるコンポーネント化のアプローチ

speakerdeck.com

今回はこちらのセッションのレポートをさせていただきます。
本セッションでは、

コンポーネント化に関連した問題
コンポーネント化をどのように実現・管理するか
協業実践に向けた方針

などについて述べられていました。

個人的には、SPAの開発を経験してから、
コンポーネント化について考えることが多くなりました。
とはいえ、あまりセッションでこういった話を聞きに行ったこともなく、
そういった意味でもこのセッションを非常に楽しみにしていました。

コンポーネントとは

スライドでは、

ソフトウェアにおいては特定の機能、特に再利用性を考えて汎用に開発されたもの

とありました。

コンポーネント化に関連した問題

スタイルガイドについて

少し前まではスタイルガイドが全てを解決してくれる、、というところから始まりました。

実は、恥ずかしながら(HTML+CSSで管理する)スタイルガイドを運用する形で
開発をそもそもやったことが無く、どんな感じなんだろう・・・??というレベルでした笑

スライドの背景になっていた下記のサイトを見てみました。

The Buffer Style Guide
https://buffer.com/style-guide

とっても綺麗にまとまってます。。。
僕はこれがある状態で(僕自身が)フロントエンドの実装ができたら嬉しいです。

発表者の方は、スタイルガイドを利用した開発でまそもそも開発が上手くいったことがないそうです。
「スタイルガイドを利用した開発フローで上手く行っている所ありますか?」
ということを会場内でアンケートした所、若干名の手があがっていました。上手く行っている所もありそうです。

そこで、なぜスタイルガイドを利用した開発が上手くいかなかったのか、という話になります。

The Buffer Style Guideを見たときにも感じたのですが、

組織構成によっては、"このドキュメントが何のためか"というのがぶれるなと思いました。
セッション/スライドでも話がありましたが

デザイナーがHTML+CSSを修正不能なら悪手

というのはその通りだと思います。
このパターンのコンポーネント化をしたいと思うのは、
大体の場合が
エンジニア側が再利用を促進したい
が発端な気がします。しかし、この流れだと、
デザイナーが一緒にコンポーネント化のビジョンを共有する
ことが難しいと感じました。

デザイナーの手の届かない所でスタイルガイドが管理されてしまうというのが
問題です。

  • 開発が修正したスタイルガイドがデザイナーにキャッチアップされない。
  • デザインしたものが全てきちんとスタイルガイドに反映されない

ということが発生すると、メンテナンスされなくなっていき、機能しなくなるなと。

そこで、デザインファイルで管理するという話があがっていました。
そうすると、デザイナーが継続してメンテナンスできると。
デザインファイルをコンポーネントの用に管理して(Photoshopの外部ファイル参照?)デザインファイルをコンポーネント管理できたら非常に素敵だな、とは思いました。

綺麗にデザインファイルを管理してもらうメリット、
それがコンポーネント化に繋がっていくというビジョンをデザイナーの方と共有できるといいなと感じました。

クライアントサイド実装の溝

ここでは、デザイナーはページ全体から設計して、
エンジニアはコンポーネントから開発していくことが多いという話がありました。確かに、そういったケースが自然で、
また、それによってデザイナー側にコンポーネント化のメリットが伝わりにくいんじゃないかなとも思いました。

コンポーネント化をどのように実現・管理するか

プラットフォーム毎のコンポーネントを成す技術

ここでは、具体的にHTML+CSSコンポーネント化を行う際の話がありました。

  • "HTML+CSSだけスコープがない。"
  • "CSSはスコープがなく脆く壊れやすい言語"

これは誰もが感じたであろうHTML+CSSの辛さですね。。
ここでは、その対策として最近スタンダードになってきている(?)
CSS Modules, CSS in JS,ShadowDOMが紹介されていました。
CSS Modulesは使ったことがありますが、CSS in JSは使ったことがないので、試してみようと思います。
CSS ModulesとCSS in JSの比較は結構いろんなところでされているようです。

e.g)
http://morishitter.hatenablog.com/entry/2015/09/28/103334
http://postd.cc/modular-css-with-react/
http://blog.kubosho.com/entry/css-in-js

CSS Modules
https://github.com/css-modules/css-modules

import styles from "./style.css";
// import { className } from "./style.css";

element.innerHTML = '<div class="' + styles.className + '">';

webpackでコンパイルする際に、一意で衝突しないクラス名が生成され、styleも当たります。
実装上はそれを意識する必要がありません。

sample site
https://css-modules.github.io/webpack-demo/

CSS in JS
https://github.com/MicheleBertoli/css-in-js

var style = {
  sample: { backgroundColor: "#fff" }
}

var Sample = React.createClass({
  render() { return <div style={style.sample}>HOGE</div>; }
});

こちらは、よりcssjavascriptの一部の属性として扱っている感じがあります。
ただし、CSS in JS自体はアプローチであり、特にSPAを作る上で使えるライブラリはめちゃくちゃ沢山あるので、それにもよるかも、、。

Shadow DOM
@tonkotsuboy_comさんが共有されていたこちらの記事が分かり易かったです。(が2回以降が見たくなってしまいました。。笑)

実装例に関しては、@kei_n_n_iekさんが共有されていた記事が大変わかりやすかったです。

こういった技術の登場により、スコープが無く苦労していた
HTML,CSSにも概ね、コンポーネントを意識した実装方法が可能になってきました。

協業実践に向けた方針

あまりこういった話も直接セッションで来たことがなかったので新鮮でした。
(よく議論されていることだとは思うのですが、、)

ここで記載されていた内容で、自分が一番共感できた部分は、

  • 一方通行な開発にならないこと

これにつきます。
コンポーネント化にしても、スタイルガイドにしても課題解決の一つの手段であるはずなので、課題がきちんと共有できていないと、
小さいサイト規模からのコンポーネントや、デザインファイルのコンポーネント型の管理は非常に難しいのではないでしょうか。

まず大切になってくるのは

  • パーツを再利用することのメリット(一貫性や、開発速度の向上)の共有
  • コンポーネント化をしたいと思う人が、裏で思っている課題の共有
    • 毎回似通ったボタンをいちいち実装しないといけない
    • 一貫性がなく、文言変更や、特定のデザイン変更があった場合の修正がすごく大変
    • パーツの使い回しができないことによって、開発速度が落ちていると感じる
    • デザインをする際に細かいパーツの設計に毎回時間をとられ、全体のディレクションやUX設計に時間がとれない
    • デザイナー毎にデザインのばらつきが出すぎて、一貫性が弱い

個人的にはメリットの共有よりも、課題の共有の方が共通認識を持ちやすいと思います。

セッションを受けて

自分ならコンポーネント化したい?/どういう風にコンポーネントの管理をしたい?
  • 継続的な開発/運用が求められるサイト・システムにおいてコンポーネント化は必要
  • スタイルガイドは、デザイナーはデザインガイドで管理し、開発側が開発側の管理の為にスタイルガイドを用意※

これはシングルページでアプリを実装する場合がイメージしやすく、

Pivotal Styleguide
http://styleguide.cfapps.io/

のような、UI componentを開発側で管理するようなイメージ

  • デザインガイドと、スタイルガイドの一貫性を保つために、どのような仕組みやフローでコミュニケーションするかは考えないといけないと思います。。

f:id:takahiro-f:20170228222754j:plain

という疑問。

全体のコンポーネント化とweb componentについて

HTML+CSSコンポーネント化に関していえば、
かなり実装よりの話であり、webでコンポーネント化を実現する一つの手段だと思います。
セッションでも、iosandroidの話がありましたが、
それらは現状特殊な方法をとらない限りHTML+CSSで管理されることはありません。

サービス全体の要素のコンポーネント化と、
HTML+CSSコンポーネント化は一旦切り分けで考えるべきだとは思います。
サービス全体の要素のコンポーネント化ありきでHTML+CSSコンポーネント化の話があるのが理想かな。

所感
  • コンポーネント化について非常に考えさせられた。
  • 組織や体制によって、コンポーネント化の適切な実現方法は異なるんだろうなって思った
  • スライドわかりやすい…!!さすがフロントエンド系カンファレンス
  • 手法だけではなく、なぜ問題になるのかという説明が非常に丁寧で良かった
  • サービス全体の要素のコンポーネント化を実現するには、まだまだ解決しないといけないことがたくさん。

zenhack 2016 fallで僕らはどのように開発を進めたかその2

こういうのは続きを早く書くのが大切ということで、第二回目の記事を書かせていただきます。
2回目は、振り返りを書かせて頂きます。

良かったこと・良くなかったこと・次はこうしたいの3部構成でお届けします。

良かったこと

機能の役割分担できたよ

f:id:takahiro-f:20161004195805p:plain
前回のarchitectureにある通り、
FrontEnd/API/Engine(写真集めと解析)という3つのアプリに分けたことと、
最初にAPIが何をどこまでやるかということを明確しました。
具体的にやったことは、

  • likeを付けた写真の(登録、参照、更新)
  • 現在地の近くにある写真のリストの取得

とそれぞれのインタフェースを定義だけではありますが。
これは、短時間の開発でもやはり有効だということを再認識しました。
このおかげで、FrontEndをやっていた僕らがそんなにAPIがやってることに口を出さずに(笑)、

  • それぞれの間でどういったデータのやりとりをするか

ということだけを気にして、黙々と開発出来ました。
「ここ、どうする?」みたいな数が極力減ったことは
今回のhackathonのような短時間の開発でもスピードアップに繋がるとおもいました。

人の役割分担できたよ

元々は、僕の役割はそこまではブレてないんですが、こんな感じのイメージで、
そうとう野望ある役割分担をしようとしていました笑

  • taka66 - Design + Front-end
  • sideroad - API + Front-End
  • nab - Front-End
  • kojiro - スマホアプリ
  • okame - IoT

ありとあらゆるデバイスで何か作ろうと、、笑
でも始まってすぐ時間が足りないってことに気づかされ、あっさり諦めて役割を考え直したことは良かったと思います。
今回のhackathonでどうであったかはさておき、

  • taka66(僕) / Design,HTML,CSS,JS(モックアップ) + プレゼン資料作成
  • sideroad / FrontEnd(SinglePageApplication(React.js)) + interaction animation(js) + Infra(Heroku)
  • nab / API
  • kojiro / API + Infra(AWS)
  • okame / Photo search Engine

短い時間の中でプロダクトをどのように完成こと
ということはものすごく大切だと思っていて。
時間の中で動くものを作る為にこの役割分担に行き着いたのは良かったと思っています。
Done is better than perfect..

機能を削ること

実装を初めて比較的早期に、いくつかの機能を最初の実装から外すことを決めました。
例えば、現在地の近く意外の場所から検索する機能と、カテゴリに分けてそこから検索する機能などです。
最小限でコンセプトを伝えられる機能を実装して、残り時間があれば拡張しよう。
というポリシーでいきました。分かってはいるものの、考えているとあれやりたくない?
みたいなことによくなるので、hackathonではお互いにいい案配で指摘しあえることも大切だと思います。
ただ、削っている間にコンセプトを見失って、実装しやすい機能だけ実装する
ということはもちろん望ましいことではありません。
ので、機能を削る時は、自分たちが作るもののコンセプトに必要最小限であるかどうかで
優先度を考えるのがいいと思います。

自分たちが作ったものを気に入ること

これは結果論も半分です。
感覚的な話ですが、これはおよそ上手く行っているバロメーターとしては比較的正確だと考えています。
時間が無い中で、作るプロダクトは不完全なところもあります。
それでも、作っているサービスを好きでいられることは、みんながそのアプリに可能性を感じて入れていて、
コンセプトにある程度納得がいってるということにもなると思います。
個人的にはロゴとかアプリ名とかがあると愛着がますので、合間の時間を使ってなんとかロゴを作りました笑

良くなかったこと・考えること

目的・テーマへの理解と先入観

こちらは特に個人的な振り返りになりますが、
正直、
お題:「観光」
ここだけ見てたなーってのはあると思います。禅ハックのサイトをみて、申し込んでた時に考えたことは、
観光に役立つアプリを作るってこと。
そこだけ見ていて、
・協賛の鎌倉市さんの観光に関連した資料のデータの使い方、理解が不十分だった。
・後は、禅をより深く絡める、禅の考えを活かすこと。
やっぱりhackathonにはテーマがあって、そこには主催者が解決したい課題があります。
そこへの解決の道筋を見せられることは、大切なことだったなと。

誰の為のものか

ここもお題に付随するところなんですが、

  • > 観光に役立つアプリを作ること。

を考えると、まず最初に浮かぶのは観光客にとって役に立つもの
っていう発想になると思うんです。これ自体は間違っていないと思います。
ただし、もちろん観光を受け入れている側の方々もいて。
今回のhackathonは、受け入れることに携わっている方も多くいました。
基本的にはユーザはやっぱり観光客ですし(もちろん作るアプリによりますが)、
その場合、彼らに使ってもらえないことには、何もないというのはあります。
ただ、彼らに使ってもらうことで、受け入れる側の課題がどのように解決されていくか。
そこはもっとしっかりプレゼンなどで伝えるべきでした。

申請が必要なAPI

ってまぁまぁあるじゃないですか。事前に申請しとけって話でうね。
使う可能性を感じるものは。

自分の武器を探す

良くなかったってより考えてることですが。
hackathonとかに行くと思うことが多いです。
自分が一番輝けるのはどの領域なのかと。
これは役割分担を明確にすればするほど出てきますが。
今回のメンバーだったら自分はフロントとかデザインだし、
逆にそういう人がたくさんさんいればバックエンドのapi開発やったとも思う。
流動的に動けることはいいことももちろん多いけど。。
間を繋ぐことも大事だけど、やっぱり役割分けるとスペシャリティ大事になってくる。
技術を生かしたデザインみたいなのをもっとできるようになりたい。

SPAの為のマークアップ作成

SPAを実装していると、コンポーネント毎にcss閉じ込めたくなる時はよくあると思います。
その時に、マークアップcssが一つのファイルだと、そこから当て込むのが面倒なんですよね。
段々更新があった時に取り込むのが大変になる。
デザインのモック作った後に、コンポーネントの切り方をFrontEndの人と決めて、cssは全体のものは一個のcssにして、
コンポーネント依存のcssは割り切って一個のファイルで最初からcss作ったほうが、
連携しやすかったなっておもいました。
これはすぐ実践できそうなので、次にこういった機会があるときはそうしようと思いました。

次はこうしたい

  • テーマの理解と、その上で何を作るかっていうのを先入観なしで、考えられているかどうか見つめ直す時間をブレストの完了前に作る・自分がその視点を持つ
  • 事前に関連するAPIは使えるようにしておく(特に申請が必要なもの)
  • もっと、オレオレテンプレートを作り込んで、デザインでも、アプリでもwebでも、最初の一歩を踏み出せる時間を早くする。
  • SPAの為のマークアップを勉強する(次も同じ役割やるかどうかは分からないけど
  • このhackathonはチームで参加してるところは結構少なくて、1人で参加してその場でチーム作ってる方がかなり多かったので、そういう参加の仕方をすると、また違った感想を持つ気もしますし、そういう参加の仕方をしてみたいなって。

って感じかなー。時間かけて振り返ればもっと出てくることはありそうだけど。

おまけ(オリジナルシャツ作り)

今回、hackathonの開催にあたって、
チームの気合をいれる為にTシャツ、ポロシャツ、シャツを突貫で作ってきました。
急にオリジナルグッズを小ロットで作りたい時は、毎回渋谷の
ARTON.CO.LTD
さんにで作ってきました。
ロフトの隣です。プロントの上です。
個人的には何度もお世話になっています。
f:id:takahiro-f:20161008200235j:plain
f:id:takahiro-f:20161008200249j:plain

Illustratorでデザイン作って持って行って、artonでdesignちょっと調整して印刷。
っていうことをちょこちょこやっています。
その場で出来るってのがなんとも素敵ですし、1枚1枚違うデザインで作れたりもしますし。
小ロットで作るには安いし、その場で素材色々選べるし。
印刷の位置スタッフさんと相談できるし。
シャツ1枚、ポロシャツ2枚、tシャツ3枚+みんなそれぞれアイコン入りなんて、ここでやらなかったらかなり面倒
大変おすすめです!

f:id:takahiro-f:20160927211431j:plain
f:id:takahiro-f:20160927211243j:plain
f:id:takahiro-f:20160927212139j:plain

zenhack 2016 fallで僕らはどのように開発を進めたかその1

先日、鎌倉は建長寺で開催された、

禅ハック2016 Fallにメンバーを集めて参加してきました。
www.zenhack.jp

チームkoiki
f:id:takahiro-f:20161004200330j:plain


結果優勝することは出来ませんでした。
しかし、技術的にはかなり様々なブレイクスルーを短時間の内に経験し、
チームとして、アウトプットしたプロダクトに満足することが出来ましたし、達成感もありました。
また、一緒に参加していた別のチームの多くの方々から良い評価を頂けたのも嬉しい点です。

この記事では、
・どのように僕らが作業を分担して開発を進めたのか
・プレゼンではお話出来なかったより具体的なarchitecture
・課題と解決、反省点(これは次回の記事で)
など、まとめていきたいと思います。
※今回はほぼ備忘録的な記事になっています。すみません。

前置き

f:id:takahiro-f:20161004195321j:plain
まず、建長寺でやれるってことを知らなくて汗
お寺でプログラミングだー!って感じなだけだったんですが、
いざ行ってみたら、まずお寺すげー!ってなりました。
歴史、由緒あるお寺の中で、開発に集中できたこの経験は、
禅ハックでしか味わうことが出来ないものだと思います。

僕らがつくったもの

最初に、僕らが作成したプロダクトのデモを紹介します。
今回、「SPOT4U」というWebアプリを作成しました。
f:id:takahiro-f:20161004195657p:plain
f:id:takahiro-f:20161004200031p:plain

このアプリは、今自分の近くにあるスポットの写真が紹介され、

・興味がある、行ってみたい所を右にスワイプ(興味がないものは左)
・一定数見た所で、自分の興味がある場所のリストを表示できる
このリストには、

・自分の現在地からの距離
・スポットの名前(とれる場合)
・現在地からのルートへのリンク

といった情報が表示されます。
(youtubeにあげたものでは、スポットの名前が取れてないんですが、
これはnabがコード直せば再びでるようになるはずです笑)

youtu.be


簡単にいうと、現地で「次どうする…??」みたいなことになった時に使って、
身近にあるいけてるスポットを見つけられるっていうアプリです。

発表時のスライドは、speaker deckにあげていますので、
こちらも興味があればみてみてください。
speakerdeck.com

Zenhackのタイムスケジュール

今回のzenhackのタイムスケジュールは、
Schedule 2016 - ZenHack
にも書かれていますが、このようになっています。

1日目
09:30 建長寺の門の前に集合(北鎌倉駅から徒歩15分) まとまって入場&受付スタート
10:00 オリエンテーション、ルール説明、インプット
11:30 チームビルディングワークショップ
13:00 ランチ
13:45 ハック開始
15:00 おやつ
18:00 夕食&企業プレゼン
19:30 入浴
20:45 就寝準備
21:00 就寝

2日目
03:00 起床
03:20 本堂集合
03:30 座禅
04:10 ハック再開
06:00 朝食(お粥・建長寺提供)
07:00 ハック再開
08:30 おやつ
12:00 ランチ
13:15 ハック終了、会場準備
13:30 発表会
15:00 審査、休憩
15:30 表彰、総括
16:00 集合写真撮影
16:30 終了・解散

この中で、プロダクトを作ることができる時間は下記の通りです。

1日目
11:30~13:00 案出し
13:45~18:00 4.25h

2日目
04:10~06:00 1.83h
07:00~12:00 5.00h
12:30~13:15 0.75h

合計 案出し+約11.83h
今回、僕らは5人で参加したので、実作業時間は60hといった所です。

案出し

事前に各々少しアイデアを考えていたんですが、ブレストが始まって、
結局その場で考えたアイデアをベースにして作りました。
考えたアイデアの中から2案を各々がピックアップして、
それを参加者みんなで見て回って、いいと思ったやつに★をつける、といったことをやりました。
その中で、うちのチームで一番票を集めたのは、
kojiroくんの
・写真を見せた時の「心拍数」を測定して、その写真がいいかどうかを判定し、
興味がありそうな場所、おすすめの場所を教えてくれる
というものでした。

ここから、実際に作るプロダクトを考えようとなった時に、
・「心拍数」はかれるデバイスないやん
・これでやりたいことは、余計な情報を見ずに(写真だけみて)
ユーザが純粋に良いと思う感覚をもとにレコメンドできること
みたいな話になって、SPOT4Uの原型が朧げながら出来たという感じです。

フリックするUIを選択したのは、
心拍数を測る、みたいにユーザにアクションなしで自動で判定することはできないまでも、
より多くの情報をユーザが短時間に興味があるかないか判断できるようにしよう
という所から来ました。

また、最初は探したいスポットを入れて、
その場所の近くを検索するという案もありましたが、
ユースケースを限定して、よりそのアプリを使う目的を明確にしよう
という所と、
UIのステップ数を可能限り減らす
ユーザに情報入力させたくない
という所から、
今いる場所の近くを探すという使い方に限定してまずはアプリを作成することに決めました。

メンバー構成・役割分担

メンバー構成

下記のメンバーで参加しました。
今回、全員エンジニアなのと、僕がデザイン周り好きなこともあって、
自分がデザイナーっぽい立ち位置のロールをしました。
受付でエンジニアですか?デザイナーですか?って聞かれて、
「デザイナーです。」って答えた時に新たな自分になった気がしました笑
個人の仕事ではやってたことは一応あるんですが。

  • taka66(僕) / Design,HTML,CSS,JS(モックアップ) + プレゼン資料作成
  • sideroad / FrontEnd(SinglePageApplication(React.js)) + interaction animation(js) + Infra(Heroku)
  • nab / API
  • kojiro / API + Infra(AWS)
  • okame / Photo search Engine

役割分担

後ほど詳細を書きますが、今回役割分担はかなり上手くいったと思っていて、
上記の作業時間で、誰かの手があいたり、ブロッカーの作業が発生するといったことがほとんどありませんでした。
これは、作業開始時に各プロダクト(FrontEnd/API/Engine)の役割分担を明確にして、きっちり分けたことが良かったと思っています。
結果としてEngine周りの細かいロジックは分かっていない所もあって、近々お互いの実装について説明しあうことが必要だなと思っています笑

アプリケーション構成

上の役割分担からおおよそ構成もつくかもしれませんが、アプリケーションの構成は下記のようになっています。
f:id:takahiro-f:20161004195805p:plain

SPA(フロントエンド)

・フロントは、React使ってシングルページアプリケーションとして作りました。
最終的なアプリの機能・使い方としてはネイティブアプリで作っていいな、という内容でもありましたが、
・時間内にサイトを公開したかったこと
・各人のスキルセット
を考慮して、このような選択をしました。

API(バックエンド)

APIはnab,kojiroの2人がrubyがいいっすってことだったので、rubyでやってもらいました。
アプリをきっちり分担したことで、各プロダクトで各々が得意な構成で作ることができました。
kojiroくんが持っている環境(AWS)があったので、そこにAPIをのせることになりました。

写真を集める

・最後に写真を集めるところですが、ここはみんな知識がそんなに無かったんですが、
ここは万能エンジニア、頼れるもと同期のokameさんの力を借りまして(というか任せて)、実現してもらいました。

Hackathon期間中の成果としては、
1)Flickr,Twitterから位置情報つきの画像を集める
2)FacebookのGraph apiで位置情報からスポットの場所を特定する
ということができるようになりました。

Flickr,Twitter,FacebookAPIなどをリクエスト時にcallするという方法もあったんですが、
できればレコメンドしたいねって話になった時に、
一回それの解析やるためにデータとって解析するところは別で作ろうって話になり、スクレーピングするスクリプトを作ってもらいました。
実は結果としてレコメンド組み切る所までの実装は出来なかったので、ここの実装、仕組みについては、もう考えようもあったなと今は思っています。

IBMのWatsonの中にAlchemyVision apiという機能があって、
画像のカテゴリとスコアを返してくれるAPIがありました。
これも使えたなー、、とあとから。
http://qiita.com/knao124/items/60dc430fc31bf85b0e60#2-2-alchemyvision

InstagramAPIももちろん使いたかったのですが、申請が間に合わず。
こういうAPIセットはhackathon時は事前に用意しておくべきですよね、、(毎回思うんですが笑

ということで

フロント2名
バックエンド2名
エンジン1名
っていう分担です。

PaaS

PaaSは、お互い使い慣れた環境でやってしまおうということで、Heroku,AWS上でそれぞれのアプリを動かしていました。
オリエンテーション時では、スポンサーのIBMさんがBluemixの紹介をされていたので、
次こういった機会があれば使ってみたいな、という話をしていました。

hackathon

さてさて、あとは時系列別にどんな感じでアプリが出来ていったのか
ということをまとめていきたいと思います。
とはいえ、他のロールの進捗を完全に把握しているわけではないので、
近々みんなでもう一度集まってヒアリングしたい気分です笑

コミュニケーションはslackで行っていました。

1st(13:45~18:00 4.25h)

最初の30分〜60分位は
・作るもののイメージを固める話し合い
・アプリの大まかなアーキテクチャ
・役割の確認
をしていました。
その後、各自作業を開始しました。

taka66(僕)

・なんとなくのUIの絵を描いて、話し合い with sideroad
IllustratorでUIデザインを作成(15:30に一度目のデザイン案が完成)
・最初にTOPページを決めちゃってベースのHTML,CSSを作成(16:16に最初のpush)
・その後他のページのHTML,CSSの実装を始める(途中まで)

sideroad

・SPAのベースのプロジェクト作って、herokuにdeployできるようにする(~14:20)
API側のインタフェース要件を考える(~14:40)
・TOPページのHTML,CSSをあてる
・ベースの作り込み

nab + kojiro

APIのベースプロジェクトを作る
・sideroadとAPI要件のすり合わせ
AWS上にRubyのアプリをdeployできるようにする(~15:40)
・画像LikeするAPIの作成(~16:21)
・画像を登録するAPIの作成(~17:29)
・レコメンドAPIの作成(途中まで)

okame

・写真とるのにいいAPI探してAPI仕様の確認をする
twitterから位置情報付きの写真を集めるスクリプトの作成
・スクレーピングしたデータの投入(~17:49)

そのあと、お風呂に入る時間の合間の時間が少しあったので、

taka66

・最後のページのUIがいけてないことに気づいて作り直す(~20:55)
f:id:takahiro-f:20161004195334j:plain
から
f:id:takahiro-f:20161004200031p:plain

nab

facebookapiで座標から場所特定できることに気づく(~20:47)
みたいなことをしていたみたいです。

2nd&3rd(04:10~12:00)

座禅後に始まったハックの時間ですが、禅の効果なのか、、、
04:00-08:00位に、めざましく進捗した感じがありますw
07:00くらいから、mockではなく、実際にデータ使って一通り動かせるようになってきて、
エンジニア勢はみんなテンションが上がってました。
やっぱり、エンジニアにとって、動くものを作り出せたタイミングのこの気持ちは何にも代えがたいです。

taka66(僕)

・バグ修正
・HTML,CSSの改善
・結果表示のHTML,CSSの実装
・Like用のHTML,CSSの実装
・アプリ名とロゴデザインをどうしてもうやりたくて始める笑(~05:15)
・フリックアニメーション用のアイコンの作成
・TOPに表示する為の画像の撮影、動画の撮影+加工
・デモの練習
・プレゼン資料の作成、及びプレゼン内容の作り込み(たしか09:00位からやってました)
結果には結びつかなかったのであれですが笑、
個人的に、これくらいの時間からプレゼン資料の作り込みと、発表内容の整理が出来たのは良かったです。
発表時間が5分と短かったので、その時間の間でデモと発表を終わらせる構成を作っていました。
そのおかげで、最後のプレゼンはデモから初めて、プレゼンの完了まで、時間通りに終わりましたし、
質問対応用のスライドも使えたりして、いろいろ準備が役に立ちました。

sideroad

・フリック用のアニメーションの作成
・結果表示のHTML,CSSの当て込み
・現在地からの距離の表示
・load用アニメーションの作成
・ロゴの反映
・バグ修正

nab + kojiro

Facebookapiで座標からスポット名を取得できりょうにする(~05:16)
Googleのcloud vision apiを試す
・クロスオリジンとかの対応
・cloud vision apiでタグ取れるようにする
・プレゼン用の素材写真撮影被写体(nab)
・バグ修正

okame

・システムの改善
・問題がある写真を取り除く(~05:12)
Flickrからもデータを集めるようにする(~07:13)
Flickrからタグを取れるようにする(~08:56)
・スクレーピング

4th

ここは細かい改善をしてました。
最後までコードpushしてdeployしまくった結果、終了10分前くらいまでアプリ動かなかったっていう笑

とりあえず最後に

振り返りとかもあるんですが、ここまでまとめるのに疲れてしまったので、
こちらは後ほど記事を追加したいと思います!
思い返しても楽しかったなー。体力的には疲れたし、畳の上で作業してたら腰が痛くて、、
(姿勢が悪いから
あとは、slackとか使うとある程度のログが残るので、見返すのに最適ですね。