TDDをはじめる条件 #tddbc #tddconf - やさしいデスマーチ
色々と忙しすぎてブログが書けません。 JavaOneの話とか、JUnitの話とか色々書きたいんですが…もうしばらく我慢なのです。 で、TDDの前方依存と後方依存で意見が欲しいとのことなので自分なりの意見を。 技術的な前方依存 『TDDを始める前と終TDDを実際やるために必要な技術』 ・最低限対象言語でコードがかけるようになって ・最低限テスティングフレームワークを使えるようになって ・リファクタリングをしっかり学んで ・対象言語でのきれいなコード、設計とは何かを知って ・テストファーストを知って こうしておそらくスタートライン。 自分はこれは疑問です。 最後の「テストファーストを知って」という部分はTDDに関することですけど、それ以外ってTDDを始めるスタートラインではなく、ソフトウェア開発としてのスタートラインかと思います。 言い換えると 最低限対象言語でコードを書けないと、ソフトウェア
TDDBC 札幌 2.1 開催しました - やさしいデスマーチ
シルバーウィークの後半に札幌にてTDD（テスト駆動開発）の体験型イベントであるTDDBC（札幌版）を開催しました。 TDDBC 札幌 2.1 であること ナンバリングが変な事になっていますが、札幌では今回で通算５回目の開催になります。近年、テスト駆動開発は開発手法として非常に重要なスキルの１つと考えられていますが、なかなか開発現場で実戦する機会はありません。自分で学習していくことも可能ですが、見よう見まねで学習するよりも同じような志*1を持っている人が集まって、同じ目標に向けて学ぶ方が効率が良いものです。1人で悩むよりもみんなで悩み、解決できるような人がイベントにいると安心ですから。 TDDBCは、テスト駆動開発を実際にやってみるためのイベントです。TDDの伝道師である id:t-wadaさんが講師を務め、午前中に座学、午後に演習というのが基本スタイルとなっています。しかし、TDDやアジャ
TDD Boot Camp 札幌 2.0 開催しました！（運営編） - やさしいデスマーチ
本日、札幌では４回目となる TDD Boot Camp 札幌 2.0 を開催され、 TDD界のリーダーであるid:t-wada氏に札幌で２回目の登壇をしていただきました。今回はTDDに関連する部分は、参加者のブログにお任せし、自分の方からは主催者視点でのレポートとしたいと思います。これを機会に他地域でのTDD Boot Campの開催の参考になったり、開催したいなと思って頂ければ幸いです。 開催まで 今回は札幌開催で４回目ということもあり、開催自体の準備は少なかったです。これは言い換えれば、はじめての時は色々と試行錯誤が必要ということでもあります。 参加人数の動向 札幌開催での参加人数は次のようになっています。 日付 No 参加者 備考 2010.12.18 0.5 ６名 Javaのみ 2011.1.23-24 1.0 ２６名 @t_wada氏登壇、言語自由（Java, Ruby, VB,
6/4 TDD Boot Camp 2.0 開催します - やさしいデスマーチ
TDD Boot Camp 札幌 1.5は明後日の5/15に開催されるのですが、その２週間後に本命の TDD Boot Camp 札幌 2.0が開催されます。 昨年の12月にプレキャンプとして0.5相当のTDD BCが開催され、1月には id:t-wadaさんをお招きして 1.0の開催、そして、2.0の前哨戦として1.5の開催という流れでした。今回、2.0では札幌独自で開催し、誰かゲスト講師を呼ぶとしても、まさか和田さんが来る事は想定していませんでした。しかし、2.0の開催をアナウンスした所、参加したいとの反応を頂き、今回もゲスト講師としてBoot Campを牽引していただく事になりました！ というわけで、参加募集をATNDにて開始しましたので、道内だけでなく道外からもお待ちしております。また、懇親会もあわせてご参加ください。 尚、2.0のお題は、「固定長バイナリファイルのI/Oを扱うプロ
コンストラクタ内でのthis参照リーク問題 - やさしいデスマーチ
「GUIの設計パターン」のコメントで指摘があったので補足しておきます。 Javaのコンストラクタは思った以上に複雑で、希に困った状況を引き起こします。その１つの例が「コンストラクタ内でthis参照リーク」問題です。次のようなコードがあった時、どうなるか予想できるでしょうか？ class Bar { Foo foo = null; Bar() { } } public class Foo { Bar bar = null; final String finalObj; Foo(Bar bar) { bar.foo = this; if (true) throw new RuntimeException(); this.finalObj = "OK"; } public static void main(String[] args) { Bar bar = new Bar(); try { F
Javaプログラマであるかを見分ける10の質問 - やさしいデスマーチ
元ネタはこちらですが、「優れたJavaプログラマ」を見分ける質問ではありません*1。次のような状況を想定してください。 受託業務を中心にしている弊社は、Javaで業務系ウェブアプリケーションの開発を行う事になりました。しかし社内のリソースを使うにも１−２名足らない事が見積もりから解っています。そこで、中堅エンジニアを1−2名募集することになりました。正社員か派遣かは問いませんが、経験が３年程度の中堅プログラマが必要です。同等またはそれ以上のスキルを持つ正社員がプロジェクトを牽引しますが、ゼロから教えながら教育することはできないので、必要最低限のスキルを持っていることが条件になります。 こんな状況を想定して、面接の質問を考えてみました。経験が３年程度あれば、問題なく答えられるはずです*2。尚、質問はホーム言語がJavaである前提です。 下記質問にそれぞれ50文字以内を目安に簡単に説明すること
Javaのチェック例外はクソ仕様 - やさしいデスマーチ
Java言語のチェック例外は本当にGood Partなのか？というエントリーを読んで自分の考え方を簡単にまとめておこうと思う。 まず、チェック例外自体はJavaの『あまり良くない仕様』とみるのが体勢であると思う。自分もどちらかといえば、『なるべく実行時例外で』という派。とはいえ、『クソ仕様なんでチェック例外はまったく使うべきではない』派ではなく、『必要に応じて使い分ける』派。そもそもクソ仕様とdisるくらいならクソ言語なんか使わない方が幸せ。 まずチェック例外自体に関する問題を改めて整理する。 いちいち定義するのがクソ面倒 常にtry-catchかthrows句を強制するのでクソウザい 横断的に処理しにくい 大規模プロジェクトになればなるほど、例外に関するスキルがないクソ人ばかり これらについては散々議論されているだろうし、愚痴になるだけだと思うので割愛。 で、自分はどうして『必要に応じて
TDD Boot Camp 札幌を開催しました - やさしいデスマーチ
1/22-23と2日間に渡り、id:t-wadaさんをお招きし、テスト駆動開発の体験型勉強会「TDD Boot Camp」を札幌にて開催しました。テスト駆動開発は結構前から話題にはあがっていましたが、ここ１〜２年でぐっと身近になってきた感覚があります。それは、TDDの伝道師id:t-wadaさんによるTDD BootCampの開催や各種勉強会での発表などが強く触媒となっているのでしょう。そして、TDD Boot Camp名古屋、TDD Boot Camp北陸と地方開催を促進しました。そんな流れの中、TwitterにてTDD Boot Camp札幌の開催を相談したのが昨年の11月頃です。id:t-wadaさんには開催の申し出を快諾して戴き、札幌開催は1月となります。その後、福岡開催も3月に決まり、他の地域でのTDD Boot Campの開催も計画されています。 というわけで、簡単ですが、イベ
14-コードレビュー - やさしいデスマーチ
「プログラマが知るべき97のこと」の14個目のエピソードは、コードレビューに関する話です。コードレビューの目的は「コードの品質を上げ、欠陥を減らすため」と考えがちですが、それと同じ程度に「チーム全員に同じ知識を共有させること、またコーディングにおいて全員が守るべきガイドラインを確立すること」が大切であると書かれています。 残念な事に、誰もがコードレビューが重要なことを理解している一方で、適切な形で開発プロセスにコードレビューが組み込まれているケースは希です。全コードをレビューしたとしても、バグが発生した時の言い訳にはなりますが、非常に時間を使うことになり通常は費用対効果は低くなります*1。また、レビューを組み込まなければ、各プログラマが好き勝手に実装することになります。それはそれで１つのスタイルかもしれませんが、コーディングスタイルを揃えて可読性を高める事はできませんし、経験の浅いプログラ
気のせいじゃなかったのか？ - やさしいデスマーチ
3.4のときはこんなことなかったのに、3.6はピリオドを打った瞬間に長い時間とまる。 ゲッターアクセスしようとしてgetとおすとそれぞれ絞られるのに時間がかかって十数秒とまる。なんだこれ。 そこからセッターを見たくてあわててバックスペースを3回おすとまた異様に長い時間かかる。 http://d.hatena.ne.jp/shin/20100915/p2 3.5でも気にならなかったけど、3.6は結構もたつくなーと感じていた 気のせいかな？と思っていたけど、そうでもないらしい。 求む、解決方法。 追記 2010/09/24 にEclipse 3.6.1がリリースされていますが、なおってなさそう？
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
Androidで学ぶ並列処理とGUI - やさしいデスマーチ
Docomo製Android端末の発売日が発表されました。来月の札幌JavaコミュニティもAndroidイベントということもあり、チュートリアルを作成したりしています。ちょっとスレッド周りではまった事もあり、簡単な時計アプリケーションの作り方から、Androidのスレッド描画モデルを紹介します。 とりあえずソース このアプリケーションは、0.5秒毎に日時を更新する単純な時計アプリケーションです。 package com.example.android; // import 略 public class Clock extends Activity { private ScheduledExecutorService service; private Handler handler = new Handler(); /** Called when the activity is first
オブジェクト指向の教え方 - やさしいデスマーチ
自分も研修などで教える立場にたった事がありますが、ただの手続きからオブジェクト指向的な考え方へシフトさせるにはどうしたらいいか？という話題です。 どうしてオブジェクト指向にするのかの1つの理由は、面倒だからっていうのが挙げられると思います。main関数が持つ責任を減らして、自己責任で動いてもらう。細かい指示をしないでも動いてもらう。そういうことが、オブジェクト指向をすることで出来ます。 そしてこれは、大規模プログラムだとか、再利用性を意識したプログラムとか関係無しに、利益があります。何でも自分でやった方が楽だというのも1つの考え方ではありますが、それだけだと限界が訪れますし、なにより疲れます。 http://d.hatena.ne.jp/tek_koc/20090612/1244818231 コメントやブクマでメンドクサイ指摘がされていますが、自分はこれでOKだと思います。 いきなりオブジ
Java開発者の読むDjangoの設計思想 - やさしいデスマーチ
Djangoのサイトには「Djangoの設計思想」というドキュメントがあります。どんなフレームワークでもそうですが、設計思想を理解し、その流れをつかむ事で正しい利用への最短ルートです。もし、自分の思想にあわないならば問題です。可能であれば、そのフレームワークの検討を取り止めるべきでしょう。それが出来ないならば利用している時にはそのフレームワークの思想で思考することが求められます。 Djangoの設計思想は、緩く結合し、必要最低限のコードで、だが隠蔽せずに明示するという事です。DjangoではMVT（モデル／ビュー／テンプレート）と呼ばれるMVCに近い構造をとります。それらの３つのレイヤーはお互いに疎な関係を持ち、モデルとテンプレートはデフォルトの実装以外を容易に採用できるようになっています。また、ほどよく規約を適用し必要なコード量は少なくなっていまが、なんでもかんでも裏側で処理せずに、なに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
