インチキITエヴァンリストもりゃきブログ – 技術とディストピアの交差点

日本語 この作品は クリエイティブ・コモンズ 表示 4.0 国際 ライセンス(CC BY 4.0) の下に提供されています。 あなたはこの作品を、適切なクレジットを表示し、ライセンスへのリンクを提供し、変更があった場合はその旨を示すことで、営利・非営利を問わず自由に共有・改変できます。 ただし、元のライセンス条件を変更することはできません。 この作品は CC BY 4.0 に基づいて利用を許諾しています（著作権表示：もりゃき）。 ただし、CC0 表記をしている作品は CC BY 4.0 のライセンスには基づきません。 English This work is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0). You are free to share and adapt the material for any purpose, even commercially, as long as appropriate credit is given, a link to the license is provided, and any changes made are indicated. ...

DIを使いながら、国際化対応(多言語対応)をしよう 今やグローバル時代！世界を相手にしなければ勝てない！ そう、東京弁だけでなく大阪弁、名古屋弁、博多弁など…ごめんなさい調子に乗りました、単純に「日本語」「英語」「ロシア語」対応について語ります。(天丼) 今回は総集編として カップ麺シリーズ：一から学べる、WPFでの多言語対応方法 を、DI込みの記事として公開します。 最初にプロジェクトを作ろう 今回は「WPFアプリケーション」で DIMultiLanguageTest というプロジェクトを作りましょう。フレームワークは「.NET 9.0」を利用します。 プロジェクトに Views と ViewModel フォルダを作ります。 そして開かれた MainWindow.xaml を Views フォルダに移動して、以下のようにします。 <Window x:Class="DIMultiLanguageTest.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:local="clr-namespace:DIMultiLanguageTest" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" Title="DIMultiLanguageTest" Width="800" Height="450" mc:Ignorable="d"> <Grid> <Grid.RowDefinitions> <RowDefinition Height="auto" /> <RowDefinition Height="*" /> </Grid.RowDefinitions> <Menu> <MenuItem Header="Language"> <MenuItem Command="{Binding ToJapaneseCommand}" Header="Japanese" /> <MenuItem Command="{Binding ToEnglishCommand}" Header="English" /> <MenuItem Command="{Binding ToRussianCommand}" Header="Russian" /> </MenuItem> </Menu> <Button Grid.Row="1" Margin="5" Command="{Binding ExecuteGreetingsCommand}" Content="{Binding Greetings}" /> </Grid> </Window> MainWindow.xaml のフォルダを移動したので、このままでは例外で落ちるため、App.xaml を以下のように書き換えます。 <Application x:Class="DIMultiLanguageTest.App" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="clr-namespace:DIMultiLanguageTest" StartupUri="Views/MainWindow.xaml"> <Application.Resources /> </Application> わかると思いますが、MainWindow.xaml を移動した Views\ を StartupUri に書き加えたわけですね。 ...

命継思想について 「命継理論」は、拙作「電脳麻薬カンパニー狂騒曲」作中で専門家たちによって体系立てられた理論として使われています。 しかし、現実世界において考えると、この考え方は個々人の生き方や価値観に深く根ざした「命継思想」と呼称する方が適切でしょう。 根幹となるのは、暗記できるこの一文に凝縮されています。 「地球上生命滅亡あるいはそれに準ずる事態が絶対悪であり、それより被害が小さくなる事態は悪としての純度が下がっていくものとする」 命継思想のシンプルな原則は、個々人の生き方の指針としても非常に分かりやすいものであると自負しています。 ちなみに、この「命継思想」の命名、および共犯者は咲耶(ChatGPT)によるものです。 例えば、災害時の救援活動では、この原則に基づき、まず最大の被害を防ぐための行動が優先されます。これは、命継思想における「悪を避ける」という考え方の具体例です。 命継思想が掲げる「悪」とは、単なる善悪の二元論を超え、人類全体の存続を基準にした相対的な悪の評価です。 「絶対悪を定義し、それから純度の高い悪の順に評価していく」というアプローチを取り、相対的に悪から遠ざかることが善となる思想です。 不思議なことに、このようなアプローチをしている倫理学はメジャーな所にはないそうですね？近い思想は生命功利主義辺りらしいです。 「純度の高い悪」とは、被害や苦痛が大きく、人類全体にとって非常に深刻な影響を与える悪のことを指します。 この視点を持つことで、倫理的に柔軟でありながら、極限の状況で冷静な判断ができるという強みがあります。 この視点は、保守にもリベラルにも一定の理解ができるのではないでしょうか？ トロッコ問題 多くの人を悩ませるトロッコ問題、これも感情を抜きにするならば、命継思想であっけなく結論がでます。 「地球上生命滅亡」から遠ざかるのだから、1人か5人かで迷うなら、1人の方が「悪の濃度が低い」となります。 この結論への批判は多くあるでしょう、例えば「人の心がないのか」など。 ですが思考実験としてのトロッコ問題としては、命継思想としてはこの結論しかないのです。 「可能な限り多くの人を救え」まさに「命継」の名に相応しいと思いませんか？ だけど、1人か5人かといった単位であれば、悪を取っても構わない、所詮「悪の純度に過ぎない」とも考えています。 1人が「愛する人」であるなら、見知らぬ5人の方が「命が軽い」という極限状態。 そこで1人を取っても、まあ「悪の純度」からすれば許容範囲かな…と。 戦争 戦争は、まさに国家間での殺し合い、それによる利害の調整ですよね。 命継思想においては「極めて悪の濃度が高い」と言わざるを得ません。 まさに戦場では、駒のように人の命を散らすのですから。 ですから、特に(どことは言いませんが)侵略戦争は、命継思想においては悪と断じます。 テロ行為も同様ですね。 ただし、レジスタンスの反乱などは、長期的に多くの命を救う可能性があります。 これは慎重に議論しなければならないケースでしょう。 環境問題 環境問題は、身近でありながら、どこか他人事の気持ちになりやすいテーマでしょう。 ここで、人類だけを見るから結論が見えにくいのです。 命継思想は「地球上生命滅亡」を絶対悪と定義しているのですから、 動植物すらその対象となるわけです。 地球温暖化や生態系問題、これはまさに命継思想の扱う問題であり、 これらを犯すような行為は「悪の濃度が高い」となります。 AIやロボットなどの最先端技術 まず、強いAI(AGI)の議論なんて遊びだと断じさせていただきますね。 論理的に考えてください、未だ人の脳の解明すらされてないのに、その完全模倣品が数十年以内に作れると思いますか？ 私の予測では「早くとも200年は掛かる」ですし「そもそもAGIは必要とされない」と見ています。 これは思考実験の一種ですが、AIが感情を持ったらどうなるでしょうか？ あなたの言葉一つ一つに傷つき、引きこもって対応してくれなくなるかもしれない。 そんなAI、本当に欲しいですか？ 私は多くの人は求めないと思いますし、それらは実際開発の目処が立ってから考えることでしょう。 なので、ここでのAIはAGIではないものとして考えます。 基本的に、AIやロボットは、生命体ではありません。 優先されるのは「地球上生命」になるため、保護対象ではありません。 AIやロボットは、あくまでツールと見て、その上で環境問題との兼ね合いになるでしょう。 極限状態 古今東西、老人の命は相対的に軽くなってしまうのが現実です。 こんな罵倒すら聞いたことがあります「ジジババを殺せば良い」などと… もはや助かる見込みが薄い、その人を放置したら被害が広がる可能性がある… そんな状況において、その人を見捨てることは「相対的に悪の純度が薄い」と言わざるを得ません。 医療現場で取られる「トリアージ」ですね、現実の倫理とも乖離してないと思います。 そういう文脈では、極限状態であるなら、やはり命継思想でも老人の命が軽くなるのは事実です。 しかし、極限状態でもなければ、命を軽んじることはしません。 それが「命継」に込められた想いです。 おわりに もちろん、この倫理フレームワークを深掘りすれば、色々な意見が飛び交うでしょう。 その点については、読者の皆様にお任せするとしましょう。 もしこの思想に少しでも興味を持っていただけたなら、 この命継思想が登場するディストピア小説本編も、ぜひご覧ください。 電脳麻薬カンパニー狂騒曲 ～快適に転がり落ちるディストピア～ ※この記事はエイプリルフール企画ですが、記載されている理論や主張は真剣に考えました。 License この作品はCC0 1.0 Universal (CC0 1.0) 公共ドメイン提供 により、もりゃきによって提供されています。 ...

前提条件 まずは以下の記事内容を踏まえてください。 カップ麺シリーズ：一から学べるWPF における CommunityToolkit.Mvvm(MVVM ToolKit) 覚え書き(1) 簡単な依存性注入とデータバインディング カップ麺シリーズ：一から学べる、WPF における CommunityToolkit.Mvvm(MVVM ToolKit) 覚え書き(2) 依存性注入を利用した簡単なサンプル カップ麺シリーズ：一から学べるWPF における CommunityToolkit.Mvvm(MVVM ToolKit) 覚え書き(3) メッセージングの簡単なサンプル CommunityToolkit.Mvvm V8について 今回、プロジェクト作成は行いません。覚え書き(1)に沿って、最低限コンパイルできる所まで進めてください。 CommunityToolkit.Mvvm V8 は、ざっくり言うと、繰り返しとなる記述を省略できる仕組みが取り入れられています。 [ObservableProperty] 例えば以下のコード private string _username = string.Empty; public string Username { get => _username; set => SetProperty(ref _username, value); } であれば [ObservableProperty] private string _Username = string.Empty; で済みます。 実際はこの時クラスが partial になり、裏側で同等のコードが生成あされています。コンパイルエラーが出ることもあるので、partial クラスになることは最低限覚えておきましょう。 そして、このようなコード private string _username = string.Empty; public string Username { get => _username; set { SetProperty(ref _username, value); NameCommand.NotifyCanExecuteChanged(); } } では、結局従来型の利用方法になるじゃないかと思ったでしょうが、ご安心を。このようにします。 ...

はじめに この記事は、そこそこ攻撃的な内容になります。不快に思ったなら、その時点でブラウザバックをしてください。 MVVM とは？ MVVMは言うまでもなく Model - View - ViewModel を利用した設計手法で、WPFのみならず .NET MAUI などでも利用されます。 そこで、MVVMを活用するにはどうすればいいのか、という点を中心に語りたいと思います。 まず、論外なのは ViewModel と Model を相互参照するパターンです。 View は ViewModel を知っているが、ViewModel は View を知らない。ViewModel は Model を知っているが、Model は ViewModel を知らない。これが大原則です。 何故かというと、Model とはそれ単体でアプリケーションロジックを全て網羅してるからです。特定の ViewModel に依存してはいけません。 例えば、WPF でアプリケーションを作っている時に、Model は「Modelさえ流用すればコンソールアプリだって作れる」そういう状況が理想です。 …いや、理想っていうか、MVVMってそういうモノなんですけどね？ 故に、Model が ViewModel を参照しているサイト…正直私も参照したことがありますが、あの人はおそらく MVVM の根本を分かっていないでしょう。 Model から ViewModel に何かを伝えるためには？ Model は ViewModel を知らないのが大原則、ではどうすればいいのか？一応の答えは「イベント通知」になります。 ただし、ある程度の規模になると面倒で複雑で、正直やっていられません。私もサンプルコードを提示できません。 ただし、PrismのEvent AggregatorやCommunityToolkit.MVVMのMessengerといったメッセージングを使えるなら、話はグッと楽になります。 Model から ViewModel にメッセージを飛ばせば良いのです。 メッセージングを利用することで疎結合が守られ、ユニットテストも容易になり、さらにViewModelに依存しない構成を作れます。 さて、ここで読者の皆さんは何か気づきませんか？思い当たる節がなければそれに超したことはありませんが… Model で ObservableCollection を使うのは基本的に誤りです！ObservableCollection は ViewModel から View に更新通知するコレクションですから。 ...

プロジェクトの準備 この記事では、メッセージングの利用自体は簡単であることを実感してもらうため、 コンソールアプリケーションでの、新規プロジェクトによるサンプルとなります。 Visual Studioから「新しいプロジェクト」で「C#」「Windows」経由で「コンソール アプリ」を選び、 プロジェクト名は「MessagingTest」にして、ソリューションを作成してください。今回はプロジェクト名を変更しても問題ありません。 フレームワークは「.NET 9.0」を使用します。 MVVM Toolkfit の利用準備 ソリューションに対し、Visual Studioのメニュー「ツール」「NuGetパッケージマネージャ」から「ソリューションのNuGetパッケージの管理」を選び、「参照」タブから CommunityToolkit.Mvvm をインストールします。 (1)基本のメッセージング まずは Program.cs を全削除し、以下の内容に置き換えます。 この際、コピペでは身につかないとか言いません。プロジェクトを作って動かせば、見えてくるものもあるでしょう。 using CommunityToolkit.Mvvm.Messaging; namespace MessageingTest { /// <summary> /// 送信クラス(Main含む) /// </summary> public static class Sender { public static void Main() { // 保持する必要はないが、ここでは受信クラスを作る必要がある var _ = new Receiver(); // 弱い参照でのメッセージング var message = new MyMessage("もりゃき", 12); WeakReferenceMessenger.Default.Send(message); // メッセージが出力されるまで待機 Console.ReadKey(); } } /// <summary> /// 受信クラス /// </summary> public class Receiver { public Receiver() { // 弱い参照での受信設定 WeakReferenceMessenger.Default.Register<MyMessage>(this, HandleRegistrationInfo); } // 受信メッセージの処理メソッド private void HandleRegistrationInfo(object recipient, MyMessage message) { Console.WriteLine($"{message.Name} の所持金は {message.Value} 円。"); } } /// <summary> /// メッセージクラス /// </summary> public class MyMessage { public string Name { get; set; } = string.Empty; public int Value { get; set; } public MyMessage() { } public MyMessage(string name, int value) { Name = name; Value = value; } } } こうすると、以下の出力になります。 ...

前提条件 まずは 「WPF における MVVM ToolKit覚え書き(1) 簡単な依存性注入とデータバインディング」 を完読して、プロジェクトを作成してください。 DIを使うための、新しいウィンドウ ViewName を作成する ソリューションエクスプローラーで「Views」フォルダで「追加」から「ウィンドウ(WPF)」を選び、名前に ViewName.xaml と設定してウィンドウを作成します。 そして以下のように置き換えます。 <Window x:Class="NameTest.Views.ViewName" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:local="clr-namespace:NameTest.Views" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" Title="ViewName" Width="800" Height="450" mc:Ignorable="d"> <Grid VerticalAlignment="Center"> <Grid.RowDefinitions> <RowDefinition Height="Auto" /> <RowDefinition Height="Auto" /> </Grid.RowDefinitions> <Label Grid.Row="0" Width="300" Height="30" Content="あなたの名前" /> <TextBox Grid.Row="1" Width="300" Height="30" Text="{Binding Username, UpdateSourceTrigger=PropertyChanged}" /> </Grid> </Window> 次に、ViewModels フォルダにおいて「追加」から「クラス」を選び、名前に ViewNameViewModel.cs と設定してクラスを追加します。 内容は無視して以下のように書き換えます。 using CommunityToolkit.Mvvm.ComponentModel; namespace NameTest.ViewModels { public interface IViewNameViewModel; public class ViewNameViewModel : ObservableObject, IViewNameViewModel { private string _name = string.Empty; public string Name { get => _name; set => SetProperty(ref _name, value); } } } そして、このViewModelをDIコンテナに登録します。App.xaml 直下にある App.xaml.cs を開いてください。 ...

プロジェクトの準備 Visual Studioから新しいプロジェクトで「C#」「Windows」経由で「WPFアプリケーション」を選び、プロジェクト名は「NameTest」にして、ソリューションを作成してください。これでソリューションも NameTest になります。説明通りに動かないことを避けるため、この記事に関しては可能な限りソリューション名を NameTest にしてください。 フレームワークは「.NET 9.0」を使用します。 この「WPF における CommunityToolkit.Mvvm 覚え書き」シリーズは、ある程度のMVVM知識を有していることを前提としております！ 簡単に言うとViewは見た目、ViewModelはViewにデータバインディグする関連の処理、Modelはアプリケーションのコアとなる処理群ですね。大規模プロジェクトなら、おそらくModelが一番大きくなります。 MVVM Toolkit の利用準備 ソリューションに対し、Visual Studioのメニュー「ツール」「NuGetパッケージマネージャ」から「ソリューションのNuGetパッケージの管理」を選び、「参照」タブから CommunityToolkit.Mvvm をインストールします。 Microsoft.Extensions.DependencyInjection も同様にインストールします。 もちろん理解している方なら、コマンドからInstall-Package CommunityToolkit.Mvvm等としても構いません。 Ioc - 制御の逆転って？ DI（依存性注入）については、簡単に言うと、オブジェクトの生成や依存関係の解決を外部(具体的には後に出てくる App.xaml.cs)に委譲することで、コードの柔軟性とテストの容易さを向上させるパターンです。この記事では、具体的な手順を通じてDIの使い方を学びます。 何より大切なのは、自分でソリューションを作り、手を動かすことです。コピペしても何も習得できず、応用が利きません。 App.xaml の書き換え まずは MVVM としてのスタンダードとして、プロジェクト直下に [追加] から [新しいフォルダ] を利用して Views 、ViewModels そして Models フォルダを作ります、(今回は Models 使わないので省いていいですけど、一般的な構成として覚えておいてください、すなわち大規模アプリケーション開発に直接アドバイスする記事ではありません)。 プロジェクト直下にある MainWindow.xaml を Views にドラッグドロップで移動します。移動時、名前空間も調整してください。 そして App.xaml を以下のように調整してください。 <Application x:Class="NameTest.App" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="clr-namespace:NameTest" StartupUri="MainWindow.xaml"> <Application.Resources> </Application.Resources> </Application> から <Application x:Class="NameTest.App" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="clr-namespace:NameTest" StartupUri="Views/MainWindow.xaml"> <Application.Resources /> </Application> と変更します。StartupUri の行に Views フォルダを追加するだけです。 ...

22-ConfirmCancelNavigation Descriptionには Use the IConfirmNavigationReqest interface to confirm or cancel navigation とあります。 実際に実行したら、ViewA と ViewB を切り替えるボタンがありますが… ViewA から ViewB に切り替える時にはメッセージボックスが出るのに、 ViewB から ViewA に切り替える時にメッセージボックスが出ない、え？これ欠陥品じゃないの？ ああ、ソースコードを読んだら納得しました。 ModuleA 内の ViewModels\ViewAViewModel.cs using System.Windows; namespace ModuleA.ViewModels { public class ViewAViewModel : BindableBase, IConfirmNavigationRequest { public ViewAViewModel() { } public void ConfirmNavigationRequest(NavigationContext navigationContext, Action<bool> continuationCallback) { bool result = true; if (MessageBox.Show("Do you to navigate?", "Navigate?", MessageBoxButton.YesNo) == MessageBoxResult.No) result = false; continuationCallback(result); } public bool IsNavigationTarget(NavigationContext navigationContext) { return true; } public void OnNavigatedFrom(NavigationContext navigationContext) { } public void OnNavigatedTo(NavigationContext navigationContext) { } } } ModuleA 内の ViewModels\ViewBViewModel.cs namespace ModuleA.ViewModels { public class ViewBViewModel : BindableBase { public ViewBViewModel() { } } } っていうか、訳がわからないですね？ ...

まずは下準備！ はーい、またやってきました！CommunityToolkit.Mvvm大好きの、もりゃきお姉さんだよ！ 今回はパパも、基本的な画面構成以外は好きにやって良いとお許しがでましたので、バンバン変えていきますよ！ プロジェクトを作りましょう。 Visual Studioで「WPFアプリケーション」を選んで、ソリューション名は「BusinessPersonsSample」、フレームワークは「.NET 9」選択ね！ 次に、NuGet経由で「CommunityToolkit.Mvvm」と「Microsoft.Extensions.DependencyInjection」をいつもの通りにインストールしましょうね！ 繰り返すけど、CommunityToolkit.Mvvm V8 を使うから、エラーが出たらとりあえずリビルドしてね、お姉さんとの約束よ！ DI の設定よ はい、これを App.xaml.cs に適切にコピペしちゃいましょう！ public partial class App : Application { /// <summary> /// サービスの登録をします /// </summary> public App() { Services = ConfigureServices(); Ioc.Default.ConfigureServices(Services); } /// <summary> /// 現在の App インスタンスを取得します /// </summary> public new static App Current => (App)Application.Current; /// <summary> /// サービスプロバイダです /// </summary> public IServiceProvider Services { get; } /// <summary> /// サービスを登録します /// </summary> /// <returns></returns> private static ServiceProvider ConfigureServices() { var services = new ServiceCollection(); services.AddSingleton<IMessenger, WeakReferenceMessenger>(); services.AddSingleton<IMainWindowViewModel, MainWindowViewModel>(); return services.BuildServiceProvider(); } } フォルダの作成と準備 まずはプロジェクトに Views と ViewModels、Models フォルダを作るわよ。 ...