はてなブックマーク

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 の構成について書いてなかったので記録として残しておきます。 blog.serverworks.co.jp TL;DR; HashiCorp社の Terraform ベストプラクティス Nebulaworks の例 なぜ Terraform の構成は難しいのか よく使っている構成 原則 terraform ファイルの記載内容 この構成で最も設計しないといけないこと 元記事の迷子 workspac

私はローカル環境の 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 に対応していないので、ちょっと小細工が必要だったのは学びでした。 私が欲しい内容の記事がなかったので自分で書くしかないのです。 tl;dr; 前説 記事の対象となる人 記事の対象ではない人 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 に

今年はいろいろなアレコレでずいぶんと働く環境に影響がでました。 今回は週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 で構築しているということを書きました。 tech.guitarrapc.com その際に、scoopを継続的に使っていくためのツール ScoopPlaybook を書いたことに触れました。 今回はその ScoopPlaybook の紹介です。 目次 目次 TL;DR 目指す姿 WindowsでAnsiblePlaybook のようなアプリケーションインストール基盤を作る scoop の通常のインストール ScoopPlaybook で定義からインストールする 利用例 普段の利用例 できること バケットの追加、削除 ツールのインストール、アンインストール 管理者権限で実行したい まとめ TL;DR ScoopPlaybook という PowerShellモジュールを作った(2年近く使っている) scoop で何をインストールするかをYAML定義

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/p

開発環境では 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 で有効にする

最近やってよかったことの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

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 を迎えます 後継ツールとして RedisInsi

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

何度か挙げている 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.sh scoop install sudo これで sudo ./your_script.ps1 とできるので特権が必要なときに、必要な権限を渡すことができます。 さて今回の記事は、Windows において実行中のスクリプトや関数が特権が必要な場合に、sudo を使わずにUACダイアログを出して昇格したPowerShellで同関数を実行し直してほしいというケースです。 通常の特権昇格フロー + Windows Diffender操作のため利用には注意

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

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

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

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

.NET Framework で Windows Service を作るときは、Windows Service のために地道に実装するのは大変.... なので、TopShelf を使うことが定番でした。以前 Nancy を Windows Service でホストする記事を書いたこともあります。 tech.guitarrapc.com では、.NET Core ではどうでしょうか? TopShelf は .NET Standard 2.0 に対応しているので利用できます。 github.com しかしGeneric Host は Windows Service も想定されており、かなり簡単に作成できるので見てみましょう。 前回の記事から関連させて、Windows Service + Web Jobs でホスティングすることを目標としてみます。 目次 目次 TL;DR; 事前に読んでおきたい

ASP.NET Core 2.1 で追加された Generic Host (汎用ホスト) は、non-Web App アプリの作成をASP.NET Core と似た書き心地で提供します。 今後のスタンダードとなる見込みですが、どのようにして Generic Hostを利用するのか見てみましょう。 ※ 社内向けブログの転載なのでシリーズ化します。 目次 目次 TL;DR; Generic Host とは WebHost (ASP.NET Core) との違い Generic Host を使う目的 Configure 処理の追加 書き心地 サービス処理をDIする まとめ Tips IHostBuilder.RunConsoleAsync, IHostBuilder.Start, Host.StartAsync, IHost.RunAsync の違い ASP.NET Core 3.0ではGene

今のパスワード管理に小さな不満があるので長年次のパスワード管理をさがしていたのですが、Bitwardenが今ある全ての望みをかなえてくれました。 bitwarden.com 今回、TeamsId から Bitwarden に全面移行したのでその移行についてメモをしておきます。 目次 目次 今まで使ってきたパスワード管理 TeamsId を見返す 検討したサービス Bitwarden Bitwardenの使い方 TeamsIdからの移行 下準備 実装 TeamsId Csv の解析 TeamsId のフィールド解析、値取得 変換時の注意 インポート まとめ 今まで使ってきたパスワード管理 個人のパスワード管理は、2015年3月まではMeldiumを使ってましたが Discontinueが発表されてからはTeamsId を使っていました。 www.teamsid.com TeamsId を見返