About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
2013年4月13日追記: PHP 5.5 で finally 句が追加されたので Loan パターンを追記しました。 Closure Design Patterns で紹介されている Groovy のコードを PHP に翻訳しました。無名関数とクロージャを区別しても情報が分散してしまうのでクロージャに統一しました。Method Combination (関数合成)は省略しました。原文ではカリー化(currying) と書いている箇所を部分適用 (partial application) に訂正しました。カリー化と部分適用の違いについてはこちらのブログに解説があります。Groovy コアに本当のカリー化メソッドを採用することへの要望があり、長期的には取り込まれる見込みのようです。 これらのパターンは Venkat Subramaniam 氏および Neal Ford 氏のプレゼン資料から抜
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基本的に irxground 君と同意見のところは省略します。 あと、GoF の本自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければなら
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
