4/30(Tue)
/** GW出勤 */
初日から22時かよ...(T_T)
待機時間が長かった上に、もう自分の仕事を進める気も起きなかったので、
ARCountというツールを使って、ステップ数を数えてました。
このツール、再帰処理が行えないらしく、
いちいちいちいちいちいち、
ツール起動を繰り返しちゃあ、出力されたCSVファイルを適当な名前に変えて...
の繰り返し(T_T)
思わず、ホームページまで乗り込んで、改善要望出してしまいました(>_<;
まあ、フリーソフトだから、文句は言えんのですが...
ちなみに、Javaだったらこんなのがあります。
というか、うちの後輩に教えてもらったんですが(^^;
再帰処理してくれる代わりに(?)、メソッドが長すぎるだの、なんだのって、
うるさいのが特徴です(^^;
まあ、それはさておき、改善要望が通るのを祈りましょう。。。
(ていうか、自分で作るか? → めんどい...(T_T))
4/29(Mon)
/** WindowsXP */
エクスプローラのフォルダでコマンドプロンプトを開く方法を仕込んだら、
エクスプローラでフォルダをダブルクリックする度に、
コマンドプロンプトが開くようになってしまいました(T_T)
それで、とりあえずコマンドプロンプトの設定を消そうと思っても、
グレーアウトしてて、変更できないし(>_<;
なんじゃこりゃーって感じですよね(T_T)
XPでは(Home Editionだけかも知れないが)、Administratorになるのに、
なぜかセーフモードにする必要があるらしいのですが、
試しにAdministratorでExplorerをいじってみても、同じ現象でした(T_T)
仕方が無いので、適当にレジストリをいじることに決定!
どうせインストールしたばっかりだし(^^;
フォルダの設定に関する情報は、
HKEY_CLASSES_ROOT/Directory
にあることが判明。
早速、commandを消してみることに。
が、今度はなぜかダブルクリックする度に、新しいウインドウが開いてしまう始末(T_T)
どうあがいても、新しいウインドウが開いてしまうので、
もう、おとなしく再インストールした方が良いかも知れません...
4/28(Sun)
/** WindowsXP */
Pentium4に換装した際に、Windows98を再インストールしたんですが、
なぜか、Windows Media Player7が、再生と同時に落ちるという、
意味不明な現象に見舞われ、再起動したり、再インストールしても直らなかったため、
もう、「Windows98はダメだ!」と、
勢いだけで、WindowsXPを買ってきてしまいました(T_T)
今のところ、一応Media Playerの不具合も発症せず、使えてるっぽいです。
これで、動く! 改造バカ一台が見られるってもんです(^^;
まあ、NTベースに移行したことで、
コマンドプロンプトの使い勝手が良くなったり、
C#コンパイラが動いたりと、
開発マシンとしては、良い感じになるのではないかと思ってます。
そういえば、今までCドライブをFATとして使っていたせいなのか、
NTFSにしたら、体感速度上がった感じがします(^^)
なんにしても、妙な不具合が出ないといいですね...
4/27(Sat)
/** これから結合テスト */
これから先リリースに向けて、時間的に厳しくなっていくんですが、
よくあるパターンとして、仕様変更による修正によって、
想定外の部分に影響が及び、混乱するというものがあります。
これの原因は明白で、修正した部分のみテストを行っているか、
もしくは、時間的関係でテストが省かれるからです。
では、なぜデグレードの可能性を消すために、
全体的なテストを行わないのでしょうか?
それは、少し考えれば分かりますが、
規模に応じて、手作業によるテストが現実的で無くなるからです。
これが根本原因だと言えるでしょう。
「じゃあ、テストを自動化すればいいじゃん。」
と、簡単に考えるかも知れません。
例えば、JUnitのようなテストフレームワークを用いて、
テストの自動化を試みようとします。
しかし、入力データを与えるのも、テストスクリプトを書くのも、期待値を考えるのも、
すべて人間が行わなければならないのです。
つまり、自動化するには、それなりの準備が必要になります。
(※単体テストレベルなら、コードを読み込んでテストケースを設定するツールもあるようです。)
逆に言えば、テストの準備さえしっかり行っておけば、
テストを自動化でき、テストの実施にかかる時間を抑えることが可能になります。
一般的に、
((テスト自動化の準備時間) + (自動テストの実行時間) * n) < ((非自動テストの準備時間) + (非自動テストの実行時間) * n)
(n: 仕様変更の回数 = テストの実施回数)
の式が満たされる場合、テストを自動化した方が良いことになりますが、
仕様変更というのは、頻繁に起こり得るものであり、
上の方でも述べている通り、(非自動テストの実行時間)は手作業でのテストを意味するため、
自動テストに比べ、非自動テストは不利になる可能性が高くなります。
当然、これから行おうとしている結合テストには、
自動化の概念を持ち込むつもりです。
「理想論」で終わらせないために...
この試みの成果は、プロジェクトが終わった時に、明らかになっていることでしょう。
4/26(Fri)
/** 昇給 */
2.2%upだが、元がショボいので、どうにも(T_T)
ただ、これからお金使う時間が無くなる恐れがあるので、
逆にたまる可能性あり(T_T)
そんなんでいいのか...
/** GW */
10連休はムリ。
/** 引越して近くなったけど... */
単に睡眠時間が増えただけ(T_T)
昨日辺り、9時間半とか寝てるし...
4/24(Wed)
/** プチ"インスペクション"プロセス */
しゅーりょー。
問題点1項目につき、確認時間は1.5分でした。
理想値は、1分/項目だから、ちょっと遅いんですが、
まあ、初めてやったにしては、早かった方でしょう。
(結構、準備を入念にやったし。)
問題点が31項目で、全打ち合わせ時間は45分と、
短く、かつ、すっきりと終わることができました(^^)
やっぱり、打ち合わせはこうでなくちゃって感じです(^^;
2年ぐらい前の新人だった時、レビューでボロボロにたたかれたのを思えば、
「ちょっとは成長したんじゃない?」
と思える、なかなかナイスな一日でした(^^)
/** VSSはまり道... */
VSS(Version7かな?)に、Unicodeなソースを突っ込むと、
「バイナリファイル」と認識してしまい、
その後、UnicodeからSJIS等に変換したソースをチェックインしても、
履歴を使った差分を取ることができなくなります(T_T)
今回のプロジェクトでVSSを使用開始したのが、
ちょうど1ヶ月前ぐらいなので、
その間まったく気づかず...でした(>_<;
これを直すには、完全破棄して登録し直すしか無いっぽいのですが、
履歴が消えてしまうので、かなりイケてません(T_T)
ただ、全バージョンを一つずつ登録し直しても、
タイムスタンプがずれるので、あんまり意味ないです。
悩みどころなんですが、
まあ、一応履歴管理はできてるし、
差分は、VSSの外部でdiffっぽいのを使えば取れるので、
多少不便になるだけでいいかなぁ。
とか思ってます。
今回に関しては、VSSがどうこう言うより、
「Unicodeでソース書くかぁ?」
っていう辺りが問題だったのでしょう。
4/21(Sun)
/** CVS導入 */
と言っても、自宅開発環境にWinCVSですが(^^;
仕事では、VSS(Visual Source Safe)ですが、
とてもそんなもの個人で買うはずもなく、
妥当な線で、CVSに決まったのですが、
まあ、コマンドラインで操作するのもなんなので、
WinCVSってのにしてみました。
導入にあたっては、
http://www.interq.or.jp/japan/s-imai/tcltk/wincvs.html
のページが参考になりました。
バージョン管理が無いと、
「このファイルを大きく変えるから、どっかにコピー取っといて...と。」
とかやって、ファイル名に日付とか付けたりするんですが、
しまいには管理が不可能になるという事態に陥りがちでした(T_T)
これで、ソースコードを実験的に直すのも、大きく改変するのも、
自由にできるようになりました(^^)
まだ使い始めたばっかりなのですが、
複数人チェックアウトがデフォルトで可能っていう、CVSの思想さえ分かれば、
WinCVSで、十分運用が可能な気がします。
うちみたいな、レヴェルの低い現場だと、導入まで行くのは大変そうですが...
なんせ、VSSはOfficeと同じで、「買ってもよいソフト」になってるみたいだし(^^;
まあ、お金無いところには、最適のバージョン管理システムでしょう。
/** Servletの文字化け対策 */
今までは、「URLDecoder#decode(String)」でやってたんですが、
J2SDK1.4からは、URLDecoder#decode(String)はdeprecatedになり、
その手は禁じ手になったみたいです(T_T)
ここに書いてあるような対策をするか、
国際化対応している、Servlet API2.3(tomcat4以降)を使うしか無いっぽいです。
う〜ん。どうしたもんかなぁ...