リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
「失われた20年」は、実は「成長痛の20年」でした：日経ビジネスオンライン
インターネットサービス企業のディー・エヌ・エー（DeNA）、メモリー大手のマイクロンメモリジャパン（旧エルピーダメモリ）、大手製薬会社アステラス製薬、半導体に欠かせないシリコンウェハーメーカーのSUMCO、大手都市銀行のみずほ銀行、そして最近上場したジャパンディスプレイ。これらの企業の共通点は何でしょうか。 彼らは、「失われた20年」の間に生まれ、躍進してきた企業群のほんの一部です。このグループには現在、成功している企業だけでなく、苦しんでいる企業、既に売却された企業など、実に様々な企業があります。しかし「失われた20年」と呼ばれた時代であったのにもかかわらず多くの企業が生まれ、その多くが今も活躍しているのはなぜでしょうか。 彼らは、ベンチャー企業、みずほやアステラスのように合併によって作られた企業、あるいは20年の間に作られた新しい起業方法から生まれた企業です。楽天、カカクコム、グリー、
既存の Objective-C のメソッド引数の Swift 上での扱われ方を調べてみた
前置き こちらの記事には2014/06/09現在、公式にはリリースされていないiOS8プレリリースドキュメントへのリンクが含まれます。iOS8にて新しく追加された内容には一切触れておらずAppleとのNDA規約にも違反するものではないという認識ですが、場合により予告なく削除する可能性があります。予めご了承ください。 本題 iOS8プレリリースドキュメントを眺めていて気になったのですが、ほとんどのCocoaのメソッドの引数に!がついています。例えばNSKeyValueObservingプロトコルのaddObserver:forKeyPath:options:context:メソッドのシグネチャは以下のようになっています。 func addObserver(_ anObserver: NSObject!, forKeyPath keyPath: String!, options options
Swift で __conversion メソッドを使ってカスタムの型変換を定義する方法
2014/10/21追記: Xcode 6.0 beta 6以降、__conversion()を使った暗黙的なas演算子を用いた型変換はサポートされていません。Xcode 6.1(Swift 1.1)現在、暗黙的な型変換を行う手段はないため、型変換を行いたい場合はイニシャライザを定義する方法を取るのが通例として良いと思います。 class 変換対象の型 { init(_ obj: 変換元の型:) -> 変換対象の型 { return 適当に変換対象の型を返す } } Swiftではas演算子を使ったり、型の定義されている変数・定数へ代入したり、メソッド呼び出しの引数にオブジェクトを渡す際に型変換が行われますが、デフォルトでは対応していない型変換があったりします。例えばStringはasを使ってもIntに変換することはできません。 また、SwiftではnilはNilTypeという型のシングル
シニアエンジニアによるガラケー大戦回顧録に参加した
シニアエンジニアによるガラケー大戦回顧録 : ATNDに参加した。 この会合の主旨としては、当時の邪悪で不自由極まりないガラケーの開発姿勢が、如何に悲惨で惨めで肥溜めの中の蛭のようなものだったかを、非公開の会合で語ろうというものだ ガラケーの開発では、技術的に誤っている手法が実に多く使われていた。なるほど、不自由で貧弱なガラケーの実装が規格準拠しておらずバグだらけだったこともあろう。それにしても、ガラケーとは関係がないサーバーの中だけで完結する場所におけるクソもあった。何故そんなことになってしまったのか。 理由は、情報が公に出せず、したがって共有されなかったことだ。情報が共有されないため、表立って議論や相談が出来ない。その状態でかろうじて見つけたちっぽけな情報を元に、技術的に極めて劣っていながらも、何とか動くものを作り出していた。そして、その動くものを、正しいやり方だと勘違いしていたのだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
