カテゴリー: tech

  • 「反応しない練習」を開発チームのリーダー視点で実践|問題解決のためのヒント

    「反応しない練習」を開発チームのリーダー視点で実践|問題解決のためのヒント

    【はじめに】

    開発チームのリーダーとして、技術的な問題だけでなく、チーム内のコミュニケーションや感情的な衝突に対処する場面が多くあります。「反応しない練習」で紹介されている考え方は、そうした日々のストレスや複雑な状況に冷静に対応するための実践的なヒントを提供してくれます。本記事では、リーダーの視点からどのように「反応しない練習」を活用できるかを、具体的なシチュエーションを交えながら整理して解説します。また、これらの教えの背景にあるブッダの考え方についても触れます。


    2. 想定されるシチュエーションと課題

    シチュエーション1:進捗が遅れるメンバーへの苛立ち
    • 課題:進捗が遅れているメンバーに対して感情的に指摘すると、モチベーションが低下したり、関係が悪化したりするリスクがある。
    • 対処法
      • 感情を一呼吸置いて客観視する(「無駄な感情を捨てる」)。
      • 遅延の理由を事実ベースで聞き出し、建設的に解決策を探る。
    • ブッダの教え:「執着から解放される」
      感情の根底にある「期待」という執着を手放すことで、冷静に対処できる。
    • 結果:信頼関係を維持しつつ、チーム全体で問題解決に向けた行動を取れる。

    シチュエーション2:意見の衝突が起きた時のファシリテーション
    • 課題:メンバー間の意見の食い違いが感情的な衝突に発展し、プロジェクト全体に悪影響を与える可能性がある。
    • 対処法
      • 一旦その場を落ち着かせ、双方が冷静になる時間を設ける。
      • 意見を事実ベースで整理し、解決策をデータに基づいて導き出す。
      • 相手の反応や結果に過剰に期待しない態度を保つ。
    • ブッダの教え:「無我(自己を抑える)」
      自分の意見や立場に固執せず、プロジェクト全体の利益に集中する。
    • 結果
      感情の衝突を抑え、冷静な議論を行うことでチームの方向性を一致させる。

    シチュエーション3:上司からの無理な要求への対応
    • 課題:短納期や仕様変更の要求に対し、感情的に反発すると信頼関係を損なうリスクがある。
    • 対処法
      • 要求を即座に否定せず、意図や背景を冷静に尋ねる。
      • チームが可能な範囲を提案しつつ、柔軟な姿勢を見せる。
    • ブッダの教え:「四諦(問題を認識し、その原因と解決方法を探る)」
      苦(要求)をそのまま拒否するのではなく、原因を理解して解決策を模索する。
    • 結果
      上司との信頼関係を維持しつつ、現実的な解決策を提示できる。

    3. 「反応しない練習」をブッダの教えと結びつけて理解する

    草薙龍瞬さんの「反応しない練習」は、仏教の根本的な考え方をベースに、現代における具体的な実践方法を提示しています。以下の教えが開発現場でも特に役立つでしょう。

    • 執着を手放す:「こうでなければならない」という思いを捨てることで、柔軟な対応が可能になる。
    • 無我の実践:個人の感情や欲求を超えて、チーム全体の利益を最優先に考える。
    • 四諦のプロセス:課題を「あるがまま」に見つめ、その原因を探り、実行可能な解決策を実践する。

    これらの教えを意識することで、リーダー自身が冷静であり続け、チームを適切に導くことができるようになります。


    4. 注意すべきポイント

    • 感情を抑えすぎない
      無理に感情を抑えると、ストレスが蓄積し逆効果になることも。適切に発散する場を設けることが重要です。
    • 共感を失わない
      感情的な反応を抑えることが冷淡に見える場合があります。相手の話をしっかり聞き、共感を示すことでバランスを保つことが大切です。
    • 完璧を求めない
      仏教の教えも実践が難しいもの。少しずつ取り入れる意識が長期的な変化をもたらします。

    【まとめ】

    「反応しない練習」は、開発チームのリーダーとして冷静さと柔軟性を発揮するための優れたガイドブックです。ブッダの教えを背景にしたこれらの実践方法は、チームの課題解決や信頼関係の強化に大いに役立つと思います。

  • Next.js ミドルウェアでの matcher の役割と動作を解説

    Next.js ミドルウェアでの matcher の役割と動作を解説

    Next.js でミドルウェアを活用するとき、config オブジェクトの matcher プロパティが重要な役割を果たします。本記事では、この matcher の仕組みや、withAuth と組み合わせた場合の動作について、初心者にもわかりやすく解説します。また、NextAuthMiddlewareOptions を参考に、withAuth の具体的な挙動についても触れていきます。


    middleware.tsmatcher の基本動作

    Next.js の middleware.ts は、リクエストがサーバーに到達する前に実行される特別な処理を記述する場所です。
    config.matcher プロパティを設定することで、どのリクエストにミドルウェアを適用するかを制御できます。

    例として、以下の設定を見てみましょう:

    export const config = {
    matcher: ['/dashboard/:path', '/editor/:path', '/login', '/register'],
    }
    • matcher で指定されたパスのみ対象
      この例では、/dashboard/:path, /editor/:path, /login, /register にリクエストが送られた場合のみ、ミドルウェアが実行されます。
    • matcher に指定されていないパスは対象外
      /about/api/data など、matcher に含まれていないパスはミドルウェアをスキップし、直接リクエストが処理されます。

    withAuth の動作と authorized コールバック

    NextAuth.js の withAuth を利用すると、認証状態に基づいてリクエストを制御できます。このとき、authorized コールバックが重要な役割を果たします。

    基本例

    以下は、特定の条件でリクエストを制限する例です:

    export default withAuth({
    callbacks: {
    authorized: ({ token }) => !!token, // JWT トークンが存在すればアクセス許可
    },
    });
    • authorized コールバック
      authorized は、リクエストを許可するかどうかを決定する関数です。この関数が true を返すと、リクエストがそのまま進行します。false を返す場合、認証ページ(デフォルトでは /api/auth/signin)にリダイレクトされます。
    • トークンの検証
      authorized: ({ token }) => !!token では、トークンが存在する場合に true を返しています。つまり、認証済みのリクエストだけが許可されます。

    matcher が動作に与える影響

    matcher は、ミドルウェアを実行するリクエストを選別するため、認証が必要なページや不要なページを効率よく制御できます。

    認証前後のページに matcher を設定する理由

    1. 認証前のページ (/login, /register)
      認証済みユーザーがこれらのページにアクセスした場合、再度ログインフォームを表示するのは不自然です。ミドルウェアで /dashboard にリダイレクトすることで、自然な動作を実現します。
    2. 認証後のページ (/dashboard, /editor)
      未認証ユーザーがこれらのページにアクセスすると、セキュリティ的に問題があります。ミドルウェアで /login にリダイレクトすることで、アクセス制限を確実にします。

    matcher を使った効率的な制御

    matcher を設定することで、ミドルウェアを適用する範囲を必要最小限に抑えることができます。

    • パフォーマンス向上
      不要なリクエストにミドルウェアを適用しないため、処理が軽くなります。
    • 意図した動作の保証
      /api_next/static など、認証と無関係なリソースに影響を与えないため、予期せぬエラーが減ります。

    実例: middleware.ts 全体のコード

    以下は、認証ページと認証後ページを適切に制御するミドルウェアの例です:

    import { withAuth } from 'next-auth/middleware';
    import { NextResponse } from 'next/server';

    export default withAuth(
    async function middleware(req) {
    const { pathname } = req.nextUrl;

    // 認証済みのトークンを取得
    const token = await getToken({ req });

    const isAuth = !!token;
    const isAuthPage = pathname.startsWith('/login') || pathname.startsWith('/register');

    // 認証済みのユーザーがログインページにアクセスした場合
    if (isAuthPage && isAuth) {
    return NextResponse.redirect(new URL('/dashboard', req.url));
    }

    // 未認証ユーザーが保護されたページにアクセスした場合
    if (!isAuth && !isAuthPage) {
    return NextResponse.redirect(new URL('/login', req.url));
    }
    },
    {
    callbacks: {
    authorized: ({ token }) => !!token, // 認証済みかどうかをチェック
    },
    }
    );

    export const config = {
    matcher: ['/dashboard/:path', '/editor/:path', '/login', '/register'],
    };

    まとめ

    matcher は、ミドルウェアを効率的に適用するためのフィルターです。特定のパスにのみ認証ロジックを適用することで、不要な処理を減らし、意図した動作を保証できます。

    • 認証前のページを含める理由:認証済みユーザーが不要なログインページを見ないようにするため。
    • 認証後のページを含める理由:未認証ユーザーがアクセスできないようにするため。

    これを活用することで、Next.js アプリケーションの認証機能を安全かつ効率的に構築できます。

  • VSCodeでPrettierを使った自動フォーマット設定:完全ガイド【2024年版】

    VSCodeでPrettierを使った自動フォーマット設定:完全ガイド【2024年版】

    はじめに

    「コードレビューでインデントの指摘ばかり…」「チーム内でコーディングスタイルがバラバラ…」こんな経験はありませんか? 本記事では、VSCodeでPrettierを使用した自動フォーマット設定について、初心者にもわかりやすく解説します。

    自動フォーマットが必要な理由

    コードの自動フォーマットには、以下のようなメリットがあります:

    • チーム内でコーディングスタイルを統一できる
    • コードレビューで本質的な議論に集中できる
    • 開発効率が向上する
    • コードの可読性が向上する

    必要な準備

    1. VSCodeのインストール

    まだVSCodeをインストールしていない場合は、公式サイトからダウンロードしてください。

    2. Prettier拡張機能のインストール

    1. VSCodeを開く
    2. 左サイドバーの拡張機能アイコンをクリック
    3. 検索バーで「Prettier – Code formatter」を検索
    4. インストールボタンをクリック

    設定手順

    1. プロジェクトにPrettierをインストール

    # npmの場合
    npm install --save-dev prettier

    # yarnの場合
    yarn add -D prettier

    2. 設定ファイルの作成

    プロジェクトのルートディレクトリに.prettierrcファイルを作成し、以下の内容を追加します:

    {
    "semi": false,
    "singleQuote": true,
    "tabWidth": 2,
    "trailingComma": "es5",
    "printWidth": 100,
    "arrowParens": "avoid",
    "endOfLine": "lf"
    }

    3. VSCode設定の追加

    1. プロジェクトのルートディレクトリに.vscodeフォルダを作成
    2. .vscodeフォルダ内にsettings.jsonファイルを作成
    3. 以下の設定を追加:
    {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
    }

    トラブルシューティング

    よくある問題と解決方法

    1. 自動フォーマットが機能しない
      • Prettier拡張機能が正しくインストールされているか確認
      • .prettierrcファイルの構文が正しいか確認
      • VSCodeを再起動
    2. 特定のファイルでフォーマットが効かない
    3. エラーメッセージが表示される
      • .prettierrcファイルにコメントや不要な内容が含まれていないか確認
      • JSON形式が正しいか確認

    応用設定

    ESLintとの併用

    ESLintも使用している場合は、以下の設定を追加することで、保存時にESLintの自動修正も実行できます:

    {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
    }
    }

    カスタム設定例

    プロジェクトの要件に応じて、.prettierrcの設定をカスタマイズできます:

    {
    "semi": true, // セミコロンを強制
    "tabWidth": 4, // インデントを4スペースに
    "printWidth": 120, // 1行の最大文字数を120に
    "useTabs": true, // スペースの代わりにタブを使用
    "bracketSpacing": false // オブジェクトリテラルの括弧内のスペースを削除
    }

    まとめ

    本記事では、VSCodeでPrettierを使用した自動フォーマット設定について解説しました。主なポイントは:

    1. Prettier拡張機能のインストール
    2. .prettierrcファイルでの基本設定
    3. .vscode/settings.jsonでのVSCode設定
    4. ESLintとの連携方法

    これらの設定を行うことで、効率的な開発環境を構築できます。

    参考リンク

    キーワード

    #VSCode #Prettier #JavaScript #TypeScript #開発環境設定 #自動フォーマット #コーディング規約 #フロントエンド開発 #Web開発 #プログラミング

  • Certbotで証明書更新時にドメイン変更によるエラーが発生した場合の対処法

    Certbotで証明書更新時にドメイン変更によるエラーが発生した場合の対処法

    問題の概要

    Certbotを使用して SSL/TLS 証明書を管理している際、ドメインを変更した後に以下のようなエラーが発生することがあります:

    [root@server ~]# /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"
    Renewal configuration file /etc/letsencrypt/renewal/old-domain.example.com.conf is broken.
    The error was: target /etc/letsencrypt/archive/old-domain.example.com/cert3.pem of symlink /etc/letsencrypt/live/old-domain.example.com/cert.pem does not exist
    Skipping.
    0 renew failure(s), 1 parse failure(s)
    

    この問題は、新しいドメインで証明書を作成したにもかかわらず、古いドメインの更新設定ファイルが残っているために発生します。

    解決方法

    以下の手順で問題を解決できます:

    古い証明書の設定ファイルを削除します:

    sudo rm /etc/letsencrypt/renewal/old-domain.example.com.conf

    古い証明書のアーカイブとライブデータを削除します:

    sudo rm -rf /etc/letsencrypt/archive/old-domain.example.com
    sudo rm -rf /etc/letsencrypt/live/old-domain.example.com

    certbotの更新をドライランで実行し、新しい証明書の設定が正しく機能することを確認します:

    sudo certbot renew --dry-run

    問題なく動作することを確認したら、実際の更新を実行します:

    sudo /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"

    注意点

    • 証明書や設定ファイルを削除する前に、重要なデータのバックアップを取ることをお勧めします。
    • 新しいドメインの証明書が正しく作成され、Nginxの設定で使用されていることを確認してください。
    • この操作を行うと、古いドメインの証明書は完全に削除されます。もし古いドメインもまだ使用している場合は、別途証明書を取得する必要があります。

    以上の手順により、Certbotによる証明書の自動更新が新しいドメインに対して正しく機能するようになります。

  • サブモジュールによるGitリポジトリの引っ越しトラブルとその解決方法

    サブモジュールによるGitリポジトリの引っ越しトラブルとその解決方法

    概要

    Gitリポジトリの移行を行う際、サブモジュールに関する問題が発生することがあります。今回、別のリポジトリへ引っ越しを行った際に「Subproject commit 03311a1」のようなメッセージがpush後に表示され、期待していたファイルがリポジトリに含まれていないというトラブルに遭遇しました。

    本記事では、サブモジュール関連の問題を解決する手順を詳しく解説します。サブモジュールの取り扱いや、リポジトリ移行時のトラブル解決に役立つ知識を提供します。

    サブモジュールとは?

    Gitサブモジュールとは、あるGitリポジトリの中に、別のGitリポジトリをリンクさせる仕組みです。サブモジュールを使用することで、1つのリポジトリの中で複数のプロジェクトや依存関係を管理できます。

    たとえば、メインプロジェクトの中に、依存するライブラリやモジュールを外部リポジトリとして含めたい場合にサブモジュールが利用されます。

    サブモジュールの管理には .gitmodules という設定ファイルが使われ、サブモジュールの参照先やパスがここに記録されます。しかし、これがリポジトリの移行時に思わぬ問題を引き起こすことがあります。

    今回の問題の原因

    今回の問題は、リポジトリ移行時にサブモジュールを適切に処理しなかったために発生しました。具体的には、以下の操作を行った後に問題が起きました。

    find ./ -name .git
    rm -rf ./product-server/.git ./product-infrastructure/.git ./product-client/.git

    .gitディレクトリを削除することで、サブモジュールの追跡情報が失われた状態になり、Gitはサブモジュールをコミットする代わりに、サブモジュールの参照(SHA-1ハッシュ)だけを記録しました。その結果、pushした際に「Subproject commit …」のメッセージが表示され、ファイル自体がリポジトリに含まれない事態が発生したのです。

    具体的な解決手順

    サブモジュールが原因でリポジトリにファイルが含まれない場合、以下の手順で解決できます。

    1. サブモジュールの確認

    まず、サブモジュールのパスや参照を確認する必要があります。

    git ls-files --stage
    

    これにより、サブモジュールが存在する場合、その参照情報(160000)が表示されます。以下は出力例です。

    160000 03311a1 0	product-server
    

    160000 はサブモジュールを示しており、サブモジュールのパスが product-server であることがわかります。

    2. サブモジュールの解除

    サブモジュールを通常のディレクトリとして扱うためには、サブモジュールの参照を解除します。

    # サブモジュールの解除
    git rm --cached product-server
    
    # サブモジュールの実体を削除
    rm -rf product-server/.git
    
    # コミットとpush
    git add .
    git commit -m "Remove submodule and add product-server as regular directory"
    git push origin main
    

    この手順をサブモジュールごとに繰り返します。

    3. .gitmodules の確認と削除

    サブモジュールが定義されている場合、.gitmodules ファイルも存在する可能性があります。このファイルを削除する必要がある場合があります。

    rm .gitmodules
    git add .
    git commit -m "Remove .gitmodules"
    git push origin main
    

    これでサブモジュールの参照は解除され、通常のディレクトリとしてリポジトリに追加されます。

    解決までのまとめ

    今回のケースでは、サブモジュールがリポジトリ移行の際に適切に扱われなかったため、サブモジュールの参照だけが残り、実際のファイルがpushされないという問題が発生しました。この問題を解決するためには、以下の手順が必要でした。

    1. サブモジュールの参照を確認git ls-files --stage で確認。
    2. サブモジュールの解除git rm --cached <サブモジュール名> で解除。
    3. 通常のディレクトリとして追加.git フォルダを削除し、再コミット。

    これらのステップを踏むことで、サブモジュールを含むリポジトリの引っ越しを無事に完了させることができました。

  • Amazon ECS Exec チェッカーを使用してもログインできない場合の対処

    Amazon ECS Exec チェッカーを使用してもログインできない場合の対処

    はじめに

    Amazon ECS(Elastic Container Service)は、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを簡素化するためのサービスです。しかし、ECS Exec機能を利用してコンテナにアクセスする際に、想定通りに動作しない場合があります。本記事では、Amazon ECS Exec チェッカーを使用しても異常が見られなかったが、依然としてログインできない場合の対処法について解説します。

    調査したこと

    以下の手順に従って、Amazon ECS Exec チェッカーを使用してテストを行いました。実行結果は以下の通りです。

    https://github.com/aws-containers/amazon-ecs-exec-checker

    $ ./check-ecs-exec.sh $cluster $task

    -------------------------------------------------------------
    Prerequisites for check-ecs-exec.sh v0.7
    -------------------------------------------------------------
    jq | OK (/usr/local/bin/jq)
    AWS CLI | OK ([xx]/aws)

    -------------------------------------------------------------
    Prerequisites for the AWS CLI to use ECS Exec
    -------------------------------------------------------------
    AWS CLI Version | OK (aws-cli/1.22.7 Python/3.7.2 Darwin/23.4.0 botocore/1.23.7)
    Session Manager Plugin | OK (1.2.463.0)

    -------------------------------------------------------------
    Checks on ECS task and other resources
    -------------------------------------------------------------
    Region : [xxx]
    Cluster: [xxx]
    Task : [xxx]
    -------------------------------------------------------------
    Cluster Configuration | Audit Logging Not Configured
    Can I ExecuteCommand? | [xxx]
    ecs:ExecuteCommand: allowed
    ssm:StartSession denied?: allowed
    Task Status | RUNNING
    Launch Type | Fargate
    Platform Version | 1.4.0
    Exec Enabled for Task | OK
    Container-Level Checks |
    ----------
    Managed Agent Status
    ----------
    1. RUNNING for "postfix"
    2. RUNNING for "http"
    3. RUNNING for "composer"
    4. RUNNING for "log-router"
    ----------
    Init Process Enabled ([xxx]:241)
    ----------
    1. Enabled - "http"
    2. Enabled - "composer"
    3. Enabled - "postfix"
    4. Disabled - "log-router"
    ----------
    Read-Only Root Filesystem ([xxx]:241)
    ----------
    1. Disabled - "http"
    2. Disabled - "composer"
    3. Disabled - "postfix"
    4. Disabled - "log-router"
    Task Role Permissions | [xxx]
    ssmmessages:CreateControlChannel: allowed
    ssmmessages:CreateDataChannel: allowed
    ssmmessages:OpenControlChannel: allowed
    ssmmessages:OpenDataChannel: allowed
    VPC Endpoints | SKIPPED ([xxx] - No additional VPC endpoints required)
    Environment Variables | ([xxx]:241)
    1. container "http"
    - AWS_ACCESS_KEY: not defined
    - AWS_ACCESS_KEY_ID: not defined
    - AWS_SECRET_ACCESS_KEY: not defined
    2. container "composer"
    - AWS_ACCESS_KEY: not defined
    - AWS_ACCESS_KEY_ID: not defined
    - AWS_SECRET_ACCESS_KEY: not defined
    3. container "postfix"
    - AWS_ACCESS_KEY: not defined
    - AWS_ACCESS_KEY_ID: not defined
    - AWS_SECRET_ACCESS_KEY: not defined
    4. container "log-router"
    - AWS_ACCESS_KEY: not defined
    - AWS_ACCESS_KEY_ID: not defined
    - AWS_SECRET_ACCESS_KEY: not defined

    上記の結果より、Amazon ECS Exec チェッカーを使用しても異常は見られませんでした。

    すべてのチェックが問題なくパスしていることが確認できました。

    結論と対処法

    Amazon ECS Exec チェッカーを使用しても異常が見られなかったにもかかわらず、依然としてECS Execを利用してコンテナにログインできない原因は、タスク定義における pidModetask に設定されているためであると判断しました。

    pidMode の設定変更

    pidModetask から container に変更することで、この問題を解決できます。以下の手順で設定を変更してください:

    1. タスク定義の確認と編集: AWSコンソールまたはAWS CLIを使用して、問題のタスク定義を確認します。タスク定義のJSON内でpidModetaskに設定されている箇所を見つけ、該当行を削除


    2. タスクの再デプロイ: タスク定義を更新後、新しいタスク定義を使用してタスクを再デプロイします。これにより、更新された設定が適用されます。
    3. ECS Execの再試行: 設定変更後、再度ECS Execを試行して、コンテナへのアクセスが可能か確認します。

    参考情報

    https://github.com/aws/containers-roadmap/issues/2268

    まとめ

    Amazon ECS Exec チェッカーを使用しても異常が見られない場合でも、タスク定義の設定によってはECS Execが正常に動作しないことがあります。特にpidModeの設定に注意が必要です。本記事が、ECS Execのトラブルシューティングに役立つことを願っています。

  • Go 開発環境: GOROOT、GOPATH、および VSCode 設定の理解

    Go 開発環境: GOROOT、GOPATH、および VSCode 設定の理解

    Go の開発環境を設定する際に、特に VSCode や asdf を使用する場合は、GOROOTGOPATH の役割を理解し、正しく設定することが重要です。
    この記事では、これらのコンポーネントとその関係を整理し、スムーズな開発環境を実現するための設定方法を説明します。

    GOROOT: Go のインストールディレクトリ

    定義: GOROOT は、Go がインストールされているディレクトリを指す環境変数です。Go のバイナリ、標準ライブラリのソースコード、およびコンパイラツールが含まれています。

    目的: GOROOT は Go のツールチェーンに対して、コアライブラリやバイナリの場所を教える役割を果たします。Go をインストールすると自動的に設定されるため、通常は変更する必要はありません。ただし、複数の Go バージョンをインストールしている場合は設定が必要です。

    :

    • asdf を使って Go のバージョン 1.22.1 をインストールした場合、GOROOT は次のようになります。

      /Users/your.name/.asdf/installs/golang/1.22.1/go

    GOPATH: ワークスペースディレクトリ

    定義: GOPATH は、Go のコード、依存関係、およびバイナリが保存されるワークスペースのルートを指定する環境変数です。

    目的: GOPATH は、Go のツールチェーンに対してプロジェクトのソースコードやサードパーティパッケージのインストール場所を教えます。GOROOT とは異なり、GOPATH は任意のディレクトリに設定できます。

    :

    • 一般的な GOPATH の設定は次のようになります。

      /Users/your.name/go

    VSCode 設定: GOROOT と GOPATH の設定

    VSCode を使用して Go の開発を行う場合、エディタに対して Go のインストール場所(GOROOT)とワークスペース(GOPATH)を知らせる設定が必要です。

    VSCode 設定:

    • go.goroot: この設定は VSCode に Go のインストール場所を教えます。asdf が管理する Go のインストールパス内の go ディレクトリを指す必要があります。
    • go.gopath: この設定は VSCode に Go のワークスペースの場所を教えます。GOPATH に設定したディレクトリを指します。

    設定例:

    { "go.gopath": "/Users/your.name/go", "go.goroot": "/Users/your.name/.asdf/installs/golang/1.22.1/go" }

    なぜ GOROOT と GOPATH は異なるパスなのか?

    GOROOTGOPATH は異なる目的を持つため、別々のパスを設定する必要があります。

    • GOROOT は Go のインストール自体を指します。Go コンパイラ、標準ライブラリ、ツールチェーンが含まれています。
    • GOPATH は個人の Go ワークスペースを指します。プロジェクトのソースコード、ダウンロードした依存関係、ビルドしたバイナリが含まれます。

    asdf を使用すると、複数の Go バージョンを管理できますが、それぞれのバージョンに対して GOROOT が異なります。一方、GOPATH は一貫して個人のワークスペースを指します。

    実際の設定例: 環境のセットアップ

    1. Go のインストール(asdf を使用):
      asdf install golang 1.22.1
      asdf global golang 1.22.1
    2. 環境変数の設定: シェルの設定ファイル(~/.bashrc, ~/.zshrc など)に以下を追加します。

      export GOROOT=$HOME/.asdf/installs/golang/1.22.1/go export GOPATH=$HOME/go export PATH=$GOROOT/bin:$PATH
    3. VSCode の設定: settings.json を開き、次の設定を追加します。

      { "go.gopath": "/Users/your.name/go", "go.goroot": "/Users/your.name/.asdf/installs/golang/1.22.1/go" }

    結論

    GOROOTGOPATH の違いと、それを VSCode に設定する方法を理解することは、スムーズな Go 開発環境を構築するために非常に重要です。これらのパスを正しく設定することで、Go のツールやエディタが必要なファイルや依存関係を正しく見つけることができ、設定に関連するエラーのリスクを減らすことができます。

    詳細については、公式の Go ドキュメント「Go 開発環境のセットアップ」を参照してください。

  • Dockerを使ってMySQL 8.0をパスワードなしでローカル接続する

    Dockerを使ってMySQL 8.0をパスワードなしでローカル接続する

    以下の手順で、MySQL 8.0をDockerで起動し、パスワードなしでローカル接続できるように設定する方法を説明します。

    手順 1: Dockerコンテナの起動

    まず、パスワードなしでMySQLコンテナを起動します。MYSQL_ALLOW_EMPTY_PASSWORD環境変数をyesに設定します。

    docker run --name mysql -e MYSQL_ALLOW_EMPTY_PASSWORD=yes -d -p 3306:3306 mysql:8.0

    このコマンドは、以下のことを行います:

    1. mysqlという名前のコンテナを作成
    2. MySQLのルートユーザーのパスワードを空に設定
    3. コンテナをバックグラウンドで実行
    4. ローカルの3306ポートをコンテナの3306ポートにマッピング

    手順 2: MySQLクライアントで接続

    次に、ローカルのMySQLクライアントを使ってMySQLサーバーに接続します。パスワードなしで接続するために、-pオプションを省略します。

    mysql -h 127.0.0.1 -P 3306 -u root

    注: mysql のコンテナが立ち上がるまでの間

    ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 2

    というエラーが表示されます。その際数秒待って再度接続を試みてください。

    トラブルシューティング

    コンテナが正しく起動しているか確認:

    docker ps -a

    コンテナのログを確認:

    docker logs mysql

    MySQLサーバーが正しく起動していない場合、ログを確認してエラーメッセージをチェックし、適切な対策を講じてください。

  • ローカル環境でHTTPSサーバーを立ち上げる

    ローカル環境でHTTPSサーバーを立ち上げる

    OpenSSLとNode.jsの http-server モジュールを使って、ローカル環境でHTTPSサーバーを立ち上げる方法を説明。

    Subject Alternative Name (SAN) を設定する

    vim SAN.txt
    ---
    subjectAltName = DNS:sumito.jp
    

    この手順では、SANを指定するためのファイル SAN.txt を作成します。ここでは sumito.jp をSANとして指定していますが、適宜変更してください。

    秘密鍵と証明書の作成

    openssl genrsa -out server.key 2048
    openssl req -out server.csr -key server.key -new
    openssl x509 -req -days 3650 -signkey server.key -in server.csr -out server.crt -extfile SAN.txt
    

    この一連のコマンドで、2048ビットの秘密鍵 server.key と、その秘密鍵に基づく証明書署名リクエスト(CSR) server.csr を作成します。最後に、CSRと秘密鍵から、有効期限3650日の自己署名証明書 server.crt を作成しています。この際、先ほど作成した SAN.txt ファイルを使ってSANを設定しています。

    HTTPSサーバーの起動

    http-server -S -C server.crt -K server.key -p 443
    

    最後に、http-server コマンドを実行して、HTTPSサーバーを起動します。このコマンドでは、作成した server.crtserver.key を指定し、ポート443でリッスンするように指定しています。

    hosts に以下の通り記載します

    127.0.0.1       sumito.jp
    

    これで、ローカル環境でHTTPSサーバーが立ち上がりました。ブラウザで https://sumito.jp/ にアクセスすると、自己署名証明書の警告が出る場合がありますが、それを無視して進めばウェブサーバーにアクセスできます。

    注意点として、この方法で作成した証明書は自己署名なので、実際の運用環境では使えません。

    本番環境で使う場合は、認証局から発行された適切な証明書を取得する必要があります

  • Shell でjsonの配列の変数から value を抜き出す

    Shell でjsonの配列の変数から value を抜き出す

    キーが固定の場合

    以下は、シェルスクリプトでJSONデータを読み込み、jqコマンドを使用して同様の処理を行う例です。

    #!/bin/bash
    
    json='[{"name":"Worker","no":"123"}, {"name":"User","no":"456"}, {"name":"Organization","no":"789"}, {"name": "Position","no":"123"}, {"name": "PositionTranslation","no":"123"}]'
    
    echo "$json" | jq -c '.[]' | while read -r item; do
      name=$(echo "$item" | jq -r '.name')
      no=$(echo "$item" | jq -r '.no')
      
      echo "$name"
      echo "$no"
      echo "-----"
    done

    このスクリプトでは:

    1. json変数にJSONデータを文字列として格納します。
    2. echo "$json" | jq -c '.[]'を使用して、JSONデータをパイプでjqコマンドに渡し、各オブジェクトを個別の行に分割します。
    3. while read -r itemを使用して、各オブジェクトを1つずつ読み込みます。
    4. echo "$item" | jq -r '.name'echo "$item" | jq -r '.no'を使用して、各オブジェクトからnamenoの値を抽出します。
    5. 抽出した値とセパレーターを表示します。

    結果はこちらです

    Worker
    123
    -----
    User
    456
    -----
    Organization
    789
    -----
    Position
    123
    -----
    PositionTranslation
    123
    -----
    
    

    キーが固定でない場合(接頭辞が共通の場合)

    JSONデータのキーが一部共通している場合、jqコマンドの to_entriesselectmapを組み合わせて目的の値を取得することができます。以下は、public_ip で始まるキーに対応する値を取得する例です。

    #!/bin/bash
    
    json='{"public_ip01": "1.2.3.4", "public_ip02": "2.3.4.5", "public_ip03": "12.2.3.4"}'
    
    echo "$json" | jq -r 'to_entries | map(select(.key | startswith("public_ip")).value)'
    

    このスクリプトでは:

    1. json 変数にJSONデータを文字列として格納します。
    2. echo "$json" | jq -r 'to_entries | map(select(.key | startswith("public_ip")).value)' を使用して、JSONデータを jq コマンドに渡し、以下の処理を行います:
      • to_entries で、JSONオブジェクトをキーと値のペアの配列に変換します。
      • map(select(.key | startswith("public_ip"))) で、キーが "public_ip" で始まるエントリーのみを選択します。
      • .value で、選択されたエントリーの値のみを取得します。
    3. jq の出力は、選択された値の配列になります。

    このスクリプトを実行すると、以下のような結果が得られます

    "1.2.3.4" "2.3.4.5" "12.2.3.4"

    これにより、public_ip で始まるキーに対応する値が取得できました。必要に応じて、この出力を変数に格納したり、ループ処理で個別に処理したりすることができます。