投稿者: sumito.tsukada

【はじめに】

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

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

シチュエーション1：進捗が遅れるメンバーへの苛立ち

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

シチュエーション2：意見の衝突が起きた時のファシリテーション

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

シチュエーション3：上司からの無理な要求への対応

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

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

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

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

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

4. 注意すべきポイント

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

【まとめ】

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

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

middleware.ts と matcher の基本動作

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を使用した自動フォーマット設定について、初心者にもわかりやすく解説します。

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

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

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

必要な準備

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との連携方法

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

参考リンク

• Prettier公式ドキュメント
• VSCode公式ドキュメント

キーワード

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

問題の概要

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による証明書の自動更新が新しいドメインに対して正しく機能するようになります。

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.crt と server.key を指定し、ポート443でリッスンするように指定しています。

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

127.0.0.1       sumito.jp

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

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

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