こんにちはmtjです。
ソフトウェアの価値についてですが ソフトウェアは基本買ってきただけでは価値を生まないと思っています。
それこそ普段使うプログラム開発用のIDEも買うだけでは何も生産を行いません。
IDE等もプログラムを効率よく開発したいから買うので購入して即成果が上がるような物でもありません。
道具を使いこなして価値を産む人がいて初めて価値が生まれます
流行りのIOT等の機器も遠隔で情報を知れるだけの物ですが
その情報を使って価値を生んでいくのは利用者側です。
自分たちもソフトを作る上でその先に価値があるのかを考えながら開発していきたいです。
弊社でも使用しているMicrosoft Xamarinのサポートが間もなく終了します。
iOS関連と合わせて開発環境の状況を整理しました。
Microsoft関連
- 2024/5/1：Xamarin.Android サポート終了
- 2024/5/1：Xamarin.Forms サポート終了
- 2024/5/1：Xamarin.iOS サポート終了
- 2024/8/31：Visual Studio for Mac廃止
iOS関連
- 2024/4/29：ストアへのアプリは、Xcode 15 と iOS 17 SDKが必要
既存のiOSアプリは、ストアがXcode 15が受け入れられるまではアップデートは可能と思われます。
Visual Studio for Mac廃止に伴い、
MacでのC#開発用IDEの代替としてはVisual Studio Code、
または仮想Windows上のVisual Studioが位置づけされているようです。
MacでUnity開発などを行っている場合は大きな影響がありそうです。
弊社でも今後はモバイルアプリは.NET MAUIに移行していきます。
Gitでコミットをする場合、都度ざっくりコミット内容のチェックは行うのですが、
とは言え見落としなどしてしまうことがあります。
なのでブランチをmasterにマージする前に全ての変更を最終確認したいと思っていたのですが、
VisualStudioのGitなら以下の手順で簡単に確認できることに今更気が付きました。
1. VS上部のGitからブランチの管理を開く
2. ウィンドウ左部のブランチにてmasterを右クリックして対象のブランチにmasterをマージ
3. ウィンドウ右部のローカル履歴にてブランチの最新のコミット（masterをマージしたコミット）と
masterの最新のコミットを同時に選択し、右クリックしてコミットの比較
小規模かつ短期間のブランチなら都度確認だけでも問題ないかもしれませんが、
開発が長期に渡った場合や、ブランチ内で修正を何度も行った場合などは、
ゴミとなるコードが残っていないかや意図せず破壊的変更を行ってしまっていないかなど
最終確認するのが良いのかなと思っています。
以上です。
業務で久しぶりにVSTOを使用しました。
VSTOは、EXCELやWordなどのOfficeアプリケーションをカスタマイズし、機能を拡張するためのフレームワークです。これは、EXCELマクロ(VBA)の代替として使用され、以下の点で優れています。
1. C#で実装：VSTOはレガシーなVBではなく、C#でアプリケーションを拡張できます。
2. .NETのフル機能：VSTOは.NETフレームワークの全機能を利用できます。
3. GUI：WindowsFormsやWPFを使用して、Officeアプリケーションのユーザーインターフェースをカスタマイズできます。
4. コードの隠蔽：VSTOを使用することで、コードを隠蔽してアプリケーションを保護できます。
今後もVSTOを使用して効率的な開発を進めていきます。
こんにちは mtjです。
世の中には様々なプログラムの言語がありますが その中にももうサポートされていない古い言語だったりできたばかりの言語があります。
自分は古い言語、フレームワークは基本しかたなく使う者だと思っています。
新しい言語はそれこそ使う側の負担、言語自体の新たな不具合、仕様等未知の部分が多く使う場合のリスクが読み難くなります。
慣れた言語の方が開発スピードも既存のライブラリ等も使用できるので開発費用も低く済みます。
しかし新しいOSで動かなかったり 新しい機能が使えなかったりします。
では新しい言語の利点で自分が思うことは
・新しい言語のほうがセキュリティ懸念が低い
現在のOSのセキュリティ機能を使ったりするので言語自体のセキュリティは高い場合が多いです。
・新しいOSの機能が使える
・コードの書き方等が簡潔だったり古い言語では使えない用な機能があり 速度が結果的に早くなる場合がある。
・最新のサービス等の機能が使える。
プログラム言語は基本新しい物を取得していくのが最良だと自分は思います。
しかし、MACネイティブの場合はOSで強制的にSDKが移行されてしまうので 古い機能を全部消して新しい機能に置き換える事が強制されてしまいます
既存のコードはもちろんまともに動かない場合が多いです そういった意味でもMACは開発者に優しく無いとは思っています。
ちょっとの機能追加でも莫大な時間がかかってしまう場合があるのがMACです。
C#の開発はVisual Studio 2022で行っています。
VSは機能追加のアップデートも頻繁に行われており、便利な機能も多くあります。
ここでは「クイック ウォッチ」と「IEnumerable Visualizer」を紹介します。
実行中にブレイクポイントで停止させて、
オブジェクトの状態を確認するシーンは数多くあると思います。
どのようなIDEでも変数やオブジェクトをウォッチする機能はありますが、
VSでは変数やオブジェクトを右クリックして「クイック ウォッチ」があります。
通常のウォッチと同じような専用の画面が表示され、特に多くの情報を一覧で見たい場合に有効です。
「IEnumerable Visualizer」はIEnumerableな変数にカーソルを合わせると表示される、
「表示」から選択できます。
匿名クラスで欲しい情報を集めてIEnumerableな変数にしておけば、
その情報をCSVかExcel形式で出力することもできるので、
デバッグやデータをExcelで検証する場合などに重宝しています。
案件で環境変数への値の取得/設定に関して少し調査を行ったので、
ブログ用に少し内容増やして調査結果以下に記載します。
C#において扱える環境変数の種類(EnvironmentVariableTarget)は以下の3つです。
Process: プロセスごとの環境変数
User: ユーザごとの環境変数
（システムの詳細設定から確認可能、レジストリ値 HKEY_CURRENT_USER\Environment内）
Machine: PC共通のシステム環境変数
（システムの詳細設定から確認可能。レジストリ値
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment内）
取得、設定、削除（nullを設定）は以下のメソッドにより可能です。
string? Environment.GetEnvironmentVariable (string variable, EnvironmentVariableTarget target);
void Environment.SetEnvironmentVariable (string variable, string? value, EnvironmentVariableTarget target);
以下の表に、取得/設定時の種類ごとの主な違いをまとめてみました。
以下知見や所感です。
・ユーザ及びマシンは、プロセスの再起動など不要で、
同時に起動している異なるプロセスにて共有可能でした。
・管理者権限必要なのはマシンだけでした。
ユーザも内部的にはレジストリ値なので権限必要に思えたのですが、
HKEY_CURRENT_USER下のキーの変更は権限不要らしいです。
・ユーザとマシンは他のアプリとも共有で影響及ぼすかもなので取得や設定、削除に注意が必要です。
また、プロセスとは異なり、システム詳細設定やレジストリエディターから
値が容易に確認可能なため、プロキシ設定などの認証情報の書き込みを行うと
ユーザIDとパスワードが平文で見えてしまう点も注意です。
・ユーザやマシンへのSetは2秒程度かかり、実行時暫し動作が固まったので、
場合によってはプログレス表示必要かもしれません。
内部でレジストリへの書き込みを行う関係か少し時間がかかるようですね。
（参考PCスペック：CPU=intel core i9-13900, RAM=32GB）
・どれを使うかは用途次第ですが、扱いやすいのは管理者権限不要なプロセスとユーザで、
プロセス間で共有するかどうかで使い分けるのが良いかと思いました。
以上です。
今回は弊社で開発しているアプリに実装したAIチャット機能についてご紹介します。
この機能は、アプリをさらにユーザフレンドリーにし、質問応答をスムーズに行えるようにするために導入されました。
「Azure OpenAI」と「Azure AI Search」を組み合わせて、AIチャット機能を実現しました。以下に、具体的な手順を説明します。
実際にこのAIチャット機能を試してみると、以下のような驚くべき効果がありました。
AIチャット機能は、技術アピールにもなりつつ、ユーザフレンドリーなアプリを作成するための非常に有効な手段であると感じています。今後もAI技術を駆使して、さらなるユーザビリティ向上を行っていきます。
mtjです。
とある人がAIでプログラマーがなくなると言ってから結構経った気がします。
いずれかはそうなるかもしれませんが 正確性が必要なソフトになればなるほどAIでの自動化は難しいと感じます
絵とか エンタメ等間違っていても問題ないような物ではAIでの自動生成は有用で 速いと思いますが
正確性が必要な部分ではAIで出力したソフトのテスト等 実運用での問題点等を把握できる人の介入が現状どうしても必要です。
これは数年でどうにかなる問題ではないと感じます。
例えばあるOS、環境等では動かないPGが生成された場合それを修正するためには動かないPGを生成させないための仕様等をAIに指示できるエンジニアが必要でしょう
止まっても問題無いようなシステムであれば止まるたびにAIに指示をしエラーを修正させることも可能でしょうが 可用性は皆無だと思います。
限られた環境で動かすプログラムを作るにはそれ相応の知識が必要になると自分は思っていますが
それらを考えずにAIで指示し良いプログラムを作ることができるのかは今後が楽しみではあります。
（特にスレッド関連、メモリ関連、実行速度関連がAIでいい感じに作れると平和になるエンジニアが多いと思います）
AIでプログラマーが無くなるという点についてはなくなると思います。
エンジニアが仕様書をしっかり作るだけでソフト、テストコードまでできるのであればそのエンジニアの下に在籍していた開発者は全員いなくなると思います。
我々は物事の概要を伝える場合に、よく概念図を利用します。
例えばシステム全体図、サーバーとクライアントの関係、クラスAとクラスBの関連などです。
この時関連を表すのに矢印をよく使いますが、図を描くときにも読むときにもとても注意が必要です。
例えばクラス図においては、
A→B はAがBを知っている場合に使いますが、その逆はありません。
同じようにして、
例えばモデルと画面の分離アーキテクチャMVVMを表現すると、V→VM→M となります。
上の2つの例は参照と言い換えることができます。
MVVMを説明する図で V⇆VM⇆M と表現されている場合もあります。
この場合は単にVとMが直接繋がっていないことを強調している場合もあれば、
単純なデータの流れを表しているとも考えられるし、
イベントまで考えると、VはVMを知っているし、VMはイベント発行側なのでVへの参照を持つので、
これもやはり参照を表した矢印と考えることもできます。
大切なのは何を表現しようとした矢印なのかをしっかり考え、
1つの図の中で、参照とデータのような意味の異なる矢印を使わないようにすることです。