GMKtec EVO-X2にUbuntuを入れたら有線LANが認識されなかった話

「最新版を使えばいい」は本当に正しい？Dependabotを使って“pin + 自動更新”にする理由

依存ライブラリやGitHub Actions、Terraform Providerのバージョン管理をしていると、よく出てくるのが次の考え方です。 新しいバージョンが出たら、常に最新版へ上げればいいのでは？ 一見すると合理的です。 実際、古いバージョンを長期間使い続けるより、継続的にアップデートした方が、脆弱性や非互換の問題を後回しにしにくくなります。 ただし、実際の開発運用では、 「バージョンを固定しない」ことと「常に新しい状態を保つ」ことは別です。 むしろ、 バージョンは固定し、Dependabotで自動的に更新PRを作る という運用の方が、安全性と更新頻度を両立しやすくなります。 今回は、実際の開発チームで出た「pinするべきか、しないべきか」という議論をベースに、Dependabotをどう使うべきか整理します。 きっかけは「そもそもpinしなくていいのでは？」という疑問 あるプロジェクトで、GitHub ActionsやTerraform Providerのバージョンを更新する話が出ました。 その中で、 理想的には何もpinしない方がいい。新しいバージョンが出たら常にアップグレードすればいいのでは？ という意見が出ました。 この考え方自体は間違っていません。 目標としては、 依存関係を古いまま放置しない というのが正しいです。 ただし、その目標を実現する方法として「pinしない」を選ぶと、別の問題が出てきます。 そこで出てきたのが、 「pinしない」のではなく、「pin + automated bumps」にしよう という考え方です。 つまり、 バージョンは固定する。しかし、更新作業は自動化する。 これがDependabotを使う理由です。 GitHub Actionsでは、floating tagがリスクになる たとえばGitHub Actionsでは、次のような指定をすることがあります。 これは分かりやすく、一般的な書き方です。 ただし、v4 のようなタグは、厳密には「特定のコードそのもの」を表しているわけではありません。 タグが別のコミットを指すように変更されれば、同じ @v4 という記述でも、実際に実行されるコードが変わる可能性があります。 CI/CDで実行されるActionは、ビルド環境やデプロイ権限にアクセスすることがあります。 そのため、これはサプライチェーンセキュリティの観点でも重要です。 より厳密に管理するなら、特定のコミットSHAに固定します。 こうすると、同じ設定から実行されるコードが勝手に変わることはありません。 ただし問題があります。 固定しただけでは、そのバージョンは永遠に古くなっていきます。 そこでDependabotを使います。 新しいバージョンが出たら、 という流れにします。 つまり、 固定することで再現性を確保し、Dependabotで鮮度を維持する […]

FSD v2.1 Feature-Sliced Design を導入する

この記事は何？ 公式のドキュメントやチュートリアル、exsample を読んで理解するのが一番いいですが、備忘録として残しておきます。特に後述の Skills, Steiger については開発する際にあった方が便利なので、それについても記事にします。 FSDとは？ FSD (Feature-Sliced Design) はフロントエンドのアーキテクチャの一つです。 FSDとは責務で分けていくアーキテクチャと違い、ページやエンティティで分けていくアーキテクチャというとわかりやすいと思います。 コードの分離の仕方について話す前に、FSDで前提となる この３つについて理解する必要があります。 レイヤー より細かく分けていく方法がありますが、この記事では導入だけ触れたいので、３つのレイヤーのみ説明します。 です。この流れは上（app）に向かえば向かうほどアプリケーション固有、下（shared）に向かうほど汎用的になります。 原則として上位レイヤーは下位レイヤーを利用できるが、下位レイヤーから上位レイヤーへ依存できません。 始め方としては小さく初めて、必要になったらレイヤーを増やしてくようです。 スライス ブログアプリであればレイヤーの pages には といったページに分けられるため、このような構成になります。このblog-list, blog-detail, user がスライスです。これらはページやエンティティによって分けられます。 セグメント これらのmodel, ui といった部分がエンティティです。これらは責務にあたります。sharedに関しては直下にスライスではなくセグメントが入ります。 FSD 2.1 で重要なのは Pages First です。とにかくPagesから作って、細分化の必要ができたら、下位レイヤーに抽出します。 Steiger Steiger とはアーキテクチャリンターです。以下でインストールできます。 AIコーディングのために Claude Skills https://github.com/feature-sliced/skills?utm_source=chatgpt.com このリポジトリが公式に公開されています。 これで Skills を追加できるので、claude にFSDの設計知識を共有できます。

フロントエンドのアーキテクチャについて最初から考える

これは何？ この記事は基本に立ち戻りアーキテクチャの選定を試みた際の備忘録です。Feature-Sliced Design（FSD）や Vertical Slice Architecture など、モダンなアーキテクチャがありますが、どのような判断をもとに選定するのかを考え直します。 アーキテクチャの地図 アーキテクチャを理解するために、以下のような学習のための地図を作りました。設計原則、アーキテクチャ、個別の設計パターンへと詳細になっていきます。 そもそも、、、 このコードは何を担当しているのかを考えるのが最初の問です。 商品一覧画面を作るときに といったタスクを書き出します。 これら全てを一つの巨大なコンポーネントとして作ることもできますが、管理が大変になるのは皆さんもお分かりだと思います。参考：https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html?utm_source=chatgpt.com ここからどこまでを同じモジュールとして管理するのか？という設計の問題が始まります。 Cohesion と Coupling CohesionとCouplingはそれぞれ、凝集度、結合度というようです。https://qiita.com/dsudo/items/ee3fee1f558c7f1b359f Cohesionは関係するコードがまとまっているか？ Couplingは別のコードにどれだけ依存しているか？ です。 例えば以下のようなコードがあります。 技術的な種類ごとに整理されていますが、商品一覧のコーディングをするのにそれぞれ別のディレクトリを行き来する必要があります。一方で、以下のように書いた場合はどうでしょうか？ この書き方なら、商品に依存するコードがまとまっています。 この書き方が Feature-based Architecture, Vertical Slice Architecture に繋がっていきます。 コロケーションについて colocation Place code as close to where it’s relevant as possible 同じ種類のコードを集めることではなく、一緒に変更されるコードを近くに置くことです。 https://kentcdodds.com/blog/colocation?utm_source=chatgpt.com Layered Architecture について ここからアーキテクチャの話です。 Layered Architectureでは、技術的責務でアプリケーションを分離します。 これのメリットは責務がわかりやすいところです。 しかし、この方法では前述までとは変わり、機能を変更するときに、横断して変更する可能性があります。 つまり、技術的には分かれている一方で、機能は複数に分散するわけです。 […]

【WSL入門】Ubuntu on WSL2 に開発ツールを一式そろえる — Git / nvm / pnpm / AWS CLI / Terraform

前回の記事では、Windows に WSL2 を導入して Ubuntu が動くところまでを扱いました。ただ、素の Ubuntu はあくまで「まっさらな Linux」です。ここから実際に開発を始めるには、バージョン管理・ランタイム・クラウド操作のツールを自分で入れていく必要があります。 この記事では、すべて公式ドキュメントに載っている手順だけを使って、次のツールを順番にセットアップします。 各セクションの末尾に出典 URL を置いてあるので、手順が古くなったと感じたらそこを見に行ってください。記事末尾には出典一覧もまとめています。 検証環境Windows 11 / WSL2 / Ubuntu 24.04 LTS（x86_64）確認日：2026年7月28日 バージョン番号は執筆時点のものです。インストールコマンド自体は基本的に「常に最新を取ってくる」形になっているので、そのまま実行して問題ありません。 はじめに：WSL開発の大原則 コマンドに入る前に、ひとつだけ。Microsoft の公式ドキュメントが繰り返し書いている重要な原則があります。 使う予定のツールと同じ OS 側にファイルを置く。Linux ツールで Linux コマンドラインから作業しているなら、最速のパフォーマンスを出すためにファイルは WSL ファイルシステムに格納します。 具体的には、プロジェクトは次の場所に置きます。 /mnt/c/ 配下はファイルシステムをまたぐため、npm install や git status が体感でわかるほど遅くなります。第2弾でこれから入れるツールも、すべて Linux 側のホームディレクトリを前提に使ってください。 出典：WSL 開発環境を設定する — Microsoft Learn 1. まずは基本ツール Ubuntu を起動したら、最初にやることはパッケージの更新です。Microsoft の公式ドキュメントにもこう書かれています。 ディストリビューションの優先パッケージ マネージャーを使用して、パッケージを定期的に更新およびアップグレードすることをお勧めします。Windows […]