検索

• 2010年春季放送開始の新作アニメ一覧 - GIGAZINE
  • http://gigazine.net/index.php?/news/comments/20100305_anime_2010spring/

諸事情で、スクエニの「ガンガンWING」や「ヤングガンガン」を読んでいた時期があるのだが、当時から注目していた作家二人の作品がアニメ化ということで、嬉しいですねぇ。

• "WORKING!"
  • http://www.wagnaria.com/
  • 原作が４コマ漫画なので、あの日常がどう料理されるか楽しみです。
• StarChild:荒川アンダー ザ ブリッジ
  • http://www.starchild.co.jp/special/arakawa_ub/
  • 原作の中村光さんって、ガンガンWINGの当時から「中村工房」という不条理ギャグを描いていて、スゴイ味のある絵で大好きでした。まさかアニメになるなんて・・・一ファンとしても信じられません。
  • っつーか「監督：新房昭之」、さらに"アノ"シスター役が子安武人って時点で確信犯しかありえねぇだろう！！

スクエニ系では既に多くの作品がアニメ化されているのですが、今回は自分が贔屓にしていた作家で、なおかつ「え、まさか・・・あれがアニメ化？」と驚かされた２作品でした。

大学最後の年に購入し、ずっと本棚の肥やしになっていたが、ここ１週間ほどで全て読了した。

• WindowsOS内部のアーキテクチャのすべて

DOS時代の呼び出し規約が気になって Bochs + FreeDOS でDOS環境を構築したのだが、メモリ関係だけで conventional memory/UMA/HMA/UMB/EMS/XMS と何種類も存在し、DOS上でプロテクトモードを活用する為のDOS ExtenderだのVCPIだのDPMIだのの森の中を迷う寸前、「駄目だ、そもそもMS-DOSが開発されたきっかけ、IBM-PCの前後から歴史を紐解かないと」と、本棚にず～～～っと挟まっていたこの本を取り出した。

amazonの書評にもあるとおり、ぶっちゃけ同じ説明・同じ図がウザイ程何度も繰り返されるのがネックではあるが、CP/Mから歴史を順繰りに追っていく構成自体は分かりやすかった。まぁ、同じ説明・同じ図については殆ど読み飛ばしでも問題ない。歴史を俯瞰するには貴重な資料だと思う。
とはいえ、x86の初心者が読みこなせるような本ではない。というのも、やっぱり同じ説明と図の繰り返しが多すぎて読んでいて疲れてきてしまうからだ。
はじめて読む486―32ビットコンピュータをやさしく語る か、 作りながら学ぶOSカーネル―保護モードプログラミングの基本と実践 を一通り読み込んでプロテクトモード・ページング・TSSを把握した上で、その辺の記述を読み飛ばせるようになってしまえば、この分量にも立ち向かえるだろう。というか、ずっと本棚の肥やしになってたのはそのせいかもしれない・・・。

・・・購入してから、6年が過ぎていたんだな・・・。

長い回り道だったけど・・・戻ってきたよ。

• [ Prev ]
• [ Next ]
• [ 技術 ]

半分ネタ、半分本気。

リズム駆動開発(Rhythm-Driven-Development)の目的

「リズム感」をソフトウェア開発に導入することにより、個々人のプログラマの生産性を向上させる。

実施方法

特に開発フェーズにおいて以下の３ステップをリズミカルに繰り返し、プログラマが快感と安心を得られるようにする。

1. コードを書く。
2. コードを実際に動かしてみて動作確認する。
3. コードを洗練する。(できれば設計も)

より具体的には、例えばテスト駆動開発(TDD)が挙げられる。
TDDの場合、上の「コードを実際に動かしてみて動作確認する。」部分にxUnitなどのテスティングフレームワークを導入することで、この３ステップをコード全体で素早く回せるようにしている。また、続く「コードを洗練する。」のフェーズでデグレ予防の効果もある。

TDDと同様に、この３ステップは細かいサイクルで繰り返す。

プログラマの快感

動くコードを書き、洗練させていく快感

プログラマの安心

細かくコードの動作確認を行うことで、漸増的にコードを洗練させてもデグレを防ぐ安心感

これら「快感」と「安心」を得られる３ステップを繰り返すことで、開発作業に「リズム感」「心地よいテンポ」を導入し、生産性を向上させる。

なぜ「テスト」ではなく「動作確認」という表記なのか？

1. 品質保証(QA)での「テスト」という単語と明確に区別したいため。
2. プログラマにとって「よし！出来た！」と思える水準が「動作確認」であり、次の「洗練」フェーズへ進む為の条件。極めて主観的な基準点であることを明確にしたいため。

"「個々人の」"と限定しているのはなぜ？チームとは関係ないの？

「あ～、ノッてきたな」と思えるリズム感やテンポには個人差があるため、「プログラマ全体」ではなく「プログラマ個々人」と限定している。

ペアプログラミングを活用してチーム全体にRDDの３ステップを浸透させる事が可能であれば、チーム全体でRDDのメリットを享受出来る可能性はある。その場合はペアプログラミングと同時にTDDも併せて導入するとより効果的かも知れない。

(参考)RDDと正反対の開発手法(ウォーターフォールの一例)

1. 設計を100%完成させる。
2. 100%完成された(と思われる)設計に基づき、ひたすらコーディングする。この間、コンパイルはするが実行はしない
3. 完成されたコーディングを基に、ようやく実行し、テストを開始する。

• RDDでは細かいサイクルでコードを実行し動作確認するため、未完成の状態でも、例えばある関数が動くようになれば気軽に実行・動作確認する。これは上記のサイクルとは相容れない。
• RDDでは「洗練」フェーズでコードの重複を取り除いたりクラス構成/メソッド・関数のインターフェイスを修正したりするが、これは「100%完成された設計に基づきコーディングする」という上記のサイクルとは相容れない。

(参考)RDDが非常にやりづらい開発手法の例

以下のような条件が整った開発風土の場合、RDDの導入は難しいだろう。

1. コーディング段階で設計上の問題を指摘すると、「設計バグ」として品質管理上かなり問題視される。
2. オブジェクト指向言語であれ、Cなどの構造化言語であれ、ファイルモジュールからロジックの詳細まで、ほぼ関数/メソッド呼び出しと一対一で対応するレベルまで詳細に記述された設計をドキュメントとして残し管理している。

RDDではプログラマ自身がコード、ひいては設計を洗練させる過程が重要で、これがプログラマの「快感」を引き出し、生産性向上につながると捉えている。
上記のような環境では、プログラマがオブジェクトの構成や関数/メソッドのインターフェイスを修正するのに多大なコストと心理的な抵抗が発生する為、「洗練」フェーズを思うように作業出来ずテンポが乱れる。

ただしプログラマ側が「こういうやり方だ」と割り切り、「洗練」フェーズを無くした２ステップをリズミカルに繰り返せるのであれば、RDDの目的である「リズム感」により生産性向上を図れる場合もある。

「洗練」フェーズをスポイルすることで「快感」は減少するが、それでもプログラマ自身がリズム感を感じている限りは、RDDの目的は果たせているだろう。

よくある誤解

RDDやTDDを導入すれば幸せになれる

銀の弾丸など存在しない。

xUnitの導入が必須

必須ではない。もちろんRDDの手法の一つ、TDDを活用すればxUnitによる自動化されたテストスイートが結果として出来上がるが、それは単なる副産物の一つである。重要なのは開発時にプログラマがリズミカルに開発に専念できることであり、それがxUnit以外の方法で達成出来るのであればそれでよい。「実際に動かして動作確認」→「洗練」のサイクルを、人間の手だけで素早く回せ、かつ洗練のフェーズでもデグレ防止で特別にxUnitによる自動化テスト一式が必要でなければ、それはそれでOK。

テストファースト/TDDでなければならない

上と同じ理由により、リズミカルにプログラミング・動作確認・洗練ができれば、テストファースト/TDDでなくとも良い。

何が何でもテストを書かねばならない

上と同じ理由により、テストを書かなくとも良い。テストコードを書くのはリズムを保つ為である。たとえばGUIのユーザインターフェイスであったり、並行/並列処理であったり、非同期処理であったり、入出力デバイスやネットワークとのインターフェイス部分などテストコードを書くのが難しい部分については、少なくともRDDにおいては、無理してテストコードを書く必要はない。重要なのはリズミカルな開発であり、そうしたテストコードを書くのが難しい部分で"嵌って"しまうのは本末転倒である、とRDDでは捉えている。

品質向上に寄与する

RDDは、極論すればプログラマが「ノリノリだぜ～ヒャーーーハハッ！！」状態で開発する為の技法なので、品質向上とは関係ない。慎重派のプログラマが「動作確認」のフェーズで、xUnitにより緻密なテストコードを構築して品質が向上する場合はあり得るが、そうでないプログラマが、例えxUnitによるテストコードを構築したとしても、正常系しかテストしていなかったり境界値分析やデータパターンのバリエーションが不十分であったりする場合も当然あり得る。特にテスト駆動開発を活用したRDDの場合、「テスト」という単語から品質向上/品質保証(QA)と関連があるのではとミスリードし易いが、基本的には無関係である。

RDDにおけるxUnitなどによるテストコードの存在意義、そして「快感」と「安心」

RDDではテストコードは必須ではない。なぜなら、必須としてしまうと、自動化テストが難しい部分までテストコードを書こうとして、却ってリズムを崩してしまいかねないからだ。

とはいえテストコードを書けそうな部分であれば可能な限り書いた方が良い。なぜなら「洗練」フェーズにおけるデグレ防止のセーフティネットとして機能するからである。

RDDでの「快感」

細かいサイクルで動くコードを洗練させていくリズム感。

RDDでの「安心」

テストコードを書き自動化テストを構築することで、特に「洗練」フェーズにおいて安心してコード、さらには設計を洗練できるようにする。

自動化テストを活用する時に、絶対にやってはいけないこと

「xUnitのテストコードがあるんだから、Excelでぎっちり作り込んだテスト仕様書に従ってテストするなんて面倒くさくてやってられねぇよ！」

これは単なる思い上がりと怠慢である。
何度も繰り返すが、RDDにおいてはxUnitなどの自動化テストは品質保証とは関係ない。

Excelでぎっちり作り込んだテスト仕様書に基づいたテスト作業が、組織の開発プロセスに組み込まれているのであればそれに従った方が良いだろう。規模が大きくなるにつれそうした現場は増えてくるだろうが、同時にプログラマのレベルのばらつきも大きくなってくる。そうすると当然、テストコードの質のばらつきも大きくなる可能性が高い。
テストコード自体のレビューを頻繁に行い、境界値分析・異常系・データ入力パターンの過不足・コードの網羅率などを全体で改善できるのであれば品質向上にも寄与できる。
しかし、そこまでのマンパワーが無い場合は「RDDで構築した自動化テストはあくまでも開発者のもの」と割り切って、品質保証としてのテスト作業を謙虚に実施した方が良いかも知れない。

もちろんケース・バイ・ケースではあるので、組織によってはTDD導入の結果得られた自動化テスト一式を以て単体テストレベルを担保できるケースもあるだろう。

なおあえてテスト仕様書の種類(単体/結合/システム)は特定しなかった。実際の組織や現場に応じて、xUnitによる自動化テストコードの立ち位置は調整が必要だろう。

（以下、思いついた時に随時追記）

• [ Prev ]
• [ Next ]
• [ Up ]
• [ 技術 ]

　　　　　 　　　＿＿＿_
　　　　　　　／　　　u　＼　　　　　　すげーお、OpenWatcomのCコンパイラ、
　　　　 　／　　＼　 　 ／＼　　　　"__cdecl", "__fastcall", "__stdcall", さらには
　　　　／ 　し （○） 　（○） ＼　　"__pascal", "__fortran" 呼び出し規約までサポートしてるお。
　　 　 |　∪　 　 （__人__）　 J |　　　速攻でOpenWatcomに鞍替えするお。
　　　　＼　　u　　 ｀⌒´　 　／　　　呼び出し規約実験するのにこれ以上の環境はねーお。

see: OpenWatcom Manuals, "C Language Reference", A.2 Open Watcom Extended Keywords

　 　　 　　＿＿＿_
　 　　　／　　 　 　＼　　　　　長かったお・・・
　　　／　 _ノ 　ヽ､_　 ＼　　　　Web開発に膿み疲れ、人間関係で会社を辞め・・・
　 ／ oﾟ(（●）) (（●）)ﾟo ＼　　　積み残しの本を消化し始めて・・・
　 |　　　　 （__人__）'　　　　|　　以下略の事情でDOSの世界に・・・
　 ＼　　 　　｀⌒´ 　 　 ／

　 　 　　　＿＿＿_
　 　　　／　　 　 　＼
　　　／　 _ノ 　ヽ､_　 ＼　　　ぶわっ
　 ／ 　oﾟ⌒　　　⌒ﾟo　 ＼
　 |　　　　 （__人__）　　　　|
　 ＼　　 　 ｀ ⌒´ 　 　 ／


　　　　　　＿＿_＿_
　　　　 ／　ノ'　＾ヽ_＼　　　　　戻ってきたんだお！！
.　　ﾟ ／ ｡;'⌒） 　（⌒ヽ＼°　　　DOSと、TurboC++4.0Jが復活したお！
.　 ／　o'ﾟ~（___人___）~o°＼゜　　msakamoto-sfのプログラミングの原点に、
.　 |　　 　 ﾟ　|/⌒ヽ| 　ﾟ　 　 |　　　ようやく戻って来れたお！
　　＼　　 　 ｀ ⌒ ´　　　 ／


　　　　　 　　　　＿＿＿
　　　　　　 　 ／　　　　　＼
　　　　　　 ／　　 ＼ ,　, ／＼　　いよいよ・・・復活させるんだお！
　　　　　／　 　 （●）　 （●） ＼
　　　 　 |　　 　 　 （__人__）　　　|　　FreeDOS + DJGPPで、
　　　　　＼　 　 　 ` ⌒ ´　　,／　　　「はじめて読む486」を復活させるんだお！
　　　　　　ノ　　　　　　　　　　＼
　　　 ／´　　　 　 _i⌒i⌒i⌒i┐ ヽ
　　　 |　　　　ｌ　 （ l　/　/　/　l
　　 　 l　　　　l 　ヽ 　　　　　 /


　 　　　＿＿＿_
　　　／　　 　 　＼ （ ;;;;(　　　いや・・・まぁね？今でもベストセラーなのは
　 ／　　＿ノ　 ヽ__＼) ;;;;)　　知ってるけどね？
／ 　　 （─） 　（─ /;;／
|　 　　 　 （__人__） l;;,´|　　サンプルコードを試せる環境が無かったわけで。
./　　　 　 ∩ ノ)━・'／　　やっぱり自分で試してみたいなーと。
(　 ＼　／ ＿ノ´.|　 |　　コンパイラやDOSのカーネルが当然違ってくるので、
.＼　 " 　／＿＿|　 |　そのまま上手く行くわきゃないとは思うけど、まぁ
　　＼ ／＿＿＿ ／　　それも勉強かなーと・・・ね。



　　　　　　＿＿＿_
　　　　 ／_ノ '　ヽ_＼　　　まぁ、所詮自己満足だし・・・
　　　／（≡） 　 （≡）＼　　ぼちぼち試してみるお！
　 ／ /// （__人__） ///＼
　 |　　　　　|r┬-| 　 　 　|
　 ＼ 　 　　｀ ー'´ 　 　／

• [ Prev ]
• [ Next ]
• [ 技術 ]

Bochsのインストール

Bochsを本家からDLし、インストール。今回はBochs-2.3.7を使った。以前アセンブラの勉強した時にインストールしたのが残ってた。

加えて、以下のURLから修正されたWin32バイナリを取得し、bochs.exeを上書きする。

• がじぇっとぼっくす
  • http://ebisa.hp.infoseek.co.jp/bochs/index.shtml

本家のままだと、FreeDOSでスラッシュ/バックスラッシュが入力出来ない。修正後のbochs.exeを使えば、入力出来るようになった。

FreeDOSのインストール

まず本家からインストール用のISOイメージをDLする。タイミングの問題か、回線がやたら細くて２回ほどDLに失敗した。
8MB位の基本セットをDLしてもよいが、今回はソース付フルセット(240MB)をDLした。

Bochs同梱のbximageを使ってHDDイメージを用意する。
フルセットの場合、フリーの開発環境などかなりてんこ盛りでくっついてくる為、100MBでは容量が不足した。余裕を見て1GBの固定サイズHDDイメージを準備した。

Bochsの設定ファイルを調整し、ATA接続のHDD, FreeDOSのISOファイルを使えるようにして起動。
あとはFreeDOSのインストーラが面倒を見てくれるので、Win95時代とかのノリで適当にFDISKなど進めていけば良い。

ata0-master: type=disk, path="hd_flat1g.img", mode=flat, cylinders=2080, heads=16, spt=63
ata0-slave: type=cdrom, path="freedosimg/fdfullws.iso", status=inserted

インストール途中で言語を聞かれる。最初の選択肢にはJPは入っていないが、詳細選択できちんと用意されている。japanを選択すれば、ホスト側の日本語JP106キーボードが使えるようになる。

日本語フォントの設定

以下のページより、FreeDOS/V 珠洲版 を入手する。

• FreeDOS/Vページ
  • http://homepage1.nifty.com/bible/fdos/

FreeDOS/Vの起動ディスクから、fontnx.exe、vesapat.exe、dispvb.exe、fntファイル、fontn.iniをハードディスクにコピーする。

fdconfig.sysに以下の行を追加する。"\dos\"の部分は各自のコピー先にあわせる。

devicehigh=\dos\fontnx.exe
devicehigh=\dos\vesapat.exe /JP
devicehigh=\dos\dispvb.exe /hs

これで再起動すれば日本語フォントが有効になる。

ただし、自分の環境では日本語フォント有効の状態だとFreeDOSが提供するviなどコンソール制御をしている(?)プログラムが正常に表示されなくなった。BochsかFreeDOSか、どのコンポーネントの影響なのかは不明。
fdconfig.sysには起動時メニューを選択出来る設定があるので、当座はこれを使って起動時に切り替えられるようにした。
fdconfig.sys:

MENUDEFAULT=2,5
MENU 1 - Load FreeDOS with EMM386, no EMS (most UMBs), max RAM free
MENU 2 - Load FreeDOS with EMM386+EMS and SHARE
MENU 3 - Load FreeDOS including HIMEM XMS-memory driver
MENU 4 - Load FreeDOS without drivers 
MENU 5 - Load FreeDOS with EMM386+EMS and SHARE, JP FONT pack << これを追記。
...
DOS=HIGH,UMB
1235?DEVICE=C:\FDOS\BIN\HIMEM.EXE 
1?DEVICE=C:\FDOS\BIN\EMM386.EXE NOEMS X=TEST
25?DEVICE=C:\FDOS\BIN\EMM386.EXE X=TEST
1235?DEVICEHIGH=C:\FDOS\bin\xcdrom.sys /d:FDCD0001 
1235?DEVICEHIGH=C:\FDOS\bin\cdrcache.sys FDCD0001 CDRCACH0 1000 
1235?DEVICEHIGH=C:\FDOS\BIN\MORESYS.SYS 
SHELLHIGH=C:\FDOS\bin\command.com C:\FDOS\bin /E:1024 /P=C:\autoexec.bat 
1235?INSTALLHIGH=C:\FDOS\bin\lbacache.com 1000 TUNS 
5?DEVICEHIGH=C:\DOSV_JP\FONTNX.EXE
5?DEVICEHIGH=C:\DOSV_JP\VESAPAT.EXE /JP
5?DEVICEHIGH=C:\DOSV_JP\DISPVB.EXE /hs

"123"や"2", "3"の部分に5を付け足し、5を選択された場合もEMM386が使えるよう調整している。

DJGPPなどを軽く弄る程度であれば通常は日本語フォントOFFで問題ない。TurboC++ 4.0Jもデフォルトは英語メニューで、日本語フォントOFFでもIDEは問題なく動作する。（ヘルプドキュメントは日本語なので当然文字化けする）

参考

【本家】

• FreeDOS | The FreeDOS Project
  • http://www.freedos.org/
• FreeDOS Wiki
  • http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Main_Page
• bochs: The Open Source IA-32 Emulation Project (Home Page)
  • http://bochs.sourceforge.net/

【Bochs独自ビルド】

• がじぇっとぼっくす
  • http://ebisa.hp.infoseek.co.jp/bochs/index.shtml

【FreeDOS日本語対応情報】

• DOSのインストール(FreeDOS編) — KtJ Dragon
  • http://www.ktjdragon.com/ktj/misc/how-to-set-up-dos/dos306e30a430f330b930c830fc30eb-freedos7de8
• FreeDOS/Vページ(珠洲版)
  • http://homepage1.nifty.com/bible/fdos/

【FDやHDDイメージをWindows上で操作出来る WinImage(シェアウェア)】

• Gilles Vollant software
  • http://www.winimage.com/

• [ Prev ]
• [ Next ]
• [ Up ]
• [ 技術 ]

• [ Prev ]
• [ Next ]
• [ C言語系 ]

Borland C++ Compiler での、コンパイラ/リンカオプションやライブラリなどの早見表、および C言語系/memos/BCC/01, Win32のEXE,LIB,DLL開発入門(C言語) では取りあげなかったミニTipsなど。

デブサミ2010のTDDのセッションを聞いたりもしてきて、ふとはてブ見てたら

• TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
  • http://d.hatena.ne.jp/goyoki/20100223/1266939139
• 最近の TDD 議論についてちゃんと僕の気持ちを書いてみる - YoshioriのBlog
  • http://d.hatena.ne.jp/Yoshiori/20100224/1267015034
• Togetter(トゥギャッター) - まとめ「深夜のテストTL」
  • http://togetter.com/li/5878
  • http://togetter.com/li/6759
  • http://togetter.com/li/6923

とか出てきていた。

デブサミ2010のセッションでも、「TDDの『テスト』は品質保証(QA)を目的としていない、開発者の為のテストだ」というのを強調していた。
どうやら品質保証周りのQAと「テスト」という単語を中心に話が噛み合わないためらしい。

セッションを聞いた後に思ったのだけれど、開発者の「不安を無くすためのテスト」って、自分の場合、開発者＋単体テスト＆結合テスト項目洗い出し＋テスト実行とほとんど一人でこなしてきた為、「不安を無くす」＝「単体テストレベルの細かさのテストケースを実装しないと不安を解消出来ない」んだよな・・・。

現場やプロジェクトにより・・・

• プログラマが「プログラミング完了！」と思えるレベルもバラバラ
• 「単体 or 結合テストの設計、誰がするの？」もバラバラ
• 「単体 or 結合テストってどの粒度？」もバラバラ
• WEB/RIA/ネイティブGUI/バックグラウンドサービス(デーモン)/マルチスレッド/DB/通信 と、ソフトウェアの種類もバラバラ
• 「このソフトウェア、要求仕様満たしてるね！」と判子を押すキーマンのポジション・力関係もバラバラ
• TDDを継続する熱意を持ったプログラマが『継続してその現場に何人、何年いるか』もバラバラ

TDDを取り巻く状況は、さながらバベルの塔建築中に神様の怒りをかって言葉を分断されたかのようだ。

ぜぇぇ～～～んぶ、バラバラで・・・個人的には「もうついていけませぇぇえ～～～ん」状態。
もうやりたい人がやってみる、でいいんじゃないのかな。

世界はそこまで綺麗になれないと思う。

一部の開発者にとって綺麗で魅力的でやってみたら実際楽しくて役に立つ開発手法なんだけど・・・
周りに、進められる / 「これやりましょう！」と自信を持って周囲を引っ張っていける / 継続して推進できるほど・・・

自分は周囲の開発者を期待してないし、何より自分自身の「本当に周りのためを思ってTDDを進めているのか？単に先進(と思われている)の開発手法を周りに見せつけて、『ほ～ら自分、こんなに勉強してるんだぞ、スゴイダロ』と自慢したいだけじゃないのか？」という部分にいつまでたっても疑問符が付いてしまう。

TDDをしなくても/知らなくても、きっちりとしたソフトウェアを開発してくれる、信頼出来る開発者は昔から居たし、自分も知っているし、実際にそうした人と仕事をしたこともある。
けっしてWEBDB PRESSを購読していたり、ITニュースを毎日チェックしたり新しい技術にすぐ飛びつくわけではない。でもプロジェクト管理やメンバーのメンタル管理含めてトータルにきっちりした仕事をする先輩も居た。

結局、自分も信じられないし世界も信じられないだけなのかも。「いや、理屈じゃTDDはすごいけど、現実はね・・・」ってそれなんていう老害？

というか、TDDにしたってアジャイルにしたって、み～～～んな、「海の向こう」からだよね。
ルールは全部「海の向こう」からの輸入物。輸入されたルールの中で可能な限りもがくのって日本人らしいといえば日本人らしいよなとも。

あれでしょ？数年後、「海の向こうの○○氏」が「開発者を幸せにする○○手法」とか本出したら、今度は手放しでそれをもてはやして、Blogだのなんだのに「○○手法というのを試してみた」とかいうエントリを挙げて、「個人やWeb開発などフットワークの軽い組織でなら導入しやすくて効果を実感云々」とか書くんでしょ？
Google様が、あるいはどっかのハッカーが「○○サービスを公開！」とかニュースに出てくるたびに、「○○サービスを使ってみた」とか書くんでしょ？で、実際にサービスを活かしてお金儲けするのはどっかの誰かさんで、プログラマはな～～～～んも、関係ないんでしょ？

もう付き合うの、疲れたよ・・・。

自分はTDD結構好きなので、自分ではこれからもTDDを活用するけど、周りに対しての「啓蒙活動」はもういいや。Web開発の現場から今は離れてるっていうのもあるけど、ゴメン、正直、Web開発の世界は流行廃りが早すぎてついていけなくなった。

どこまでも知識を追い求めて「勉強出来る、何でも知ってるよい子」になろうとしたがるクソ真面目一辺倒の人間には、Web開発の世界は辛すぎたわ。

【追記】デブサミ2010で発表されたご本人のBlogエントリ追記。またTwitterのまとめURLも追記。

品質保証の世界とで議論が白熱しているが、逆に言えば「TDD」という火種が原因で今まであやふや・曖昧にされてきた「品質保証」や「テスト」の定義や理想などが議論されだしたので、これはこれで良いのかも知れない。自分も含めて、今まで恐ろしく無自覚に「品質」だの「テスト」だの口走っていたことがあられもなく曝された訳だwww そのクセ結局業界標準はおろか、議論に加わるような真面目な人達の間ですら了解が得られていなかった事が白日の下に曝された次第www

個人的にはTDDは好きなので、やりたい人から/やりたいチームで、ゆっくりと試行錯誤しながら広めて行ければいいんじゃないかな。xUnitなりなんなり、美味しいとこだけつまみ食い、というのも有りだと思うし。
最後に、自分としては「品質保証」とTDDに関係があったこと自体が驚きで、どちらかというと「インターフェイス/APIを早期に洗練させる」のに効果的だったかなぁと思ってます。あとはxUnitフレームワークによる自動化と、それによる回帰テストの自動化、とか。

See you again, TDD.

俺はバイナリの世界に潜るから。アデュー。

先日引っ越してKDDIのADSL引いたのだけれど、引っ越した先のアパートでこんどはアパート全体としてNTTのBフレッツを導入することになった。
で、当然電話も光電話?になるらしい?が、今の電話番号がKDDIで発番されたものらしく、NTT側に切り替えるとなると電話番号の変更になってしまうらしい。

なんで携帯電話にナンバーポータビリティがあるのに、固定電話には無いんだあぁぁああ・・・ヽ(｀Д´)ノ

理不尽だ。
2000年当時、大学入学で上京した時に7万位の金額払って固定電話の加入権買ったのがむなしくなってくる・・・。

知らなかった・・・

• NoSQL Libraries « MyNoSQL
  • http://nosql.mypopescu.com/post/276069660/nosql-libraries