駅前広場の小さな噴水に虹が架かる。 わたしはお気に入りのダサかっこいいGAFAのワンピースに身を包み、彼氏の到着を今か今かと待っている。 高学歴・高収入・高プロの三拍子が揃った自慢の彼はeスポーツ界の有名人だ。 彼の「ジタハラ持ち」から繰り出される悪質タックルと金足農旋風のコンボは半端ないってと恐れられているし、シューティングでの奈良判定の見極めやグレイヘアの巧みな使い方は災害級の暑さだと絶賛されている。 年の差のせいで、おっさんずラブだとあおり運転されるのは腹立たしいが、そんな時短ハラスメントで彼への想いが計画運休することなどあり得ない。 「だーれだっ！」 突然、視界がブラックアウトした。 「うーん……。スーパーボランティア？」 「ざーんねん。ボーっと生きてんじゃねえよ！　正解はオレでしたー！」 目隠しを外して、彼がひょっこりはんと姿を現す。 「もう。バカばっかり。わたし、お腹空いたんだ

2017/8/5 ぎんざRuby会議01 @みんなのウェディング 引用のリンク先などはこちらを参照ください https://medium.com/finc-engineering/ginzaruby01-rails-api-guide-168fe9cf5b4d

マイクロサービスの設計に対して、どう設計原則を使うのか、という話をしました。本稿では、資料中のいくつかの点に補足したいと思います。 SRP (単一責任原則)単一責任原則原則について、提唱者である Robert C. Martin 氏が2014年にさらに考察している記事を紹介しました ( The Single Responsibility Principle )。 この中では、変更する理由は「人」であるということに強くフォーカスされています。この考え方は、マイクロサービスの現実の問題に非常にマッチするため、今回取り上げました。ただ、筆者個人の考えではつねにこの「人」にフォーカスするのが常に現実の問題を解決するのに役立つかは疑問で、場合によっては受け取り方には注意が必要かなと思います。単一責任原則は、この追記がなくても長く大事にされてきたものです。 マイクロサービスの統合マイクロサービスをどう