はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「TIOBE Index for November 2025」（2025年11月のTIOBE指数）でこんな面白い見出しを見つけました！ November Headline: Is C# going to surpass Java for the first time in history? C# は史上初めて Java を追い抜くことになるのか？ つい最近まで、Python の成長率に並ぶ言語はありませんでした。しかし今、Python は頭打ちのようです。Python に代わり、C# が最も急成長していると言われています。C#

複雑性はなぜ破綻するのか？ 計算量と認知負荷から読み解く、ソフトウェアの限界について考えました。 これは、情報過多時代の「過学習」にも通じるテーマです。 私たちの脳がどこで飽和し、どこから理解が追いつかなくなるのか..その構造を知ることは、エンジニアリングだけでなくリスキリングの土台にもなりうると思っています。 はじめに ソフトウェア開発には、「複雑性が問題を生む」 という常識があります。 なぜ複雑になると破綻するのか どこから複雑と呼べるのか どの瞬間に人の理解が追いつかなくなるのか 技術負債は、なぜ突然「手がつけられない」段階まで膨張するのか ソフトウェアの複雑性を・・ という3つのレンズで読み解いてみました。 ポイントは、「複雑なコード」 ではなく、「複雑さ自体の本質」 を扱うことです。 1. 複雑性とは「計算量の爆発」を人間が受け止められなくなる現象 ソフトウェアの複雑性は、しばし

はじめに Visual Studio 2026 から、ついに MCP（Model Context Protocol）が IDE に標準対応しました。 これ、地味ですが VS2026 最大級のアップデートです。（いや、地味ではないか…） その背景には、Copilot の役割そのものが変化したことがあります。 VS2022 までは Copilot は “補完・提案” がメイン VS2026 では Copilot が外部ツールを叩ける 「エージェント」 へ進化 そしてこのエージェント化を支えているのが MCP です。 Copilot が MCP ツールを標準で扱える [ビルトイン] nuget MCP サーバーが最初から付属 有効化はチェックを入れるだけ MCP サーバーの実行は UI で可視化され、確認ダイアログも出る つまり VS2026 は、

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに C++は3年ごとに新しい規格が策定されていて、2025年11月時点では最新のC++23が各コンパイラで実装されつつあります。 そして、次期規格のC++26も標準化委員会で策定が進んでいます。 今回は、C++23で追加された機能とC++26で提案されている機能をコード例とともに紹介し、C++の最新動向をまとめました。 ※本記事は公開されている標準化ドキュメントやcppreferenceを基に、一般の開発者視点でまとめたものです。 1. C++標準の進化タイムライン ISOによって3年周期で更新されるC++。最新はC++23、次期はC++26ですが、実際の開発現場ではC++17やC++20がまだ主流です。バージョンによって使える機能は大きく異なるため、どの規格で何が追加されたかを把握しておくことが重要です。 現在のC++エコシステム 出典: ISO C++ Standards Com

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 先日、こんな記事を書きました。 結構ニッチな話題だし読む人も限定されると思って書いたのですが、沢山の人に見ていただけたみたいで驚きました。この記事 でも書いたのですが、Windowsアプリ開発の現場にいると10年前と言わず20年前のシステムが今でも稼働していることが多々あります。 そして、これだけ長期間稼働しているシステムは、度重なる機能追加や改修を経て肥大化し、当初の設計思想は見る影もなくなっていることが多いです。歴代の担当者が各々の判断で手を加えた結果、全体像を把握している人が誰もいないブラックボックスと化しているのが実情

はじめに C#は急速に進化してきた言語です。10年前の「当たり前」は、今では保守性やパフォーマンスの観点から非推奨になっていることもあります。 今回は、レガシーシステムの保守や段階的なリファクタリングに携わる開発者向けに、よくある「昔の書き方」から「現在の推奨」への置き換えパターンを、すぐに実装できるスニペット集としてまとめました。 C＃開発の現場に入ると、新規開発でない限り意外と古いコードを見ることが多いと思います。 今まで受け継がれてきたシステムは大量にあり今でも10年以上前のシステムが元気に動いています。 そして開発者も容易に書き方を変えることはしません。プロジェクトととして統一する狙いもあると思います。それでもコードは確実に進化してます。ぜひ覚えておいてほしい「今と昔のコード」を集めてみました。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに 生成AI（ChatGPT、Claude、GitHub Copilotなど）でコードを書く機会が激増している中、開発スピードは劇的に向上していますが、「動くコード」と「安全なコード」は別物です。 特に本番環境では、パフォーマンスやセキュリティ、保守性まで考慮する必要があります。 AIが特に書きがちな（または書いたら嫌な）危険パターンを15個 厳選してみてみました。それぞれに「何が危険か」と「修正例」をセットにしています。 【 この記事の対象読者 】 ◇ 生成AIを使ってPythonコードを書いているエンジニアとか ◇「動くけど本番に載せて大丈夫？」と不安を感じたことがある人とか ◇ チーム開発でAI生成コードを安全に活用したい人とか とりあえず、「覚えておいたら便利かも！」ってところです。

はじめに 現在の産業界において、PLC（Programmable Logic Controller） は製造現場から物流システム、インフラ設備まで幅広く活用されています。最近では IoT や DX推進においても重要な役割を担っています。 そして、PLCとPC（C#アプリ）を連携させることで、リアルタイム監視、予知保全、品質管理、生産管理、クラウド連携など多様なシステムが実現できます。 C#は .NET Framework の豊富なライブラリ、Visual Studio の強力な開発環境、さらには Azure IoT Edge や AWS IoT Greengrass との親和性により、産業用システム開発においても非常に有効な選択肢です。 C#の可能性は無限大！！ しかし、多くの開発者が最初にぶつかる壁は 「そもそもPLC通信ってなに？」「どの技術を選べばいいの？」 という基本的な疑問ではな

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに C#の基礎文法を読むだけでなく手を動かして身につけるための100問の練習問題集を作ってみました。 GitHub Codespacesを使用することで、環境構築不要でブラウザ上ですぐに学習を始められます。 すごーく長いけど、100本を全てこの記事にまとめました！！ 初心者さん用に作ったのですが、ベテランさんでも眺めてみると意外と新しい発見があるかもしれません。 対象環境 C# 10.0以降 (.NET 6以降) 推奨: .NET 8 (最新LTS版) GitHub Codespaces: デフォルトで対応済 概要 目的: C#の

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに 突然ですが、C#の新バージョン機能って追えてますか？ 言語仕様はバージョンアップのたびにたくさんの新要素が増えています。ほんの数行の文法シュガーでも、コードの可読性やメンテナンス性を大きく向上させることがあったりします。 今回は、C# 10 以降（C# 11, C# 12…など）で追加された「小さいけれど便利な機能」にフォーカスしながら、具体的な使い方や注意点をまとめました。 （かなり地味だけど個人的にはすごいやつ集めてみました！） 「そういえばこんな機能あったんだ…」 「昔の書き方をそのまま使ってたけど、もっと簡潔にできるじゃん！」 など、新たな発見のきっかけになれば嬉しいです。

はじめに C#の画像処理において、パフォーマンスを追求する際にunsafeコードを使用することは割と一般的ですよね。実際に使われているのをよく目撃します。 今回は、そんなunsafeコードの適切な使用場面と、より安全な代替手段について改めてまとめました。画像処理に限らず、大量のデータ処理や計算集中型の処理にも有用なのでぜひ参考にしてください。 unsafeアプローチについて まずは、unsafeコードについて軽くご紹介します。unsafe（アンセーフ）を日本語にすると「危険」「安全ではない」という意味です・・・ちょっと怖いですよね。 上級言語のC#が低級言語のような直接的なメモリ操作を行えるようになります。メモリを直接操作するため、メモリコピーやポインタ演算が可能となり、高速な処理が期待できるのです。 unsafeコードの特徴

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに エンジニアとして働いていると、時として「これは一体なぜ？」と首を傾げたくなるような不思議な現象に遭遇します。 絶対にみんなも一度は経験あるかもしれない…そんな「ITの摩訶不思議」な現象をピックアップし、その裏に潜む技術的な真相を勝手にまとめてみました。 1. 幻のバグ「シュレーディンガーのバグ」 現象 本番環境でのみ発生し、デバッグを仕掛けた途端に消えてしまう謎のバグ。まるで量子力学の世界のように、観測した瞬間に状態が変化してしまいます。 真相 オブザーバー効果：ログ出力やデバッガの処理による微妙なタイミングの変化 競合状態（Race Condition）：複数のプロセスやスレッド間のタイミング依存の問題 環境の違い：本番環境特有の負荷やデータパターン 対策 # 再現性の高いログ収集の例 import logging import threading logging.basicC

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?