tech.guitarrapc.cóm

Technical updates

.NET アップグレード アシスタントでCentral Package Managementに移行する

C#(.NET)プロジェクトでNuGetパッケージを管理する方法はいくつかありますが、Visual Studio 2022 17.2以降 (NuGet 6.2以降)で導入されたCentral Package Managementはプロジェクトのパッケージ管理を簡単にする新しい方法です。これを使うと複数のcsprojファイルを持つソリューションで、パッケージとバージョンを一元管理できるため、今後の標準になっていくと予想されます。

.csprojのNuGetパッケージ定義からCentral Package Managementへの移行はこれまで手作業でしたが、Visual Studio 2022と.NET Upgrade Assistant拡張を使うと簡単に移行できるようになったので紹介します。

.NET Upgrade Assistantとは

.NET Upgrade Assistant | Marketplace VisualStudioは、.NETアプリケーションを最新の.NETバージョンにアップグレードするためのツールです。.NET Frameworkから.NET 6+(.NET 9.0含む)へアップグレードや、.NET Coreから.NET 6+(.NET 9.0含む)へのアップグレードもできます。1

先日0.5.793.65096がリリースされCentral Package Managemen移行もサポートされました。うれしいですね。

.NET Upgrade Assistant Now Supports Upgrading to Centralized Package Mangement | .NET Blog

.NET Upgrade Assistantをインストールする

.NET Upgrade AssistantはVisual Studio 2022 17.1以降で利用できます。Visual Studioのメニューバー > Manage Extensions > .NET Upgrade Assistantを検索してインストールします。

image

細かい手順は以下のリンクを参照してください。

.NET アップグレード アシスタントをインストールする

Central Package Managementに移行するとどうなる?

サンプルに次のようなプロジェクトを用意します。

CPMSample
│  CPMSample.sln
│
├─ConsoleApp
│      ConsoleApp.csproj
│      Program.cs
│
└─TestProject1
        TestProject1.csproj
        UnitTest1.cs

Central Package Management移行前

NuGetパッケージはそれぞれのcsprojファイルで参照されています。

  • ConsoleApp.csproj
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
      <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="ConsoleAppFramework" Version="5.3.3">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
    <PackageReference Include="ProcessX" Version="1.5.5" />
  </ItemGroup>

</Project>
  • TestProject1.csproj
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <IsPackable>false</IsPackable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="coverlet.collector" Version="6.0.2" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.11.1" />
    <PackageReference Include="xunit" Version="2.9.2" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.8.2" />
  </ItemGroup>

  <ItemGroup>
    <Using Include="Xunit" />
  </ItemGroup>

</Project>

Central Package Management移行後

このプロジェクトをCentral Package Managementに移行すると次のような構成になります。Directory.Packages.propsファイルが追加されています。Central Package Managementはプロジェクトのルートディレクトリに配置されたDirectory.Packages.propsファイルでパッケージとバージョンを一元管理します。2 移行後にcsprojファイルをみると、csprojで指定していたパッケージのバージョン指定がなくなっています。

CPMSample
│  CPMSample.sln
│  Directory.Packages.props
│
├─ConsoleApp
│      ConsoleApp.csproj
│      Program.cs
│
└─TestProject1
        TestProject1.csproj
        UnitTest1.cs
  • Directory.Packages.props
<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
    <CentralPackageTransitivePinningEnabled>true</CentralPackageTransitivePinningEnabled>
    <!-- TransitivePinningを無効にするとfalse -->
    <!-- <CentralPackageTransitivePinningEnabled>false</CentralPackageTransitivePinningEnabled> -->
    <NoWarn>$(NoWarn);NU1507</NoWarn>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="ConsoleAppFramework" Version="5.3.3" />
    <PackageVersion Include="coverlet.collector" Version="6.0.2" />
    <PackageVersion Include="Microsoft.NET.Test.Sdk" Version="17.11.1" />
    <PackageVersion Include="ProcessX" Version="1.5.5" />
    <PackageVersion Include="xunit" Version="2.9.2" />
    <PackageVersion Include="xunit.runner.visualstudio" Version="2.8.2" />
  </ItemGroup>
</Project>
  • ConsoleApp.csproj
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="ConsoleAppFramework">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
    <PackageReference Include="ProcessX" />
  </ItemGroup>
</Project>
  • TestProject1.csproj
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <IsPackable>false</IsPackable>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="coverlet.collector" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" />
    <PackageReference Include="xunit" />
    <PackageReference Include="xunit.runner.visualstudio" />
  </ItemGroup>
  <ItemGroup>
    <Using Include="Xunit" />
  </ItemGroup>
</Project>

Central Package Managementのメリットと注意点

すべてのcsprojで使っているNuGetパッケージとバージョンがDirectory.Packages.propsに記載されているので、パッケージを簡単に確認できるようになりました。

Directory.Packages.propsファイルのManagePackageVersionsCentrallyPackageVersionに注目してください。ManagePackageVersionsCentrallyはCentral Package Managementを有効にするためのプロパティです。.csprojに直接定義するとそのcsprojだけをCentral Package Managementに移行できますが、アップグレードアシスタントを使うと、Directory.Packages.propsに記載されて複数のcsprojを一括でCentral Package Managementに移行できます。PackageVersionはManagePackageVersionsCentrallyで指定したパッケージのバージョンを一元管理するためのプロパティです。3

Central Package Management移行後、csprojでパッケージのバージョンをVerisonで指定するとエラーになります。csprojでバージョンを指定するには<PackageReference Include="PackageA" VersionOverride="3.0.0" />のようにVersionOverrideを使います。csprojに例外を作るとパッケージバージョン管理が難しくなるので個別指定はおすすめしませんが、例外的にバージョンを固定したい場合に使えます。

.NET Upgrade AssistantでCentral Package Managementに移行する

.NET Upgrade AssistantでCentral Package Managementに移行する手順は次の通りです。

1. Visual Studioでソリューションファイルを開く

Visual Studioでソリューションファイルを開きます。.csprojじゃないので注意してください。

2. 適当なcsprojを右クリック > Upgradeを選択

image

3. メニューからNuGet central package management (CPM)を選択する

Upgrade AssistantのメニューにNuGet upgradesがあります。これを選択します。

image

※ 注意: ソリューションを右クリック > Upgradeを選択しても、Central Package Managementに移行メニューが出ないので注意してください。↓はSolution > Upgradeを選択したときの画面ですが、NuGet upgradesが存在しません。

slnのUpgradeではCentralPackageManagementに移行できない

4. Central Package Managementに移行するプロジェクトを選択する

Central Package Managementに移行するプロジェクトを選択します。可能なら全プロジェクトを選択すると一元管理できていいですね。

image

5. プロジェクトのカスタマイズ

Central Package Managementに移行するプロジェクトを選択すると、プロジェクトのカスタマイズ画面が表示されます。ここでDirectory.Packages.propsの場所を指定します。デフォルトではソリューションファイルと同じディレクトリに配置されます。

また、Enable transitive pinningTransitive Pinningを有効にするか選べます。Transitive Pinningは、推移的なパッケージ(依存しているパッケージが依存しているパッケージ)のバージョンを固定する機能です。Transitive Pinningを有効にすると、推移的な依存関係が暗黙的にトップレベルの依存関係に固定されます。4.NETチームはTransitive Pinning有効を推奨にしています。

Transitive Pinningを有効にすると、NuGetパッケージが参照しているライブラリも更新されるため動作担保できない可能性があります。が、推移的パッケージのバージョンもコントロールされているほうがセキュリティ管理しやすいので、有効にできるといいですね。

image

6. 移行実行

正常に移行できると、次のようにチェックマークがつきます。また、Directory.Packages.propsファイルが作成されます。

image

Dockerビルドとの相性

Dockerビルド時にdotnet buildしている場合、Directory.Packages.propsがないとエラーになります。場合によっては、Dockerビルド開始前にDirectory.Packages.propsをコピーする処理を追加する必要があります。

C#の.csprojごとにDockerビルドすると、Dockerfileにプロジェクトが参照しているcsprojを引っ張る処理が書かれます。ただDirectory.Packages.propsは追加されず、またDockerコンテキストパスよりも上位に配置されていることもあり相性が悪いです。

C#プロジェクト全般に言えるのですが、Dockerビルドするならsln以下のディレクトリ構成ごとDockerコンテキストに持ってきて、まとめてビルドするとシンプルで管理しやすくなります。あるいはホストマシンでdllビルドしてDockerコンテナにコピーする方法もあります。

× これは面倒
1. csprojごとにDockerコンテキストへコピー
2. Directory.Packages.propsをコピー
3. dotnet restore & dotnet build

〇 これが簡単でおすすめ
1. slnの構造ごとDockerコンテキストへコピー
2. dotnet restore & dotnet build

まとめ

これまで手作業でCentral Package Managementに移行していたので、.NET Upgrade Assistantで簡単に移行できるのはとても便利です。これでDirectory.Package.propsを作って、csprojを1つ1つ確認していく手間が省けます。

運用を考えるとOSSライブラリの管理は重要です。Central Package Managementを使ってパッケージのバージョンを一元管理することで、ライセンス情報を一元管理できるので、セキュリティやライセンス管理にも役立ちます。ぜひ快適なNuGetパッケージ管理を試してみてください。


  1. csprojのTargetFrameworkTargetFrameworksを書き換えるだけで済む場合は不要ですが、csprojを触らないという人もいもいますし、SDKスタイルにcsprojを書き直す必要がある場合もあります
  2. .slnと同じパスでなくてもよいですが、.slnファイルと同じディレクトリに配置することが多いです
  3. csprojは引き続きPackageReference Includeです
  4. NPMのpackage-lock.jsonファイルのように依存関係のNuGetバージョンも固定する機能です

GitHubとはてなブログを連動させる

このブログはGitHubで書いています。流れとしては、下書きをGitHub Actionsで生成し、下書き更新ではてなブログのプレビューを更新、PRマージではてなブログへ投稿されます。

今回はGitHubと連動したはてなブログ投稿の仕組みを書きます。

おすすめ

2023/09/21、はてなブログ公式から次の記事とGitHubテンプレートが公開されました。

組織でのはてなブログ運営をGitHub上で行うためのテンプレートリポジトリ「HatenaBlog Workflows Boilerplate」を公開しました | はてなブログ開発ブログ

GitHubテンプレートは組織向けに整備されていますが、やりたいことは個人でも大きく変わりません。そこで2022年から組んでいたGitHubとはてなブログ連動の悩みも踏まえ、2025年からこのテンプレートを下地にして運用しています。

なぜGitHubとはてなブログを連動させるのか

そもそもはてなブログは記事管理ができるのになぜGitHubで記事を書くのかという疑問ではないでしょうか。はてなブログは記事管理ができるので、記事を書く場所としては十分です。

記事の公開先と保持を分けたい

私がGitHubと連動させようと思ったきっかけはZennとGitHub Pagesです。これらはGitHubで記事を保持して、公開する場を自分で選択していくことができます。

それに対して自分は記事自体をはてなブログに保持してしまっているため、記事の公開先を将来変えたくなった時に困ります。もともとWordPressからはてなブログに引っ越してきたこともあり、記事の公開先を将来変えたくなる動機があります。ブログを引越す時、記事をGitHubで管理していると記事の移行がとても楽です。はてなブログの記事ははてなブログの管理画面からエクスポートできますが、初めからGitHubで管理すれば記事の移行はデプロイ変更にフォーカスできます。

記事の履歴を取りたい

また、GitHubで管理していると記事のバックアップや履歴も取れるので安心です。

はてなブログとGitHubの連動方法の変遷

はてなブログとGitHubの連動方法は2種類試してきました。

push-to-hatenablogをテンプレートに採用(2022年~)

はてなブログで直接書いていた記事をGitHubから連動するように変えたのは次の記事がきっかけでした。

push-to-hatenablogを使ってはてなブログ記事をGit管理してみた

ほかにも方法があるかと2022年当時探したのですが、blogsyncを使った方法しかなかったので整備されている方法に乗りました。

記事を更新する

この記事更新方法は次のフローです。

# 下書きの作成

1. GitHubでIssueを作成 > `記事の追加用テンプレート`を選択し、記事本文の`path: `に`yyyy/MM/dd/適当なID`を指定してIssueを作成します
2. IssueをcloseするとActionsで`_draft`パス以下に下書き記事が作成されます

# 下書き記事の編集

- 作成された下書きをVS Codeで編集する。
- プルリクエストを作成するとをtextlintで校正されます
- プルリクエストをマージすると下書きがはてなブログに同期されます
- はてなブログの下書きを見て、記事を調整するか決めます

# 下書き記事の公開

- 記事を公開する前に`_draft/`から`entry/`ディレクトリに移動します
- 下書き記事の`Draft: true`行を削除し、プルリクエストを作成。mainブランチにマージすると記事がはてなブログで公開されます

# 既存記事を修正する場合

- 修正ブランチを作成し、mainブランチにマージすると修正がはてなブログに反映されます

はてなブログで直接書いていた時は校正がなかったので、公開してからちょくちょく修正することを繰り返していました。GitHubで記事を書くにあたりtextlintを導入して、PR時にGitHub Actionsで校正し始めました。

問題点

GitHubをいつも使っているので、やり方も大したことないしモチベーション変わらず書けるだろうと考えていたのですが甘かったです。いざやってみると記事を書きたくなくなっていたのですが、振り返ると原因はめんどくささが爆発していました。

  • 記事を書くときにIssue作ることを思い出せない
  • Issueのpath:に何を入力すればいいか思い出せない。READMEに書いても直感的じゃない
  • Issueのpath:のIDをどうやって決めるかわからない。適当はむしろわからなくなる
  • 下書きをはてなブログに反映させるのにいちいちPRを作ってマージするのが面倒
  • 公開時に_draftから_entryに移動するのがめんどうで、先に移動するとdraftが混じってどこに行ったか探す羽目になる

どれも大したことないことなのですが、これが積み重なって記事を書くのがストレスになっていました。 一度やる気をなくすと2,3カ月放置し、久々に記事を書こうとするとまたやり方を忘れていて、下書きまで作ったところでやる気をなくすという悪循環に陥りました。

問題点はわかっていましたが忙しさを言い訳に放置していました。

HatenaBlog Workflows Boilerplateをテンプレートに採用(2025年~)

2024年中にはてなブログ公式ブログを見かけていたのですが、いったん放置していました。2025年に毎日記事書く気力がわいたので、ようやく手を付けました。 幸いにもGitHubからの同期方法はblogsyncから変わっていなかったので、設定調整はほぼありませんでした。

この記事更新方法は次のフローです。

# 下書きの作成

1. Actionsから  `create draft`を選択し、`Title`に記事タイトルを設定、`Branch: main`に対して実行します
2. 作成した下書きを含むプルリクエストが作成されます

# 下書き記事の編集

- 手順「下書きの作成」にて作成したプルリクエスト上で記事を編集します
- はてなブログでプレビューできるようにするため、下書き記事に限りプッシュされた時点ではてなブログに同期されます
- 記事の編集画面のURLは、プルリクエストに記載されています

# 下書き記事の公開

- 下書き記事の`Draft: true`行を削除し、プルリクエストをmainブランチにマージすると記事がはてなブログで公開されます
- 記事を公開すると、下書き記事は下書き記事用ディレクトリ`draft_entries`から公開記事用`entries`ディレクトリに移管されます

# 既存記事を修正する場合

- 修正ブランチを作成し、mainブランチにマージすると修正がはてなブログに反映されます

このフローは、以前めんどく感じていた諸々を解消しています。

  • 記事を書くときにGitHub Actionsから適当なタイトルをつけるだけなので単純

image

  • 下書きPRを更新するとはてなブログに下書き同期されて、プレビューURLもPRに記載されるので公開まで調整が楽

image

  • 下書きPRをマージするとdraft_entriesから公開記事用entriesディレクトリに移動するPRを自動作成される

image

textlintを使った記事校正の調整

はてなブログの更新テンプレート修正に合わせてtextlintの使い方を調整しました。

textlintを2019年まで適用する

過去の記事が多すぎてtextlintする気がなくなり、過去の記事を修正するまで新しく書きたくないという悪循環ループになっていました。そこで2019年までの記事についてtextlintの校正を終えました。1

幸い2018年以前の記事を参照する機会は少ないので、これで「textlintしないといけない」という強迫観念がなくなりました。

textlintをサクッと使う

これまでtsuyoshicho/action-textlint@v3を使ってPRにtextlintのコメントもつけていましたが、PRのコメントが爆発したときにやる気をなくします。

      - name: textlint-github-check
        uses: tsuyoshicho/action-textlint@v3
        with:
          github_token: ${{ secrets.github_token }}
          reporter: github-check
          textlint_flags: "./entries/guitarrapc-tech.hatenablog.com/entry/${{ matrix.year }}/**/*.md"
      - name: textlint-github-pr-review
        uses: tsuyoshicho/action-textlint@v3
        with:
          github_token: ${{ secrets.github_token }}
          reporter: github-pr-review
          textlint_flags: "./entries/guitarrapc-tech.hatenablog.com/entry/${{ matrix.year }}/**/*.md"

VSCodeで自動的にtextlintがかかるようにしてtextlintのエラーを書いていて即修正できるようにしました。また、PRではtextlintが落ちたかどうかだけ判断するようにしました。2

      - name: textlint
        run: |
          for year in 2019 2020 2021 2022 2023 2024 2025; do
            echo "::group::textlint for ${year}"
            npm run "lint${year}"
            echo "::endgroup::"
          done

PRで駆動するめんどくささがあるので、GitHubのAuto Mergeを併用しています。記事自体の推敲が終わったが些細な文言調整だけすることがあります。こんな時はtextlintが通ったら3自動マージして公開します。

image

image

GitHubで書くメリット

はてなブログで記事を書いているとやりにくく、GitHubで記事を書くとやりやすいことがあります。

複数記事をまとめて調整する

はてなブログで記事管理していると一個一個の記事を開いては調整、更新する必要があります。GitHubで記事を書くと複数記事を修正したPRを立ててマージするだけで一気に記事を修正できます。

記事の数が増えれば増えるほど効果的です。例えば、いろんな記事フォーマットを試したくなって過去記事も修正したくなったときでも最小限の手間で修正できます。

記事を戻す

はてなブログには履歴がありません。このため記事を戻してくても戻すことは難しいです。GitHubで管理していると、過去記事が履歴に残っているため戻すのが簡単です。

CIを挟める

文書、難しくないですか。私は文書を書くのが得意じゃないので、CIを挟んで文書の校正を自動化しています。ローカルのVSCodeでも校正できるのでCIは念のため、ですが効果的です。

はてなブログ機能をやめる動機

はてなブログは画像をドラッグ&ドロップでアップロードできます。カードプレビューも特殊記法で簡単にできます。はてなブログの機能は便利ですが、はてなブログで公開しない将来を考えるとはてなブログ機能は減らしたいものです。

GitHubで記事を書く場合VSCodeプレビューで見た目99%を決めるので、はてなブログの機能は使わない矯正ギプスになっています。

GitHubで書くデメリット

GitHubで記事を書くデメリットもあります。

気分で記事を書くにはめんどくさい

以前よりは楽になりましたが、記事を書く気分になって記事を書き始めるまで1m程度かかるハードルは高いです。はてなブログで書いているときは、管理画面から記事を書き始めるまでワンクリックなので大きな違いです。

画像

画像がめんどくさいです。今は割り切ってGitHub Issueに画像をあげてリンクを張っていますがよくないです。GitHub上に画像を置くのもめんどくさいのでどうしたものか。画像を配置すること自体がめんどくさい。

まとめ

はてなブログ公式から、GitHubとはてなブログの連携方法が公開されたのは本当に良いタイミングでした。そして、自分のやる気はめんどくさいに左右されるのも改めて実感しました。めんどくさい駆動ブログです。


  1. 2018年以前はいったん見ないふりです
  2. PRコメント多すぎになるのはよくない
  3. PR Status Checkにtextlintを指定している

2024年を振り返って

2023年の振り返りはさぼりましたが、2024年を振り返ります。前回の記事はこちら

2022年を振り返って

総合

2024年は、お手伝いしていた成果が世の中に出た年でした。喜ぶ人が観測できてよかったです。2025年も新しいことへのチャレンジに取り組んでいます。2025年は自社のために時間を捻出できそうなので形にしていきたいです。

インフラ的なお仕事は「サービス全般を一人で見るのは難しい」です。だからこそチームを作ってサービスを支えることが必要です。幸いにして、2022年から見ていたチームが素晴らしく、サービスを支えられています。チームに尊敬と感謝を改めて表明します。振り返るとIaC 100%、CI/CDを通したワークフロー整備がチーム育成の土台になりました。IaCはプロジェクトの地力を高めるを証明になったので、今後もよりよくなっていくように頑張ります。

2024年になってもわからないことが多く、何もわかっていないことを痛感します。ただ、ChatGPTをはじめとする生成AIを利用することで、これまで独力で試行錯誤していることに、壁打ちという武器を得ることができて開発イテレーションが早くなりました。生成AIを使うとこれまでの限界を超えることができるので、2025年もAIに置いて行かれないように学び続けたいです。

経営

2024年は外部への協力に注力しました。これは2025年から自社のサービスを立ち上げるための準備として当初から計画していたことです。無事に準備が整ったので、2025年は作りたかったものを自社で作っていく予定です。

プログラミング

今年はC#メイン、HCL、Bashへ注力しました。

C#

C# 13が出て、手元のコードの多くを.NET9に書き換えをしました。.NET8のCollection Expressionほどのインパクトがある変更はすくないですが、Spanを最優先でAPIをそろえていける手ごたえがあっていいですね。

What's new in C# 13 | Microsoft Learn

C#でずっとやりたいなぁと思っていたことに2024年は取り組んで形になりました。いずれどこかで発表したいものです。2025年も長年C#でやれなかった宿題があるので、引き続き取り組んでいきたいです。

C#言語機能そのものの改善もいいのですが、2024年はC#でZxを使っていける手ごたえを得られたのが大きかったです。ようやくCIにおけるスクリプトをBashからC#へ置き換え検討できそうです。つまり、ProcessXとConsoleAppFramework v5が欠かせない部品になりそうですね。

Bash & PowerShell

この5年あまりはBashを使い倒しました。Bashはいいものです。ただ人によって書き方がバラバラすぎるので、チーム向けにスタイルガイドguitarrapc/bash-styleguideも作成しました。Googleのスタイルガイドを参考にしつつ、Bashの特性を生かしたスタイルガイドにしたつもりです。Bashをどう書くと挙動を安定させつつ、チームでメンテできるかを考えるのは楽しいです。

PowerShellへ傾倒をした次のステップとしてBashにも同程度に傾倒する必要があると考えてこの数年やってきました。私がPowerShellで悩んでいたのは本ブログのPowerShell記事が減ったことでもわかる通りですが、Bashと向き合うことは今後PowerShellをどう使っていくか考えるにあたり欠かせないチャレンジとなりました。

改めてBashを考えてみましょう。BashはPowerShellとは違い、ネイティブコマンドと組み合わせたときに挙動を制御できるのが強みです。PowerShellはネイティブコマンドと組み合わせたときに挙動を制御できないのが弱みです。BashもPowerShell同様にコマンドを書き連ねたり2,3行書く分には申し分ないのですが、それ以上のスクリプトを書くのは強く避けるべきと痛感しました。Bashでスクリプトを書くこと自体はそれほど難しくないですが、「Bashの言語構文はスペース1つに左右される繊細さ」1と「コマンドの挙動を理解する必要がある」ためスクリプト言語として難しいと言わざるを得ません。Zxに注目しているのはこのためです。

さて、PowerShellの利用範囲を広げるためにはBashのように「ネイティブコマンドと組み合わせたときに挙動を制御できるようになる」必要があります。たったの数行であってもネイティブコマンドが出た瞬間にPowerShellは候補から外れ、将来ネイティブコマンドを使うことを考えて選択肢にいれないこともあります。PowerShellの利用範囲を広げられない大きな原因の1つなのは疑いようのない事実です。しかし2023年にリリースされたPowerShell 7.4で、PowerShellとネイティブコマンドの組み合わせ課題が解消されるPSNativeCommandErrorActionPreferencePSNativeCommandPreserveBytePipeが入りました。PowerShellがクロスプラットフォームに使えるシェル、スクリプト言語のスタートラインに立ったといえます。2025年は、この新機能を踏まえたPowerShellの利用方法について紹介していきたいです。

What's New in PowerShell 7.4

なお、Windowsのデフォルトは今後もしばらくWindows PowerShell 5.1のままでしょう。PowerShellが.NETをベースとする以上、LTSで3年程度の.NETと各OSのサポート期間バランスを取るのは難しいからです。

PowerShellのサポートライフサイクル

ちゃんとチームでメンテしていくなら、スクリプトをZxで書くことを最優先に検討したほうがいいと考えています。Goなどの任意のコマンドで書くことも同様に検討する派ですが、話がずれるのでそれはまた別の機会に。

HCL

Terraformは多くの機能が入り、おおむねほしい機能が揃いました。特にmoved/import/removedブロックは、コードからterraform stateを制御できるようになる点からワークフロー革命です。インフラのリファクタリングをPR+CIで完結できるようになったので、terraform stateを使っているのであれば早くTerraform 1.10にアップグレードしてやり方を変えましょう。terraform stateを実行するワークフローは事故の原因です。

Terraformの運用は悩ましいものがありますが、やはりモジュールに実装を押し込める手法が最も安全で運用しやすいと感じています。Terraformのモジュールはクラスと捉えることができ、モジュールは循環参照できません。このため、モジュールのvariables/outputsを適切に設計すると、コード間の依存関係を明確に制御できます。モジュールの外に関心が漏れることも防げます。Terraformのコード設計によって循環参照をなくせるのは、インフラを維持、改善するにあたり大きなメリットです。チームに対する設計方針の説明もしやすく、コードレビューのスコープも狭まり、コード品質の維持管理もしやすくなります。

Terraformは新サービスやプロバイダーの追加が早い一方、世の中のリリースはもっと早いので追いつけていないと感じます。IaCもそろそろ次のステージに行けるといいですね。個人的にはCrossplaneのようにKubernetesからクラウドをすべて管理するのは違うと感じますが、aws-controllers-k8sのようにKubernetesから一部クラウドリソースを管理するのはありですし使っています。2025年は次のIaCにも注目しています。

記事

2本、過去最少!今年は毎日更新したい謎の欲求があります。頑張りましょう。

原因は記事を書くスタイルを変えたはいいものの、記事を書くのがストレスだったからです。以前は記事を書くときははてなブログからさくっと書いてましたが、2023年末からGitHubで書いてはてなブログに同期する手法へ変えました。この時PRをマージすると公開されるようにしていなかったのと、textlintでの校正が苦痛で仕方なかったのがストレスの原因です。2024年末にHatenaBlog Workflows Boilerplateをベースとした記事スタイルに変更したのと、textlint校正の大半を完了したので、記事を書くのが楽になりました。今年は記事書きたい。

ライフスタイル

コロナが収束している気が一切しないので、マスク生活をやめていません。2024年についに罹患したのですが、発症前にラーメンを食べているときに隣の席のお客さんが咳をしていたので、その時罹患したと推測しています。幸いにして、手洗い・マスクをしている4年は体調を崩しにくくなったので、これからも衛生には気を付けて続けていきたいです。

2025年は?

PowerShellの新しい利用を紹介していきたいです。Terraformでいくつか実践的に投下したいものがあるので、それも試したいです。C#でもいくつか書きたいライブラリがあるので書いていきたいところです。

やりたいこといっぱいですね、頑張りましょう。


  1. ShellCheckでもBashの言語構文の異常はカバー仕切れないですしね

2024年に買ってよかったもの、使ってよかったもの

2024年に買ってよかったもの、使ってよかったものです。2023年はこちら

オープンイヤーイヤホン

image

FreeClip | HUAWEI

これまで骨伝導やFloat Runなど多くのオープンイヤーイヤホンを使っていましたが、2024年はHUAWEIのFreeClipを使っていました。FreeClipはオープンイヤーイヤホンの中でも隙なく満足度が高いため毎日使っています。

FreeClipが好きなポイントは次の通りです。

項目 評価 理由
付け心地 ★★★★★ つけていることを忘れるレベル、落ちない、左右入れ替えも自動適応
マイク ★★★★★ 周囲の音を拾わない、デュアルマイク+骨伝導VPUセンサー、マルチチャネルDNN通話ノイズリダクション強い。
イヤホン音質 ★★★☆☆ 可もなく不可もなく。ボリューム25%程度でちょうどいい
耐久性 ★★★★★ TPU素材で汚れがつきにくく、すべすべが続く
連続稼働 ★★☆☆☆ 音楽再生程度なら約8時間、通話メインだと約3時間
充電込みバッテリー ★★★★★ 最大36時間 & USB-C充電 & 10分充電で3時間音楽再生
そのほか 評価外 IP54、操作性は微妙、マルチポイント対応

唯一気になるのはバッテリーですが、サイズ的にしょうがないです。 外出先のオフィス環境で利用するので、付け心地とマイクが秀逸なのはとても助かります。オープンイヤーでで周囲の音への耐性が高いのは現実的にとても重要です。

好きなポイント

FreeClipがFloat Run、OpenComm、ATH-CC500BT、INZONE Budsに対して圧倒的に優れているのが「付け心地」と「マイク」です。

  • 付け心地比較: FreeClip > | つけていることを忘れる壁 | >>>>> Float Run >>>>> ATH-CC500BT > OpenComm
  • マイク巣比較: FreeClip > | 周囲の音を拾わない壁 | >>>>> Float Run >>>>> ATH-CC500BT >>> OpenComm

FreeClipは耳に引っ掛けるのですが、つけている感覚がほぼないのでうっかりつけたまま外に出てしまうことがあります。FloatRunは、うっかり外し忘れることがあってもつけていることはすぐ分かったのに対して、つけていることに気づけないのは特異な体験です。見た目も大きいピアス程度なので目立たないのもいいですね。FreeClip左右が同じ形状なので一見するとどっちがどっちだっけとなりそうですが、自動的に左右を判別して自動適応くれるのもいいです。LRを気にしない付け心地いいですよ。カナル型ができないのはともかく、オーバーヘッドは左右で同型なら同じことをしてほしいですね。

マイクの性能はこれまで使ってきた中でも凄まじいです。「しゃべっていないときはマイクが周囲の音を拾わない」ので、オフィスなど自分の周囲で人がしゃべっている環境でも通話に声が混じりません。ソフトウェアノイズキャンセルなしでこの性能は素晴らしいです。骨伝導・DNN通話ノイズリダクションを通話に用いるのすごすぎでは?これが今後のマイク性能の基準になってほしいです。

気になる人向けの感想を残しておきます。

  • イヤホンの音は感動するような良さ、ではないですが十分。というか付け心地が良すぎて、FloatRunやOpenCommに戻れなくなってしまったので、体感に革命を起こされてしまい、もう戻れない
  • オープンイヤーはマルチポイント対応ができていないことが多いのですが、FreeClipはマルチポイント対応しているので、スマホとPCを同時に接続して使うことができる

伸びしろ

課題はバッテリーです。通話しっぱなしで長時間やり取りができないです。

  • 音楽再生は実際のところ7時間前後で、通話だと3時間程度しか持たない
  • 通話で切れそうな時は、片耳ずつ充電してつなぐという逃げ方をしている

タッチ操作は微妙ですがタッチ操作しないので平気です。耳に引っかかる性質上マスクの着脱時にイヤホンが巻き込まれやすいのは仕方ないです。

基準が上がった

Float Run2出てほしいと思ってましたが、オープンイヤーはイヤーカフスが基準になったので選べなくなりました。ほかのイヤーカフスをいろいろ試してみたいものの、今のところFreeClipが一番好みです。

自宅ではINOZNE Budsを使っているのですが、これは独自無線接続(アダプタも必要)という事情で完全に家用です。外出先ではFreeClipを使っています。ゲームで使うなら、今もINZONE Budsがダントツにオススメです。

FreeClipを使ってからイヤホンに求める基準が上がってしまった、罪深いイヤホンです。

モニター

image

DELL U4025QW | DELL

ここ数年ずっとHDMI2.1対応、リフレッシュレート120Hz以上、モニタサイズ37-41インチ、湾曲、KVM搭載、5K、Thunderbolt対応、USB-PD対応、HDR10以上なモニターが欲しいと言い続けていました。2023年にHDMI2.1製品が出始め、2024年ついにほしいスペックのモニターがリリースされました。

ほしいスペックのモニターが出るまで長かったです。

たびたびおこなっていた検討記録

モニター条件に対する評価は次の通りです。

image

大きいモニターはコーディングや操作に有利

私はコーディング、ブラウザ、ターミナル操作、Unity Editorを同時に立ち上げるので、縦が確保できつつ横に長いモニターが必要です。このため、モニターサイズは37-41インチ、解像度が5K(横長)であることは重要です。

VSCode + VisualStudio + ブラウザ + Unity Editorをいい感じに配置できるというのは圧倒的に快適です。

視野を狭くする

これまでのモニターはAcer ET430を使っていました。これは43インチな4Kなのですが「縦に大きすぎる一方で横が足りない」という問題がありました。縦が確保できているのはいいのですが、高すぎは微妙だと考えています。4K以前はトリプルモニターもしていましたが、モニターが増えるのは見る場所が散らばってしまいます。

個人的には大きなモニターで真ん中に見たい内容を配置しつつ、周囲に補助情報を配置するのが好きです。5Kモニターは4Kで物足りない横を広げつつ、縦も確保できます。

湾曲もいい点です。43インチ4Kだと横が微妙に目に入れにくいのですが、湾曲255Rの5Kモニターは横が目に入りやすいです。湾曲は視野に収めるという意味から大きなモニターで重要な要素です。

リフレッシュレート120Hzは最低基準

ゲームをやっているとそろそろ120Hzが最低基準になってきました。これまでのモニターは60Hzなので、120Hzになるとゲームが快適になります。ただ、人間の認識的には144Hzまであればよさそうなので、HDMI2.2搭載のモニターが出たらそこでリフレッシュレートを高めたい欲はある程度落ち着きそうです。

リフレッシュレートは、グラボ、モニター、ゲームのすべてが対応している必要があります。この中で一番入れ替え頻度が低いのはモニターなので「モニターのリフレッシュレートが事実上使えるリフレッシュレートである」という認識が重要です。

120Hzは見分けつかないと思っている人がいたら、ぜひ120Hzのモニターを使ってみてください。120Hzは60Hzと比べて違いがわかりやすいです。日常になってしまうと、60Hzに戻ると違和感があります。

HDR10以上は必須

現在のゲームは多くがHDR標準対応しており、HDRの有無は明暗表現の差が大きいです。特にステージが暗いゲームにおいて、HDR10以上はゲームを楽しむ上で必須です。

HDRをWindows 11で使うにあたってブラウザやナイトライトで副作用があることには注意が必要です。HDRが有効だと、Chromeの白表現が強くなって枠やマウスを見失い状況が起こりやすくなります。また、ナイトライトの黄色が強くなるので、HDRを使っているときのナイトライトは厳しいものがあります。早く寝るのがベストです。

ディスプレイ切り替え

HDMI 2.1、DP、Thunderboltで切り替えができるので、最大3PCに対してモニター切り替えがスムーズに行えます。ディスプレイは手動切替以外にも、最後につないだPC出力が表示される自動切換えもできます。

macOSの画面を映す体験がよく、WindowsをつないでいるところにThunderbolt4をつなぐだけでディスプレイ切り替え+充電が行えます、神。

KVM

U4025QWのKVM機能は残念ながら2PCまでしか想定がありません。1 これを認識していなかったので、私にとってはKVMは期待外れでした。ただKVMとしてはちゃんと機能するのでいいモニターです。

私はWindows2台、macOS1台を使っているので、KVMを使うのではなくUSB切り替えを使っています。macOSの場合はThunderbolt4でつなげば、ディスプレイとUSB周りが一緒に使えるので、macOS+Windows1台なら大した問題はないです。

5K 39.7インチの解像度は十分

私はDPI 100%で利用しています。これまで4K 43インチでちょうどよかったのが、5K 39.7インチにすると文字サイズが小さくなって使いにくくならないか不安でしたが、実際に使ってみると十分でした。4K 37インチでも問題ないだろうとはおもっていたのですが、実物で文字サイズが問題ないと確認できたのはよい発見でした。

モニターアーム

エルゴトロン HXデスクモニターアーム | Amazonを使っています。HXはLXデスクマウントアームの上位モデルで、49インチ、9.1~19.1kgまで対応しています。LXデスクモニターアームは以前の43インチモニターの時にサイズ・重量的に耐えられなかったこともあり、HXを選んだのは将来含めてよい選択でした。

COFO無重力モニターアームPro | cofoが少し気になっていますが、エルゴトロンは10年保証に対して、Cofoは1年保証なのでちょっと微妙ですかね。

円安

モニターが発売されるころに円安が進み、U4025QWモニターの価格が変わらなかった結果、$1=133円程度の為替レートで購入できたので、ラッキーでした。DELLのモニターはたびたびセールがあるのですが、U4025QWはまだセールを見かけていないのでほしいときに買うぐらいがいいです。

気になるところ

Thunderboltポート(アップストリーム・ダウンストリームともに)が緩く、コネクタが抜けやすいです。Thunderboltケーブルを付属のものから別商品に変えても抜けやすいのでThunderboltコネクタが原因と判断しています。同モニターでコネクターが固いものも観測しているので、コネクターの緩いロットが混じっているようです。

CO2モニター

image

SwitchBot CO2センサー(温湿度計)

CO2センサーは数年前から導入したいなぁと思っていたのですが、どれもお高かったり、国内取り扱いなかったりでなかなか手が出せませんでした。SwitchBot CO2センサーは国内取り扱いがあり、価格も手頃で、すでにSwitchBot製品をいくつか使っていたので導入しました。

ほかに検討したCO2センサーは次の通りです。

データの可視化

温湿計を以前から使っています。数年のデータがあるわけですが、データがたまるというのはとても良いことで、後からスマホで見返すことができます。CO2センサーも同様にデータがたまるので、後から見返すことができます。これがSwitchBotを選ぶ最大の利点です。

もちろん取得したデータと連動したサーキュレーターONトリガーとかもできるのですが、一番重要なのはデータがたまることでここに満足しています。プッシュ通知が来るので、窓を開けるとかも判断できるのはいいですね。

感度

キャリブレーションしても400ppm程度から変わらなかったので一時は感度を疑いましたが、年末の様子から900ppmを超えていたりするので、感度は問題ないようです。オフィスだと3000ppmとかいくのを考えるとやけに低い気もするものの、自宅だとそんなものな気もします。これは他のモニターで対照試験したくなります。

注意点として、電池充電は30分更新になるので、更新頻度低い感じはあります。ただ、CO2センサーはあまり頻繁に変わらないので30分更新でも問題ないです。2

PS5コントローラー充電スタンド

image

CFI-ZDS1J

PS5を買ったもののコントローラーの置き場に困ってPS5コントローラー充電スタンドを買いました。PS5コントローラーは落とした時に壊れるんですよね…悲しすぎる。この製品はPS5のコントローラーを立てて充電するもので、充電ケーブルでつないだコントローラーが棚から落ちたりすることがなくなりました。

Switchコントローラーも同様の充電スタンドJoy-Con充電スタンド(2way)が発売されたのですが、1組しか充電できないので2組できるようにしてほしいものです。

収納棚

image

ポリプロピレン小物収納ボックス6段・ホワイトグレー

デスクの横に無印のキャリーシェルフを置いているのですが、その棚に収納棚を追加しました。デスク周りの小物を収納するのに便利です。無印の商品って、ほかの製品がちょうど入る寸法になっていていいですよね。ただ、無印の商品は販売期間が短く後継品ないことも多いので、商品がずっとある信頼は失われています。そういうところは残念です。

まとめ

今年は忙しさがやばくてガジェットをあまり試してないです。それでも面白いものが多くていいですね。


  1. モニターのKVMで3PC以上を想定しているものがそもそもない
  2. 息を吹きかけても二酸化炭素が増えず動作の正誤を判断できない

2024年に使ったサービス

2023年に使ったサービスは書いてませんでしたが、2025年になったのでやる気を出します。2022年の記事はこちら。

継続しているもの

基本方針は、すぐに辞められる月間契約を選択、やめない/月間がないものは年間契約。

月間契約

サービス名 価格 期間 継続? 用途
Apple Music 1,680円 2019年~ 継続 ストリーミング (1480円から値上がり)
AWS $0.37 2013年~ 継続 S3とか。Cloudflareにドメイン移管してRoute53コストを大きく減らした
Cloudflare $0 2024年~ 新規 ドメイン管理、DMARC管理
GitHub Pro $5.00 2013年~ 継続
Google Workspace 1360円/user 2013年~ 継続 Google Drive容量が足りずStarter(680円/user)からStandardにアップグレード
IIJ 990円/user 2021年~ 継続 ギガプラン5GB 音声SIM
Docomo->auに変えて回線安定&速度上がったんですがDocomo回線さん!?
Money Forward ME 480円 2018年~ 継続 家計簿、手放しで管理できるのがいいです
NERV Disaster Prevention 480円 2024年~ 新規 強震モニターや警報がよいです
OpenAI Plus $20 2024年~ 新規 壁打ち相手に最適
Plala 4843円 2004年~ 継続 ISP、光電話つき、HGWレンタル
YouTube Premium 1280円 2020年~ 継続 広告のあるYouTube に戻りたくないです。(1180円から値上がり)
X 980円 2023年~ 継続 もともとTwitterは応援したかったのでXになってPremiumに入っている。Xから得られるものがあるのでもう少し維持か?
ジャンププラス 980円 2016年~ 継続 新規の漫画面白い
マガジンポケット 1080円 2018年~ 継続 新規の漫画面白い(840円から値上がり)
レンティオ 2500~2800円 2023年~ 継続 ロボット掃除機をレンタルでいろいろ試してます。
ルンバはなるほどうるさい

年間契約

サービス名 価格 期間 継続? 用途
Amazon Prime 5900円 2014年~ 継続 ネットショッピング。ビック・ヨドバシメインですが今も時々使ってます。(4900円から値上がり)
Bitwarden Families Organization $40 2019年~ 無料->有料 無料でやっていましたが有料に切り替え。TOTP管理できるので最高
GitKraken $72.0 2016年~ 継続 Git GUI クライアント。macOS/Windows両方で利用。(2023年に$49になったが再び値上がり)
Nintendo Switch Online 408円 2024年~ アップグレード 一時的に追加パックに変更中。2025年は戻す予定
はてなブログ 8434円 2013年~ 継続 今使ってるマネージドなブログサービス

スポンサー

いつもお世話になっているライブラリの作者さんに対して支援しています。

サービス名 価格 期間 タイプ 用途
GitHub Sponsors $1.00 2022年~ Monthly @mayuki
GitHub Sponsors $110.00 n/a Onetime @neuecc
GitHub Sponsors $10.00 n/a Onetime @suzuki-shunsuke
GitHub Sponsors $8.00 n/a Onetime @azu

無料

サービス名 価格 期間 継続? 用途
Azure 0円 2015年~ 継続 ContainerApps / AzureFunctions / AppService / AKS メイン
Circle CI 0円 2015年~ 継続 Orb の開発、リリース
diagrams.net 0円 2013年~ 継続 Mermaid メインだしそろそろやめたいけど、構成図が厳しい。
Docker Hub 0円 2017年~ 継続 個人のイメージぽんぽんおいています。課金する気にはなれなく悩ましい
Eight 0円 2017年~ 継続
Fastly 0円 2015年~ 継続 検証に Developer Account
Fulcul 0円 2020年~ 継続 タクシーの状況見るときに
Google cloud 0円 2016年~ 継続 開発環境
Go 0円 2019年~ 継続 タクシーの状況見るときに
Google Analytics 0円 2013年~ 継続 ブログとか
IFTTT 0円 2016年~ 継続 連動系はこっち
Integromat 0円 2019年~ 継続 インスタントは処理はこっち。2023、2024年とほぼ使ってないので終了予定
Microsoft To Do 0円 2019年~ 継続 TODO はこれで安定しています。
netprint 0円 2019年~ 継続 コンビニ印刷便利
PayPay 0円 2019年~ 継続 2022年になって使う機会がすごく増えました。
2025年予定されている3rdパーティクレカが使えなくなったら終了予定
S.Ride 0円 2022年~ 新規 タクシーの状況見るときに
Slack 0円 2017年~ 継続 個人のあれこれ。3か月で消えるようになって草
Unity 0円 2018年~ 継続 開発環境。Plus廃止に伴い、Personalに切り替え。Pro 27500/monthは高すぎでは?
Zapier 0円 2016年~ 継続 連動系はこっち
一休 0円 2017年~ 継続 ホテル、レストラン予約

やめたもの

サービス名 価格 期間 用途
Audible 1500円 2023年~ 新しい本で聞きたいのがよくあるけど、なかなかこないので諦め
Google Adsense 0円 2017年~ 記事と紛らわしいインライン広告が多く、広告が制御不能な状況と判断し終了
Kibela 0円 2017年~ 2024年利用がなく終了
Luup 0円 2024年 試しに近郊で数回使ったが自分のへぼっぷりだと安全確保が難しいと判断してやめた
Uber 0円 2017年~ 2023、2024年と使わなかったのでさようなら
Uber Easts 0円 2016念~ 2023、2024年と使わなかったのでさようなら
Udemy コース次第 2017年~ 見る機会が減ったのでいったん停止

感想

2023年中にやめたのは記録とってないのでわすれました。値上がりがすごいですね、しょうがない。

ちゃんと2024年も利用サービスを減らしているのは良いのですが、新規も増えました。個人的なおすすめはRentioとChatGPTです。

  • Rentio: ロボット掃除機を試すのによい。ロボット掃除機は高い割に買うと満足できない率が高く、またいろんなものを試す機会が少ないので。レンタルで気に入るものを見つけるか、半年で返却して別のにしていくのは割と新鮮さがあってよい
  • ChatGPT: 壁打ち相手に最適で、自分の考えている構成や仕組みの穴や別の視点がないか確認できる。ChatGPT4から劇的に使いやすくなりました。o1はさらにいいけど遅いので、o1 miniが最近は多い

2024年に劇的によくなったサービスは、Bitwardenです。1Passwordとの差がかなり縮まったので、今後も期待です。

  • Bitwarden: UI/UXが刷新されFillによる自動入力精度がかなり向上し、Passkey対応もされている

変わっておらずやめたいけどやめられないサービスが、PlalaとMoneyForward MEです。ISP変えるのだるいんですよね。

  • Plala: ISPとしては新規を止めており2025年に終了か統合しそうな気配。こういう状況になったサービスはよいことないので、早めに切り替えたい
  • MoneyForward ME: 過去履歴を含めると入れ替えしたくないのが家計簿や会計ツール。MoneyForwardから切り離された(分社化)ので、2025年はどうなるか注目。個人的にはサービスのログインやUI、キャンペーン表示は微妙なので変化を期待

サービスが悪くなっていないという前提付きですが、Forkは買い切りでバランスの良いGitクライアントなので、GitKrakenより人にはオススメしやすいですね。布教した人はだいたいForkになっており、GitKrakenは使われる率が低いという。わかる。