ValueObjectは好きですか?私は大嫌いです。いじょ。 ざっくり言えばプリミティブ型に専用の型を付ける教義です。例えばUserIdをintとして扱っているとTeamIdと取り違えるかもしれないし、Hpに突っ込んでしまうかもしれない。StrengthとIntelligenceとAgilityとSpeedは別物なのだから全部intじゃなくて区別して欲しい、そうじゃないと間違った演算しちゃうぞ、と。まぁそういう自体を避けるために、それぞれラップした個別型を作るのです。int strengthじゃなくてStrength strengthだぞ、と。 これは一見正しく実際正しいのですが、問題もあります。一つに面倒くさい。ラップしたctorを作るのだけでも定形でウザ、と思いますが、更に等値とか実装するのは面倒くさい。また、そのままだと計算できなくなるので、算術演算のために生の値を.Valueで取り
We’re pleased to introduce the first preview of Source Generators, a new C# compiler feature that lets C# developers inspect user code and generate new C# source files that can be added to a compilation. This is done via a new kind of component that we’re calling a Source Generator. To get started with Source Generators, you’ll need to install the latest .NET 5 preview and the latest Visual Studio
昔、gist にだけ置いてて、そういえばブログに書いてなかったものを思い出したので書いておくことに。 (一応、部分的には言及したことがあるんですけど、ちゃんとした話はしたことがなかったはず。) 決定論的ビルド 3年くらい前まで、C# コードをコンパイルすると、ソースコードを一切書き換えていなくても、生成結果の exe/dll や pdb のバイナリが変化していました(決定性(deteminism)がない)。 原因は以下の2つです。 バイナリ中に埋め込まれる GUID にタイムスタンプと乱数から生成される値を使っていた デバッグ用のファイル情報がフルパスで埋め込まれていた GUID の方はタイムスタンプと乱数なので本当に致命的で、ローカルで再コンパイルしても毎回バイナリが変化していました。 フルパスの方は基本的には pdb (デバッグ用シンボル情報)だけの問題なんですが、 exe/dll で
Cy#の河合です。昨年12月に、『MagicOnion』というライブラリのリリースを告知しました。今回、再びオープンソースライブラリとして、C#のためのCLI/Batchライブラリをリリースしました。 [GitHub – Cysharp/MicroBatchFramework] .NET CoreになってWindows/Mac/Linux問わずクロスプラットフォームなアプリケーション開発環境として機能するようになったC#ですが、そして機能的には十分揃っているのですが、ちょっと気の利いたフレームワークは意外と欠けているところがあります。バッチ・コマンドラインアプリ。というと地味なトピックスですが、ゆえに基本機能以上のサポートがなかったりします。しかし、「C#の可能性を切り開いていく」という理念を掲げるCy#としては、派手・地味を問わず、現状のC#に欠けているものを埋めていくことで、C#がアプ
環境 ・Visual Studio 2017 ・OpenCvSharp3-AnyCPU ソースコード一式 導入方法 NuGetパッケージマネージャー起動 Visual Studioで新規にプロジェクトを作成する。(今回はMovieOpenCvSharpとした) ツール>NuGetパッケージマネージャー>ソリューションのNuGetパッケージの管理 OpenCvSharp3-AnyCPUインストール 参照>検索欄に"opencv"と入力 OpenCvSharp3-AnyCPUを選択 インストール対象プロジェクトにMovieOpenCvSharpをチェック インストール ソースコード抜粋 注意: 動作検証のためApplication.DoEvents()を使用しています。 アプリを作る場合は別スレッドで描画するなどしてください。 using OpenCvSharp; using OpenCvSh
動機 外界のデータに対して、どのように型付けを行うか - これは人類の当面の課題である。外界からアプリケーションに取り込んだデータに対して、内部で扱いやすいようにnon-nullの型を書くと、予期しないクラッシュを引き起こしてしまった、というような経験を誰しもお持ちではないだろうか。一方で、外界の状況と一致した型を書くと、冗長にnullチェックを書く羽目になり、デベロッパー・エクスペリエンスがよろしくない。このジレンマから逃れるために、外界からデータを取り込む境界部分で包括的なアサーションを施して、アプリケーション内部では対応する型をもっているものとして扱いたい。 JavaScriptでJSON Schemaを用いてアサーションを行うライブラリは知っていたので、うまい具合にJSON Schemaとコードを同期させるソリューションがあれば、JSON Schemaとアプリケーションのコードを同
下記コードのビルドが通らず困っています。 public class TestClass : IBase, IExpansion1, IExpantion2 { public T Get<T>() where T : IBase { return this; } } public interface IBase {} public interface IExpansion1 : IBase {} public interface IExpantion2 : IBase {} 具体的には return this; のところで型変換ができないと怒られます。 思惑としては、 他のクラスがTestClassの機能を使うのに実体そのまま使うのではなく、 利用クラスごとに適切なinterface(IExpansion1, IExpantion2)を取得し、 それを通して使って欲しいと考えています。 その
Blazor との出会い 今年2018年2月7日に、自分のソーシャルネットワークのタイムラインに Microsoft のブログ記事が流れてきました。 A new experiment: Browser-based web apps with .NET and Blazor ブラウザベースの .NET による Web アプリフレームワーク、"Blazor" (ブレイザー) だそうです。 これを読んだ当時、自分はこんな感想を持ちました。 「 "ブラウザベースの .NET による Web アプリ" ってなんのこっちゃ? まだ実験段階的なこと書いてるし、急いで試さなくてもいいかー。それよりも、これまで作った Angular 1.x な Web アプリの Angular5 への移行を急がなきゃ...」 ...ということで、何度も import 文を書く苦行や、*[(xyz)] みたいな呪文マークアッ
プログラムを作成するにあたっては、発生し得る例外というものを十分に考慮しなければなりません。しかしながら、非同期処理/並列処理の場合は例外処理がやりにくいのも実情です。特にタスクは呼び出し元スレッドとは非同期に実行されるので、その中で発生した例外は一体「いつ、誰が」捕捉すべきなのか、という問題にぶつかります。今回はこのようにタスク内で発生した例外の扱い方について見ていきます。 例外の捕捉 タスク中で発生し処理されなかった例外は、タスク自身によって捕捉され、コレクションとして保存されます。WaitメソッドかResultプロパティが実行されると、これらのメンバーからSystem.AggregateExceptionがスローされます。タスクが捕捉した例外は、スローされるAggregateExceptionのInnerExceptionsプロパティで取得できます。 using System; us
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く