今回もWindowsFormsのDataGridViewコントロールを拡張したお話。

マウスカーソル下にあるセルの背景色・前景色を自動で変更する処理(ホットトラッキング)を社内ライブラリに実装しました。プロパティの設定だけで実現できるのでコーディング不要です。

内部処理は、DataGridViewのOnCellPaintingメソッドをオーバーライドし、マウスカーソル下かによってCellStyleを変更することで実現しています。

DataGridViewコントロールにグラフ表示を行う機能を追加しました。
現在対応しているグラフは、横棒グラフ・縦棒グラフ・積上横棒グラフ・線グラフ・面グラフ・点付き線グラフなど。

既存のグラフコントロールを使用して、セルのGraphicsオプジェクトに直接描画しているので、他のグラフに対応するのも簡単です。必要があれば円グラフや3Dグラフなども対応できます。

今回の実装により、DataGridViewで表現できる幅が広がりました。

最近、画像処理案件が続いてあり、社内の画像処理ライブラリに色々と機能追加を行いました。

a) ライブラリの64bit対応
b) 画像処理の並列化
c) 欠陥素子補正
d) 色マッチング処理

まだまだ機能追加したいことがあるのですが、時間が足りないです。
無限に開発をしていたいのですが時間は有限なのでしかたないですね。

インフォテックで作成するソフトではログファイルを必ず出力するようにしています。

稼働している設備でなにか問題が発生した場合などにログファイルを調べれば、エラーメッセージ・例外スタックトレース・通信内容・シーケンス状態などが全てわかるようにしています。
これにより問題発生時の原因究明・問題改善が容易になります。

今回、ログ出力に機能追加を行い、エラーメッセージを表示する直前にスクリーンキャプチャ画像ファイルを保存する機能を追加しました。
これにより問題発生時の状況把握がさらに容易になります。

先日もこの機能のおかげで、装置問題発生時のA/D即値や波形が確認できたことで、問題が装置側にあることがすぐに分かり即解決できました。

画像処理ライブラリOpenCVを良く使用するのですが、いつも32bit版のDLLを使用しています。
本来なら64bit版を使用したいところですが、同じソフト内で使用する他のライブラリが32bitしか無いことが少なからずあり64bit版を避けていました。

今回、32bit版と64bit版でどの程度の性能差があるのかが気になり確認してみました。
その結果、64bit版に変更するだけで3割くらい速度アップしました。
処理内容にもよるでしょうか、単純に速くなるのはありがたいです。
それと64bitにすることで1プロセスが使用できるメモリ上限も増えるので、メモリ不足の心配も少なくなります。

今後はできるだけ64bit版を使用するようにし、32bitでしか動作しないライブラリなどは32bitの別プロセスで実行し、プロセス間通信でやりとりする作りが良いと考えています。面倒ですけど。

今行っている仕事は２台の既存設備の他社製PCソフトを１から作り直し、２台とも同じPCソフトにする案件。

１台は10年前くらいの設備、OSはWindowsXP、言語はC++。
もう１台が厄介で、25年以上前の古参設備、OSはMS-DOS、言語はN88-BASIC。良くあるんですよね、こういう古いソフトの作り直し。

C++のほうは(ソースコードが汚いものの)問題なく読めて理解できます。

N88-BASICのほうはトリッキーです。実際に動かして見ないと何をしているのか追っかけられない。しかたないのでPC98エミュレータを用意して実機無しでも動くようにして調査しています。

それにしても良くN88-BASICのソフトが動いているものです。動かなくなる前に作り直しになってよかったです。壊れてから焦って作り直ししようとしてもすぐには対応出来ませんので。

弊社が作成するソフトは工場で使用されるものが大半。
そのため、デザインはあまり気にされません。というよりはデザインにコストをかけることは喜ばれません。

しかし、現在開発を行っているソフトは外販の可能性もありデザインにコストをかけて良く、私が関わってきたソフトで一番凝ったデザインのソフトになっています。

私の兄がフリーランスとしてデザイン会社を営んでおり(https://m-code.jp/)、以前から一緒に仕事が出来ればと思っていましたが、とうとう実現しました。
兄は普段WEBデザインやCGデザインを行っており、パナソニックやオンキョーなどの案件を担当していますので実力は十分。お客様からもとても良い評価を頂きました。

最近、会社で使用しているデスクトップPCとノートPCをSSDに交換しました。
NVMeなのでHDDに比べて、シーケンスアクセスで10倍、ランダムアクセスで100倍近く高速です。

PC操作時の色々なタイミングで速度を実感でき、快適に開発が行えるようになりました。

またC#のタプル(ValueTuple)の話です。

ActionデリゲートやFuncデリゲートは、複数個の引数を指定することができます。
例えば以下のようにstring型の引数を2つ受け取るActinデリゲートを受け取るHogeメソッドが定義できます。
(実装内容に意味は無いのであくまで参考の実装です)

void Hoge(Action<string, string> action) {
    action("aaa", "bbb");
}

これで動くのは動きますが、2つのstring引数が何者なのかコードからは全く読み取れないですね。
このメソッドを作った本人で無いと使用できないメソッドになっています。
今までならなせいぜいXMLコメントに引数の意味を記載してメソッド使用者に伝えることになります。
XMLコメントに「第一引数は名前、第2に引数はIDです。」みたいなことが書いてあれば、利用者は以下のように実装が可能でしょう。

Hoge((name, id) => {
    Console.WriteLine(name);
    Console.WriteLine(id);
});

しかし、タプル(ValueTuple)を使用すれば、このような問題は解決します。
先程のHogeメソッドを以下のように変更し、string型2つを保持するタプル変数１つにします。

void Hoge(System.Action<(string Name, string Id)> action) {
    action(("aaa", "bbb"));
}

これならば、２つのstring型に名前が付き、いちいちXMLコメントに記載しなくても最低限の意味は分かるようになりました。（あくまで最低限。XMLコメントが不要ということでは無いです。）
利用者側の実装は以下のようになります。

Hoge(x => {
    Console.WriteLine(x.Name);
    Console.WriteLine(x.Id);
});

今朝見た日経XTECHの以下の記事が面白かったです。
「建設業の足元にも及ばない、IT業界は最も遅れた労働集約型産業だ」

我々IT技術者が良く比喩に使う建築業よりも遅れた業界だったとは！

私はこの業界に入ってソフト開発会社2社に勤めましたが、どちらもSIer無しの１次受けで、自社内での受託開発でしたので、この記事に書いているような多重請負でのIT土方な現場には関わったことがなく（関わりたくないですが）、驚くとともに技術者が可哀想になります。

このような現場では、志が高い技術者が入ったとしても、続かないか腐っていきます。結果、知的技術者はいなくなり、労働者だけしか残らいない技術者デフレスパイラルになってしまう。もったいない。

私は、志が高い技術者はベンチャー系会社に入ったほうが幸せだと考えています。
いまの日本のソフトウェア業界では、やりがいがあり・技術力が身につき・成果が収入になるのはベンチャーだけです。

つまり何が言いたいかというと、「インフォテックはベンチャー系なので、やる気のある技術者はぜひ面接に来てください」ということです。