今回は、ZshとiTerm2の連携機能を使って、この便利機能を設定する方法を解説します。

なぜディレクトリごとにテーマを切り替えるのか？

• 視覚的な区別: 複数のプロジェクトを並行して進めている場合、ターミナルの色が変わることで、今どの環境で作業しているのか一目で分かります。
• 集中力の向上: 特定の作業モードに合わせた色合いにすることで、集中力を高める効果も期待できます。
• 誤操作の防止: 本番環境や重要なディレクトリに入ったときに、警告色にすることで、不用意なコマンド実行を防ぐことができます。

必要なもの

• iTerm2: macOS用の高機能ターミナルエミュレータ
• Zsh: macOSのデフォルトシェル（Bashでも可能ですが、Zshの方が設定が簡単です）

設定手順

設定は大きく分けて2つのステップです。

1. iTerm2で複数のプロファイル（テーマ）を作成する
2. Zshの設定ファイルで、ディレクトリに応じたプロファイル切り替えスクリプトを記述する

ステップ1: iTerm2で複数のプロファイル（テーマ）を作成する

まず、切り替えたいテーマごとにiTerm2のプロファイルを作成します。

1. iTerm2を開き、Cmd + , で設定（Preferences）を開きます。
2. 「Profiles」タブを選択します。
3. 左下の「+」ボタンをクリックして、新しいプロファイルを作成します。
   • 例えば、デフォルトの「Default」プロファイルとは別に、仕事用の「Work Theme」、個人用の「Personal Theme」など、分かりやすい名前を付けましょう。
4. 各プロファイルでテーマを設定します。
   • 作成したプロファイルを選択し、右側の設定を変更します。
   • Colors: 「Color Presets」から好きなカラースキームを選んだり、背景色を調整したりできます。
   • Text: フォントや文字サイズを設定します。
   • Window: 背景画像や透明度を設定することも可能です。

これで、複数のテーマがiTerm2に準備できました。

ステップ2: Zshの設定ファイルで、ディレクトリに応じたプロファイル切り替えスクリプトを記述する

次に、シェルがディレクトリを移動するたびに、iTerm2に「このプロファイルに切り替えて！」と指示を出すスクリプトを記述します。

お使いのZshの設定ファイル（通常は ~/.zshrc）を開いて、以下のコードを追記してください。

# iTerm2のプロファイルを切り替える関数
# この関数は、iTerm2独自の制御シーケンス（OSC 1337;SetProfile）を使ってプロファイルを変更します。
function iterm_set_profile() {
  local profile_name="$1"
  echo -e "\033]1337;SetProfile=${profile_name}\a"
}

# コマンド実行前に呼ばれる関数
# ここで現在のディレクトリ($PWD)をチェックし、適切なプロファイルを呼び出します。
function precmd_iterm_profile_switcher() {
  if [[ "$PWD" == *"/Users/yourname/projects/work"* ]]; then
    # 例: '/Users/yourname/projects/work' ディレクトリ配下なら 'Work Theme' プロファイルに
    iterm_set_profile "Work Theme"
  elif [[ "$PWD" == *"/Users/yourname/documents/personal"* ]]; then
    # 例: '/Users/yourname/documents/personal' ディレクトリ配下なら 'Personal Theme' プロファイルに
    iterm_set_profile "Personal Theme"
  else
    # それ以外のディレクトリでは、デフォルトのプロファイルに戻す
    iterm_set_profile "Default"
  fi
}

# Zshがコマンド実行前にprecmd_iterm_profile_switcher関数を実行するように登録
precmd_functions+=(precmd_iterm_profile_switcher)

【重要】コードをあなたの環境に合わせて修正してください！

• "/Users/yourname/projects/work" や "/Users/yourname/documents/personal" の部分は、あなたがテーマを切り替えたい実際のディレクトリパスに修正してください。
• "Work Theme"、"Personal Theme"、"Default" は、ステップ1であなたがiTerm2で作成したプロファイルの名前に正確に合わせてください。

設定の反映

~/.zshrc に上記のコードを追記したら、ターミナルを再起動するか、以下のコマンドを実行して設定を再読み込みします。

source ~/.zshrc

これで設定は完了です！

動作確認

実際にテーマを切り替えたいディレクトリに cd してみてください。 例えば、/Users/yourname/projects/work ディレクトリに移動すると、「Work Theme」のiTerm2プロファイルが適用され、背景色やフォントが切り替わるはずです。そして、別のディレクトリに移動すると、「Default」テーマに戻るのを確認できるでしょう。

ちょっとしたヒント

• if文の条件を増やすことで、さらに多くのディレクトリやプロジェクトに対して異なるテーマを設定できます。
• *" の部分は、指定したパスがディレクトリ名のどこかに含まれていればマッチするという意味です。より厳密に特定のディレクトリだけを対象にしたい場合は、"$PWD" == "/Users/yourname/exact/path" のように = を使って記述することも可能です。

これで、あなたのiTerm2環境は、さらに快適で視覚的に分かりやすいものになったはずです。ぜひこの機能を活用して、ターミナル作業をより効率的で楽しいものにしてください！

僕は一度もありません。

アプリケーションエンジニアとしてRDBMSは何度も触ってきたのですが、
NoSQLの代表的なサービスを触る機会が実務で出てきたので、ざっくり理解するところまでに至りたいと思い記事を執筆しています。

特徴

フルマネージドのNoSQLデータベース

AWSがインフラの管理を行うため、ユーザーはインフラのメンテナンスを気にせずに使用可能。

自動スケーリングと高いパフォーマンス

読み書きのスループットを自動でスケールさせ、オンデマンドモードではアクセス量に応じたパフォーマンスが提供されます。

高可用性と耐障害性

データは複数のリージョンやアベイラビリティゾーンに分散して保存されるため、障害耐性が高く、可用性が99.999%を実現しています。

柔軟なデータモデル

各アイテムに異なる属性を持たせることができるスキーマレスデザインを採用しており、データ構造の変更が容易です。

トランザクション対応

ACIDトランザクションをサポートしているため、複数のテーブル間で整合性を維持しながらデータを操作できま
(RDBMSと比較すると弱い

ユースケース

アプリケーション

IoTデバイスやモバイルアプリのバックエンド

リアルタイムのデータを扱い、大量のリクエストを処理する必要があるIoTデバイスやモバイルアプリケーションのデータストアとして適しています。

リアルタイムアナリティクス

DynamoDB Streamsを利用して、データ変更を他のシステムでリアルタイムに処理できます。変更があるたびにLambdaで処理するアーキテクチャが一般的です。

ECサイトやソーシャルアプリのセッション管理

DynamoDBの高速な読み書き性能を活かして、ECサイトのセッション管理やソーシャルアプリのユーザー活動データの保存に利用されます。

IaC（Infrastructure as Code: Terraform）

複数環境でのデプロイ

テスト環境・本番環境用のDynamoDBテーブルを、同じコードで異なる環境にデプロイ可能。これにより、環境間の設定の違いを一元管理しやすくなります。

機能

DynamoDB Streams

データの変更をストリームとして記録し、変更イベントに対してリアルタイムでアクション（例：Lambdaを使用した処理）を実行可能です。

セカンダリインデックス

主キー以外の属性を指定してクエリを実行できるようにするための「グローバルセカンダリインデックス(GSI)」と、同一パーティションキーで異なるソートキーを持つ「ローカルセカンダリインデックス(LSI)」があります。

自動スケーリング

読み書きキャパシティのスループットを動的に調整可能で、ピーク時のトラフィックに合わせて自動でスケーリングされます。

バックアップとリカバリ

DynamoDBはオンデマンドバックアップとポイントインタイムリカバリ（PITR）をサポートし、指定された時点にデータを復元できます。

DAX (DynamoDB Accelerator)

キャッシュ機能であるDAXを利用することで、ミリ秒単位の応答が要求されるアプリケーションのパフォーマンスをさらに向上できます。

トランザクション機能

ACID特性を持つトランザクションをサポートしており、一貫性のあるデータ処理が可能です。

RDBMSとの違いまとめ

I`m PHPer!!!!!

便利なstatic

PHPの static メソッドは、インスタンスを生成せずにクラスから直接呼び出せるメソッドです。

使うべきタイミング

状態を持たない処理

インスタンスの状態に依存しない、独立した処理を行う場合に適しています。例えば、ユーティリティ関数やヘルパー関数などがこれに該当します。

class MathHelper {
  public static function add($a, $b) {
    return $a + $b;
  }
}

echo MathHelper::add(3, 4); // 出力: 7

ファクトリーメソッド

クラスのインスタンスを生成するメソッド（ファクトリーメソッド）として使用されることがあります。

この場合、`new`キーワードを隠蔽して、インスタンス化の過程を制御できます。

class User {
  public $name;

  private function __construct($name) {
    $this->name = $name;
  }

  public static function create($name) {
    return new self($name);
  }
}

$user = User::create('John Doe');

あまり使いたくないね。。。

シングルトンパターン

特定のクラスのインスタンスが一つだけ存在することを保証するシングルトンパターンの実装に利用されます。

<?php

class Singleton
{
    private static $instance;

    private function __construct()
    {
// プライベートコンストラクタ
    }

    public static function getInstance()
    {
        if (self::$instance === null) {
            self::$instance = new self();
        }
        return self::$instance;
    }
}

$singleton = Singleton::getInstance();

だめな使い方

インスタンスの状態を操作する処理

インスタンスの状態に依存するメソッドに`static`を使うべきではありません。staticメソッドはクラスレベルで動作するため、インスタンス固有の状態を保持することができません。

class User {
  private $name;

  public static function setName($name) {
    $this->name = $name; // エラー: $thisを使えない
  }
}

過度な使用

全てのメソッドを`static`にすることは避けるべきです。

staticメソッドを多用すると、オブジェクト指向プログラミングの基本原則であるカプセル化や多態性が損なわれる可能性があります。
特に、後からメソッドをオーバーライドする必要が出てきた場合に柔軟性を失います。

依存性注入の回避

staticメソッドは依存性注入と相性が悪く、テストやメンテナンスが難しくなる場合があります。テスト可能なコードを維持するためには、インスタンスメソッドを使用し、必要な依存関係をコンストラクタやセッターで注入する方が望ましいです。

まとめ

static メソッドは、クラス固有の処理やユーティリティ関数として適切に使用することで、コードの構造を明確にし、インスタンス化を不要にするメリットがあります。ただし、過度な使用はオブジェクト指向の原則を損なう可能性があるため、状況に応じて適切に使い分けることが重要です。

今回は、ソフトウェア開発の一環として非常に重要なインフラストラクチャ（以下、インフラ）についてお話ししたいと思います。

多くのプログラマーがコードを書くことに夢中になる一方で、インフラについてはあまり関心を持たないことがあります。
しかし、インフラに興味を持つことは、より強力でスケーラブルなアプリケーションを作成するために不可欠です。

インフラとは？

インフラとは、ソフトウェアが動作するための基盤となるハードウェア、ネットワーク、ストレージ、クラウドサービスなどを指します。これには、サーバーの設定、ネットワークの構築、データベースの管理、スケーリングのためのクラウドサービスの利用などが含まれます。

なぜインフラに興味を持つべきか？

1. パフォーマンスの最適化: インフラの知識があると、アプリケーションのパフォーマンスを最適化するための適切なリソースを選択し、設定することができます。
2. 信頼性の向上: 適切なインフラの設計は、アプリケーションのダウンタイムを最小限に抑え、信頼性を向上させるのに役立ちます。
3. スケーラビリティ: インフラを理解していると、トラフィックの増加に対応できるスケーラブルなアーキテクチャを設計することが可能です。
4. セキュリティの強化: インフラのセキュリティを強化することで、アプリケーションを攻撃から守ることができます。
5. 多角的な課題解決: プログラム以外の手段として、インフラの変更や最適化を考慮することで、課題解決の選択肢が増えます。例えば、コードの最適化だけでなく、サーバーのスケールアップやネットワーク設定の見直しも有効な解決策となります。

具体的に考えてみよう

例えば、あるウェブアプリケーションのパフォーマンスが悪く、ユーザーからのクレームが増えている状況を考えてみましょう。

この場合、最初に考えるのはコードの最適化かもしれません。
効率的なアルゴリズムを使用したり、データベースクエリを最適化することが効果的です。

しかし、これだけが解決策ではありません。

インフラ観点で考えてみましょう。

サーバーのスケールアップ

現在のサーバーがトラフィックに対応しきれていない場合、サーバーのスケールアップ（より強力なサーバーにアップグレード）を検討できます。

これにより、リソース不足によるパフォーマンス低下を防ぐことができます。

例えば、EC2インスタンスのサイズをt3.smallからt3.largeに変更することで、CPUとメモリリソースが増加し、パフォーマンスが向上する可能性があります。

ロードバランシングの導入

トラフィックが特定のサーバーに集中している場合、ロードバランサーを導入することで、トラフィックを複数のサーバーに分散させることができます。これにより、各サーバーの負荷が軽減され、全体のパフォーマンスが向上します。

AWS Application Load Balancer（ALB）を使用して、複数のEC2インスタンス間でトラフィックを分散することで、スケーラビリティと信頼性を向上させることができます。

また、ALBではパスルーティングを設定することが可能なため、重たい処理専用のサーバーで処理をするといったことも考えることができます。

その際にはログイン情報を引き継ぐといったことも考える必要が出てくるため、Redisなどのミドルウェアも視野に入れる必要があります。

サーバーレスの選択

AWS Lambda といったサーバーレスアーキテクチャを選択することも視野に入れると良いです。

サーバーレスを利用することで、サーバーの管理が不要になり、スケーリングも自動で行われます。

（Lambdaには制約があるので注意。この記事わかりやすいよ

キャッシュ戦略

結果をキャッシュサーバーに格納していこうぜぇぇぇ

ネットワーク設定の最適化

ネットワークの設定を見直し、遅延を最小限に抑えるための最適化を行うことも重要です。

例えば、コンテンツデリバリネットワーク（CDN）を使用して、静的コンテンツをユーザーに近い場所から提供することで、応答時間を短縮できます。

CloudFrontを利用して、画像やJavaScriptファイルなどの静的リソースをキャッシュし、グローバルに分散されたエッジロケーションから提供することで、ユーザー体験を向上させることができます。

具体的に何を学ぶべきか？

1. サーバー管理: Linuxの基本的なコマンド、サーバーのセットアップ、SSHの使用方法を学びましょう。
2. クラウドサービス: AWS、Azure、Google Cloudなどの主要なクラウドプロバイダーのサービスについて理解し、使いこなせるようにしましょう。
3. コンテナ技術: DockerやKubernetesなどのコンテナ技術を学ぶことで、アプリケーションのデプロイメントが効率的になります。
4. ネットワークの基礎: IPアドレス、サブネット、DNS、ロードバランシングなどの基本的なネットワーク概念を理解しましょう。
5. インフラストラクチャー・アズ・コード（IaC）: TerraformやCloudFormationを使用して、コードでインフラを管理する方法を学びましょう。

最後に

インフラの知識は、プログラマーにとって非常に有益です。

コードを書くことだけでなく、そのコードが動作する環境について理解することで、より優れたソフトウェアを作成することができます。
さらに、プログラム以外の手段としてインフラを活用することで、課題解決の幅が広がります。ぜひ、インフラに興味を持ち、自身のスキルセットを拡充していきましょう。

このブログが皆さんのインフラへの関心を高めるきっかけとなれば幸いです。次回もお楽しみに！

都内で三流プログラマーとして働いているやんやんです。

世界一流エンジニアの思考法 を自分の中に落とし込む記事を書いています。

本書の紹介

世界一流エンジニアの思考法 (文春e-book)

一流との違い

試行錯誤は悪

分かるようになるまで自分でどうにかする もしくは 質問できるレベルになるまで自分で調べる という形で取り組んできた自分からするとかなり衝撃的だった。

本書では、その試行錯誤の時間は正解を探しているだけで何も新しい知識を学んでいないとなかなかのパンチラインを残している。

何も学んでいない = 次の問題がやってきたときに対処ができないということになるのだろう。

確かにその通りだ。

ログから手当たり次第に試すのではなく、このログがどこでどのように吐かれたのか、依存関係や背景を基に何が原因か考えることができるようになりたい。 ← 凄く難しくないか？

理解に時間をかける

これは日々痛感しているのだが、仕事のできる上司はかなり理解力が高く、コミュニケーションを取ることに対して引け目を感じていた。

本書では、どんなに能力が高い人でも理解に時間がかかることを説明していた。

僕の上司も「今までに〇〇をXXしてきたから」「これはあの時に苦しんだから」と時間なり、それ相応の苦労をしてきたと言っていた。

本書ではビッグテックの現場で出ている体験を基にしているので、世界レベルのエンジニアでも理解することに対して時間がかかるのだろう。

これまでの積み重ねで皆頑張っているんだと何故か共感できた。

小さなドキュメントをコードの前に書く

これは技術レベルに関係なく、すぐ実践できることなので今日から実践していきたい。

今から何を作るのか理解するために小さなドキュメントを書いていく。

• Scope
• Background
• Problem
• Solution

確か、岡田斗司夫も同じようなことを言っていた。

マインドセット

BeLazy

BeLazy = 怠惰 という意味になるが、そのままの意味ではなく、「少ない時間で価値を最大化しなさい」という教えがあった。（プログラマの三大美徳の怠惰と同様の考え方。

これを達成するためが以下のことだと考える。

• やるべきことを絞る
• それ以外はやらない

やるべきことを達成したら、またやるべきことを絞り、、、というサイクルを回して価値を最大化していく。

ビジネスマンである限り、ここで言われていることは目指すべきではあるがそう簡単ではないというのが現実である。

それでも言っていることは正しいと思うので近づけるよう努力したい。

リスクや間違いを受け入れる

これは下記記事の時にいた上層部に届いてほしい。

この当時の会社では案件を頓挫させてしまったが最後、席を追い出される形で最終的に退職することになった。

[getpost id=”1204″ target=”_blank” cat_name=”1″ date=”0″]

話を戻す。

成功へ早く近づくために、失敗を受け入れるマインドを持つ必要がある。

• 早く失敗する
• 失敗から学ぶ

まずはやってみて、そこから学んで次へ進んでいくようにしたい。

炎上案件とは？

何らかの理由でとにかく燃えている案件のことです。

• シンプルな短納期（多分炎上の理由1位）
•  チーム内における重要人物のプロジェクトからの離脱
• 神様（クソ客）による土壇場での仕様変更
• イキり営業による全てできますスタイルによる契約

プロジェクトに関わるすべての人が何かしらに追われている状況になるため、関係者各位で揉め事が起こっています。
ステークホルダー > 営業 > PL > SE > プログラマー

僕が経験した炎上案件では、短納期 + 急な仕様変更（馬鹿な営業のせい） により開発と営業の間で戦争が勃発しプロジェクトが崩壊しかけた事があります。
最終的には客先への調整（謝罪） + 営業と開発の戦争に部長が仲裁する形 で終着することでギリギリのところで丸く収まりました。

しかし一度崩壊しかけたプロジェクトなのでチーム内でのいざこざは残ったまま開発を続けていくことになりストレスの掛かるプロジェクトでした。

このように炎上案件は誰も幸せになりません。

今回は炎上案件について僕の実体験を簡潔にお話したのですが、一口に炎上案件と言っても様々な理由があることを覚えていただければ幸いです。

炎上するとどんな事が起きるのか

お客さんに詰められる

受託企業における一番恐ろしいタイミングがお客様から詰められる時です。
当たり前の話ですが、身銭を切ってシステム開発を依頼されているので、全力で詰めてきます。

お客さんが詰めるときはだいたい以下の理由かと思います。

• 納期に間に合わない
• 契約時に想定していた要件を満たせていない

これらの理由で怒られるのが本当に本当にストレスでした。(契約不履行と言われたときにはゾッとします。

上長から詰められる

お客様から詰められるということは必然的に上司からも詰められます。

お客さんからの評価が悪いと次回の契約や会社の評判が下がるといった悪影響が発生する可能性が高くなるため、上司もピリピリします。

炎上は炎上を生むだけです。

メンバーから不満が出る

他方から詰められるとチーム内からも悲惨な声が聞こえてきます。

「後少しでリリースできるから一緒に頑張りましょう。」という声がけしかできません。

世知辛いです。

炎上したときには死ににいく姿勢が大事

ようやく本題です。

炎上案件に参画すると全員が「この案件から抜け出したい」と願っている事は目に見えるのですが、そういった願いは儚く散っていきます。どうにか納品することが唯一の地獄からの脱出する道です。

全員がギリギリのところで踏ん張っているタイミングでは率先して死にに行く姿勢がメンバーを勇気づけると考えています。

一度プロジェクトを崩壊させた目線から思うことが誰かがアクセルを踏んで頑張ることが誰かの活力につながることを強くお伝えしたいです。

今炎上案件に参画している人はぜひ、死にに行く姿勢を持ってほしいなと思います。（限界だったら逃げてください。本当に逃げてください。）

炎上案件は悪いことばかりではない

精神的にしんどい事が多い炎上案件ですが、悪いことばかりではありません。

サイヤ人の理論と一緒でギリギリのところで生き抜くと確実に成長します。成長するのは技術力かもしれませんし、人間力かもしれません。

とにかくあなたの何かが確実に成長します。

また、炎上案件の凄いところが普通に過ごした期間と炎上案件に関わった期間の成長の度合いに大きな差があります。

それだけ炎上案件には人を成長させるパワーがあります。

一度経験しておくのをオススメしますよ。

[getpost id=”1204″ target=”_blank” cat_name=”1″ date=”0″]

恥ずかしい思いをしないためにもDocコメントの基礎くらいは知っておきたいところです。

Docコメントのメリット

可読性・視認性が高くなる

何をするのか・どのようなデータを持っているのかなどが一目で分かる。

一目でわかるこそ、保守開発時には大いに役に立チマス。（正直これだけ書くモチベーションになれます。

ツールに影響する

PHPStan や PHPUnit などのツールを使用する際に大きく役に立つ。

特に静的解析の精度向上に役に立ち、バグの発生や早期発見にすんげぇ貢献してくれる。

Docコメントのデメリット

めんどくさい

Docコメントを書く事が猛烈にめんどくさい日がたまにあります。

メリットをちゃんと理解しているので、めんどくさい日でもちゃんと書きます。みなさんも書きましょう。

不適切な内容だとツラい

Docコメントに書いてある内容が間違っていると誤解を生み、新たな仕事を発生させることがある。

最近ではある大手のサービスのSDKのDocコメントが間違っており、IDE上の警告が消えないために時間を費やしてしまう事件がありました。（多分Docコメントのメンテナンスされていないだけかな…？）

みんなもキヲツケテネ。

書き方

こんな感じで書くよ。(改行がおかしいのは許してね)

/**
* 何をするメソッドなのか 
*
* @param 変数
* @return 戻り値
*/
private function fuga(): void {}



/**
* プロパティの説明
*
* @var string
*/
protected string $hogehoge

型定義

参考：https://docs.phpdoc.org/3.0/guide/references/phpdoc/types.html

タグの意味

参考：https://docs.phpdoc.org/3.0/guide/references/phpdoc/index.html

今日はちょっとマニアックな話、ステートフルとステートレスについてお話ししたいと思います。
これ、聞いたことあるけどよくわからないって人、多いんじゃないかな？
でも大丈夫、ここでしっかり理解していきましょう！

ステートフルって何？

まずはステートフルについて。

ステートフルっていうのは、端的に言うと「過去の情報を覚えている状態」のこと。
システムが過去にどんな処理をしたかを記憶していて、それをもとに次の動作を決めるんです。

例えば、Webサイトにログインする時を考えてみてください。
一度ログインすると、そのサイトは「あ、この人はもう認証済みだな」と覚えてくれてますよね。
これがステートフルな動作。ユーザーの状態を保持して、その情報に基づいて何らかの処理をするわけです。

具体例

1. Webセッション管理：
   ユーザーがWebサイトにログインしたとき、サーバーはそのユーザーのセッション情報（例えば、認証情報、プロファイル設定など）を保持します。この情報は、ユーザーがサイトをナビゲートする間、持続し、適切なコンテンツやオプションを提供するために使用されます。
2. データベーストランザクション：
   データベースは、過去のクエリやトランザクションの履歴を追跡し、それに基づいてデータの整合性を保持します。たとえば、銀行の取引記録は、口座の残高を正確に保つために重要です。

じゃあステートレスって？

一方で、ステートレスはその逆。

つまり、「過去の情報を覚えていない状態」を指します。
こっちは、過去の情報に左右されずに、その都度独立して処理を行います。

たとえば、HTTPプロトコル。
これ、実はステートレスなんですよ。
ウェブサーバーは、同じユーザーからのリクエストでも、それぞれを完全に別々のものとして扱うんですね。だから毎回、ページをリロードするたびに「誰この人？」ってなるわけです。

具体例

1. HTTPプロトコル：
   HTTPはステートレスプロトコルです。ウェブサーバーは、同一のクライアントからの複数のリクエストを関連づけません。各リクエストは独立しており、サーバーはそれぞれのリクエストを新規のものとして処理します。
2. RESTful API：
   RESTアーキテクチャはステートレスであり、各APIリクエストは他のリクエストから独立しています。例えば、REST APIを通じてリソースを取得するリクエストは、以前のリクエストやその結果とは無関係に処理されます。

ステートフルとステートレス、使い分けは？

これら二つ、どちらが良いとか悪いとかではなくて、用途によって使い分けるのが大事。

ステートフルは、ユーザーに合わせたカスタマイズや複雑な処理が必要な場合に向いています。
一方、ステートレスはシンプルさとスケーラビリティが求められる場合、例えば大規模なWebサービスとかにぴったり。

要は、状況に応じて臨機応変に使い分けることが大切。
システム設計する時は、この二つの特性をよく理解して、最適なアーキテクチャを選んでいきましょう！

まとめ

いかがでしたか？
ステートフルとステートレス、ちょっと難しいけど、この話を押さえておけば、システムの動きを理解するのに役立つはず。

ぜひこの知識を活用して、もっとITの世界を楽しんでいってくださいね！それでは、また次回！

ある日、突然 vscode が動かなくなるという恐ろしい症状に出くわしました。（業務では PHPStorm を使用しているので、vscode の勝手があまりわからない。。。）

PHP executable not found. Install PHP and add it to your PATH or set the php.debug.executablePath setting

「PHPの実行ファイルがねーぞ！」というエラー文言、 Docker にて環境構築をしている事が原因あろうと想像つきます。

PHPコンテナへのパスを追加する

仕事のできる先輩へ相談したところ、すぐに返事をもらえました。

それだけで解決するわけ無いだろ！って思ったんですけど大人しく従ってみることにしました。

手順1：プロジェクト固有の設定ファイルを定義する準備

vscode にはプロジェクト単位で設定ファイルを作成することができます（知らんかった…

プロジェクトの第一階層に .vscode というディレクトリを切りましょう。

手順2：コンテナへのパスを定義しよう

プロジェクト固有のディレクトリの中にPHPが動作しているコンテナへのパスを書いたshellファイルを定義しましょう。

こんな感じ↓

docker exec -it `コンテナ名` php $@

手順3：vscode の設定ファイルを定義しよう

プロジェクト固有のディレクトリの中に settings.json というファイルを定義しましょう。

vscode 本体に設定することも可能なんですけど、一つのプロジェクトしか触らないというエンジニアは居ないと思うので、プロジェクト固有の設定を記述していきましょう。

設定ファイルの中身はこんな感じ↓

{
    // 手順2で作成したシェルファイルを定義
    "php.debug.executablePath": "./container-php.sh"
}

ちなみにファイル名が「setting.json」だとvscodeが認識してくれません！
「settings.json」というファイル名してくださいね！

先輩に感謝

先輩にコーヒーとタバコをおごりました。

感謝致します。

Reactの考え方

React では、DOM 要素を直接操作する代わりに、React の状態管理やレンダリング方法を使用して操作を行うことが推奨されているとのこと。

useState

useState フックは、状態（state）を React コンポーネント内で管理するために使用します。状態は、コンポーネント内でのデータの変更を追跡し、自動的に再レンダリングするために使われます。

差分取って差分の分だけレンダリングするっぽいですね。楽だし早いね。

Reactの基本理念？である状態管理で差分を取るってのがuseStateの肝な気がする。

useEffect

コンポーネントのレンダリング後に実行される処理(データ)を管理するために使用します。

useEffect フックは第1引数に副作用の関数を受け取り、第2引数には、依存する値の配列を指定します。この配列に指定した値が変更された場合に副作用関数が再実行されます。

空の配列を指定することで、初回レンダリング時にのみ副作用関数が実行されることを意味します。

    const [csrfToken, setCsrfToken] = useState(null);
    useEffect(() => {
        // メタタグからトークンを取得
        const metaTag = document.querySelector('meta[name="csrf-token"]');
        if (metaTag) {
            setCsrfToken(metaTag.content);
        }
    }, []);

なんとなくonloadっぽい。。。

注意点

第二引数に何も指定しない

無限ループ発生します。ローカル端末が燃えます。気をつけましょ。