超不定期雑記

エンド・ゴールサイエンスカフェ「星の海へ、漕ぎ出そう」

guicheng <webmaster@rudicast.net> — Thu, 22 Sep 2011 15:55:00 GMT

先週の土曜日、半田市で開催されたサイエンスカフェに講師として登壇してきました。
そのときの発表資料をアップロードします。

星の海へ、漕ぎ出そう(.pptx形式 1.28MB)
期日:2011年9月17日(土) 16:00～18:00
場所:クラシティ半田
主催:NPO法人エンド・ゴール

探査機の軌道を「航路」に見立てると、現在の深宇宙探査は大航海時代の幕開けの時期に相当します。
今回のサイエンスカフェではこの「航路(＝軌道)」に焦点を当てて、日本の深宇宙探査の歴史について語りました。
内容は6月に九州で開催された「はやぶさ帰還1周年記念パーティ」の焼き直しではありますが、前回の持ち時間が20分だったのに対して今回は2時間。
従って、かなりの加筆修正をしています。

日本初の深宇宙探査機である「さきがけ」「すいせい」は、目標であるハレー彗星に直行するという非常に素朴な軌道を採りました。
続く工学実証衛星「ひてん」はこれからの深宇宙探査に必要なスイングバイ技術の習得を目的とし、見事にその任務を果たしています。さらには二重月スイングバイ、エアロブレーキング、太陽摂動を利用した省エネ月周回軌道投入など、華々しい成果を上げました。
そして火星探査機「のぞみ」はバナナンオービットととも呼ばれる二重月スイングバイ＋地球パワースイングバイの軌道が計画され、パワースイングバイ失敗後も黄道面の北天方向に跳ね上げるという奇想天外な修正軌道が採られました。
最後に小惑星探査機「はやぶさ」について紹介し、イオンエンジンによる航行がいかに難しいかをお話ししました。

実際には用意した資料以外にもいくつか出してみたり、ホワイトボードに図を描いて解説したりもしました。
軌道は探査機のミッションの中でもあまり日の当たらない要素ですが、今回のサイエンスカフェで興味を持ってくださった方が一人でもいれば幸いです。

Subversion のリポジトリダンプが途中までしか svnadmin load されない？

guicheng <webmaster@rudicast.net> — Thu, 04 Aug 2011 08:09:00 GMT

まずは症例報告のみ。原因不明。

手元に51リビジョンまでコミットしたSubversionのリポジトリがある。
これを別のサーバに移行しようと思い、旧リポジトリのダンプを取って新サーバでロードした。
しかし新サーバのリポジトリを見てみたら、リビジョンが40までしか再現されていなかった。
行った手順は以下の通り。

1. 旧サーバ(手元のWindowsPC)で svnadmin dump を発行した。ログによると、リビジョン51までダンプが作られたとのこと。
2. 新サーバ(さくらのVPS)にダンプファイルをアップロードし、 svnadmin load した。ログによると、リビジョン40まで再現したとのこと。

対策として、旧リポジトリから全データをエクスポートし、新リポジトリの作業コピーに上書きしてコミットし直した。
ダンプファイルがおかしいのか、Subversionのバージョン違いによるのか、あるいは別の原因があるのかは不明。
従って、根本的な解決とは言い難い。

わんくま名古屋#18LT資料「IDisposable を成敗する」

guicheng <webmaster@rudicast.net> — Sun, 10 Jul 2011 02:45:00 GMT

今回のわんくま名古屋ではLTを一本受け持ったんですが、そのスライドを公開します。

IDisposable を成敗する

IDisposable オブジェクトを生成したら、必ず Dispose() しなければなりません。
ファイル操作系の処理などでよく使われる IDisposable オブジェクトですが、COM系のライブラリでは重要度が飛躍的に高まります。
というか、ほとんど全部が IDisposable オブジェクトだしねぇ……

IDispose オブジェクトは例外が発生した場合でもきちんと処理しないといけないわけですが、これがまためんどくさい。
単純な try-catch 構文では大量のタイプ量と多段ネストに悩まされ、using構文を使ったとしても多段ネストの問題はクリアできません。
LDAPだったら3段程度なのであまり問題になりませんが、Excel操作では地獄を見ます。

ところがこの問題は、Stack を使えばあっさりとクリアできてしまうんです。
生成した IDisposable オブジェクトをスタックにガサガサ突っ込んで、finally節で foreach 使ってスタック要素を Dispose() すればOK。
これが非常に強力で、これまで多段ネストのせいで落ちていた可読性が、格段に良くなります。
しかも、Dispose() のし忘れはなし。
これが、私が C# からの Excel 操作を得意としている理由なんですね。

さらにこの機構を育てると、いっぱしのフレームワークになります。
次回の名古屋では、このフレームワークについて発表したいなと思います。

名古屋勉強会#18お疲れ様でした

guicheng <webmaster@rudicast.net> — Sun, 10 Jul 2011 02:01:00 GMT

昨日開催した「わんくま同盟名古屋勉強会#18」に参加された皆様、お疲れ様でした。
今回は輪番休日の影響か、参加者が少なめでの開催でしたが、いつも通りの濃い内容だったのではないかと思います。

一番手はりょーいちさんの「デジタルカメラ　ステップアップ術」。
今回は構図や色彩などについてでした。
りょーいちさんの写真は躍動感があるというか、対象のとらえ方がすげーウマイと思っていたんですが、実はこんな工夫があったんだと感心しきりでした。

続いて二番手は秋野氷雨さんの「グラフにまつわるエトセトラ」。
グラフって何？から始まって、色彩問題など、グラフに関わる話題がいくつも出てきました。
グラフ問題って数学的なネタでしかないと思っていたんですが、スケジュール管理にも転用できることを見せられて、目から鱗でした。

LT3本とお昼ご飯を挟んで、午後一番手はbiacさんの「TDD道場」。
今回もテストコードを書いてから実装をするという、TDDの原則に則ったコーディングが実演されました。
会場からも突っ込みの声が上がり、テストコードについて考えるいい機会になったのではないかと思います。

次に川路義隆さんの「AWSを開発チームに導入してみよう」。
AWS は Amazon が提供するクラウドサービスですが、これを開発チームで導入するにはどうすればいいかについてでした。
私はクラウドサービスがどんなモノかよくわかっていないために躊躇している部分がありましたが、これだけ手軽に扱えるのであれば導入してみたいと思いました。

続いて割と普通さんの「ASP.NET MVC3を利用したHTML5な画面開発～クラウドも有るよ！～」。
MVC3とjQueryを組み合わせるとHTML5の画面開発が簡単にできることが紹介されました。
JavaScriptにかなり否定的な見方をしていました私ですが、さっくりときれいな画面を構築できるのであれば試してみたくなりました。まぁ、ハマリどころもあるようですが。

最後はインフラジスティクスの池原さんによる「Windows Phone “Mango”」。
まだ日本では本体が発売されていないWindowsPhoneですが、年内にも発売の見込みだそうです。
最近発表されたSDKのBeta版では日本語対応されたこともあり、これから熱くなるデバイスかもしれませんね。

次回は少し期間が空いて10月29日の開催です。
お手すきでしたら、是非ご参加ください。

転職しました

guicheng <webmaster@rudicast.net> — Fri, 20 May 2011 07:00:00 GMT

いろいろあって、この5月から三重の会社に転職しました。
関東には4ヶ月ほどしかいなかった計算になります。
定住するつもりだったんだけどなw

さて現職は、ゼネコンでございますwww
といっても、社員数が片手で数えられる程度の非常に小さな会社ですが。
てことで、私も工具箱と資材抱えて走り回る毎日ですよw
ソフト開発するために転職したんだけどなー

てことで、今度からは建築現場をプログラマーの目から見てみようと思ってます。
んで、その辺ははてなの方に書いていこうかと。
よろしければ、下記もご覧ください。

超不定期雑記はてな版
http://d.hatena.ne.jp/guicheng/

Windows 7 64bit に Lhaplus を入れてみた

guicheng <webmaster@rudicast.net> — Fri, 04 Mar 2011 03:49:00 GMT

これまで圧縮解凍ツールは AI soft のファイルコンパクト5 を使っていた。
対応形式が多く、何より右クリックメニューから圧縮・解凍操作ができる点が気に入っており、Ver.2(当時は別の名前だった記憶がある)の頃から使い続けている。
他にも解凍時にウィルスチェックしてくれたり、圧縮ファイル内を見るための「書庫エクスプローラー」を備えるなど、えらい高機能で使いやすいツールだった。

ところが古いソフトということもあって 64bit 版 Windows には対応していない。
32bit 版 Windows7 でも一部のメニューが欠損するなど、何かと問題はあった。
しかし AI soft が解散してしまった現在となってはバージョンアップの見込みはなく、泣く泣く 7-Zip に乗り換えたわけだが、これって .tar に対応してないのね……
何より、なぜか私のフィーリングに合わない。

てことで調べてみたら、 Lhaplus が Windows 7 64bit でも動作するらしい。

Lhaplus(HoeHoe.com 跡地)

公式には 32bit 版 Windows にしか対応をうたっていないが、私の環境(Windows 7 Ultimate SP1 64bit)では圧縮・解凍共に正常に動作した。
ただし、圧縮ファイルの右クリックメニューに「圧縮」「解凍」のメニューが追加されない問題がある。
しかしこれは、下記のツールをインストールすることで解消される。

Lhaplus x64 shell extension(Shark++ Software's Web Page)

このツールは install.cmd を実行する際に管理者権限が必要である。
Windows Vista 以降の場合、右クリックメニューの「管理者として実行」から実行しなければならない。
さもないと、インストール時に「権限がない」というエラーが出る。

Lhaplus は超有名なソフトなので、使い勝手を今更レポートする必要もないだろうからパス。
不満は圧縮ファイルのアイコン(ファイルコンパクトに慣れすぎた……)と書庫内閲覧ができないことくらい。
書庫内閲覧はあまり使っていなかったので、実用上の問題は今のところ発生していない。

【告知】第5回 .NET 中心会議 (3月19日開催)

guicheng <webmaster@rudicast.net> — Sat, 26 Feb 2011 20:00:00 GMT

@IT 主催のイベントで .NET中心会議ってのがありまして、その第5回が3月19日に大手町で開催されます。
今回のサブタイトルは「あなたのチームに最適なテストを考える」となっていまして、VisualStudio2010のテスト機能を中心に .NET 開発におけるテストについて議論されます。

んで。
この会議のパネルディスカッションに、私もパネリストとして登壇することになりまして。
あんまり深く考えずに承諾しちゃったんですが、ホントに私で大丈夫なんだろうか……
今更ながら不安になってきましたが、思い付く限りしゃべってきたいと思います。

開催概要

タイトル	第5回 .NET 中心会議「あなたのチームに最適なテスト」を考える
日時	2011年3月19日（土）　13:00～16:45（受付12:30～）
会場	大手町ファーストスクエアカンファレンス
定員	50名
参加費	無料
主催	アイティメディア株式会社　＠IT編集部

プログラム

12:30～	受付
13:00 ～ 14:00	基調講演『VisualStudio2010によるテスト手法』	講演者> 日本マイクロソフト株式会社近藤和彦氏
14:00 ～ 14:10	休憩
14:10 ～ 16:00	パネルディスカッション『あなたのチームに最適な .NET 開発のテスト手法』	パネリスト日本マイクロソフト株式会社近藤和彦氏日本アイ・ビー・エム株式会社太田健一郎氏わんくま同盟 guicheng
16:00 ～ 16:45	Q&Aセッション

2011年1月22日わんくま東京#55 セッション資料

guicheng <webmaster@rudicast.net> — Sat, 12 Feb 2011 12:44:00 GMT

1月22日の「わんくま同盟東京勉強会#55」に参加された皆様、お疲れ様でした。
相変わらず何を今更なタイミングで申し訳ありませんが、この回のセッション資料を公開します。

さて今回、私は「NUnitを使い倒す」というタイトルで登壇しました。
コードの品質を保証するためにも単体テストが重要であることは今更議論の余地はありません。
しかしテストの書き方についてのセッションは数あれど、環境設定の話って意外とないんじゃないかなーと思いまして、そっちにフォーカスした内容で一席話すことにしました。

「NUnitを使い倒す」セッション資料(PDF:388KB)

今回はNUnit の入手とインストールに始まり、プロジェクトの構成、テスト関数の書き方、VisualStudio との連携、便利ツールの作成までをお話ししました。
また、ほぼ全編にわたってライブコーディングしてます。
なお1月15日に登壇した名古屋#16もほぼ同等の内容です。
名古屋での直前の修正を加えたのが東京だと思ってください。

さて、名古屋と東京で突っ込みを受けた点やアフターフォローについていくつか。

テスト関数

テスト関数として Assert.AreEquql() を強く推して話をしましたが、これは NUnit に慣れていない人向けの話と思ってください。
実際にはセッション中でも触れたとおり Assert.That() の使用が推奨されています。
Assert.That() は高機能で使いやすいんですが、初めて使う人には AreEquql() の方が取っつきやすいかなと思ってこちらを強く推しました。
ちなみに私は普段、 That() の方を使っています。

VisualStudioとの連携

VisualStudio との連携は、 TDD.net が有名でしょう。
しかし TDD.net といえど、ビルドのたびにテストを走らせるようなことはできません。
また今回はあくまでも NUnit の環境設定ということで、あえて外しました。
私は、コンソールランナーによる常時テストと TDD.net は補完しあう関係にあると思っています。
常時テストで引っかかったら TDD.net でテスト関数単体での実行をするというスタイルが適切ではないでしょうか。
私も個人環境では上記のような使い方をしています。

テストプロジェクトDLLの位置を知る

セッション中、便利ツールとしてテストプロジェクトDLL の位置を知るようなプロパティを書いてみました。
東京では時間の関係で触れませんでしたが、パスに日本語が混ざっていると想定通りに動作しませんので注意してください。
名古屋ではこれが原因で思いっきりミスしました……

実は名古屋の直前で biac さんから指摘を受けたんですが、NUnit 標準で TestContext.CurrentContext.TestDirectory というプロパティが用意されています。
このプロパティは上記のヘルパーツールと同じ動作をするので、今となってはこちらを使った方がいいでしょう。
私が使っていた NUnit2.5.2 には搭載されていませんでしたが、biac さんによると2010年8月にリリースされた NUnit2.5.7 から実装されていたそうです。
まぁ、古い NUnit を使うことになったら役に立つだろうということで。

テストデータの配置

bleis さんからは、テスト用のファイルを別に作成するよりも、テストデータ用構築用のDSL的なものを作ってテストコード中に埋め込むべきとの指摘をいただきました。
こうすればテストコードをそのまま実装コードに持って行くこともできるので便利だとのことです。
私も理想的にはその通りですし、できる限りそのように実装すべきとも思います。
しかし大量のリファレンスデータをもとにチェックする場合など、別にデータファイルを用意した方が圧倒的に便利なケースも多々あります。
そんなときに汎用的に使える手法ではないかなと思います。

2010年12月11日わんくま東京#54 セッション資料

guicheng <webmaster@rudicast.net> — Sat, 12 Feb 2011 11:51:00 GMT

大変長らくお待たせしましたが、昨年12月11日に開催された「わんくま同盟東京勉強会#54 スペース・デイ」のセッション資料を公開します。
よろしければご覧ください。

時間	タイトル	スピーカー
10:50 ～ 11:40	外側から見た宇宙広報	guicheng
13:10 ～ 14:00	月・惑星探査広報のこれから	てらきん
14:10 ～ 15:00	映画 ”HAYABUSA”が成しえたこと	上坂浩光
15:10 ～ 16:00	アウトリーチ活動に関するあれこれ	IES兄

※ 上坂浩光さんのセッション資料は資料は非公開です。

さて。
この回の勉強会はビデオを公開するとしていましたが、諸般の都合により公開不可となりました。
楽しみにしていた皆様、大変申し訳ありません。

しかし、この回の内容はどうにかして次につなげなければならないと強く感じています。
そこで、当時の状況を録画・録音されている方がおられましたら、私宛にご連絡いただけないでしょうか。
どのようになるかはまだ何とも言えませんが、何らかの形で公開したいと思います。

私の連絡先は下記の通りです。
申し訳ありませんが、ぜひともご協力ください。

mail: webmaster@rudicast.net
Twitter: @guicheng

VSS と SVN を共存させる

guicheng <webmaster@rudicast.net> — Sat, 29 Jan 2011 12:50:00 GMT

客先では Visual SourceSafe 2005 でソースコード管理をしているが、これがまたいろいろと問題があるわけで。
所々からソースコードを消してしまったという怨嗟の声が聞こえてくる。
私も先週やったorz

いや、適切に処理すればそんなこと起こらないというのはわかっている。
でも現実問題として、間違ったボタンを押すことはあるわけで。
チーム全体としてのソースコード管理ツールを変更するわけにいかないが、自衛のために SVN を使うくらいはいいよね。
ということで、VSSとSVNを同居する方法を考えてみた。

VSS の管理下にあるディレクトリをバックアップしておく。
1. を SVN に「インポート」する。
もとの名前で VSS フォルダを作成する。
3. に SVN から「チェックアウト」する。
4. に 1. のバックアップをすべて書き戻す。

VSS の管理下にあるか否かは .vssscc, .scc ファイルで管理されており、ここに記録されていないファイル・フォルダは完全に無視される。従って SVN の管理フォルダである .svn が作られても、全く問題なく共存できるというわけ。

運用方法としては、 VSS からソースコードを取ってきたらまず SVN にコミットする。コードの修正中は SVN に対してこまめにコミットし、区切りがついたら SVN にコミットしてから VSS にチェックインするという手順を取っている。
これなら、たとえ VSS によってソースコードを破壊されたとしても、SVN から元に戻すことができる。