【Kotlin Developers Meetup】に行ってきました

Kotlin Developers Meetup

https://kotlin.connpass.com/event/90679/

に行ってきたので、そのときのレポート

Creating DSLs in Kotlin

JetBrains社のHadi Hariri氏にKotlinについて講演してもらいました。

ただ、英語での講演だったので、全然聞き取れませんでした。。。


LT

LT1: FSM DSL in Kotlin

資料

https://speakerdeck.com/tomoya0x00/fsm-dsl-in-kotlin

Kotlinでtree探索をしようとした話。

私が不慣れなのと、内容の難易度が高くてついて行けませんでした。。。


LT2: Readable Code in Kotlin

資料

https://speakerdeck.com/kaonash/readable-code-in-kotlin

以下、LTを聴きながらのメモ

 

リーダブルコードの中で

「コードは理解しやすくなければならない」と書かれている。

 

理解しやすいコードは

簡潔なコードというわけではない。

短いコードは一見かっこいいかもしれないが、

理解がしずらい点もある。

 

どうやれば理解しやすいコードがかけるか?

1.  nullableのハンドリング

できるだけ早くスマートキャストをしてあげて、

nullなのかそうでないのかという状態を明示するようにする。

2. 型推論にあまりたよりすぎない。

型推論は便利。

ただ、あまり頼りすぎると、

この変数の型はなんなんだと分からなくなってしまう。

 

変数の型を確かめるために、コードをたくさん追わないと行けない。

だから、型推論できる場所でも型を書くようにしましょう。

ではどんなときに型を書くのか?

変数名で型を推測できるときは書かなくてもよいが、

そうでないときは書いたほうがいい。

 

また、letについてみんながどう思っているのかを知りたい。

letはわかりにくいので

runmapというネーミングに変えてあげたほうが

英語が苦手な見としては、わかりやすい。


LT3: multiplatform kotlin?

資料

https://speakerdeck.com/panini/kotlin-multiplatform

以下、LTを聴きながらのメモ

 

登壇者のPaniniさんはKotlinエンジニアなのだが

React Nativeも最近書いている。

React Nativeの良い点としては、

ファイルをセーブしたら、そのまま実行してくれるので便利。

 

ただ、jsよりもkotlin書きたい。。。。

そんなときに

Kotlin.js

という、kotlinをjsに変換してくれる神と出会った。

 

Kotlin を React Nativeで書くためには、

一行、ライブラリをimportする文を書くだけでできる。便利。

 

Hot Reload

jsはコンパイルされないから、すぐに実行できる。

Kotlinでもできないのかな?と思って調べたら、

gradle continuous build

という神の機能がある。

これを使ったら、ファイルの変化を検知してHot Reloadしてくれる。

コンパイルを挟むので少し時間がかかるけど、早いので良い。


LT4:spring fu on graalVM

以下、LTを聴きながらのメモ

 

登壇者の型は、Kotlin イン アクションとか、あかべこ本を書いた方。

graalVM

というのがある。

jvm言語はもちろん、それ以外の言語もこれの上で走る。

AOT compile

Javaや通常、実行時にバイトコードがマシンコードになるが、

これを使うことで、直接バイナリを得ることができる。

ただ、これはlinuxでしか動かない。

なので、macの上で docker  とか使って動かそう。

spring boot も動かせるよ!

ただ、jarファイルを食わせたら、エラーになってしまう。。。

ここで登場するのが

Spring Fu

kotlinでかけるよ!

これをgradlewで動かすと、もちろん動く。

そして、、、jarファイルを食わせると、、、同じようなエラーになってしまう。。。

告知!

kotolin fes 2018やるよ!

品川でやるよ!みんなきてね!


LT5: create minicraft mod with kotlin

以下、 LTを聴きながらのメモ

(英語でのLTだったので、メモが間違っている部分があるかもです。。)

 

登壇者の方は、Y.A.M の 雑記帳を書いている人。(いつもお世話になってます!!)

mine craft をやっているよ。

登壇者の方の息子さんもmine craftをやっているよ。私のPCでね!笑

mine craft modというものがあるよ

modというのは

オブジェクトのようなもので、

ブロックを追加したり、人のステータスを変更できたりするよ

forgeというもので、modカスタマイズできるよ。

modはInteljとgradleで作れるよ!

そしてjavaを使うんだけど、

今回kotlinでやってみたよ!

今回のゴールは私の息子がmodを作ることだ

ただ、

・子供がタイピングしたりエラーを解消したりいろんなファイルを触ったりするのはとても難しい

・重要なのは、早く、遊びながら作れること

結果として

modは子供がプログラミングに興味を持つのにいいきっかけになった。

そして、早くmodを作ることにも成功した!


Q & A

Hadi Hariri氏に直接質問をできるQ & Aが用意されました。

ただ、質問と回答が英語だったので聞き取れず。。。

英語勉強しよう。

【UIT#3 The “Backends for Frontends” sharing】に行ってきました

UIT#3 The “Backends for Frontends” sharing

https://uit.connpass.com/event/88434/

に行ってきたので、そのときのレポート

「マイクロサービスの思想から捉える、Backends for Frontendsとその類似パターン」 qsona (株式会社FiNC)

資料

以下、講演を聴きながらのメモ

BFFとは」「その位置付けと目的」

backend for frontendという言葉は少し混乱がある。

server for frontendという言葉のほうが実態に近いように思う。

複数のAPIを合成したりする位置付け

UI側でのABテストなどをする

BFFとマイクロサービスの関係性

マイクロサービスとは、協調して動作する、小規模な自律型のサービス

FINCアプリの場合は、各プロダクトが様々な機能を内包している。

機能の11個、それが単体でも事業になりそうなものが

FINCアプリの中にある。

それらを別々のマイクロサービスとして扱っている。

 

様々なクライアントと様々なサーバーがある。

それらを直接組み合わせると、

APIのコール数が増えるなどの問題がある。

 

その解決策として、中間に1つサーバーを挟む。

それを API Gateway として扱っている。

 

このAPI Gateway には独自のロジックは持たせたくない。

ロジックを持つと、マイクロサービスの旨味が減ってしまう。

注意点

バックエンドロジックをAPI Gateway にもりもりしてしまうと

辛くなる。

宣伝

Microservices architectureよろず本というのを書いたので、読んでね!

類似パターン

クライアントとBFF層のやりとりはgRPCにして

BFF層kotlinで書く。

iOS と Android は基本的に同じ構成をしている。

画面遷移など。

デザインによる違いなどの吸収はクライアント側で行う。

gRPCにした理由は

RPCにしたかったから。

レストフルは避けたい。

クライアントの要求に答える形なので、RPCとしたかった。

Kotlinの理由

既にいる Kotlin エンジニアのコストが減る。

並列処理として go や node.js を使おうかという考えもあったが、

コルーチンでギリギリ行けそうなので Kotlin



「FOLIOのBFFと秩序の話」 Quramy (株式会社FOLIO)

以下、講演を聴きながらのメモ

「FOLIOのBFFと秩序の話」 Quramy (株式会社FOLIO)

今日話すこと

FOLIO の BFF の自慢話

こんな失敗したのでみんなしないでねという話。

イントロ:サービス紹介、システム構成

MobileAPP と Web で大きく BFF を分けている。

モバイルアプリの iOS とAndroid へ提供している API は同じもので

デザインによる違いはクライアントで吸収させている。

BFF のお仕事

下流サービスの集約

Web の BFF は SSR(サーバサイドレンダリング)も行なっている

Aパート:良い話(うまくいった自慢話)

まずアーキテクチャはどんなのを採用しているか?

クリーンアーキテクチャ風

なぜこんな風にしているか?

BFF はクライアントやマイクロサービスに挟まれているので

クリーンアーキテクチャが親和性が高いと思ったから。

主な目的は型付け。

Json でやりとりをしていて、 Node.js を採用しているので、

型をつけたかった。

リクエストやレスポンス整形で誤っていればコンパイルエラーになるようにしている。

BFF の思想を決めておく

やるべきこと、やらないことを決めておく。

日付の計算やパースフォーマット、数値項目の加算原産など

チームでこれらのことに合意をとって進めて行くと良い。

Bパート:辛かった話(失敗した話)

Web の BFF と Mobile の BFF は作られた時期が全然違う。

Webのほうが古くて、それでつらかった部分を考慮して Mobile が作られている。

悲劇の紹介

ユーザーがみるダッシュボード的な画面。

ログインした次の画面、マイページ的な。

これが辛い。

薄いコントローラと巨大なロジック層によって

巨大な Json を返す。

React を採用しているので、クライアントで Json を処理する。

辛い部分として、

巨大なロジック層の部分が 1800 行とかある。

また、型も Any にしている。

型がついてないし、巨大なので触りたくない状態。

だが、旧来のMVCの形をしているので、ある意味わかりやすい部分はある。

直近の対処

改修をする際には、なるべく型付けを少しづつしていってリファクタリングをしている。

もう少し先の対応としては、

React コンポーネントが必要な Json を取りに行くという

画面側が必要な部分だけ取りに行く。next.jsのような思想を目指している。

おさらい

秩序をもたらすためには、

  • レイヤを意識しよう
  • ユースケースを意識しよう
  • スキーマ + 型を使おう


「merpay Frontend における BFF」 @1000ch (株式会社メルペイ)

資料

https://docs.google.com/presentation/d/1RY2qCIypDBju2LfVhBfBnBaaVN_SFM_KAz7-WVucl90/edit#slide=id.p

以下、講演を聴きながらのレポート

 

BFF のことを調べていたら

「使う側にとって、良い設計になっているバックエンド」

という文献に当たった。

最初は、API をまとめるための API サーバーという認識だったが、

複数の API サーバーにリクエストして、htmlを生成するサーバーも BFF と呼ぶ。

と、古川さん(Node.js会長の)が言っていた。

backend for frontendsという言葉なので、捉え方によってはなんとでもなりそう。

広義の意味では SSR Server を BFF と行ったり、

API をまとめる APIサーバーを backend for BFF という捉え方もできる。

node.js が API をまとめるようにしたくなかった。

isomorphoic app を動かすようにしたかった。

フロントエンドの人が js を触っているので、

その人たちもメンテナンスができる。

backend for bff がやっていること

API Gatewayとして動作させている。

httpリクエストを gRPC に変化して横流しする。

将来的にはアグリゲーションさせるかもしれない。



「なぜBFFを導入しなかったのか」 Kento Moriwaki (Wantedly, inc)

資料

Bffを導入しなかった理由(僕らにはまだ早かった)

以下、講演を聴きながらのメモ

システム構成

railsの一枚岩だけど Micro Service 化を進めている。

バックエンドとフロントエンドの責務を分けて行きたいと思って、

BFF の登場だ!ということを考えた。

課題

グローバルヘッダーやフッターは全ページ共通

ただ、SSR 化したかったのは、ヘッダーやフッターを除いて中のコンテンツを SSR したかった。

共通パーツ問題を解決するために考えたこと

  1. reactバージョンを作る?
    rails jqueryで2重管理になってしまう
  2. 全部react実装に統一する?
    Angularもいれていたので、Angular と React を2重管理させるのはカオスになりそうだった。

課題:インフラの問題

どうやってデプロイするか?

切り替わりの間で何か障害が起こったときのインパクトがでかすぎる。

また、画面を少しづつ移行させたいという要望もあった。

 

これらの課題を解決するに至らず、BFF は挫折した。

今後は

これらの要件を満たしつつ、最小限の工数で。

BFF は目的じゃなくて手段の一つ。

もともと作っていた Restful API でやってきたこと

model を json に変換するところを共通化していた。

複雑な処理もあるが、小さい Service 単位に切り出していた。

これらのことのように、Controller を薄くしておいたおかげで

さまざまな部分を共通化できた。

今後もし BFF に対応したかったら、

  • 対応する API を叩くように書き換えるだけ
  • BFF で直接 Render することも可能。

まとめ

SSR したいだけなら、BFF は必須じゃない

ただ、BFF のメリットはすごくあるので

1つ1つ疎結合にしていって、一歩ずつやっていこうと思う。



「LINEとBFFの話」 Jun (LINE株式会社)

資料

以下講演を聴きながらのメモ

LINEは、

  • サーバの人が多い
  • サーバは Java, Perl
  • サーバーサイドテンプレート
  • SPA でもindex.htmlはサーバーに置いてある

BFF というものは

フロントエンドとか技術だけの話だけではないと思う。

BFF の導入は慣れているプロセスを破壊するものなのか?

破壊は改善です!というのも、エンジニア以外から「本当に?」と思われてしまう。

BFF というのは、組織と責任が伴う。

 

BFF がなかったら、テンプレートがサーバーにあるため、責任が不明確。

例えば、画面の問題があって、テンプレートはサーバーにあるため

サーバーのエンジニアが見る

からの、「これはテンプレートの問題ですね」

となって、フロントエンドエンジニアが対応する

これは非効率

 

また、「これくらいのテンプレートならサーバーサイドエンジニアでも直せるや」

と思って直すと、フロントエンドエンジニアの人の知らないところで変更が入ってしまってつらい。

BFF があると

問題の切り分けが効率がよい。

サーバーサイドエンジニアはデータを触るだけ

フロントエンドエンジニアの人も、渡ってきたデータを触るのに集中できる。

何か BFF で問題が発生した場合は

インフラの人と責任分担して解決しよう。

SEO/OGP/i18n

のことは、最初から考慮して設計しよう

あとからの対応はほぼ無理になる。

performanceに関わること

BFF を導入しても遅くない。

むしろ早い。

node.js の速さもある。

内部ネットワークでの data fetch をすると rtt 1桁くらいになる。

「BFF しましょうとなったときに気をつけたいこと」

結果的にいいもの作って証明しないといけない。

開発環境を慎重に選びましょう

責任をちゃんと話し合いましょう

計測できるようにしましょう。

 → 数字がないと、何がよくなったのか証明できない。

結論

BFF はいいものだが、それだけじゃ進まないときもある

他の組織と話合おう

責任を分け合って、一部だけがつらくならないようにしよう。

結果的に良いものを作って、みんな幸せになろう。



「BFFアンチパターン」 @yosuke_furukawa

資料

バックエンドとフロントエンドを分けること自体がアンチパターンだという文献もある

そこで書かれていることが、

「どちらにも詳しいという人がいなくなってしまうし、責任の所在が不明確になったりもする。」

 

古川さんが BFF アンチパターンを書いていたときに

だんだん組織アンチパターンになってしまった。

 

BFF はフロントエンドとバックエンドの架け橋。

アンチパターンその1:スパースコミュニケーションのアンチパターン

BFF はアーキテクチャを疎結合にするが、

コミュニケーションまで疎結合になってしまうパターン。

n+1 queryのパターン

マイクロサービスだからといって

API を簡素にしていい訳ではない。

これらのことは、コミュニケーションをとらなかったから起こったこと。

アーキテクチャは疎であったとしても

対等な存在であり、コミュニケーションは密に行おう。

アンチパターンその2:インフラレスポンシビリティ

フロントのために BFF を導入したのに

何か BFF で問題があったとき、その責任をバックエンドに押し付けてしまうという問題

BFF は全員でみるべきものであるので、みんな当事者意識をもつようにしよう。

アンチパターンその3:ビックバンジョイント

フロントとバックエンドを別々で開発しており、

お互いに開発が完了した段階で結合テストをしましょうという段階で

確実に想定外のレスポンスが存在する。

なので、最後の最後で結合してあとは結合テストということができない。

なので、結合テストの部分はスケジュールを長く持たせないといけない。

古川さんたちがやっていることとして、

開発中にモックで作っているものを、

お互いの開発が部分的に終わったら、終わった部分から少しずつ本物にしていくということ。

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得に行ってきました

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得

https://supporterzcolab.com/event/410/

に行ってきたので、そのときのレポート

対象者

  • 現在新規事業の立ち上げに携わっている方
  • これから新規事業にたずさわるかもしれない方
  • (もしくはたずさわりたいと思っている方)
  • ライブラリを書くより、プロダクト開発が好きな方

話すこと

  • 作りすぎて失敗したことの事例紹介
  • つくりすぎないために
  • コアバリュー大事

登壇者の方が作ったサービス

pook

https://s.pook.life/lp/

ランサーズは、オンラインクラウドソーシングの会社だが

pookはオフラインでやることに特化したサービス

 → オフィスで肩を揉んでくれたり

 → 栄養士の方が手作りご飯を届けてくれたり

本題

エンジニアの新規事業への関わり方

そもそも新規事業って?

新規事業とは、既存事業から生かして、新しい経済成果を生み出すこと。

対して、起業というのは0から始めること。

どうやって関わって行くの?

求められること

サービスを作ることが求められる。

実際には、プログラムを書くというよりは、問題を解決すること。

失敗1:作りすぎた。

リリース時に作ったのは、

  • APIの数150本
  • ページは80

ガチガチの仕様をその通りに作ってリリースした。

多いと何が悪いか。

多いとリリースが遅くなる

 → 多すぎたということは、無駄なことを作ってしまった。

  → 使われないコードはただのゴミ。

本当にあった怖い話

 nヶ月書けて作った仕組みをすぐに消した。

 顧客が本当に求めていたものと違った。

どうすれば良かったか?

作らなければよかった

 → しかし作って見ないと分からないこともある。

  → 作る前にそもそも考えることがあるはず。

  • 同じような体験ができるサービスを作って模擬する。
  • ユーザーにもっとヒヤリングする
  • プロトタイプで実験してみる。

反省

  • 作らないで実験できないか考えてみる。
  • 試したい仮説をすぐに実装できないか考える

失敗2:技術選定

エンジニアあるある。

最近イケてる○○という技術を使おうぜ!

 → 既存に縛られないので、使いがち

結果

情報が少なくて死ぬ。

社内で知識が多い人の助けも受けられない。

サービスがあたるか当たらないかという問題の前に

サービスが作れるか作れないかという問題が発生する。

反省

  • 枯れた技術を使うべきだった
  • もっと協力しやすい技術を選定すべきだった。
  • できるかどうか分からないは早めに潰す。

失敗3:仕様が変わる。

どうしてそうなった?

  • 作るべきものがあやふやだった
  • 目的を達成するための機能がもりもり
  • 全部マスト

どうすればよかった?

コアバリューを定めて、やらないことを決める。

コアバリューとは?

ミッションやビジョン実現のために、組織が独自にもつ共通の価値観。

これを選定することで、作らないものを決めることができる。

 → コアバリューはなんですか。どうしても欲しい機能はなんですか。と唱える。

  → そうすることで、議論の着地点も見つかる。

反省

コアバリューを決めて、作らないを決める。


まとめ

新規事業開発に置けるエンジニアの心得

  • 一番大事なことは作らないこと
  • また、そのために、コアバリューを決める。
  • エンジニアとして問題を解決することにコミット

とはいえ、経験がないと分からないことが多いので、経験をたくさんしよう。


Q & A

Q1.

コアバリューを決めることでいらないものが見えてくるということだったが

APIの数など具体的にはどの程度減ったりするか?

A1.

Apiの数は80本になったりした。大体全部合わせて半分くらいになった。

Q2.

やっていくなかで一番コストがかかることは?

A2.

新規事業でいうと、人件費が一番コストになる。

技術でいうと、どこにコストがかかるか?

 → 作って捨てればいいので、キレイに作らないことを考えればよかった。

  → 無駄にキレイにつくることを考えてしまった。

   → 結果、使われないキレイな部分ができてしまった。

なので、キレイに作るっていうところにコストがかかる。

Q3.

新規事業をやる上で、予算をどのくらいに抑えろとかあったか?

A3.

最初はなかったが、途中からなんでこんなに時間かかってんだとかあった。

最初はノリで始まったものだが、どうしてこれこんなに時間かかってるの?とか。

新規事業は黒転するまでに時間がかかる。

 → なので、試算を前もってしておいて(エンジニアどのくらい必要です。どのくらいでリリースできます。どのくらいで黒転しますとか)ロードマップ考えておこう。

Q4.

開発するに置いて、「これ使ったよ」みたいなツールとかあるか?

A4.

プロトタイプを作るツールでいうと、InVisionというツールを作っていた。

https://www.invisionapp.com/

InVisionというのは、web上ピピッと操作してプロトタイプを作れるツール。

逆にコンフルエンスを使ったのは失敗だったと思った。

コンフルエンスはバージョン管理ができたり、キレイに書けたりすることができるツール

別にキレイに書く必要はなかったが、キレイにかけるがために、キレイに描こうという空気ができてしまった。

それよりも、ガンガンアウトプットできるようなツールのほうが良かった。