製造業の現場アプリや研究用ツールでは、いまでもWindows Formsベースのシステムが多く使われています。
安定していて資産も豊富ですが、タッチサポート以前のフレームワークゆえに、タブレットやタッチパネルでのスクロール操作が「なんだかイマイチ…」という声もよく聞きます。

そこで当社では、任意のWindows Formsコントロールに対して、マウスやタッチによるドラッグスクロールを実現する「DragScrollerクラス」を開発しました。
コントロールにこのクラスを紐づけるだけで、ユーザーはスマホ感覚でドラッグしてスクロールできます。

ポイントは、Windows Forms標準のスクロール動作に依存せず、ドラッグ量から移動量を計算し、疑似的にタッチスクロールを再現していることです。これにより、既存のWindows Formsアプリを作り直すことなく、タッチパネル操作を現代風にアップデートできます。

「既存資産は活かしたい。でも操作感は今どきにしたい。」そんなニーズがあれば、DragScrollerのような拡張アプローチは有効です。タッチパネル前提の検査端末や、現場で使う簡易ビューアの改善など、実運用に即したUI改善のご相談もお気軽にどうぞ。

こんにちは mtj　です

一時期のディープラーニングのようなバブルのような盛り上がりではありませんが　AIが普通に普及していますね
プログラムの方もとあるAi企業の裁判のような例もありますが用途も多岐に渡ります

コーディングだけではありませんが世の中の仕事の密度もかなり上がっていると思います。
今までは軽い調べ物でも時間がかかった物も今ではAIですぐに回答らしき物が得られます
回答らしき物なので正確性の担保は人が行う必要がありますがそれでも判断がかなり早くなりました

これにより省力化が可能な場所はかなり省力化が進んでいるのではないのでしょうか

もちろんコードでも全然動かないレベルの物　間違っている物も出てくるので知識が無い人が動かせば崩壊レベルにはなってしまいますが
仮にソフトが誰でもAIで作れる世の中になった場合どの程度正確な物が作れるかは楽しみです

適当な指示でどのようにして正確な判断を行うかその部分も楽しみではあります

早いものでもう三月ですね。
今回は題の通りで黒帯表示アプリを作った話となります。

どのようなアプリかと言いますと本当に単純で、黒いだけの画面を表示するためのアプリとなります。
デスクトップなど視界に入れたくない箇所の上に表示してそれら覆い隠すのが目的です。

経緯としては、モニタと自身の位置関係の都合で、
自身の正面に位置するモニタ中央～右側にVSなどのエディタを配置することが多いのですが、
そうすると余った左側のスペースからデスクトップや他ウィンドウが覗いており、
何となく落ち着かないと常々思っていました。
（デスクトップにはファイルを置きたい派なので、デスクトップを空にする選択肢はなしでした。
　またVSならアプリ内の配置が可変なのでフルスクリーンで何とかなるのですが、
　他のエディタなどはどうにもならずでして、、、）
課題を感じつつ何もしていなかったのですが、今更隠してしまえば良いことに気付いたため
WindowsFormにてさっくり実装しました。

namespace BlackBeltViewer;

public partial class Form1 : Form {

    // 黒帯モードか
    private bool IsBlackBeltMode { get; set; }

    public Form1() {
        InitializeComponent();

        // button1
        button1.Dock = DockStyle.Fill;
        button1.FlatStyle = FlatStyle.Flat;
        button1.Click += button1_Click;
        // Form1
        this.Text = "BlackBeltViewer";
        this.Load += Form1_Load;
    }
    
    private void Form1_Load(object sender, EventArgs e) {
        Draw();
    }

    private void Draw() {
        var color = IsBlackBeltMode ? SystemColors.Desktop : SystemColors.Control;
        this.FormBorderStyle = IsBlackBeltMode ? FormBorderStyle.None : FormBorderStyle.Sizable;
        this.BackColor = color;
        button1.BackColor = color;
        if (IsBlackBeltMode) {
            // FormBorderStyle.Noneにより枠が非表示となりフォームが縮むのでざっくり大きく
            this.Height += 30;
            this.Width += 8;
        }
    }

    private void button1_Click(object sender, EventArgs e) {
        // クリックでモード切り替え
        IsBlackBeltMode = !IsBlackBeltMode;
        Draw();
    }
}

コードを見てもらえばわかりますが本当に単純で、
・UIは画面に全面を覆ったボタン1つだけ
・ボタンのクリックで通常/黒帯モードを切り替え
・黒帯モード時に画面の枠を非表示・黒塗り・サイズ若干拡大
と言ったアプリとなります。
WindowsFormでプロジェクトを作成し、Form1にボタンを1つ配置し、
上記コードをForm1.csに貼るだけで動作するはずです。
（コンストラクタで行っているプロパティのセットやイベント登録は、
　実際にはデザイナーからプロパティウィンドウを開いて行ないました）

一瞬で作れるアプリですが、個人的にはかなりQoLならぬQoWが向上して満足しています。
以上です。

製造ライン監視や、研究用の実験記録などで、RTSP対応ネットワークカメラを使いたい場面が増えています。
ただ、「既存アプリはUSBカメラ前提」「カメラごとにAPIが違って面倒」という悩みも多いところです。

当社では、社内共通ライブラリにRTSPなどのネットワークカメラ対応機能を実装し、USBカメラやGigEカメラと同じインターフェースでアクセスできるように致しました。
アプリ側は「フレーム取得」「設定変更」といった、いつもの書き方のままでOKです。

カメラ種別の違いはライブラリ側で吸収し、RTSP接続・再接続・デコード処理を内部で完結。
そのため、既存システムからの移行が簡単に行えるようになっています。

「将来はカメラを増やしたい」「拠点ごとにカメラ構成が違う」――そんな環境でも、
共通インターフェース設計にしておくことで、保守性と拡張性を両立できるようになっています。

こんにちは mtjです

最近ゲーム開発で採用のうんぬんで色々と盛り上がっている話がありましたね
自分関連で言うとプログラマーになりたいのにC++をやってない人の部分でしょうか

全体で言うとゲームプログラマーになりたいのにC++をやっていなくともやれると思います
しかし 該当の会社ではC++をやっていないとプログラマーとしての価値は無いということでしょうか
自分は特に問題のある事を言っているとは思えませんでした　その会社で使うプログラム以外の言語をいくら覚えていても会社からの価値は無いので当然の話だと思いました

ではC++を覚えていないならどうするかですが　今持っている知識、言語で何かを作る事だと思います
C++が書けないにしても何かを作る事さえできればプログラマーの価値を証明することができます その上でC++も勉強しますと意気込みがあれば説得力がある気がします

この技術の業界は以下に相手にあった価値を説明できるかの業界だと思っています
いかにすぐれた技術を持っていたとしてもそこに必要でない物では活かすことができません
そのためには日々情報を仕入れ 興味を持った物は何かをしてみると繰り返す事で自分の価値を上げていく必要があると自分は思っています

AWSの案件に携わる可能性が出てきたため、12月ごろからちょくちょくAWSの学習をしています。
クラウド事情に疎く、クラウドサーバーとDBやストレージのイメージしか持っていなかったのですが、
様々なサービスが存在していて驚きました。
個人的にはサーバーレスでコードを実行できる AWS Lambda が気になっています。
インフラの管理が不要でアプリ開発にのみ集中できるとのことでとても便利そうです。
処理時間は最大15分とのことですが、分割可能な処理であれば複数のLamdaに分割し、
途中データはDBやストレージに保管するようにするなど工夫もできそうだなと思っています。

学習は主に AWS Skill Builder で行っています。
基礎コースは基本的に無料なのでとてもありがたいです。
座学形式のコースだけでなく、実際に手を動かしてみるコースもあり学習しやすいです。
aws自体のアカウントは不要で、一時的なアカウントを用意してもらえてそこで試すことができます。
しかし、概念の学習には十分に感じているのですが、実務で使用するには足りない気がしています。
各サービスの設定画面を見てみると設定可能な項目が多数存在し、
それらをどのように設定すべきかのベストプラクティスがわからないため、
他の何かでの学習したり自分で色々試してみる必要がありそうです。
AWSのアカウントは半年間、完全無料（クレジット上限と機能制限有）で
安心して使用できるようなので近々試してみようと思います。
（以前まではそうではなかったようですね。
　初めたてでも設定を誤ると請求が飛んで来たようで、、、）

何かあればまた書こうと思います。以上です。
（昨年末の記事にて少し触れたVS2026で拡張機能が動作しなくなった件は、
　大した問題でなかったので該当記事に追記しました）

Windowsのスマホ連携機能は、ここ数年で「通知を見る」レベルから大きく進化しています。
スマホのカメラをWindowsのWebカメラとして利用したり、Wi-Fi接続だけでスマホのストレージを通常のファイルシステムと同じように扱えたりと、現場でそのまま使えそうな機能が増えてきました。

スマホ連携によりサーバーレスで以下のようなことが出来ると思われます。

・スマホカメラをWebカメラとして使えば、現場作業者が設備やワークの写真を検査結果に紐づけて共有できます。
手元のスマホで撮影できる手軽さが良いです。

・Wi-Fi経由でスマホのストレージにアクセスし、PCソフトが検査手順書や検査結果などをスマホにファイル送信し、現場作業者がスマホで確認することができます。

今後、スマホを活用した検査・研究支援の案件でも、こうした標準機能を前提にした軽量な連携が選択肢になります。

こんにちは mtj　です

とあるクラファンの開発がうまくいっていなかったという情報が流れています
プロジェクト開発の代表はソフトを開発できるべき　と言われたりもしていますが個人的にはプログラムはできる必要が無いと思っています

目的に沿った進捗が管理できていればリーダーはプログラミング等のスキルは無しでも問題ないと思います。

ではどのようにそういったプロジェクト管理スキルを得るかという話になりますが　結局開発を繰り返す、プロジェクト開発の本を読む、信頼できるアドバイザーを1人は付ける等になる気がします。
近道は結局自分一人で開発を進められるプログラミングが一番早いのかもしれません。

こういった開発は基本失敗の繰り返しを反省した結果成功する物だと自分は思っています
他であった失敗事例を学び繰り返さないように自分で考え　自分が失敗した場合は繰り返さないように対策を考える その積み重ねが成功に繋がると自分は思います。

先月Visual Studio2026が正式リリースされましたね。
弊社でも開発に使用すべく導入準備を進めております。
インストール時に2022の設定やコンポーネントなど引き継ぐ選択肢があったおかげで、
Windowsアプリのプロジェクトはすんなりと問題なく開発可能な状態にできました。
しかし、MAUIによるモバイルアプリプロジェクトの対応が難航したので、
ここに注意点などを記述しようかと思います。

1. プロジェクトの.NETバージョンは支障がなければ素直に10に上げるのが良いと思われます。
VS2026をインストールすると.NET8ではビルドできなくなります。（VS2022においてさえも！）
.NET9も試したのですが、こちらもiOSビルド時に発生するエラーを解決できず、時間を溶かしました。
他の方も.NET10に上げたら上手く行ったという報告を見かけたので、
ほぼ間違いなく.NET10が推奨だと思われます。

2. .NET10に上がったことで、iOSをビルドするXcodeのバージョンも上げる必要があります。
新しい環境でビルドが成功するまでは古いバージョンのXcodeを残しておきたいと思うのですが、
その場合はAppStoreで更新をせずにAppleのDevelopperサイトにてダウンロードしましょう。
xip形式でなので展開すればXcode.appファイルが出来上がります。
これをアプリケーションフォルダにドラッグすれば更新できるのですが、
そのままだとおそらく上書きされてしまうので、
一旦アプリケーションフォルダ内の古い方を Xcode_16.4.app などにしてドラッグしましょう。
これでXcodeのバージョンが異なるとエラーで怒られることはなくなるかと思います。
ただし、メジャーバージョンが同じもの（例えば26.0と26.2）を同居させた場合に、
新しい方をXcode.appとしていても古い方が検出されてしまいエラーが発生したので、
メジャーバージョンが異なる場合のみ同居可能なのかもしれません。
（一先ず古い方をゴミ箱送りにすれば動作しましたが、
　デフォルトパス設定をちゃんとすれば問題起きないのでしょうか、、、？）
また実機実行に必要なデバイスサポートファイルを新しいXcode内に格納する必要もあります。
　Xcode右クリック > パッケージの内容を表示 >
　　”Contents” > “Developer” > “Platforms” > “iPhoneOS.platform” > “DeviceSupport”
古いXcode内のDeviceSupportからコピーするのが楽かもしれません。

3. .NETのバージョンが切り替わった後や、global.jsonで.NETのバージョンを指定した後は、
プロジェクト直下でcmdを開き、以下の2コマンドを順に実行し、
sdkが意図したバージョンになることを確認しましょう。
dotnet workload restore → dotnet –version

4. .NETのバージョンを切り替えた後にiOSをビルドする場合は、
古いバージョンのビルド情報がMacに残っておりビルド失敗の原因になり得るので、
ローカルとMacそれぞれからXamarin関係のキャッシュを一度削除しましょう。
・ローカルでは以下の2フォルダがキャッシュなので削除
　%localappdata%\Temp\Xamarin\XMA
　%localappdata%\Xamarin\MonoTouch
・Macでは以下の2フォルダがキャッシュなので削除
　$HOME/Library/Caches/Xamarin/XMA
　$HOME/Library/Caches/maui/PairToMac
Macとのペアリングが成功しなくなった場合などもこれで解決することが多いです。

5. .NETのバージョンを上げた結果、ビルド時に以下のようなエラーが発生するようになりました。
（iOSシミュレータ実行時のもので、iOS実機時やAndroid時は対応する箇所の記述が異なります）
> 資産ファイル ‘D:\VSTS\Komatsu720623\Project\Mobile\KOM-MICS Mobile\obj\project.assets.json’ に ‘net10.0-ios/iossimulator-x64′ のターゲットがありません。
> 復元が実行されたこと、および ‘net10.0-ios’ がプロジェクトの TargetFrameworks に含まれていることを確認してください。プロジェクトの RuntimeIdentifiers に ‘iossimulator-x64′ を組み込む必要が生じる可能性もあります。
エラーメッセージの示唆に従ってRuntimeIdentifiersやRuntimeIdentifierにてターゲットを指定しても、
特定のターゲットのみ成功するようになることがあるだけで根本的に解決しません。
おそらくプロジェクトのキャッシュに前のターゲット情報が残っていることが原因なので、
以下のようにキャッシュを削除及びパッケージの依存関係の復元を行いましょう。
① Project直下のbinフォルダとobjフォルダを削除
② Project直下でcmdを開き、dotnet restore（※）
これにより、Androidならリビルド、iOSならMacとペアリング→リビルドにより
ビルド及び実行が成功するようになると思います。
※この dotnet restore は前述の dotnet workload restore よりも必ず後に実行してください。
　dotnet restore → dotnet workload restore の順だとビルド成功しません。

6. .NETのバージョン更新や、(MAUIは無関係ですが)Androidの要件変更により、
いくつかのパッケージの追加・更新を行う必要がありました。
今回はそれで解決したので良いのですが、
もしも保守されていないパッケージで問題が起こったら、、、と思うとぞっとします。
そう考えると依存するパッケージも極力メジャーで保守され続けるもののみにした方が良いですね。
モバイルアプリ開発はマルチプラットフォームの普及もあり一度リリースするまでは手軽ですが、
そこで終わりではなくリリースを保つためにOSやSDKのアップデートに追従して
保守し続けないといけないのが大変だと実感しました。。。

※12/25: 諸事情により記入途中です。後日追記します。
　→12/29: 追記完了しました。

何とかシミュレータ/実機共にデバッグ実行できるようになり、
またリリースビルドとストアへのアップロードも成功し一安心しました。

しかし、これで2026対応は終わりではありませんでした。
VSの社内拡張機能が動作しなくなったのです。
しかも2026だけでなく2022でも動作しません、、、
まだ調査中なのですが、次回はそれについて書こうと思います。（※↓）

それでは皆さん良いお年をお迎えください。

※ 26/2/6追記
VS2026にて一部破壊的な仕様変更が行われたようです。
社内拡張機能の処理にて、エディタを最新の状態にするために
削除→Undoにより編集イベントを発生させ最新を反映させる実装となっていたのですが、
このイベントがUndoスタックに乗らなくなり、Undoが機能しなくなっておりました。
代わりにカーソル移動により編集イベントの発生を試行するように修正し対応しました。

製造業の現場では、システム開発や研究開発にPythonを活用するケースが増えています。データ解析やシミュレーション、品質検証など幅広い用途で使われていますが、実際の開発現場では「環境構築」に多くの時間が割かれてきました。Pythonのバージョン違いやライブラリの依存関係、さらには必要なデータファイルの準備など、開発そのものとは直接関係のない作業が意外と大きな負担になっていたのです。

最近ではAIがこの部分を大きくサポートしてくれるようになりました。AIがコードを解析し、必要なPythonバージョンを自動で切り替え、足りないライブラリをインストールし、さらには動作に必要なデータファイルまで生成してくれるのです。これにより、開発者は「環境構築」という面倒な準備作業から解放され、本来注力すべきアルゴリズム設計や品質改善に集中できるようになります。

今後は、AIによる環境自動化がさらに進化し、クラウドやオンプレミス環境を問わず、最適な構成を瞬時に整えるようになるでしょう。製造業におけるシステム開発や研究開発のスピードは、これまで以上に加速していきます。私たちシステム開発会社としても、この技術を積極的に取り入れ、製造業の現場に最適化されたソリューションを提供していきたいと考えています。