HTML5 & The Web PlatformHTML5と関連する仕様について、その目的や中身について簡単に紹介しています。 2010年2月19日に開催されたDevelopers Summit 2010で講演したときのスライドです。Read less
TDDと品質保証 - @katzchang.contexts
今んとこはこんなイメージです。 *1 TDDで作るテストコードは、開発者が意図している仕様となっていることを保証している、と言う部分は言い切っちゃっていいような気はする。問題は、その仕様が要件を満たすとは限らないということ。最悪のシナリオは「仕様を保証するテストコードはきっちり出来たけど、ユーザが欲しいものは何も出来なかった」。よくある、古典的な課題の一つです。 要件を確認しながら「小さな一歩」を続けられるかってことなんだろうかなぁ。「目の前の問題に集中しろ！たまには周りを見渡せ！」っていう、相反した要素が求めらるわけですよ。これが、ペアプロとの相性がいい理由かな。 この辺りを夜な夜な語り明かしたい方々は、 TDDBootCamp北陸に是非お越し下さい（宣伝 *1:https://cacoo.com/diagrams/C1YxffZJT0r38ey6
JUnit って、なんでテスト順が不定なの？ 馬鹿じゃないの？
副作用のあるテストを書かせないためかもしれないけど。 でも、テストって普通、簡単なものから難しいものへ、順番に書いてくんじゃないの？ そうなってないと品質上げていきにくいし。テスト順を不定 (ってこと) にして何がうれしいんだろ。 あるいはたとえばデータベースまわりのテスト書いてると、普通は副作用に依存したいと思うんですけど。１つのテストケース動かす度にテーブル作り直すとかありえないし。 INSERT のテストケースを動かして、次に SELECT のテストケースで読めるか確かめるとか普通やるよね。 てか、INSERT が動かないことには SELECT のテストが動くわけないのに。テスト順がないから、そういう依存関係の定義も面倒。 テスト順が明示的であれば、最初に問題が出たテストから順番につぶしていけばいいよね、ってことになるけど、順序が不定だから直感的じゃない。 「べき」論にこだわって生産
Spring Framework's Migration from Jira to GitHub Issues
We used the opportunity to streamline the Jira field values, so for example 25 component values in Jira correspond to 5 "in: *" labels on GitHub. The "status: *" and the "type: *" labels have also been given extra through and revised. Our choice of labels is aligned with the labels used in Spring Boot. The Boot team has given their process and labels a lot of thought, and we know the consistency w
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Migrating from grails 1.1.1 to grails 1.2.1 | TO THE NEW Blog
SpringSource dm Server™ Programmer Guide
5. The Web Admin Console
