はてなブックマーク

以下で公開されているアドバイザリー通り、今月末の 10/31 に Azure では全体的に TLS 1.0 と TLS 1.1 のサポートが廃止され、11/01 からは各種 Azure サービスを利用するためには TLS 1.2 以上が必須となります。 対象となるサービスが非常に多いため、影響範囲も広くなりがちですが殆どのケースでは問題ないでしょう。 既に大半のトラフィックは TLS 1.2 が使われているはずですが、TLS 1.2 をサポートしていない古い環境の存在や .NET Framework を使っている場合は明示的に TLS 1.2 を回避する設定が流行った時があるため、いま一度見直しておくのが良さそうです。 一部のサービスでは Azure へのリクエスト時だけではなく、Webhook による Azure から外部へのリクエスト時にも適用されるため、受け側も TLS 1.2 への

Build 2024 で発表された Cosmos DB のアップデートの中でも注目度の高い Vector Search (Preview) について、実際に試して深堀しておきました。これまで Azure で Vector Search を実行するにはコストが高い割に SLA の低い AI Search を使う必要がありましたが、Cosmos DB for NoSQL が Vector Search に対応したことで情勢が大きく変わろうとしています。 基本となるデータストアである Cosmos DB が Vector Search に対応したことで、追加のインデックスとしての AI Search を使う必要がなくなるため、Vector Search の実行結果として Cosmos DB に保存されている全てのデータを取得できるというのは大きなメリットです。もちろん Cosmos DB の全て

Build 2024 では Windows などローカルのリソースを使って Generative AI を動かすという話が非常に多かったように、Keynote でも度々取り上げられた Phi-3 についても AWQ で 4-bit 量子化された DirectML で利用可能な ONNX モデルが公開されています。 セッションでも話がありましたが、Microsoft としては DirectML を使っておけば GPU / NPU の両方に対応できるようにするようなので、今後はローカルでの AI 利用は DirectML が主導権を握る可能性がありそうです。 現状 Hugging Face で公開されている DirectML に対応した Phi-3 の ONNX モデルは以下の 4 種類です。Phi-3 mini と Phi-3 medium の両方が利用可能になっていますが、残念ながら現時点

タイトルの通りですが、このブログでは長年 Google AdSense を使った広告掲載を行っていましたが、今日から全て止めることにしました。止めるに至った理由はいくつかあるのですが、最近の無茶苦茶な広告の出し方に嫌気が差したのが一番大きいです。 正直これまで自分がブログに AdSense で広告を載せているのだから、広告ブロッカーは使わないようにしていたのですが、最近遭遇したページで以下のような広告を食らったので使用を決意しました。いったい何のサイトを開いたのかもわからないぐらいなので酷いですね。 広告ブロッカーのインストールを決意した瞬間であった… pic.twitter.com/tE39ZMxEd2— Tatsuro Shibamura (@shibayan) 2024年5月1日 元々、このブログでお金を稼ぐことは全く考えておらず「はてなブログ Pro 代が出ればいいなー」ぐらいの考

昔にも Dev Container を利用して Azure Functions の開発環境を構築する方法を書いたのですが、その後 Dev Container の機能強化と Azure Functions のアップデートによってベストプラクティスが変わってきたので、現時点でのベストプラクティスを確認しておきました。 Windows 環境であれば Visual Studio 2022 を利用しておけば Azure Functions + C# の開発環境は一発で構築できますが、それ以外の言語で特に Python の場合は Dev Container を利用した方が良いケースが多いです。最近では Visual Studio Code を使う人も増えていますし、Dev Container を用意しておくと最悪でも GitHub Codespaces 上でブラウザベースの開発が出来るので便利になりま

.NET 8 の GA が 2 カ月後に迫ってきたこのタイミングで、Azure Functions での .NET 8 向けアップデートが本格的に発表され始めました。そろそろ .NET 6/7 で Isolated を利用しているケースではアップデートを検討しても良いでしょう。.NET 6 の In-Process を利用しているケースは後述しますが急ぐ必要はありません。 そして .NET 8 とは直接関係ないですが、.NET 8 から主流になるはずだった Isolated Worker モデルの改善が同時に公開されました。ようやく In-Process に近い開発体験が得られるようになってきましたが、正直パフォーマンスと信頼性の面ではまだまだという印象です。 3 updates to the isolated worker model for .NET apps: GA of https

Windows 11 で全面的に導入された Fluent Design System は個人的には結構好みなので、自作アプリでも同じようなデザインを実現したいのですが意外に難しいです。コントロールだけに限れば Windows App SDK を使うとある程度は対応は可能ですが、まだ使いやすく提供されていない機能もあります。 例えば以下は Microsoft Store アプリですが、タイトルバーからして大きく異なっています。全体的に Mica が適用されていて、完全にカスタマイズされたタイトルバーが実装されています。 Windows 11 におけるタイトルバーのデザインについては、以下のドキュメントに典型的なパターンが紹介されているので、こちらを参照するとイメージしやすいと思います。 このように紹介されているということは、Windows 11 向けのアプリではタイトルバー含めデザインを統一

先日開催された Microsoft Build 2023 では Azure Cosmos DB の新機能が数多く公開されました。ぶっちゃけかなり大規模な機能追加となっているので、気になる機能は個別に検証しつつまずは全体として NoSQL API に関連するアップデートをまとめることにします。 とはいえ基本は Cosmos DB Blog で公開された以下の記事を参照してもらえれば問題ないです。 この中で一番使われているはずの NoSQL API に関係するアップデートは以下になります。GA / Preview 合わせてかなり多く、しかもそれぞれがかなり重要度が高い機能になっています。特に Burst Capacity は今すぐ有効化する価値があります。 Burst Capacity が GA Hierarchical partition keys が GA 1TB Serverless C

今朝に発表された Terraform Cloud のアップデートで OpenID Connect を利用した認証情報の取得に対応したようです。Dynamic Provider Credentials という名前で紹介されています。 GitHub Actions ではほぼ OIDC のみを使うようになりましたが、一番強い権限が必要な Terraform Cloud で使えなかったのが悩みの一つでした。GitHub Actions と Azure AD を組み合わせて利用する方法は以前に書いているので、以下の記事を参照してください。 Terraform Cloud を Azure Provider で利用する場合には期限付きの Client Secret を作成する必要があったので、Client Secret 自体の管理が必要になるというデメリットがかなり大きかったです。まだベータ扱いですが、

数年前から WinQuickLook という Windows アプリケーションを趣味で開発しているのですが、内部実装をガラッと変えた新バージョンの開発進捗が著しく悪いことに悩んでいました。現在 V4 というソリューションで絶賛開発中となっていますが、リリース日は未定という状態です。 このアプリケーションの開発を加速させるために、ViewModel を用意するより簡単な方法を求めていました。 初期バージョンは Windows Shell 周りの実装に力を入れていたので、UI 周りは Window が 1 つでボタンが数個ある程度だったため、大体はコードビハインドを使って書いていたのですが、V4 を機に MVVM で作ろうとしたところ余りにも面倒すぎて止まっているのが現状です。 Window が 1 つのアプリで ViewModel を分離して、更に MVVM フレームワークの導入とかそっちの

Visual Studio 2022 17.4 以降に含まれている NuGet 6.4 では、複数プロジェクトでのバージョン管理を一元化出来る Central Package Management が実運用可能なレベルとして提供されています。 NuGet などのパッケージマネージャを利用する際の共通の悩みが、プロジェクト間でバージョンがバラバラになってしまいやすく、それぞれが参照しているパッケージのバージョンを上げること自体に手間がかかることですが、NuGet 6.4 以降では CPM を有効化すると解消可能です。 最新の Visual Studio 2022 か .NET SDK をインストールしていれば CPM が利用可能なので、GitHub Actions などで利用する際には最新バージョンを使うように指定するのが安全です。 SDK スタイル以前の古い csproj でも利用可能です

Build 2022 で発表されてから音沙汰がなかった Windows on ARM 開発 PC である Project Volterra ですが、突然 Windows 開発キット 2023 として発表されて、なんと日本でも発売が開始されたので購入しました。 こういった開発者向けデバイスが最初から日本でも発売されるのは珍しい予感です。 日本の Microsoft Store では価格を巡って混乱がありましたが、どうせキャンセルされると分かり切っていたので、正規の料金になったタイミングで購入したところあっという間に届きました。 あくまでも開発者向けという扱いにいるので外箱は段ボールそのままでしたが、本体は Surface と同様に質感が高く、コンシューマ向けにもそのまま発売して問題ないレベルだと感じています。 スペックについては以下の公式ドキュメントに一通りまとまっていました。最新の Win

引っ越しを機にフレッツ 光クロスを引いて 10Gbps の環境を作っておいたのですが、使っていたルーターが 10GbE が 1 つしかなかったので Wi-Fi 6 の 2.4Gbps 上限で使わざるを得ませんでした。 Wi-Fi 6 でも周りに 5GHz が全く飛んでいない場所なので、実測は 1Gbps 超えで良い環境でした。 とはいえ、このエントリで以下のように希望する Wi-Fi ルーターのスペックを書いたのですが、Wi-Fi 6E 解禁のタイミングで発売されたので買ったという話です。 OCN バーチャルコネクトに対応しつつ、10GbE が 2 つ以上付いた Wi-Fi ルーターがこの世に存在していない疑惑がありますが、Wi-Fi 6E が使えるようになったタイミングで入れ替えを検討しています。 OCN バーチャルコネクトへの対応は日本メーカーのルーターぐらいになってしまうので、今回も

アプリケーション開発で地味に難しい認証周りですが、Azure の Web Apps / Static Web Apps / Container Apps には認証機能が組み込まれているため、コードを修正することなく追加できるので非常に便利です。 既に何回もブログで扱っているので、基本的な使い方については以下のエントリを参照してください。 少し前に GitHub や Sign in with Apple、汎用的な OpenID Connect に対応したので、適用可能なシナリオが大きく広がりました。最近では Azure AD B2C を導入して、OpenID Connect として Easy Auth に登録するパターンも増えてきました。以前はハックっぽい設定を入れる必要がありましたが、今では標準対応です。 継続的に Easy Auth の実装はアップデートが行われていて、少し前には Ope

Build 2022 合わせで Windows App SDK 1.1 の正式版がリリースされていたようです。あまりリリース自体が話題になっていない気がしますが、UWP アプリケーションからの移行先なので 1.1 対応を行いました。 リリースノートを見る限り、割と地味なアップデートという感があります。ぶっちゃけ 1.1 の機能の大半は 1.0 の時にやっておいて欲しかったものです。 It's here! We've just released WinUI 3 in #WinAppSDK 1.1 Stable with several new features & stability improvements to check out✨ 🔎 Release notes: https://t.co/cAK8nb7MHo 🛠 Get started: https://t.co/aya1pKT

GW なので趣味アプリの開発を行っていると、音楽ファイルに保存された曲情報を取得する必要が出てきたので、Windows Property System を使って実現したという話です。 曲情報というのは以下のようにファイルのプロパティから確認出来るメタデータのことです。 単純にファイルからメタデータを読み込むだけなら TagLib# というライブラリを使うと、特に難しい処理が必要なく読み取ることが出来ます。しかし最近はアップデートがほぼ止まっていて、偶に PR はマージされていますがリリースがされていない状態が続いています。 そういう経緯もあり、別の方法を検討した結果 Windows Property System に辿り着きました。 Windows Explorer やファイルのプロパティから確認出来る各種メタデータは、Windows Property System という統一されたインタ

これまで P/Invoke 定義はドキュメントやヘッダーファイルから手書きすることが多かったのですが、最近は必要な Win32 API や COM インターフェースが多くなってきたので CsWin32 を使って自動生成しています。 CsWin32 自体は win32metadata というプロジェクトの成果物となる winmd ファイルから、必要なものだけを Source Generator で生成するツールになっています。 生成してほしい Win32 API と COM インターフェースに関係する構造体と定数も自動生成されるので、依存関係を自分でチェックする必要もないのが最高です。 詳しい説明やセットアップ方法は公式の GitHub リポジトリに任せて、ここからは実際に CsWin32 を使ってアプリケーションを開発する際の注意点と効率化のポイントを書いていきます。 CsWin32 用の

最近は C# と Node.js 以外の環境は WSL 2 や GitHub Codespaces を使って用意することが多いのですが、Conda (Miniconda) を使った環境の構築時にかなりハマったのでメモとして残します。 結果的にはまずまずの環境が出来たと思っていますが、思ったより情報が少ないのと検証中は Codespace のリビルドに時間がかかってしまい厳しかったです。 例によって GitHub Codespaces と言っていますが、中身は Dev Container なのでローカルの VS Code でも問題なく使えるはずです。ちなみに GitHub Codespaces 自体は Team か Enterprise を契約しているとすぐに使えますが、個人向けは永遠にベータの予感がしてきました。 Miniconda の Dev Container 定義を作成する 作成した

Azure AD 認証と App Service Authentication を組み合わせて、Web App へのログインを行いつつ同時に発行されるアクセストークンを利用して、別に用意された API を実行したいというシナリオが存在します。 Microsoft Graph API を呼び出す場合はアプリケーションに許可するスコープを追加すればよいですが、自前で用意した API の場合にはまず API を公開するという設定が必要になります。 公式ドキュメントでも Web App から Web API を呼び出すシナリオが紹介されていますが、Azure AD にアプリケーションを登録するあたりは若干省略されていてわかりにくいです。 最近は Azure AD の設定を Azure Portal からではなく Terraform で全て行うブームが個人的に来ているので、今回も Terraform

Ignite 2021 で発表された Azure Container Apps について、実際に触って調べたのでいろいろと所感を書きます。特に Web Apps / Azure Functions との違い・使い分けについて重視しました。 名前から分かるようにコンテナーの実行に特化したサービスです。既報の通り Kubernetes 上で動作していますが Kubernetes の知識が無くても簡単に扱えるようになっています。 最新の Serverless サービスなだけあって、全体的に設計が洗練されている印象を持っています。最初からログ周りは Log Analytics ベースになっているのも好印象です。 提供される機能と App Service との違い まだプレビューなので機能は少なめですが、現時点で提供されている Container Apps の機能は以下のような感じです。カスタム V

少し前に App Service Authentication と Front Door や Application Gateway を組み合わせた時の問題と解決法を書きましたが、ほぼ同じアーキテクチャの Static Web Apps では当時は回避方法が無く利用困難でした。 Static Web Apps はグローバルに分散されて配信されますが、CDN ではないので Front Door を入れてさらに高度なルーティングとキャッシュを行いたくなることは多いです。 当然ながら非常に困る挙動なので GitHub に Issue を作成していたのですが、先日対応完了したというコメントを貰ったので再度検証することにしました。 まずは適当に Static Web App を Standard で作成して、カスタム認証として Azure AD B2C を設定したアプリケーションを GitHub 経

GitHub や Azure DevOps を使った開発フローにテスト実行を組み込むのは一般的に行われていると思いますが、Azure Storage や Cosmos DB などに依存するテストを実行する際には、実際のリソースにアクセスさせるのではなくローカルで完結させたいことが多いです。 特にテストケースによってはデータが実行毎に揮発してくれた方が都合の良いことが多いので、実際のリソースより気軽に起動とデータの全削除が行える Emulator が便利です。Azure Storage と Cosmos DB には Docker ベースの Emulator が提供されているので、CI と組み合わせるのが簡単になっています。 Azure Storage の Emulator は最近は Azurite が主流になっているので、古い Storage Emulator ではなくこちらを使って行くよう