最近ソフトウェアのある1機能の開発を行ったのですが、想定よりも工数が多くかかってしまいました。
工数がオーバーした原因を考えると、
全体の設計がぼんやりとした甘い状態からコードを書き始めてしまったために、
実装時の迷いや構造の見直しによる手戻りが生じたりしてしまったからではないかと思われます。

プログラムもそれ以外のものでも、
何かを作る際に全体が曖昧なまま個々の詳細から作り込むと、
最終的にそれらを整合性を保ちながら結合させるのは難しく、
結果として辻褄を合わせるはめになり、時間がかかったり構造が歪になってしまう気がしています。

そうならないためにも、全体を曖昧に設計した後、
まずは徐々に全体設計の詳細を詰めて行き（抽象度を下げて行き）、
中盤以降に詳細を作り込み始める（プログラムだとコードを書き始める）のが良いのだと思います。

今回の場合だと、設計は処理の流れと曖昧なクラス設計のみだったのですが、
社内メンバーからの助言を盛り込むと、
データの流れも考えた上で、クラス設計の最低限上位の部分まではしっかり設計してから、
コードを書き始めるべきだったのかと思います。

手を動かさないと何も進めていないように感じたり思われたりするかもしれませんが、
その時間をかけることで結果的に工数を削減できるのではないかと思われるので、
時間に上限は設けた上でしっかり設計を行うようにしたいです。

ここ最近は他社のソフトを作り直す案件に携わっています。
自分の担当はPyhonで書かれた部分をC#で書き直す作業です。
書き直すコードはざっくり言うと画像に写っている人間を検出するコードで、
以下のような処理を行っています。
1. 推論エンジンに入力画像を投げる
2. 推論出力結果から検出された物体の情報を切り出す
3. 切り出した物体情報を元の入力画像上の値に変換する
物体の情報をどのようにデータ構造に格納しているかなどがわかって、書き直していて面白いです。

書き直していて思った所感は他に以下の2点です。

1. Pythonの方が多次元配列を扱いやすい
　Pythonには数値計算ライブラリのnumpyがある関係で多次元配列が扱いやすいです。
　機械学習を行う際の主流になるのも納得です。
　C#で書き直しているコードでは1次元配列で保持し、
　多次元配列のインデックスを1次元配列のものに変換してアクセスするようにしたのですが、
　インデックスの計算などにミスしてしまい、修正に少し手間取ってしまいました。
　…とここまで書いて、ふと調べてみましたがC#でもnumpyのライブラリがあるようでした。
　書き直したコードのパフォーマンスなどに問題あれば、使用を検討しようと思います。

2. コードのコピペをする際は中身を極力解読すべき
　既存Pythonのコードを調査していたところ、コアの部分がネットからコピペされていました。
　ライセンスなどないコードだったのでそれ自体は問題ないかとは思いますが、
　よく解読せずにコピペしたために生じたのではないかと思われる実装ミスがありました。
　（コピペ内で行われている処理をコピペ外で重複して行っており、
　　設定次第では正常に動作しなくなっていました）
　マジックナンバーなど解読できないこともあるかと思いますが、
　不精せずに可能な限り解読を試みてコメントを付与して、
　保守しやすい状態にする必要があると感じました。

以上です。

早いもので2022年ももう少しで終わりですね。

弊社は本日、午前は通常業務、午後からは大掃除を行いまして、本年の業務終了と相成りました。
明日から4日まで冬季休暇で5日から通常業務となります。

皆様本年はお世話になりました。
来年も何卒よろしくお願いいたします。
それではよいお年をお迎えください。

1. EXCELマクロをVBAで実装する案件を行いました。
VBAは一度読んだことがある程度だったので文法を調べつつだったのですが、
C#では手軽にコードレスに行えるところでも手間がかかるなどして、
想定以上に工数がかかってしまいました。
ですが必要な機能をひとまず実装してみて、コードを少しづつ洗練して行く過程は楽しかったので、
良い経験にはなったかなと思っています。

2. Pythonの環境構築や調査を行いました。
既存のPythonで書かれた処理をC#で置き換える案件のためです。
Pythonは学生時代に講義で習ったのと研究でグラフ出力するのに使用したことがある程度なのですが、
久しぶりだったのもあり楽しかったです。
得られた知見としては、特段の事情がなければ環境構築はAnaconda上で仮想環境を作成して行うのが良いということです。
今回まずはローカルの環境にpipでライブラリのインストールを行っていたのですが、
その際にcmakeでのビルドが必要だったりして中々上手く行きませんでした。
しかしAnacondaで試してみたらすんなり出来ました。
ライブラリの取得先がpipとは異なるからなのか、パスの設定などまで行ってくれるからなのか、
理由ははっきりわかっていませんが、
依存している他ライブラリのインストールまで含めて良しなにやってくれるようです。
pythonやライブラリのバージョン競合も防げますし、環境の削除も一発ですし、
本番環境でなければAnaconda上で済ませてしまいたいと思いました。

3. 私事ですが毎朝2,3分走っています。
朝は少しでも寝ていたいため毎朝ギリギリの時間に出発しているのですが、
3か月ほど前からは特にそれが顕著で、毎朝バス停まで走るはめになっています。
初めはぜぇぜぇ言いながら走っていたのですが、
最近は走るのが少し楽になってきて一周回って楽しくなってきました。
心なしか体力も向上した気がしており、仕事でも疲れにくくなったように感じています。
運動の重要性をひしひしと実感しております。

以上、近況的な投稿でした。

題の通りで、先月末コロナに感染しました。
快復傾向に至るまで1週間ほどかかり社内メンバーにはご迷惑をおかけしてしまいました。

症状としては喉の痛みが少しあったのと、38-39℃ほどの発熱で、
発熱は連日続いたため大変しんどかったです。
発熱外来では解熱剤を貰えなかったのですが、
家にロキソニンが余っていたのでそれを呑んで耐え凌ぎました。
現在は快復はしたのですが、後遺症なのか痰が喉に絡み続けていて、
咳を出さざるを得ず若干過ごしにくいです。

社内メンバーにも家族にも感染を広げなかったのは不幸中の幸いでした。

開発担当の案件も遅れが出てしまったのですが、
社内メンバーに開発を手伝ってもらい、
本日無事納品することができて一安心しました。
（福岡さん、masugiさん、ありがとうございました。）

皆様お気を付けてお過ごしください。

弊社で最も規模の大きなプロジェクトはWindowsFormにて開発が行われています。

先日、そのプロジェクトにてコントロールを別ウィンドウ化する処理を
既存の実装を参考にして実装したのですが、
予想以上に手軽に出来て驚きました。

以下のようにするだけでした。

// 別ウィンドウとなるフォームを作成
var window = new Form {
	Owner = this.ParentForm,
	Width = this.Width,
	Height = this.Height
};
// 別ウィンドウ化したい対象コントロールの親コンテナに新規ウィンドウをセット
// （別ウィンドウに移し替える）
targetControl.Parent = window;
// 別ウィンドウクローズ時に親コンテナを元に戻すように
window.FormClosed += (_, _) => {
	targetControl.Parent = this;
};
window.Show();

親コンテナのSetterは参照を移し替えるだけかと思い込んでいたのですが、
配置も移し替えるのですね。
便利に作られていてありがたいです。

皆さんは休日、どのように過ごされていますでしょうか。

自分は疲労により椅子に座る気力もなくベッドに転がってだらだらとスマホを弄るなど、
無をしてしまうことが多々あります。
流石にもっと精力的かつ有意義に過ごしたいと思い、
先々週から週末に栄養ドリンクのユンケルを1本飲むようにしてみています。
流行りのエナジードリンクでなく栄養ドリンクなのは、
エナドリは学生時代に飲み過ぎたせいか少し苦手になってしまったからです。
まだ2週だけですが、心なしか週末に心身共に元気な状態で過ごせた気がします。
（プラシーボかもしれませんが。。。）

ところで、弊社は明日から15日まで一応夏季休業となっております。
この連休も元気に過ごせるよう、ユンケルを飲んでおこうかなと思っています。
皆様もお体にはお気をつけて、元気にお過ごしください。

2つの値を交換したい時、皆さんはどのようにしていますか？

私は本日、以下のように愚直に行っていました。

var x = 1;
var y = 2;
var tmp = x;
x = y;
y = tmp;

スマートでないな～と思っていたのですが、
コードレビューにて同様の処理をタプルを用いて以下のように記述できるとの指摘を受けました。

var x = 1;
var y = 2;
(x, y) = (y, x);

う～ん、これはスマート！
（シンプルで可読性が高くて良いですね！）

タプルの構築と分解代入の複合により実現されるようです。
少し調べてみたところ、
コンパイル時には以下のような具合に最適化されるようです。

var tmp1 = y;
var tmp2 = x;
x = tmp1;
y = tmp2;

コンパイラも賢いですね！

今後もこのような知見を活かしてコードをシンプルに保てるようにしたい所存です。

（参考）
以下のサイトを参考に一部コードを引用させていただきました。
ありがとうございました。

複合型の分解 – C# によるプログラミング入門 | ++C++; // 未確認飛行 C

先日、あるクラスのソートのためにICompareble<T>を実装したラッパークラスを作成したのですが、
コードレビューの際にLinqのOrderByを使用すれば良いとの指摘を受けました。

以下のようなクラスとそのリスト、値の演算メソッドがあった際に、

class Hoge {
	public int No { get; set; }
	public int Value { get; set; }
}
var hogeList = new List<Hoge>(){ /* 要素たくさん */ };
int CalcHeavyForSort(int value) {
	var ret = 0;
	// 重い演算
	return ret;
}

次のように書くことで、

hogeList = hogeList.OrderBy(x => CalcHeavy(x.Value)).ThenBy(x => x.No).ToList();

1. Valueの演算結果により昇順でソート
2. 1によるソートの順序内でNoにより昇順でソート
を実行してソートされたリストを取得できます。

降順ならOrderByDescending, ThenByByDescendingです。
特殊な比較を行いたい場合は、IComparerを引数に与えることもできるようです。

引数で与えたラムダ式の実行も1要素1回だけのようですので安心ですね。
（内部でラムダ式の戻り値のリストを作成し、
インデックス同士を比較するメソッド内でその戻り値リストへアクセスしているようです。）

雑ですが、もしも次のようにソート時に同じ重い演算を複数回実行する必要がある場合は、

hogeList = hogeList.GroupBy(x => CalcHeavy(x.Value))
		.ThenBy(x => CalcHeavy(x.Value) * x.No).ToList();

次のように匿名クラスでラッパーを作り、それをソートすると良さそうに思います。

hogeList = hogeList.Select(x => new {
		Source = x,
		CalcedValue = CalcHeavy(x.Value),
	})
	.OrderBy(x => x.CalcedValue)
	.ThenBy(x => x.CalcedValue % x.Source.No)
	.ToList(x => x.Source);

Linqは便利で可読性が高く保守もしやすいので、
シビアなパフォーマンスが求められるケースでなければ積極的に使っていきたいです。

先日、USBカメラを接続するためにドライバのインストールを行ったのですが、
その際に以下のエラーが発生し、インストールに失敗しました。
「このハードウェアのデバイスドライバーを読み込むことができません。
　ドライバーが壊れているか、ドライバーがない可能性があります。（コード39）」

結論から言うとWindowsセキュリティ設定が原因で、

Windowsセキュリティ->デバイスセキュリティ->コア分離->メモリ整合性をオフに変更

により解決しました。
以下、解決までの過程です。

1. 試行錯誤
次のようなことを試したのですが、解決も原因特定もできませんでした。
・カメラやケーブル、接続ポートを変更
・メーカーHPにてドライバの対応OS, CPUの確認
・ドライバを最新のものに更新

2. PC初期化
社内の他のいくつかのPCでは問題なく成功しており、
PC自体に原因がありそうだったのでPCの初期化も行いましたが、
それでもインストールは成功しませんでした。

3. メーカー問い合わせ・解決
にっちもさっちも行かなくなり、メーカーさんに問い合わせたところ、
次の手順でWindowsのセキュリティの設定を緩めれば良いと教えていただき、
無事解決しました。
スタート->設定->更新とセキュリティ
 ->Windowsセキュリティ->デバイスセキュリティ
  ->コア分離->コア分離の詳細
   ->メモリ整合性をオフに変更

原因となったメモリ整合性、PCによっては出荷段階で既にオンになっているようなので、
ドライバのインストールに失敗した際には確認してみると良いかもしれません。

その後、本件について補足情報などないか検索していたところ、
エラーメッセージ+エラーコードがタイトルの記事に解決策が掲載されているのを発見しました。
プログラミングの際はエラー発生の初期段階でエラーメッセージの検索をするのですが、
今回は失念していました。今後は気を付けたいです。