リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
