日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。本来の MVC とは何か？何が正しくて何が間違っているか？も重要なのだが、それよりは、なぜそれが生まれたのか？何を解決しようとしたのか？どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか？を知りたい。しかし、そういうことがまとまっている日本語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M
今日からはじめるDocker - コンテナー仮想化の必要性を理解して、まず開発環境に導入してみよう！ Dockerは、コンテナー仮想化ツールです。本稿では、サーバーサイドのアーキテクチャの歴史からDockerが生まれた流れや背景を説明し、PCの開発環境で実際にインストールしてDockerの動作を体験します。 エンジニアの方であれば、「コンテナー」や「Docker」といったキーワードを耳にしたことがあるかと思います。自分が関わっているシステムの開発や運用に活用できるかどうか検討している方もいるでしょう。 この記事の前半では、コンテナーやDockerとはそもそもどういったものかを概観していきます。後半では、PC（WindowsやMac）を使ってローカルでDockerを試していきます。 コンテナーとDockerを歴史から知る 仮想化前はすべて手作業だった サーバー仮想化技術の採用 パブリッククラ
これを書こうと思ったキッカケは、奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」っていう、最近モヤモヤと感じていたことをうまく説明してくれてる記事をみたこと。 年始からちょくちょくサーバの運用環境を物色しながら考えていたことと見事にシンクロした。だいたいの要旨はTwitterのほうでも書いたのだけれど。 ムーアの法則でどんどん向上する技術にくらべ、人間のキャパシティは変化しない定数項として考えていい。だとすれば、そうやって向上する性能を、人間の労力を削減する方向で使えてはじめて、「技術が競争優位性を生む」といえるだけの破壊的な価値がでてくるということになる。 では、現在の技術トレンドを活用することで減らせる「人間の労力」とは何か。 それは、過去10年あまりで定着した、これまでの（そして今なお）Webアプリケーションの定番構成である、「ロードバランサ、ア
昨日は、仕事の予定が思ったより進んだ（というか〆切が延びた）ので、行けるかどうか微妙だった「Architecture After 1995」のシンポジウム、「『2000年以後』を考える」を見に行ってきた。パネリストは五十嵐太郎氏。氏が関わった2000年の展覧会「空間から状況へ」と今回の展覧会を比較しつつ、10年前と何が変わったのか、何が引き継がれたのかについて、出展した建築家たちを交えつつ振り返るという構成。『思想地図vol.3』の巻頭座談会「アーキテクチャと思考の場所」が、1999年の『批評空間』誌上における「いま批評の場所はどこにあるのか」へのアンサーになっていたことと、おそらくパラレルに企図されたものだろう。シンポジウムの中身というより、出展されていた方々のアティテュードについては個人的な問いが残ったが、それは会場でも言ったとおり「保留」としたので、押しかけでコメントした部分だけ、あ
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く