T-1000の日記

どうやら、文字コードはUTF-8にしておく必要がありそうです。
（日本語の文字を使用する場合は）

例えば以下のスクリプトをSJISで保存して実行したら文字が化けました。

// ==UserScript==
// @name AmazonAlert
// @namespace Test.Amazon
// @include http://*.amazon.co.jp/
// ==/UserScript==

やっぱりコードを書くのは面白い。

以下のサイトを見てGreaseMonkeyをインストールしてみました。

Greasemonkey入門 ～よくわかるグリースモンキーの使い方 ～

サンプルはGoogleAutoPagerというユーザスクリプトを使って説明されていました。
実際にインストールしてみると、勝手に次のページに移動していて
ブラウザの使い勝手がかなり向上したように思います。

やっぱりJavaScriptも知ってた方が良いみたいですね！
JavaScriptが書けたら同時にGreaseMonkeyも自分でのカスタマイズが可能になる
わけですからね。

前回の勉強会で、「カリー化」についての話を聞きました。
で、調べておくように言われたので（言われたからするわけではないですが、
知っておかないと話に付いていけない可能性が非常に高いので）
調べてみました。

Wikipediaで調べてみると、、、

複数の引数をとる関数を、引数が「もとの関数の最初の引数」で戻り値が「もとの関数の残りの引数を取り結果を返す関数」であるような関数にすること。

だそうですが、最初にこの文章を読んでみると？？？な状態になりましたが、
他のサイトでわかりやすい例がありました。

確かにカリー化を行うことで、引数を減らした（処理によっては分割した）記述ができるため
楽になると思いました。

が、この引数を束縛するという考え方が使えそうな時が思い付きません。。。

昨日、Windowsでのプロセス間通信について考えました。
ま、理由は今の仕事で使われているからなんですが。

仕事で使われているのは「名前付きパイプ」でした。

基本的にパイプはUnix系OSで使われる事が多いですがWinでも使われるんですね。

最近は「.NETリモーティング」だと思っていましたが。
（それかよく知りませんがRPCというものもあるみたいですね）

パイプを「レガシー」な技術と大きな声で言ってしまって少し恥ずかしい思いです。

今、仕事で通信処理の設計をしていますが、
書式に「UML」を使用しています。

最初はいまいち設計手法が良くわかりませんでしたが
だんだんと分かってきた気がします。

大体、ユースケース図→クラス図→シーケンス図の順番で作成
していくと自然なのかなと思いました。

昨日までやっていた、Vistaでのサンプルアプリケーションの作成作業が終わって
納品時に中身の確認をしていた所…。

「これは普通の人ではわかりにくいですね」

少しショックを受けました。

単純にCOMコントロールのプロパティの内容を変数に代入して使っていただけなのに…。

そもそも、このコントロールはプロパティが配列データを返すようになっていて、
C#.NETで開発する時には、object型になってしまうため、配列にキャストする必要が
ありました。（VB.NETの場合はObject型配列でしたが）

いくらテストが大変だと言っても、「直すべき所を直さずに」無理矢理周りでカバーするなんていう
事をしているからそんな「不自然な」状態になるわけで。

オープンソースのプロジェクトの場合はどちらを直すかを正しく見極めてから改造に
入るから安定した良いソフトができるのかもしれませんね。

最近、単体テストのチェックシート（要は仕様書）を作成しているのですが、
なかなかテスト項目を挙げていくのは大変だと思いました。

データのパターン、ロジックパターンをすべて網羅していく必要がありますが、
データパターンについては押さえるのが難しいですね。
というか、きりが無い…。
（特に、入力チェック。今まさに入力チェックの仕様書を作成しています）

最近では「xUnit」という自動テスト支援ツールも整いつつある中で、
だんだんと紙には残さない方向に向かっているのでしょうかね…。

そこで気になるのは、xUnitは技術者ならTestCaseがあればいいかもしれませんが、
ユーザとか評価部隊などの「素人」への資料はどうしているのでしょうね。