
問題の詳細と対策について。

Windows 11では、アプリケーションをフルスクリーンで表示している時にAlt+Tabを利用すると、Alt+Tab押下中に表示されるウィンドウが増殖することがある。具体的には、同一のウィンドウに対して複数の要素が表示されるようになったり、既に閉じたウィンドウの情報が未だに表示され続けたりすることがある。

対策は、自分が執筆時点で把握しているものだと２通りある。なお、環境によっては問題が改善されない場合もあると聞いている。

１つは、設定 > システム > マルチタスク > デスクトップ の項目にある「Alt+Tabキーを押したときに、開いているすべてのウィンドウを表示する」を変更するという方法。これは症状が起きたときにそれを一時的に抑え込むという類の対処で、恒久的な解決策ではない。

![](https://i.imgur.com/ig3fhERh.png)

もう１つは、ExplorerPatcherというアプリケーションを導入し、ウィンドウの切り替え方法をWindows10スタイルに変更するという方法。こちらは恒久的な対処になり得る。但し、24H2以降のバージョンではExplorerPatcherはWindows Defenderによりブロックされるようになり、導入がより大変になったと聞いているので、この方法もあまりお勧めはしづらい状況にある。


2025-04-29-windows-11-alt-tab-duplicated

<p>問題の詳細と対策について。</p>
<p>Windows 11では、アプリケーションをフルスクリーンで表示している時にAlt+Tabを利用すると、Alt+Tab押下中に表示されるウィンドウが増殖することがある。具体的には、同一のウィンドウに対して複数の要素が表示されるようになったり、既に閉じたウィンドウの情報が未だに表示され続けたりすることがある。</p>
<p>対策は、自分が執筆時点で把握しているものだと２通りある。なお、環境によっては問題が改善されない場合もあると聞いている。</p>
<p>１つは、設定 > システム > マルチタスク > デスクトップ の項目にある「Alt+Tabキーを押したときに、開いているすべてのウィンドウを表示する」を変更するという方法。これは症状が起きたときにそれを一時的に抑え込むという類の対処で、恒久的な解決策ではない。</p>
<p><img src="https://i.imgur.com/ig3fhERh.png" alt=""></p>
<p>もう１つは、ExplorerPatcherというアプリケーションを導入し、ウィンドウの切り替え方法をWindows10スタイルに変更するという方法。こちらは恒久的な対処になり得る。但し、24H2以降のバージョンではExplorerPatcherはWindows Defenderによりブロックされるようになり、導入がより大変になったと聞いているので、この方法もあまりお勧めはしづらい状況にある。</p>


Windows 11 Alt+Tab ウィンドウ増殖問題


2024年分の確定申告の振り返り。

## 過去回

- [2022年分の確定申告](https://r7kamura.com/articles/2024-02-01-kakutei)
- [2022年分の確定申告](https://r7kamura.com/articles/2023-02-15-kakutei)
- [2021年分の確定申告](https://r7kamura.com/articles/2022-02-01-kakutei)
- [2020年分の確定申告](https://r7kamura.com/articles/2021-02-03-kakutei)
- [2019年分の確定申告](https://r7kamura.com/articles/2020-02-25-kakutei)

## 提出方法

前年までと同様、以下の方法で提出した。

- 所得税は会計freeeの提出フローに従い提出
- 消費税は会計freeeでXTXファイル生成後、Web版e-taxでアップロードして提出

今年から消費税も会計freeeから直接提出できるようになったとの事で楽しみにしていたのだが、最終的にe-taxとの通信でエラーが常に発生する問題が生じており、この方法では提出できなかった。来年に期待。

## 今年よくできたこと

今年も中間納付分の記載を忘れずに進められた。2021年は所得税の中間納付分の記載を忘れ、2022年は消費税の中間納付分の記載を忘れるという誤りがあったため、自戒の意味でわざわざ書いている。


2024年分の確定申告の振り返り。

2025-02-02-kakutei

<p>2024年分の確定申告の振り返り。</p>
<h2>過去回</h2>
<ul>
<li><a href="https://r7kamura.com/articles/2024-02-01-kakutei">2022年分の確定申告</a></li>
<li><a href="https://r7kamura.com/articles/2023-02-15-kakutei">2022年分の確定申告</a></li>
<li><a href="https://r7kamura.com/articles/2022-02-01-kakutei">2021年分の確定申告</a></li>
<li><a href="https://r7kamura.com/articles/2021-02-03-kakutei">2020年分の確定申告</a></li>
<li><a href="https://r7kamura.com/articles/2020-02-25-kakutei">2019年分の確定申告</a></li>
</ul>
<h2>提出方法</h2>
<p>前年までと同様、以下の方法で提出した。</p>
<ul>
<li>所得税は会計freeeの提出フローに従い提出</li>
<li>消費税は会計freeeでXTXファイル生成後、Web版e-taxでアップロードして提出</li>
</ul>
<p>今年から消費税も会計freeeから直接提出できるようになったとの事で楽しみにしていたのだが、最終的にe-taxとの通信でエラーが常に発生する問題が生じており、この方法では提出できなかった。来年に期待。</p>
<h2>今年よくできたこと</h2>
<p>今年も中間納付分の記載を忘れずに進められた。2021年は所得税の中間納付分の記載を忘れ、2022年は消費税の中間納付分の記載を忘れるという誤りがあったため、自戒の意味でわざわざ書いている。</p>


2024年分の確定申告


複数のGemfileを並行運用する際に便利な情報を幾つか挙げておく。

## 更新漏れの検知

複数のGemfileを並行運用していると「Gemfile.lockを変更したがもう１つのlockファイルの更新を忘れてしまった」という事態が起き得る。これを避けるために、差分検知を行うworkflowを設けておくと有用である。

以下はr7kamura/gemfile-diffというactionで実現する例:

```yaml
name: gemfile-diff

on:
  pull_request:
    paths:
      - Gemfile.lock
      - Gemfile_rails_8_0.rb.lock

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: r7kamura/gemfile-diff@v0
        with:
          gemfile_lock_a: Gemfile.lock
          gemfile_lock_b: Gemfile_rails_8_0.rb.lock
          ignore:
            actioncable
            actionmailbox
            actionmailer
            actionpack
            actiontext
            actionview
            activejob
            activemodel
            activerecord
            activestorage
            activesupport
            rails
            railties
```

## Dependabot対策

DependabotはGemfile.lockしか更新してくれないので、並行運用時にDependabotを稼働させるには何らかの対策が必要になる。

dependabot/fetch-metadataというactionを使うと、dependabotが変更対象としているGemの名前を取得できる。
これを利用すると、dependabotからのPull Requestの場合に他のlockファイルも自動で更新させるという処理を実現できる。

一例としては、以下のようなWorkflowを用意すると良い。

```yaml
name: gemfile-lock-update-for-dependabot

on:
  pull_request:
    paths:
      - Gemfile.lock

jobs:
  gemfile-lock-update-for-dependabot:
    permissions:
      pull-requests: read
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - uses: actions/create-github-app-token@v1
        id: app-token
        with:
          app-id: ${{ secrets.MY_GITHUB_APP_ID }}
          private-key: ${{ secrets.MY_GITHUB_APP_PRIVATE_KEY }}
      - uses: actions/checkout@v4
        with:
          token: ${{ steps.app-token.outputs.token }}
      - uses: dependabot/fetch-metadata@v2
        id: metadata
      - uses: ruby/setup-ruby@v1
      - run: bundle update "${{ steps.metadata.outputs.dependency-names }}"
        env:
          BUNDLE_FROZEN: "false"
          BUNDLE_GEMFILE: Gemfile_rails_8_0.rb
      - uses: stefanzweifel/git-auto-commit-action@v5
```

この例ではPersonal Access TokenではなくGitHub Appを利用してアクセストークンを発行しているが、どちらで実装しても構わない。
いずれの方法を取るにせよ、このアクセストークンには以下の権限が必要になる。

- contents: write
- workflows: write


複数のGemfileを並行運用する際に便利な情報を幾つか挙げておく。

2024-12-16-gemfiles

<p>複数のGemfileを並行運用する際に便利な情報を幾つか挙げておく。</p>
<h2>更新漏れの検知</h2>
<p>複数のGemfileを並行運用していると「Gemfile.lockを変更したがもう１つのlockファイルの更新を忘れてしまった」という事態が起き得る。これを避けるために、差分検知を行うworkflowを設けておくと有用である。</p>
<p>以下はr7kamura/gemfile-diffというactionで実現する例:</p>
<pre><code>name: gemfile-diff

on:
  pull_request:
    paths:
      - Gemfile.lock
      - Gemfile_rails_8_0.rb.lock

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: r7kamura/gemfile-diff@v0
        with:
          gemfile_lock_a: Gemfile.lock
          gemfile_lock_b: Gemfile_rails_8_0.rb.lock
          ignore:
            actioncable
            actionmailbox
            actionmailer
            actionpack
            actiontext
            actionview
            activejob
            activemodel
            activerecord
            activestorage
            activesupport
            rails
            railties
</code></pre>
<h2>Dependabot対策</h2>
<p>DependabotはGemfile.lockしか更新してくれないので、並行運用時にDependabotを稼働させるには何らかの対策が必要になる。</p>
<p>dependabot/fetch-metadataというactionを使うと、dependabotが変更対象としているGemの名前を取得できる。
これを利用すると、dependabotからのPull Requestの場合に他のlockファイルも自動で更新させるという処理を実現できる。</p>
<p>一例としては、以下のようなWorkflowを用意すると良い。</p>
<pre><code>name: gemfile-lock-update-for-dependabot

on:
  pull_request:
    paths:
      - Gemfile.lock

jobs:
  gemfile-lock-update-for-dependabot:
    permissions:
      pull-requests: read
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - uses: actions/create-github-app-token@v1
        id: app-token
        with:
          app-id: ${{ secrets.MY_GITHUB_APP_ID }}
          private-key: ${{ secrets.MY_GITHUB_APP_PRIVATE_KEY }}
      - uses: actions/checkout@v4
        with:
          token: ${{ steps.app-token.outputs.token }}
      - uses: dependabot/fetch-metadata@v2
        id: metadata
      - uses: ruby/setup-ruby@v1
      - run: bundle update "${{ steps.metadata.outputs.dependency-names }}"
        env:
          BUNDLE_FROZEN: "false"
          BUNDLE_GEMFILE: Gemfile_rails_8_0.rb
      - uses: stefanzweifel/git-auto-commit-action@v5
</code></pre>
<p>この例ではPersonal Access TokenではなくGitHub Appを利用してアクセストークンを発行しているが、どちらで実装しても構わない。
いずれの方法を取るにせよ、このアクセストークンには以下の権限が必要になる。</p>
<ul>
<li>contents: write</li>
<li>workflows: write</li>
</ul>


Gemfile並行運用時のTips


長年の運用で「Gemfileはこう運用すると上手くいった」という知見が蓄積されてきたので、ここに書き出してみておく。

## Bundler/OrderedGemsを有効化する

RuboCopの `Bundler/OrderedGems` Copを有効化する。

悪い例:

```ruby
gem 'puma'
gem 'jbuilder'
```

良い例:

```ruby
gem 'jbuilder'
gem 'puma'
```

## セクションを分けない

基本的に、独自の判断で空行を入れてセクションを分けたりしない。

ここで言うセクションとは「空行で区切られた１つのまとまり」のことである。`Bundler/OrderedGems` は、このまとまりの中で辞書順であることを要求する。

悪い例:

```ruby
gem 'aws-sdk-rails'
gem 'aws-sdk-s3'

gem 'graphql'
gem 'graphql-batch'
```

良い例:

```ruby
gem 'aws-sdk-rails'
gem 'aws-sdk-s3'
gem 'graphql'
gem 'graphql-batch'
```

但し、１つの例外を認める。`Bundler.require` を活用しているプロジェクトで、どうしても先に読み込ませたいgemがある場合である。代表的な例だと、`if defined?(Rails)` のためにrails gemを先に読み込ませておきたいといった例が挙げられる。

悪い例:

```ruby
gem 'jbuilder'
gem 'puma'
gem 'rails'
```

良い例:

```ruby
gem 'rails'

gem 'jbuilder'
gem 'puma'
```

## 無駄にgemを読み込まない

`Bundler.require` が使われている場合、適切に `require: false` を付ける。

`Bundler.require` が使われる代表例として、主にRailsアプリが挙げられる。
このような環境では、`require: false` を明示的に付けない限り、Gemfileに定義したgemは自動的に読み込まれることになる。
静的解析器などの同じプロセスで利用されないgemや、CIなどの特定の状況でしか利用されないgemについては、適切に `require: false` を付ける。

悪い例:

```ruby
group :development do
  gem 'brakeman'
  gem 'bullet'
  gem 'rubocop'
  gem 'rubocop-rails'
end

group :test do
  gem 'rspec'
  gem 'rspec_junit_formatter'
end
```

良い例:

```ruby
group :development do
  gem 'brakeman', require: false
  gem 'bullet'
  gem 'rubocop', require: false
  gem 'rubocop-rails', require: false
end

group :test do
  gem 'rspec'
  gem 'rspec_junit_formatter', require: false
end
```

## gem groupを分ける

独立して使われるgemは別のgem groupに分ける。

例えばRailsアプリの開発において、rubocopやbrakemanなどの静的解析ツールは、Railsの実行時に使うgem群と同時に読み込む必要がない。
こういった場合、gem groupを適切に分けておくことで、結果的にCIでインストールするべきgemの数を減らたり、`require: false` オプションの記述を省けたりといった恩恵がある。

悪い例:

```ruby
group :development do
  gem 'brakeman', require: false
  gem 'bullet'
  gem 'rubocop', require: false
  gem 'rubocop-rails', require: false
end
```

良い例:

```ruby
group :brakeman do
  gem 'brakeman'
end

group :development do
  gem 'bullet'
end

group :rubocop do
  gem 'rubocop'
  gem 'rubocop-rails'
end
```

## コメントにWhatを書かない

そのGemのdescriptionを見れば分かるような情報をコメントに書かない。

コメントはあればあるほど情報量が増えて嬉しいという訳ではない。重要性の低い情報が増えれば増えるほど、重要な情報がより見られなくなってしまう。また、コメントは無料ではなく、意外とそれを保守するためにコストが支払われる。

どのコメントが「必要」でどのコメントが「不要」かを決めるのは容易ではない。指針として、5W1Hで言うところのWhyを表す情報は残すに足る価値があり、Whatには無い、という指針が良いと考えている。

悪い例:

```ruby
gem 'jbuilder' # JSON生成用のDSLを提供する。
gem 'listen' # i18n-jsの自動更新機能に必要。
gem 'vcr', '5.0.0' # 次のバージョンからライセンスが変更されてしまう。
```

良い例:

```ruby
gem 'jbuilder'
gem 'listen' # i18n-jsの自動更新機能に必要。
gem 'vcr', '5.0.0' # 次のバージョンからライセンスが変更されてしまう。
```

## 無駄にバージョンを指定しない

バージョン指定は「この範囲までのアップグレードを機械的に提案してほしい」という意図を持って指定する。

より大きな人件費を掛けて人力で変更を提案してもらいたい場合はバージョンを指定する。「その時点で採用したバージョンにとりあえず `~>` を付けて指定しておこう」といった類の行為は避ける。なお、前述の話と合わせると、バージョンを指定する場合にはその理由がコメントに書かれることになるはず。

悪い例:

```ruby
gem 'aws-sdk-rails', '~> 5.0.0'
```

良い例:

```ruby
gem 'aws-sdk-rails'
```

ところで、主にGemfileの記述や保守のコストの観点から、基本的にgemのダウングレードが提案される可能性を考慮しない形でバージョンを指定していくほうが効率的なことが多い。「◯◯以上」というバージョン指定が単独で発生するのは稀なことになる。

## dependabotにlockfile-onlyを指定する

dependabotに `versioning-strategy: lockfile-only` を設定する。

dependabotは、デフォルトではGemfileでのバージョン指定を考慮してくれない。この状態では、どのようにバージョンを指定していてもその指定ごと変更を提案されてしまい、先述したようなバージョン指定の運用ができない。

またこのデフォルト設定で運用していると、dependabotの設定ファイルに特定のGemのアップグレードを提案しない設定やその理由が書かれることになるため、情報の分散を招き保守性を下げるという点でも好ましくない。

悪い例:

```yaml
updates:
  - package-ecosystem: bundler
    directory: ...
    schedule: ...
```

良い例:

```yaml
updates:
  - package-ecosystem: bundler
    directory: ...
    schedule: ...
    versioning-strategy: lockfile-only
```

## dependabotの付けるラベルを変更する

デフォルトの `dependencies` + `ruby` のラベルから、`dependabot-bundler` 等に変更しておく。

デフォルトで用意される `ruby` ラベルは特に誤解を招きやすく、まともな運用に適さない。`ruby` ラベルの説明文には「Pull requests that update Ruby code」と記載されるが、こういうものがあると「Rubyのコードを変更するから、自分のつくったPull Requestに `ruby` ラベルを付けておこう」と考えてこのラベルを付けたり付けなかったりする者が後を絶たない。

`dependencies` ラベルは  `author:dependabot` で代替できるので、このラベルの存在によって付加される情報量は少ない。

悪い例:

```yaml
updates:
  - package-ecosystem: bundler
    directory: ...
    schedule: ...
```

良い例:

```yaml
updates:
  - package-ecosystem: bundler
    directory: ...
    schedule: ...
    labels:
      - dependabot-bundler
```


長年の運用で「Gemfileはこう運用すると上手くいった」という知見が蓄積されてきたので、ここに書き出してみておく。

2024-11-30-gemfile

<p>長年の運用で「Gemfileはこう運用すると上手くいった」という知見が蓄積されてきたので、ここに書き出してみておく。</p>
<h2>Bundler/OrderedGemsを有効化する</h2>
<p>RuboCopの <code>Bundler/OrderedGems</code> Copを有効化する。</p>
<p>悪い例:</p>
<pre><code>gem 'puma'
gem 'jbuilder'
</code></pre>
<p>良い例:</p>
<pre><code>gem 'jbuilder'
gem 'puma'
</code></pre>
<h2>セクションを分けない</h2>
<p>基本的に、独自の判断で空行を入れてセクションを分けたりしない。</p>
<p>ここで言うセクションとは「空行で区切られた１つのまとまり」のことである。<code>Bundler/OrderedGems</code> は、このまとまりの中で辞書順であることを要求する。</p>
<p>悪い例:</p>
<pre><code>gem 'aws-sdk-rails'
gem 'aws-sdk-s3'

gem 'graphql'
gem 'graphql-batch'
</code></pre>
<p>良い例:</p>
<pre><code>gem 'aws-sdk-rails'
gem 'aws-sdk-s3'
gem 'graphql'
gem 'graphql-batch'
</code></pre>
<p>但し、１つの例外を認める。<code>Bundler.require</code> を活用しているプロジェクトで、どうしても先に読み込ませたいgemがある場合である。代表的な例だと、<code>if defined?(Rails)</code> のためにrails gemを先に読み込ませておきたいといった例が挙げられる。</p>
<p>悪い例:</p>
<pre><code>gem 'jbuilder'
gem 'puma'
gem 'rails'
</code></pre>
<p>良い例:</p>
<pre><code>gem 'rails'

gem 'jbuilder'
gem 'puma'
</code></pre>
<h2>無駄にgemを読み込まない</h2>
<p><code>Bundler.require</code> が使われている場合、適切に <code>require: false</code> を付ける。</p>
<p><code>Bundler.require</code> が使われる代表例として、主にRailsアプリが挙げられる。
このような環境では、<code>require: false</code> を明示的に付けない限り、Gemfileに定義したgemは自動的に読み込まれることになる。
静的解析器などの同じプロセスで利用されないgemや、CIなどの特定の状況でしか利用されないgemについては、適切に <code>require: false</code> を付ける。</p>
<p>悪い例:</p>
<pre><code>group :development do
  gem 'brakeman'
  gem 'bullet'
  gem 'rubocop'
  gem 'rubocop-rails'
end

group :test do
  gem 'rspec'
  gem 'rspec_junit_formatter'
end
</code></pre>
<p>良い例:</p>
<pre><code>group :development do
  gem 'brakeman', require: false
  gem 'bullet'
  gem 'rubocop', require: false
  gem 'rubocop-rails', require: false
end

group :test do
  gem 'rspec'
  gem 'rspec_junit_formatter', require: false
end
</code></pre>
<h2>gem groupを分ける</h2>
<p>独立して使われるgemは別のgem groupに分ける。</p>
<p>例えばRailsアプリの開発において、rubocopやbrakemanなどの静的解析ツールは、Railsの実行時に使うgem群と同時に読み込む必要がない。
こういった場合、gem groupを適切に分けておくことで、結果的にCIでインストールするべきgemの数を減らたり、<code>require: false</code> オプションの記述を省けたりといった恩恵がある。</p>
<p>悪い例:</p>
<pre><code>group :development do
  gem 'brakeman', require: false
  gem 'bullet'
  gem 'rubocop', require: false
  gem 'rubocop-rails', require: false
end
</code></pre>
<p>良い例:</p>
<pre><code>group :brakeman do
  gem 'brakeman'
end

group :development do
  gem 'bullet'
end

group :rubocop do
  gem 'rubocop'
  gem 'rubocop-rails'
end
</code></pre>
<h2>コメントにWhatを書かない</h2>
<p>そのGemのdescriptionを見れば分かるような情報をコメントに書かない。</p>
<p>コメントはあればあるほど情報量が増えて嬉しいという訳ではない。重要性の低い情報が増えれば増えるほど、重要な情報がより見られなくなってしまう。また、コメントは無料ではなく、意外とそれを保守するためにコストが支払われる。</p>
<p>どのコメントが「必要」でどのコメントが「不要」かを決めるのは容易ではない。指針として、5W1Hで言うところのWhyを表す情報は残すに足る価値があり、Whatには無い、という指針が良いと考えている。</p>
<p>悪い例:</p>
<pre><code>gem 'jbuilder' # JSON生成用のDSLを提供する。
gem 'listen' # i18n-jsの自動更新機能に必要。
gem 'vcr', '5.0.0' # 次のバージョンからライセンスが変更されてしまう。
</code></pre>
<p>良い例:</p>
<pre><code>gem 'jbuilder'
gem 'listen' # i18n-jsの自動更新機能に必要。
gem 'vcr', '5.0.0' # 次のバージョンからライセンスが変更されてしまう。
</code></pre>
<h2>無駄にバージョンを指定しない</h2>
<p>バージョン指定は「この範囲までのアップグレードを機械的に提案してほしい」という意図を持って指定する。</p>
<p>より大きな人件費を掛けて人力で変更を提案してもらいたい場合はバージョンを指定する。「その時点で採用したバージョンにとりあえず <code>~></code> を付けて指定しておこう」といった類の行為は避ける。なお、前述の話と合わせると、バージョンを指定する場合にはその理由がコメントに書かれることになるはず。</p>
<p>悪い例:</p>
<pre><code>gem 'aws-sdk-rails', '~> 5.0.0'
</code></pre>
<p>良い例:</p>
<pre><code>gem 'aws-sdk-rails'
</code></pre>
<p>ところで、主にGemfileの記述や保守のコストの観点から、基本的にgemのダウングレードが提案される可能性を考慮しない形でバージョンを指定していくほうが効率的なことが多い。「◯◯以上」というバージョン指定が単独で発生するのは稀なことになる。</p>
<h2>dependabotにlockfile-onlyを指定する</h2>
<p>dependabotに <code>versioning-strategy: lockfile-only</code> を設定する。</p>
<p>dependabotは、デフォルトではGemfileでのバージョン指定を考慮してくれない。この状態では、どのようにバージョンを指定していてもその指定ごと変更を提案されてしまい、先述したようなバージョン指定の運用ができない。</p>
<p>またこのデフォルト設定で運用していると、dependabotの設定ファイルに特定のGemのアップグレードを提案しない設定やその理由が書かれることになるため、情報の分散を招き保守性を下げるという点でも好ましくない。</p>
<p>悪い例:</p>
<pre><code>updates:
  - package-ecosystem: bundler
    directory: ...
    schedule: ...
</code></pre>
<p>良い例:</p>
<pre><code>updates:
  - package-ecosystem: bundler
    directory: ...
    schedule: ...
    versioning-strategy: lockfile-only
</code></pre>
<h2>dependabotの付けるラベルを変更する</h2>
<p>デフォルトの <code>dependencies</code> + <code>ruby</code> のラベルから、<code>dependabot-bundler</code> 等に変更しておく。</p>
<p>デフォルトで用意される <code>ruby</code> ラベルは特に誤解を招きやすく、まともな運用に適さない。<code>ruby</code> ラベルの説明文には「Pull requests that update Ruby code」と記載されるが、こういうものがあると「Rubyのコードを変更するから、自分のつくったPull Requestに <code>ruby</code> ラベルを付けておこう」と考えてこのラベルを付けたり付けなかったりする者が後を絶たない。</p>
<p><code>dependencies</code> ラベルは  <code>author:dependabot</code> で代替できるので、このラベルの存在によって付加される情報量は少ない。</p>
<p>悪い例:</p>
<pre><code>updates:
  - package-ecosystem: bundler
    directory: ...
    schedule: ...
</code></pre>
<p>良い例:</p>
<pre><code>updates:
  - package-ecosystem: bundler
    directory: ...
    schedule: ...
    labels:
      - dependabot-bundler
</code></pre>


Gemfileのベストプラクティス


よく考えたら作業机いらなくね？と思い、手放すことにした。「机捨てた」と言うと相手の思考が止まりがちなので、普段は「テレビでパソコンしてる」って説明してる。これが一番伝わりやすい。

![](https://i.imgur.com/ucJBvBfh.jpg "現在の作業場")

立ち座りしやすく、疲れづらいのがいいところ。あと掃除がしやすい。

トラックボール付きのキーボードが椅子についてて、動画編集やプログラミングなど、意外とこれで十分作業できている。ゲームパッド非対応のPCゲーム等でどうしてもマウスが必要なときは、椅子の隣に袖机的な何かをもってきている。上の写真ではソファの一部を場当たり的にもってきていますね。

この環境で重宝しているものとして、[DJI Mic 2](https://www.amazon.co.jp/dp/B0CFZX734J)がある。これは無線のピンマイクで、Discordや会議なんかで通話するときにワイヤレスイヤホンと併せて使っている。元々カメラの撮影用機材として入手したものだけど、通話用マイクとしても意外と使い勝手が良かった。家の中ならどこでも繋がるので、ソファとかに移動してそのままゴロゴロしながら通話できるのも良い。

![](https://i.imgur.com/u2lPY19h.jpg "前の作業場")

これまで使っていた机やディスプレイ、アームなんかは、それぞれ友人達に譲った。他の人はどうか分からないけど、もの捨てるのって心理的にかなり重く感じる。悪い意味で、悪いことをしている気持ちになるというか。こういう風に知り合いでもらい受けてくれる人がいると、心理的な負担が和らいで助かる。たとえ気休めであったとしても。


よく考えたら作業机いらなくね？と思い、手放すことにした。

2024-08-12-desk

<p>よく考えたら作業机いらなくね？と思い、手放すことにした。「机捨てた」と言うと相手の思考が止まりがちなので、普段は「テレビでパソコンしてる」って説明してる。これが一番伝わりやすい。</p>
<figure><img src="https://i.imgur.com/ucJBvBfh.jpg" alt="" title="現在の作業場"><figcaption>現在の作業場</figcaption></figure>
<p>立ち座りしやすく、疲れづらいのがいいところ。あと掃除がしやすい。</p>
<p>トラックボール付きのキーボードが椅子についてて、動画編集やプログラミングなど、意外とこれで十分作業できている。ゲームパッド非対応のPCゲーム等でどうしてもマウスが必要なときは、椅子の隣に袖机的な何かをもってきている。上の写真ではソファの一部を場当たり的にもってきていますね。</p>
<p>この環境で重宝しているものとして、<a href="https://www.amazon.co.jp/dp/B0CFZX734J?tag=r7kamuracom-22">DJI Mic 2</a>がある。これは無線のピンマイクで、Discordや会議なんかで通話するときにワイヤレスイヤホンと併せて使っている。元々カメラの撮影用機材として入手したものだけど、通話用マイクとしても意外と使い勝手が良かった。家の中ならどこでも繋がるので、ソファとかに移動してそのままゴロゴロしながら通話できるのも良い。</p>
<figure><img src="https://i.imgur.com/u2lPY19h.jpg" alt="" title="前の作業場"><figcaption>前の作業場</figcaption></figure>
<p>これまで使っていた机やディスプレイ、アームなんかは、それぞれ友人達に譲った。他の人はどうか分からないけど、もの捨てるのって心理的にかなり重く感じる。悪い意味で、悪いことをしている気持ちになるというか。こういう風に知り合いでもらい受けてくれる人がいると、心理的な負担が和らいで助かる。たとえ気休めであったとしても。</p>


我が机を、ここに棄てる


r7kamura/bump-requestを改善して、ボタンをポチポチやるだけでパッケージの新しいバージョンをリリースできるようにした。

- <https://github.com/r7kamura/bump-request>

![](https://i.imgur.com/xFAU4fch.png)

r7kamura/bump-requestは、新しいバージョンのリリースを自動化するためのGitHub Action。何個もパッケージをメンテナンスしていると、流石にこういうものがないと生きづらくなっていく。詳しくは以前の記事でも触れている。

- [リリースの自動化](https://r7kamura.com/articles/2022-12-24-release-automation)

これを使う際、以前までは新しいバージョンを都度手入力する必要があったが、今回これを `major`, `minor`, `patch` の選択肢を元に自動計算してくれるようにできた。semantic versioningのバージョン形式に則っているだろうということを前提として、最新のリリースのバージョンを元に次のバージョンを計算するという素朴な仕組みになっている。

---

そこまで複雑ではない処理内容だったので、以前まではシェルスクリプトで実装していた。しかし今回から少しばかり複雑な計算処理が入ることになったので、このタイミングでDenoを使う実装に移行しておいた。

Denoは、おおよそNode.js互換なJavaScriptのランタイムに、TypeScript compiler、Formatter、Linter、Test runner等がデフォルトで同梱されている便利なツール。こういうちょっとしたスクリプトを型の恩恵を受けつついい感じに書けるのがたいへん便利。

- <https://deno.com/>


r7kamura/bump-requestを改善して、ボタンをポチポチやるだけでパッケージの新しいバージョンをリリースできるようにした。

2024-06-01-bump-request

<p>r7kamura/bump-requestを改善して、ボタンをポチポチやるだけでパッケージの新しいバージョンをリリースできるようにした。</p>
<ul>
<li><a href="https://github.com/r7kamura/bump-request">https://github.com/r7kamura/bump-request</a></li>
</ul>
<p><img src="https://i.imgur.com/xFAU4fch.png" alt=""></p>
<p>r7kamura/bump-requestは、新しいバージョンのリリースを自動化するためのGitHub Action。何個もパッケージをメンテナンスしていると、流石にこういうものがないと生きづらくなっていく。詳しくは以前の記事でも触れている。</p>
<ul>
<li><a href="https://r7kamura.com/articles/2022-12-24-release-automation">リリースの自動化</a></li>
</ul>
<p>これを使う際、以前までは新しいバージョンを都度手入力する必要があったが、今回これを <code>major</code>, <code>minor</code>, <code>patch</code> の選択肢を元に自動計算してくれるようにできた。semantic versioningのバージョン形式に則っているだろうということを前提として、最新のリリースのバージョンを元に次のバージョンを計算するという素朴な仕組みになっている。</p>
<hr>
<p>そこまで複雑ではない処理内容だったので、以前まではシェルスクリプトで実装していた。しかし今回から少しばかり複雑な計算処理が入ることになったので、このタイミングでDenoを使う実装に移行しておいた。</p>
<p>Denoは、おおよそNode.js互換なJavaScriptのランタイムに、TypeScript compiler、Formatter、Linter、Test runner等がデフォルトで同梱されている便利なツール。こういうちょっとしたスクリプトを型の恩恵を受けつついい感じに書けるのがたいへん便利。</p>
<ul>
<li><a href="https://deno.com/">https://deno.com/</a></li>
</ul>


ボタンをポチポチしてパッケージをリリース


現在自分が利用しているキーマップについて。

## 基本情報

- Keyball39
- ローマ字入力
- 日本語キーボード
- Windows
- プログラミング、動画編集等で利用

## レイヤー０

![](https://i.imgur.com/vIdbZn7h.png "デフォルトのレイヤー")

全体構想として、モディファイアキー・レイヤーキー・クリックキーを左右両方に配置することで、取れる選択肢を増やしつつ負担を減らすことを目指している。このために、特徴的な設計としてホームポジションにモディファイアを配置している。この方式は、英語圏ではよくHome Row Modsと呼ばれている。単押しで文字入力、長押しでモディファイアキーになる。

この方式の利点は、小指を使わなくて済んだり、親指のキーを他の用途に明け渡せたり、複数モディファイアを組み合わせやすかったりする点。例えば、プログラミングをしているとエディタでCtrl+ShiftやAlt+Shiftを活用できる場面が多く、この方式だとそれが扱いやすい。

この方式の欠点は、入力精度が低いと短押しと長押しを誤ったり、GUIツール経由だと諸事情でShift付きのキーを短押しに設定できなかったり、キーリピートさせたい場合に最初に２連打を要求されたりする点。他のモディファイアは誤って単体で長押ししてしまっても問題が起こりにくい一方、Windowsキーは誤って単体で長押ししたときにスタートメニューが出てきてしまったり、また使用頻度が低かったりという都合で、ホームポジションには割り当てていない。

トラックボール付きのキーボードを利用しているので、ポインタ操作もキーボード上で完結できるよう、このキーボードの特殊な位置に付いているキーに左クリックを割り当てている。この位置に配置しておくと、ポインタ操作を行わないキーボードでのキーマップとの互換性を保ちやすい。この左クリックキーはレイヤー１では右クリックに、レイヤー２では中クリックになる。小指の付け根で押していて、実は慣れると意外と押しやすい。

親指のホームポジションによく使うレイヤー１への切り替えキーを配置している。押しやすいこの部分の短押しにSpaceとEnterを設けず、あえてその隣のキーに配置しているのは、主に誤操作を防ぐため。チャットアプリ等ではEnterキーで即座に送信することが多いので、これが間違って押されてしまうと被害が大きい。短押し・長押しでの切り替えは入力時間に依存する関係上、急いで入力しているとどうしても誤入力が発生しやすいので、誤ることを前提として考えている。

## レイヤー１

![](https://i.imgur.com/BLFsIFth.png "レイヤー１キーを押している間だけ有効な、よく使うレイヤー")

左手がテンキーになっていて、数字とよく使う記号を配置している。具体的には、時間の入力時に使うコロン、郵便番号や電話番号に使うハイフン、数値で使うピリオドなど。数字キーのShiftキー領域はこのレイヤーでは使わない。

右手は移動キーになっていて、矢印キーやその他諸々の便利キーを配置している。タブ移動用にCtrl+PageUp/PageDownを配置していて、これが結構捗る。あとはWindowsだと、ページを閉じるためのCtrl+Wや、アプリケーションを終了させるためのAlt+F4などが便利。

IMEの切り替えキーもこのレイヤーに用意している。親指キーの同時押しでIMEを切り替えられるようにしていて、左→右の順で押すとかな、右→左の順で押すと英数になる。いわゆるComboと呼ばれる同時押しはGUIだと設定できないものの、レイヤーキーと兼ねる形だとこういう運用ができてちょっと便利。貧者のコンボと言える。

かな入力だとそうもいかないんだけど、ローマ字入力だとShiftキーで一時的に半角英数入力に切り替えられたり、IME側の変換で対応できたりするので、実際のところプログラマーのような日英入り交じる文字列を書くことが多い職種であっても、IME切り替え用のキーをデフォルトレイヤーに用意しなくても何とかなっている。

## レイヤー２

![](https://i.imgur.com/n33RZWOh.png "レイヤー２キーを押している間だけ有効な、たまに使うレイヤー")

記号レイヤー。

記号は個々人で頻度が大きく変わる部分なので、あくまで参考程度に。括弧系の記号がすべてこの列にあるのがちょっと覚えやすい。`<` や `>` もデフォルトレイヤーのこの列にある。

## その他

OS側の設定等で工夫している部分について。

入力頻度の多い長音「ー」を１打で入力できるように、Google日本語入力のローマ字テーブルを編集して、Lキーで長音「ー」を入力できるようにしている。元々Lキーは小文字入力用に使えるキーだが、この機能は利用頻度も低い上に、Xキーでも代替できる。

Altキーを比較的押しやすい位置に配置できているので、アプリケーション等にカスタムショートカットを設定するときは大抵Altキーとの組み合わせを使っている。例えば、ブックマークをFuzzy検索するショートカットをAlt+Bに設定したり、インデントをAlt+→、アウトデントをAlt+←に設定したり、最近利用したVSCodeワークスペースをPowerToys RunのAlt+Spaceで検索したりといった具合。


現在自分が利用しているキーマップについて。

2024-05-26-keymap

<p>現在自分が利用しているキーマップについて。</p>
<h2>基本情報</h2>
<ul>
<li>Keyball39</li>
<li>ローマ字入力</li>
<li>日本語キーボード</li>
<li>Windows</li>
<li>プログラミング、動画編集等で利用</li>
</ul>
<h2>レイヤー０</h2>
<figure><img src="https://i.imgur.com/vIdbZn7h.png" alt="" title="デフォルトのレイヤー"><figcaption>デフォルトのレイヤー</figcaption></figure>
<p>全体構想として、モディファイアキー・レイヤーキー・クリックキーを左右両方に配置することで、取れる選択肢を増やしつつ負担を減らすことを目指している。このために、特徴的な設計としてホームポジションにモディファイアを配置している。この方式は、英語圏ではよくHome Row Modsと呼ばれている。単押しで文字入力、長押しでモディファイアキーになる。</p>
<p>この方式の利点は、小指を使わなくて済んだり、親指のキーを他の用途に明け渡せたり、複数モディファイアを組み合わせやすかったりする点。例えば、プログラミングをしているとエディタでCtrl+ShiftやAlt+Shiftを活用できる場面が多く、この方式だとそれが扱いやすい。</p>
<p>この方式の欠点は、入力精度が低いと短押しと長押しを誤ったり、GUIツール経由だと諸事情でShift付きのキーを短押しに設定できなかったり、キーリピートさせたい場合に最初に２連打を要求されたりする点。他のモディファイアは誤って単体で長押ししてしまっても問題が起こりにくい一方、Windowsキーは誤って単体で長押ししたときにスタートメニューが出てきてしまったり、また使用頻度が低かったりという都合で、ホームポジションには割り当てていない。</p>
<p>トラックボール付きのキーボードを利用しているので、ポインタ操作もキーボード上で完結できるよう、このキーボードの特殊な位置に付いているキーに左クリックを割り当てている。この位置に配置しておくと、ポインタ操作を行わないキーボードでのキーマップとの互換性を保ちやすい。この左クリックキーはレイヤー１では右クリックに、レイヤー２では中クリックになる。小指の付け根で押していて、実は慣れると意外と押しやすい。</p>
<p>親指のホームポジションによく使うレイヤー１への切り替えキーを配置している。押しやすいこの部分の短押しにSpaceとEnterを設けず、あえてその隣のキーに配置しているのは、主に誤操作を防ぐため。チャットアプリ等ではEnterキーで即座に送信することが多いので、これが間違って押されてしまうと被害が大きい。短押し・長押しでの切り替えは入力時間に依存する関係上、急いで入力しているとどうしても誤入力が発生しやすいので、誤ることを前提として考えている。</p>
<h2>レイヤー１</h2>
<figure><img src="https://i.imgur.com/BLFsIFth.png" alt="" title="レイヤー１キーを押している間だけ有効な、よく使うレイヤー"><figcaption>レイヤー１キーを押している間だけ有効な、よく使うレイヤー</figcaption></figure>
<p>左手がテンキーになっていて、数字とよく使う記号を配置している。具体的には、時間の入力時に使うコロン、郵便番号や電話番号に使うハイフン、数値で使うピリオドなど。数字キーのShiftキー領域はこのレイヤーでは使わない。</p>
<p>右手は移動キーになっていて、矢印キーやその他諸々の便利キーを配置している。タブ移動用にCtrl+PageUp/PageDownを配置していて、これが結構捗る。あとはWindowsだと、ページを閉じるためのCtrl+Wや、アプリケーションを終了させるためのAlt+F4などが便利。</p>
<p>IMEの切り替えキーもこのレイヤーに用意している。親指キーの同時押しでIMEを切り替えられるようにしていて、左→右の順で押すとかな、右→左の順で押すと英数になる。いわゆるComboと呼ばれる同時押しはGUIだと設定できないものの、レイヤーキーと兼ねる形だとこういう運用ができてちょっと便利。貧者のコンボと言える。</p>
<p>かな入力だとそうもいかないんだけど、ローマ字入力だとShiftキーで一時的に半角英数入力に切り替えられたり、IME側の変換で対応できたりするので、実際のところプログラマーのような日英入り交じる文字列を書くことが多い職種であっても、IME切り替え用のキーをデフォルトレイヤーに用意しなくても何とかなっている。</p>
<h2>レイヤー２</h2>
<figure><img src="https://i.imgur.com/n33RZWOh.png" alt="" title="レイヤー２キーを押している間だけ有効な、たまに使うレイヤー"><figcaption>レイヤー２キーを押している間だけ有効な、たまに使うレイヤー</figcaption></figure>
<p>記号レイヤー。</p>
<p>記号は個々人で頻度が大きく変わる部分なので、あくまで参考程度に。括弧系の記号がすべてこの列にあるのがちょっと覚えやすい。<code>&#x3C;</code> や <code>></code> もデフォルトレイヤーのこの列にある。</p>
<h2>その他</h2>
<p>OS側の設定等で工夫している部分について。</p>
<p>入力頻度の多い長音「ー」を１打で入力できるように、Google日本語入力のローマ字テーブルを編集して、Lキーで長音「ー」を入力できるようにしている。元々Lキーは小文字入力用に使えるキーだが、この機能は利用頻度も低い上に、Xキーでも代替できる。</p>
<p>Altキーを比較的押しやすい位置に配置できているので、アプリケーション等にカスタムショートカットを設定するときは大抵Altキーとの組み合わせを使っている。例えば、ブックマークをFuzzy検索するショートカットをAlt+Bに設定したり、インデントをAlt+→、アウトデントをAlt+←に設定したり、最近利用したVSCodeワークスペースをPowerToys RunのAlt+Spaceで検索したりといった具合。</p>
