VOYAGE GROUP　エンジニアブログ

すでに三が日も過ぎましたが、あけましておめでとうございます。CTO 小賀(@makoga)です。
 昨年に引き続き、今年も年の初めは振り返りと抱負でいきたいと思います。


2011年の振り返り

昨年は若手エンジニアが書いた下記エントリが一番PVおよびブクマを稼ぎました。ブクマが1,000を超えたのでお祝いにAJITOで軽いパーティーも行いましたｗ

• 自分の周りに居る凄腕プログラマーが実際に読んでいる本

その他ではRailsやSymfony2などのフレームワーク系のエントリが人気がありました。

• Rails(Web)アプリケーションのセキュリティ(パスワードハッシュstretch編)
• Rails(Web)アプリケーションのセキュリティ(ログファイル編)
• Symfony2のススメ1 ～認証とともに～
• Symfony2のススメ1.5 ～コンポーネントちょい話～
• Symfony2のススメ2 ～認証とともに～

また、下記は一昨年に続き、昨年も検索エンジン経由でよく読まれました。

• あなたにも今日こそPerlの文字化けが理解できるたった一つの原則
• iPad で「妄撮」をやってみました。
• MySQL InnoDBでのネクストキーロックの落とし穴

一部の読者に人気のネタ系エントリでは後半のエース@Akiyahがアンパンマン3部作など良エントリを連発。：）

• Rを使ってお絵描き（アンパンマン）、Rを使ってお絵描き（アンパンマン3D）、MacのGrapherでアンパンマン
• グレートナビック風を動くようにした
• VOYAGE WiMAXボーイ(36才)をぷにょっとさせた

VOYAGE GROUP内では新卒エンジニアが書いた下記エントリも好評価でした。

• 「新卒エンジニアがこのさき生き残るには」

※VG内エンジニアから「この先生きのこる、にしない理由が分からない」 という声もありましたが、本人曰く「あえてしなかった」ということでした。

最近ではVOYAGE GROUPの代名詞にもなっている(?)勉強会関係のエントリも多くありました。

• VOYAGE GROUP　エンジニアブログ : 勉強会
• VOYAGE GROUP　エンジニアブログ : presentation
  
• VOYAGE GROUP　エンジニアブログ : イベント

2012年の抱負

昨年後半からVOYAGE GROUPは新しい技術にもより積極的に挑戦しています。Node.js, Sencha Touch, PhoneGap, MongoDB, Erlang, Behat, Rails3, Amazon Elastic MapReduce, etc.
今年はこれらの技術を使ってサービスを構築した際に得られたノウハウを順次このブログで公開していきたいと思います。

また、技術系の話だけではなく、サービス作りについての話も企画しています。
昨年末から今年にかけてリリースが続いたこともあり、面白い内容にできそうで今から楽しみです。

もちろん、昨年に引き続き、一部の方に好評なネタ要素が高いエントリも比率を落とさないように気を配りたいと思います。

本年もよろしくお願い申し上げます。

こんにちは、VOYAGE GROUPの水越(@Akiyah)です。

皆さん、デザインミニ塾というイベントを知っていますか？
デザインミニ塾とは産業技術大学院大学でほぼ毎月開催されているデザインに関する勉強会です。
塾と言っても申し込みをすれば誰でも無料の、毎回デザインの分野で活躍している方を呼んで講演をしていただくという形式の気軽に参加できるイベントです。

私はエンジニアなのですがデザインにも興味があるので、異文化交流と言う意味でもこのデザインミニ塾を2010年頃からちょくちょく見に行っています。大好きで毎月楽しみなイベントです。
思い返してみると2011年末現在までの約2年間で15回参加したようです。

先日、社内勉強会でエンジニアやデザイナー、そしてUX(ユーザーエクスペリエンス)に興味がある人を集めてデザインミニ塾の紹介を行いました。デザインミニ塾の開催案内pdfファイルを見ながら私が印象に残った話を語ると言うスタイルで、質問や意見が出て盛り上がりました。

その社内勉強会のときにまとめた資料があるので、再編集してこのブログにのせます。エンジニア目線で面白かった回をピックアップしました。

---

第6回
「医療安全への終わりなき挑戦」
～ ヒューマンファクターとインタフェース ～
自治医科大学医学部メディカルシミュレーションセンター教授
河野 龍太郎 氏

この第6回がはじめて参加したデザインミニ塾なのですが、自分の中ではデザインミニ塾で一番良かった回です。
『実務入門 ヒューマンエラーを防ぐ技術』という本の編集者でもある河野 龍太郎 氏の講演で、ヒューマンエラーが起こるわけと、その原因となるインターフェース上の問題を、医療現場、航空機、管制塔、原発などの事例を豊富に紹介していただきました。

B = f(P,E)
B : Behavior（行動）
P : Person（人）
E : Environment（環境）

という式をつかって、行動は人と環境を入力とする関数の結果であり、ヒューマンエラーを人のせいにせず、そのエラーを引き起こした環境に原因があると認識して改善すると主張されています。デザインミニ塾なのに工学やシミュレーションがリスク回避にとても大切だとエンジニアの大切さを主張されていたのが印象的です。

これに近い回では『第24回「ユーザを中心としたものづくり」人間中心設計への取組』で講演された、株式会社 U'eyes Design の鱗原氏のブログである使いやすさ日記もデザインの善し悪しを冷静にマルバツつけていてとても参考になります。

---

第10回
「公共交通とサイン」
アール・イー・アイ株式会社代表取締役
中村 豊四郎 氏

地下鉄の案内のデザインを行った方の講演です。デザイナーの仕事は華々しいものだとイメージしていたのですが、フォントの性能の測定や配色の視認性の実験など、工学的で地道な作業を聞いて案外エンジニアと似ているんだなと思いました。
普段何気なく接している公共交通の案内図などですが、こういうところにデザイナー達の働きが隠されているのですね。

---

第16回
「デザインの力を生かすＬＧの戦略（仮）」
LG Electronics Inc. デザイン研究センター HEB デザイン研究所 常務
洪 思允 氏

LGやサムソンと言った韓国の電機メーカーの名前はもちろん知っているのですが、日本の大手の電機メーカーと比べ物にならないくらいデザインに力を入れていると言う事を聞き、衝撃を受けました。同様の事を『第25回「日本のデザインにまだアドバンテージはあるか？ 〜アジアの国々の取り組みと比較して〜」』でも聞いたので、改めて日本以外の国のデザインへの強い取り組みを感じることができます。

---

第18回
「カラーユニバーサルデザインをはじめとするUD デザイン活動のお話し」
(株)武者デザインプロジェクト 代表取締役/UDソーシャルデザイナー
武者 廣平 氏

カラーユニバーサルデザインの講演です。私は色彩も好きなのでとても興味深い回です。日本人男性の場合は色覚特性がC型以外のP型やD型の人（いわゆる色弱の方ですが、色覚特性と表現されます）が20分の1もいる事を知り、この話を聞いてからP型D型の人が見づらいかもしれない単純な赤を使う事ができなくなりました！（その代わりに少し青が混じったオレンジを使ったりします）

---

第19回
「「共感」から発想するデザインコンセプト～オブザベーションのご紹介」
株式会社インフィールドデザイン 代表取締役
佐々木 千穂 氏

相手に共感してデザインするオブザベーションという手法とともに、『私は三年間老人だった 明日の自分のためにできること』という本を紹介していただきました。26歳のデザイナーが老婆の特殊メイクをして街に出てみたら、若い自分が受けているのと全く違う対応を社会から受けるという衝撃的な本です。
相手に共感すると言うのはこういう事か、と同時にここまでしないと立場の違いはわからないのか、とショックを受けました。

---

第21回
「異文化市場のお客さんの頭の中を探ろう ローカリゼーションマップの試み」
モバイルクルーズ株式会社代表取締役
安西 洋之 氏
テツタロウデザイン代表
中林 鉄太郎 氏

ローカリゼーションマップという概念についての回です。地域毎の考え方や文化の違いの事をローカリゼーションマップというようです。例えば女性がコンビニに行くとき、日本人なら日焼け止めクリームや乳液、フランス人なら香水、アメリカ人ならアイメイク、と言った違いがあるのだそうです。その他にもメキシコではマルちゃんが国民食として、メキシコの食材とあわせて調理して食べられているというローカリゼーションマップの成功例も紹介されました。これらは『「マルちゃん」はなぜメキシコの国民食になったのか？ 世界で売れる商品の異文化対応力』という講演された安西氏と中林氏の本でも紹介されています。

---

さて、いかがでしょうか。興味が出てきた方もいるのではないでしょうか。
実は参加するにはpdfにかかれているメールアドレスにメールを送らないといけないのですが、デザインミニ塾の次回の予定は産業技術大学院大学のトップページにお知らせが書かれてから知る事ができるという、すこしややこしい方法なのです。興味がある方は次回から申し込みでくじけずにぜひ参加してみてください。

こんばんは。VOYAGE GROUPの野良クルー、@katzchangです。

ところでみなさん、バルスしてますか？

バルスとは滅びの言葉、つまりおまいらに解かりやすく言うと、異常系処理をキックするコマンドなわけです。で、やはり、異常系処理も含めてテストされるべきですよ。当然ですね。

ということで、テスト駆動開発、いわゆるTDD"風味"で、バルスのJava実装を作ってみました。とはいえ、要するに System.exit(1) すればよいので、実装は大したことがない。でも、実際にどのような動作になるか、あまり試したことがないのは僕だけじゃないはず。試す価値はありそうです。

方針としては、balseメソッドを実装したBalsableクラスを用意し、システムが無事に異常終了することを確認すればよいということにします。

さて、いきましょう。

package balse;

import static org.junit.Assert.*;

import org.junit.Test;

public class BalsableTest {

	@Test
	public void test() {
		new Balsable().balse();
		fail();
	}

}

テストコードはこんな感じ、new Balsable().balse();を実行すると、次のfail();が実行されないはずです。そうです、このときはそう信じていました………。alt + shift + x, t。



よし、Gre……………y……？

なんと、JUnit test runnerがバルスしてしまいました。バルスマジバルス。

仕方がないから、外部プロセスとして実行し、結果を確認することにします。方針転換ってやつです。

こんな感じにテスト用のランナーを用意し、

package balse;

public class BalsableRunner {
	public static void main(String...args) {
		new Balsable().balse();
	}
}

外部プロセスとして実行させます。

@Test
public void testBalsableProcess() throws Exception {
	ProcessBuilder pb = new ProcessBuilder("java",
			"-classpath", "./target/test-classes;./target/classes",
			"balse.BalsableRunner");
	Process p = pb.start();
	assertThat(p.waitFor(), is(1));
}

今度はGreen。ちゃんとバルスできています。

ところが、ここで心配になりました。このバルスは、ちゃんとプロセス全体をバルスしているのでしょうか？マルチスレッドでも問題なくバルスるのでしょうか？

そう、不安があったらテストしましょう。

マルチスレッドを使ったテスト用ランナーを用意し、それをテストします。今度はリターンコードだけではなく、スレッドが実行されていることを確かめるべく、標準出力の内容も検査することにします。

@Test
public void testBalsableThread() throws Exception {
	ProcessBuilder pb = new ProcessBuilder("java", "-classpath",
			"./target/test-classes;./target/classes",
			"balse.BalsableThreadRunner");
	Process p = pb.start();
	assertThat(p.waitFor(), is(1));

	// TODO: helperを作るべき
	InputStream is = p.getInputStream();
	BufferedReader br = new BufferedReader(new InputStreamReader(is));
	String line;
	List<String> lines = new ArrayList<String>();
	while ((line = br.readLine()) != null) lines.add(line);
	is.close();

	assertThat(lines.size(), is(2));
	assertThat(lines.get(0), is("時間だ！！答えを聞こう！！"));
	assertThat(lines.get(1), is("バルス！"));
}

はい、Green。標準出力の内容も意図通りのようです。

他のコードも含めて https://github.com/katzchang/balse にコミットしていますので、煮るなり焼くなり好きにしてください。

これを他のプロダクトに組み込む場合、直接System.exit(1)を呼ぶより、Balsableを通して呼ぶように変えることができます。そのときのテストとしては、MockBalsableを用意し、モックのbalse()メソッドが呼ばれたことを確認すれば、プロダクトへのバルス実装は完了です（Balsableにももう少し手を加える必要はあります）。そして、end-to-endテストとして実際にBalsableを組み込んだ上でバルスしていることを確認できれば、出荷可能です。

さて、この記事はTDD Advent Calendar jp: 2011の10日目の記事でした。

9日目の記事は@yujioramaのC言語でもレガシーでも、TDD をやってやれないことはない(レガシーコード改善成分90%、TDD成分10%)、明日は大学でテスト駆動開発プロセスを研究してる@pocketberserkerです。きっと読み応えのある記事を書いてくれることでしょう……！！

純粋なTDDではないけど、まぁこんな感じで進めてますということで…。