カーソルが解放されるタイミング (2) - ablog
カーソルが解放されるタイミング - ablog の続き。 Statement、ResultSet を毎回 close しながら無限ループするプログラムと、Statement、ResultSet を close せずに無限ループするプログラムを実行してみて、前者は永久に実行され、後者はカーソルリークで例外が発生して異常終了することを検証してみた。 [結論] Statement を close すればカーソルリークは発生しない。コネクションプーリングを使わない場合は、Connection を close するとカーソルリークは発生しないが、コネクションプーリングを使う場合は Connection を close しても、Statement を close しないとカーソルリークが発生する。たぶん。 やさしく学ぶ基礎からのJDBC P.137 java.sql.Statementをクローズすると
TiDDを実践して気付いたことpart7～繰り返し開発を制する者はSW開発を制す - プログラマの思索
先日、S-OpenでRUPで有名なクールシュテン博士によるアジャイル開発の講演があった。 Agile開発は大規模プロジェクトでは難しい、アーキテクチャを重視するプロジェクトでは難しい、などの話を聞いて、そんな話は昔から聞いていた、と正直聞き飽きた。 そんな違和感を感じながらも、チケット駆動開発を実践して、アジャイル開発の難しさが何となく分かってきた気がする。 考えたことをメモ。 【元ネタ】 TiDDを実践して気付いたことpart6～TiDDでAgile開発を実践して分かってきたこと: プログラマの思索 TiDDを実践して気づいたことpart4～TestLinkによるテスト戦略: プログラマの思索 以前書いたように、Agile開発が難しい理由は、その最大の特徴である「超短期間の繰り返し開発」を実現するハードルが高いことにある。 その内容は次の3つに言い換えられる。 １・繰り返し開発はイテレー
更にもう一つのAll In OneRedmine～RedmineLE - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
スクラムチェックリスト by Henrik Kniberg @ crisp.se - kawaguti’s diary
注意: この記事より新しい版があります。 Henrik Kniberg氏のスクラムチェックリスト (http://www.crisp.se/scrum/checklist ) を日本語訳してみました。スクラムをうまく行えているかどうかのチェックになると思いますので、ご活用ください。（TracのWiki記法になっておりますが、いずれHenrikさんが元のppt形式に取り込んでくれるかも、です。） (2009/09/01) 原版のフォーマットをHenrikさんからもらいましたので、マージしました。 (元ファイルはGithub: http://github.com/kawaguti/Scrum-Checklist-Japanese/ に置いています) = the unofficial Scrum Checklist = * version: 2.1 (2009-08-17) * http://w
第二期アジャイルムーブメント - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Mercurial以前と以後のチケット駆動開発 - プログラマの思索
Mercurialのような分散バージョン管理を組み合わせたチケット駆動開発とそれ以前の開発スタイルの違いをまとめる。 【元ネタ】 Re:Re:mercurialでチケット駆動開発 - ろじぼ Mercurialによるチケット駆動開発は強力だ！: プログラマの思索 ReviewBoardとMercurial＋TiDDは相性が良い？: プログラマの思索 【Mercruial以前のTiDD】 「Mercurial以前のチケット駆動開発」シートにあるように、trunkと本番ブランチの2本でソース管理している。 基本は、trunkはリファクタリングや機能追加、本番ブランチは障害修正のみ行い、ソース修正の目的をコードライン単位に使い分ける。 理由は、コードラインの品質を維持したいからだ。 リファクタリングや障害修正、機能追加をtrunkの1本のみで行うと、突然の本番障害に対応できなくなるからだ。 そし
Redmineで要件管理、リスク管理ができるプラグイン - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
astah*Professionalファーストインプレッション - プログラマの思索
生産性: 知識ゼロから学ぶ ソフトウェアテスト