gologo13のブックマーク - はてなブックマーク

Kong を使った Microservices Architecture API Gateway Pattern の実現方法 - Qiita
Kong を使った Microservices Architecture API Gateway Pattern の実現方法Dockermicroservices この記事は、Kong - API Gateway Pattern速習会＠Wantedlyの資料として作られたものです。サービスが大きくなるとやりたくなってくることより高速な実装に置き換えたい APIを複数のサービスに分けて開発したいマイクロサービス化何故マイクロサービスか James Lewis/Martin Fowlerの"Microservices"日本語訳 State of the Art in Microservices by Adrian Cockcroft - Qiita いろいろ理由は言われてるけど... 人が扱える大きさの限界「明確な」境界が必要名前空間やスコープなど、プログラミング言語でも使用してい
gologo13 2017/04/01
kong

microservices

api gateway
リンク
GitでMerge CommitをRevertする方法 - Qiita
何個もCommitがあるような一つのPull Requestを全てRevertしたいようなときに使えます。そもそもRevertとはあるコミットを打ち消すような、全く逆のコミットを作ることです。追加した部分を削除して、削除した部分を追加して、変更した部分を変更前の状態にするコミットを作成します。取り消したいコミットがあるのだけれど、既にリモートにコミットしてしまって、git reset, git rebase -i, git reflogなどを使っての取り消しが不可能なときに使います。通常のRevert 普通のcommitなら、revertは
gologo13 2016/12/22
git

revert
リンク
コードレビューの際に気をつけること - Qiita
コードレビューをする際と、してもらう際に気をつけるべきだと思っているをまとめておきます。レビュイーとして大切なことコードレビューをお願いする前にレビュアーが高いパフォーマンスを発揮するためには、レビューを受ける人の心構えと事前の打ち合わせが実は最も大切です。特に大きめの変更のコードレビューをお願いする前にすると良いこととしては、まず、レビュアーを確保するそのレビュアーと大まかな設計の合意をとるという方針でやっていくのが良いです。レビューしていても、根本をひっくり返すような指摘はしにくいですし、したとしても、それなら1から書いたほうがはやくて良い物が出来るといったことが簡単に起きます。「レビュー後に直せるもの < レビュー前に直せるもの」ということを意識して、Issueなどを用いて、出来る限り事前に設計、打ち合わせをしましょう。そうすればレビュアーもすんなりレビューできる
gologo13 2015/12/05
コードレビュー
リンク
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルールゴール「チームで長期にわたって生産性を上げる」前提みんながサービス・プロダクトについて自主的に考える組織エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考えるいわゆるPM職の不在 = コードは書かずに、マネージだけする人がいないこれは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。理想型図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチームマイクロサービスチームは、
gologo13 2015/09/26
体系的にまとめられているのすごくいい。いつか使いたい。

github

code review

git
リンク
1