Coderetreat in KIT を開催しました - Fly me to the Luna
2014/05/31に金沢工業大学でCoderetreatを開催しました。 今回は大学ということもあり、学生さんが多いと見込み、いつものCoderetreatとは異なる形で開催しました。 テーマは「楽しくプログラミング！」 想定していた以上に1,2年生の学生さんが多く、大丈夫か？？と思ってたんですが、みなさん優秀でした。プログラミングの本を持ち込んでる子も多く、言語を学び、学んだことを生かしつつ次に行けたんじゃないでしょうか。学生さん、社会人の別け隔てなくプログラミング。みなさんほんとうに楽しそうに過ごせてよかったです。 当日の導入資料 工夫したこと ライフゲーム以外の課題を用意した ライフゲームって相当奥深い課題なので、あれはとてもいい課題なのだけど、取っ掛かりが相当大変で、プログラミングと言うのは難しいものだ、と思われてしまうと悲しい。ということで、初心者でも45分で解ける課題としてう
Continuous Modeling - Fly me to the Luna
みなさまご無沙汰しております。僕はここの所、残業はしないまでも毎日クタクタになるほど忙しい毎日を過ごしています。どんな仕事か一言でいうと、あるプロダクトのアーキテクチャを刷新するお仕事です。今までできなかったあれやこれやを実現するために、既存のアーキテクチャを改善したり、作りなおすお仕事です。今はまだ始まったばかりで、方針を決めるために、既存のアーキテクチャ上に機能拡張してみて問題点を調査したり、どう改善するのか方針案を考えたり、実際に改善案を少しずつやってみたりしています。 このプロジェクトは、それほど大所帯ではないですが、他の会社のエンジニアさんも加わるなど、結構スキルセットがバラバラです。そのため、久しぶりにペアプロで作業を回しています。1日じゅうペアプロすると、一日の終わりの頃には頭がクタクタです。久しぶりです、この感覚。楽しい。 さて、既存のアーキテクチャを見ていくと、10年以上
Mockitoノススメ - Fly me to the Luna
モックライブラリ使ってますか? 僕はJavaの人なので、主にJUnitを使ってテストコードを書いています。テストコードを書いている最中、「もしこのオブジェクトから例外が帰ってきたら、ちゃんと例外のハンドリングができてんの？」等々、既存のオブジェクトの振る舞いを差し替えたくなることってありませんか？そういうときにモックライブラリを使うと、既存のオブジェクト処理を差し替える事ができます。 実は最初はモックライブラリって意味あるの?と懐疑的だったんです。どういうところに懐疑的だったかというと、 テストコード中に出てくるモックライブラリのセットアップがめんどい。 テストコードがプロダクトコードの実装に依存しちゃうんじゃないの？プロダクトコードをちょっと変えただけでテストが落ちるようになるんじゃないの？ みたいなところです。でもMockitoというモックライブラリを使ってテストコードを書き初めてから
Jenkins Maven Repository Server Pluginが簡単すぎて鼻血でた。 - Fly me to the Luna
Maven3になり、Eclipseプラグインも安心してビルドできる、ってのもあって、最近Mavenでビルドする事が増えてきています。JenkinsでCIを回してるんですが、別立てでApacheを立てたりするの面倒じゃないですか。で、そういうのを解決するプラグインないか探してみたらありましたわよ奥様。 Jenkins Maven Repository Server - Jenkins - Jenkins Wikiでございます。 使い方は簡単です。Jenkinsのプラグイン管理画面からJenkins Maven Repository Serverプラグインをインストールすると、あら不思議。 [JenkinsのURL]/project/repository/everything の下にJenkinsでビルドしている成果物全てのMaven Repositoryができているではありませんか。例えば先
assertion養成ギプスを作ってみた - Fly me to the Luna
ちょっと前、id:t-wadaさんらがtogetterで「デフォルトでテスト成功にするという JUnit の設計判断とその功罪について」っていうテーマでいろいろつぶやかれてましたね。 http://togetter.com/li/138798 あったら便利かもしれないので、assertion養成ギプスをjavaagentとして作ってみました。 http://kompiro.org/maven/junit/extensions/quick/training.assert/0.0.1/training.assert-0.0.1.jar Eclipseだと、プロジェクトの直下に上記のJARを配置し、VM Argumentsに下記のように「-javaagent:training.assert-0.0.1.jar」と加え、 javassit 3.12.1に依存しているため、それもダウンロードしてクラ
本物のエバンジェリストとは - Fly me to the Luna
平鍋さんから声をかけられ、Linda Risingさんが日本に滞在している間、付き人をさせていただきました。僕はLinda Risingさんは平鍋さんの師匠であり、Fearless Changeの著者のお1人だと言うことは存じていましたが、パタン・プリンセスと呼ばれていることを存じてませんでしたし､世界的に活躍されているコンサルタントだと言うことが、どういうことなのか、良く分かってませんでした。それはどういうことなのかというと､ 先週末にはポーランドのJavaのカンファレンスに招かれて出席し、一度アメリカの自宅に戻ったものの､すぐ日本に移動し、Agile Japan 2011の懇親会に出ずに自宅へ帰らなければならないほどお忙しい人 なのです。僕は1ヶ月に3､4回は飛行機に乗って世界各国を飛び回るのが当たり前の人と行動を共にしたことはありません。そんな方を空港へ迎えに行ったり､ホテルまでお見
Test Doubleを使うとテストの信頼性/保守性が下がるのか？ - Fly me to the Luna
最近はユニットテストを行うテストコードにおいて、Test Doubleを多用してます。Test DoubleとはMockとStubを合わせた総称です。Test Doubleを用いると、信頼性や保守性が下がると言われることがあります。しかし、それはTest Doubleの用法を誤っているためではないかと僕は思うのです。Test Doubleの用途はユニットテストのスコープをテスト対象のクラスに限定するために用いるべきものです。実感として、Test Doubleを使っているからと言って、ユニットテストの信頼性/保守性が下がったとはあまり感じていません。 良く誤解されていますが、Test Doubleはスローテスト問題を解決するための手段ではありません。Test Doubleをうまく利用すれば、結果的にスローテスト問題を解決できます。しかし、スローテスト問題を解決するための手段ではないのです。ス
5分でEclipse PluginをGroovyで書くよー。 - Fly me to the Luna
ぼーっとしていたらEclipse PluginをGroovyで書いてました！他のJVM言語でもEclipse Plugin書けるんです！ Eclipseはe4プロジェクトでJava以外の言語(例えばJavaScript)でもPluginの実装を実現しようと頑張ってますが、なんか3系でもできちゃった。 必要なもの(環境) JDK 6 Eclipse for RCP and RAP Developer Groovy Eclipse を上記Eclipseにインストール こっからはほぼ画像ペタペタ貼っているだけです。この通りに作業すれば同じようにプラグインが作れます。 ほいじゃ、実際に作っていくよー。 まずGroovyプロジェクトを作るー プロジェクト名は「 eclipse-plugin-by-groovy 」って作りました｡ GroovyプロジェクトをPluginプロジェクトにコンバート MAN
@Ruleは素晴らし。 - Fly me to the Luna
@Rule。このアノテーションは、あまり知られていないようですが、ヤバいです。このアノテーションが追加されたのは4.7からなので結構古いのです。@Ruleのうれしさは、カスタムで作られているRunnerをほぼ置き換えられる、ということを言われていました。ただ、僕はあんまり使った事がなかったですし、周りでも使っている話はあまり聞いた事がありません。でも、使ってみて非常に便利だと感じました。 例えばTemporaryFolderを利用して作成されたファイルは、テストの終了時に自動的に削除されます。ちなみにTemporaryFolderの使い方はこんな感じです。 public static class HasTempFolder { @Rule public TemporaryFolder folder= new TemporaryFolder(); @Test public void test
いよいよEclipse3.6(Helios)がやってくる。 - Fly me to the Luna
後数時間でいよいよEclipse3.6(Helios)がやってきます。(ただいまFriends of Eclipse権限でダウンロード中)今回のリリースでは、39個のプロジェクトが同時リリース。そして初めてe4も同時にリリースです。e4については、後日レポートします。(がんばる)簡単に触れると、e4は、Eclipseの次期バージョンを目指し、開発が進んできたIDEです。Eclipse Platformの開発にて、初めてコミュニティが主体になって進めてきたプロジェクトです。新たな開発プラットフォームとなるべく開発が進んでいます。Eclipse 3系の中心のorg.eclipse.uiはかなり巨大なBundleに成長してしまいました。その中でも特に重要なクラスであるWorkbenchクラスの実装コードは5000行(!)近く、改善を加えるにも結構限界があったんではないか、と思われます。e4では「
QConTokyo 2010に登壇させていただきました。 - Fly me to the Luna
QConTokyo 2010に登壇させていただきました。InfoQの翻訳業をする傍ら、このネタがQConにないのはもったいない、と直談判してお話させていただいたのが真相なので、他のスピーカーとは毛色が違います。でなければ、自分が登壇できるはずもないイベントですから。すいません。 どうせデブサミと同じネタだろ、と思ってPaul KingさんのGroovyの話を聞きに行ったみなさま。僕も聞きに行きたかったです。でもすんません。6割は資料が変わってます。そして写真ばかりです。Presentation Zen厨になって話してきましたので、もしかすると資料では伝わらない部分が多いかもしれません。でも最初眠っていたお父さんも、途中から聞き入る全113枚+質問コーナ。プレZenすごい。 Javaにおけるモジュラリティ元年View more presentations from Hiroki Kondo.
TDD Boot Campでコーチ役やらせていただいた。 - Fly me to the Luna
12/19に行われたTDD Boot Campに参加してきました。前もってid:t-wadaさんからコーチ役のお願いをされたのですが、当日id:agtさんがスカウトされていました。cacooの開発者の方です。そしてMobster Eclipse Pluginの開発者でもあります。そんな方とコーチ業です。勉強にならないはずがない。でも悲しいかなコーチ業。id:agtさんのコメントを聞けないorz。 今回自分はQuick JUnitメンテナということもあり、id:ebackyさんからeclipseの推奨環境を聞かれたので、「こういう環境作ってね」というお願いをするのもよかったんですが、TDD Boot Camp用にカスタマイズしてみました。 「t」アイコンはテスト結果をtwitterにつぶやく機能を有効/無効にするやつです。当日参加者の方にはテスト結果をできるだけつぶやいていただきました。後で
TDD、TDDと言うけれども。TDDのダークサイドについてそろそろ一言語ってみる。 - Fly me to the Luna
id:t-wadaさんの話の中で、TDDが品質を保証するわけではない、という話があったんですが、それについて私見をつらつらと。ちなみに自分は2年くらい仕事でTDDをやってきました。 やってきた中で下記のTDDの利点を感じることができました。 その時に気づいた最もシンプルなコード、クリーンなコードができる テストコードからコードを書く、と言うのはプロダクトコードの利用方法が考えられるのでとても有効に作用します。id:t-wadaさんもリファクタリングが一番重要と話されていましたが、テストコードがあれば安心してリファクタリングができます。 より高い品質のコードが書けるようになる これはt-wadaさんの話の中でもありましたね。なぜかと言うと、プロダクトコードが実行される時の前提条件を知ろうとすると、結構いろいろなコードに目を通すことになります。コードに目を通すことで優れた先人の知恵を見つけるこ
ソフトウェア開発の不思議 - Fly me to the Luna
なぜよくあるソフトウェア開発ではきっちり要求を聞いて、かっちり仕様を決めて、その通りにカチカチに固めた開発をしようとするんだろう。 例えばなんですけど、僕がプラモデルをくみ上げるとき、最初から一つ一つきっちり部品を組むと必ず失敗していました。自分が不器用なことももちろんあるのだけれども、間違った部品をはめてしまって外すのに苦労した、なんて思い出ないですか？なのでそのうち最初は緩めに組んでおき、全体的に固まってきたらちゃんと組むという手順が効果的だと気づき、そうするようになりました。世の中ではこれを仮組みって呼ぶらしいです。 いや仮組みくらい、だれだってやってると思うんですよ。最初からうまく作ろうとしたってうまくいかないわけですから。 この「最初からうまく作ろうとしたってうまくいかない」という教訓はソフトウェア開発にも当てはまるって、いろんなプロセスで繰り返し語られているわけですけど、どうも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
