はてなブックマーク

.NET CLR1情報を取得するライブラリを数年前に作ったのですが、改めて便利なので公開しました。今回は.NET CLR監視のススメです。 guitarrapc/ClrProfiler .NET CLR情報とは EventListenerとEventPipeの使い分け EventListener API ClrProfiler Datadogで可視化 まとめ .NET CLR情報とは .NETにはCLR event tracingといわれる仕組みがあります。これは簡単にいうとパフォーマンスカウンターで取得していた.NETアプリケーションのメトリクスをWindowsとLinux両方でインプロセス取得できるようになる仕組みです。 .NET Core 2.2からCLRイベントを受信するためにEventListenerクラス導入されました。さらに.NET 3.0以降はEventPipeべースのイン

C#プロジェクトで参照しているNuGetパッケージのライセンス一覧を取得する方法が気になって調べたので紹介します。 ライセンス一覧を取得する方法 dotnet list packageとNuGet APIを使う sensslen/nuget-licenseを使う aaronpowell/dotnet-deliceを使う CycloneDX/cyclonedx-dotnetを使う ライセンスは途中で変わる まとめ ライセンス一覧を取得する方法 ライセンス一覧を確認するには大きく2つの選択肢「dotnet cliのNuGetパッケージ一覧機能を使って自前解析」と「OSSツールを使う」があります。一通り触った感じだと、自前解析も大した手間じゃなく、OSSならsensslen/nuget-licenseとCycloneDX/cyclonedx-dotnetが一番使いやすい感じでした。 dotnet

NuGetにはVisual Studioでパッケージをインストールするときに自動的に実行されるスクリプトの仕組みがあります、それがtools/init.ps1です。 前々からNuGetパッケージインストール時に警告なくスクリプトが実行されて嫌だなぁだと思っていましたが、今回はその理由を考えてみます。 init.ps1とは tools/init.ps1の現状 init.ps1の実行を確認する init.ps1ができること init.ps1の実行を止められるのか init.ps1の懸念 init.ps1を使った攻撃は過去にすでに起こっている init.ps1の代替手段 まとめ init.ps1とは NuGetパッケージにtools/init.ps1というスクリプトを配置することで、パッケージインストール時に任意の処理を実行させることができます。パッケージインストール後の追加処理を自動化する仕組

この記事は Qiita C# Advent Calendar 2021 7日目の記事です。 Visual Studio や Rider での コードフォーマットは個人で使うにとても良く、開発上は必須といえます。 しかしチーム開発でコードフォーマットをいい感じに標準化させたい、労力かけずにフォーマット修正をかけたいと思ったときには CLI で実行できてほしいものです。 dotnet には長らく標準的なコードフォーマッタ用のCLI がありませんでしたが、.NET 6 SDK からコードフォーマッタ dotnet format が標準組み込みとなりました。 今回は C#で開発するにあたり、CI でCLIを実行してC# のコードフォーマットを自動修正する方法を紹介します。 普段からやっていると開発上でフォーマッタで困らなくなるので、塵も積もれば的な良さを感じる人がいれば幸いです。 tl;dr; 実

GitHub Actions の OpenID Connector と AWS の OIDC Provider を使うことで、IAM Role を Assume できるというのは前回書きました。 tech.guitarrapc.com 構築中によく出るエラーに関しても書いたのですが、いざ実際に使おうとしたら別のエラーではまったので忘れないようにメモしておきます。 tl;dr; GitHub Actions で並列実行すると時々失敗する。 configure-aws-credentials を1 jobで複数回呼び出したときに初回の認証を上書きできない 正常動作例1 正常動作例2 問題の動作 tl;dr; OpenID Connect で認証すると、AWS OIDC Provider の認証の上限に引っ掛かりやすい Composite Action の中で、 configure-aws-cr

前々から言われていた GitHub Actions で OpenID Connect 経由で、各種Cloud Provider の認証を得るのが GA しました。 めでたい。 github.blog これにより、aws-actions/configure-aws-credentials のみで認証が組めるようになったので見てみましょう。 https://github.com/marketplace/actions/configure-aws-credentials-action-for-github-actionsgithub.com tl;dr; 動作例 基本 Terraform で AWSを用意する。 OIDC Provider を用意する IAM Role を用意する リソースを作成 GitHub Actions の構成 FAQ GitHub Actionsで実行してみたら動作しない

Git の GUI クライアント、いろんなツールがあってそれぞれ使いやすさがあります。 普段私は、GitKraken をメインにしていますが、サイズの大きなリポジトリでは Fork を利用しています。 しばらくForkをメイン気味に使っていた中で、私がForkに感じた良さと苦手なことをメモしておこうと思います。 tl;dr; 自分のgit利用ケース git GUI クライアントについて Fork GitKraken Fork と SourceTreeの比較 Fork の良い点 Fork の懸念点 特筆点 ForkとGitKrakenの比較 Fork の良い点 Fork の懸念点 特筆点 Fork の欠点と対処 Fork の縦ペインで視点移動は減らせるのか tl;dr; Git GUI クライアント、まだまだ全然決定版がないですね。 GitHub.com や GHE、GitLab など複数の

リモートワークが続いて1年余り経ちました。 ここ半年余りの課題は、仕事中の集中、切れ目の2つなのですが、解消するために何をしているか残しておきます。 tl;dr; 課題 切り替えを促すためにやっていること (集中) 机の上をオフィスと同じようにさっぱりと片付ける (集中/切れ目) 常時オンライン雑談部屋に参加 (集中) 一日、あるいは単位時間の目標を常に示して細かく達成していく (集中) Twitter を開かない (集中/切れ目) 仕事のトリガーを作る (集中) 集中切れた、眠くなった対策 今後やるか検討していること (集中) スマホを見えないところに置いておく まとめ tl;dr; オフィスで集中で来ているなら、その状況を作れるように努力する、ということでいろいろやっています。 机の上をオフィスと同じようにする 仕事前に身支度を整えて恰好から入る 一日の目標は意図的に細かく書き出して達

ベストプラクティスといいつつ、どのような風にやりたいかで変わるというのは往々にしてあります。 ベストプラクティスは求めても意味ないのでどうでもいいとして、いろんなパターンのメリット/デメリットを把握して現状に即しているのかどうかは考え続ける必要があります。 ということで、長年頭を悩ませて納得感があまりない代表はTerraformです。 今回は以下の記事を読んでて、普段やっているTerraformの構成について書いてなかったので記録として残しておきます。 https://blog.serverworks.co.jp/where_my_terraform_bestpractice 概要 HashiCorp社の Terraformベストプラクティス Nebulaworksの例 なぜ Terraform の構成は難しいのか よく使っている構成 原則 terraformファイルの記載内容 この構成で

私はローカル環境の Kubernetes にDocker Desktop for Windows を用いています。 Minikube や kubeadm、k3s、kind、microk8s など各種クラスタ構成がある中で、WSL2にローカルのクラスタ環境を他で組んだ場合の違いを改めてみておくことにしました。 今回は ローカル Kubernetes クラスタの構成にMinikubeを用いて構築してみて、最終的にどれがいいかの所感です。 目次 目次 TL;DR はじめに 環境 期待する利用方法 Kubernetes のローカルクラスター構成 Minikube on WSL2 のインストール systemd の構成 minikube の動作確認 minikube on WSL2 の面倒な点 余談: なぜローカル Kubernetes 環境を必要とするのか kind on WSL2 はどうなのか

IPv4 PPPoEからIPoEにしつつ、Unifi Dream Machine (UDM) でIPv4 over IPv6環境でアクセスするまで組んだのでそのメモです。 Unifi Dream MachineはMAP-Eに対応していないので、ちょっと小細工が必要だったのは学びでした。 私が欲しい内容の記事がなかったので自分で書くしかないのです。 概要 構成 記事の対象となる人 記事の対象ではない人 LANネットワーク環境の前提 WAN ネットワーク環境の前提 ネットワーク環境 事前調査 採用しなかった方法 必要な条件が何かを考える 必要な条件 余談: UDM とMAP-E 1. PPPoE から IPoE への変更 2. VDSL から 光ファイバー回線への切り替え 3. ホームゲートウェイ（HGW）によるIPoE接続 への変更 4. UDM で IPv6 を受けてクライアントに配布する

Scoop Bucketを作るのは避けたいものです。 しかし、MainやExtrasに追加するのもアレだし、既存のパッケージ更新はメンテされてないし、など様々な理由で自分のバケットを作ることはあるでしょう。 自分のバケットを持った時に面倒なのが、バケットの更新追従です。 幸いにもScoopにはExcavateという自動更新する仕組みがあります。今回はこれを仕込んでみましょう。 TL;DR 実際に使用しているリポジトリ 動作環境 Scoop App Manifest 自動更新の仕組み 1. 自動更新するバケットjsonを自動更新に対応させる GitHub のリリースページを見る 2. 自動更新スクリプトをバケットのリポジトリにおく 3. 自動更新を定期実行する 実行環境について まとめ 参考 TL;DR Bucketのmanifestを記述したjsonにcheckver、 autoupdat

今年はいろいろなアレコレでずいぶんと働く環境に影響がでました。 今回は週4-5のリモートワークになるにあたって使うようになったものをメモします。ずっと書こう書こうと思って半年経ってただけあって、毎日がっつり使ってます。 TL;DR デスク回り 昇降デスク (スタンディングデスク) 昇降しないデスクの課題 昇降デスクを選ぶ理由 昇降デスクにして気づいたこと Bordeless FeEL ほかのメーカーのを選ぶなら タイルカーペット ホームキャリー デスクワゴン KVM ヘッドホン Windows 関連設定 Windows Hello (顔認証) Dynamic Lock そのほか身の回り オートディスペンサー 3M ワンタッチベルト まとめ 参考 TL;DR 昇降デスクは立ったり座って気分転換でき集中が切れたときの対策したい人におすすめ HDMI切り替えじゃなくてKVM買うと体験がよい。ただ

C# のアセンブリ情報はAssemblyInfo.csによって制御されています。 .NET Coreでいくぶん取り扱いが変わったものの基本は一緒です。 たびたび忘れるので、どのように取り扱いが変わったのか制御方法をメモしておきます。 TL;DR Microsoft.NET.GenerateAssemblyInfo.targets AssemblyInfo の自動生成をなぜ制御するのか AssemblyInfoの自動生成を止める AssemblyInfo の特定の属性の生成を止める TL;DR .NET CoreでAssemblyInfo.csはビルド時に自動生成される csprojにGenerateAssemblyInfoを指定することで自動生成自体を止めたり、GenerateAssemblyXxxxxAttributeを指定することで特定属性の出力を止めることができる 出力を上書きたいと

以前Windowsの開発環境をscoopで構築しているということを書きました。 https://tech.guitarrapc.com/entry/2019/12/01/233522 その際に、scoopを継続的に使っていくためのツールScoopPlaybookを書いたことに触れました。 今回はそのScoopPlaybookの紹介です。 TL;DR 目指す姿 WindowsでAnsiblePlaybook のようなアプリケーションインストール基盤を作る scoop の通常のインストール ScoopPlaybook で定義からインストールする 利用例 普段の利用例 できること バケットの追加、削除 ツールのインストール、アンインストール 管理者権限で実行したい まとめ TL;DR ScoopPlaybookというPowerShellモジュールを作った(2年近く使っている) scoopで何をイ

WSL1を長い間使っていましたが、先日Windows 10 Version2004がリリースされてWSL2に切り替えを行いました。 WSL2いいのですが、WSL1と同じように、あるいはちょっと欲張ろうと少し困ったのでメモ。 TL;DR WSL1 で何をしていたのか WSL2 で何をするのか WSL2 への対応 Windows システムボリュームの利用が増えた Windows Features が不要に WSL OS Provisioning dockerの入れ直しをやめた systemd/snap Windows パスの分離 まとめ TL;DR Windows 10 May 2020 Updateがリリースされてから2週間使ってますが、もうWSL1に戻る気はないぐらいには気に入っています。おすすめです。 具体的には、 👍: WSL2にしてapt/pip3が爆速になってうれしい 👍: W

開発環境ではDockerでDBや各種バックエンドを動かすことが多いのですが、WFHが広がる中で自宅がWindows 10 HomeでDocker Desktop for Windows起動できないんだけど、何か手がないかと相談があったりなかったり。 以前試したときは問題なかったのですが、改めて最新の状況で試します。 また、wsl2の仕組みから言ってHyper-VでホストしたWindows 10 Homeでも動作するはずなのでそこも確認です。 Hyper-VにWindows 10 Homeをインストールしているのでその検証結果も知りたい人にも向けていいのではということで。 更新履歴 TL;DR WSL2について Docker Desktop for Windows をインストールする Insider Preview を Slowring で有効にする Windows Update で Win

最近やってよかったことの1つが、Wi-Fiを入れ替えたことでした。 何がどう変わったのか残しておきます。 TL;DR Wi-Fi をどれぐらい使っているのか 動機 選定基準 候補の絞り込み Amplifi HDを設置する REF TL;DR Amplifi HD、日本ではまだ出荷可能になったばかりですがいい感じでおもしろいし安定はしてる 外出先からアプリで設定変更したり通信テストできるのは人権 ミニスクリーンに現在の通信状況が可視化されるのは本当にいい、最高 タッチでWPSを有効にできたりするけど、WPS今どき機器がなくていらない感 Wi-Fi をどれぐらい使っているのか 私の環境は100％ Wi-Fiです。 唯一LANを使っているのは、Hue HubとYamaha RTX810 - Wi-Fi APの間のみです。ただ、これも同一ボックス内LANで結んでいるので目に見えません。 私が有線を

GitHub Actions以前調べたのですが、いろいろあって個人プロジェクトでサクッとビルドするのみに使っていました。 今回改めて調べを進めたのでメモ。 幾つかのリポジトリをGitHub Actionsに移行したけど、記事にしようとまとめていたらやった内容以上に調べてめちゃめちゃ時間かかった。 TL;DR トレンド GitHub Actions の基本 使用条件 使用制限 料金 ホストランナーの指定 ハードウェアリソース インストールされるツール IP OSの選択 実行権限 ファイルパス 環境変数 シークレット GITHUB_TOKEN コンテキスト Artifact トリガーイベント Cache Actions 通知 YAML Getting started YAMLシンタックス on env jobs.<job_id>.needs jobs.<job_id>.runs-on jobs

Redisを扱うにあたって、GUIでRedisの状態が把握できるツールは便利です。 最近はRDBToolsを使っていたのですが、2か月ぶりにサイトをみると2019/12/31でEOLとのアナウンスとRedisInsightのGAリリースが出ていました。 このRedisInsightが、無料で使えるRedis GUIの中で完成度が高く、Redis Labs本家が開発しているのでオススメできそうです。 TL;DR その他のGUIツール ダウンロード/インストール インストール時の注意 Docker ローカルインストール 起動 接続 できること できないこと まとめ TL;DR RedisのGUIツールとして、以前RDBToolsを紹介したのですが31st December 2019でEOLを迎える 後継ツールとしてRedisInsight がRedisLabs からGAリリースされている 安定

この記事は、PowerShell Advent Calendar 2019の一日目です。 qiita.com Windowsのパッケージマネージャーの裏はPowerShellが多く使われています。 そんなWindowsにおけるパッケージマネージャーと言えば、Package Management Chocolateyが有名なのではないでしょうか? 私もChocolateyをパッケージマネージャーに用いて開発環境の構築をしてきましたが、課題が多かったためScoopに切り替えました。 Chocolateyで何が問題だったのか、なぜscoopを選んだのか、この一年scoopをどのように環境構築に利用しているのかを紹介します。 TL;DR Chocolatey の利用 どのように Chocolatey を利用していたのか Chocolatey で困ること Chocolatey が抱える問題点 Sco

何度か挙げているAzure DevOps Pipelineですが、ずっとYAMLで紹介してきました。実際に私はAzure DevOpsにYAMLがPreviewで来てからずっとYAMLにしています。 これはほかのCIサービスも複数触っていたことからもYAMLでかけることに大きなメリットを見出していたからですが、改めてAzure DevOpsでPipelineをYAMLで定義するのをなぜススメるのか一部を書いておきます。 TL;DR YAML 定義のメリット YAMLでパイプラインを組みたいときの流れ YAML で困ること Multi Stage Pipeline と失敗ジョブの再開 Reference variable などの未サポート機能 リリースとYAML定義 Display Name のうざさ キャッシュ機能 おわりに TL;DR ビルドは、そのプロジェクトを透明に維持するための大き

.NET Core 3.0 では、単一バイナリ(Single-file executables)が生成可能になりました。 github.com 今回はどのようにSingle Executable生成するのか、普段は .NET Core 2.1 でビルドしたいときの分け方、dotnet global tool とビルドを分けること、GitHubリリースへのCIからの配置を見てみます。 目次 目次 TL;DR リポジトリ .NET Coreアプリケーションを利用するときの従来の展開方法 FDD FDE SCD 課題 Single-file executables が解決すること Single-file executables の展開方法 FDE SCD Single-file executables を生成する 普段は .NET Core2.1 は開発して配布時にのみビルドする dotnet

時々思い出したようにPowerShellの記事を書いてみます。 スクリプトでよくあるのが、sudoで実行時に権限があるスクリプトの許可をしたいというケースです。 Windowsは組み込みsudoがないので面倒でしたが、現状ならscoopでsudoをインストールするといいです。 https://scoop.sh/ scoop install sudo これでsudo ./your_script.ps1とできるので特権が必要なときに、必要な権限を渡すことができます。 さて今回の記事は、Windowsにおいて実行中のスクリプトや関数にて特権が必要な場合に、sudoを使わずにUACダイアログを出して昇格したPowerShellで同関数を実行し直してほしいというケースです。 通常の特権昇格フロー + Windows Diffender操作のため利用には注意してください。 この2つを自動化できるのは運

開発中、リリースのいずれにおいても「今どのバージョンなのか」という情報は重要な情報です。 とはいえ、実際に埋め込みたいのはバージョンというより「ソースコード」とくに「コミット」と連動する情報、加えて「ビルド」と紐づく情報もほしいでしょう。 どのようにすれば実現できるか、これを.NET Coreをベースに考えてみましょう。 真新しいことはなく、よく昔からあるやつを今ならどうやるかというメモです。 前回の知識があれば簡単です。 概要 GitHub なぜSCM情報を埋め込みたいのか .NET Framework におけるSCM情報の埋め込み方法 .NET Core でSCM情報をどこに仕込むと楽なのか GitVersioningを使ったGit情報埋め込み NuGet パッケージを使ってビルド時に自動的にバージョンを埋め込む nbgv CLI を使ってバージョンを埋め込む GitInfoを使ったG

以前VS2017で使っている拡張機能について書きました。 https://tech.guitarrapc.com/entry/2017/07/25/034154 VS2019もRCとなり、いよいよリリースが近づいてきたにつれ、各種拡張機能もサポート対応が進んでいます。 一部はまだ対応されていないものの、今のところいい感じで使えつつあるので一度まとめてみます。 余談ですが、VS2019では初期読み込みに時間がかかり、VS起動時間に影響のある拡張機能は拡張機能側の実装にバックグラウンドで読み込むことを推奨しています。もし新規に拡張機能を作る場合は検討されるといいでしょう。 左上にSolution名でないのが慣れないのですが、右上のQuick Search横にSolution名出ているので慣れましょう。 右下にはGitリポジトリが出てますが、Slnとずれていることもあります。 Extension

先日、外部のgitリポジトリを参照しつつ開発を進めたい時に、改めて今ならどのようにやるといいのか調査と検証を行いました。 開発においてシンプルさは重要です。そのため、利用している言語やフレームワークで標準提供されたパッケージシステムを使うのは優先的に検討するべきです。 しかし会社などでprivate repoでコード参照をしたいときには、参照する外部リポジトリも適切にgit管理したいものです。 gitは、自分のリポジトリを扱うことに関してとても便利な機能がそろっています。 一方で、自分のリポジトリの外、外部リポジトリを連携させることについては、自リポジトリほど楽に取り扱えるわけではありません。 そこで今回は、gitが提供している外部リポジトリのハンドリングとして、submodule と subtree の2つを通して外部リポジトリをどのように扱うのか考えてみます。 これまでは外部リポジトリ

以前 TryRoslyn と言われてたサービスですが、今は Sharplab という名になっています。 このサービスを使うと、コードがILやネイティブコードにどのようにコンパイルされるか確認したり、実行したりオブジェクトのメモリ状態を確認できます。 例えば次の図は、構造体の文字列がどのようなメモリ状態なのかを示したものです。 Sharplab を使って、コードだけでなくメモリ状態を可視化することで理解を深めるきっかけにできるか見てみましょう。 目次 目次 TL;DR; Sharplabの基本 いつ使うのか コードの共有 言語選択 表示の切り替え(Decompile) 言語ごとのデコンパイル結果の比較 Other Run C# のメモリ状態を確認する Boxing を可視化する 構造体における文字列の参照状態を確認する クラスにおける参照状態を確認する TL;DR; Shaplab を使って