C#初心者向け情報発信中。Blazor＋Azure連携・WPF/WinForms・生成AI活用など。個人事業主（メンター＆情報発信）、元大手IT企業マネージャ、開発20年以上🔧「効率的で楽しい開発」を追求。 ブログ：https://xitter.cf/t.co/rJB7JONEFF、YouTube：https://xitter.cf/t.co/OZIjTutZwc
Joined July 2022
- Tweets790
- Following253
- Followers473
- Likes3.9K
Pinned Tweet
私の自己紹介です。
・💻 プログラミング言語の中ではC#が一番好き
・🛠️ 好きな開発環境はもちろんVisual Studio
・👨💻 尊敬する言語設計者はアンダース・ヘルスバーグ
・🤹 大手IT企業ではマネージャとして苦労も
・😊 今は個人事業主として毎日幸せにプログラミング
お気軽にフォローください ✨
C#Kaigiの基調講演資料をみなおしています。
AI時代の話も含めて、全て面白かったのですが、やはり一番印象に残ったのはC#1.0における「ValueType」の設計判断です。
このような設計判断は、国家百年の計、的な凄みを感じますね。。。
今日はC# Kaigiですね！
参加者の皆さま、よろしくお願いします！
「動作中のプログラムの中身をリアルタイムに覗く — 実行を止めないデバッガのコンセプトとRoslyn計装によるC#実装」を発表しますので、ご興味があったらぜひ！
UnityやBlazorを題材として、Liveデモも行う予定です！
#csharpkaigi
昨日の発表資料を公開しました。
「動作中のプログラムの中身をリアルタイムに覗く — 実行を止めないデバッガのコンセプトとRoslyn計装によるC#実装」
speakerdeck.com/prota/realti…
#csharpkaigi
C# Kaigi 2026、運営・参加者の皆さま、昨日は本当に楽しい時間をありがとうございました！
発表を人気投票 1 位に選んでいただけたのも、とても嬉しかったです。
頂いた Hejlsberg 先生のサイン色紙、大切にします！
#csharpkaigi
生成AIの回答は全て「けっこうよい精度の仮説」と捉えるのもよいですね。（間違っていてもよい）
従来、良い仮説を立てること自体難しかったですが、AIはここのコストを劇的に下げましたね。
「何を調べればいいかわからない」から「これを確認すればいい」になるのは大きいです。
C#/.NETって、Java、C++、Delphi、Haskellとか他言語の既存コンセプトをうまく取り入れていますね。
「Compiler as a Service」(Roslyn)って、けっこう独自で新しいかなとか思ったけど、やっぱりこれもLispのマクロとか、昔からあるメタプログラミングの現代版って感じなのかなぁ。
C#で、フォルダ単位で依存関係の違反を自動チェックできないかなと思っていたら、NetArchTestというライブラリを発見。
これを使えば、プロジェクトに分割しなくても、依存関係をチェックできるようになるかな。
（静的チェックではなく、単体テストとして記述）
アンダース・ヘルスバーグ（C#の生みの親）のすごさを分かりやすく伝えるには…
「今の人気言語トップ10の中で、2つ（C# とTypeScript）を作った唯一の人物」
とかですかね😀
（唯一であってますよね、たぶん）
C# 14の新機能をみると、「痒いところに猛烈に手が届くアップデートの集合体」という印象ですね。
field キーワード周りの改善など、実務で“毎日効く”アップデートですね。
こういう丁寧な積み重ねこそが、C# という言語の強さだと思います。
.NET 10の新機能、AI・クラウド時代に「.NETでシステム全体をフルスタックで…」という強い意気込みを感じました！
devblogs.microsoft.com/dotne…
一方で、（他と比べると相対的に）デスクトップ領域については、歴史と資産を抱えるがゆえの「苦悩」を、ほんのり感じました😅
※あくまで個人の感想です。
C#14 の「拡張プロパティ」について ChatGPT に質問したら、
“クラスにフィールドを後付けできる機能（Mix-in!?）”みたいな説明が返ってきて面白かったです
（※実際はできません）
バッキングフィールドが生じる書き方をすると
This member is not allowed in an extension block
と怒られますね😅
BlazorサーバモードのSignalR使ったアーキテクチャ、けっこうぶっとんでますよね。
学生時代、研究室で「サーバ・クライアント意識せずに統一的にコードを書けるフレームワーク」みたいな研究がありました。
まさか、それを本当に実用フレームワーク化するとは…という感じです。
BlazorのRazorコンポーネント（*.razorファイル）って、コード変換時の介入も難しいし、実行時の内部構造とかも触りにくいな…。
開発支援系ツールつくるときは、Razorコンポーネントはツール開発者泣かせかもしれない😅
双方向バインディングのUI（Blazor 等）で、
「カスタムフィルタの条件ツリー編集」などの“木構造そのものを編集するUI”を作るときは、Single Source of Truth を意識すると安定しやすい気がします。
「UIで編集 → データ更新 → UI再構築」
この流れを意識すると、不整合が減るかと思います。