八割の動詞 - Backnumbers: Steps to Phantasien
PC は忙しい時ほど壊れる. 先週は職場の PC にこの経験則が降りかかった. 頻繁にフリーズしはじめる VisualStudio 2008. VS 単体での修復では問題が直らず困り果て, 結局 OS から入れ直す羽目に. まあディスクが故障しなかっただけ幸いだと思おう... OS の入れ直しは生活習慣を見直し悪習を捨てる機会でもある. 私の Windows 生活で最大の悪習は cygwin だ. ホスト OS への敬意を欠く cygwin には以前から後ろめたさを感じていたが, 惰性でずるずると使い続けていた. 今回のトラブルは良き市民たれという神(シアトル在住)の思し召しかもしれない. 啓示に耳を傾け, しばらく cygwin なしでがんばってみたい. PowerShell cygwin を捨てるということはシェルを乗り換えるということだ. いま Windows 民の間でホットなシェル
一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選 - 設計と実装の狭間で。
10万行コード読んだらJava分かるよってTwitterに書いたらすげぇ勢いでRTされたので、調子に乗って捕捉エントリ書くよ。 Java Core API JDKインストールしたディレクトリに入ってるsrc.zipを展開すると入ってるから読むと良いよ。 すぐ近くにあるのから読むってのはメンタル的に楽でいい。 厳密にはOSSじゃなくて単に公開されてるってだけなんだけども、JavaプログラマなのにコアAPIのコード読んでないとか無いよね？ どれから読めば良いか分からんかったら、 java.lang java.util java.io java.text 辺りをまずはキチンと理解すること。当然コードを読み終わったら、それを使ってコードを書く事。 OpenJDK http://hg.openjdk.java.net/jdk7/jdk7 OpenJDKを読むことで、プログラム言語してのJavaではな
Javaパフォーマンス計測 そんなタイマーで大丈夫か？ - プログラマーの脳みそ
駄目だ。大問題だ。 long t1 = System.currentTimeMillis(); long t2 = System.currentTimeMillis(); System.out.println(t2-t1); 結果はなんとでるか？ 99.9%以上の確率で0が表示される。そもそもSystem.currentTimeMillis()は時刻をミリ秒で返す。1行のプログラムを実行するのに1ミリ秒もかかってたら、たかだか1000行分動いただけで1秒かかってしまう。今のコンピュータはそんなに遅くない。 そもそもドキュメントをちゃんと読むと ミリ秒で表される現在の時間を返します。戻り値の時間単位はミリ秒ですが、値の粒度は基本となるオペレーティングシステムによって異なり、単位がより大きくなる場合があります。たとえば、多くのオペレーティングシステムでは、時間を 10 ミリ秒の単位で計測します
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
Java Advent Calendar -ja 2010 おまけ - cactusman日誌
id:shuji_w6e さんのご紹介をうけて。 Java Advent Calendar -ja 2010 が25日を過ぎてもなぜか続いているようですが、まぁ、おまけということで軽い内容にします。 ご紹介するものは、JGitです。 JavaのGitライブラリとGitクライアント、サーバなどを含むプロジェクトです。 http://eclipse.org/jgit/ EclipseのIncubationフェイズのプロジェクトで、EGitとは兄弟プロジェクトになります。 あっちのほうは、Eclipse Pluginになります。 で、JGitの何が良いかと言います、Pure Javaなところです。 そのため、JGitのCUIツールはJavaさえあればWindowsでも動きますし、ライブラリとしてJavaやJVMで動作する言語と混ぜて使うのも難しくないです。 EclipseがGitリポジトリに移行
Javaのメソッド名によく使われる単語・接頭辞 - 地平線に行く
Javaの標準API（java.*, javax.*）に含まれるメソッド名を分析して、よく使われている単語や接頭辞を抜き出してみました。 これで、もうメソッド名を決めるのに迷わない！はず…。 接頭辞 順位 単語 意味 代表例 出現回数 1 get 取得する List#get() 21198 2 set 設定する List#set() 8197 3 is 〜かどうか List#isEmpty() 4373 4 remove 取り除く List#remove() 2403 5 add 追加する List#add() 2213 6 create 作成する URI#create() 853 7 paint 描画する Component#paint() 731 8 update 更新する Component#update() 573 9 contains 含んでいるか List#contains()
単体テストを“神速”化するQuick JUnitとMockito
単体テストを“神速”化するQuick JUnitとMockito：ユカイ、ツーカイ、カイハツ環境！（16） Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション（CI）によるテストの自動化や、テスト駆動開発（TDD）の普及などにより、ユニットテスト（単体テスト）のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
きちんと準備しなきゃ機能テストツールを使ったってテスト自動化は楽になりませんよ - nemuzukaの「明日から本気出す」
Javaで作られたWebアプリケーションをテストする際に、MVCモデルで言うところの、「M」部分はJUnitでテストクラスを作成して、継続的にテストし続けると幸せになれるよ、というのは一般的になってきていると思います。 「V」「C」部分もMockフレームワークを使用することである程度テストクラスは書けますが、結局ブラウザからの打鍵でやらないと最終的に確認できないことが多いわけです。 ブラウザからの打鍵テストを手動で実施する場合、画面に変更がある度に実施しなければならないことから非常に効率が悪く思われがちです。ある機能を変更した際に、他の機能にも影響を及ぼしていないかを確認する回帰テストだって、そのシステムで取りうる全てのパターンを手動でテストするには手間がかかりすぎますし、不毛な作業のように思われます。というわけで、影響がありそうな箇所を経験と感で洗い出してテストするのですが、洗い出し項目
Mockitoノススメ テストスタイルの変化 - Fly me to the Luna
Mockitoを使うようになってから、僕はテストコードへの取り組みが変わりました。Mockitoを使うまで僕がUnit Testと思っていたものは、厳密にはUnit Testじゃないんじゃないか、と思うようになりました。なぜかというと、実装コードを書いていくと、たくさんのクラスと関連していきます。だんだんと、そのクラス、Unitをテストするのではなく、そのAPIの裏にあるクラスの状態、振る舞いも予測しなければならなくなっていきます。例えば永続化層にアクセスするクラスを開発しているのであれば、どんなに上層にあるレイヤーのクラスでも、テストデータをDBに入れないといけない、というのは、よくよく考えてみると、変な話なのです。どこかの段階で、DBを操作するクラスを参照しなくなるはずですから。大体、リズムが悪いですよね。DBの初期化用のテストデータ用意するのは大変です。 Unit Testでは、テス
[Java]Javadocを印刷したい - 新・たけぞう瀕死の日記
まあ正直Javadocは印刷してどうこうするものではないと思いますが、やんごとなき事情により印刷したいケースというのもあるわけで、そんなときのためのツールとしてPDFDocletというものを教えてもらいました。 http://pdfdoclet.sourceforge.net/ その名の通り、JavadocをPDFとして出力するDocletです。すべてのJavadocが1つのPDFファイルに出力されるので、できたPDFを印刷するだけで済むというシロモノです。 Antで使う場合はこんな感じで。 <javadoc doclet="com.tarsec.javadoc.pdfdoclet.PDFDoclet" docletpath="pdfdoclet-1.0.2-all.jar" classpathref="classpath" additionalparam="-pdf javadoc.pd
![[Java]Javadocを印刷したい - 新・たけぞう瀕死の日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
2010-03-17
書店でもパラ見していたのですが、翔泳社さんより献本いただきました。 著者の方には怒られてしまうかもしれませんがw、本書の見所はなんといっても100ページ以上もある付録でしょう。トラブルシュート時に使用可能な様々なツールの使い方がまとめられています。この章だけでも充分に価値のある一冊だと思いました。 本文のほうは、システム開発の一般教養として読んでおくべきもの、という印象を受けました。まあこういう教養が欠けているからトラブルシュートしないといけないハメになるわけですが…。 読み物として読むこともできますし、流行り廃りに左右されるようなものでもないので、読んでおくといざというとき役に立つはずです。Java開発者は読んでおいて損はない一冊ではないでしょうか。 Tomcatなど通常のServlet/JSPコンテナ上で動作するニコニコカレンダー 1.0.2をリリースしました。今回のバージョンでの追加
【ハウツー】Javaのビヘイビア駆動開発をやさしく現する"easyb"を試す (1) ビヘイビア駆動開発、そしてeasybとは? | エンタープライズ | マイコミジャーナル
本稿では、Java向けのビヘイビア駆動開発(Behavior Driven Development: BDD)フレームワークであるeasybを簡単に紹介する。 「ビヘイビア駆動開発」という用語になじみのない方のために簡単に説明すると、「ソフトウェアを書く前に、その仕様をコードで書く」という開発手法である。対して、皆さんおなじみの「テスト駆動開発(TDD)」は、「ソフトウェアを書く前に、そのテストをコードで書く」という開発手法だ。 この2つの開発手法は、「プログラムを書く前に、そのプログラムが正しく動くことを保証するためのコードを書く」という点ではまったく一緒だ。保証するためのコードもかなり似通ったものになる。ただし、TDDのコンセプトは「テスト対象のものがないのにテストを書く」というもので、あまり直観的とは言えない。対してBDDは、「仕様通りに動くことを保証するために、検証コードを先に書く
私がJavaのバイトコードをJavassistで操作する時
最近、既存コードのテストコードを書きまくっています。 その中で、Easymock(classExtension)などを用いてMock化している場合に、 finalクラスをMock化できず困っていました。 何かいい方法がないかなと思っていたらhudsonの開発者である川口さんが jaavassistを利用してfinalを除去しているという記事があり、 なるほどと思って自分もその方向で対応を行うことにしました。 その際に「なぜテストを書くのか」「どうしてそんな書き方をするのか」 ということを色々考えていたので、簡単に脳みそを整理してみます。 バイトコードが使われるとき 主にフレームワーク内部やIDEで利用されている技術と聞いています。 つまり大多数の一般的な開発者には使われないという認識です。 なぜテストにおいてバイトコード操作やリフレクションを使うのか 私の主観としては、リフレクションやバイ
非対話的デバッガ YouDebug - 川口耕介のブログ
バグ修正はプログラマの仕事の一つですが、このうちのかなりの時間は問題を再現することに費やされます。 症状からバグの全容が推察できる時もあるのですが、多くの場合には、手元で問題を再現し、更なるデータを集めることによって始めてバグが理解されるからです。しかし、環境に依存する問題などは再現が難しい場合もあります。どうしたらよいでしょうか。 ロギングというのがよく行われる解決・予防策ですが、「デバッガを走らせて変数xの値を教えてくれればいいのに！」と思った事があるのは私だけではないと思います。ロギングと異なり、デバッガは予めプログラムに障害発生を予期するコードを埋め込んでおく必要はありません。また、呼び出し元のローカル変数をアクセスしたり、任意の式を評価したり、あるいは変数の値を変更することもできてしまいます。当たり前ですが、障害分析ツールとしてはデバッガはずっと強力だからです。 ではなぜユーザー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
