リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは
JavaしかかけないおいらがiPhoneアプリをリリースするまで - しんさんの出張所 はてなブログ編
今回の内容は前回よりだいぶましだぞ・・・。 業務系Java屋がMixiアプリをリリースするまで Javaしかかけないおいらがmixiアプリ第2弾をリリースするまで mixiアプリ第3弾「コレオススメ！」リリースするまで Javaしかかけないおいらがmixiアプリ第4弾をリリースするまで JavaしかかけないおいらがAndroidアプリをリリースするまで の続きになります。 正直実装的にはmixiアプリ第2弾のエントリ(GWT+Flash+JavaSEとの互換レイヤでサクサク開発)が飛びぬけていると思いますが、それ以来くらいのインパクトはあると思います。 長文です。 iOS版を開発するぞ マモノバスター2のAndroid版は無事だせました。読んでない人は上に並んでる過去のエントリを読んでみてください。 AndroidはJavaSEと同じJava言語ということで、JavaSEと互換のレイヤーを
#JJUG_CCC Spring 2014で「初めての Java EE 開発から学んだこと」というタイトルで発表させて頂きました！ - Challenge Engineer Life !
昨日、ベルサール西新宿で開催されたJJUG CCC Spring 2014でJava EEに関する発表をさせて頂きましたm(_ _)m セッションに参加して頂いた方々、本当にありがとうございました！！ また、先月、日本オラクルさんのJavaセミナーで講演させて頂いたときのレポートも公開されましたm(_ _)m 「顧客ニーズへの柔軟かつ速やかな対応」、「開発環境のカイゼン」──Java EE 6の採用で構造計画研究所が得たメリット http://t.co/8acwAhpfwm— builderjp (@builderjp) 2014, 5月 19 1年半前にボスからJavaでのWeb開発を求められて「今さらジャバ！？」と半分やさぐれつつ、右も左もわからない中、Java EEで開発をしてきたのですが…その頃はまさかJJUG CCCのような舞台やOracleさんで発表する機会を頂けるなんて正直思
「顧客ニーズへの柔軟かつ速やかな対応」、「開発環境のカイゼン」──Java EE 6の採用で構造計画研究所が得たメリット - builder by ZDNet Japan
自社製品の機能強化と対応プラットフォーム拡大のため、初めて取り組んだJava EE開発。構造計画研究所の菊田洋一氏らは、それによってどのようなメリットを得たのだろうか？ 構造計画研究所の菊田洋一氏が、Java EE 6採用のメリットを語った 日本オラクルは2014年4月、ユーザー企業の情報システム部門管理職やアーキテクトらを対象にしたセミナー「最新のJavaを3時間で知るJava解説セミナー」を開催した。昨年より定期開催されている同セミナーの特色は、日本オラクルのエンジニアやコンサルタントがJavaおよびJava EEの最新動向について解説するほか、ゲスト・スピーカーとして招かれたユーザー企業のアーキテクトらが、Java EEへの取り組み状況を直接紹介している点だ。今回のセミナーでゲスト・スピーカーとして登壇したのは、本サイト記事「初めてのJava EE 6開発！ 最初の壁をどう乗り越えた
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
日本のプロジェクトが生産性が悪い理由：夜な夜な海外ネット：オルタナティブ・ブログ
日本のソフトウエア開発プロジェクトでは多くの非開発者が必要だ。その理由はまだウォータフォールで開発しているからだ。ウォータフォールでは、大組織を運営するためのような組織体制が必要である。米フォード自動車なでも同じような工程で自動車を設計から製造なで行ってきた。伝統的な手法のため、安心して使うことができる。 ウォータフォールでシステムを開発する場合は、フェーズ毎に同期を取るために打ち合わせが必要である。フェーズ毎の成果物の整合性が合っていないとその後のフェーズで問題が起きる。しかし考えてみると、ウォータフォールで開発しなければこんなに開発と直接関係ない作業も人の必要性もない。 日本でアジャイル開発がそんなに採用されない理由は、もしかしたら組織ありきだからかもしれない。従来ウォータフォールの組織体制でアジャイル開発をするのは難しい。しかし、メインフレームの製造のようにパソコンを製造していたら、
実践者からエール ユーザーよ、主体性を取り戻そう こうすればシステムを内製できる〜シンポジウム「システムイニシアティブ2011 Summer」から〜
企業にとって最適なシステムとは何か。適用業務を熟知したユーザー自らが主体的に取り組み、構築したシステムにほかならない。では、そうした「ユーザー主体開発」をどう進めればよいのか――。2011年7月28日、日経BP社と「システムイニシアティブ研究会」が共同でシンポジウム「システムイニシアティブ2011 Summer」を開催した。会場を埋め尽くしたユーザー企業のシステム担当者の熱気あふれる中、システムの内製に取り組んだ企業の事例報告、来場者を巻き込んだディスカッションと意見交換会が行われ、ユーザー主体開発の「実践」に向けた方法論や課題が検討された。 八十二銀行はシステム分野で常に先進的な取り組みを続けてきたことで知られる。1965年に地銀初となる銀行内為替業務オンラインシステムを稼働させたのを皮切りに、1971年には全店にわたる顧客の名寄せ機能を、そして1989年にはオンラインシステムの24時間
組織に継続的インテグレーションを導入していく7つの段階
みなさんこんにちは。@ryuzeeです。 継続的インテグレーションの導入に関する分かりやすい記事があったので抜粋・意訳にてご紹介します。 原文はJohn Ferguson Smart氏のブログ記事「The Seven Phases of Introducing Continuous Integration into Your Organization」です。 継続的インテグレーションは全部かゼロかといった類のものではない。事実、CIの組織への導入はいくつかの明確な段階を経て進んでいくのだ。それぞれの段階は技術的な構造もそうだが、それ以上に重要であるであろう開発チーム自体のプラクティスや文化のインクリメンタルな改善を含んでいる。 以下の章では各段階についておおよその全体像を示すことにしよう。 第1段階 ビルドサーバがない初期の段階ではチームはなんらの中央ビルドサーバも持ちあわせていない。ソフ
金融フロンティア領域TOPシェアのSimplexが採用強化｜【Tech総研】
金融機関のフロンティア領域におけるITコンサルティングやシステム開発で大きなシェアを誇るシンプレクス・コンサルティング。即戦力のITスキルと金融分野への興味をもつITエンジニアの採用を強めている。その背景には何があるのか。 シンプレクス・コンサルティングは、最先端の金融業務知識とITを結び付けた金融ソリューション・サービスを提供するコンサルティング企業だ。中でも、「金融フロンティア領域」と呼ばれる業務領域のシステム開発を得意としている。金融機関でいうフロント業務とは、例えば、株式、債券、デリバティブなど金融商品のディーリングやトレーディング業務を指す。後方事務処理業務を指すバック業務に対する言葉だ。バック業務がどちらかといえばコスト削減の対象になるのに対して、フロント業務では金融機関自らの収益最大化を目的とする。このフロント業務の中でも、特に戦略的なIT投資によって収益向上を図ろうとする領
Agile Conference tokyo 2011 参加レポート｜オブジェクトの広場
Agile Conference tokyo 2011 参加レポート 株式会社オージス総研 アドバンストモデリングソリューション部 浅井 良 Agile Conference tokyo 2011概要 7月20日に江東区文化センターホールにて行われたAgile Conference tokyo 2011に参加してきました。 Agile Conference tokyo 2011 - イベントTOP 株式会社テクノロジックアートにより主催・運営されるAgile Conference tokyoは今回で3年目を迎えます。「回を重ねるごとに来場者数も伸びており、アジャイル開発がいよいよ日本国内で本格的に広がっていくのではないかという期待を抱かざるをえません。」と書かれているように、400名の定員に対して参加希望者が殺到して抽選制になるほどの人気で、特に、午前中のマーティンファウラー氏の基調講演
「本番環境への適用まで自動化して繰り返す」、Martin Fowler氏がアジャイルのテクニックを語る
「本番環境への適用まで自動化して繰り返す」、Martin Fowler氏がアジャイルのテクニックを語る 「本番環境への適用までを自動化する『Deployment Pipeline』のテクニックが重要だ」──。オブジェクト指向開発やアジャイル開発の専門家で、2001年に発表された「アジャイルソフトウエア開発宣言（Manifesto for Agile Software Development）」の起草にも参加した米ThoughtWorksのMartin Fowler氏（Chief Scientist）が7月20日に東京・江東区で開催された「Agile Conference tokyo 2011」の基調講演に登壇（写真）。「Software Design in the 21st Century：21世紀のソフトウェアデザイン」と題して、アジャイル開発で効果的な手法について語った。 Fowler
アンチパターン - Wikipedia
ソフトウェア開発におけるアンチパターン (英: anti-pattern) とは、必ず否定的な結果に導く、しかも一般的に良く見られる開発方式を記述する文献形式を言う[1]。その内容は、基本的には、否定的な開発方式の一般的な形、主原因、症状、重症化した時の結果、そしてその対策の記述からなる[2]。 デザインパターンを補完・拡張する関係にあるもので、多くの開発者が繰り返すソフトウェア開発の錯誤を明確に定義することにより、開発や導入を阻害する一般的で再発性の高い障害要因の検知と克服を支援することが目的である[3][4]。 ある問題に対する、不適切な解決策を分類したものをアンチパターンと言う[5][6]。 アンチパターンという呼び方は、アンドリュー・ケーニッヒ（英語版）が1995年に作り出したもので[7]、後に書籍The patterns handbook[8]で再掲された。 ギャング・オブ・フォ
＠IT：初めてのソフトウェアメトリクス（後編）
初めてのソフトウェアメトリクス（後編） ソフトウェアメトリクスを現場に組み込む テクノロジックアート 長瀬嘉秀｜矢野大介 2006/1/14 前編（ソフトウェアの品質を数値化して確かめる）、中編（凝集度と結合度：このコードのどこが悪いのか？）を通じて、ソフトウェア・メトリクスの概要を解説しながら、ツールを利用したメトリクス測定による問題点の抽出方法を提示しました。今回は、実際の開発現場で設計改善するときの問題点や、メトリクス測定を利用した改善方法を説明します。 1. 開発現場の現状 一般的に、開発が進み、機能が増えていくに従って、図1のような複数のクライアントコードからロジックコードが呼び出されるような構造になっていきます。図1で明らかなように、依存性がとても複雑になるため、徐々に拡張性や可読性、保守性が悪化していきます。また、単純に重複したコードを共通化・共有していくと、さらに複雑さが増
Javaで覚えるIT技術者の40の常識 - ＠IT
～新人プログラマ／SEは覚えておきたい“まとめ”～ ＠IT編集部 2011/3/24 このページは、開発者／プログラマが、以下のような項目に関して、常識的な基礎知識を学ぶための記事リンクのまとめです。 デスクトップなどの見た目に関する3つの常識 プログラミング・コーディングに関する6つの常識 ネットワーク／通信に関する9つの常識 セキュリティに関する3つの常識 データとファイルに関する5つの常識 設計・アーキテクチャに関する6つの常識 ソフトウェアの品質管理に関する3つの常識 業務アプリに関する5つの常識 Java SE（旧、J2SE）のコアAPIやJSP／サーブレット＋StrutsのWebアプリケーション開発、JBossやその他のJavaオープンソースソフトウェアのサンプルコードや使い方を通じて、さまざまな“常識”を学習する以下の連載の記事に、基礎知識のカテゴリごとに分けてリンクしていま
ビルド時に環境ごとに設定ファイルをAntで切り替える方法 - wyukawa's diary
例えば以下のように環境依存な設定ファイルがあるとします。この設定ファイルを環境にあわせてどうやってビルド、デプロイするのがいいのか？というのがテーマです。 sample-common/ |--src/ |--main/ |--resources/ |--mail.properties メールサーバのホスト名が書かれている sample-db/ |--src/ |--main/ |--resources/ |--ibatis-config.xml DBサーバのURLが書かれているibatis-config.xmlはこんなイメージです <property name="JDBC.ConnectionURL" value="jdbc:oracle:thin:@localhost:1521:XE" />ひとつのやり方としては、これらの設定が書かれたファイルをリポジトリに置く際はローカルにあわせたもの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
国内の開発者が使っている言語、1位C、2位VB、3位Java。アジャイル開発は2割が採用、半数以上がウォーターフォール。IDC調べ
Facebookはどのようにコードを出荷しているか
創発 未来につながるために 世界に帆を立てるために Developers Summit 2011