アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
Software Architecture is Overrated, Clear and Simple Design is Underrated
I had my fair share in designing and building large systems. I've taken part in rewriting Uber's distributed payment systems, designing and shipping Skype on Xbox One and open-sourcing RIBs, Uber's mobile architecture framework. All of these systems had thorough designs, going through multiple iterations and had lots of whiteboarding and discussion. The designs then boiled down to a design documen
クリーンアーキテクチャ(The Clean Architecture翻訳)
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
オーバーエンジニアリングと技術的負債を見極める––SmartHRが明かす、成長の軌跡と技術選定 - Part2
SmartHRのインフラの変遷 内藤研介氏：開発言語とコミュニティへの貢献に続きまして、ここからはインフラとか開発環境について、お金と技術的選択を軸にお話ししたいと思っております。 一般的に、私たちのようなB to Bサービスは、B to Cサービスに比べるとユーザー数は少ない傾向にあります。その中でもSmartHRは、主に社内の管理者が使うサービスなので、サービス自体の特性としてインフラの投資がめちゃくちゃ必要なものでもないです。 こちらの数字は、2015年11月に本番リリースした際のサーバ費用です。ステージング環境も含めた費用ですね。非常に経済的なアーキテクチャだったわけです。料金のうちのほとんどはAWSの、RDSというデータベースのサービスです。あとはElastiCacheというキャッシュのサービスとか、そういった部分が占めていました。 詳しい方が聞かれるとちょっと驚かれるかと思うん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Amazon Builders' Library
