月別アーカイブ: 2012年12月

Backbone.js:別ファイル定義のViewではelの定義にjQueryオブジェクトを使ってはいけない

ちょっとはまったのでメモ。

こんな感じで別ファイル定義のViewの中で、elの定義に$(“#id”)なjQueryオブジェクトを使うと、うまく動きませんでした。

var MyView = Backbone.View.extend({
  el : $("#id"),
  ...
});

どうしてダメかは何となくはわかりますが、ちゃんと調べてないです。

回避策

jQueryオブジェクトではなく、セレクターを使う。
Viewをインスタンスを作成するときにjQueryオブジェクトを渡す。

サンプル

	<!DOCTYPE html>
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<title></title>
	<script type="text/javascript" src="http://code.jquery.com/jquery-1.8.3.js"></script>
	<script type="text/javascript" src="underscore-1.4.3.js"></script>
	<script type="text/javascript" src="backbone-0.9.9.js"></script>
	<script type="text/javascript" src="hoge.js"></script>
	<script type="text/javascript" src="foo.js"></script>
	<script type="text/javascript" src="bar.js"></script>
	<script type="text/javascript">
	$(document).ready(function () {
	new Hoge({});
	new Foo({});
	new Bar({ el: $("#bar") });
	});
	</script>
	</head>
	<body>
	<div id="hoge"></div>
	<div id="foo"></div>
	<div id="bar"></div>
	</body>
	</html>

view raw

index.html

hosted with ❤ by GitHub

	/// <reference path="http://code.jquery.com/jquery-1.8.3.js"/>
	/// <reference path="backbone-0.9.9.js" />
	var Hoge = Backbone.View.extend({
	el : $("#hoge"),
	initialize: function(){
	this.render();
	},
	render : function(){
	this.$el.text("hoge");
	}
	});

view raw

hoge.js

hosted with ❤ by GitHub

	/// <reference path="http://code.jquery.com/jquery-1.8.3.js"/>
	/// <reference path="backbone-0.9.9.js" />
	var Foo = Backbone.View.extend({
	el : "#foo",
	initialize: function(){
	this.render();
	},
	render : function(){
	this.$el.text("foo");
	}
	});

view raw

foo.js

hosted with ❤ by GitHub

	/// <reference path="http://code.jquery.com/jquery-1.8.3.js"/>
	/// <reference path="backbone-0.9.9.js" />
	var Bar = Backbone.View.extend({
	initialize: function(){
	this.render();
	},
	render : function(){
	this.$el.text("bar");
	}
	});

view raw

bar.js

hosted with ❤ by GitHub

実行結果

サンプル実行結果

GistSharpExtension、CreateNewGist.exeを1.4.1.0にバージョンアップ

コメントを残す

現在編集中のコードを簡単に新しいGistとして更改できるツールである、GistSharpExtension、CreateNewGist.exeを、それぞれ1.4.1.0にバージョンアップしました。

変更点は次の通り。

バグFIX:Ctrl+EnterでGist作成時、入力したdescription等の内容が反映されないケースがあったので修正した。

v.1.4のメイン機能にバグを仕込んでいたというわけです、すみませんすみませんm(_ _)m

そんなわけで、安心して使えるようになったGistSharpExtension並びにCreateNewGist.exe v1.4をよろしくお願いします。

Re: Gitのdiff・mergeをgitconfigだけでWinMergeにする

コメントを残す

Gitのdiff・mergeをgitconfigだけでWinMergeにする – nrm://lab.kss.inc – Petittech

mergeはまだ試してないんだけど、インストーラが書いたやつだからたぶん動く

WinMerge 2.13で確認したところ、動きませんでした＞＜

WinMergeのコマンドラインオプションを確認

WinMergeのコマンドラインオプションを、ヘルプで確認してみましょう。

WinMerge[U] [/r] [/e] [/f filter] [/x] [/xq] [/s] [/ul] [/ur] [/um] [/u] [/wl] [/wr] [/wm] [/minimize] [/maximize] [/dl leftdesc] [/dr rightdesc] leftpath [middlepath] rightpath [/o outputpath]

ごちゃごちゃして分かりにくいので、要所のみ抜き出すと次のようになります。

WinMerge[U] leftpath [middlepath] rightpath [/o outputpath]

*pathのそれぞれを次のようにすればよさそうです。

leftpath : $LOCAL（現在のブランチのファイル）
middlepath : $BASE（現在のブランチの一つ前のコミットファイル、HEAD^）
rightpath : $REMOTE（マージするブランチのファイル）
outputpath : $MERGED（マージ結果を保存するファイル）

WinMergeをgit mergetoolで使うgitconfig

上記を踏まえると、WinMergeをgit mergetoolで使うためのgitconfigは次のようになります。なお$LOCAL、$REMOTEのファイルは変更する必要はないので、読み取り専用にしています。

	[merge]
	tool = WinMerge
	[mergetool "WinMerge"]
	cmd = \"C:/Standalone Programs/WinMerge/WinMergeU.exe\" //r //e //u //wl //wr \"$LOCAL\" \"$BASE\" \"$REMOTE\" //o \"$MERGED\"

view raw

git-mergetool-using-winmerge-settings.txt

hosted with ❤ by GitHub

ポイントは次の通り。

Unicode版のWinMergeU.exeを使う。
git.mergetool.pathは不要。
コマンドラインオプションの”/”は2重にする。（msysGitの制限？）

/r : 再帰的にマージツールが動くらしいが未確認。フォルダーマージで必要なのかな？
/e : ESCキーでWinMergeが閉じるようにする。
/u : マージ用の一時ファイルがWinMergeの「最近使用したファイル」に追加されないようにします。
/wl : 左（$LOCAL）側を読み取り専用にする。
/wr : 右（$REMOTE）側を読み取り専用にする。

これで、git mergeやgit rebaseでconflict発生時に、git mergetool -yとするだけで、WinMergeがマージツールとして起動して、GUIによるマージ作業が行えるようになります。

[マージ前]

コマンドラインオプションで指定した通り、マージ先、一つ前のコミット、マージ元のファイルが3ペイン表示されます。

[マージ後]

「左へコピー」などのGUI操作でマージして保存すると、$MERGEDに指定したファイル、つまりマージ対象ファイルとして保存されます。

これで皆さんも快適なマージライフを！

って、既に「WindowsのGit(msysgit)環境で、秀丸エディタ、Winmergeを使う設定 – みちしるべ」でも動かないって言及されてますね・・・

TypeScriptでWSHを書いちゃおう #visualstudio – @masaru_b_cl

コメントを残す

この記事はVisual Studio Advent Calendar 2012 : ATNDへの参加エントリーです。

昨日は@kazukさんの「Visual Studio 2012 でのパフォーマンスプロファイリング « kazuk は null に触れてしまった」でした。

TypeScriptいいですよね

今年10/1に突然Microsoftから発表されたTypeScriptですが、型安全でラムダ式も使えたりして、良いですよね。

TypeScriptは「コンパイルされてJavaScriptを吐き出す」ということで、WSH（Windows Script Host）のJScriptも書けるんじゃないの？というのがこのエントリーの趣旨です。

何はともあれインストール

TypeScriptを書くからにはVisual Studioがいいですよね。ということで、「TypeScript for Visual Studio 2012」をインストールしましょう。

可能ならPro以上のEditionにして「Web Essentials」もインストールするとなお良いですね。

プロジェクト作成

さて、無事TypeScriptのインストールが終わったところで、早速TypeScript用のプロジェクトを作成しましょう。「Visual C#」のテンプレートに「HTML Application with TypeScript」というテンプレートがありますので、選択してプロジェクトを作成します。今回は"WSHSample"という名前にしました。

え？Webアプリじゃないよって？気にせず行きましょう！ｗ

余分なファイルの削除

プロジェクトが作成されると、既定で次の3つの項目が作成されています。が、WSHには不要なので、ソッコー削除します。

クラスファイルの作成

ではWSH用のクラスを定義するファイルを作成しましょう。

「新しい項目の追加」ダイアログを開き、これまた「Visual C#」の中にある「TypeScript File」テンプレートを選択し、"greeter"という名前で追加します。

「Web Essentials」を入れているとこんな感じでtsファイルと生成されたjsファイルが横に並んで表示されます。

とりあえず既定のコードは全部削除して、次のコードを入力して保存します。

	module TAKANO.Sho {
	export class Greeter {
	constructor (public name: string) {}

	greet() {
	WScript.Echo("Hello " + this.name + "!");
	}
	}
	}

view raw

greeter.ts

hosted with ❤ by GitHub

またもやWeb Essentialsの力により、即座にコンパイルされてjsファイルが生成されます。

	var TAKANO;
	(function (TAKANO) {
	(function (Sho) {
	var Greeter = (function () {
	function Greeter(name) {
	this.name = name;
	}
	Greeter.prototype.greet = function () {
	WScript.Echo("Hello " + this.name + "!");
	};
	return Greeter;
	})();
	Sho.Greeter = Greeter;
	})(TAKANO.Sho \|\| (TAKANO.Sho = {}));
	var Sho = TAKANO.Sho;
	})(TAKANO \|\| (TAKANO = {}));

view raw

greeter.js

hosted with ❤ by GitHub

メイン処理スクリプト作成

TypeScriptで書いたクラスですから、TypeScriptでメイン処理も書いてしまった方が何かと楽です。

そんなわけで、greeter.tsと同じようにmain.tsを作成して、次のコードを入力して保存します。

	/// <reference path="greeter.ts"/>
	var greeter = new TAKANO.Sho.Greeter("Sho");
	greeter.greet();

view raw

main.ts

hosted with ❤ by GitHub

もちろんmain.jsが作成されますが、main.tsとほとんど変わらないので省略。

ちなみにコード中の

/// <reference path="greeter.ts"/>

はgreeter.tsを参照するためのもので、これを入れるとコード補完が普通に利くようになります。

実行用wsfファイル作成

最後に、生成されたgreeter.js、main.jsを参照したwsfファイルを次のように作成して終了です。

	<?xml version="1.0" encoding="shift_jis" ?>
	<job id="main">
	<script src="greeter.js" language="JScript"></script>
	<script src="main.js" language="JScript"></script>
	</job>

view raw

execute.wsf

hosted with ❤ by GitHub

execute.wsfをダブルクリックして実行すると、次のようにちゃんと実行されてWScript.Echoの結果が表示されます。

まとめ

TypeScriptでWSHはイケる。

TypeScript for Visual Studio 2012を入れる。
Web Essentialsも入れると何かと捗る。
Webプロジェクトだけどただのフォルダ、ファイルの組み合わせなので問題なし。

メインロジックもtsで書いて、実行はwsfで行う。

TypeScriptの恩恵をフルに受けることが可能。

最終日はアンカーの@tashinmuさんにバトンタッチです。

Visual Studio Adevent Calender 2012 – Visual Studio が対応するアプリケーションタイプ – Days with Microsoft Platform – Site Home – MSDN Blogs

「実例で学ぶASP.NET Webフォーム業務アプリケーション開発のポイント最終回 2つのAJAX：「jQuery AJAX API」と「ASP.NET AJAX」」が公開されました

コメントを残す

2つのAJAX：「jQuery AJAX API」と「ASP.NET AJAX」（1/3）：CodeZine

ついに最終回です。

ASP.NET WebフォームアプリケーションにAJAXを導入する方法には大きく分けて2つの方法があります。一つがjQueryのAJAX APIなどJavaScriptを使い自前で行う方法、もう一つがASP.NET AJAXを利用する方法です。

というわけで、WebFormsで2種類のAJAXを扱う方法について紹介しています。

また、連載の最後ということで

ASP.NET Webフォームに限らず、フレームワークにはある一定の思想、原理が存在します。その思想、原理を理解すれば、「フレームワーク」がもともと持っている機能、アーキテクチャを最大限に生かすことができます。

というメッセージも添えさせていただきました。

最近はすっかりWebFormsの人気がありませんが、まだまだ使いどころがあるはずです。何らかの形で今回の連載がお役に立てれば幸いです。

1212121212

コメントを残す

記念エントリ！

IEnumerableの型を指定したforeach #adcjcs by @masaru_b_cl

1件のフィードバック

この記事はC# Advent Calender 2012 : ATNDへの参加エントリーです。

昨日は@ishisakaさんの「C#でYAMLを使えるか試してみた | OPC Diary – No Code, No Life.」でした。

IEnumerable型

古き良きC# 1.0の時代より受け継がれる「Iteratorパターン」のためのインターフェースであるIEnumerable型。.NET 2.0からジェネリック版のIEnumerable<T>型が追加され、昨今では黒歴史扱いを受けたりしています。

しかし、いまだにIEnumberable型のみを実装した型も少なくありません。たとえばSystem.Windows.Forms.Control.ControlsプロパティのControlCollection型などがあります。

そのため、画面のコントロールをすべて舐めるような処理も、型のないIEnumerable型を使う必要があります。

foreachによる列挙

IEnumerabe型の列挙といえば、foreachです。for？なにそれ？

ただ、すでに述べたようにIEnumerable型の要素をただ列挙しても、Object型としてしか取得することができません。

// 型推論に任せる
foreach (var item in source)
{
  // itemはObject型になるので、型変換が必要
  var person = item as Person;
  Console.WriteLine("{0}, {1}, {2}", person.Id, person.Name, person.Age);
}

これを解決するために、LINQのCast<T>演算子を使うといった方法がありますが、余計な処理が一枚かんでいるという印象はぬぐえません。

// Cast<T>メソッドを通す
foreach (var person in source.Cast<Person>())
{
  Console.WriteLine("{0}, {1}, {2}", person.Id, person.Name, person.Age);
}

そこで、おすすめなのが、明示的に型を指定することです。こうすることで、自動的にキャストが行われるため、コードがすっきりします。

// 明示的に型を指定する
foreach (Person person in source)
{
  // personは自動的にPerson型にキャストされる
  Console.WriteLine("{0}, {1}, {2}", person.Id, person.Name, person.Age);
}

このことは、C#言語仕様（%ProgramFiles%\Microsoft Visual Studio 11.0\VC#\Specifications\1041\CSharp Language Specification.docx） p.279 「8.8.4 foreachステートメント」の次の内容に対応しています。

ステートメントは次の形式になります。

foreach (V v in x) embedded-statement

これは次のように展開されます。

{
  E e = ((C)(x)).GetEnumerator();
  try {
    while (e.MoveNext()) {
      V v = (V)(T)e.Current;
      embedded-statement
    }
  }
  finally {
    … // Dispose e
  }
}

サンプル

	using System;
	using System.Collections;
	using System.Collections.Generic;
	using System.Linq;
	using System.Text;
	using System.Threading.Tasks;

	namespace ConsoleApplication1
	{
	class Person
	{
	public int Id { get; set; }
	public String
	Name { get; set; }
	public int Age { get; set; }
	}

	class Program
	{
	static void Main(string[] args)
	{
	var people = new[] {
	new Person { Id = 1, Name = "太郎", Age = 25},
	new Person { Id = 2, Name = "次郎", Age = 22},
	new Person { Id = 3, Name = "三郎", Age = 20},
	new Person { Id = 4, Name = "四朗", Age = 17},
	};

	IEnumerable source = people;

	// 型推論に任せる
	foreach (var item in source)
	{
	// itemはObject型になるので、型変換が必要
	var person = item as Person;
	Console.WriteLine("{0}, {1}, {2}", person.Id, person.Name, person.Age);
	}

	Console.WriteLine();

	// Cast<T>メソッドを通す
	foreach (var person in source.Cast<Person>())
	{
	Console.WriteLine("{0}, {1}, {2}", person.Id, person.Name, person.Age);
	}

	Console.WriteLine();

	// 明示的に型を指定する
	foreach (Person person in source)
	{
	// personは自動的にPerson型にキャストされる
	Console.WriteLine("{0}, {1}, {2}", person.Id, person.Name, person.Age);
	}
	}
	}
	}

view raw

Program.cs

hosted with ❤ by GitHub

まとめ

C#にはこういった楽をするためのsyntax sugarがたくさんあります。たまに言語仕様をチェックしてみるのも楽しいのではないでしょうか。

次は@Marimoiroさんにバトンタッチです。

C#でゲームつくるです　[C# Advent Calender 2012]C#を補助するいろんな脇役

スーパー戦隊のメカのインターフェース設計はすごい #childrenac2012 by @masaru_b_cl

2件の返信

この記事は子育てエンジニア advent calendar 2012 : ATNDへの参加エントリーです。

昨日は@muddydixonさんの「通勤時間と仕事と育児と勉強 – PolyPeaceLight」でした。

スーパー戦隊見てますか？

我が家は4歳と0歳の息子がおります。特に長男は昨年の「海賊戦隊ゴーカイジャー」から現在の「特命戦隊ゴーバスターズ」まで、スーパー戦隊に夢中です。

（仮面ライダーもフォーゼから始まり、さかのぼってクウガとW、現在のウィザードと見ていますが、それはまた別の機会に）

私も一緒になってみているのですが、案外面白いのですよね、大人でも。

スーパー戦隊のメカたち

スーパー戦隊といえば、なくてはならないのが巨大ロボをはじめとしたメカたちです。私が子供のころは、1体のロボットで最後まで突っ切ったものですが、最近は次から次へと新しいメカが登場し、それだけはなく最終的には全部が合体したりします。

今のゴーバスターズでは「バスターマシン」と呼ばれ、「CB-01 チーター」が単体でゴーバスターエースというロボットになれるところ、「GT-02 ゴリラ」、「RH-03 ラビット」が合体して「ゴーバスターオー」になったかと思えば、新たに「BC-04 ビートル」、「SJ-05 スタッグビートル」が登場しそれらが合体して「バスターヘラクレス」になり、さらにこれまでの5体のバスターマシンがすべて合体し「グレートゴーバスター」になります。それだけではなく、さらに新たなメカ「タテガミライオー」が出てきて単体でロボットになり、「GT-02 ゴリラ」、「RH-03 ラビット」と合体し「ゴーバスターライオー」に、さらに追加で「BC-04 ビートル」、「SJ-05 スタッグビートル」が合体して「ゴーバスターキング」になります。さらにさらに、「CB-01 チーター」に「SJ-05 スタッグビートル」が合体して「ゴーバスターエーススタッグカスタム」になったり、映画限定メカの「FS-0O ふろっぐ」とも合体したりと、まぁよくこれだけと思わなくもありません。

そしておもちゃに

そんな男の子心をくすぐるメカたちですが、当然おもちゃになり誕生日、クリスマス商戦で活躍するわけであります。で、すごいのがこれだけバリエーションがある合体パターンにすべて対応しているのですよね、おもちゃも。

手元には長男の誕生日、および入院で頑張ったご褒美で買った＆ジジババに買ってもらった「CB-01 チーター」、「GT-02 ゴリラ」、「RH-03 ラビット」があるのですが、それだけ見ても分解したり、組み替えたりと結構複雑なのですよね。それにすぐ適応する4歳児はすげぇなぁと思ったものです。

どうしてこんなことが可能か？

どうしてこんなことが可能になっているのかというと、やはり「インターフェース設計がしっかりしている」これに尽きますね。付随して「適度なモジュール化」なんてのもあります。

この設計、破たんしないためには番組開始前にすべてのマシンの情報がきっと開発元には行ってるんでしょうね。そうじゃなきゃ無理ですもの、こんなに次から次へと出てくるのに整合性をとるの。なんとなくサテラビューを見越した設計がされていたスーパーファミコンを彷彿とさせます。

開発元で働くお父さん、お母さんがたにおきましては、子供に内緒にしておくのが大変なんだろうなぁとか、いらぬ妄想をしてしまいます。

と、むりくりエンジニアっぽい結論でした！

まとめ

バンダイさんすごい！

次は@JunichiIto77さんにバトンタッチです。

もっと勉強時間を増やしたい子育てエンジニアに「銀の弾丸」はあるか？ #childrenac2012 – give IT a try

TDDにIDEを活用しよう (VS2012+CodeRush Xpress) #TddAdventJp by @masaru_b_cl

コメントを残す

この記事はTDD Advent Calendar jp: 2012 : ATNDへの参加エントリーです。昨日は@nnasakiさんの「デシジョンテーブルを使用してテストしてみよう #TddAdventJp – nnasakiのブログ」でした。

TDDにおけるIDEの重要性

TDDを進めていく中で、一番注力したいことは@irofさんもおっしゃっていましたが、「思い通りに動くコードを書くこと」です。

しかし、思ったことを書こうとしても「この変数が欲しいな」、「名前が不適切だから変えよう」などなど、単純だけど少し手間な作業が案外プログラミングには多いものです。こういったものは、ツールに任せてしまうのが一番です。

幸い昨今のIDE（統合開発環境）は非常に優秀ですので、文脈（コンテキスト）を踏まえた変換処理などもお手の物です（エディターとは違うのだよ、エディターとは！）。これを使わない手はありません。

IDE活用の実例

では、実際にIDEをフル活用してTDDを行っていってみましょう。今回使用するのは、Visual Studion 2012、および無償の拡張ツールであるCodeRush Xpress、Quick Test Switcherで、言語はC#です。

題材は「車窓からのTDD」を選びました。C#用に、以下ように仕様を微調整しました。

bool IsEmptyプロパティ
スタックが空の場合、true。それ以外false を返す。
int Sizeプロパティ
スタックのサイズを取得する。
void Push()メソッド
引数の値をスタックの一番上に積む。
void Pop()メソッド
スタックの一番上の値を取り除く。
スタックが空の場合、EmptyStackExceptionが発生する。
int Topプロパティ
スタックの一番上の値を取得する。
スタックが空の場合、EmptyStackExceptionが発生する。

プロジェクト作成

コードを書き始める前に、器となるプロジェクトを作成しておきましょう。次のように、プロダクトコード用のTddFromTrainWindowと、テストコード用のTddFromTrainWindow.Testプロジェクトを作成しておきます。

TddFromTrainWindow
- クラスライブラリプロジェクト
TddFromTrainWindow.Text
- 単体テストプロジェクト
- TddFromTrainWindowプロジェクトを参照している

なお、「TddFromTrainWindow”.”Test」としているのは、”.”で名前空間を区切ることで、テストコードでは上位の名前空間の型がそのまま参照可能になるからです。

また、テストコードが自動で実行されるよう、［テスト］メニュー→［テスト設定］→［ビルド後にテストを実行］を有効にしておきましょう。

StackTest、Stackクラスの作成

それでは実装を進めていきましょう。まずはStackTest、Stackクラスのペアを作成します。

Ctrl+Shift+Aで「新しい項目の追加」ダイアログを開き、［基本単体テスト］を選択して”StackTest”として作成する。
StackTestクラスのTestMethod1メソッドをTestCreateにリネームする。
new Stack();までタイプしたところでCtrl+.を押し、［新しい型の生成］を選択してTddFromTrainWindowプロジェクトにStackクラスを作成する。
テストコードとプロダクトコード間の移動はQuick Test Switcherの機能を利用して行う（ショートカットキーはCtrl+9に事前に変更済み）。