JMockitは理想的なモックフレームワーク - かとじゅんの技術日誌
テストを書いているとモックオブジェクトを使う機会が多いと思います。そのモックオブジェクトは自前で作るよりは、JMockやMockito*1などのフレームワークを利用した方が楽でしょう。 今回は機能的に、ほぼ最強と思われるJMockitを紹介します。 これが、他のモックフレームワークとの機能比較です。 MockingToolkitComparisonMatrix - jmockit - A feature matrix comparing several mocking toolkits. - Project Hosting on Google Code 機能が多ければ使いやすいか。そんなことはないと思います。しかし、これは使いやすいかもと周りの人からお勧めがあったので、実際に使ってどんなところが使えるのか検証してみたので、書いてみます。あと、最後にScalaで使えるか試してみました。 あ、
努力する人が最後には”できる人”になる - かとじゅんの技術日誌
先日の2月3日で39歳になりました。社会人20年を振り返ると苦労の歴史でした。でも、それは誇らしいことでもあります。 今でこそ「できる人」というイメージが強いかもしれませんが、、駆け出しのころは全くできない子でした。 ということで、苦労話。タイトルがありきたりですが、でも難しいことなんであえてつけてみた。押し付ける気も全くないですけど、できるやつが何 後付でカッコつけてんだよ！とか、非論理的だなって言われると思います。それは否定しません。そんなことは承知の上で、以下 おやじのうんちくをたれます。 限界を超えた努力 初めてのプログラミングは10歳の時にBASICでプログラムです。なんか難しいこと簡単にやらせてみたい欲求があって、PCというのは難しいけど楽しいかもしれないと思った。その頃の「好き」のレベルはまだ淡い幻想です。 それ以来、社会人になるまでPCはゲーム機でしたが、社会人になってC言
パソコン歴を振り返る - かとじゅんの技術日誌
徹夜明けのどうでもいい雑記です。 個人持ちPCの遍歴について書きます。 初めての出会い 初めての出会いは、小学4年にFM-New7。友達の家にあったPCを触ったのがきっかけ。たしか数日間借りて、お絵かきソフトをF-BASICを使ってプログラミングした記憶がある。スクラッチから書けるわけもなく、雑誌のコードを見ながらコーディング。 後はやっぱりゲームやってたね。媒体はテープ。どうやったらこんなすごいゲームが作れるんだろうとか、想像してとても楽しかった。 1982年、後継機の FM-7 が発売された。 重装備だった FM-8 から、あまり重要でない機能を外し、 価格を１２万６千円まで下げた。ライバルの PC-8001 より４万円も安いということもあって、FM-7 は大ベス トセラーとなった。この特集で取り上げるのは、FM-7 のマイナーチェンジ版の FM-NEW7 である。 高校時代 その後は
リスクヘッジのための黄金の法則 - かとじゅんの技術日誌
不況の折は、特にリスクマネジメントが問われる。 そういう意味においては、フリービット社の石田氏のこの行動指針は、リスクヘッジのための黄金の法則だと思っている。*1 早く動いて、早く失敗して、早く修正する。 以前のエントリを書かせてもらったが、「ベスト」ではなく「ベター」な戦略で未来に起きるリスクを早期に回避することが仮説思考だ。まさにその仮説思考に通じる行動指針といえる。 つまるところ、最後のゴールにリスクを持っていかないことだ。ゴールの到達までに、早期に実践し、失敗し、修正することを繰り返すことだ。最後に実践し、失敗することは避けなければならないのだ。 ビジネスの分野ではもちろん有益な行動指針であるが、開発プロセス論に適用すれば、「アジャイル」のような開発プロセスになる。XP本に書いてあるハンドルを小刻みに動かして車の行方を常に軌道修正するあれだ。また、設計と実装の実践論においては「テス
非検査例外に萌えるわけ - かとじゅんの技術日誌
検査例外はアジャイルやオブジェクト指向の考えに反するという事実 - じゅんいち☆かとうの技術日誌 タイトルは釣り度が強すぎかなー、、、まぁ、個人のブログなんで気にしないでくださいw ブログはカジュアルに書けばいいんですよ。タイトル付け失敗してもサーセンです。 「オブジェクト指向の考え」ではなく「オープンクローズド原則」に反するとしたほうがいいですね。 しかし、貶める気もない人に 貶めるという定義付けは いただけないなー。 で、そんなこんなで重量級をゲットしてもた。。 非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESS オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ エントリをいただいたので、さらにまた考えてみました。 チェック例外の正当性を再検証する 最近、多くの人の尊敬を集めているBruce EckelやRod Johnsonといった
知識は蓄積しても役に立たない時代 - かとじゅんの技術日誌
興味深いエントリを見つけた。 つまり、これはインプットじゃあなかったわけだ。だってアウトプット口がないんだから。 となると自分がやってきたことは何だったのか？ 少なくとも現時点では、ただの消費になっているのは間違いない。 みなさん、少なからず経験あるのではないかな。私は共感した。 ITプログラマを夢見て歩き出したときから、これはつきまとう問題。アウトプットするにもまずはインプットと考えてしまうのは仕方ないことだと思う。知識を集めないよりは集めたほうがいい。 何をするにも知識が必要だが、その知識はものすごい勢いで陳腐化していることに気づかないといけない。 インターネットが登場する以前は、知識を得て保持しているだけで価値があった。それはなぜか。その当時はナローバンドであったり、検索エンジンもそれほど膨大なネット上の情報をインデックス化できていなかった。つまり、情報にアクセスする手段が発達してい
そろそろ「何やらせても要領いいよね〜」について一言いっておくか - かとじゅんの技術日誌
若いころから「何やらせても要領いいよね〜」とか、「そつなくこなすよね」といわれる。社交辞令も含まれている言葉だが、よく言われる…。逆に業界経験が長いのに「何やっても要領悪い」じゃ格好付かないので、「それぐらいやって当然」的なスタンスだｗ この言葉は、私だけに限ったわけではなく、「仕事ができる人」や「仕事が早い人」に対して贈られるほめ言葉であるが、さて「要領がいい」とはどういう意味だろうか。あまりに日常的に使われすぎていて、使っている人たちも本当に意味をわかっているか微妙なところだ。 気軽に使っている「要領がいい」という言葉について今一度に考えてみたほうがいい。「要領いい人」と「要領の悪い人」の差ってなんだろうかと一考すべきだ。 そろそろ「何やらせても要領いいよね〜」について一言いっておくか。 うちの会社にも、「要領のいい」人は在籍している。外部の会社にもいらっしゃるだろう。難題に対して（も
Value Objects と Immutable - かとじゅんの技術日誌
おつかれさまです。そろそろ、プログラミングに関するエントリも書かなければw DDDの勉強を開始するにあたって、一番最初にEntitiesとValue Objectsに出会う。 今回は、まず先にValue Objectsと関連が深いImmutableについて、考えてみよう。なぜ、Value ObjectsかというとOODの基礎をなすからだ。基礎が弱いとその上の建造物ももろいものとなってしまう。だからValue Objectsがまず先。なーんだ、ただのJavaBeansなんでしょ、と思うと痛い目にあうよw 値を表すのがValue Objects。説明することが目的のオブジェクトである。ここに説明されているとおり。 ● Value Objects（値オブジェクト）パターン エンティティとは逆に、たとえば「色」や「量」のように、その属性だけが重要で、アイデンティティを考えることに意味のないオブジェ
堅牢なUNIX環境を作るためのポイントについて - かとじゅんの技術日誌
といっても、観点は改ざん防止やネットワークからの侵入を検知するとかいろいろあるが、 まず、この件を再発防止する方法を考えてみたい。 Mavenを使っていてLinuxのOSを破壊したので書いておく。 このようなリスクを回避したり、最小化できる堅牢な環境を作るにはどうしたらよいか。 いわずもがな、まずはBackupは定期的に行うことが必要。おすすめはストライピング以外のRAID。最近はオンボードのソフトウェアRAIDが安価に使える。これは予算に合わせて考える。Backupはバッチタイムなので、当然救済できないデータというのがあるので、最終奥義として考える。RAIDも万能というわけではない、ハードウェアトラブルでディスクがどうなってしまうかわからない。念には念をでAmazon S3みたいな外部ストレージにバックアップデータを退避させておくとよいかもしれない。 今回の場合は、RAID構成だったとし
プロフェッショナルなら政策メッセージを使え - かとじゅんの技術日誌
あけましておめでとうございます。今年もよろしくお願いします。 引き続き、ロジカルシンキングの話。前々回、前回と論理の基礎をざっくりと述べた。 同僚や上司、顧客から、納得を得るために必要なこと 〜演繹法〜 同僚や上司、顧客から、納得を得るために必要なこと 〜帰納法〜 これ以上深い論理学の観点には触れずに、、、今回は論理的な表現としての「メッセージ」（命題ともいう）について触れたい。*1 メッセージのタイプは４つあります。 事実メッセージ 評価メッセージ 政策メッセージ 希望メッセージ 簡単に説明すると、 事実メッセージは、単なる事実を述べる命題。 評価メッセージは、ある事柄に対する自分の評価を述べる命題。 政策メッセージは、政策を提言したり、何かアドバイスする命題。 希望メッセージは、依頼や希望を述べる命題。 となる。 この4つのメッセージを理解すると、コミュニケーションや意志決定が円滑にで
同僚や上司、顧客から、納得を得るために必要なこと 〜演繹法〜 - かとじゅんの技術日誌
自分の考えを相手に納得してもらいたい場面はプライベートでも仕事でもよくある。 そういう時に使えるのがロジカルシンキングだ。日本語に訳すと、論理的に考えることだ。そのまんまw まず、その論理とか何かという点について少し言及したい。 論理ってなに？ * (1)思考の形式・法則。議論や思考を進める道筋・論法。 * (2)認識対象の間に存在する脈絡・構造。 論理とは思考の法則、思考のつながり、推理の仕方や論証のつながりのことである。 なんか小難しいが、「考え方の規則」とか、「考え方の法則」ということかな。 論理的で何がうれしいのか？ そもそも、人間の思考はランダムだ。会議でも思いつきの発言で結論がまとまらないことがあるが、まさに人は散発的にいろんな考えが思いつく。普通にやっていては、ランダムな思考になりがちだ。 そこで思いついた自分のアイデアや主張がいかに正しいか、他人に納得してもらうための根拠が
INPUTすることを生活の一部にする - かとじゅんの技術日誌
妻子持ちの私にとっては、平日も休日もじっくり勉強する時間はとれない。いろいろと家のことも頼まれるからだ。 普通にやっていては時間はとれません。 私が実践しているのは以下。 RSSで新着の話題をチェックする。 今日の書籍というのを決めて鞄に入れて出社する。 RSSで新着の話題をチェックする。 Google ReaderにRSSを登録させておき、移動中はiPhone上のBylineでチェックして、気になった記事だけスターを付けていく。このスターは、後で読むという意味なので、移動中で時間がない時はじっくり読まずにスターだけ付けていく。タイトルだけでまず気になるものを選別すればいい。そして、帰宅後、時間がとれた時に、PC上のGoogle Readerでスターのついた記事を読んでいく。 さらにおすすめはブックマークに記録して後で検索しやすくすることだ。私ははてなブックマークを使っている。Google
妻子持ちITエンジニアが、家族から理解を得るには - かとじゅんの技術日誌
うちの会社は、1ヶ月に1回土曜に集まって社内LT大会をやっている。 なぜこんなことをやっているかというと、ITをプロとして仕事として生業にしていくには自己研鑽が必要だからだ。これは先のエントリにも述べた通りだ。自己研鑽といっても、発表の機会もないと勉強の機会がないので、社内LT大会をすることに決めた。(みんな直前になって資料を作成するなんとかしないとねぇ。当日、寝不足で死にそうになっているのはよくないw） これは休日開催なので、参加するにはいろいろと調整が必要。特に私のような妻子持ちはつらいところだ。かといって、大事なイベント。なんとか都合をつけたい。 そういう時は、きちんと家族に理解を求めている。「これだけは参加させてください。不況時代を生き抜くために必要なんです。」真剣にそういうことをいって理解を得るw また、お子さんがいらっしゃるのなら、お子さんにもなんで土曜なのに仕事にいくのか？と
プロジェクト管理で最低限気を付けたい３つのこと - かとじゅんの技術日誌
技術日誌といいつ、この手のエントリは書いた覚えがないが、最近、あちこちで、現場のリーダ格の人に対して「役に立たない」とか、「あれなら逆にいなくていい」とか耳にするので、少し考えてみる。話をよく聞くと、PMとかチームリーダの人は動いているが残念ながら結果が出せていないようだ。 その現場は以下のようなマネジメント上の問題があるようだ。 プロジェクトの現状把握が足りずに何がリスクか見えていない。 場当たり的で、計画がほぼない。 (PMが)進捗などの管理作業だけをやっている。 なるほどねー。こりゃ大変だｗ 自分が思うに３つの点が重要かな。と好き勝手書いてみるｗ プロジェクトのAs-IsとTo-Beの把握。 プロジェクト管理上のリスクの管理。 管理サイクルを回してチームとしての意志決定。 1番目は、どこからどこに向かう必要があるかを知ることから何もかもが始まる。プロジェクトの前提が必要。 2番目は、
そろそろ「好きだからできるんですよね」について一言いっておくか - かとじゅんの技術日誌
最近、というか前から「かとうさんって、ITが好きだからそこまで こだわってやれるんですよねー」といわれる。 洋書とか読んでると、「なんでそんなにがんばれるんですか」ってね。 そのことについて、そろそろ ガツンと言っておきますか。 ITは確かに夢もあって好きだが、仕事となると好きだけでは超えられない壁があると思う。それは、市場（顧客）から対価を得ることができるかということだ。技術者なら自分の持っている技術で市場に貢献して対価を得るということになる。つまり、売れる自分でないといけない。そうじゃないとお給料をもらってはならんと思っている。（当然、新人とか新しい仕事であれば見習いというので、ある意味市場から投資を受けている状態ですが、最終的には市場にお返しできなければならない） これはIT技術者だからというより、社会人としては当然のように意識すべきこと。自分がどういう風に成り立っているか足下もみな
設計と実装の両輪 - かとじゅんの技術日誌
自分がC/C++で飯を食っていた 2001年ごろに某ゲーム機メーカでお手伝いすることなり、現場にいた外注メンバーもできる人ばかり。その同僚からデザインパターンとかって耳慣れない話を聞く。コンボジットとか、デコレータ作ってみましたとかいってるｗ 意味わかんねーよ的な迷い子ｗ 帰宅後必死に調べる。そして、GoF本がしばらくバイブルとなり典型的なパターン厨となる。 新たな気づきとしては、オブジェクト指向言語の実装機能(カプセル化、継承、多態)を理解した程度では、複雑な要件を実装していくことは困難だと体感した。何が必要かというと、デザインパターンなどを加味した上でのオブジェクト指向設計の力。 設計と実装の両面での考え方が必要 実装力というのは、クラスのAPIをどのように使いこなすかであって、設計力というのはクラスの構造や関連をどのように構成するかを決める能力だと思っている。設計は戦略であり、実装は
文字列の結合をやるからといって、すぐにStringの+をつかってはいけない - かとじゅんの技術日誌
文字列の結合っていろいろなやり方があるのですが、みなさんはどんなやり方をされていますか？ String firstName = "Junichi"; String lastName = "Kato"; String fullName = ""; fullName += firstName; fullName += lastName; とか、もちろんやってないですよね？ ＋演算子ってわかって使わないとヒドイことになりますよｗ 性能をはかってみよう ちょっと、簡単に以下のような性能をはかるテストを書いてみた。 文字列の連結方式としては、 Stringの+演算子 Stringのcontractメソッド StringBufferのappendメソッド StringBuilderのappendメソッド が考えられるので、それらの性能をはかってみた。 package tests; import org
XMLとオブジェクトの変換をする方法 - かとじゅんの技術日誌
XMLファイルをプログラムからアクセスする方法をおさらいすると DOM SAX StAX といろいろある。 DOMとSAXとStAXと。 - 都元ダイスケ IT-PRESS このあたりを見てもらうとわかりやすい。 XMLにアクセスする場合は、だいたいはモデルに変換することが多い。上記にような低レベルAPIでないと細かい制御はできないが、もっと単純にXMLの要素をオブジェクトに変換する場合は以下のような高レベルAPIのような選択肢もある。 apache commons-digester JAXB digesterはライトウェイトで良さそうであるが読み込み専用ということなので、JAXBを少し触ってみた。JAXBはJava6からは標準APIとして搭載されている。 蛇足だが、configurationは設定ファイルを扱うライブラリもある。XMLも読み込める。ただし、独自に作成したモデルオブジェクト
例外の再考 - かとじゅんの技術日誌
愛する部下の一人がよいエントリを書いてくれたので、私も重い腰をあげてみたw Throwableについて本気出して考えてみた 2nd Season - 都元ダイスケ IT-PRESS 短時間で、ようまとめたなーw チェック例外は、Java以外の言語では聞いたことがないのですが。Javaが10年やってきて、これがベストプラクティスなら他の言語にも存在してもよいはず。なぜ使わないんだろう。。。ということで、例外を再考してみました。 例外をめぐる議論 何気にいろいろ調べていたら、こういうのがでてきました。2004年以降はRTE使っているよというのがこれか！？ Javaの理論と実践: 例外をめぐる議論 これはもう過去にされていた議論ですね。知らなかったですw Sunは、文書化されない例外は投げるべきでない。つまるところ、扱う例外はメソッドのthrowsにちゃんと明記する派。APIを使う側のユーザとし
sourceforge.jpにMaven2リポジトリを作成する方法 - かとじゅんの技術日誌
別のOSSプロジェクトを始めていて、Maven2のリポジトリが欲しくなりました。 sourceforge.jp上にMaven2のリポジトリを作成できると噂で聞いていたので、早速ぐぐってみたらid:tonocchiさんのブログ嫁でしたw mvn deploy ッてやったら、勝手にリポジトリを作ってくれるので、そんな面倒い物じゃないです。あと、前回のwebサイト航海用の設定が既にあるので、それらを転用します。こんな感じにpomに記述して、mvn deployすれば完了です。 <repository> <uniqueVersion>false</uniqueVersion> <id>website</id> <url>scp://shell.sourceforge.jp/path/to/repository</url> </repository> どこまで使えるのかわかりませんが、なるべく自前の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
