JUnit のセカイ #JJUG - やさしいデスマーチ
このエントリーは、@cero-tさんのエントリーの次で、Java Advent Calendar 2011の6番目のエントリーです。自分自身の今年のメインテーマがTDD（テスト駆動開発）と言う事もあり、関連エントリーとしてJUnitについて書きたいかと思います。今更JUnit？と思われた方も普段からJUnitを使っていあなたも気軽にお読みください。尚、色々な話題を駆け足で紹介するので、どれも簡単な紹介程度になってしまいますが、ご了承願います。 JUnit4 スタイル JUnitがアノテーションに対応し結構な月日が流れましたが、古いコーディング規約のままでテストコードを書いていませんか？JUnit4では、アノテーションとアサーションを使ったテストコードを書くことが基本スタイルです。かつては、TestCaseのサブクラスを作り、testではじまるメソッドを定義していましたが、今は Testアノ
テスト駆動開発チートシート - やさしいデスマーチ
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
ユースケース駆動開発BootCampはじめました - やさしいデスマーチ
昨日のこととなりますが、札幌でソフトウェアの開発プロセスの１つであるICONIXをテーマとした勉強会を開催しました。ユースケース駆動開発BootCampという名称で、TDDBCの派生です。本家TDDBCと同様に、午前中は講演中心の座学、午後から演習で実際に手を動かして体験してみるというスタイルの勉強会です。最近はこの手の体験型勉強会がテスト駆動開発などを中心に広がりつつあるような気がします。 開催の経緯 実は３年ほど前に札幌Javaコミュニティを立ち上げた時、最初の頃に行っていたのが「ユースケース駆動開発実践ガイド」の読書会でした。この本は、ユースケース駆動開発に関してICONIXというプロセスを紹介しながら解説する本です。その後、自分としても関連したプロジェクトにユースケース駆動開発のエッセンスは取り入れるように取り組んでおり、一定の成果があったと感じております。そこで、このプロセスを広
Java開発者の読むDjangoの設計思想 - やさしいデスマーチ
Djangoのサイトには「Djangoの設計思想」というドキュメントがあります。どんなフレームワークでもそうですが、設計思想を理解し、その流れをつかむ事で正しい利用への最短ルートです。もし、自分の思想にあわないならば問題です。可能であれば、そのフレームワークの検討を取り止めるべきでしょう。それが出来ないならば利用している時にはそのフレームワークの思想で思考することが求められます。 Djangoの設計思想は、緩く結合し、必要最低限のコードで、だが隠蔽せずに明示するという事です。DjangoではMVT（モデル／ビュー／テンプレート）と呼ばれるMVCに近い構造をとります。それらの３つのレイヤーはお互いに疎な関係を持ち、モデルとテンプレートはデフォルトの実装以外を容易に採用できるようになっています。また、ほどよく規約を適用し必要なコード量は少なくなっていまが、なんでもかんでも裏側で処理せずに、なに
オブジェクト指向の教え方 - やさしいデスマーチ
自分も研修などで教える立場にたった事がありますが、ただの手続きからオブジェクト指向的な考え方へシフトさせるにはどうしたらいいか？という話題です。 どうしてオブジェクト指向にするのかの1つの理由は、面倒だからっていうのが挙げられると思います。main関数が持つ責任を減らして、自己責任で動いてもらう。細かい指示をしないでも動いてもらう。そういうことが、オブジェクト指向をすることで出来ます。 そしてこれは、大規模プログラムだとか、再利用性を意識したプログラムとか関係無しに、利益があります。何でも自分でやった方が楽だというのも1つの考え方ではありますが、それだけだと限界が訪れますし、なにより疲れます。 http://d.hatena.ne.jp/tek_koc/20090612/1244818231 コメントやブクマでメンドクサイ指摘がされていますが、自分はこれでOKだと思います。 いきなりオブジ
finalをつけたらパフォーマンスが落ちたでござるの巻 - やさしいデスマーチ
山岳信仰の盛んだった日本では山奥の開発現場など、まだまだfinal信仰が盛んなわけですが、先ほどのコードにfinalを付けてみました。 public static void main(String[] args) { final int NUM = 31; long start = System.currentTimeMillis(); for (int i = 0; i < Integer.MAX_VALUE; i++) { int hash = 17; hash = hash * NUM + i; hash = hash * NUM + i; hash = hash * NUM + i; hash = hash * NUM + i; hash = hash * NUM + i; } System.out.println(System.currentTimeMillis() - star
ICONIXプロセス - やさしいデスマーチ
札幌Javaコミュニティでは「ユースケース駆動開発実践ガイド」の読書会を行っているわけですが、勉強会の成果物的な意味も含めて、とりあげられているICONIXプロセスに関して簡単にまとめておきます。 ICONIXはあまり聞き慣れないプロセスかとは思いますが、ロバストネス分析という名前はどこかで聞いたことがあるのではないでしょうか？実は、ICONIXプロセスの一部にロバストネス分析があり、ユースケースから詳細設計を駆動する為に存在しています。逆に言えば、実はロバストネス分析を実践的に使うための方法がICONIXとも言えます。ロバストネス分析はICONIXプロセス全体を通して重要な意味を持っており、ロバストネス分析といえばICONIXとも言えるわけです。 ICONIXプロセスは、小〜中規模の画面を介するソフトウェア（Webアプリなど）の開発に適したプロセスで、概要設計後の基本設計から要求テストま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
