OAuth2 のフローを Alloy Analyzer でモデリングする - 詩と創作・思索のひろば
趣味でウェブの認証 API を地力で設計しようとしていたときに、認証フローの仕様を頑張ってこしらえたとして、その正しさをどうやって保証するんだろう？ と疑問に思い、調べていたところ、「形式手法」というのに行き当たった。 形式手法というのはシステムの正しさを上流工程から検証するための方法で、数理論理やロジックに基づいている。その中でも厳密な仕様定義を求める方向と自動検証を求める方向とあるらしいが、Alloy はその後者に位置づけられ、軽量形式手法と呼ばれるもののひとつだということらしい。Alloy はモデリングのための言語および実行環境で、以下のホームページから入手できる。 http://alloy.mit.edu/alloy/ インターネット上にチュートリアルやマニュアルもあるが、作者による教科書の邦訳が出ていて、これで勉強してみた。 抽象によるソフトウェア設計−Alloyではじめる形式手
React使い必見！ Immutable.jsでReactはもっと良くなる | Wantedly Engineer Blog
Reactを導入して半年近くが経ちましたWantedlyでは、今年の初めからReact(+Redux)の導入に取り組み始めたので、気付けば半年近く立っていることになります。今自分がこの記事を書いているエディタから、Wantedly Adminのチケット画面まで、ある程度大きなアプリケーションを開発してきました。 そこで今回は、チームで継続的に開発していく過程で遭遇した問題と、それを解決するために導入したImmutable.jsについて紹介します。 増え続けるCallbackとAction、肥大化するStoreReactとセットで語られることが多いFluxアーキテクチャ。ここでは詳しい説明は省略しますが、とてもシンプルな考え方なので、チュートリアルなどで簡単に学ぶことができます。しかし、実際にチームで開発していくと、たしかに動いてはいるけど、綺麗とは言い難いコードが増えてしまいました。 Ac
Paxos, Raftなど分散合意プロトコルを概観する(1) - 備忘録 blog
tl;dr 分散合意プロトコルについてサーベイしたので、メモを残す。 2PC 3PC Paxos Raft(次回) Proof of Work(次回) Proof of Stake(次回) 分散システムについては素人の筆者が書いたため誤りが多いと思うので、できれば確認のため元論文を参照してもらいたいです。 introduction 基本的な定理, 用語 CAP定理: 分散システムは、一貫性 (Consistency)、可用性 (Availability)、分断耐性 (Partition-tolerance)のうち最大でもいずれか2つしか満たすことはできない。 レプリケーション: 一貫性を保ちながら、リソース間で情報を共有すること。 RPC: プログラムであるノードから別のノード上の関数を呼び出すこと。ここでは、ノードから別のノードにメッセージを送ることという理解でもたぶん大丈夫だと思う。
The complete guide to Go net/http timeouts
When writing an HTTP server or client in Go, timeouts are amongst the easiest and most subtle things to get wrong: there’s many to choose from, and a mistake can have no consequences for a long time, until the network glitches and the process hangs. HTTP is a complex multi-stage protocol, so there's no one-size fits all solution to timeouts. Think about a streaming endpoint versus a JSON API versu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
