こうした問題に対してMicro Frontend, DDD, Single-SPA, GraphQL, イベントストーミングといった手法を用いて,ドメインごとに責務の分かれたチームがエンジニアリングに取り組んでいるということが紹介されました。とくにMicro Frontendは,（モノリスなリポジトリにするか議論はあったそうですが）コンポーネントごとにリポジトリも,デプロイメント・パイプラインも,チームも完全に分かれているとのことで興味深かったです。

Micro Frontendについては,以下の記事も参考になりそうです。 martinfowler.com

Discussion: DDD x Microservice

@mackstarさんと@hidenorigotoさんの対談です。

開発組織とビジネスサイドとの役割や関わり方についての話が盛り上がりました。設計としての全体像はアーキテクトが責任を持つそうですが,そういう立場の人は得てして忙しすぎて手が回らなくなってしまって,チームが困ることも実際には起きているそうです。そうした問題に対してワーキンググループを立ち上げて,解決に取り組むという活動を最近はじめたとのこと。

ProductOwnerがBacklogに責任を持つこと,チームの自治(autonomous)を重要視しているなど,AgileProcessが重要という話もありました。

Talk #2: Hypermedia!

@adamculpさんのHypermediaについてのトークです。 APIとホームページを対比しながら,Hypermediaとは何かについての再確認と,HATEOAS ,そしてHALについて紹介がありました。また,HypermediaのリンクについてのPSR-13も紹介されました。PSRですが,言語に関係なくAPI開発者は読むべきという発言が印象的でした。

REST APIのドキュメンテーションが簡単にできるGUIのIDEの紹介もありました。 www.youtube.com

HTTPの純粋主義者(purist)からすると,RESTで苦労する開発者はRESTをちゃんと使っていないかHTTPの原則を理解していない。という言葉は重かったです。

LT #1: Hypermedia Doc

@koriymさんのLTです。

REATにおいてHATEOAS(Hypermedia)と並んでもう一つ重要な「共通理解」を助けるためのドキュメントについてのLTです。 Application State DialogをDot言語で記述して,開発に関わる全てのひと（ProductOwnerやデザイナも含む）との共通理解を構築する方法の紹介がありました。

またダイアグラムと辞書をALPSに沿って記載する例の紹介もありました。 alps.io

2019-11-07

A SCRUM BOOK THE SPIRIT OF THE GAMEを読んでいる

Scrum

6月にCSM受けてスクラム熱が上がっているところに

が発売されたので四苦八苦しながら読んでいる

2019-03-30

「Final Object #1」参加記録

勉強会

3/27に@koriym さんのトークイベント、Final Object＃1に参加してきました。株式会社TRASTA さんで再び開催されました。

今回もTwitterで実況してました。

今回はゲストスピーカーに古賀さんと林さんを迎えての開催でした。

はじめまして！Webアクセシビリティ -サーバーサイドエンジニア編- by @shiori_pk

はじめまして！Webアクセシビリティ -PHPer編- by 古賀詩織 | プロポーザル | PHPerKaigi 2019 - fortee.jp

の素振りを兼ねての登壇です。アクセシビリティを普段から考えているか、会社としてどこまで対応するか方針があるかといった話題が印象的でした。

ショッピングサイトみたいな画像のたくさんあるサイトの場合、
URLしか返さないAPIではスクリーンリーダー向けのalt属性などの情報を伝えられなくなる。
#FinalObject
— 腹周りたぷたぷ@脂肪肝 (@hanahiro_aze) 2019年3月27日

サーバーサイドエンジニアが意識すべき点としてAPIが返す情報にアクセシビリティを意識した情報を含んでいるか、という点は「なるほど」と思いました。また、アクセシビリティというと目の見えないひとなどを意識することが多いですが、インターネット回線が弱い地域の人に向けても考える必要があるという点は、前回のFinalObjectでも話題になったクライアントキャッシュの利用によって解決できるという示唆がありました。

アクセシビリティを高くすることで、これまでリーチできなかった人へサービスを届けることができるようになることは、マーケティング上もプラスに働くという提案もあり、とても参考になる発表でした。

=== 2019/4/1 追記 ===

古賀さんから資料をご提供いただきましたので、追記します。

コガ / excite on Twitter: "3月27日に #FinalObject でおこなったLTの事前トークの資料です！ PHPerKaigiより少しスライドが多いだけですが、こちらも公開しました🙌 https://t.co/FTmnSpUzTP"

FinalObject_1_hello!_a11y_ver_phper from shiori koga

www.slideshare.net

=== 2019/4/1 追記 ===

RESTの力 by @koriym

こちらもPHPerKaigiの素振りを兼ねた発表でした。前回の話に引き続き、「アプリケーション状態」、「キャッシュ」、「自己記述的メッセージ」についてのお話です。

アプリケーション状態

キーワード
リソース状態：リソースの状態。サーバーサイドが持っている情報
アプリケーション状態：アプリケーションが今何を見ているか。サーバーサイドは興味がない状態。
#FinalObject
— 腹周りたぷたぷ@脂肪肝 (@hanahiro_aze) 2019年3月27日

安全な遷移と安全でない遷移：アプリケーション状態からリソースへの操作
サーバーはリソースの状態と次のアクションを情報として返す。
たとえばaタグ（安全な遷移）やformタグ（安全でない遷移）
#FinalObject
— 腹周りたぷたぷ@脂肪肝 (@hanahiro_aze) 2019年3月27日

「アプリケーション状態」と「リソース状態」を「安全な遷移と安全でない遷移」と「アフォーダンス」で繋ぐという点が整理して理解できました。前回の話の後も、この点の理解がイマイチできてなかったのですが、以下のスライドで「なるほど」と腹落ちした感じです。

キャッシュ

前回も話に上がった「E-Tagでの条件付きリクエスト」、「no-cacheとno-store」を中心にキャッシュの設計についてのお話でした。

個人的にはこのスライドがキャッシュ導入の参考になるのでありがたかったです。

自己記述的メッセージ

「メディアタイプの選択」、「schema.orgなどを命名（ボキャブラリー）に使うこと」が中心のお話でした。 htmlかjsonくらいしか使ったことがなかったので、メディアタイプの膨大さには驚きました。また、適切なメディアタイプの選定の参考になるページの紹介もありました。

情報の設計（IA）ですべきことはこういうことなんだなぁと思いました。

資料の全編は↓で公開されていますので、ご参照ください。

speakerdeck.com

事業開発をしてみよう by はやしりょう

ご自身でも事業をされているはやしさんによる、エンジニア目線での事業開発のはじめ方についてのお話でした。「要件定義ができるなら事業開発もできるはず」ということで、エンジニアリングとグロースハックの差分は考えを「コードにする」か「行動する」かの違いとのこと。

個人的には「課題を解決する前に、解決すべき課題を設定するためにモデリングをする」、「ユースケース図->ER図->実装」というプロセスを通じて気づいていないことに気づくことができるというお話が印象的でした。

Extra: REST API (Hypermedia API)開発のための7ステップ by @koriym

RESTful Web APIs9章で紹介されている設計プロセスについての解説がありました。 Todoリストを例に、

クライアントが必要なオブジェクトを書き出して「Semantic Descriptor」を作成する。
それぞれの参照関係を結んで「状態遷移」を書く。
使用されているボキャブラリーをIANAなどに登録されている標準的なものに置き換える
適切なメディアタイプを選定する
独自のボキャブラリーの説明を書く（ALPSやJSON-LD）
実装する
公開する

という手順をさらいました。

以上簡単に当日の感想とレポートでした。

2019-02-21

「Final Object #0」参加記録

勉強会

@koriym さんのトークイベント、Final Objectに参加してきました。株式会社TRASTA さんで開催されました。

主にTwitterで実況してました。 @hgsgtk さんによるイベントの速記録も参考になりますので、併せてご参照ください。なお、聞き逃した箇所は適宜上記ブログと『RESTful Web APIs: Services for a Changing World』(English Edition)から補っています。

~Opening

イベントの招待状にはタイトルと仙厓義梵の『◯△□図』だけが記載されていました。何を話すのか知らされないイベントというのは新鮮で期待を胸に参加しました。

オープニングでは@koriymさんの『◯△□図』の解釈と『指月布袋画賛』の紹介がされました。曰く、円相（満月）が真理を表し、四角は普く拡散されている状態を表す。三角はその中間で不要なもをを削ぎ落とすなど真理に至るまでブラッシュアップされていく様を表しているとのこと。イベントの副題である「Think, "Talk" and Code」が開発者としての真理であるCodeに至るためのTalkに主眼をおいた会であるという提示がされました。

REST

本イベントはRESTの真理に近づくためのトークイベントであることが宣言されます。 2014年のPHPカンファレンス関西での基調講演「全てを結ぶ力」、2015年PHPカンファレンス福岡での基調講演「全てを結ぶ力(2015)」のダイジェストからイベントは始まります。普段使っているRESTについて、我々は本当に理解して使っているのか、「Nobody Understands REST or HTTP」とも言われるように、RESTを理解するのは難しい状態にあるというテーマが設定されます。

『メディア論』でおなじみのマクルーハンが「誰が水を発見したかは知らないが、それが魚でないことだけは確かだ」という言葉の紹介もありました。

Roy T.Fieldingによって展開されたREST論文をそのまま読むのは難しいので、『RESTful Web APIs: Services for a Changing World』(English Edition)の「Appendix C. An API Designer’s Guide to the Fielding Dissertation」を手がかりに理解をしていくという方針が示されます。

HyperMedia Style Web API

WebAPIの種類はいくつかあることが紹介され、今回のテーマであるRESTはRoy T. Fieldingが記すようにハイパーメディアスタイルに分類されることが紹介されます。

トンネリング: SOAP
オブジェクト: URIスタイル/CRUD
ハイパーメディア: REST
クエリスタイル: GraphQL
イベントドリブン: メッセージ指向 -- リチャードさん来日イベント参照

Webアーキテクチャの4つの重要な特性

Roy T.Fieldingが論文の第4章で重要視しているWebを成功に導いたの4つの特性が紹介されます

低い参入障壁

FTPやTelnetなどのコマンドラインツールと異なり、Webブラウザはマニュアル不要で操作できる。テキストエディタでオーサリング可能で、設置（デプロイ）も簡単にできる。

拡張性

サービスが変わり続けることができる例えば、ファミコンのカセットは一度デプロイしてしまうとそれっきりなので、拡張性がないと言える。 GAFAのような帝国もHTTP,URI,HTML,Javascriptによってユーザーに合わせて変化し続けてきた。

分散ハイパーメディア

クライアントには情報がなく、表現（プレゼンテーション）や制御情報はリモートにある。

制御情報がクライアントにある例は、テレビなどのリモコン。Webではformタグの中にPOSTする情報は全て書いてある。スマホもUIの表現の中に何ができるかが仕込まれているといえる。

データ（プレゼンテーションと制御情報）によってできることの指示を受け取る。それをデータ自体と同じように扱う。

例えば<a>タグ。レスポンスデータの中にリンクという形で制御情報が含まれている。

安全な遷移と安全でない遷移

安全な遷移：リンクによるリソース間の遷移（GETメソッド）安全でない遷移：リソースの状態を変更するような操作の提供（POST,PUT,DELETEメソッド）リソースの状態はシステム側がダイナミックに変更可能である。

クライアントを壊さずにサーバーの動作を変えられる

URIを変更せずに変えられないなら拡張性がないといえる。今日のWebAPIが犯しがち。

インターネット規模

無秩序なスケーラビリティ

全体を理解してなくても他のサービスが壊れない。クライアントはサーバーのことを意識し続けなくて良いし、サーバーはリクエスト間の状態を保ち続けなくて良い。

独立した配備

自分が新しいページを追加することでWeb全体を破壊するようなことがなく、独立している。マイクロサービスのイメージ

APIはWebではない

APIはWebに似ているが、意思決定に人間が介在しないAPIにはセマンティックギャップがある。人間が読める文章で記述すれば（分散ハイパーメディアの特性を捨てれば）セマンティックギャップは無くなるが、拡張性、スケーラビリティを失う。

4つ全ての特性を網羅したWebAPIを構築するのは難しく、必要に応じて取捨選択する必要が出てくる。

例えば - 「インターネット規模」を捨てて、「低い参入障壁」「分散ハイパーメディア」以外の「拡張性」を選択する -- 全てのクライアントを一斉に更新できる、社内APIの場合はいいかもしれない。 - 「インターネット規模」,「低い参入障壁」を選択し、「拡張性」と「分散ハイパーメデイア」特性を捨てる -- 今日のWebAPIは大抵ここを選択している、

フィールディング制約（9の制約）

HTTPは仕様。RESTは制約。

4つのインターフェースの制約

リソースの識別

URI=リソースのID リソース状態が変更されてもURIに変更は発生しない。単一のURIに多くのリソースが含まれるのは良くない。レストランサイトの例 - 営業時間、メニュー、場所は全て別々のリソースで持つべき。 - サイトの右下に地図があるよというのは人間に向けた説明であって、コンピュータには認識できない。

表現によるリソース操作

表現可能なものはなんでもリソースといえる。 - ペットボトルそれ自体は送れないが、画像や仕様（大きさ、素材など）は送れる - 表現の実態はバイト列で、ネットワーク越しに送ることができる

標準化されたHTTPメソッドのセット（GET/POST）を使用してリソースを操作できる。

自己記述的メッセージ

メディアタイプなどメッセージの解読に必要な情報はリンクヘッダ, content-type, プロファイルへの参照に書かれている。情報をキャッシュする必要があるか、情報がいつまで有効かを決めるのはサーバー。クライアントで決めるのはRESTではない。

HTTPの仕様では以下の失敗があった。 - 1.0: Hostヘッダーがない -> 1.1で解消 - 1.1 どのリクエストできたメッセージかわからない。

Halだと表現できるのでBEAR.SundayではHalを採用した。

ハイパーメディア制約

アプリケーション状態はクライアント側に保持され、その変更はクライアントの責任において行う。変更はHTTPリクエストを行なってレスポンスを処理することによってのみ可能で、レスポンスに入ってない操作は不可。

次のアクションはform（ハイパーメディアコントロール）の中にある。 - ショッピングサイトの例：商品一覧からカートにPOSTする。

6つのアーキテクチャ制約

~~https://www.ca.com/content/dam/ca/jp/files/ebook/a-guide-to-rest-and-api-design.pdf~~

2019/12/01 CAテクノロジーズが買収されてリンク先がなくなっていたので、英語版の物に差し替え https://docs.broadcom.com/docs/a-guide-to-rest-and-api-design

https://www.redhat.com/ja/topics/api/what-are-application-programming-interfaces

（これはアーキテクチャ制約にカウントしない）NULL制約

制約がない状態から始める。構築のプロセスにはコンポーネントから構築するパターンと、設計空間を作って制約を適用するパターンがある。 RESTは抑制と理解を強調する、設計空間を作って制約を適用するパターンによって構築された。

クライアント・サーバ

ブロードキャスト・イベントリスナーと違う

ステートレス

リクエストがなければ、クライアントが存在しないのと同じ。ステートレスと言うのは、ステートが変わらないと言う意味ではないので注意が必要。サーバーがアプリケーション状態を気にするなら専用のURIをつくり、リソース状態として管理すべき。

（RESTにおける）キャッシュ

自己記述的メッセージ制約とステートレス制約の上に成り立っている。アプリケーションのキャッシュとは違い、RESTのキャッシュはネットワークを使わないことを目指す。キャッシュを正しく使うことで、共有できるものとできないものを文書に残さなくても区別できるようになる。リクエスト数が減ってサーバーの代金が減るという利点以外に、ネットワーク帯域という公共財を使わないようにするエシカルな理由もある。

統一インターフェース

アドレス可能性、表現を通したリソース操作、自己記述的メッセージ、ハイパーメディア制約の上に成り立つ。 1回のリクエストで様々な情報を返すことでレイテンシが高くなる、おしゃべりAPI問題。

階層化システム

クライアント・サーバーの間にプロキシ（コンポーネント間を仲介する）・ゲートウェイ（プロトコル間を仲介する）を追加する場合は統一されたインターフェースを持つ、 HTTPシステム中の「コンポーネント」として振る舞う。クライアントから見たときに透過的にHTTPサーバとして見えるようにする。

コード・オン・デマンド

<script>タグのようにサーバはクライアントのコードが何をするか知らない。

WebAPIの設計戦略

システムが持っていると良いと思う特性を書き出す
必要な特性と、犠牲にしてもいい特性を見極める
本当に必要な特性をもたらしてくれるアーキテクチャ制約を見つける
その制約を具体化するプロトコルやその他標準を元に設計する（例えばHTTP,URI,HTML,Javascript）
2-4を繰り返す

EXTRA TALK

RESTの理解が正しくされていない理由についての考察がありました。

まず、以下の構図があります。

理論: Roy T.Fielding Experts: Mike Amundsen, Martin Fowler Mini Experts: @koriym audiense: われわれ

理論まで行く人が少く、audienseのなかだけでぐるぐる回っていて、本質的なものよりプラクティスの情報が氾濫している現状がある。一方、こうした構図は世の中に受け入れられて広く普及する過程で役に立った文化でもある。またRailsのようにマーケティング上手なRockstarの周りに集まり、それを広めるVIPがいてコミュニティで聞き耳を立てているコンシューマがいるという図式も紹介がありました。

最後に少数派を主義者として排除するのではなく、受け入れてみてくださいというお話がありました。