ご希望の依頼内容を入力頂くと、最短１時間以内に「かんたん見積金額」をご連絡する「かんたん見積」サービスを開始致しました。
無料で見積をさせて頂きますので、初めてのシステム開発でも気兼ね無く安心してご依頼頂けると考えております。

「工場の生産ラインで使用する検査ソフトを作成したい」、「研究に使用する画像処理ソフトを作成したい」、「既存設備のソフトに機能追加を行いたい」など、ご要望がございましたら、まずは「かんたん見積」で見積のご依頼をお願い致します。

こんにちは mtjです。

プログラマーをやっている人であればわかると思いますが結構趣味と仕事の内容が被ってきたりします

家でサーバーを立ち上げて何か趣味のWEBサービスを立ち上げたり
それこそ何かのソフトを作ったりまあまああります。

使う知識も仕事で知ったことだったり、趣味で得た知識を仕事でも使ったりします。

そういう意味ではプログラマーという仕事は結構境界が曖昧で使える知識も多岐に渡っているんだと感じます。
ゲームのコントローラー等を自作したりハード関係に波及できたりもします。

覚えて知識を本当に色々なとこで活用できるのでなかなか楽しいですね

1. はじめに
つい先日、Windows10の特定モデルのPCにて、
プログラムからキー送信を行うのAPIであるSendKeysを使用した機能が動作しない、
という不具合が報告されてきました。
その原因及び回避方法が特定できましたので、その共有となります。

2. 原因
原因はタイトルに記載していますが、おそらくMicrosoft IMEの不具合で、
IMEが半角の場合にSendKeysが動作しないことがあるようです。
（IMEが全角の場合は動作することに気付き、原因に辿り着けました）
Windows 10 version 2004 以降の新しいIMEにはどうも不具合があり、
PCによっては入力時などに問題が発生することがあるそうです。

3. 回避方法
問題を回避するには、
IMEの設定にて「以前のバージョンの Microsoft IME を使う」をオンにすることで回避可能となります。
これによりIMEが半角時でもSendKeysが動作しました。

このIMEの設定は以下のレジストリを変更することでも設定可能です。
> レジストリキー：HKCU¥SOFTWARE¥Microsoft¥Input¥TSF¥Tsf3Override¥{03b5835f-f03c-411b-9ce2-aa23e1171e36}
> 名前：NoTsf3Override2
> 種別：DWORD値
> 値：1
次の記事から引用させていただいております。ありがとうございます。
「以前のバージョンのMicrosoft IMEを使う」をコマンドで変更する方法を検証してみた : ITインフラに悩まされてる日常

上記設定のレジストリ値は、
・管理者権限なしでプログラムから編集可能
・PCの再起動なしで反映可能（IMEのプロセスの再起動により反映）
のため、プログラムからも容易に設定変更可能です。
なのでこの回避方法は、人手による設定変更なしでプログラムだけで完結できます。

4. おわりに
最初は全く見当が付かなかったのですが無事解決して良かったです。
調べている過程で知ったのですが、
どうもSendKeysはWindows10以降まともにサポートされていないようです。
PCによっては動作しないことがまれにあり使用は非推奨である旨の書き込みをちらほら見かけました。
そのため、今回の件もMicrosoft IMEだけが原因でなくSendKeys側にも問題があるのかもしれません。
今後はSendKeysの使用には慎重になろうと思います。

参考：
「以前のバージョンの Microsoft IME のご使用について | Microsoft Japan Windows Technology Support Blog
Windows10の「Microsoft IME」を以前のバージョンに戻したら、ソフトの挙動が安定した話。 | メモノローグ

ウェハなどの対象ワークの検査を行う前に、位置や傾きのアライメント(位置合わせ)を行うことが良くあります。
アライメントを画像処理で行う場合、調整する４点を求めて射影変換を行うことが多いです。

今回行った案件では、２点だけ求めて簡易なアライメントを行うため、アフィン変換を使用しました。

社内ライブラリで内部的にアフィン変換を使用することはありましたが、ライブラリのAPIとして外部から実行出来るようになっていなかったので、今回APIに追加を行いました。1点から3点の任意点数でアフィン変換が行えるようになっています。

こんにちは　mtjです。

失敗から学ぶということで　ソフトは基本失敗から学ぶ事が多いです
なので自分は成功事例も失敗事例も色々な物を見ています、開発秘話等の難しかった所等を見るのはかなり好きです。

そういった事例を蓄えておくことで事前に収集しなければいけない情報もわかるようになります
その情報を元に発生するかもしれない動作以外の問題について対策していきます

よくある話だとサーバーのログイン関連でしょうか
同時にログインされる想定人数等を元にソフト、サーバーの規模等を決めていきます。
同時に約１０人しかログインしないサーバーに１万人規模のログインサーバーを建てる必要はないので

それ以外にもサーバーであれば今後のスケール等を元にそういった実装も加えていくのもいいかもしれません

というように設計は経験、知識で要求機能以外の問題点を確認していくと思います。
自分は同じ業界の友達とニュースになったような不具合等で雑談する時もあります
いろんな業界の人がいるので勉強になることも多いです。

9月ももう末ですね。
ようやく涼しくなって来てありがたいです。今夏は暑すぎました。。。

最近今更のように少しずつデザインパターンを学習（再学習含む）しています。
学習中にJavaのコードをC#で書き換える写経をしています。

そんな中でAbstractクラスで実装されがちなテンプレートメソッドパターンを
C#の場合はインタフェースのみで実現できることに気が付きました。
（Javaはおそらく完全な実現は無理そうです、
　インタフェースでfinal defaultなメソッドは宣言できないみたいなので）

実現方法は
「C#8.0でインタフェースにデフォルト実装メソッドを定義し、sealedで修飾」
です。

実現例：

/// <summary> 表示インタフェース </summary>
public interface IDisplay {
    /// <summary> オープンします。 </summary>
    void Open();
    /// <summary> プリントします。 </summary>
    void Print();
    /// <summary> クローズします。 </summary>
    void Close();

    /// <summary> 表示します。 </summary>
    sealed void Display() {
        Open();
        Print();
        Close();
    }
}

「C#8.0以降なら似たようなことをできるものの
　C#にはfinal修飾子がないため実現できない」と思っていたのですが、
デフォルト実装したメソッドをsealedで修飾可能なことに今更気付きました。
（というかそもそもメソッドにsealed修飾できることを知りませんでした）

これならデフォルト実装したテンプレートメソッドを
継承先のクラスにより上書きされてしまうことを防げますね。

実際にテンプレートメソッドパターンを実装することはあまりないかもしれませんが、
インタフェースにsealedなデフォルト実装メソッドを宣言可能なことは
知っているといずれ役立ちそうな気がします。

※調べてみると2019年に既に気付いていた方がおりますね。
　もしかして皆さん知っておられるのでしょうか。

Template Method Pattern C# 8.0風味 #デザインパターン – Qiita

以上です。

先週末にお客様工場のPCソフト更新に行ってきました。

以前に別会社さんが作成されたPCソフトの出来が良くないため、インフォテックで全てリプレイスを行った案件です。

同じような設備が４台あり、元々は設備ごとに微妙に異なるPCソフトを使用していましたが、インフォテックが作成したソフトでは、１種類のソフトで全ての設備が動作するようにしました。バラバラのソフトにすると保守に無駄に時間とコストがかかり、お客様の不利益になるので良くないです。

今回は最後の4台目の設備のPCソフト更新でした。
さすがに4台目になると慣れたもので、旧部材の撤去・新PCの設置・ADとI/Oの配線変更・動作検証などスムーズに進みました。

こんにちはmtjです。

プログラマーという職業はおそらくですがプログラムに詳しいと思われるでしょう
しかし、プログラムに詳しいという事は大体がPC自体の動作に詳しい人達です。

そしてソフトの使用される分野に対しても詳しい人が多いです。
画像処理であれば画像処理の動き、カメラ等の知識
3Dプログラムであれば3D空間の演算等それらの処理
ゲームプログラミングであればゲームの知識

その分野の知識がなければ言われたコードは書けるもののその先に踏み込む事は不可能だと思っています。
なので自分たちは新しい分野のソフトを作る時にその分野の知識も同時に仕入れています。

そういった知識を入れる事を忘れずに　取り残されないようにしていきたいです

MAUIでiPhoneアプリを開発する場合、ビルドのためにVisualStudioとMacをペアリングする必要があります。
アプリ開発の終盤、そのペアリング時やビルド時にMacのメモリが不足している旨の警告が出るないしエラーが出て失敗することが頻発しました。
その解決方法の共有となります。

タイトルの通り、キャッシュの削除により解決できました。
Windows・Macそれぞれで削除が必要です。

・Windowsでは以下の2フォルダがキャッシュなので削除
%localappdata%\Temp\Xamarin\XMA
%localappdata%\Xamarin\MonoTouch（←こちらはMacの接続先情報なので不要かもですが念のため）

・Macでは以下のフォルダがキャッシュなので削除
$HOME/Library/Caches/Xamarin/XMA

これで警告やエラー出ずにペアリング・ビルドできるようになりました。

以下はキャッシュが溜まる要因の予想です。
・ペアリング時にVisualStudioのバージョンないしMAUIのバージョンごとにキャッシュが溜まる
・異なるPCや異なるプロジェクトでペアリングを行うと、バージョンが異なりがちでその度にキャッシュが溜まる
くらいにふんわり考えています。

若干面倒なのであまりキャッシュ溜まらないことを願っています。
今後は1プロジェクトを改造・保守するのが主なので、上記予想が正しければ大丈夫なのではないかと思うのですが。。。

以上です。

[参考]
Clearing the Broker, IDB, Build, and Designer Agents on the Mac – Microsoft Learn
c# – Can't connect VS2022 .Net Maui Project with Mac – Stack Overflow
macos – I can't connect to Mac with Xamarin Mac Agent from Visual Studio 2015 – Stack Overflow

長らく行っていましたモバイルアプリ開発が無事に完了しました。

工場向けの生産監視アプリで、設備の稼働状況などを表示したり、設備の設定を行えたりします。
以前にiOS用にXamarinで作成したアプリを、Xamarinサポート終了に合わせて全て作り変えました。
今回はiOSとAndroidの両対応で、フレームワークにMAUIを使用しています。

MAUIがまだ成熟していないので、出来ないことが多かったり、ネット上の情報が足りていなかったりと、想定以上に大変ではありましたが、無事に出来上がりました。

この開発のお陰で、.net6以降用の社内ライブラリと、MAUI用の社内ライブラリが出来上がり、今後の開発の基盤がだいぶ出来上がりました。