AIでプログラムの生成が出来た後の事
この文章はAIでプログラムの生成を「github等で公開されたコードから類似を探して適応させる以外の方法で生成する」前提
現状はそんな方法は公開されてない(けどきっと誰か研究してそう)けど、ChatGPTとか画像の自動生成とか音楽の自動生成とかみてるとそんな遠くない時期に何かそれっぽいものが出てきそうだなと...
仮にAIでの凄い自動生成が実現したとして、これまで開発するエンジニアはどうなるのか
設計に合わせてコードを書けるという能力がほぼ価値を失う
逆に非エンジニアが考える要件をAI向けに変換する作業(設計？)は残る。ただし、ChatGPTとかみてると、AIで代用出来る可能性は限りなく高いので、長期的には価値を失う
そして非エンジニアが直接AIを使って欲しいシステムを作れるようになるとする
システムの更新もAIで再生成すれば良い
システム間の連携も所詮codeで実現なのでAIが出来るようになる
データ移行もcodeなのでAIが出来るようになる
インフラもIoCでcodeになるのでAIが出来るようになる
運用・監視も元々データを見る作業なのでAIでカバー
普通のシステムだとやることなぁ〜い！
はやくこうならないかなぁ...
テストと開発工数と...
最近自動テストをすることは必須って風潮で、それはそれとして良いんだけど...って話
いにしえのSIerの手動テストが良いとか言うつもりは全く無い前提で
テストには色んなレベルがあって、それらを認識しつつ「必要なテストを必要最低限作り込む」っていう方向にならないかなぁ〜って思ってみてる
TDDはそもそも開発手法なので、TDDで作ったテストは「実装作業として必要な物」であって、そこで作られるテストは本来の意味ではテストじゃないと思ってる(全部捨てても問題ない)
じゃあ何がテストなのかって話になると
(「要件を満たすことを確認するもの」,「例外的動作をシミュレーションして正しく動作するもの」)
(「定期的に実施して基本的な品質を確認するもの」,「必要に応じて実施して正しい動作を確認するもの」)
これらの組み合わせ
その中で定期的に実施しして〜の部分は自動テスト化しないとかなりしんどい(大抵は相当多めの数になるので)
必要に応じて〜の部分は、再現可能な作業手順さえ存在して居れば自動化されてなくても良い(頻繁に変化しないならの条件付き)
って考えると実はテストは「自動化しなければならない」という必然性はなく、むしろ「再現可能であれば良い」「工数を削減するために自動化しましょう」程度の話になる
あとは「組織として心の平穏を保つため」に何処をどの程度自動化・定期実行していくのかだとおもう
必然性が無いものに、本体の開発工数を超えてのテストを自動化する意味ってなんなんだろうって考える今日この頃
MSFS A320neoでオートパイロット
こんな所にそれっぽい動画があるので、これを見ながら説明
オートパイロットの準備として、IFRを選択する（飛行機の下の選択）
高高度か低高度は好きな方でOK
出発のコースとかはなんとなく好きなやつでOKだけど、滑走路と番号は合わせること
滑走路が22なら出発は「出発(LAXA3 22)」みたいに後ろの数値と滑走路の番号を合わせる
到着も同じ感じで、アプローチは RNAVを選択(他にILSとか色々あるけどとりあえずRNAVで）
ナビログで今回のコースと速度とか高度とかをちょっと確認しておくと良いけどこれはオプション
離陸はオートパイロット出来ないので、パーキングブレーキ解除(十字キーの左)、throttleを最大にして加速
速度メータの所のマークが出た辺りでちょっと操縦桿を引いた(左スティックをちょっと下に)ら離陸
ちょっと高度が上がって(100ftとか)からギアを引っ込め(十字キーの右)て、フラップをあげる(十字キーの上)
そこで「AP」って書いてるスイッチをポチッと押すとランプが光る←めっちゃ重要
その後、throttleを70％くらいまで下げる（そうするとオートスロットルに切り替わるので着陸前くらいまで操作しなくて良い）
APのランプが光っていれば左スティックも触らなくて勝手に移動していってくれるので放置すればいいけど、高度だけはチョコチョコ変える必要がある
（上手くいかないときはランプの点いてる場所が同じか確認）
この段階まで上手くいけば、ここからコントローラー操作はしばらくないのでマウス操作になる
コンソールのところでフライトプラン(FPLNだっけ...?)を表示するボタンをポチッと押す
そしたら何処にどの高度で飛べって書いてるのが表示される(そのまま飛んでれば自動更新される)
表記は「場所」「時間」「高度」なので、場所と高度を見ながら飛ぶ
いまどこにいるかはレーダーっぽい画面に出てる
右上に「向かってる場所」と「距離(海里)」が出てるのでそれを参考にする
目標高度は初期値で5000とかで表示されてる部分
高度はコンソールのフライトプランを見つつ、適当に決める
セット方法は、マウスの真ん中でスクロールさせる感じで数値を選ぶ(この時点ではまだ変化しない)、マウスの左ボタン長押ししつつの、中央クリック（視点移動が中央クリックでそっちも発動するので2回押す）
ほっとくと目標高度に向けて一気に動くのでそれを防ぐのにV/S(垂直方向の制御)を使って一定の速度で上下する方法を使うけど、慣れるまでは一気に動かす
いずれにしろ目標高度に達すると安定するので、次の目標高度の設定とかをしておく
スピードの所は高度10,000までは240くらいで、10,000超えたら330とかにセットする
セット方法は高度と同じでスピード選択からの中央クリックのパターン
高度を上げていってるときとか、V/Sで操作してるときとかに数値を変える場合はなにもしなくても反映されたりするので、やりながら慣れる（パターンはあんまり多くない）
イメージ的には
高度だけセットするとその高度に一気に向かう(普段この動きは見た事ない)
V/Sをせっとしてから高度をせっとすると、V/Sに従ってその高度になる(時間がかかるけど普通の飛行機の挙動)
なんか挙動的に反映されないなぁ〜って思ったらセットすると反映される
しばらくは高度を上げていき...
フライトプランで高度を下げる感じに出始めてからゆっくり高度を下げていく
（東京大阪間を飛んでも安定して飛行するのはちょっとだけ
高度11,000より下になったあたりで、スピードを240くらいに下げる(儀式)
っていうのを繰り返していくと...いつのまにか着陸する空港に近づいていくはず
着陸の一つ前の目標点くらいで速度をどんどん下げる(190とか)
（ILSの表示をオンにすると下がりすぎとかの判断も出来るけど...慣れてからで
着陸の一つ前の目標点を過ぎた段階で、空港の高度に目標高度を合わせつつ、V/Sも適切にセットする（下げすぎない程度なら...
この辺からコントローラーが必要なのでいつでも使える様に準備
着陸ちょっと前で速度を170とかに設定しつつ
目の前でフラップを下げる(十字キーの下)、エンジンをアイドル(一番下)まで下げる、着陸ギアを下げる(十字キーの右)
直前でさらにフラップを下げつつ
タイヤが地面についたら、ブレーキをかけて(Xキー)速度を下げる
着陸成功！！
色々練習した結果、こんな感じだった
慣れたら巡航中に読書したり映画見たり料理したり食事したりも出来るのでオススメ
最近のOSSでふと思ったこと
某OSSがライセンス変更したり、某OSSを使って商売してる企業がライセンス変更に合わせてforkしたOSS作ったりをみてて
企業ベースのOSSの場合はこの辺のリスクを考えて採用する必要があるのか〜
ってふと思った
逆に、非営利団体が管理してるOSSだとライセンス変更のリスクは少なそうだけど
非営利団体が事実上の稼働停止とかするパターンもあるので
OSSの採用って難しいなって思った
このままOSSのライセンス変更リスクとか、セキュリティー対応する人のトラックナンバーが少ないとかの状況が続くと...なかなか厳しい...
OSSでしっかりビジネスが出来る状態が出来ると良いんだけど、難易度高いなぁ〜
（そういえば、なんか15年位前にも同じようなこと聞いたなｗ
MSFS Mobile Companion App
全MSFSユーザにお勧めしたいアプリ
ざっくりした手順
ダウンロードして
2つのファイルを指定の場所にコピペして
MSFS起動して、メインの画面が出てきた頃に
zipを解凍した後に出てくるexeを実行
ネットワーク的に許可する必要があるので許可する
コマンドラインにIPアドレス:4040って出てくるのでそこにアクセス
そうすると...
MSFSと繋がって色々出来る
いちいち画面を切り替えたり見やすい場所に変えたり・・・とか全く必要が無い
ブラウザさえあれば操作出来るのでそこら辺に転がってる端末が使える
これは素晴らしいアプリですね
（欲を言うと切りが無いけど、十分良い
個人的には手作業でやるにはすごく面倒なシミュレーション速度変更がこんなところに！っていうのが一番の感動ポイントだったりする
これで16倍速で飛べば離陸〜着陸までの空を飛んでるだけの時間を凄く短縮出来る
（とある国を飛ぶとひたすら何も無いところが続くのでちょうど良い
アーキテクチャの天下統一は可能なのか？ってふと思った
過去から未来の全てのアーキテクチャの天下統一したアーキテクチャって実現可能なのかなぁ〜って思ったのでちょっと考えた
仮説-天下統一したアーキテクチャ
1. ある一つのアーキテクチャが存在する
2. そのアーキテクチャはあらゆる開発で利用可能
3. 他のアーキテクチャを選択する必要性は全くない
仮設-既存のアーキテクチャ
1. 既存のアーキテクチャはプロダクトのソフトウェア品質要求、コスト、流行で決まる
2. 既存のアーキテクチャで天下統一したものは無い
（参考リンク
ということは
天下統一したアーキテクチャはソフトウェアの品質要求がどんなレベルであろうと、プロダクト開発にかかるコストも要求レベルを実現出来ることになる
＝どんな品質要求でもかかる開発コストは同レベルになる
反論-1
数万ユーザ同時アクセスでms単位でレスポンスを返すことを要求されるプロダクトと
数ユーザ同時アクセスでs単位でレスポンスを返すことを要求されるプロダクトで
開発コストが同レベルになることは無い
反論-2
PoCに適したアーキテクチャと、本開発に適したアーキテクチャが同じになることは無い
（反論パターンは沢山作れるのでざくっと省略
以上の反論から
アーキテクチャの天下統一は無理がある
ただし、プロダクトの特性に合わせたある程度の最適解は同様なサービスのアーキテクチャ等から抽出可能な気がする
おまけ
