設計の重要性

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

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

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

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

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

bingのチャット検索(ChatGPT)

bingのチャット検索(ChatGPT)が流行っているので試してみました。

■C#でSQLiteを使用するコードを依頼
コードだけではなく、必要なライブラリやコネクション文字列の例も教えてくれました。

■上記の質問のあとに、他のコード例を依頼
ちゃんと続きの会話と理解してSQLiteのコード例を教えてくれました。

■上記コードをVB.netに変換
コード変換を行うWEBサイトを使用して変換してくれました。

■結果
今回のチャット内容は簡単なものなので実際にはどれほど役に立つかはまだわかりませんが、ちょっとした調べ物などをお願いして開発の労力を減らせそうに思います。
良い開発パートナーになりそうです。

面白いデバイスの活かし方。

こんにちはmtjです。

最近mocopiという簡易的なトラッキングデバイスが発売されました
今までは正面から赤外グリッドで距離、画像でボーン判定を行いトラッキング、
もしくはトラッキング用のスーツ等をつけ人の動きをトラッキングするのが普通だった気がします。

しかしどちらもそれ用の設備を整えたり、全身じゃなく顔トラッキングだけ等限界がありました。
mocopiは時計のような大きさのデバイスでbluetooth接続で簡易にトラッキングができるという物
用途としては今のところVチューバー向けになると思いますが従来のトラッキングデバイスと併用すれば安くモーションキャプチャ等活かす方法はある気がします
kinectもそうでしたがやはりトラッキングというとアミューズメント、娯楽向きになるのではないかなと思います。

自分はデバイスを持っていませんが、友達が持っているのでどこかでSDKでも触れたらなと思います。

機械翻訳

業務で調査をしているときに、インターネットのサイトを調べることがあるのですが、日本語で書かれてはいるものの、いかにも海外のサイトを日本語に機械翻訳したようなサイトが出てくることがあります。

私が最近見た例ですが、

「[] に戻ります。クイックツアーメニューまたは、直進してこのクイックツアーの終了。」

(英語の原文はGo back to the quick-tour menu or go straight to the end of this quick tour.)
というように、翻訳後に日本語の文として成り立っていない文になることがよくあります。(なお、これはwebサイト内にある言語を切り替えるプルダウンを用いて機械翻訳したものです。)

このように日本語の文として成り立っていない文が多いと、サイトが読みづらいです。英語で文書を読むのに慣れていない私としては、日本語で書かれていた方が有難いですが、英文の原典を読むのに慣れなければならないな、と思います。
余談ですが、とあるAPIのマニュアルの日本語版(機械翻訳されたもの)で「お前」という単語が出てきたときは思わず苦笑いしてしまいました。

Python->C#書き直し業務所感

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

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

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

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

以上です。