こんにちはmtjです。
何かしらのソフトを触っていると なんでこんな使いにくい だったり おかしい動作があるんだって思う時があると思います。
開発の中では簡単な部分は完成してしまっていると通過点になってしまっておりそのまま開発が続けられる可能性が高いと思います。
その通過点に使いにくい部分があったりする事で上のような明らかにおかしいような動作が残されたりするのではないかなと思います。
大事なのは実際に使ってみてのテストになるのですが
それもテスト者がどの程度効率化、使いにくさ、わかりにくさを認識するかになると思われます。
結果としてはなかなかそういう事を防ぐのは難しいと思いました
今回は題の通りで、
ソフトが使用する別ソフトのexeファイルをインストーラーに同梱する必要が生じたため、
ソフトのインストーラーを作成するSetup Projectにexeファイルを追加したのですが、
それによりSetup Projectのビルドが失敗するようになりました。
その対処として、exeファイルをzipに圧縮して追加するようにしました。
以下経緯です。
失敗の原因は、追加した覚えのないdllファイルでした。
どうもSetup Projectにexeファイルを追加すると、
そのexeの依存するdllがすべて自動で追加されるようです。
追加されたファイルはプロパティウィンドウにて除外の設定が可能なのですが、
除外しても失敗は解決できませんでした。
（正確には、VS上でのビルドは成功するようになったのですが、
運用としてはスクリプトから言語設定の構成を切り替えて2回ビルドを行う必要があり、
そのスクリプトでは依然として失敗しました。
StackOverFlowの投稿で見かけたのですが、
構成の切り替えにより除外した依存関係が自動で有効化されるらしいです。）
dllが追加されないように（※）exeをzipに圧縮して追加し、
ソフトの起動時にzipを解凍する処理を実装しました。
※拡張子の変更も試しましたが、
変更してもしっかり実行ファイルだと認識しdllが追加されてしまいました。
結局、dllの追加により何故失敗するかはエラーメッセージからもはっきりわからなかったのですが、
ソフト自身の依存するdllと同名の異なるバージョンのdllが追加されていたので、
バッティングが原因だったのではないかと推測しています。
Setupプロジェクトの動作が重いのも相まって解決に少し手間取ってしまったのですが、
リリース作業の運用は変更する必要なく解決できたので良かったです。
先日の案件でユーザごとにライセンス認証を行うためにUSBドングル対応を行いました。
市販のUSBドングルを使用する方法ではなく、普通のUSBメモリで認証を行う機能を社内ライブラリに実装しました。
USBメモリの固有情報＋秘密キーから作成した認証用ファイルをUSBメモリに入れておくことで実現しています。
簡単な方法ですが、十分な効果があります。
弊社が作成するソフトは工場で使用するものが大半なのでライセンス管理は普段行っていませんが、今後必要な場合には、この方法で簡単に対応出来るようになりました。
こんにちはmtjです。
ソフトの受託開発は基本的にはお客さんの仕様通り作る事が仕事ですが
明らかに操作フローが不明だったり 違和感あるような内容は少し細かく踏み込んだりします。
依頼側が詳しければきちんと教えてくれたりしてくれます。
特に詳しくない場合UIもフローもだいたいなんとなくだったりします
そういうときにこちらが意識して問い合わせる内容は以下のような内容です。
上記の情報からその立場で仮想的に使ってみてUXを検討します。
誰が
操作者の知識量を想定します。
システムに慣れた人かどうかか特定の一部の人だけかでUIのわかりやすさ等を検討します。
どの程度の頻度 どの機能をどの程度の頻度で触るかで使いやすさの検討を行います。
どういった目的で触るか
主に画面操作時に見せる内容、入力等を検討するため
結果、操作後の動作
操作結果の見せる情報、物理的に出力する内容の検討のため
上記を意識し 提案をしていく事で良いシステムが出来上がると思います。
普段生活している時も意識してシステムを見ることで普段作っている側では発見できないような事も発見できるかもしれませんね。
C#にてprivateなメンバを別のクラスにのみ公開したいことがあります。
この1つの実現方法として、
特定のクラスが自身と密接に関係する場合以外は推奨されないと思いますが、
特定のクラスを内部クラスとして定義すれば可能だと知りました。
内部クラスはごくまれにしか定義しないので、今更知りました。
Stateパターンってどう実装するのが良いのだろうと思っていたのですが、
Stateのクラスを外部に公開しないなら内部クラスで良かったのですね。
地味に疑問だったので晴れて良かったです。
/// <summary> partialテストクラス </summary>
internal class SampleClass {
/// <summary> 状態インスタンス </summary>
private IState State { get; set; }
/// <summary> 何かの数 </summary>
private int Count { get; set; }
/// <summary> 具象状態クラス </summary>
internal class ConcreteState : IState {
/// <summary> 何かする </summary>
public void Do(SampleClass parent) {
tester.Count++;
}
}
}
/// <summary> 状態インタフェース </summary>
internal interface IState {
/// <summary> 何かする </summary>
void Do(SampleClass tester);
}
※詳しくないのですが、
Javaだとprotectedがサブクラスだけでなく同一package内ならアクセス可能らしいので、
packageをちゃんと定義すれば可能なのかもしれません。
先日の案件で、依頼元が作成しているVB6ソフトに通信機能を実装してほしいとのご要望がありました。
しかし、今さらVB6での開発は行いたくないため、C#で通信機能を実装したDLLを作成し、VB6からDLLを
呼び出してもらうようにしました。
この結果、弊社のC#共通ライブラリを使用して効率良く開発が行えました。
特にVB6はスレッドが使用出来ないことがネックになるのですが、C#でDLLを作成することでスレッドも使用できますので、
通信の受信待ちなどをVB6のスレッドを気にせず、別スレッドで非同期に待てるので、とても実装が楽になります。
今回、初めてVB6で使用できるCOM形式のC#DLLを作成しましたので、調査必要な箇所も多かったですが、
詰まることもほぼ無く開発出来ました。
工場の設備などでは年期のはいったVB6ソフトがよく使われています。改造依頼も良くあります。
このような依頼内容の場合は、今後もこの方法が有効であると分かりました。
こんにちはmtjです。
最近といっても数年前からですがAIでプログラム出力が盛んになってきました。
AIのプログラムはしっかり読んで覚えるべきかどうかが度々議論になっている気がします。
自分は自分の価値を高めたいのなら見るべきだし、作業としてさっさと終わらせるだけなら見なくていいという意見です。
自分の場合は基本読んで理解します、読まずにAI作成プログラムを導入するのはリスクが高いです
見ない人の気持ちも上に書いた通り さっさと終わらせたいならそうすればいいという感じです
上のような話はプログラムをコピペで作るだけという話にも似ているような気がします
読んで理解して書くより 動いている動作をコピペして目的通り動けばいいという考えですが
早いといえば早いけど コードで見たら酷い物になっていると思います、酷いものと理解できるのであればそもそもそういうレベルでコピペなんてしないと思いますが
AIを読まない人の話も コピペでプログラムを作る人の話も システム制作の話を深堀りしていった時にからっぽになってしまうのではないかと思います
自分が面接をしていたら そんな怪しい人は取れない気がします
よく言われていますが 今後はシステム開発はAIを使っている人 使われている人を見極めるスキルが必要になるのかなと感じます
使われている人の場合はシステムがうまく行っている場合は問題ないように見え、速度も早いですが 爆弾を含んでいるような人材になると思います
AIで上手くいかない場合の対処が難しくなり 復旧等も時間がかかり最悪復旧不可のような自体もあるかもしれません。
システムを完成できない人よりも見極めが難しくなるかもしれませんね
もう一月も半ばですが、皆様明けましておめでとうございます。
本年もどうぞよろしくお願いいたします。
内容としては題の通りなのですが、詳細には、
OpenVINO2021にてONNX形式のモデルをOpenVINOの中間表現IR形式(.xml, .bin)に変換し推論を行うと、
ONNXでの推論結果よりもIRでの推論結果は推論精度が目視で10-20%ほど低下することがわかった、
という話となります。
経緯としましては、案件にてPyTorchの学習済みのモデルファイル(.pth)をOpenVINOを使用して推論することとなったのですが、
既存システムで使用しているOpenVINOは2021と少し古いためPyTorch形式の推論に対応しておらず、
対応している別の形式に変換する必要がありました。
既存システムではIR形式にて推論しているため、ひとまずIR形式への変換と推論を試してみたのですが、
その推論結果はPyTorchでの結果よりも精度が低下しました。
そこでONNXへの変換と推論も試してみたところ、ONNXでは精度の低下は見られず、
IRの場合に低下することがわかったという次第になります。
調査したところIR形式はONNX形式よりも若干高速とのこと（※）なので、
推測ですがONNXから変換時にその分ネットワークがそぎ落とされてしまうことがあるのかもしれません。
速度を限界まで最適化したい場合でなければOpenVINOではONNXで推論するのが良さそうですね。
※
目視では推論速度に大して差があるように見受けられなかったのですが、
以下の記事によると、Yolov5でONNXとIRで推論処理時間に10msほど差があるようです。
【やってみた】ONNX・OpenVinoでYOLOv5の高速化！ – 神戸のデータ活用塾！KDL Data Blog
以上です。
先日行いました案件で、ユーザ様からのご要望で帳票印刷ツール「シーオーリポーツ」を使用しました。
あらかじめ印刷レイアウトを付属ソフトで作成しておき、印刷するアプリからは各印刷要素の文字設定・画像設定・表示有無などをコード上から行って印刷が可能です。
印刷レイアウトをコード上で作成・保守する手間が省けるため大幅な工数削減になります。
とくに、あとから頻繁に印刷レイアウトが変更になるような案件では重宝しそうです。
工場向けの案件では印刷することは減ってきておりますが、検査結果をPDFファイルで残しておきたいなどのご要望はありますので、そのような場合に使用できそうです。
こんにちはmtjです。
.Netの画面遷移について
デスクトッププログラムを作る上でWebのような画面遷移は悩んだことがある人が多いのではないでしょうか
WPF UWP等を扱わずに初期状態のWinForm等でできる動作としては以下のような作りになると思われます。
1.新しいFormを作る
画面毎に切り離せるので作りが綺麗にしやすいのと作りやすいです
移動時に画面が新たに開くのでWebのように見せるためには少し工夫が必要
2.コントロールの表示を切り替える事での動作。
見た目は１つの画面で遷移ぽく見えるので綺麗です。
欠点としてはForm側での管理もあるので気をつけないとコードが汚くなってしまう事です。
自分は新しいFormを作り 現在の表示用の画面に中身のコントロールを配置するようにしました
１のForm別の作りやすさはそのままに遷移のように作れるので割とうまくできました。
懸念点としては別Formの物を移動しているので予想外の挙動をするのではないかというぐらいです。
利点としては置く場所さえあればよいので本当の画面遷移のように表示したいFormさえ何かで受取表示さえ行えば上位はほぼ気にすることなく動作を行える点です。
コントロールの時のようにコントロールの表示の切り替え等を作ったりする必要がなく それぞれのやり取りも必要最低限のデータで行えます。
１つのFormで完結していればデータの受け渡しも必要ありません。
結構WinFormでも工夫することで面白い表示が行えるので色々試したいと思いました。
以上です。