Programmers Office

楽しみ～（謎）

先日のNUnitとJUnitの件の続きです。 Visual Studioで正規表現を使った置換ができるのはヘルプを見れば分かるのですが、慣れていないとなかなか使えないですね。 http://www.microsoft.com/japan/msdn/library/default.asp?url=https://jqinglong.github.io/programmers-office/japan/msdn/library/ja/vsintro7/html/vxgrfregularexpressionss.asp 例えば、次のような置換をしたい場合、 assertEquals(“3”, emp.getDeptno(), dept.getDeptno()); ↓ Assert.AreEqual(emp.getDeptno(), dept.getDeptno(), “3”); タグ付き正規表現を使います。 検索する文字列： assertEquals({”[1-9]”}, {.*}); 置換後の文字列： Assert.AreEqual(\2, \1); 「条件」をチェックして正規表現を選択して置換すると、見事にやってくれます。 やった！ {}で囲むと、そこにはタグが付いたことになり、\1～9で使うことができるという仕組みです。

http://www.ezaki-glico.net/officeglico/index.html こんなものがあるそうで。 お菓子にお悩みの方、いかが？？

出典を忘れてしまい、本当に申し訳ないのですが、ちょっと前に「分離したら結合する必要がある」という言葉に触れ、当たり前のようで実は深いなと感銘を受けていました。 さて、LINQです。 http://msdn.microsoft.com/netframework/future/linq/ http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp#linqprojec_topic2 を見れば一発だと思いますが、クエリがプログラム言語に統合されているというわけです。 9月のPDC2005（http://www.microsoft.com/japan/msdn/pdc/default.aspx）で紹介されたそうですが、それを伝え聞いて衝撃を受けました。これで文字列結合との戦いが終わるのかと。 しかし、今日ふと思ったのですが、SQLが何故ここまで使われているか、それは水平切り口でのドメイン特化言語だったからであり、プログラム言語とは分離していたからではないか、と。 おそらく、プログラミング作業の中で、業務ロジックを書いている時とSQLを書いている時では微妙に違う帽子をかぶっています。だから階層も分けます。しかし、それは結合される必要があり、多くの場合、業務ロジックを書くのもSQLを書くのも結合するのも同じ人がやるのではないかと思います。その結合方法が、実行するまでシンタックスが正しいかどうかすら分からない「文字列」ではあまりにも悲しいので、LINQに対する期待が起こるわけですが、これは言い方を変えると、業務ロジックに対する関心と、データ操作に対する関心が分離していたところを結合してくれる人が現れたことに対する喜びなのかと思うわけです。 ところが、この方法は割と強固な結合だと思います。 http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp#linqprojec_topic5 強固に結合するためにはこの程度のシンタックスしか定義できず、従来方式との併用になるのではないかと思われます。しかしそれは・・・と思ってしまいました。 まあ、登場はもう少し先の話なので、これから色々盛り上がるとよいなと思います。 （ちなみに、現時点ではやはりS2.DAOのSQLコメント方式が最高ではないかなと。）

高橋書店のリシェル３というのを買いました。 http://www.takahashishoten.co.jp/index.php?submit=note_det&goods_id=78 あまり手帳使うのは得意ではないのですが、バーティカルというのはよさそうです。 （というのは和田さんの日記で知りました） この手の手帳って、あまりカラーバリエーションないものですね。その中では緑のこれはよかったです。

by 森屋さん http://www.atmarkit.co.jp/fdotnet/nagile/nagile01/nagile01_02.html システム開発の中ではままならないことも多いですが、自分で緑色をコントロールするNAgileには、確かに癒されるかもしれません。 この記事は、その他の皆様の発言も含めて必見ですね。

今日は一日JUnit用のテストコードをNUnit用に書き換えていたのですが、どうしてAssertの書き方を変えてしまっているのでしょうね。 NUnit Assert.AreEqual( object expected, object actual, string message ); JUnit assertEquals(java.lang.String message, java.lang.Object expected, java.lang.Object actual) メソッド名等の違いは置換すればよいですが（一発置換用のVisualStudioマクロを作りながらやっていましたが、次のファイルから効果がでるとよいな～）、メッセージの位置が違うのは痛い・・・ よい方法ないものでしょうか？？明日も試行錯誤は続く・・・

リフレッシュを兼ねて観戦決行。埼玉スタジアム歩くのは結構嫌だなと思っていたのですが今年はシャトルバスに乗れました。 お決まりのストラップは今年は派手です！ 前半の席はやや微妙で途中から傘さしてました。 最初は左の3番から小林そしてオサマへと入れていく東京が優勢でしたが、30分くらいから札幌のドリブルでの切り込みが始まり得点の 雰囲気を醸し出します。 後半もその雰囲気のまま7分、右サイドギリギリのパスから折り返し、キーパーのはじいた球を叩き込んだ札幌が先制しました。 ところがここから東京が爆発。常に点を狙える位置を取り続けるオサマが2点、ソヤも2点と圧倒してしまいました。 オサマは去年の前俊同様激しい動きはないですが確実に得点するという感じで面白かったです！

やるぞと言って一週間たってしまい、まったくもってアジャイルではありませんが、今日から始めました。 ・・・いい！ (1)場ができる あまり大きなスペースを取れるところもないので、席の近くのロッカーにA3の裏紙を3枚（未着手・実施中・完了）貼って、そこに付箋紙を貼ってみましたが、班外の人も見に来てくれ、班のメンバーとそこで話したりできます。 (2)仕事の「かけら」化 以前、結城さんの http://www.hyuki.com/d/200506.html#i20050620101645 を読んだときに、大いに納得していたのですが、タスクカードがすなわち「かけら」になり、仕事のやり取りがしやすくなりそうです。 (3)アラート これまでの経緯や立場上、色々な相談・依頼を受けるのですが、それを未着手に貼っていくと、あっという間にパンクしそうになっています（苦笑）。後輩には「自分が忙しいことを見せようと思って始めたんでしょう」と言われましたが、まあ、そうかもしれません（笑）。アラートをあげるのが苦手な方、是非！

今日、PMシンポジウムに参加した会社の部長から、「参考になることが書かれている」として、オブジェクト倶楽部のプロジェクトファシリテーションのページの紹介が回覧されてきました。 実践編はこうですよ、ということでXP祭りの平鍋さんの資料を返信し、せっかく着目したなら一つでもやりましょう、ということで、タスクカードによるソフトウェアかんばんと、ネットワークパトランプによるソフトウェアあんどんを推薦しました。 やるぞ！！