プログラミング C# - 翔ソフトウェア (Sho's)

最近の流行り (謎) らしいので、9/6 からダイエット開始。
今日までで、約5キロ減。

• 自転車を購入して自転車通勤
• 万歩計を購入してウォーキング
• PC にデータを転送して管理できる体重計を購入
• 食事制限
• 酒量に変更なし

ちょっと残念だったのは、『XP祭り2006関西』には5キロ減らしていったのに、誰も気付いてくれなかったこと。まあそりゃそうか。
自分を褒めたいのは、その『XP祭り2006関西』で三次会まで行ったのに、殆ど食べないようにしたため、帰った後で全く体重が増えていなかったこと。
# 大阪行ったのに、お好み焼きもたこ焼きも我慢したのは評価できる。

ISO9001 についてマインド マップを描いてみた。

※ クリックすると拡大。

# それにしても、俺って ISO9001 が嫌いなんだなあ。

※ 昨日の『ISO9001について』の続き。

昨日のマインドマップ付きの記事に関して、貴重なフィードバックを頂いた。ありがたいことだ。

頂いたフィードバック:

• 「運用設計の問題」
• 「運用の問題」
• 「典型的な ISO9001 への誤解が多く見られる」

ISO9001 を実践し続けて数年になる。
ISO9001 について思うところをもう少しだけ書き足してみる。

• PDCA のループが軽く速く回らない。品質を保つためには改善活動が不可欠なので、そこが重いのはつらい。
• そして、改善活動というのは改善のプロセス自体が日々改善されていかないようではダメダメだと考えている。例えば、或る時期 ISO で改善していて、数年後も同じ規格で同じように改善しているようでは「なってない」と思う。そして、ISO は ISO であるが故にメタ プロセス自体を進化させるのは難しい。
• それは、「取得 → 維持」という「余計な枠組み」が入ってしまう ISO であるが故の宿命的な「システムが抱える問題」であり、根源的な問題。
• 「守破離」でいうと、「守の段階から抜けようとすると足を引っ張られる感じ」
• ソフトウェア開発のプロセスというのは変化と進化が激しく、その変化の激しさから考えると ISO のそのような特性はボトルネックになるように感じる。
• 「運用設計がまずいと駄目」、「運用が上手ならうまくいく」。ただし、上の理由により、「運用が上手なようなら、ISO9001 がなければもっとうまくいく」とも思う。

先日「けんぞう蕎麦」を雨の中歩いて食べに行ったところ、臨時休業で食べられなくて残念な思いをした話を書いた。
※ 『けんぞう蕎麦』

今日はそのリベンジで、雨の中自転車で「けんぞう蕎麦」に向かった。

三連休の昼時ということで、店の中には五組程の待ちができていたが、今回は無事ありつくことができた。

辛子大根の汁で打ち立ての越前蕎麦を食べる。蕎麦粉100%だが、つるつるの滑らかな蕎麦だ。

美味い。新蕎麦の季節が楽しみだ。

三連休の最終日は、前日に続いて息子と自転車で外出。

素晴らしい秋晴れだった。

三連休の最終日は、とても清清しい良い天気だったので、早起きして家族で動物園へ。

ここ『いしかわ動物園』には、デカばあさんと呼ばれるカバがいるのだ。

いつもは水の中に全身浸かったままじっとしているので、こんな風に全身をじっくり眺められるのはとても珍しいのだ。もう何十年も前から何度も何度も見に来たカバだが、こんなのは初めてなのだ。

デカばあさんは、現在54歳だとかで、人間の年齢でいうととっくに百歳を越えているといわれている。国内最高齢のカバなのだ。

もともとは「カバヤ」の宣伝のために外国から連れて来られたカバなのだ。

※ 以下カバヤのサイトから引用。

1953年（昭和28年）、戦後復興期の日本に、1頭のカバがドイツから来日しました。
推定1歳のメスの子カバは、「カバ子」と名付けられ、カバヤのキャラメルのキャンペーンで全国を回り、本物のカバ自体が珍しかったその時代、カバ子は子どもたちに絶大な人気を誇り、鮮烈な印象を与えました。

フランス・カバ協会がまとめたカバの長寿番付でも堂々の世界第二位なのだ。驚きなのだ。
# っていうかフランスにカバ協会なんてものがあることの方がもっと驚きなのだ。

ともあれ、私が御幼少の砌(謎)によく見にきたカバを、今になって我が子と一緒に見ることができるのだ。すごいのだ。

土曜日は、息子と二人で『土木の日 ふれあいバスツアー』というイベントへ参加。

福井駅前を8時半に出発。
先ずは、九頭竜川の真名川ダムを見学。

真名川ダムは"アーチ式コンクリートダム"だ。
このダムの中腹の通路 (下の写真の水色部分) へいざ出発。

エレベーターでダムの中を50メートルばかり下へ。ダムの中の通路を歩く。かなり涼しく、頭上では水滴が凍っている。

到着。結構高い。

前には噴水が50メートルの高さに上がっている。動力等はなく、ダムの水面差だけで上がっているそうだ。

ダム見学の後は、公園で弁当を食べ、その後、福井県池田町のキャンプ場へ。
水に関するゲームやクイズ大会などを行った。

それから、拾い集めた小枝などを使って時計作り。下の写真は息子が作った時計。

次に、"エコキャンドル" というのを作成。廃油から作る。

そして、出来上がったエコキャンドルを持って、"いけだエコキャンドル"の会場へ移動。

一万本のエコキャンドルが道を照らす。

長い一日だったが、盛り沢山のイベントで私も息子も楽しめた。

一日、良い天気と紅葉が始まりかけた山々に囲まれて過ごせ、とてもゆったりした気持ちになれた。

日曜日は、家族で福井県立恐竜博物館へ。

『Microsoft On - 出張ワークショップ - 最新技術を学ぶ in 福井』
日時	2006年10月20日(金) 13:00～17:15
場所	ふくい産業支援センター 会議室A・B
主催	マイクロソフト株式会社 (共催: 福井情報技術者協会 後援: (株)福井コンピュータ、(株)トゥーアーティ、アル・デザインワークス)
内容	福井で「Microsoft On」による無料セミナーを開催。 第一部「Visutal Studio によるアプリケーション開発実際」 第二部「Windows Vista とWindows開発環境の進化」
講師	マイクロソフト株式会社 デベロッパー エバンジェリスト 松崎 剛 氏

無事終了。

• 参加者数: 35名
• 懇親会参加数: 11名

当初の予定以上に人が集まり、会場はいっぱいになった。
講師の松崎さんの話がとてもよかった。

開始前に「単なる Visual Studio 2005 の使い方の話より、.NET Framework の話を聴きたくて来られてる方が多いでしょう」とのご提案があり、前半のメニューでは、CLR や ＩＬ、アセンブリなどについての「中々 Web サイトや書籍では目に出来ないテクニカルな情報」について話していただいた。

後半は、Vista に関してデモを中心に話していただいた。

単に技術を紹介するにとどまらず、そのテクノロジーがどうして出てきて、今後どのような展望があるのかについて、松崎さん自身の考え方を聴けたのが良かった。「Web サイトや書籍で目に出来ない」生の声を聴くことができた。

コマンドライン上でのツールを使って基本的なことを説明した後で、Visual Studio 上で同じことをやってみせるやり方は分かりやすくて良かった。C# や、ASP.NET、XAML の説明のときにもメモ帳でソースを書くところから説明をしていた。共感できる。単なるドラッグ&ドロップの連続での説明だと見た目は派手だが内容に欠けるのだ。

聴衆を飽きさせずに、常に興味を引き付ける話ぶりは流石だ。参加者の方はその名調子に引き込まれていたようだ。

chikura さんと一緒に松崎さんを福井駅に送る車中で、三人でこれからの新人技術者についてなどの様々な話をした。

その後も懇親会でみっちりと話し合った。久しぶりに少し飲みすぎたが、とても楽しい一日だった。

日曜日は、家族五人で公園へ行って団栗を拾った。

七種類の団栗が見つかった。

ペリカンの万年筆 "M205 デモンストレーター"購入。通称ペリスケ (ペリカンのスケルトンの略)。

# 下の写真はペリカンのブルー ブラック インクを入れて見たところ。

透明でペリカンのインク吸入機構が丸見えだ。ベースはペリカンのトラディショナルシリーズ。ペン先は Mを選択。書き味はサラサラ系。

最近は手書きには万年筆を使用している。特にメモ書きが多い。

私にとっての万年筆の使いやすさの10のチェック ポイントは以下の通り:

1. 持ち運びやすい程度に小さく、書きやすい程度に大きいこと。
2. キャップがネジ式でないこと。キャップレスはさらなり。
3. インクの補充方式が吸入式であること。
4. インクの残量が外から見えること。
5. ペン先が金で柔らかめであること。
6. 強い筆圧にも耐えて、いつまでもペン先がへたらないこと。
7. インクフローが十分で、ヌラヌラ系の書き味 (引っ掛かりがなく滑らかな書き味) であること。
8. 久しぶりに使用しても書き出しからインクがかすれることがないこと。
9. 高すぎないこと。
10. 見た目や書いたときの感触に味があること。

「メモ書き用に常時携帯して書きたいときに気分よくすっと書ける」のが大切。
書き出すまでの手間が掛かりすぎるのは嫌だし、書き出しがかすれたり紙に引っ掛かったりするのはもっと嫌だ。書いている途中で急にインク切れになりそうなのも好きではないし、高価すぎて持ち歩くのに躊躇するほどなのもちょっと。

このチェック ポイントで見ると、今回購入した "M205 デモンストレーター" は、6/10 点。果たして 10 点満点の万年筆は存在するのだろうか。

『404 Blog Not Found ― テキストエディタさえあればできるTDD』について。

※ 「それがわからないのであれば、あなたはTDDがわかってないのだ」という強い言葉に反応。

まず、角谷さんは誤解なんか全然していないように思える。

つまり、「Perl だとちゃちゃっと書けて、面倒くさくない」というのは、まさにハッカーの発想であって、TDD は本来そんなハッカーには不要なものじゃないかということだ。

上記記事より引用:

プログラマーにとって最も偉大な習慣とは、プログラマーでない人たちの立場になってものを考えられるかではないのか。テストを書く人はプログラムを書く人と同じとは限らない。いや、本当のところは違っていた方がいいのだ。

私が「eclipseを使っている人はいいけど」と言ったのは、まさにそのことだ。

それがわからないのであれば、あなたはTDDがわかってないのだ。

記事では、「Perlではこんな簡単に書ける」ということで Perl で書いたテストの例が挙げられている。

しかし:

• 上に書いたが、テストがこんな風にちゃっと書ける、というのは主にハッカーにとっての利点であるように思える。少なくとも「プログラマーでない人たちの人たちの立場」のものとは思えない。記事には「プログラミングを全く知らなくてもテストを書くことが出来る」ともあるが、Perl のテストの例を見る限り、とてもそうは思えない。特別なツールを使わずにテキスト エディタでさっと短くテスト コードを書く、というのは、「プログラマーでない人たち」から見ると逆にハードルが高いだろう。そちらの方が簡単、というのは「プログラマーでない人たち」の視点ではなくハッカーの視点だと思う。
• そもそも TDD の一文字目が表わすのは、「プログラマーでない人たちの立場になった」テストではないと思う。あくまでもプログラマーが設計と実装を行うためのものだ。「テストを書く人はプログラムを書く人と同じとは限らない」とあるが、その「テスト」とは違う。こんな風に、TDD の Test は通常のテストと混同されることが多い。通常のテストと混同されないようにTDD の Test は Test と呼ばない方が良い、という議論もあるほどだ。TDD はあくまで設計と実装を楽にやるためのプラクティスであって、プログラマーのためのものだ。

※ 私は TDD はプログラマーの視点変換ツールだと考えていて、その点に関しては記事の方と意見が共通だ。