こんにちは mtj です。

最近とある宇宙のゲームをやっているので　やっぱり宇宙は面白いなと改めて感じました

スケールがなんでも大きい　光年なんて単位はなんて宇宙でないとほぼ聞かないと思います。
またワープとかの理論も面白いです。

Alcubierre driveというものがありますが　物体は光を超えることができないから　光の速度を超えているビックバンを起こして移動するという理論です。
そういった関連の話は見ていて面白いので読み物として読んでも面白いです。

また点在する星についても色々あって面白いですね　ガス惑星だったり　氷で覆われていたり地球では起こり得ないようなことが起こっている星がいっぱいあったり
色々夢がありますね。

先日、コードの速度チューニングを行ったのですが、
その際にC#ではforeach文よりもfor文の方が速いという話を思い出して、
書き換えを行う前に調査してみました。

次の記事を参考に速度調査させていただきました。ありがとうございます。
forとforeachのアクセス速度比較 – Qiita

個人的な結論としては、以下のようになりました。
・リスト使用時はfor文が速い（要素へのアクセスには注意）
・配列使用時はforeach文が速い
・リストよりも配列の方が速い
なので、カリカリにチューニングしたい場合は配列+foreachが良いのかもしれません。
（そこまでする必要がある場合は、実際のコードで速度比較して決定した方が良さそうです）

それぞれの速度比較は以下です。（処理時間は末尾に記載）

・リスト使用時の速度
for文（一時キャッシュあり）> ForEachメソッド > foreach文 >>> for文（一時キャッシュなし）
・配列使用時の速度
foreach文 > for文（一時キャッシュあり）> for文（一時キャッシュなし）

調査してわかったこと・わからなかったことは以下です。
・Listの値へのインデクサでのアクセスはその都度個数チェックが発生するので、
　何度も使う場合遅い。一時変数にキャッシュすべし。
・ListのEnumeratorでは個数以外のチェックも行っているので、
　個数チェックだけのfor文やArrayのEnumeratorより遅い
・配列の場合に、for文よりもforeachの方が速い理由は不明
　（個数へのアクセスが内部フィールドな分速いとか？）

処理速度を調査するにあたり
参考にさせていただいだ記事中のコードに以下のようなコードを追記し、
リストと配列の2パターン用意してテストしました。

for (var i = 0; i < testlist.Count; i++) {
	var value = testlist[i]; // 一時変数にキャッシュ
	for (var cnt = 0; cnt < 1000; cnt++) {
		buf = value;
	}
}

それぞれの処理時間は以下です。10回平均です。
（tmp = 一時キャッシュあり）

By List
for Loop : 204 ms
for Loop tmp : 79.5 ms
foreach Loop : 82.7 ms
ForEach Loop : 81.8 ms

By Array
for Loop : 67.8 ms
for Loop tmp : 50.7 ms
foreach Loop : 49.7 ms

以上です。

C#で後処理を行いたい場合にfinallyブロックに記載することが良くあります。
途中でreturnで抜けても、例外発生しても必ずfinallyブロックが実行されるので安心です。

たとえば以下のように記載します。

try {
    //ここで処理Aを実行
    counter++;
    //ここで処理Bを実行
} finally {
    counter--;
}

処理Aのあとにcounterを+1し、処理Bを実行後にcounterを-1するコードです。
これだと処理Aでreturnや例外発生するとcounterが-1されて正しく動作しないです。
このコードだと、処理Aだけtryブロックの外側で実行するだけで良いですが、そうもいかない場合も多々あったり。

というわけで、DisposeActionクラスを作ってみました。
いたってシンプルなクラスで、コンストラクタで与えたラムダ式をDisposeメソッド内で実行するだけです。
以下のように使用します。

//ここで処理Aを実行
counter++;
using var _ = new DisposeAction(() => counter--);
//ここで処理Bを実行

先程の問題が解決し、行数が減り、コードも見やすくなったのではなかろうかと思います。

DisposeActionのインスタンスは不要なので、本当は以下のように書けると良いのですが。現状のC#では出来ないです。

using new DisposeAction(() => counter--);

こんにちは mtj です。

福井の朝倉氏遺跡にいってきました。
発掘物の復元方法等色々展示されており勉強になる部分も多々ありました。

巨大な城下町復元ジオラマ等もあり　そういった物を作るのも面白そうと感じました。
様々な復元を見て職人の技だなと関心しました。

職業柄エンジニアの視点になってしまうので地味にタッチパッドだったりそういった機器の動作にも惹かれました。

先日、案件の見積もりを行いました。

ざっくり言うと3軸アームを制御してアームに取り付けたセンサによりワークの検査を行うシステムで、
ワークそのものも何かしらのセンサとなります。
機能が多く、かなり見積もり工数が膨らんだため、
工数内に予定通り納められるか不安ではあるのですが、
自分は軸制御の案件は初めてなので実装を楽しみにもしています。

個人的に一番楽しみなポイントは、
ワークであるセンサの出力の波形から適した近似式のパラメータを求めるところです。
近似式を計算する関数に一回通すだけでなく、
n手間加えて若干最適化のような処理を行う仕様となる予定で、
実装するのを楽しみにしています。

まだ注文が出たわけではないのですが、
注文が出たら頑張ります。

弊社で開発しているソースコードのバージョン管理はVisualSourceSafeを惰性で使い続けいました。
数年前からは新規プロジェクトはGitを使用していますが、古いソフトはVisualSourceSafeのままです。

社内ライブラリもVisualSourceSafeだったのですが、VisualStudio2022がVisualSourceSafeに対応していないため、この週末にGit＋VisualStudio2022に移行しました。
予想していたより問題も起こらず、すんなりと移行完了。単体テストも全てクリア。

こんなに簡単なら、もっと早くに移行しておけばよかった。

ほかのプロジェクトも徐々にVisualSourceSafeからGit＋VisualStudio2022に移行を進めていきます。
VisualStudio2022でないと「GitHub Copilot」も使用できないですし。

こんにちは mtjです。

京都で開催されているビットサミットに行ってみました。
日本だけでなく海外からのインディーゲームの展示もありかなりグローバルなイベントだという印象を受けました。
大手企業から学生作品まで大小様々な規模のゲームが展示されており見てて飽きないイベントでした

開発者視点から言うと業界の繋がりを深めるにはいいイベントだなと感じました
学生でそういった開発者（学生同士でも）と話せる機会、作品を見せれるはそれほどないので
こういったイベントでこそこういった物を作ってる等交流を行うことでチャンスを増やすことができると感じました。

ビットサミットとは関係ないのですが当日は祇園祭の出店の日だったのもありかなりの人出でしたどちらも活気があり
京都が盛り上がってる気がしました。

remove.bg (https://www.remove.bg/)という写真や画像の背景を消すサイトを使ってみました。
試しにremove.bgを使ってフリー素材から背景を消してみました。

他の画像でも試してみましたが、人物がきれいに切り抜かれています。

また、背景をぼかしたり、

背景を別の画像に差し替えることもできます。

使ってみると結構面白かったです。
趣味でコラ画像を作るのが捗りそうです。

先日、PythonのコードをC#に書き直すことになる案件の工数見積のために、
Pythonコードの調査を行いました。
以前もPythonの書き直しの案件はありましたが、
今回は以前と違って他社さんが作成したコードでなくGithub上のオープンソースのコードが対象です。
（もちろんライセンスには準拠します。）

自分がPythonに不慣れなのもあるのですが、
Pythonは型宣言がほとんどなくデータの型を追いにくい
（特に多次元行列をスライス記法でnumpyなどに投げた結果、
　どのようなデータに整形されたかがわかりにくい）
といった理由で読むだけでは判断が付かず、
実際に動かしてみないと処理内容に確証が持てないことが自分は多々あります。

そこで今回は、読んでいる途中でBingChatに投げてみました。
メソッドを貼り付けて、
・「以下のコードを説明してください」
・「以下のコードを1行ずつ説明してください」
などとお願いしたところ、
わかりやすくメソッド概要とコードの1行ずつの解説が出力してくれて、調査の時短になりました。
説明が不明瞭or不足している箇所も部分的に「この部分を説明してください」とお願いすることで、
深堀りして説明を得られました。
これさえあれば自力で解読する必要はないかもしれませんね。
（解説を理解し、間違っていないか判断するためにプログラムの知識は必要ですが）

業務コードを投げるのはコンプライアンス的に問題ですが、オープンソースなら大丈夫ですし、
・GPTのバージョンにより学習期間は異なりますが、
　オープンソースは基本学習済みのため精度の高い回答を貰える可能性が高い
・単純なコードでない限り、自力で解読するより圧倒的に速い
ように思いますので、オープンソースの解読には積極的にChatAIを利用しようと思います。

「GitHub Copilot」とは、コーディング中にAIがコード例を提示してくれる、今後のソフトウェア開発を大きく変える革新的なツールです。
弊社でも最近このツールを使用しております。
VisualStudio標準のAI補完機能「InteliCode」よりも柔軟にコード例を提示してくれます。

自分が書いたコードを学習し、適切なコード例を提案してくれます。
開発者は、Copilotが提供するコード例を参考にしながら、より迅速かつ正確なコードを作成することができます。
これにより、開発の生産性が向上し、バグのリスクを低減することができます。

Copilotはまだ新しいツールであり、正しくないコードを提案することもあります。
しかし、Copilotの精度は徐々に向上していくことが期待できますので、今後が楽しみです。