LaravelのHorizonへのアクセスが403エラーになる件

Github ActionsでのSSHポートブロックの環境での鍵情報をどうするかを検討していた件

こちらを参考にしてください。

今回は、

dockerコンテナで、

いつものように立ち上げて処理していたが、

ユーザーをrootで動くようにしていたので、

ファイルアクセス権の問題で、

Permisison

の関連エラーが出ていた。

今回の件を、

自分の備忘録として、

忘れないうちにメモを残しておきます。

今回の内容の経緯

コンテナを立ち上げる際に、

FROM php:8.1-fpm

のように、

ベースとして、

Ubuntuが動く環境でやっており、

デフォルトだと、

rootになってしまっていた。

ファイル権限周りで色々と調整していたが、

調整方法としては、

コンテナ内でファイル権限操作により対応する
立ち上げるコンテナ自体の実行ユーザーを変更する

が考えられるが、

後者の

立ち上げるコンテナ自体の実行ユーザーを変更する

という対応にした。

対応メモ

対応方法としては、

Dockerfile

の中に

RUN groupmod -g 33 www-data \
 && usermod -u 33 -g 33 www-data

USER www-data

を入れて対応するのみ。

については、

www-data ユーザー／グループのデフォルトの UID/GID

なので、

それを使って設定してる。

この調整したら、

Docker イメージの再ビルド
Docker コンテナの再起動

の２つでオッケーのはず。

ちなみに、

ユーザー指定で、

コンテナ動かすとか、

入って対応するとかの時は、

docker run -u www-data myapp

のように

「-u」（user）

オプションを使うと良い。

定期処理とポーリングについてのメモ。

Laravelで、

スケジューラーを使用して、

処理をしていたが、

その中で、

定期処理
ポーリング

という部分で、

DBポーリングなど、

関連したキーワードを聞いたり、

質問時の回答に出てくることがあり、

自分の理解のために、

確認したり把握したことをメモ。

あくまでも、

個人見返しようなので、

部分的だったり、

認識違うこと書いてるかもしれないので、

他のサイトを参考に。

定期処理とポーリングの違いは？

この違いについては、

ポーリング自体は完全に別の概念と思っていたが、

確認してみると、

定期処理：決まった処理を毎回実行（例：メール送信）
ポーリング：状態（DBなど）を毎回確認するための処理
　→ if(status == 'done') { 次に進む }

つまり、「ポーリング」は定期処理の中の一パターン。

ということ。

なるほど。

定期的にDB見に行くんだが、これは？

これ、

決まった処理といえば、

決まった処理と言えるが。

「Laravelのスケジューラで、毎分DBを見に行く」＝DBポーリングの一種

ということらしい。

なるほど、

定期的にステータス見て、

別の処理してるから、

定期処理ではなく、

ポーリングなのか。

Github ActionsでのRunnerをGitHubの管理画面の方から実行する件

本番環境へのデプロイに関して、

自分なりに試そうとする中で、

再確認の意味を込めて、

Github Actionsを設定し直して、

試した時の個人用のメモ。

調べながら、メモしている感じなので、

個人的な見返してどういう経緯だったとかを確認するようなので、

調べる中で気になった関連事項についても個人用に書いているので、

個別に必要な情報は、記事内にもある公式情報を参照してもらえると。

個人用の簡潔なメモ。

正確な情報を記載しているというよりも、

その時のメモなので、

正確な情報は公式情報等で探してください。

GitHub Actions関連で試したことメモ

GitHub Actionsに関して、

色々と初歩を試したことなど、

以下の記事にもメモしてるので、

必要に応じて見返そう。

Github Actionsでのセルフホストランナーをどうするかを検討していた件

Github ActionsでのRunner実行でのcdでのエラー「Error: Process completed with exit code 1.」が発生する件

GitHub Actionsでやろうとしたこと

普段は、

実際のコードを調整して、

反映するので、

その時に、

GitHub Actionsが動くかを確認できるが、

何度もコード変更するのは面倒。

なので、

管理画面から、

GitHub ActionsのRunnerを動かせるようにする。

Runnerを管理画面から動かせるように設定

設定自体は簡単。

ランナーのコードに、

workflow_dispatch

を追加するだけ

on:
  push:
    branches: [ main ]
  workflow_dispatch:

という感じ。

これ、

反映したら、

GitHubのリポジトリ

　↓

Actionsタブ

　↓

左側から、対象のRunnerを選択

　↓

ランナーの中に

This workflow has a workflow_dispatch event trigger.

と書かれていて、

Run workflow

というボタンが出るので、

そこから実行。

Github ActionsでのRunner実行でのcdでのエラー「Error: Process completed with exit code 1.」が発生する件

本番環境へのデプロイに関して、

自分なりに試そうとする中で、

再確認の意味を込めて、

Github Actionsを設定し直して、

試した時の個人用のメモ。

調べながら、メモしている感じなので、

個人的な見返してどういう経緯だったとかを確認するようなので、

調べる中で気になった関連事項についても個人用に書いているので、

個別に必要な情報は、記事内にもある公式情報を参照してもらえると。

個人用の簡潔なメモ。

正確な情報を記載しているというよりも、

その時のメモなので、

正確な情報は公式情報等で探してください。

GitHub Actions関連で試したことメモ

GitHub Actionsに関して、

色々と初歩を試したことなど、

以下の記事にもメモしてるので、

必要に応じて見返そう。

Github ActionsでのSSHポートブロックの環境での鍵情報をどうするかを検討していた件

Github Actionsでのセルフホストランナーをどうするかを検討していた件

GitHub Actionsでやろうとしたこと

シンプルなことをやってる。

ということだけ。

ただ、

これがうまく挙動しなかった。

GitHub ActionsのRunner実行エラー

うまく挙動しないというか、

正確には、

うまく動いたり、うまく動かなかったりするという事象が発生

という状態。

ちなみに、

発生するRunnerのエラーは、

Run cd /home/user/target-folder
/home/user/actions-runner/_work/_temp/eeeeeeee.sh: 
line 1: cd: /home/user/target-folder: No such file or directory
Error: Process completed with exit code 1.

というエラー。

これ、

対象フォルダは存在してる。

それがよくわからん。

考えられることとしては、

１つのサーバーに複数のRunnerを使うリポジトリがある

ということくらい。

ただ、

これが原因なのかは、可能性の範囲。

試した調整

cdがないと言われるので、

コードの書き方を調整。

jobs:
  deploy:
    runs-on: self-hosted

    steps:
    - name: Deploy to server
      run: |
        cd /home/user/target-folder
        git pull origin main

これ、

cd /home/user/target-folder
git pull origin main

この分離を

git -C /home/user/target-folder pull origin main

でまとめるように調整。

ただ、安定せず。

追加で設定

concurrency:
  group: deploy-group
  cancel-in-progress: true

これ、

cancel-in-progress: true

については、

そのグループで前のジョブが実行中なら、

後から来たジョブを自動キャンセルする。

１度エラーになったが、

もしかして、

うまく安定した？

引き続き、

様子見。

Laravelのworkerに関してJob作成して試した件の個人的なメモ。

Laravelで、

queueを使っていたが、

使い方のみ調べて、

設定して運用していたので、

色々と自分なりの整理や、

より理解できるように試したり、

聞いたりしながら、

自分なりのメモを残してる。

LaravelのWorker / Queueに関してのメモ

色々と、

WorkerやQueueについて、

試しながら、

調べたことで理解した部分や、

個人的になるほどとか、

気になった点のメモは、

こちらの方にもメモしてる。

Laravelのqueueについてのデフォルト設定と基本についての個人的メモ。

Laravelのqueueのドライバーの基本についての個人的メモ。

Redisについて調べて試した件

Job作成

LaravelにJob作成

php artisan make:job TestJob

<?php

namespace App\Jobs;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Illuminate\Support\Facades\Log;

class TestJob implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public function handle()
    {
        Log::info("TestJob executed at " . now());
        sleep(10);
    }
}

Jobを実行する

Route::get('/test-sync', function () {
    dispatch(new \App\Jobs\TestJob());
    return 'Job dispatched!';
});

を準備して、

curl http://localhost:8000/test-sync
curl http://localhost:8000/test-sync
curl http://localhost:8000/test-sync
curl http://localhost:8000/test-sync

呼び出して

キューに追加。

Redisを確認

こちら、

Redisを導入した環境で、

redis-cli

でクライアントに入って、

ZRANGE laravel_horizon:pending_jobs 0 -1

を確認すると、

127.0.0.1:6379> ZRANGE laravel_horizon:pending_jobs 0 -1
1) "66650e15-0c04-4f0e-ac72-76c1926018e2"
2) "10f23faa-362f-463e-ba55-97fa5557e04e"
3) "839680cb-26ea-4862-9e38-123bd8872797"
4) "6baf89c2-e9df-4874-b7ee-0637c6c6e51f"

という感じで確認できる。

Queueに溜まったJobを実行する

溜まったJobを実行するので、

を行う。

これをすると、

溜まっているJobが１つずつ実行されて、

Redisクライアントで確認すると、

ZRANGE laravel_horizon:pending_jobs 0 -1

結果が、

127.0.0.1:6379> ZRANGE laravel_horizon:pending_jobs 0 -1
(empty array)

となるので、

うまく処理できてる。

概念メモ

[ Horizon ]  ← 全体の管理者（ダッシュボード付き）
     │
     ├─ [ Supervisor ]  ← worker の設定と監督役
     │         ├─ worker #1
     │         ├─ worker #2
     │         └─ worker #3
     │
     └─（他にも supervisor を作れる）

Redisについて調べて試した件

今回は、

Redisについて、

使用する機会がなかったので、

調べながら試した時のメモ。

あくまで個人のメモ用なので、

断片的であったり、

正確な情報でないこともメモしている。

必要に応じて、

この記事を見直すと思うので、

その際は、調整するように。

何度かは見返すと思うので。

Redisとは？

Redisは インメモリデータベース

データをメモリ上に置くことで超高速アクセスを実現する。

以下の用途で使用

キャッシュ：データベースアクセスの回数を減らす
セッション管理：ログイン情報や一時データの管理
メッセージキュー：Pub/Subやストリームでリアルタイム通知

また、

特徴としては、

・データ構造型が豊富

String（文字列）
List（リスト）
Set（集合）
Hash（連想配列）
Sorted Set（スコア付き集合）

・永続化も可能（RDBスナップショット、AOFログ）

・シングルスレッドで動作（ただし高速）

という点かなと。

Redisを試すための準備と起動

コンテナ立ち上げて試す。

コンテナ立ち上げ

docker run --name redis-test -p 6379:6379 -d redis

コンテナに入って、

プロンプトに入る

redis-cli

入ると、

127.0.0.1:6379>

127.0.0.1:6379> PING
PONG
127.0.0.1:6379> SET mykey "hello"
OK
127.0.0.1:6379> GET mykey
"hello"

とりあえず動いた。

Redis把握のための基礎関連

Redisの位置づけ

NoSQLの1つ

RDB（リレーショナルDB）とは違い、テーブルや固定スキーマに縛られない

Key-Value型NoSQL の代表格

「キーで値を取り出す」単純な構造をベースにしている

種類	特徴	例
Key-Value型	キーで値を取り出すだけ。値の中身は自由	Redis, DynamoDB
ドキュメント型	JSONのようなデータをそのまま保存、クエリも可能	MongoDB, CouchDB
列指向型	データを列単位で保存し分析向き	Cassandra, HBase
グラフ型	ノードとエッジで関係性を表現	Neo4j

Redisを使う理由として、

Key-Value

Key-Value型が高速な理由

検索が単純

つまり計算量が少なく、アクセスが高速。

Key-Value型では キーを指定して値を取り出すだけ です。

RDBのように複雑な結合（JOIN）や条件検索が不要。

メモリ上で処理

Redisは インメモリデータベース なので、ディスクI/Oがほとんど発生しません。

RAMから直接データを読むので数十万〜数百万回/秒レベルの高速アクセスが可能

ということは？

　↓

Key-Value型 = 「キーで値を取るだけ」 の超シンプル設計

メモリ上で動く + 検索単純 + データ構造シンプル → 超高速

Redisはこの性質を活かしてキャッシュやランキングなどに使われる

ということ。

Laravelのqueueのドライバーの基本についての個人的メモ。

Laravelで、

queueを使っていたが、

使い方のみ調べて、

設定して運用していたので、

改めて、

個人用に再確認して、

それを自分のために整理したメモ。

前提

Laravelで試していますが、

バージョンについては、

php artisan --version

で確認すると、

概ね、

１０か１１でした。

Laravel Queueの基本と試した件

Queueの基本部分と、

それを試す件については、

以下の記事の方に、

個人的にメモ。

Laravelのqueueについてのデフォルト設定と基本についての個人的メモ。

Laravel Queueのドライバ

デフォルトは、

sync

Laravel Queue は「Job を dispatch する」という共通インターフェースを提供

ドライバごとに Job の保管・実行方法が異なる

sync → 即実行（ストレージ不要）
database → DB テーブルに Job を保存 → worker が取り出して実行
redis → Redis に保存 → worker が非同期で実行
sqs → AWS SQS に保存 → worker が非同期で実行

こちら、

Laravel バージョン	Queue 関連の変更・sync登場
Laravel 4	Queue サポート開始。非同期キュー中心
Laravel 4.x	sync ドライバ追加（開発用）
Laravel 5〜8	sync ドライバをデフォルトに設定。DB/Redis/SQS 等の多彩なドライバ追加
Laravel 9〜10	同様、sync はデフォルトで「簡単に即時実行」を保証。非同期は外部ドライバで制御

ということらしい。

これ、

どこ押さえ解けば良いのか？

💡 ポイント

sync は 開発・学習のために生まれた「即時実行型」ドライバ
歴史的には「非同期キューの準備が不要な環境で Queue を扱う」ためのもの
本番運用では大量 Job を扱う場合、sync のままでは呼び出し元がフリーズするのが設計上の制約

ということは、

本番でsyncは想定されていない？

項目	sync	他ドライバ（database / redis）
非同期処理	なし	あり
Job の保管	なし	DB / Redis に格納
並列処理	dispatch 呼び出し元のプロセス依存	worker プロセスで実行可能
大量 Job	dispatch 側がブロック → UI フリーズ	worker による分散処理可能
エラー管理	その場で throw	failed_jobs テーブルで管理可能

💡 ポイント：

「sync は本番運用を想定していない」と考えて差し支えない
本番では非同期ドライバに切り替えるのが標準的な設計

Laravelのqueueについてのデフォルト設定と基本についての個人的メモ。

Laravelで、

queueを使っていたが、

使い方のみ調べて、

設定して運用していたので、

改めて、

個人用に再確認して、

それを自分のために整理したメモ。

前提

Laravelで試していますが、

バージョンについては、

php artisan --version

で確認すると、

概ね、

１０か１１でした。

Queueとは？

キューについては、

目的としては、

重い処理（メール送信・API 呼び出し等）を非同期化
パフォーマンス向上
さまざまなキューバックエンドを統一的に扱うため

という認識。

Laravel 8 以降は Job のバッチ処理などが強化された認識で、

自分もそれの少し後くらいから使い始めました。

Queueを動かすコマンドや関数

メインとして

php artisan queue:work

Job（処理内容）

こちらは、

実際に実行されるときに、

どのような処理するかを記載する。

処理の実装は、

クラスとして定義し、handle() に処理を書く
Job::dispatch() でキューに投入

を実装するので、

app/Jobs

などにまとめる。

Queue Driver（保存先）

Driverについては、

sync
Redis
Database
Amazon SQS

などが設定できますが、

デフォルトは、

config/queue.php

に設定があり、

'default' => env('QUEUE_CONNECTION', 'sync'),

であるので、

ここで設定変更できる。

Worker（実行役）

Workerに関しては、

キューから Job を取り出して順次実行
成功→削除、失敗→リトライ or Failed Jobs

を行うもの。

これは、

php artisan queue:work

で動かす認識。

メモ

✔️ よくある誤解

「worker が実行する時にコンストラクタが再び呼ばれる？」
→ 呼ばれません。

Job は シリアライズ → デシリアライズ されるので、
実行時に呼ばれるのは handle() だけ です。

シリアライズ（serialize）とは？

オブジェクトや配列などの「複雑なデータ」を、
ファイルやキューに保存できる「文字列データ」に変換すること。

逆に元に戻すことを デシリアライズ（unserialize） と言います。

⚙️ Laravel Queue でのシリアライズ

Laravel の Queue に Job を入れるとき、こうしています：

dispatch() が Job のインスタンスを作る（コンストラクタが呼ばれる）
Job のインスタンスをシリアライズ（＝文字列データ化）する
その文字列を Redis/SQS/DB に保存する
Worker が文字列を取り出して
- デシリアライズ（元の Job インスタンスに復元）
- handle() を実行

重要ポイント

コンストラクタが呼ばれるのは dispatch 時だけ
Worker 側は デシリアライズで復元されるだけなので、
コンストラクタは実行されない
実際の処理は handle() に書く必要がある理由がこれ

🏁 まとめ（超シンプル）

シリアライズ＝オブジェクトを文字列にする
デシリアライズ＝文字列から元のオブジェクトに戻す
Laravel Queue は「Job をシリアライズしてキューに保存する」
Worker はそれをデシリアライズして handle() を実行する
コンストラクタは dispatch 時しか呼ばれない

Terraformを試した件

Terraform

「テラフォーム」

を使ってみることで、

インフラ構成をコード化するものが、

実際にどのようなものか、

まずは試してみようと思いました。

あくまで、

個人的な備忘録なので、

ChatGPT等に聞きながら、

自分なりに見返したいところだけ、

この記事にメモしてる。

要素メモ

Terraformを使っていく中で、

Provider（プロバイダー）

というのが用語として出てきたので、

そちらについてメモ。

プロバイダーについては、

Terraformが操作できる外部サービスのこと
例：AWS, GCP
APIを通してリソースを作成・変更・削除する

という認識。

terraform {
  required_providers {
    digitalocean = {
      source = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

provider "digitalocean" {
  token = var.do_token
}

Resource（リソース）

リソースに関しては、

作成・管理する対象のこと
例：Droplet, VPC, Firewall, Volume
宣言的に「こういう状態にしたい」と書く

という認識。

resource "digitalocean_droplet" "web" {
  name   = "web-1"
  image  = "ubuntu-22-04-x64"
  region = "nyc2"
  size   = "s-1vcpu-1gb"
}

Variable（変数）

変数に関しては、

外部から値を渡すための仕組み
APIトークンやSSH鍵パスなどを安全に設定可能

という認識。

variable "do_token" {}
variable "pvt_key" {}

になるが、

実際の鍵情報のファイル名を使うという認識。

Data Source（データソース）

データソースに関しては、

既存リソースの情報を取得するための仕組み
例：既にDigitalOceanにあるSSHキーを取得してDropletに設定

という認識。

data "digitalocean_ssh_key" "terraform" {
  name = "terraform_id_rsa"
}

作成した鍵情報のファイル名を使う。

コマンドメモ

プロバイダーの初期化

terraform init

作成/変更/削除のプラン確認

terraform plan

実際に反映

terraform apply

リソース削除

terraform destroy

実行時めも

var.do_token
  Enter a value: ここにはプロバイダーのトークン（基本プロバイダーのAPIトークン）

var.pvt_key
  Enter a value: ここは、秘密鍵情報のパス（~/.ssh/id_rsa）

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value:

本当にすべてのリソースを削除しますか？
Terraform は上記に示されているすべての管理対象インフラを削除します。
この操作は元に戻せません。
“yes” と入力したときだけ実行されます。

画像を特定拡張子のに変換するコマンドを試した件

画像ファイルに関して、

処理の中で、

特定の画像に変換したいなとなって、

その変換処理を作ろうとして、

コマンドを調べて、

実際に変換処理を試してみようと思いました。

あくまで、

個人的な備忘録なので、

ChatGPT等に聞きながら、

自分なりに見返したいところだけ、

この記事にメモしてる。

使うコマンド

実際に変換するコマンドは、

convert

というコマンドを使う。

これ、

ImageMagick

というOSS画像処理ツール群。

概要:
ImageMagickは1987年にJohn Cristy氏によって開発された、画像の読み込み・変換・編集ができるOSSの画像処理ツール群。
目的:
GUIなしで画像を扱いたいニーズ（Webサーバーでの動的画像生成など）に応えるために設計。
コマンドラインやスクリプトでの画像変換・リサイズ・圧縮・合成などが得意。
主な機能:
- 画像形式の変換（例: JPEG → PNG / WebPなど）
- サムネイル生成
- テキストの描画
- トリミング、リサイズ
- アニメーションGIFの作成
対応形式:
JPEG, PNG, GIF, TIFF, PDF, WebP, SVGなど200以上。

これ、

準備

自分の環境は、

Ubuntu

でやっているので、

以下のコマンドで導入。

sudo apt update

sudo apt install imagemagick

導入できたら、

convert

のコマンドで、

パラメータ表示されるので、

そこまでできたら準備完了。

試す

実際に自分の環境で試した。

コマンドは、

convert old_file new_file.png

のような感じ。

これで問題なければ、

エラーなく何も表示されずに完了。

参考

実際に、

特定ファイル名を含むファイルを、

変換する処理コードは、

こんな感じでシェル組んだ。

#!/bin/bash

PATTERN="*sample*"

find ./ -name "$PATTERN" | while read filepath; do
  dir=$(dirname "$filepath")
  filename=$(basename "$filepath")
  filename_noext="${filename%.*}"
  convert "$filepath" "$dir/${filename_noext}.extension_name"
done

参考まで。

ローカルのコンテナ上で、Next.jsのnext-auth使用してビルド後に実行したらエラーになった件

Nextjsで実装していたときに、

認証周りを構築しようとした時に、

何かライブラリなどを用いて、

GoogleのOAuthでの認証を試そうと考えました。

現時点で調べていると、

「Auth.js(NextAuth.js)」

というライブラリが良さそうなので、

こちらを試してみることにしました。

今回は、

ライブラリ「Auth.js(NextAuth.js)」を用いて、

Google OAuthの認証を試していたので、

その時にビルドまでうまくいったのだが、

実行するとエラーになった時のメモを

備忘録としてこの記事に残します。

公式サイトの情報

公式サイト

まずは、公式サイトでNextAuth.jsのことを確認

自分が確認した時点（2023/04/25）で、

NextAuth.js is becoming Auth.js! 🎉 
Read the announcement. Note, 
this site is under active development.

とアナウンスされているので、

それぞれのリンクをメモしておきます。

nuxt-authでGoogle認証を試した

今回のビルドエラーになったのは、

Next.jsでGoogle認証を試していたのだが、

開発モードではうまく挙動していた。

TypeScriptを使っているので、

ビルド時にエラーになったが、

ベースとなるやっていることは、

以下の記事を参考。

ビルドのエラーは調整済み

ビルドについてもエラーになったが、

以下の対応をやって、

問題なくビルドは完了している。

ローカルのコンテナ上で、Next.jsのnext-auth使用してビルド後に実行したらエラーになった件

実行エラー

実行したら、

エラーが発生した。

エラー内容

Error: Error serializing `.csrfToken` returned from `getServerSideProps` in “/auth/signin”.
Reason: `undefined` cannot be serialized as JSON. Please use `null` or omit this value

こちら、

以下の対応もした。

今回の調査

上記の対応とは別で、

今回は環境も違うので。

http://sample.com/api/auth/providers

でプロバイダーを確認

結果は、

{"google":{"id":"google",
"name":"Google",
"type":"oauth",
"signinUrl":"http://sample.com/api/auth/signin/google",
"callbackUrl":"http://sample.com/api/auth/callback/google"}}

という結果。

Dockerコンテナ上のLaravelの初期設定で、artisanコマンド実行できない件「vendor/autoload.php」（初歩的なミスなので、繰り返さないようにメモ）

環境構成を再構築する中で、

リポジトリから取得して、

環境作っていく中で、

うまくフロントができて、

バックエンドもリポジトリから持ってきて、

動いてるかなと見ると、

502等のエラーが起きてた。

この状況で、

エラーなどを確認した時のメモ。

エラー状況メモ

まず、

ログファイルを見ようとしたが、

storage/logs/laravel.log

にファイルができていない。

これで自分の場合はうまく反映できた。

なので、

ルーティング等を確認しようとして、

php artisan route:list

としたが、

そもそも、

artisan動いてない。

これ、

そもそも

php artisan

が動いてなくて、

あれ、

vendor/autoload.php

もないし、

compose install

も動かない。

単純ミス

単純にコンテナ内に入ってなかった。

これ、

時々ミスるので、

いつか、

自分が見返すかもしれないので、

反省の意味込めて、

この記事に残す。

TraefikでDockerコンテナをリバースプロキシで試した件

Traefik

「トレーフィック」

を使ってみることで、

リバースプロキシ

などの基礎理解にも役立つかなと思って、

試してみることにした。

あくまで、

個人的な備忘録なので、

ChatGPT等に聞きながら、

自分なりに見返したいところだけ、

この記事にメモしてる。

前提環境 / 準備

環境としては、

Mac

を使って試した。

docker --version

docker compose version

を準備。

それ以外の初期のTraefixの起動までは、

こちらで試した。

TraefikをMacで立ち上げを試した件

設定

version: '3.8'

services:
  sample_admin:
    build:
      context: ./admin
    container_name: sample_admin
    ports:
      - "9021:80"
    volumes:
      - ./admin/application:/var/www/html
    networks:
      - app-network
      - traefik-network
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.sample-admin.rule=Host(`sample-admin.localhost`)"
      - "traefik.http.routers.sample-admin.entrypoints=web"

  sample_ui:
    build:
      context: ./ui
    container_name: sample_ui
    ports:
      - "9022:9022"
    volumes:
      - ./ui/application:/var/www/html
    networks:
      - app-network
      - traefik-network
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.sample-ui.rule=Host(`sample-ui.localhost`)"
      - "traefik.http.routers.sample-ui.entrypoints=web"

  sample_mysql:
    image: mysql:8.0
    container_name: sample_mysql
    environment:
      MYSQL_ROOT_PASSWORD: root_password
      MYSQL_DATABASE: sample_database
      MYSQL_USER: sample_user
      MYSQL_PASSWORD: sample_password
    volumes:
      - sample-mysql-data:/var/lib/mysql
    networks:
      - app-network

networks:
  app-network:
    driver: bridge
  traefik-network:
    driver: bridge

volumes:
  sample-mysql-data:

起動、確認

sudo docker-compose up -d

コンテナを立ち上げたら、

http://sample-admin.localhost/

これでアクセスできるはず。

しかし、

Gateway Timeout

となってしまう。

Traefixに関して

version: "3.9"

services:
  traefik:
    image: traefik:v2.11
    container_name: traefik
    restart: always
    command:
      - --api.insecure=true
      - --providers.docker=true
      - --entrypoints.web.address=:80
      - --log.level=DEBUG
    ports:
      - "80:80"
      - "8080:8080"   # dashboard 用
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - traefik-network

  whoami:
    image: traefik/whoami
    platform: linux/amd64   # ← M1/M2/M3 Mac なら必須
    container_name: whoami
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`whoami.localhost`)"
      - "traefik.http.routers.whoami.entrypoints=web"
    networks:
      - traefik-network

networks:
  traefik-network:
    external: true

で

      - --log.level=DEBUG

を追加すると、

docker logs -f traefik

でログが確認できる。

これで確認したところ、

time="2025-11-08T07:28:19Z" level=debug 
msg="'504 Gateway Timeout' caused by: 
dial tcp 172.28.0.3:9022: i/o timeout"

となっている。

ネットワークの問題？

ネットワークを確認する

docker network inspect traefik-network

これ確認したら、

traefik-network に入っているのは traefik と whoami のみ で、

入れたかったコンテナが入っていない。

こちらは、

networks:
  app-network:
    driver: bridge
  traefik-network:
    external: true

ですでにあるネットワークに入るようにして、

これで対応。

解決しない

[ブラウザ / ホスト]
       |
       |  http://sample.localhost
       v
[Traefik コンテナ]
       |  ← docker network 経由で sample にアクセス
       v
[開発用 コンテナ: server 0.0.0.0:8080]

この中で、

docker exec -it traefik sh

で入って、

curl http://sample:9022

ではうまくいくので、

Traefik -> 開発用コンテナ

これは問題ないはず。

ブラウザ → Traefik

が問題あり、

Traefik が受け取ったリクエストを正しく oms_ui に送れていないか、

もしくは

Traefik がホスト側でリクエストを受けられていない可能性があるみたい。

ネットワークを１つに設定

コンテナを作る際に、

docker composeのためのymlファイルで、

    networks:
      - app-network
      - traefik-network

元のネットワークを残していたが、

    networks:
      - traefik-network

このように、

Traefikのネットワークを残すようにすることで解決。

個人用ポイントメモ

Traefik がサービスを見つけるために必要なものは？
→ 同じ Docker ネットワーク に所属していて、Traefik 用の labels が付いていること。

ドメインによってバックエンドを切り替える仕組みの名前は？
→ リバースプロキシ（Traefik では Router が担当）。

Traefik がコンテナ内部のポート番号を知る必要がある理由は？
→ 受け取ったリクエストをどのサービスのどのポートへ転送するか決めるため。

TraefikをMacで立ち上げを試した件

Traefik

「トレーフィック」

を使ってみることで、

リバースプロキシ

などの基礎理解にも役立つかなと思って、

試してみることにした。

あくまで、

個人的な備忘録なので、

ChatGPT等に聞きながら、

自分なりに見返したいところだけ、

この記事にメモしてる。

前提環境 / 準備

環境としては、

Mac

を使って試した。

docker --version

docker compose version

を準備。

設定

~/traefik-practice/
├─ docker-compose.yml
├─ traefik/
│  ├─ traefik.yml
│  ├─ acme.json
│  └─ logs/

mkdir -p traefik/logs
touch traefik/traefik.yml
touch traefik/acme.json
chmod 600 traefik/acme.json

version: "3.9"

services:
  traefik:
    image: traefik:v2.11
    container_name: traefik
    restart: always
    command:
      - --api.insecure=true
      - --providers.docker=true
      - --entrypoints.web.address=:80
    ports:
      - "80:80"
      - "8080:8080"   # dashboard 用
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

  whoami:
    image: traefik/whoami
    platform: linux/amd64   # ← M1/M2/M3 Mac なら必須
    container_name: whoami
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`whoami.localhost`)"
      - "traefik.http.routers.whoami.entrypoints=web"

起動

sudo docker-compose up -d

[+] Running 9/9
 ⠿ whoami Pulled
   ⠿ 24f325000f63 Pull complete
   ⠿ 13615ce8532d Pull complete
   ⠿ 3f914992e3e0 Pull complete
 ⠿ traefik Pulled
   ⠿ 6b59a28fa201 Pull complete
   ⠿ d505aca7b2af Pull complete
   ⠿ 6bea70b51c2f Pull complete
   ⠿ d44254284535 Pull complete
[+] Running 2/2
 ⠿ Container whoami   Started
 ⠿ Container traefik  Started

Traefik と whoami コンテナの起動が無事に完了。

traefik → リバースプロキシとして動作中
whoami → サンプルWebサービスとして動作中
ネットワーク traefik-practice_default も自動作成済み

メモ

リバースプロキシを試し、理解したく、

[クライアント] → [リバースプロキシ] → [バックエンドサーバ群]

として、

┌────────────┐
│ ユーザー端末 │
└─────┬──────┘
       │
       ▼
┌────────────────┐
│ リバースプロキシ │ ← ここでSSL終端・ロードバランス・キャッシュ
│ (例: Nginx, Traefik) │
└─────┬────────────────┘
       │
       ▼
┌────────────────┐
│ バックエンド群 │ ← 実際のアプリ (Laravel, Next.js, API等)
└────────────────┘

このような感じかなと。

Traefixをブラウザて確認

ブラウザで

http://localhost:8080/dashboard/#/

これで

Traefixの管理情報がブラウザで見れました。

「Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?」のエラーになった件

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

Github ActionsでのSSHポートブロックの環境での鍵情報をどうするかを検討していた件

こちらを参考にしてください。

今回は、

dockerを立ち上げようとした時に

Cannot connect to the Docker daemon 
at unix:///var/run/docker.sock. 
Is the docker daemon running?

このようなエラーが発生。

今回の件を、

自分の備忘録として、

忘れないうちにメモを残しておきます。

エラー内容

実行処理としては、

docker ps

で確認しようとしたら、

Cannot connect to the Docker daemon 
at unix:///var/run/docker.sock. 
Is the docker daemon running?

というエラー。

メモ

ローカルの Docker は

Docker CLI
Docker Daemon (dockerd)

の２つに分離される。

ゆるく言うと、

「操作する人」と「実際に働く人」が分かれてる状態

これが分離してるってこと。

────────────────────
■ 分離ってどういうこと？

Docker は実は 2 つのプロセスで動いてる。

Docker CLI
これはただの“リモコン”。
キーボードから打つ docker ps とか docker run の部分。
Docker Daemon (dockerd)
これがほんとの Docker の本体。
・コンテナを作る
・コンテナを起動する
・イメージを pull する
・ネットワーク作ったり volume 管理したり
ぜんぶここがやってる。

CLI 自体はコンテナを動かす能力ゼロ。
命令を送るだけ。

ここが「分離している」という意味。

────────────────────

ということ。

イメージしにくいのでもう少し

もう少し、

生活にしたイメージとしては

────────────────────
■ 例えるなら

・CLI → お店の注文端末（注文ボタン）
・Daemon → キッチンで料理を作る人

CLI（ボタン）は押せるけど、
キッチンが閉まってたら料理は作られない。

つまり、Hiro の Mac の状況は

端末はあるけど、キッチン（daemon）が起動してない

だから docker ps が通らない。

────────────────────

対応

CLI は Linux/Mac だと
「/var/run/docker.sock」という Unixソケット を通して
Daemon に命令を送ってる。

このソケットは
Daemon が起動したときに作る“通信口”。

daemon が起動してないと
・ソケットがない
・ソケットがあっても応答がない
から CLI は接続エラーになる。

ここで、

Mac では「Docker daemon だけを単体で起動する」という選択肢は存在しない

という認識（現時点での解釈）なので、

Docker Desktopが、

Docker Desktop が
・Linux VM を起動
・VMの中で dockerd を起動
・その仮想環境を UNIX ソケットとして Mac 側に露出

という感じらしいので、

それで立ち上げてデーモン起動で対応完了。

WireGuardを個人的に試した件

VPNの理解のために、

WireGuardを使用して、

試すのが良いと意見を聞き、

それを試すことにした。

あくまで、

個人的な備忘録なので、

ChatGPT等に聞きながら、

自分なりに見返したいところだけ、

この記事にメモしてる。

前提環境 / 準備

環境としては、

Ubuntu

を使って試した。

sudo apt install wireguard -y

で導入。

設定

メモ

２つのサーバー間

──────────────────
サーバーとクライアントで何が違うか
──────────────────

A（サーバー）側

ListenPort を開けて待ち受ける
ピアの公開鍵を登録して AllowedIPs を指定
Endpoint は不要
→ 「自分から接続しに行く」わけじゃなく、相手が接続してくるのを待つだけ

B（クライアント）側

自分の秘密鍵・VPN内IPを設定
接続先サーバー A の公開鍵を登録
AllowedIPs で許可するルーティングを指定
Endpoint 必須
→ 「どこに接続するか」を知っている必要がある（AのグローバルIP:51820）

要するに、両方の設定ファイルは構造は同じ [Interface] と [Peer] だけど、値の意味が逆向きになるんだよね。

イメージで言うと：

Droplet A (サーバー)
[Interface] → 自分の秘密鍵、IP、ListenPort
[Peer] → Bの公開鍵、AllowedIPs

Droplet B (クライアント)
[Interface] → 自分の秘密鍵、IP
[Peer] → Aの公開鍵、AllowedIPs、Endpoint

なるほど、

だけど、

片方だけ、Endpointが入るのがわからん。

Interface, Peerがわからんからか。

そもそも、Interface, Peerとは？

──────────────────
WireGuardの本質：VPNトンネル
──────────────────

VPNはざっくり言うと “自分と相手を安全につなぐ暗号化トンネル” だよね。
そのトンネルを作るために必要なのが鍵とIP情報。

Interface → 「自分側のトンネル情報」
Peer → 「相手側のトンネル情報」

──────────────────
Interface（自分）とは？
──────────────────

自分が持つ秘密鍵
自分のVPN内のIPアドレス
（サーバーならListenPortで待ち受け）

つまり 「自分のトンネルをどう作るか」 を決める部分。
ここを見れば「このノードはVPN上でどのIPを持ってるのか、どの鍵で通信するのか」がわかる。

──────────────────
Peer（相手）とは？
──────────────────

相手の公開鍵
相手に許可するIP（AllowedIPs）
（クライアントなら接続先としてEndpoint）

つまり 「この相手と通信していいか」 の情報。
Peerに書いた公開鍵とIPにだけ通信が許可される。
ここを見ると「誰とつながるのか」がわかる。

──────────────────
図でイメージすると

Droplet A (サーバー)
Interface → 自分の鍵、IP、ListenPort
Peer      → Bの公開鍵、AllowedIPs

Droplet B (クライアント)
Interface → 自分の鍵、IP
Peer      → Aの公開鍵、AllowedIPs、Endpoint

これ、

Interface は必ず「自分」、Peer は必ず「相手」

がポイントらしい。

さらに、

WireGuard は双方向通信できるけど、設定上は

どちらかを“起点”として接続を開始するかどうか

という役割分担で考えると良いらしい。

なるほど、

少しわかったような気がする。

整理

ポイントはこう整理できる：

──────────────────

双方向通信は可能
──────────────────

WireGuardはトンネルが一度張られると、両方向で暗号化通信できる
だから「どちらも設定ファイルは必要」
つまり両方に Interface と Peer の情報を書く必要がある

──────────────────
2. でも接続の開始は片方が主体
──────────────────

「サーバー」と呼ぶ方は ListenPort を開いて待つだけ
「クライアント」と呼ぶ方は Endpoint を指定して接続しに行く
接続が確立すれば、双方向通信はどちらからもできる

──────────────────
3. まとめると
──────────────────

両方に設定が必要 → トンネルを作るには双方が自分用Interfaceと相手用Peerを持つ
接続開始は片方だけ → Endpointを書いて自分から接続するのはクライアントだけ
トンネル確立後は双方向通信可能 → データのやり取りはどちらからでもOK

視点としては、

設定は「自分視点」
接続開始役を決めると整理しやすい

こう考えると、AとBのconfが「同じ構造で値だけ違う」理由も納得できる。

通信試す

サーバーA,Bで

sudo wg-quick up wg0

をやって立ち上げたら、

サーバーA

ping 10.0.0.1

サーバーB

ping 10.0.0.2

これでうまく接続できました。

Github Actionsでのセルフホストランナーをどうするかを検討していた件

本番環境へのデプロイに関して、

自分なりに試そうとする中で、

再確認の意味を込めて、

Github Actionsを設定し直して、

試した時の個人用のメモ。

調べながら、メモしている感じなので、

個人的な見返してどういう経緯だったとかを確認するようなので、

調べる中で気になった関連事項についても個人用に書いているので、

個別に必要な情報は、記事内にもある公式情報を参照してもらえると。

個人用の簡潔なメモ。

正確な情報を記載しているというよりも、

その時のメモなので、

正確な情報は公式情報等で探してください。

GitHub Actions関連のメモ

GitHub Actionsを試す中での関連したメモについては、

以下の記事にもメモを残しているので、

そちらについても、

今回の内容に関連する部分があるので、

そちらも参考に。

GithubでSSHエージェントでの鍵情報のキャッシュを試した件

GitHub Actionsの実行環境

実行環境としては、

SSHポートは自分のIP以外はブロック

という感じ。

なので、

.github/workflow

のような形で、

セルフホストランナーを実施。

セルフホストランナーとは？

セルフホストランナーについて、理解を自分の中で整理すると、

GitHub Actionsの通知のための仕組みが、

ホストランナーである。

そのホストランナーを、

自分自身の環境で動かすものが、

セルフホストランナーである。

GitHub上では、

「Runner」

という定義というか設定になっている。

セルフホストランナーを分類すると

セルフホストランナーを分類すると、

organizationsに紐づくRunner
リポジトリに紐づくRunner

に分類される。

ここでの使い分けは、

サーバー内でのリポジトリの使用状況や、

リポジトリの管理方針、

鍵情報の管理方針、

などに関わるかなと思うので、

この記事では割愛。

セルフホストランナーを動かす

今回は、

organizations単位でのRunnerを動かす。

organizationsの設定から、

Runnerを登録設定できるので、

そちらから実施。

Runnerの設定フロー
           ┌────────────────────┐
           │ GitHub Organization│
           └────────┬───────────┘
                    │
        ┌───────────▼────────────┐
        │ Actions > Runners を開く│
        └───────────┬────────────┘
                    │
        ┌───────────▼────────────┐
        │ New self-hosted runner │
        └───────────┬────────────┘
                    │
        ┌───────────▼────────────┐
        │ OS選択（例: Linux）      │
        └───────────┬────────────┘
                    │
        ┌───────────▼────────────┐
        │ セットアップ手順取得       │
        └───────────┬────────────┘
                    │
        ┌───────────▼────────────┐
        │ サーバーでセットアップ実行  │
        │ （config.sh & run.sh）  │
        └───────────┬────────────┘
                    │
        ┌───────────▼────────────┐
        │ ランナー登録完了          │
        └──────┬────────┬────────┘
               │        │
   ┌───────────▼──┐  ┌──▼────────────────┐
   │ 任意のリポで   │  │ workflowで指定     │
   │ 使用可能      │  │ runs-on: self-hosted │
   └──────────────┘  └────────────────────┘

という形で、

Runnerの設定を進めれば良い。

他、細かなことについては、

別途、自分の中で整理できたら、

必要に応じて記載しますね。

Github ActionsでのSSHポートブロックの環境での鍵情報をどうするかを検討していた件

本番環境へのデプロイに関して、

自分なりに試そうとする中で、

再確認の意味を込めて、

Github Actionsを設定し直して、

試した時の個人用のメモ。

調べながら、メモしている感じなので、

個人的な見返してどういう経緯だったとかを確認するようなので、

調べる中で気になった関連事項についても個人用に書いているので、

個別に必要な情報は、記事内にもある公式情報を参照してもらえると。

個人用の簡潔なメモ。

正確な情報を記載しているというよりも、

その時のメモなので、

正確な情報は公式情報等で探してください。

GitHub Actionsの実行環境

実行環境としては、

SSHポートは自分のIP以外はブロック

という感じ。

なので、

.github/workflow

のような形で、

セルフホストランナーを実施。

うまくいかない

GitHub Actionsを実行すると、

1s
Run cd /var/www/html/sample
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Error: Process completed with exit code 1.

という形で、

SSH鍵情報での権限エラー。

対応策を考える

権限となっているが、

自分の環境で考えると、

パスフレーズ設定しているので、

それが原因と考えている。

それを

パスフレーズなしでの鍵情報を作成するのも

方法としてはあるのかもしれないが、

他の方法が適切ではないかと考え始めた。

鍵情報の作成パターンを考える

パターンとしては、

Deployキー
SSHキー

かなと。

SSHキーは、

通常のターミナル接続で行う際に、

パスフレーズ入れておきたいので、

それ以外となると、

Deployキーを試すか。

と考えていたが、仕組みはSSHキーなのか。

Deployキーを試すかとなったが、

設定情報についても、

SSHキー情報を設定するのみで、

仕組みとしては、

SSHキー情報を、

どのリポジトリ用で使うかという考え方なのか。

           ┌────────────┐
           │ SSH鍵ペア   │（秘密鍵＋公開鍵）
           └────┬──────┘
                │
     ┌──────────┴──────────┐
     │                     │
User SSH Key                Deploy Key
（ユーザー設定に登録）     （リポジトリ設定に登録）
│                             │
├─ 全リポジトリにアクセス可       ├─ そのリポジトリだけアクセス可
└─ 開発者が使う用                 └─ サーバーやCI/CDが使う用

GithubでSSHエージェントでの鍵情報のキャッシュを試した件

本番環境へのデプロイに関して、

自分なりに試そうとする中で、

再確認の意味を込めて、

Github Actionsを設定し直して、

試した時の個人用のメモ。

調べながら、メモしている感じなので、

個人的な見返してどういう経緯だったとかを確認するようなので、

調べる中で気になった関連事項についても個人用に書いているので、

個別に必要な情報は、記事内にもある公式情報を参照してもらえると。

個人用の簡潔なメモ。

簡潔めも

やるのは、

SSHエージェント（ssh-agent）による鍵のキャッシュ

という感じ。

SSHエージェント（鍵管理プロセス）を起動

eval $(ssh-agent -s)

を実施して、

秘密鍵をエージェントに登録

ssh-add ~/.ssh/id_rsa

を実施。

パスフレーズ聞かれるので、

パスフレーズを入力したら完了。

確認等メモ

上記でSSHエージェントやったら、

git pull

でパスフレーズなしでいけた。

おけ。

Github Actionsでrunnerがsudo権限で「Error: Process completed with exit code 1.」でうまく動かなかった件

本番環境へのデプロイに関して、

自分なりに試そうとする中で、

再確認の意味を込めて、

Github Actionsを設定し直して、

試した時の個人用のメモ。

調べながら、メモしている感じなので、

個人的な見返してどういう経緯だったとかを確認するようなので、

調べる中で気になった関連事項についても個人用に書いているので、

個別に必要な情報は、記事内にもある公式情報を参照してもらえると。

ということで試したのは、

Github Actionsのシンプルな挙動を試した件

こちらをみてもらって、

今回は、

これらとは別に

GitHub Actionsでrunnerを動かす中で、

うまく動かなかった件の調査メモ。

前提

前提としては、

SSHポートはブロック

という感じ。

これを試していた感じ。

また、

１度は、うまくいっていて、

別の日に試したら、

うまく挙動しなくなっていた感じ。

うまくいかない挙動

GitHub Actionsのrunner動かすと、

run.sh

を動かしていたが、

Error: Process completed with exit code 1.

となってしまった。

確認等メモ

Github Actionsでrunnerを確認したら、

sudo: a terminal is required to read the password; 
either use the -S option to read from standard input 
or configure an askpass helper

となっていた。

runner実行する

run.sh

の実行ユーザーは、

sudoでの権限与えてないので、

パスワード求められてブロックされていることが原因かと。

おそらく、

対策としては、

sudo権限をパスワードなしで与えてしまう
対象フォルダ自体をこのユーザーに権限を与える

このどちらかかなと思う。

その中で、

パスワードなしで与えるのも良くないかと考えて、

実行しようとしているフォルダの権限を、

run.sh

の実行ユーザーに対して、

権限を与える対応を実施した。

この対応で、

✅ Files copied successfully

となったので、

私の方では処理がうまくいきました。

Github Actionsでrunnerが「Runner listener exit with terminated error, stop the service, no retry needed.」でうまく動かなかった件

本番環境へのデプロイに関して、

自分なりに試そうとする中で、

再確認の意味を込めて、

Github Actionsを設定し直して、

試した時の個人用のメモ。

調べながら、メモしている感じなので、

個人的な見返してどういう経緯だったとかを確認するようなので、

調べる中で気になった関連事項についても個人用に書いているので、

個別に必要な情報は、記事内にもある公式情報を参照してもらえると。

ということで試したのは、

Github Actionsのシンプルな挙動を試した件

こちらをみてもらって、

今回は、

これらとは別に

GitHub Actionsでrunnerを動かす中で、

うまく動かなかった件の調査メモ。

前提

前提としては、

SSHポートはブロック

という感じ。

これを試していた感じ。

また、

１度は、うまくいっていて、

別の日に試したら、

うまく挙動しなくなっていた感じ。

うまくいかない挙動

GitHub Actionsのrunner動かすと、

run.sh

を動かしていたが、

0|github-r | 
Runner listener exit with terminated error, 
stop the service, no retry needed.
0|github-r | 
Exiting runner...

となってしまった。

確認等メモ

Github Actionsでrunnerを確認したら、

Active

となっていたが、

オレンジ色に丸いアイコンなっていたので、

run.sh

を再度、止めてから実施。

これで、

Idle

とステータスが緑色の丸いアイコンになった。

もしかすると、

これ、

立ち上げする方法は、

PM2でプロセス化しようとしていたが、

bash run.sh

で試しに立ち上げたのが良かったのかも。

これ、

pm2 start ~/actions-runner/run.sh --name github-runner --interpreter bash

にしていたが？

やはり、

GitHub Actionsで用意されている、

svcというものを使う必要があるのかも。

sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status

これが原因かと。

PM2で常駐化させて、

ログ等みたかったが、

その辺りは、

引き続き調査。

Laravelでの「Unable to set application key. No APP_KEY variable was found in the .env file.」エラー。

Laravelを使用していて、

初期設定の中で、

php artisan key:generate

の実施で、

Unable to set application key. 
No APP_KEY variable was found 
in the .env file.

エラーが発生したが、

設定ファイルあり、

なぜか、

ずっとエラーになったのでメモ。

Laravelのバージョン

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 9.52.4

というバージョンであることがわかります。

対応

確認としては、

.envファイルが存在する
APP_KEY=が存在する

あたりは、

.env.example

などから、

流用してくれたらあると思うが、

それらをやっても、

Unable to set application key. 
No APP_KEY variable was found 
in the .env file.

というエラーが出るようなら、

.env

の中身を

APP_KEY=

のように値なしにして、

php artisan config:clear
php artisan config:cache

を実行した上で、

再度、

php artisan key:generate

を実行するとうまくいきました。

ちなみに、

実行できた暗号キーの自動生成の反映実施

も忘れがちなので、

自動生成された暗号キーの反映に、

php artisan config:clear
php artisan config:cache

を忘れずに。

DockerコンテナでのLaravelのルーティングが404でログも出なかった件（ログの権限設定ミス）

Laravelを使用していて、

Dockerコンテナの環境で、

ネットワークを構築して、

UI側との接続を試していたら

"GET /routing/path HTTP/1.0" 404

のエラーが発生したが、

この件、なぜか調べたときの内容。

Laravelのバージョン

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 9.52.4

というバージョンであることがわかります。

事象

Laravelでのルーティングに関しては、

php artisan route:list

で確認したら、

GET|HEAD /routing/path

が存在するので、

ルーティング設定自体は問題ない。

エラーログ詳細としては、

"GET /routing/path HTTP/1.0" 404

というエラーが起きていた。

調査途中メモ

調査途中で、

Laravelのログを確認しようとしたら、

storage/logs

にログファイルが生成されていない。

コンテナ内の

フォルダの所有権を調整したら、

ログファイルは生成された。

ただし、

php artisan tinker

で、

Log::debug('Test log message');

こちらを試すとログは出るが、

UI側から試しに動かしてアクセスあっても、

ログに出力されず。

Nginxの設定で、

ドメイン指定でホストから動かしていたのを、

server {
    listen       80;
    server_name  localhost;

にしてしまっていたので、

server {
    listen       80;
    server_name  sample.com;

のように修正。

これで、

UI側で、

404ネットワークエラーが開発ツールで出てたのが、

500エラーに変わったので、

進捗ありかなと。

ただ、Laravelのログに何も表示されない。

ログファイルのパーミッションを確認したら、

-rw-r--r-- 1 root root 236 Sep 22 08:28 laravel.log

になってしまっていたので、

-rwxr-xr-x 1 www-data www-data 236 Sep 22 08:28 laravel.log

になるように調整。

これでLaravel側にもログでたので、

ここらから先はなんとかなるので、

調査対応完了。

まとめ

原因としては、

やはり、

基礎的な設定周りのミスが原因だった。

コンテナ初期構築時の設定ファイルそのままにしていた

ということになりますね。

そのため、結果として、

環境変数ファイル、環境後の設定情報に変更

という点と、

そうなるような仕組み作りが大切ですね。

リポジトリ内に準備するファイルを含めて。

Github Actionsのシンプルな挙動を試した件

本番環境へのデプロイに関して、

自分なりに試そうとする中で、

再確認の意味を込めて、

Github Actionsを設定し直して、

試した時の個人用のメモ。

調べながら、メモしている感じなので、

個人的な見返してどういう経緯だったとかを確認するようなので、

調べる中で気になった関連事項についても個人用に書いているので、

個別に必要な情報は、記事内にもある公式情報を参照してもらえると。

試した内容

試した内容としては、

ローカル環境でファイル修正
リポジトリに反映
サーバー環境に反映

という流れ。

このシンプルな流れを試す。

前提

前提としては、

SSHポートは実行時にオープン
SSH鍵情報はパスフレーズなし

という感じ。

試す時だけ、ポートいったん開けて、

鍵情報もとりあえず、

パスフレーズなしをこのために作って試しました。

実施内容

今回は、

HTMLファイル用意して、

それが反映されるかを確認。

HTMLファイルの中身は任意で省略。

ファイル構成は

├── .github
│   └── workflows
│       └── ci.yml
├── README.md
└── index.html

この感じ。

この中のworkflowファイルを準備。

name: Deploy to Production

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: Sample-github-actions
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Debug HOST secret
        run: |
          echo "===================="
          echo "HOST secret value: ${{ secrets.HOST }}"
          echo "===================="

      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.PRIVATE_KEY }}
          script: |
            cd /var/www/html/sample
            pwd
            ls -l
            git pull origin main

この中の

    environment: Sample-github-actions

ここに

Githubの管理ページで設定した、

SecretsのEnvironmentを設定。

これがないと、

うまくその中の変数が取得できなかった。

その変数を

        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.PRIVATE_KEY }}

のように使っている。

これ、

SSHでの接続をしているので、

Githubの管理ページの方から、

「Settings」- 「Secrets and variables」

にそれぞれを設定。

Nameが、HOSTやUSERのような変数名。

ここで作成する「Environments」が、

    environment: Sample-github-actions

となります。

基本的にこの設定と、

先ほどのコードで、

SSH設定が間違っていなければ、

問題なく、

Github Actionsで

サーバーにも反映できました。

ConoHa VPSでのNginx経由で、DockerコンテナのWebページが表示できない件

Debian系（Ubuntu）で、

サーバー環境の１つとして、

何かないかと調べたところ、

ConoHa VPS

が選択肢になり、

試すことになったので、

その際の個人的なメモ。

今回は、

Nginxを設定したけれど、

なぜか、

表示できなかった件を調査。

ConoHa VPSとは

GMOが提供しているVPSで、

国内リージョン
SSD高速
長期割りでお得
個人でも使いやすい
GUI管理画面もわかりやすい

という点で、

個人的には、他のVPSよりも、

こちらのConoHa VPSを選択しました。

公式情報としては、

以下も参照。

Conoha VPS

アクセスできない

Nginx

実際に調べながら、

試してみましたが、

ConoHa VPSでは、

セキュリティグループ

という名前で、

サーバーへのIN/OUTのファイアウォールを設定するようです。

のなかで、

「ネットワーク」

を選択して、

その中に

「セキュリティグループ」

があるので、

そのセキュリティグループを変更することで、

自分が設定したいIP制限が可能になります。

セキュリティグループでのIP制限

こちらについては、

80, 443ポートを対応したが、

アクセスに関してはうまくいかず。

ConoHa VPSでのIP制限の方法

Nginx挙動確認

そもそも、

Nginxが起動中か？

systemctl status nginx

を確認したら、

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running)

なので、起動中。

Nginxがローカルで応答してるか

curl -I localhost

で確認したら、

curl -I localhost
HTTP/1.1 200 OK
Server: nginx/1.24.0 (Ubuntu)
Date: Mon, 08 Sep 2025 08:43:47 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 02 Sep 2025 08:40:44 GMT
Connection: keep-alive
ETag: "68b6ad8c-267"
Accept-Ranges: bytes

で動いている。

DNSの確認

DNSの名前解決を確認する

digというコマンドで確認

dig sample.com +short

で確認したら、

111.111.111.111

のように、

IP表示されるが、

対象サーバーIPと一致なので問題なし。

ポート指定

Dockerコンテナのポート指定で確認。

curl -I localhost:8081

で確認したら、

$ curl -I localhost:8081
HTTP/1.1 200 OK
X-Powered-By: Next.js
Content-Type: text/html; 
charset=utf-8
Content-Length: 59368
Vary: Accept-Encoding
Connection: keep-alive
Keep-Alive: timeout=5

でレスポンスくる。

コンテナ内のNextjs自体の起動確認

Nextjsは、

試しに動かすと

ready - started server on 0.0.0.0:8081, url: http://localhost:8081
Browserslist: caniuse-lite is outdated. Please run:
　:
wait  - compiling...
event - compiled successfully in 156 ms (172 modules)

なので、

とりあえず、動く。

コンテナ内でのアクセス確認

curl http://localhost:8081

で確認すると

error - Error: connect ECONNREFUSED 127.0.0.1:33491
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1532:16) {
  errno: -111,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 33491
}

となる。

これか。

確認したら、

.env

を開発時から持ってくるの忘れてた。

こちら対応。

コンパイル等も問題なくなった。

しかし、同じエラー

SSL証明書設定忘れ

上記の環境ファイルは、

忘れてたので、

そちらは必要なのだが、

その上で、

このサイトにアクセスできません
sample.com で接続が拒否されました。

となる、

なぜだ。

あ、もしかしてと思い、

SSL証明書を確認したら、

設定していない、

というか、設定した記憶がない。

それなのに

https://sample.com

というアクセスをしていた。

http://sample.com

のようにアクセスしてみたら、

問題なく動いた。

こちら、調整漏れで、

他の環境と同じようにいけると思って、

しっかり、設定してなかったのがダメだね。

こちら、

今回のメモ、以上。

Nextjsでのbuildで「Creating an optimized production build …Killed」が発生した件のメモ。

Nextjsでプロジェクト作成して、

本番環境でビルドするときに、

Creating an optimized production build …Killed

が起きたので、

その時の内容などを、

個人用にメモをしておく。

完全な個人用の断片メモ。

エラーの事象と状況

エラーについては、

開発環境でのビルドではエラーが発生しない
本番環境でのビルドではエラーが発生する

という状況。

内容としては、

info  - Need to disable some ESLint rules? 
Learn more here: https://nextjs.org/docs/basic-features/eslint#disabling-rules
info  - Linting and checking validity of types
Browserslist: browsers data (caniuse-lite) is 9 months old. Please run:
  npx update-browserslist-db@latest
  Why you should do it regularly: https://github.com/browserslist/update-db#readme
info  - Creating an optimized production build ...Killed

というエラー。

試したこと１：npx対応

上記エラーの中で、

https://github.com/browserslist/update-db#readme

のなかで、

npx update-browserslist-db@latest

を実行。

こちらだけでは解決せず。

メモリ不足

本番環境の管理画面での各種使用率を確認してみたら、

CPU挙動が不安定になっているタイミングで、

メモリ使用率がかなり高くなり、

１００％近くなっていた。

そのため、

ビルド時のメモリ使用上限を決めて、

そちらで対応することを試みた。

実行コマンドはこちら

node --max-old-space-size=1024 node_modules/.bin/next build

上記実行で、

info  - Need to disable some ESLint rules? Learn more here: https://nextjs.org/docs/basic-features/eslint#disabling-rules
info  - Linting and checking validity of types
info  - Creating an optimized production build
info  - Compiled successfully
info  - Collecting page data ..zsh: killed     node --max-old-space-size=1024 node_modules/.bin/next build

うまく途中まではいっている気がする。

自分が使用している環境がミニマム構成なので、

もう少し削ってみる

node --max-old-space-size=512 node_modules/.bin/next build

こちらを実行すると、

info  - Need to disable some ESLint rules? Learn more here: https://nextjs.org/docs/basic-features/eslint#disabling-rules
info  - Linting and checking validity of types
info  - Creating an optimized production build .
<--- Last few GCs --->

[2734995:0x1e2d3380]   122541 ms: Scavenge (reduce) 506.1 (520.3) -> 505.8 (520.8) MB, 5.7 / 0.0 ms  (average mu = 0.321, current mu = 0.414) allocation failure
[2734995:0x1e2d3380]   122923 ms: Mark-sweep (reduce) 506.4 (520.8) -> 500.6 (520.6) MB, 286.3 / 0.0 ms  (+ 578.7 ms in 126 steps since start of marking, biggest step 16.1 ms, walltime since start of marking 1035 ms) (average mu = 0.340, current mu = 0.35

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb200e0 node::Abort() [node]
 2: 0xa3c157 node::FatalError(char const*, char const*) [node]
 3: 0xd083ae v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xd08727 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xee9785  [node]
 6: 0xeea2cc  [node]
 7: 0xef8269 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 8: 0xefb5ac v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 9: 0xec000c v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
10: 0x123695b v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
11: 0x1640839  [node]
zsh: abort (core dumped)  node --max-old-space-size=512 node_modules/.bin/next build

になるので、

そもそも、サイズ小さくしすぎたら、

時間かかって終わるのではなく、

メモリ足りなさすぎて落ちる。

試したこと

メモリ使用率高いの何かを

ps aux --sort=-%mem | head

で調べたら、

php-fpmが高かったので、

リスタートすることで、

不要な確保メモリの解放で、

メモリ使用量が減るかと思って試す。

sudo systemctl restart php8.1-fpm

こちらでメモリ使用量が減った。

この後、

npm run build

をやると、

リミット無いせいか、

またエラーになったので、

node --max-old-space-size=1024 node_modules/.bin/next build

で程よく上限をかけて実行。

info  - Need to disable some ESLint rules? Learn more here: https://nextjs.org/docs/basic-features/eslint#disabling-rules
info  - Linting and checking validity of types
info  - Creating an optimized production build
info  - Compiled successfully
info  - Collecting page data
info  - Generating static pages (9/9)
info  - Finalizing page optimization
 :
λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerSideProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)

でうまくいったので、完了。

DockerコンテナでのLaravelのMigrationが「SQLSTATE[HY000] [2002] Connection refused」のエラーになった件

Laravelを使用していて、

Dockerコンテナの環境で、

ネットワークを構築して、

Migrationを実行をした時に、

SQLSTATE[HY000] [2002] Connection refused

のエラーが発生したが、

この件、なぜか調べたときの内容。

ただの環境ファイルを置いてるつもりで置けてなかった

という初歩の問題だったのだが、

確認した流れなど、

備忘録として、個人的にメモ。

Laravelのバージョン

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 9.52.4

というバージョンであることがわかります。

事象

Dockerでの環境構築で、

データベースの初期化で、

php artisan migrate

でのマイグレーションを実施。

その際に、

SQLSTATE[HY000] [2002] Connection refused

のエラーが発生。

エラーログ詳細としては、

Illuminate\Database\QueryException 

SQLSTATE[HY000] [2002] Connection refused
 (SQL: select * from information_schema.tables where table_schema 
= forge and table_name = migrations and table_type = 'BASE TABLE')

というエラーが起きていた。

調査途中メモ

調査途中で、

.env

の環境設定がおかしいのかと思ったが、

DB_CONNECTION=mysql
DB_HOST=sample_host
DB_PORT=3306
DB_DATABASE=sample_database
DB_USERNAME=sample_user
DB_PASSWORD=sample_password

としており、

この点に関しては、

コンテナ間のMySQLの通信も、

コマンドで確認済み。

エラーログを再確認したところ、

SQLSTATE[HY000] [2002] Connection refused
 (SQL: select * from information_schema.tables where table_schema 
= forge and table_name = migrations and table_type = 'BASE TABLE')

でこれの

table_schema = forge

となっているので、

configの設定の中で、

環境変数の

'database' => env('DB_DATABASE', 'forge'),

この値がうまく環境変数の値として読み込めていないと推測。

原因

原因としては、

環境変数ファイルがプロジェクト直下に置いてなかった

というだけでした。

単純ですが、

今後のために、

なぜ、これを自分が起こしてしまったのかを考えたら、

コンテナ初期構築時に設定ファイルコピーを忘れてた

ということになりますね。

そのため、結果として、

環境変数ファイルをボリュームマウントの対象フォルダに入れてなかった

ということが起きていたのです。

この辺りは初期構築時の構築処理にまとめておく必要がありますね。

その辺りも今後、対策するので、また機会があればメモ。

Laravel+Nextjsで「504 Gateway Time-out」「connect() failed (111: Connection refused」の件

アプリケーションを作成していく中で、

タイムアウト周りのエラーが発生して、

その調査や対応方法の模索で、

色々と時間が取られることは多い。

今回の事象としては、

「504 Gateway Time-out」

がNextjs上で発生しており、

Nginxのログでも、

「connect() failed (111: Connection refused」

が発生していたので、

この事象が発生したことに関して、

メモとして残しておく。

Laravelのバージョン

実行環境のLaravelのバージョンとしては、

php artisan --version

のコマンドで確認したところ、

Laravel Framework 9.23.0

というバージョン。

Nextjsのバージョン

使用しているNextjsに関して、

package.json

で確認すると、

"next": "12.2.2",

というバージョン。

エラー内容

Nginxのログを確認すると、

connect() failed (111: Connection refused) while connecting to upstream

という形で、

エラーが発生。

また、Nextjsのログにも、

---body---
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx/1.21.4</center>
</body>
</html>
---body---

このように、

タイムアウトのエラーログが残っていた。

「join」のテーブル条件に、

「function」で関数を与えてあげること。

上記のように実装することで、

複数条件の結合が完了。

忘れた時はここを思い出せば良いので、

リンクをブックマークにメモ。

NextjsでのJest導入時の個人的なメモ。

Nextjsでプロジェクト作成するときの、

各種初期導入して、

最新情報を取得して、

Github Copilotのみで進めれるかなとか思ったが、

うまく挙動せず、

諦めて、

公式情報を確認して、

１つずつ、ペコペコやったので、

完全な個人用の断片メモ。

メモ：パッケージマネージャ

npm、yarn、pnpmは、JavaScript/TypeScriptプロジェクトで使われるパッケージマネージャです。

npm

Node.js公式の標準パッケージマネージャ
コマンド例：npm install
依存関係を node_modules にフラットにインストール

yarn

Facebookが開発したnpm互換のパッケージマネージャ
高速なインストール、ロックファイルによる一貫性
コマンド例：yarn add
一部npmより高速・安定

pnpm

高速・省スペースなパッケージマネージャ
依存パッケージをグローバルに保存し、プロジェクトごとにリンク
コマンド例：pnpm install
ディスク容量を大幅に節約できる

公式サイトの情報

公式サイト

まずは、公式サイトで確認

自分が確認した時点で、

以下のコマンド。

自分が使用してないパッケージマネージャもメモ残す。

npm

npm install -D jest jest-environment-jsdom @testing-library/react @testing-library/dom @testing-library/jest-dom ts-node @types/jest

yarn

yarn add -D jest jest-environment-jsdom @testing-library/react @testing-library/dom @testing-library/jest-dom ts-node @types/jest

pnpm

pnpm install -D jest jest-environment-jsdom @testing-library/react @testing-library/dom @testing-library/jest-dom ts-node @types/jest

が初期導入コマンドとなっていました。

リンクをメモしておきます。

https://nextjs.org/docs/app/guides/testing/jest#manual-setup

Jestの初期設定ファイル生成生成

上記の公式にもある通りに進める。

初期設定ファイルの構築が行えるので、

コマンドからその点を行う。

実行コマンドはこちら

npm init jest@latest
# or
yarn create jest@latest
# or
pnpm create jest@latest

上記実行で、

? Would you like to use Jest when running "test" script in "package.json"? › (Y/n)

と聞かれるので、

追加してもらうので、

「y」で実行する。

? Would you like to use Typescript for the configuration file? › (y/N)

自分の環境では、

TypeScriptの環境なので、

「y」で実行。

? Choose the test environment that will be used for testing › - Use arrow-keys. Return to submit.
❯   node
    jsdom (browser-like)

Nextjsで

画面側のテストも実行したいので、

「jsdom (browser-like)」を選択。

? Do you want Jest to add coverage reports? › (y/N)

品質管理やテストの抜け漏れ確認に役立つので、

基本的には「y」を選んで良いのではと。

? Which provider should be used to instrument code for coverage? › - Use arrow-keys. Return to submit.
❯   v8
    babel

Next.jsやTypeScriptプロジェクトではv8が推奨のはず、
「v8」を選択。

? Automatically clear mock calls, instances, contexts and results before every test? › (y/N)

「各テストの前に、モック（mock）の呼び出し履歴・インスタンス・コンテキスト・結果を自動的にクリアしますか？」

用語解説

mock（モック）：テスト用のダミー関数やオブジェクト
calls（呼び出し履歴）：モックが呼ばれた記録
instances（インスタンス）：モックで生成されたオブジェクト
contexts（コンテキスト）：関数の実行時の状態
results（結果）：モックの返り値など

これは「y」を選択。

テスト用ファイル準備

こちらも公式サイトをそのまま使用。

配置としては、

自分の環境では、

srcフォルダを使用してるので、

├── src
│   ├── __tests__
│   │   └── page.test.jsx

この配置で、

あとは、公式のコードを使用。

import '@testing-library/jest-dom'
import { render, screen } from '@testing-library/react'
import Page from '../app/page'
 
describe('Page', () => {
  it('renders a heading', () => {
    render(<Page />)
 
    const heading = screen.getByRole('heading', { level: 1 })
 
    expect(heading).toBeInTheDocument()
  })
})

環境ファイル調整

自分の環境では、

モジュールパスのエイリアスを使っているので、

Optional: Handling Absolute Imports and Module Path Aliases
If your project is using Module Path Aliases, 
you will need to configure Jest 
to resolve the imports by matching the paths option 
in the jsconfig.json file with the moduleNameMapper option 
in the jest.config.js file. For example:

こちらに該当するので、

sconfig.json or jsconfig.json

のコードを調整。

{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "bundler",
    "baseUrl": "./",
    "paths": {
      "@/components/*": ["components/*"]
    }
  }
}

これは差分のみ追加でした。

それと、

jest.config.js

こちらは、

moduleNameMapper: {
  // ...
  '^@/components/(.*)$': '<rootDir>/components/$1',
}

をConfig配下に追加しました。

テスト実行

テスト実行で試します

npm run test

実行すると、

# npm run test

> portfolio-ui-nextjs@0.1.0 test
> jest

 PASS  src/__tests__/page.test.jsx
  Page
    ✓ renders a heading (67 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        4.706 s
Ran all test suites.

という形でうまく、

テストが完了。

環境ファイルの読み込みで、.envファイルの読み込みではなく、環境設定値が読み込まれてしまっていた件

Nodeで環境ファイルを読み込む際に、

なぜか、

.env

のファイルの値ではなく、

なぜか別の値が入っているなとなり、

その点について、

値を確認していくと、

環境設定値が入ってしまっていたので、

その点を調査して確認していた。

この時の確認などを、

今後も必要に応じてやりそうな気がするので、

自分用にメモ。

起きた事象は？

Nodeで

require('dotenv').config({ path: './.env' });

の感じで、

環境ファイルを読み込んでいたが、

なぜか、

実行環境の環境ファイルの値にならない

という点がおきました。

上記の実行環境では、

環境ファイル自体は正しく配置されている
読み込みパスについても問題ない
新規設定値についてはうまく読み込める

という形でした。

例えば、

環境設定ファイルとして、

.env

を準備して、

TEST="sample data"

のようにすると、

うまく読み込めて値が使えました。

しかし、

他のプロジェクトなどで使っていた環境設定変数があれば、

なぜか、

このプロジェクトの環境ではない値が、

取得されてしまうという事象でした。

シェルの環境変数を読んでしまってた

環境変数自体に、

なんで別の値が入っていたかというと、

シェルの環境変数を読んでしまっていた

というシンプルなことでした。

確認コマンド

env

または、

それをgrepして、

env | grep -E 'EXIST_VARIABLE'

のように確認できます。

やってることのイメージとしては、

┌──────────────────┐
│ OS / シェルの環境変数(envコマンドで確認) │
└───────┬──────────┘
        │（Node.js 起動時に引き継がれる）
┌───────▼──────────┐
│ process.env（Node.js内部で参照できる） │
└───────▲──────────┘
        │
    dotenv が .env を読み込んで追加

こんな感じ。

シンプルだけど、

入れてないとか思ってたけれど、

シェルの環境変数にしてしまっていたものが、

影響を及ぼしていたので、

その点、学びになった。

シェルの環境変数の削除（一時的に、現在のターミナルのみ）

環境変数の削除自体は、

一時的に消すだけなら、

unset EXIST_VARIABLE

で削除できます。

Nextjsでの初期プロジェクト導入時の個人的なメモ。

Nextjsでプロジェクト作成するときの、

各種初期導入のYes/Noがなんだったっけ、

となってしまうことがあるので、

現時点のバージョンでの、

初期導入時のメモ。

あくまで個人的なメモなので、

推奨設定ではない点が注意。

公式サイトの情報

公式サイト

まずは、公式サイトで確認

自分が確認した時点で、

npx create-next-app@latest

が初期導入コマンドとなっていました。

リンクをメモしておきます。

https://nextjs.org/docs/app/getting-started/installation

Installationメモ

Terminal Command

実行コマンドはこちら

npx create-next-app@latest

What is your project named? my-app

これはプロジェクト名。

任意のものを設定。

Would you like to use TypeScript? No / Yes

TypeScript導入するか。

導入するので、Yes。

Would you like to use ESLint? No / Yes

ESLintを導入するか。

導入するので、Yes。

Would you like to use Tailwind CSS? No / Yes

Tailwindを導入するか。

レイアウト作成で使うのでYes。

Would you like your code inside a `src/` directory? No / Yes

プロジェクト構造整理用のsrc/ディレクトリ配置選択。

src配置がデフォルトになってきているようなのでYes。

Would you like to use App Router? (recommended) No / Yes

これはNext.jsの新ルーティング仕様。

Yesが公式推奨で、将来の標準の認識なのでYes。

Would you like to use Turbopack for `next dev`? No / Yes

開発速度優先ならYes、安定重視ならNoっぽいかなと。

今回は、プロトタイプなのでYes。

Would you like to customize the import alias (`@/*` by default)? No / Yes

パスのエイリアス。

@/を使うと

import MyComp from "@/components/MyComp"

みたいなこと。

自分は楽なのでYes。

導入後も変えれるはずなので、心配ならNo。

What import alias would you like configured? @/*

@/*はプロジェクトのsrc/直下を指すエイリアスで、

@/components/Button → src/components/Button と解決されます。

デフォルトのままが良いかと思うので、

そのままの設定。

ビルドのエラーは調整済み

ビルドについてもエラーになったが、

以下の対応をやって、

問題なくビルドは完了している。

Initializing project

実行したら、

Installing dependencies:
- react
- react-dom
- next

Installing devDependencies:
- typescript
- @types/node
- @types/react
- @types/react-dom
- @tailwindcss/postcss
- tailwindcss
- eslint
- eslint-config-next
- @eslint/eslintrc

added 336 packages, and audited 337 packages in 41s

137 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
Success! Created portfolio-ui-nextjs

という形でうまくインストールが完了。

docker-composeのbuildがDebian系で「exit code: 100」のエラーになった件

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

https://packages.debian.org/debian-archive-keyring

こちらを参考にしてください。

今回は、

docker-compose

を使っているのですが、

ビルドする中で、

failed to solve: executor failed running
[/bin/sh -c apt-get update]: 
exit code: 100

このようなエラーが発生。

今回の件を、

自分の備忘録として、

忘れないうちにメモを残しておきます。

エラー内容

実行処理としては、

docker-compose -f docker-compose.sample.yml build

という形で、

docker-compose.sample.yml

というファイルを準備して、

そちらをビルドする流れてで進めていました。

このビルドを実行したところ、

failed to solve: executor failed running
[/bin/sh -c apt-get update]: 
exit code: 100

このエラーが発生しました。

考えられる原因

こちら動かすymlファイルは、

# base
FROM php:8.1-fpm

 :

# apt
RUN apt-get update

という感じで、

php fpmベースでしたが、

他のアプリケーション構築でも使っており、

正常に挙動しており、

なぜだろうかとは思っていました。

考えられる原因としては、

Dockerビルド時のリソース不足
ネットワークの問題
Dockerのバージョンに関する問題
Dockerのイメージやコンテナ・キャッシュによる問題
Debian系の問題

が考えられます。

最終的には、

「Dockerのイメージやコンテナ・キャッシュによる問題」
　＋
「Debian系の問題」

ということが原因かなと思いました。

この辺りは対処加えて、

原因として考えられることなどはメモ。

Debian系の仕様変更

この点は、ChatGPTで確認してみたところ、

2025年初頭、

DebianのAPTリポジトリ署名鍵が更新され、

古い鍵が期限切れになったため、

古いイメージでは署名検証に失敗するようになった変更です。

一次情報は Debian の公式 debian-archive-keyring パッケージの changelog に載っています。
ここに 2025 年の鍵更新（旧鍵期限切れ・新鍵追加）の記録があります。

パッケージ情報

Changelog（2025年の更新記録あり）

https://metadata.ftp-master.debian.org/changelogs/main/d/debian-archive-keyring/debian-archive-keyring_2025.1_changelog

Add 2025–2027 archive signing keys
Retire expired 2023 keys
のような記述があり、これが今回の署名エラーの直接の原因です。

とのことです。

個人的に、

このDebian系の署名エラーの対応で、

そのまま、apt対応の追加でいけるかなと思いましたが、

うまくいきませんでした。

Dockerのイメージやコンテナ・キャッシュによる問題

この点に関しては、

php fpm 8.1パッケージ自体が、

最新のDebian系に対応していないということかなと思いましたが、

他のコンテナで同じパッケージを使用しており、

直近では動いていた（ビルドは長らくやってませんでしたが）。

この点で、

このパッケージ自体が対応できていないのであれば、

今後、使えないのかなと思いながら、調査していました。

aptでのupdateをせずにビルドをするとうまくいく、

そして、

立ち上げた環境で、

apt update

をやると同じように、

exit code: 100

のエラーになるので、

この時点のままでのエラー解決は諦めました。

その上で、

最後の考えられることとして、

現在の自分の環境にあるDockerイメージや、

使っている・使っていたコンテナ・キャッシュ周りが影響して、

うまくビルドが動いていないことが考えられます。

キャッシュされたイメージやコンテナが原因で、

問題が発生していることもあるようなので、

まずは、（これは解決策ではありません）

docker-compose -f docker-compose.sample.yml build --no-cache

こちらで、

ビルドしているキャッシュ自体を使わないで、

ビルドプロセスを試してみます。

しかし、同じようなエラーとなります。

ビルドプロセスで使用されるベースイメージが更新された場合など、

キャッシュされた状態が原因でビルドが失敗することがあるようなので、

Dockerイメージやコンテナのキャッシュをクリア

を行います。

コマンド

docker system prune -a

こちらを実行すると、

今までのイメージやキャッシュがクリアされます。

こちらでクリアしたのちに、

再度、ビルドプロセスを試します。

docker-compose -f docker-compose.sample.yml build

こちらを実行したら、

うまくビルドが完了しました。

これで解決ですね。

コマンドメモ

今回の

docker system prune

こちらのメモ。

docker system prune は Docker 内の未使用リソースをまとめて削除します。
実行時の挙動は以下の通りです（確認あり、-fで確認スキップ）。

削除対象：

停止中のコンテナ
未使用のイメージ（dangling image）
未使用のネットワーク（ただし bridge, host, none は残す）
ビルドキャッシュ（docker builder prune 相当）

オプション：

-a : 参照されていないすべてのイメージも削除（danglingだけでなくタグ付きも）
--volumes : 未使用のボリュームも削除（データ消えるので注意）

このコマンドで古いDebianベースのキャッシュレイヤーが消え、
再ビルド時に最新のベースイメージがpullされて署名エラーが解消しました。

AnsibleでのDockerコンテナ内のコード実行でコンテナを停止してしまった件

Debian系（Ubuntu）で、

サーバー環境の中で、

処理等の管理で良い方法を探していて、

Ansibleを使っている方がいらっしゃるようなので、

自分の方でも試してみることにした。

今回は、

Ansibleを調べるところから、

試すまでを色々することになったので、

その際の個人的なメモ。

Ansibleの概要と簡易試した件

Ansibleについては、

以下の記事に、

簡易に試した時と調べた概要をメモしている。

Ansibleを試した件

AnsibleでのDockerコンテナ内のコード実行

元々、うまく挙動していなかった（コンテナが停止していたコード）

コード

- hosts: sample
  gather_facts: yes
  tasks:
    - name: Run sample command in Docker container
      docker_container:
        name: container_name
        command: "実行コマンド"
        detach: true

これで、

コンテナが停止してしまっていた。

これを、

community.docker.docker_container_exec

を使うことで、

実行中のコンテナで

必要なコマンドを実行できる。

コード

- hosts: sample
  gather_facts: yes
  collections:
    - community.docker
  tasks:
    - name: Execute Django sample command inside running container
      community.docker.docker_container_exec:
        container: container_name
        command: >
          sample command

を行うと、

PLAY [sample] ************************

TASK [Gathering Facts] ***************
 :
 :
PLAY RECAP ****************************
your-ip :ok=2

のような結果が出たので、

うまく挙動しました。

Ansibleを試した件

Debian系（Ubuntu）で、

サーバー環境の中で、

処理等の管理で良い方法を探していて、

Ansibleを使っている方がいらっしゃるようなので、

自分の方でも試してみることにした。

今回は、

Ansibleを調べるところから、

試すまでを色々することになったので、

その際の個人的なメモ。

Ansibleとは

Ansibleについては、

簡潔にまとめると、

IT自動化ツール
エージェントレス（SSH接続）
YAML形式で構成管理
冪等性（何度実行しても同じ結果）
モジュールベースで拡張可能

ということらしい。

簡潔にまとめると、

サーバ構成・アプリ展開・運用自動化をするツール

ということになるのかなと。

Ansibleの公式情報

実際に調べながら、

試してみるにあたって、

公式情報はどこなのかを調べてメモ。

https://www.redhat.com/en/ansible-collaborative

Ansibleについて

公式情報で、個人的にメモしたいところ。

引用しながら、

これ、公式より引用。

Module code is executed locally on the control node.

モジュールコードはコントロールノード上でローカルに実行される

これは、

「Network Automation側」

のことなのかなと。

Module code is copied on the managed node, executed, then removed.

モジュールコードはマネージドノードにコピーされ、実行され、その後削除される

これは、

「Server Automation側」

のことなのかなと。

Ansibleはモジュールを

マネージドノード（対象サーバー）に送って、そこで実行して削除する。

ということなのかと。

参考：公式より引用

Ansibleを試す

MacにAnsibleを導入

コマンド

brew install ansible

inventoryファイルを作る

ファイル名

vim inventory.ini

内容サンプル

[sample]
your-ip ansible_user=root ansible_ssh_private_key_file=~/.ssh/id_rsa

Playbookを作る

ファイル名

vim playbook.yml

内容

- hosts: sample
  gather_facts: yes
  tasks:
    - name: Display hostname
      debug:
        msg: "The hostname is {{ ansible_hostname }}"

これで、

実行コマンド

ansible-playbook -i inventory.ini playbook.yml

を行うと、

PLAY [sample] ************************

TASK [Gathering Facts] ***************
[WARNING]: 
Platform linux on host your-ip is using 
the discovered Python interpreter
at /usr/bin/python3.8, 
but future installation 
of another Python interpreter could change
the meaning of that path. 
See https://docs.ansible.com/ansible-
core/2.18/reference_appendices/interpreter_discovery.html 
for more information.
ok: [your-ip]

TASK [Display hostname] ***************
ok: [your-ip] => {
    "msg": "The hostname is Sample-Hostname"
}

PLAY RECAP ****************************
your-ip :ok=2

のような結果が出たので、

うまく挙動しました。

ConoHa VPSでのIP制限の方法

Debian系（Ubuntu）で、

サーバー環境の１つとして、

何かないかと調べたところ、

ConoHa VPS

が選択肢になり、

試すことになったので、

その際の個人的なメモ。

今回は、IP制限をどうしたら良いかを調査。

ConoHa VPSとは

GMOが提供しているVPSで、

国内リージョン
SSD高速
長期割りでお得
個人でも使いやすい
GUI管理画面もわかりやすい

という点で、

個人的には、他のVPSよりも、

こちらのConoHa VPSを選択しました。

公式情報としては、

以下も参照。

Conoha VPS

IP制限の方法

実際に調べながら、

試してみましたが、

ConoHa VPSでは、

セキュリティグループ

という名前で、

サーバーへのIN/OUTのファイアウォールを設定するようです。

のなかで、

「ネットワーク」

を選択して、

その中に

「セキュリティグループ」

があるので、

そのセキュリティグループを変更することで、

自分が設定したいIP制限が可能になります。

セキュリティグループの作成

実際に自分が設定したい制限を、

「セキュリティグループ」

を作成することで管理します。

セキュリティグループを作成する画面は、

左メニューの

「セキュリティ」

から

「セキュリティグループ」

を選択することで、

管理画面が開くので、

そちらで、

セキュリティグループの変更
セキュリティグループの追加

などを行うことができます。

セキュリティグループ内の設定項目

セキュリティグループを設定する中で、

設定項目として、

通信方向
イーサタイプ
プロトコル
ポート範囲
IP/CIDR

があります。

基本的に許可を増やしていくので、

不要な許可設定は増やさないことが大切

かと個人的には考えています。

その中で、

通信方法：IN

イーサタイプ：IPv4

プロトコル：TCP

ポート範囲：自分が使いたいポート

IP/CIDR：自分がアクセスする元のIPアドレス

だけ設定しました。

上記を追加設定して、

そのセキュリティグループとして使うことで、

うまく挙動しました。

【個人用メモ】画面処理の自動化のためのSeleniumの基礎と始める準備まで

画面操作に関して、

処理を自動化しようとして、

Seleniumを使って、

自動化をすることにした。

ある程度、

使用してきたが、

忘れないうちに、

個人用にメモを残しておく。

Seleniumとは？

Sleniumは、

シンプルに説明すると、

Webブラウザを自動操作するテスト自動化ツール

と言える。

実際に動かすと、

ブラウザが自動起動
必要ページ（URL）へのアクセス
画面項目内容の取得
画面上のボタン等の押下

などを行うことができます。

使っていくと、

テストなどで便利なので、

必要に応じて取り入れていくと、

便利なツールです。

Seleniumの公式情報

すでに色々と調べながら、

必要の応じて使っていたが、

公式情報は時々見るので、

こちらを参照。

バージョンの情報やドライバなど、

最新情報は公式情報を見る方が良い。

https://www.selenium.dev

Seleniumを始める準備

Seleniumを使うにあたって、

Seleinum本体の取得
ブラウザのドライバの取得
実際の処理の実装

がベースになります。

最後の実際の処理の実装は、

各種プログラミング言語に対応していますが、

よく使われるPythonでメモ残します。

Selenium本体の取得や

ブラウザのドライバの取得に関しては、

私の環境をベースに以下がメモ。

Seleinum本体の取得

Seleniumの本体の取得に関しては、

実際の実装を進めるプログラミング言語に関わるので、

公式情報の

「Dowonload」

で各種プログラミング言語があるので、

その中で、

自分が使いたいプログラミング言語の

「Stable」

から情報を取得していくことになります。

例えば、

Pythonであれば、

上記のページに行くと説明があり、

以下のコマンドで導入。

コマンド

pip install -U selenium

公式情報はこちら。

https://www.selenium.dev

ブラウザのドライバの取得

先ほどの確認したページで、

細かくは情報が記載があるので、

そちらを参照にする方が良い。

最新情報は違う可能性もあるので、公式サイト参照

というのはありますが、

私が見た時のリストを、

こちらにも載せておきます。

公式サイトの情報の引用

ブラウザ種類	取得サイト
Chrome	https://chromedriver.chromium.org/downloads
Edge	https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver/
Firefox	https://github.com/mozilla/geckodriver/releases
Safari	https://webkit.org/blog/6900/webdriver-support-in-safari-10/

上記などから、

使用するブラウザのドライバを取得。

実際の処理の実装

実際の処理についても、

各プログラミング言語について、

基礎部分のサンプルがあるので、

公式サイトを見てみると良い。

例えば、

Pythonなら、

from selenium import webdriver


driver = webdriver.Chrome()
driver.get('https://selenium.dev/')
driver.quit()

という感じで、

実際にうまく動いたので、

それをベースに試したら良い。

他、試したときの細かなエラー等については、

別の記事でメモしていく予定。

UbuntuでSystemedの常駐プロセス化で動いている設定を確認した件

Debian系（Ubuntu）で、

Systemedを使って、

プロセス常駐化をしていたが、

設定の情報を確認する方法や、

停止する方法が把握できておらず、

ちょっと戸惑ったので、

この時の対応を、

今後も必要に応じてやりそうな気がするので、

自分用にメモ。

Systemedとは？

systemdは、

Linuxで

プロセスの自動起動
プロセスの常駐化
プロセスの依存管理
プロセスのログ収集

などを統一的に管理するための仕組み。

個人的に使うことが多い、

pm2やscreenは、ユーザー単位のツール、

systemedは、OSレベルの管理ツール

という認識。

この辺りは、もう少し、systemedの挙動を知りたいところ。

経緯：プロセスが停止できない・再起動続いてしまう

すでに調べながら、

プロセスの常駐化を設定して、

止まらないようにSystemedで設定済みだった。

しかし、

プロセス単体を停止しても、

Systemedの仕組みによって再起動してしまう。

これ、止めれなくなってしまったという流れ。

この状況は、Systemedの設定が正しくできており、

再起動自体がうまく行っている証拠ではあるのだが。

Systemedの状況確認や停止など。

Systemedに関して、

設定の情報を確認する方法
停止する方法

を調べながらやったので、

それをメモ。

設定の情報を確認する方法

Systemedの設定情報確認で、

自分が使用しているシェルの設定を確認。

確認コマンド

grep -r shell.sh /etc/systemd/system

上記で、

/etc/systemd/system/sample.service:ExecStart=/sample/sample.sh

のようになるので、

これが設定されている。

また、常駐のためのサービスの設定は、

以下でリスト化できる

systemctl list-units --type=service

こちらで確認したリストのサービスを

常駐化されているので、

以下の方法で停止する。

Systemedの常駐を停止する方法

先ほどの調査したサービスを、

実際に停止するのも、

systemctl

のコマンドを使用する。

停止・無効化のコマンド

systemctl disable --now sample-service

これでプロセスを常駐化するための設定の

サービスを停止して無効化できた。

GithubのWebhookを使用して、本番環境へのデプロイを試した件

本番環境へのデプロイに関して、

自分なりに試そうとする中で、

色々と、

見返して再確認することがあると思うので、

調査した時の内容や、

実際に試したことをメモ。

調べながら、メモしている感じなので、

個人的な見返してどういう経緯だったとかを確認するようなので、

調べる中で気になった関連事項についても個人用に書いているので、

個別に必要な情報は、記事内にもある公式情報を参照してもらえると。

試すことになった経緯

GitHubのWebhookを試そうと思ったのは、

８０ポート、４４３ポートを開放している環境
８０ポート、４４３ポートを開放していない環境

の２つに分けて、

それぞれ、

どのような方法が良いかなと考えて、

GitHubのWebhookを試してみようとなった。

その検討時のメモは、

以下のメモ記事を参照。

Githubからの本番環境へのデプロイで構成別のプラクティスを考えた件

GitHubのWebhookについて

Webhook自体は、

Slack等を使ったとことがあるが、

公式情報にもあるが、

Webhook を使うと、GitHub で特定のイベントが発生するたびに、

外部の Web サーバーに通知を配信できます

ということ。なるほど。

Webhook を使用すると、ソフトウェアシステムで発生するイベントにサブスクライブし、それらのイベントが発生するたびにサーバーに配信されるデータを自動的に受信できます。

Webhook を、API をポーリングする (API を断続的に呼び出す) のではなく、データが発生次第受信します。 Webhook では、Webhook の作成時に 1 度イベントに関与するだけで済みます。

Webhook は、次のようなさまざまなシナリオで使用されます。

外部 CI サーバーで CI (継続的インテグレーション) パイプラインをトリガー。たとえば、コードがブランチにプッシュされたときに Jenkins または CircleCI で CI をトリガーします。

GitHub のイベントに関する通知をコラボレーションプラットフォームに送信。たとえば、プル要求に関するレビューがある場合に Discord または Slack に通知を送信します。

Jira などの外部イシュートラッカーを更新。

プロダクションサーバーへのデプロイ。

GitHub で発生したイベントを監査目的でログに記録。

GitHubの公式

https://docs.github.com/ja/webhooks/about-webhooks

上記の中で、

自分なりにあまり使わない用語なのでメモ。

ポーリングする (API を断続的に呼び出す)

これは、使っていこう。

上記で考えると、

やはり、

通知系イベント発生のために、イベントドリブンという認識。

個人的にちょっと思ったのは、

Webhookとソケットは、

どちらもイベントドリブンの認識だが、

常時かどうかが違うのか？

Webhook：リクエスト型。イベント発生時に一度だけHTTP送信。軽量・シンプル。
ソケット（WebSocket等）：常時接続。双方向通信が可能。リアルタイム性◎、実装は重め。

ということらしい。

違うのは、

「接続維持の有無」と「通信の方向性」

ということ。

上記を簡潔にいうならば、

Webhook：イベント時に一方向で通知（接続は都度）
ソケット：接続維持しながら双方向通信が可能

ということらしい。

なるほど。

Webhookを実際にやっていく上のやること

実際にWebhookを試していくにあたって、

実際にやることを考えたら、

Webhookを利用した軽量アプリで常駐化
GitHubでpushした時にWebhookアプリのURL呼び出すように設定

の２つが必要な認識。

これを取り組んでみる。

常駐アプリを作る

Node.jsで作る準備

npm init -y
npm install express
npm install body-parser

コード

const express = require('express');
const bodyParser = require('body-parser');
const { exec } = require('child_process');

const app = express();
app.use(bodyParser.json());

app.post('/webhook', (req, res) => {
  console.log('📥 Webhook received:', req.body);

  // 任意の処理（例：pull & deploy）
  exec('cd /path/to/your/project && git pull', (err, stdout, stderr) => {
    if (err) {
      console.error('❌ Error:', stderr);
    } else {
      console.log('✅ Git Pull:', stdout);
    }
  });

  res.sendStatus(200);
});

const PORT = 3000;
app.listen(PORT, () => {
  console.log(`🚀 Webhook server listening on port ${PORT}`);
});

上記で

node app.js

などで動かす。

これをドメインと紐づけてアクセスできるようにしたら、

アプリ側は準備オッケー。

GitHubのリポジトリにWebhookの設定を追加

GitHubの対象リポジトリで、

上部メニューの「Settings」に移動

左メニューに「Webhook」を選択。

「Add webhook」で追加

設定してみたのは以下。

項目名	設定値
Payload URL	https://〜の先ほどの常駐アプリのURL
Content Type	推奨はx-www-form-urlencodedだが、とりあえず、application/jsonで挙動確認
Secret	未設定
Enable SSL Verification	オン
Which events would you like to trigger this webhook?	Just the push event

上記をして、

「Add webhook」

こちらで準備完了。

試してたらエラーになった

上記処理で試していたら、

Webhookでアプリにはアクセスあり、

cd /path/to/your/project

は動いたが、

git pull

で、

❌ Git Pull Error: git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

のようにエラー。

パスフレーズ求められているということが原因と考えられる

というところまでは進んだが、

Nodeアプリ側に認証情報を渡すことや、

パスフレーズ省略を試していたが、

うまくこの点を解消できず。

パスフレーズなしなどは、

個人的には、セキュリティ面の上でないかなと思うので、

この点は引き続き、調査を続ける。

もしわかったら、

別の記事にメモ残すかも。

Githubからの本番環境へのデプロイで構成別のプラクティスを考えた件

セキュリティの方針として、

SSHポートについては、

デフォルトとして、

クローズにしている環境があり、

それ以外には、

外部公開用として、

８０ポート、４４３ポートを開放している環境

それとは逆に、

８０ポート、４４３ポートを開放していない環境

がある。

それぞれに対して、

どのように対応するかを考えたときのメモ。

個人的に経緯やその時調べたことなど、

見返すときのために記載。

調べながら、メモしている感じなので、この調べた個人用のメモ、

実際の実施の方針が違うことがあるので、

あくまで、経緯などを参考程度に。

想定するサーバーの構成状況

先ほど、書いている通り、

８０ポート、４４３ポートを開放している環境
８０ポート、４４３ポートを開放していない環境

の２つに分けられる。

このそれぞれがあるが、

前提としては、

SSHポートは基本的にクローズ

という方針で管理している。

上記の構成でどうするかを考える。

GitHub Actionsでも良いのでは？

GitHub Actionsでやるという方法が、

GitHubを使っているとシンプル。

その方法でやるか？

個人的な結論としては、

不要なポートはできる限り開けたくない

という理由でなし。

構成別でどの方法を取るか

構成別で以下の方法で実施予定

サーバ環境	最適パターン	ポート開放状況	理由
コーポレートサイト系	Webhook	80/443オープン	Webhookのみでシンプル。
社内閉鎖環境（完全閉）	Jenkins	全ポートクローズ	外部から接続不要。定期Pullで安全運用

どちらもJenkinsでも良いが、

それぞれの設定や挙動も見たいのもあり、

上記で試そうと思う。

実際に試した内容については別記事で、

必要に応じてメモ。

Github ActionsでデフォルトのSSHポートではなく、HTTPSポートを使用して行う方法を試した件

セキュリティの方針として、

SSHポートについては、

デフォルトとして、

クローズにしている環境については、

GitHub Actions用に、

GitHubのIPアドレスを調べて、

追加するという方法も考えられなくはないが、

別の方法として、

HTTPSポートを使った方法があるようなので、

その方法を試したときの内容を、

自分用にメモ。

シンプルなGitHub Actionsの設定方法

GitHub Actionsに関して、

SSHポートを使った方法については、

以下の記事のメモを参考。

Github Actionsで本番環境への自動反映を試した件

HTTPSポートを使った方法の公式情報

HTTPSポートを介して、

SSHを使用する方法があり、

その点について、

以下の公式情報をまずは把握。

HTTPS ポートを介して SSH を使用する

リポジトリに設定ファイルを追加

リポジトリ内の設定ファイルは、

.github/workflows/deploy.yml を作成

こちらは、

Github Actionsで本番環境への自動反映を試した件

を参考にする。

追加設定する内容として、

remote_port: 443

を追加。

.github/workflows/deploy.yml

作成用（Vim）

vim deploy.yml

ymlファイルのコード

name: Deploy to Production

on:
  push:
    branches:
      - main  # `main` に push されたら実行

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Sync files via rsync
        uses: burnett01/rsync-deployments@4.1
        with:
          switches: -avz --delete
          path: ./
          remote_path: /var/www/html/your_project/  # 本番環境のディレクトリ
          remote_host: ${{ secrets.SSH_HOST }}
          remote_user: ${{ secrets.SSH_USER }}
          remote_key: ${{ secrets.SSH_PRIVATE_KEY }}
          remote_port: 443

Github上にsecrets設定情報を追加

リポジトリのymlファイルで使用する設定情報を、

Github上に設定を追加します。

１．GitHubのリポジトリを開く

２．「Settings」 → 「Secrets and variables」 → 「Actions」を選択

３．「New repository secret」をクリック

４．以下のように、1つずつ追加する
Secret Name: SSH_HOST
Secret Value: 123.456.78.90（←本番サーバーのIP）
「Add secret」をクリックして保存

上記のように設定を進めたら完了。

Ubuntuでメモリ使用率高くなっていたので調査して対応した件

Debian系（Ubuntu）で、

メモリ使用率があがっており、

この状況で調査して、

メモリ使用率を下げていった。

この時の対応を、

今後も必要に応じてやりそうな気がするので、

自分用にメモ。

経緯

使用しているサーバーが、

Ubuntuを使用して、

その上で、各種アプリケーションを動かしていたが、

しばらく、問題ないので放置していたら、

メモリ使用率が、９０％を超えていたので、

このままだとアプリケーション止まりそうな気がしたので、

メモリ使用率を上げてそうなもので、

自分が使用していないものを対応。

メモリ使用率が高いものを確認

メモリ使用率が高いものを確認するには、

以下のコマンドを実施。

確認コマンド

ps aux --sort=-%mem | head -n 20

上記で、

色々とメモリ使用量が高いものがわかるので、

それらのプロセス削除など、

必要有無で判断して対応することになる。

不要プロセス削除

具体的には、

以前、動かしていたKibana+Elasticsearchだと思われるが、

それ関係で、logstashが動いていたので、

このプロセスを削除する。

ps aux --sort=-%mem | head -n 20

確認してみたところ、

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     12345  0.5 12.1 4645400 994328 ?      Sl    2024 2986:45 /usr/bin/java
〜続く〜
/home/user/logstash-6.7.1/logstash-core/lib/jars/slf4j-api-1.7.25.jar 
org.logstash.Logstash -f config/logstash-analytics-daily-payment.conf

となっており、

不要なので、このプロセスを削除。

上記のプロセスIDは、

PIDのところにある「12345」の部分なので、

プロセスの削除コマンド

kill -9 12345

でプロセスの削除を実施。

Github Actionsで本番環境への自動反映を試した件

リポジトリに反映した時に、

自動で本番環境に対して、

コードを反映したいので、

その点を試した時のメモ。

リポジトリに設定ファイルを追加

リポジトリ内に GitHub Actionsのワークフロー（設定ファイル）を作成 する。

.github/workflows/deploy.yml を作成

フォルダ作成

mkdir -p .github/workflows

ファイル

.github/workflows/deploy.yml

作成用（Vim）

vim deploy.yml

ymlファイルのコード

name: Deploy to Production

on:
  push:
    branches:
      - main  # `main` に push されたら実行

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Sync files via rsync
        uses: burnett01/rsync-deployments@4.1
        with:
          switches: -avz --delete
          path: ./
          remote_path: /var/www/html/your_project/  # 本番環境のディレクトリ
          remote_host: ${{ secrets.SSH_HOST }}
          remote_user: ${{ secrets.SSH_USER }}
          remote_key: ${{ secrets.SSH_PRIVATE_KEY }}

Github上にsecrets設定情報を追加

リポジトリのymlファイルで使用する設定情報を、

Github上に設定を追加します。

１．GitHubのリポジトリを開く

２．「Settings」 → 「Secrets and variables」 → 「Actions」を選択

３．「New repository secret」をクリック

４．以下のように、1つずつ追加する
Secret Name: SSH_HOST
Secret Value: 123.456.78.90（←本番サーバーのIP）
「Add secret」をクリックして保存

上記のように設定を進めたら完了。

GitHub Actionsの挙動を確認

GitHubのリポジトリで、

「Actions」

を確認してみる。

確認すると、

Add GitHub Actions for auto-deployment
Deploy to Production #1: Commit xxxxxx pushed by xxxxxxx

これが、❌になっていた。

エラー

Enter passphrase for (stdin): ssh: connect to host *** port 22: Operation timed out
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.3]

が起きていた。

設定情報を再確認して、

更新してから、

再度、pushを試したらうまくいった。

LaravelのORMでのトランザクションで「There is no active transaction」のエラーになった件

Laravelを使用していて、

ORMを使って処理を構築していたとき、

トランザクション周りで、

There is no active transaction

のエラーが発生したが、

この件、なぜか調べたときの内容。

個人的にメモ。

Laravelのバージョン

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 10.48.10

というバージョンであることがわかります。

事象

自分の方で、

エクスポート処理を作成しており、

DB::beginTransaction();

他の箇所で同じような処理自体は挙動は問題ない。

ただし、

新しく作成した処理では、

There is no active transaction

というエラーが起きていた。

原因

今回、自分の処理コードで発生した事象は、

原因としては、

DB::table('sample_table')->truncate();

を実行していると、

コミットが発生していることが原因でした。

DB::beginTransaction();

DB::table('sample_table')->truncate();

DB::commit();

という処理が、

truncateを実行すると、コミットが発生していることで、

その後のコミットで、

There is no active transaction

が発生していたということ。

この件は、

Laravelのtruncateの仕様だが、元を辿ると、MySQLのtruncateの仕様

という点を理解すべきですね。

以下のMySQLの公式サイトに記載がありました。

https://dev.mysql.com/doc/refman/8.0/en/truncate-table.html

上記サイトの一部を引用

Truncate operations cause an implicit commit, and so cannot be rolled back.

切り捨て操作は暗黙のコミットを引き起こすため、ロールバックすることはできない。（DeepL翻訳）

ということなので注意が必要ですね。

対策

対策としては、

トランザクションの開始、終了の中に入れない
truncateメソッドではなく、deleteメソッドを使用する

という対応を行う必要があります。

トランザクションの開始、終了の中に入れない

コミットが暗黙的に発生するので、

トランザクションの範囲から外します。

DB::beginTransaction();

DB::table('sample_table')->truncate();

DB::commit();

のコードを、

DB::table('sample_table')->truncate();

DB::beginTransaction();

DB::commit();

にする形ですね。

truncateメソッドではなく、deleteメソッドを使用する

暗黙的なコミットが、

truncateでは発生しますが、

deleteでは暗黙的なコミットは発生しない

という点を考え、

deleteメソッドを使用します。

DB::beginTransaction();

DB::table('sample_table')->truncate();

DB::commit();

というコードを、

DB::beginTransaction();

DB::table('sample_table')->delete();

DB::commit();

という形で、

deleteメソッドを使うように調整します。

最後に

ちょっとしたことでしたが、

調査に戸惑ったので、個人的なメモです。

上記、少しでも参考になれば幸いです。

MySQLでEXPLAINを使っての重たいクエリの調査

今回は、

LaravelでのORMを使う中で、

MySQLでデータベースの検索処理で、

select * from master_sample;

などの確認データで、

色々なJOINなどをやっていると、

件数が増えてきて、

重たくなってきたので、

その調査をした時のメモ。

調査として、

EXPLAIN

を使ったのだが、

この辺りの調査は、実施したことなかったので、

試しながら、実際に試した時の個人用の備忘録。

使用したMySQLのバージョン確認

mysqlのコマンドラインで確認

mysql -V

実行結果

$  mysql -V
mysql  Ver 8.0.31-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

MySQLでEXPLAINでの実行SQLの確認

実際に実行するコードとしては、

EXPLAIN SELECT * FROM master_sample;

のように使用する。

結果は、

id	select_type	table	type	possible_keys	key	rows	Extra
1	SIMPLE	master_sample	ALL	NULL	NULL	1000	Using where

のようになる。

簡単に各項目をメモ

id: クエリ内のSELECTの識別子（複数のクエリがある場合に区別）
select_type: クエリの種類（SIMPLE, SUBQUERY, PRIMARYなど）
table: 対象のテーブル名
type: テーブルアクセス方法（ALL, INDEX, RANGE, REF, EQ_REF, CONST, SYSTEM）
possible_keys: 使用可能なインデックス（NULLなら候補なし）
key: 実際に使用されたインデックス
rows: 検索対象の推定行数（小さいほど効率的）
Extra: その他の情報（Using index, Using where, Using temporaryなど）

こちらになるので、

上記の

type

が、

ALL

については、

「フルスキャン」での検索になっているので、

インデックス適用を検討した方が良い。

The MySQL server is running with the –secure-file-priv option so it cannot execute this statement

今回は、

MySQLから、

select * from master_sample;

などの確認データで、

必要なデータをCSV出力して、

スプレッドシートなどで確認することがあったのですが、

その際、

The MySQL server is running with the --secure-file-priv 
option so it cannot execute this statement

が起きたので、

調整した時のメモ。

使用したMySQLのバージョン確認

mysqlのコマンドラインで確認

mysql -V

実行結果

$  mysql -V
mysql  Ver 8.0.31-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

MySQLからCSVへのデータ出力

実際に実行するコードとしては、

以下を参考にしてください。

MySQLからCSVの出力方法

The MySQL server is running with the –secure-file-priv option so it cannot execute this statementの対応

エラーの内容としては、

The MySQL server is running with the --secure-file-priv 
option so it cannot execute this statement

というエラーが発生していた。

対応としては、

my.cnf

に以下を追加。

追加するコードとしては、

mysqldに

[mysqld]
secure-file-priv=/var/www/html/mysql-files/

のように設定を追加します。

追加コード（コピペ用）

secure-file-priv=/var/www/html/mysql-files/

設定をしたら、

MySQLを再起動してください。

MySQLからCSVの出力方法

今回は、

MySQLのレコードを確認で

select * from master_sample;

などの確認データで、

必要なデータをCSV出力して、

スプレッドシートなどで確認することがあったので、

その際のメモ。

使用したMySQLのバージョン確認

mysqlのコマンドラインで確認

mysql -V

実行結果

$  mysql -V
mysql  Ver 8.0.31-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

MySQLからCSVへのデータ出力

実際に実行するコードとしては、

select * from master_sample 
INTO OUTFILE '/var/lib/mysql-files/sample.csv' 
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"';

このように、

実際のSQLに「INTO OUTFILE」以降を追加して実行。

追加コード部分のコピペ用

INTO OUTFILE '/var/lib/mysql-files/sample.csv' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"';

こちらを実行して、

実際の対象のパスを確認すると、

うまくファイルができていました。

Ubuntuでjournalsのシステムログを削減する方法（/var/log/journals）

クラウド環境の中で、

サーバーとして、

Ubuntuを使用しているが、

ディスク使用率が高くなり過ぎているので、

その調査を行いました。

その時のメモは

Ubuntuでのディスク肥大時の調査（duコマンド）

こちらを参照してください。

今回は、

上記で見つかった大きくなっていたファイルとして、

システムログのjournalsが大きくなっていたので、

そちらの対応を行った時のメモ。

自分の備忘録として、

忘れないうちにメモを残しておきます。

経緯

各種アプリケーションを動かしているUbuntuの環境で、

サーバーのディスクの使用量が大きくなっていました。

調査した結果、

/var/log/journal

のファイルが大きくなっていました。

/var/log/journalとは？

今回の対象の

/var/log/journal

このディレクトリのファイルですが、

systemdの永続的なシステムログを保存するディレクトリ

となっています。

ですので、

長期的にシステムログを検証する必要がある場合は、減らし過ぎない

という点だけ、

ご注意いただければと思います。

/var/log/journalを削減

私の環境では、

外部公開等のものではなかったこともあり、

大きく削減しても問題ないため、

削減対応を行いました。

削減としては、

サイズ指定での削減
保存期限指定での削減

のどちらか、

または、組み合わせての指定を実施しました。

実際の例を置いておきますので、

参考にしてください。

サイズ指定での削減

例：１Gまでのサイズに削減

journalctl --vacuum-size=1G

例：１００MBでのサイズに削減

journalctl --vacuum-size=100M

期限指定での削減

例：保存を１日までに削減

journalctl --vacuum-time=1d

例：保存を１２時間までに削減

journalctl --vacuum-time=12h

サイズ指定＋期限指定も可能

journalctl --vacuum-time=1d --vacuum-size=1G

これらのように、

設定を進めることで、

journalのサイズ削減ができるので、

必要に応じて、変えながら対応を進めてみてください。

Ubuntuでのディスク肥大時の調査（duコマンド）

クラウド環境の中で、

サーバーとして、

Ubuntuを使用しているが、

ディスク使用率が高くなり過ぎているので、

その調査を行った時のメモ。

別途、

Dockerでのコンテナの肥大化は

使用サイズの大きいコンテナのゴミファイルなどを調査・調整した件

こちらを参考にしてください。

大きくなったゴミファイルを調査して、

削除等を実施した時の内容です。

自分の備忘録として、

忘れないうちにメモを残しておきます。

経緯

各種アプリケーションを動かしているUbuntuの環境で、

サーバーのディスクの使用量が大きくなっていました。

あくまで、

Dockerコンテナを使用していない環境なので、

ログファイルなどが大きくなっていたということが考えられます。

Ubuntuの大きいファイルの調査

サイズの大きい場所を見つけるには、

duコマンドを使って調査します。

確認コマンド

du -sh /* | sort -hr | head -n 10

結果サンプル

45G	/var
3.7G	/home
2.9G	/usr
1.7G	/snap
145M	/boot
47M	/etc
18M	/opt
2.5M	/tmp
1.1M	/run

このようになるので、

それぞれ、どこが大きいかを確認できます。

また、

上記でディレクトリがわかったら、

例えば、

/var

を確認したいのであれば、

du -sh /var/* | sort -hr | head -n 10

のように、

du -sh /ここのパスを変える/* | sort -hr | head -n 10

を調整してもらえると、

自分が確認したいディレクトリ中のサイズを確認できるので、

必要に応じて、変えながら調査を進めてみてください。

使用サイズの大きいコンテナのゴミファイルなどを調査・調整した件

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

Debian系（Ubuntu）でテンポラリフォルダの自動削除

こちらを参考にしてください。

今回は、

使用サイズが大きくなったコンテナについて、

その中でログファイルなど、

大きくなったゴミファイルを調査して、

削除等を実施した時の内容です。

自分の備忘録として、

忘れないうちにメモを残しておきます。

経緯

各種アプリケーションを動かしているUbuntuの環境で、

Dockerを使用していましたが、

サーバーのディスクの使用量が大きくなっていました。

原因として、

コンテナの使用サイズが大きくなっていたのが原因でした。

コンテナの使用サイズを確認する方法については、

コンテナの使用サイズを確認する方法

こちらを参考にしてください。

Dockerのコンテナの中の調査

サイズの大きいコンテナを見つけた上で、

そのコンテナの中に入って、

肥大化しているファイル等を確認します。

コンテナに入るコマンド

docker exec -it container_name /bin/bash

上記で入って、調査をしました。

前提として、

Dockerfileでは、

python:3.8-slim

をベースにコンテナ作っている環境です。

大きいファイルを確認します。

以下のコマンドで確認できます。

テンポラリフォルダの削除と対策

削除自体は、

/tmp

のフォルダの中は一次情報ファイルなので、

削除しても問題ない認識です（使用中アプリケーションがなければ）。

なので、このテンポラリフォルダの中を削除しました。

削除コマンド（非隠しファイル）

rm -rf /tmp/*

削除コマンド（隠しファイル）

rm -rf /tmp/.[!.]* /tmp/..?*

上記が、自分の環境でしたが、

上記でコンテナの全体使用サイズがわかるので、

大きくなっているものを把握して、

対応を行うことができます。

この大きくなったコンテナの対応については、

別途、メモ記事を残せたらと思います。

追記

以下の記事にテンポラリフォルダの中身を消す対応をメモ。

Debian系（Ubuntu）で、

テンポラリフォルダが肥大化しており、

削除コマンドで削除して対応したが、

何度も同じ対応をするのは面倒なので、

削除を自動化する対応をした時のメモ。

経緯

基本的に、Debian系であれば、

今回と同じ対応になるかと思います。

自分の状況としては、

Dockerコンテナで立ち上げた環境が、

Debian系であることが多いので、

その時の対応になります。

テンポラリ削除の自動化の設定（systemdで対応の場合）

デフォルトの設定については、

/usr/lib/tmpfiles.d/tmp.conf

にあるようなので、

このファイルを確認してみました。

vi /usr/lib/tmpfiles.d/tmp.conf

確認してみたところ、

D /tmp 1777 root root -

となっており、

これはファイルを削除しない設定。

上記のファイルがデフォルトの設定ですが、

直接、上記のファイルを変更するか、

どのファイルを用意するか調べたところ、

/usr/lib/tmpfiles.d/ → デフォルト設定（変更しない）。
/run/tmpfiles.d/ → 一時的な設定（リブート時にクリア）。
/etc/tmpfiles.d/ → カスタム設定（推奨される変更場所）。

という感じでした。

上記について、

/etc/tmpfiles.d/

に設定ファイルを追加します。

追加ファイル

/etc/tmpfiles.d/tmp.conf

編集コマンド

vi /etc/tmpfiles.d/tmp.conf

追加する内容

v /tmp 1777 root root 1d

次に、反映処理

systemctl restart systemd-tmpfiles-clean

上記の設定タイマーの確認

systemctl status systemd-tmpfiles-clean.timer

テンポラリ削除の自動化の設定（cronで対応の場合）

すでにcronが入っていること前提ですが、

入ってなければ、以下のコマンドで導入

apt-get update && apt-get install cron -y

設定コマンド

crontab -e

設定内容

@daily find /tmp -type f -mtime +1 -exec rm -f {} \;

または、

0 3 * * * find /tmp -type f -mtime +1 -exec rm -f {} \;

のどちらかを設定

設定できたかを確認

crontab -l

cronの稼働状況

ps aux | grep cron

起動してなかったら以下のコマンド

/etc/init.d/cron start

コンテナの使用サイズを確認する方法

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

こちらを参考にしてください。

今回は、

立ち上げたコンテナが使用しているサイズについて、

確認する方法について、

コマンドを確認して

実際に動かした時のメモ。

自分の備忘録として、

忘れないうちにメモを残しておきます。

経緯

各種アプリケーションを動かしているUbuntuの環境で、

Dockerを使用していましたが、

サーバーのディスクの使用量が大きくなっていました。

最初は、

xxxx.log

などのログファイルが、

アプリケーションなどのログファイル
Nginxなどのミドルウェアのログファイル

の問題で肥大化しているのかと思いましたが、

９５％くらいが、

９０％に減るくらいで、

そこまで減りませんでした。

Dockerのコンテナの肥大化

ログ周りでいつも重くなっていましたが、

それ以外で、

日々、動いており、肥大化する可能性があるものとして、

Dockerコンテナかと思って、

調べたところ、

コンテナがすごく大きくなっていました。

最新状態と履歴含めた確認は、

以下のそれぞれで確認できます。

使用サイズの履歴

docker system df -v

確認結果イメージ（以下のような感じで表示されます）

5yr3cbd22dvn   regular        953B      8 months ago    8 months ago    1         true
nyxxv3lvgry5   regular        33.4MB    8 months ago    8 months ago    1         true
rpmoslc5f3c6   regular        0B        8 months ago    8 months ago    1         true
vmz6pctqmpyf   regular        0B        8 months ago    8 months ago    2         true
h5fa9tsklfnb   regular        0B        8 months ago    8 months ago    1         true
g9vmjtbh0xqk   source.local   468B      8 months ago    8 months ago    2         false
kbnlhqr1qfpj   regular        32.6kB    8 months ago    8 months ago    1         true
ej6xe2gibwbr   regular        42.8MB    8 months ago    8 months ago    1         true
j42fehdwp6k1   source.local   32.6kB    8 months ago    8 months ago    2         false
ymsn3owpao8i   source.local   0B        8 months ago    8 months ago    2         false
jf57k2e4kpzr   regular        6.71MB    8 months ago    8 months ago    1         true
l7h3ic9kqcwk   regular        33.4MB    8 months ago    8 months ago    1         true

上記、必要あれば、フィルタ等で必要情報を履歴情報で取得するのもありですね。

また、最新情報だけ簡潔にというものであれば、

以下のコマンドで確認できます。

コンテナを使用して、LaravelでMySQLからデータ取得時に「php_network_getaddresses: getaddrinfo」が発生した件をメモ

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

https://jwt-auth.readthedocs.io/en/develop/laravel-installation

こちらを参考にしてください。

今回は、

docker-compose

で環境を立ち上げた上で、

LaravelからMySQLのデータ取得を試していたところ、

(PDOException(code: 2002): 
SQLSTATE[HY000] [2002] php_network_getaddresses: 
getaddrinfo for [コンテナ名] failed: 
nodename nor servname provided, or not known

このようなエラーが発生。

自分の備忘録として、

忘れないうちにメモを残しておきます。

エラー内容

実行処理としては、

Laravelの方で、

DB::table('sample')->get();

という形で、

テーブルデータの取得を行っていました。

コンテナ間のアクセスを確認

docker exec -it mysql_container mysql -u user -ppassword -e "SHOW DATABASES;"

というファイルを準備して、

docker exec -it admin_container mysql -h mysql_host -u user -ppasswordw -e "SHOW DATABASES;"

そちらをビルドする流れてで進めていました。

このビルドを実行したところ、

 => ERROR [ 3/22] RUN apt-get update 
[+] Building 2.7s (9/26)
 => [internal] load build definition from Dockerfile 
　 ：
 => ERROR [ 5/22] RUN apt-get update 
------
 > [ 5/22] RUN apt-get update 
#0 0.313 Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
#0 0.362 Get:2 http://deb.debian.org/debian bookworm-updates InRelease [55.4 kB]
#0 0.383 Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0 kB]
#0 0.407 Err:1 http://deb.debian.org/debian bookworm InRelease
#0 0.407   At least one invalid signature was encountered.
#0 0.447 Err:2 http://deb.debian.org/debian bookworm-updates InRelease
#0 0.447   At least one invalid signature was encountered.
#0 0.488 Err:3 http://deb.debian.org/debian-security bookworm-security InRelease
#0 0.488   At least one invalid signature was encountered.
#0 0.494 Reading package lists...
#0 0.504 W: GPG error: http://deb.debian.org/debian bookworm InRelease: At least one invalid signature was encountered.
#0 0.504 E: The repository 'http://deb.debian.org/debian bookworm InRelease' is not signed.
#0 0.504 W: GPG error: http://deb.debian.org/debian bookworm-updates InRelease: At least one invalid signature was encountered.
#0 0.504 E: The repository 'http://deb.debian.org/debian bookworm-updates InRelease' is not signed.
#0 0.504 W: GPG error: http://deb.debian.org/debian-security bookworm-security InRelease: At least one invalid signature was encountered.
#0 0.504 E: The repository 'http://deb.debian.org/debian-security bookworm-security InRelease' is not signed.

このエラーが発生しました。

考えられる原因

考えられる原因としては、

Dockerビルド時のリソース不足
ネットワークの問題
Dockerのバージョンに関する問題
Dockerのイメージやコンテナ・キャッシュによる問題

が考えられます。

最終的には、

Dockerのイメージやコンテナ・キャッシュによる問題

が原因でした。

Dockerビルド時のリソース不足

デフォルトで割り当てられたCPUやメモリについて、

複数立ち上げを行っていると、

PCのスペック的には、

ビルドのプロセスでリソース不足が発生します。

ただ、今回の自分の環境では、

特に問題はなさそうでした。

ネットワークの問題

この点に関しては、

特に他のDebian系の環境で

apt-get update

を動かしてみても、

特に問題ない状態ですし、

自分のPCからの外部アクセスについても、

特に問題見当たらなかったため、

この点は影響なしと考えました。

Dockerのバージョンに関する問題

Dockerのバージョンについては、

バージョンごとに、

うまくいかない点が出てきますが、

自分は比較的バージョンを上げて対応しており、

同じビルドしている設定とは、

特にバージョンを変えていないので、

この点も問題なしと判断しました。

Dockerのイメージやコンテナ・キャッシュによる問題

上記に記載した点は問題なかったので、

最後の考えられることとして、

現在の自分の環境にあるDockerイメージや、

使っている・使っていたコンテナ・キャッシュ周りが影響して、

うまくビルドが動いていないことが考えられます。

キャッシュされたイメージやコンテナが原因で、

問題が発生していることもあるようなので、

まずは、（これは解決策ではありません）

docker-compose -f docker-compose.sample.yml build --no-cache

こちらで、

ビルドしているキャッシュ自体を使わないで、

ビルドプロセスを試してみます。

しかし、同じようなエラーとなります。

ビルドプロセスで使用されるベースイメージが更新された場合など、

キャッシュされた状態が原因でビルドが失敗することがあるようなので、

Dockerイメージやコンテナのキャッシュをクリア

を行います。

コマンド

docker system prune -a

こちらを実行すると、

今までのイメージやキャッシュがクリアされます。

こちらでクリアしたのちに、

再度、ビルドプロセスを試します。

docker-compose -f docker-compose.sample.yml build

こちらを実行したら、

うまくビルドが完了しました。

これで解決ですね。

Laravelで「Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.」のエラーになった件

Laravelを使用していて、

エクスポート処理を作っていたときに、

ブラウザで挙動確認した時、

Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.

のエラーが発生したが、

この件、時々、ミスするので、

今後のためにメモ。

Laravelのバージョン

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 10.48.10

というバージョンであることがわかります。

事象

自分の方で、

エクスポート処理を作成しており、

他の箇所で同じような処理自体は挙動は問題ない。

ただし、

新しく作成した処理では、

Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.

というエラーが、

ブラウザの方で起きていた。

この時、ブラウザの表示は、

４０４エラーではなく、

真っ白な画面表示でした。

ルーティングなどは、

以下のコマンドで確認しても問題なし。

ルーティングのリストを確認

php artisan route:list

上記以外で、

Laravelログ上にアクセスまでは来ている形跡があるので、

何か設定投下コードのミスかを諸々、確認。

対策

結論として、

コントローラーからの戻り値として、

作成したデータを返せていなかったのが原因。

イメージとして、

モデル側

public function modelFunction() {
  return Storage(....)
}

としていたが、

コントローラー側

public function controllerFunction() {
  $model = new sampleModel();
  $model->modelFunction();
}

という感じで、

戻り値（return文）をコントローラー側で返していなかった。

この調整を実施。

ブラウザで再度、挙動を確認したら、

問題なく挙動したので、この対策で完了。

Laravelのルーティング追加したけれど、反映されなかった件

Laravelを使用していて、

ルーティングを

Route::get('/sample', [SampleController::class, 'getSample']);

などで追加して、

その挙動を確認していた時に、

４０４エラーが発生して、

記載方法間違ったかなと思ったが、

対応はシンプルだった。

ただ、

自分自身、忘れそうなので、

経緯と対応コマンドをメモ。

Laravelのバージョン

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 10.48.10

というバージョンであることがわかります。

事象

自分の方で、

Route::get('/sample', [SampleController::class, 'getSample']);

に設定して、

うまく反映できたかなと思ったが、

４０４エラーがブラウザ上で起きていた。

ルーティングファイルのコードの記載自体は、

特に問題なさそうだが、

Laravelのログには何もアクセスログが残らない。

そこで、

ルーティングのリストを確認

php artisan route:list

こちらで確認すると、

追加したルーティングがうまく反映されていない。

対策

Laravelでのルーティングの設定が、

キャッシュで保持しているようなので、

以下のコマンドでキャッシュに反映させる。

コマンド

php artisan route:cache

こちらで反映して、

再度、ルーティングのリストを確認。

コマンド

php artisan route:list

で確認。

確認した結果、追加したルーティングがリストに表示された。

この状態でブラウザで再度、挙動を確認したら、

問題なく挙動したので、この対策で完了。

Laravelで環境変数の.envを反映する件

Laravelを使用していて、

環境変数を

.env

ファイルに設定して、

こちらの設定ファイルを使って、

環境ごと値を変数として使っていました。

Laravel標準コマンドでの反映処理などを行っていましたが、

反映できなかったことがあったので、

その時の対応をメモ。

Laravelのバージョン

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 10.48.10

というバージョンであることがわかります。

Laravelでの環境変数周りの反映

環境変数を

.env

に設定したら、

以下のコマンドで反映していました。

php artisan config:clear
php artisan cache:clear
php artisan config:cache

こちらで反映できていたのですが、

新しい環境を作った時に、

この環境変数の値が反映されず、

空データになってしまいました。

その対応として、以下のキャッシュファイルを手動削除。

キャッシュファイルの手動削除

Laravelでの設定ファイルは、

キャッシュファイルが作成されます。

そのファイルが、

bootstrap/cache/config.php

というプロジェクトのファイルです。

そのファイルを

rm -f bootstrap/cache/config.php

で削除。

こちらを実行することで

問題なく環境変数の値が取得できるようになりました。

LaravelとReactでJWT認証を導入

Laravelを使用していて、

認証処理を作ろうと考えて、

フロントエンドとバックエンドが、

ドメインが違うことを考え、

Laravel標準のLaravel Sanctumを使うのではなく、

JWTでの認証を行うことにしました。

今回は、

このLaravelとReactの環境で、

JWTでの認証処理を導入したときのメモ。

Laravelのバージョン

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 10.48.10

というバージョンであることがわかります。

LaravelへのJWTの認証の導入

JWT認証を使うために、

「tymon/jwt-auth」

を導入します。

公式情報

導入コマンド

composer require tymon/jwt-auth

パッケージの設定

php artisan vendor:publish --provider="Tymon\JWTAuth\Providers\LaravelServiceProvider"

これにより、config/jwt.php設定ファイルが作成されます。

JWTシークレットキーの生成

php artisan jwt:secret

これにより、.envファイルにJWT_SECRETが追加されます。

このキーは、トークンの署名および検証に使用されます。

config/auth.phpの調整

'defaults' => [
    'guard' => 'api',
    'passwords' => 'users',
],

'guards' => [
    'api' => [
        'driver' => 'jwt',
        'provider' => 'users',
    ],
],

メモリサイズの設定

自分が動かしている環境では、

php8.1-fpmを使っているので、

以下の設定ファイルを変更する。

/etc/php/8.1/fpm/php.ini

上記ファイルの中の

memory_limit

のサイズを変更します。

ファイル内の、

メモリサイズ（memory_limit）を変更します。

memory_limit = xxxM

xxxには任意のサイズを指定してもらって、

MByteでの指定をしています。

上記の設定変更が終わったら、

php8.1-fpmも再起動させます。

再起動コマンド

sudo service php8.1-fpm restart

こちらで再度確認すると、

うまく処理が完了しましたので、

解決できました。

selenium chrome driverのドライバ取得方法のサイトが変わっていたのでメモ

seleniumでの処理自体は、

ホスト上やコンテナ上などで、

環境を立ち上げていたが、

その辺りで対応した時は、

Docker+Python3+Seleniumで「chromedriver unexpectedly exited. Status code was: 255」

chrome driver ドライバ取得

chrome driverのドライバ取得に関しては、

公式サイトから取得します。

ダウンロードに関しての情報は、

こちらをまずは参照。

chrome for developerのサイト

Chrome for Testingのドライバ取得

バージョン的に、v114くらいまでは、

上記サイトにありますが、

それ以降のchromedriverについては、

Chrome for Testingのサイトにあります。

以下のサイトで取得できます。

Chrome for Testingのサイト

Magentoの導入をコマンドラインで諸々。

Magentoについて、

ちょっと環境を作る必要があったので、

その際に実施した時のメモ。

データ自体は、

別の環境にあるものを使ったので、

それを使っているという点も注意。

公式サイトの情報

公式サイト

Adobeが管理しているので、そちらを参照。

https://business.adobe.com/products/magento/magento-commerce.html

導入メモ

プロジェクト取得

composer create-project --repository=https://repo.magento.com/ magento/project-community-edition=^2.4 magento

上記、安定版取得したので、

最新の分は必要に応じて変更必要。

repo.magent.comの認証は

Magento Marketplaceで、

Access Keysの認証キーを確認。

認証キーの

public key：username

private key ：password

で、repo.magento.comの認証は通る。

初期設定

php bin/magento setup:config:set \
    --db-host=localhost \
    --db-name=db_name \
    --db-user=user_name \
    --db-password=password \
    --backend-frontname=admin

Magentoのインストール

php bin/magento setup:install \
    --db-host="localhost" \
    --db-name="db_name" \
    --db-user="user_name" \
    --db-password="password"

調整

UPDATE core_config_data SET value = 'https://example.com' WHERE path = 'web/unsecure/base_url';

UPDATE core_config_data SET value = 'https://example.com' WHERE path = 'web/secure/base_url';

アップロードとデプロイ

php bin/magento setup:upgrade

php bin/magento setup:di:compile

php bin/magento setup:static-content:deploy -f

php bin/magento cache:clean

キャッシュクリア

php bin/magento cache:flush

モジュールを無効化（データベース）

ReflectionException: 
Class "StripeIntegration\Payments\Model\Adminhtml\Source\BillingInterval" 
does not exist in /var/www/html/magento/vendor/magento/framework/Code/Reader/ClassReader.php:34

本番環境では動かしていたが、

新たな環境は決済周りは不要で、データだけ確認するので、

これは無効化して対応。

DELETE FROM eav_attribute WHERE source_model LIKE '%StripeIntegration%';
DELETE FROM eav_attribute WHERE backend_model LIKE '%StripeIntegration%';

上記をやったら、

また、アップロードとデプロイ

php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f
php bin/magento cache:clean
php bin/magento cache:flush

モジュールを無効化（コマンド）

コマンドで無効化

php bin/magento module:disable Magento_TwoFactorAuth Magento_AdminAdobeImsTwoFactorAuth

無効化したら、キャッシュをクリア

php bin/magento cache:clean

モードの変更

モードは必要に応じて、ログ確認の時などに切り替える

コマンドでモードを変更

php bin/magento deploy:mode:set developer

ログはこの辺りを見る。

tail -f var/log/exception.log
tail -f var/log/system.log

バージョン管理の無効化

pub/staticにバージョン情報管理しているのだが、

参照がうまくいかなかったので、

これを無効化。

php bin/magento config:set dev/static/sign 0
php bin/magento cache:clean

カスタムデザインの配置

カスタムのデザイン周りは、

以下のフォルダに配置

app/design/frontend

設定ファイル

必要に応じて、

以下を各種設定を確認、手動で調整しても良い

app/etc/env.php

ローカルのコンテナ上で、Next.jsのnext-auth使用してビルド後に実行したらエラーになった件

Nextjsで実装していたときに、

認証周りを構築しようとした時に、

何かライブラリなどを用いて、

GoogleのOAuthでの認証を試そうと考えました。

現時点で調べていると、

「Auth.js(NextAuth.js)」

というライブラリが良さそうなので、

こちらを試してみることにしました。

今回は、

ライブラリ「Auth.js(NextAuth.js)」を用いて、

Google OAuthの認証を試していたので、

その時にビルドまでうまくいったのだが、

実行するとエラーになった時のメモを

備忘録としてこの記事に残します。

公式サイトの情報

公式サイト

まずは、公式サイトでNextAuth.jsのことを確認

自分が確認した時点（2023/04/25）で、

NextAuth.js is becoming Auth.js! 🎉 
Read the announcement. Note, 
this site is under active development.

とアナウンスされているので、

それぞれのリンクをメモしておきます。

nuxt-authでGoogle認証を試した

今回のビルドエラーになったのは、

Next.jsでGoogle認証を試していたのだが、

開発モードではうまく挙動していた。

TypeScriptを使っているので、

ビルド時にエラーになったが、

ベースとなるやっていることは、

以下の記事を参考。

ビルドのエラーは調整済み

ビルドについてもエラーになったが、

以下の対応をやって、

問題なくビルドは完了している。

https://script.google.com/home

実行エラー

実行したら、

エラーが発生した。

エラー内容

Error: Error serializing `.csrfToken` returned from `getServerSideProps` in “/auth/signin”.
Reason: `undefined` cannot be serialized as JSON. Please use `null` or omit this value

原因

今回、ローカルで各種設定をした上で、

ブラウザで、

http://localhost:8032/api/auth/csrf

http://localhost:8032/api/auth/providers

などを試したら、

うまく挙動していた。

ここまで確認したら、

実行しているローカル上で、

next-authでの動きは問題ないかと。

GCP自体の設定も問題ないので、

考えられることとしては、

サーバーサイドのみでの挙動が、

うまく処理されていないということ。

なので、その辺りを色々と試した結果、

9000/tcp, 0.0.0.0:8032->8092/tcp

という感じで、

元々は、ポート番号を、

ローカルのホストの番号とコンテナのポートの番号が違う

ということなので、

ローカルのホストの番号とコンテナのポートの番号を合わせる

という対応をすると、

うまく挙動できました。

Ubuntuでphp-fpmの設定を変更したことで、502エラーでアプリケーションが動かなかった件

Ubuntuで、

Nginxとphp-fpmを使って、

Webサーバーを起動させることで、

アプリケーションを動かしていました。

しかし、

なぜか、php-fpmがステータスがfailedで、

うまく起動していません。

この件の対応した時のメモです。

php-fpmの状況確認

確認コマンド

sudo systemctl status php8.1-fpm.service

確認結果

● php8.1-fpm.service - The PHP 8.1 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.1-fpm.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2024-09-06 10:48:15 JST; 24s ago
       Docs: man:php-fpm8.1(8)
    Process: 1100378 ExecStart=/usr/sbin/php-fpm8.1 --nodaemonize --fpm-config /etc/php/8.1/fpm/php-fpm.conf >
    Process: 1100390 ExecStopPost=/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/8.>
   Main PID: 1100378 (code=exited, status=78)

こちらでうまく起動できていないことが発覚。

php-fpmの設定不正確認

php-fpmの設定を変更したことが原因と考えられるので、

コマンドを使って不正設定を確認。

確認コマンド

sudo php-fpm8.1 -t

確認結果

[06-Sep-2024 10:49:23] ALERT: [pool www] pm.start_servers(2) must not be less than pm.min_spare_servers(5) and not greater than pm.max_spare_servers(10)
[06-Sep-2024 10:49:23] ERROR: failed to post process the configuration
[06-Sep-2024 10:49:23] ERROR: FPM initialization failed

php-fpmの再起動

再起動コマンド

sudo systemctl start php8.1-fpm

こちらで再起動もうまくいって、

問題なくアプリケーションも動くようになりました。

【GoogleAppsScript】claspでコード取得と反映する方法（Githubリポジトリのためのコード取得のために使用してみた）

Google Apps Scriptで、

各種処理を作っていく中で、

コードをGithubで管理したい

ということがあり、

公式で用意されているもので、

試してみた時のメモです。

clasp CLIをインストール

Node.js がインストールされていることを確認します。

その上で、

npm install -g @google/clasp

このコマンドで、claspをインストール。

clasp で認証

ターミナル等のコマンドで、

clasp login

を実行して、

認証を実施してください。

claspを使用して、Google Apps Scriptのコードを取得

コマンドラインで、

clasp clone <スクリプトID>

を実施することで、

コードを取得することができます。

スクリプトIDについては、

スクリプトエディタから

「ファイル」 > 「プロジェクトのプロパティ」

で確認することができます。

claspを使用して、Google Apps Scriptのコードを反映

取得したコードを、

各種エディタ等で更新した後、

clasp push

のコマンドを実行することで反映できます。

反映時のエラー

エラー内容として、

User has not enabled the Apps Script API. 
Enable it by visiting https://script.google.com/home/usersettings then retry. 
If you enabled this API recently, 
wait a few minutes for the action to propagate to our systems and retry

このエラーが出ていましたが、

このエラーについては、

Google Apps Script設定ページ

上記から設定ページにアクセスします

「Google Apps Script API」のトグルをオンにします。

トグルがオンになると、Google Apps Script APIが有効になります。

こちらを行ってから、再度、反映のコマンドを実行するとうまくいきました。

参考：Google Apps Scriptの一覧を確認

使用しているスクリプトを確認するには、

以下のリンクで確認できます。

Google Workspaceでドメインを複数使い始めた件

管理ツールとして、

Google Workspace

を使っていたけれど、

複数ドメインを使いたい

ということがあり、

Google Workspaceの設定をしていたので、

この記事に残しておきます。

複数のドメインをGoogle Workspaceで使う方法の種類

複数のドメインをGoogle Workspaceで使う場合、

ドメインごとにGoogle Workspaceのアカウントを

作成する必要があるのかと思いましたが、

Google Workspaceのサポートの方に確認したところ、

私が確認した時点では、

別のGoogle Workspaceアカウントで分離する
同じGoogle Workspaceアカウントで複数紐付ける

ということでした。

上記のことを、

Google Workspaceの方での各種設定情報などの文言で言うと、

別々のプライマリドメインに分離して管理する
プライマリドメインとセカンダリドメインで管理する

と言う違いのようです。

今回は、

プライマリドメインとセカンダリドメインで管理する

こちらの同じアカウント内で、

複数のドメイン（プライマリとセカンダリ）で

Google Workspace上で管理する方法を試したメモです。

Google Workspaceの公式情報

問い合わせ担当者に今回、教えて頂いた情報は、

こちらのページに記載があります。

https://support.google.com/a/answer/7502379?hl=ja

上記のページを確認してもらいながら、

対応を進めてもらえると良いですが、

自分がやったことをメモ。

セカンダリドメインを追加

上記にも記載ある通り、

一部、引用しましたが、

ドメイン設定を確認して、

こちらの、

アカウント設定 – ドメイン – ドメイン管理

の設定から、

ドメイン追加を行うと、

次の画面が表示されます。

こちらの左側が、

セカンダリドメインの設定

という方法なので、

そちらを選択してから次に進んでください。

次の画面で進んだ時にTXTレコードの設定が必要となりますので、

その値を次のようにDNS設定に反映させる必要があります。

DNS設定にTXTレコードを設定（お名前.com）

上記のセカンダリドメインを追加すると、

TXTレコードをDNS設定に追加する

ということを行う必要があります。

必要なTXTレコードの値は、

上記のセカンダリドメインの追加を進めると表示されるので、

そちらの値を使ってください。

その値を、お名前.comで、

このドメインのDNS設定を進めます。

このDNSレコード設定から、

TXTレコードを追加します。

先ほどのGoogle Workspaceのセカンダリドメインの設定から、

設定するとなっているTXTレコードの値を、

お名前.comでは、

上記の設定で、

TYPEを「TXT」に設定
VALUEにGoogle Workspaceで表示された値を設定

という設定で、

追加ボタンで進めます。

上記の追加で、

このように

設定されているとオッケーです。

これを確認できたら、実際の反映まで進めて下さい

状況によってこのTXTレコード反映までちょっと時間かかることもあるようです。

Google WorkspaceでGmailを有効にする設定

上記でTXTレコードの設定をした上で、

Google Workspaceでアカウントの追加まではできます。

アカウント作成して、

ライセンスを紐づけることで、

Gmailの送信までは動いたのですが、

受信がうまく動きませんでした。

そこで手順を再確認したところ、

１つ、漏れていました。

Google Workspaceで「Gmailを有効にする」設定が必要

という点でした。

設定手順の方にも記載ありました。

こちらが必要ですね。

実際にGoogle Workspaceで確認してみます。

こちらの画面で、

こちらで、

MXレコードの設定を進めます。

DNS設定にMXレコードを設定（お名前.com）

Google Workspaceのお名前.comに対して、

MXレコードを設定する方法は、

こちらに公式にも記載があります。

https://help.onamae.com/answer/20389

上記にも記載がありますが、

一部、引用しながら大切なポイントを共有しておくと、

なお、Google Workspaceのご登録時期により、設定いただくレコードが異なりますので、
下記より、該当時期のレコードをご確認ください。

という部分が重要で、

Google Workspaceのご登録時期により、設定いただくレコードが異なります

で設定が違います。

2023年3月末までのご登録
2023年4月以降のご登録

の２つで設定が違うので、

その点は、

記載内容を確認して進めます。

自分が確認した時点では、

この２つのどちらか、

自分が使っているGoogle Workspaceの登録時期を確認して、

上記のいずれかでお名前.comのDNS設定にMXレコードを追加します。

自分の環境では、

「2023年3月末までのご登録」に該当するので、

お名前.comのDNS設定でのMXレコードの設定は、

このように設定しました。

こちらで設定を反映すると、

Google Workspaceでのセカンダリドメインで、

プライマリドメインと含めて、

複数ドメインの管理とアカウントの作成、Gmailの送受信までうまくいきました。

参考：Google Workspaceの導入・活用の始め方

Google Workspaceの導入方法や、

実際の活用の始め方については、

以下のサイトを参考にしてもらえればと思います。

Google Workspaceの導入・活用方法

Next.jsで「Hydration failed because the initial UI does not match what was rendered on the server」のエラー発生

Nextjsで実装していたときに、

レイアウト周りのコードを調整していたのだが、

上記の画像のようなエラーが発生した。

タグの閉じ忘れなどかなと考えたが、

Next.jsのコーディング方針としておかしい書き方をしていたので、

それが原因で上記エラーが起こっているようだった。

今後のために

個人的な備忘録としてこの記事に残します。

エラー内容

エラーに関しては、

このようなエラー表示になっていた。

上記のエラー文言を確認すると、

以下のように表示されていた。

Unhandled Runtime Error

Error: Hydration failed because the initial UI does not match what was rendered on the server.

Warning: Expected server HTML to contain a matching <div> in <p>.

See more info here: https://nextjs.org/docs/messages/react-hydration-error

参考

https://nextjs.org/docs/messages/react-hydration-error

エラー箇所

自分のコードの中で、

上記エラーが起きる箇所を、

地道に絞って行った時、

以下の部分が対象だった。

エラー発生部分

<Typography>
  <div>文言</div>
  <div>文言</div>
</Typography>

上記がNext.jsのコーディングとしてよくなく、

それが原因だろうということで、

ChatGPTにも聞いてみたら、

指定されたコードに関するエラーの原因は、
<Typography> コンポーネント内で <div> を直接使用していることにあります。
<Typography> コンポーネントは、
Material-UI（現在はMUIとして知られています）の一部で、
テキストを表示するために最適化されています。
しかし、このコンポーネントはデフォルトで <p> タグを生成するため、
その内部で <div> タグを使用するとHTMLの構造的な問題が生じ、
Reactのhydrationエラーの原因となります。

という感じで、

やはりコーディングが良くない。

上記の部分を調整して、

再表示したらエラー表示がなくなりました。

Gitを理解するために初心者におすすめのサイト・書籍

コードを管理するにあたって、

バックエンド、フロントエンドの両方で、

作成したコードに関しては、

「Git」（ギット）

を使って管理することが一般的になりました。

そんな中で、

実際にGitを使ってみたいけれど、

「Git」というのを初めて聞いた
「Git」を触り始めたけれど、よくわからない

という初心者に向けて、

おすすめのサイトと書籍を記載しておきます。

私自身も理解するために参考にしたサイト書籍なので、

同じように初めてGitに触れる方にも、

ぜひ参考にしてほしいと思います。

Gitを理解するために初心者におすすめのサイト・書籍

サル先生のGit入門

まずはじめにお勧めするのが、

サル先生のGit入門

というサイトです。

基礎的なところから、

入門編
発展編
プルリクエスト編
逆引きGit

という流れで、

内容がしっかりとして、

基礎学習にはすごく良いサイトなので、

内容を理解していきながら、理解を深めていきたいという方にオススメです。

はじめてでもできる GitとGithubの教科書

次に紹介するのは、

はじめに読む書籍としてオススメな、

こちらの本です。

リンク

「Gitってなに？」

というところから始めるので、

Gitって何？
コマンドラインツールって何？

というところで引っかかる人は、

この書籍ではじめの一歩を踏み出すのがオススメです。

独習Git

エンジニア向けの書籍として「独習〜」というシリーズがあり、

その中の「Git」にフォーカスした独習シリーズの書籍です。

リンク

独習シリーズは、

上記（書籍の一部のキャプチャを引用）のように、

基礎向けの書籍を読んだ後に、

ステップアップとして使うのにオススメです。

もう少し、Gitを深く理解していきたいと考える初心者に、

オススメなので、使ってみてください。

docker-composeのbuildが「bookworm InRelease」などのコンテナを立ち上げて、コンテナにアクセスするための流れをメモ

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

こちらを参考にしてください。

今回は、

docker-compose

を使っているのですが、

 => ERROR [ 3/22] RUN apt-get update 
[+] Building 2.7s (9/26)
 => [internal] load build definition from Dockerfile 
　 ：
 => ERROR [ 5/22] RUN apt-get update 
------
 > [ 5/22] RUN apt-get update 
#0 0.313 Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
#0 0.362 Get:2 http://deb.debian.org/debian bookworm-updates InRelease [55.4 kB]
#0 0.383 Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0 kB]
#0 0.407 Err:1 http://deb.debian.org/debian bookworm InRelease
#0 0.407   At least one invalid signature was encountered.
#0 0.447 Err:2 http://deb.debian.org/debian bookworm-updates InRelease
#0 0.447   At least one invalid signature was encountered.
#0 0.488 Err:3 http://deb.debian.org/debian-security bookworm-security InRelease
#0 0.488   At least one invalid signature was encountered.
#0 0.494 Reading package lists...
#0 0.504 W: GPG error: http://deb.debian.org/debian bookworm InRelease: At least one invalid signature was encountered.
#0 0.504 E: The repository 'http://deb.debian.org/debian bookworm InRelease' is not signed.
#0 0.504 W: GPG error: http://deb.debian.org/debian bookworm-updates InRelease: At least one invalid signature was encountered.
#0 0.504 E: The repository 'http://deb.debian.org/debian bookworm-updates InRelease' is not signed.
#0 0.504 W: GPG error: http://deb.debian.org/debian-security bookworm-security InRelease: At least one invalid signature was encountered.
#0 0.504 E: The repository 'http://deb.debian.org/debian-security bookworm-security InRelease' is not signed.

このようなエラーが発生。

今回の対応的には、

Dockerイメージやコンテナのキャッシュをクリア

という対応を行ったので、

自分の備忘録として、

忘れないうちにメモを残しておきます。

エラー内容

実行処理としては、

docker-compose -f docker-compose.sample.yml build

という形で、

docker-compose.sample.yml

というファイルを準備して、

そちらをビルドする流れてで進めていました。

このビルドを実行したところ、

 => ERROR [ 3/22] RUN apt-get update 
[+] Building 2.7s (9/26)
 => [internal] load build definition from Dockerfile 
　 ：
 => ERROR [ 5/22] RUN apt-get update 
------
 > [ 5/22] RUN apt-get update 
#0 0.313 Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
#0 0.362 Get:2 http://deb.debian.org/debian bookworm-updates InRelease [55.4 kB]
#0 0.383 Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0 kB]
#0 0.407 Err:1 http://deb.debian.org/debian bookworm InRelease
#0 0.407   At least one invalid signature was encountered.
#0 0.447 Err:2 http://deb.debian.org/debian bookworm-updates InRelease
#0 0.447   At least one invalid signature was encountered.
#0 0.488 Err:3 http://deb.debian.org/debian-security bookworm-security InRelease
#0 0.488   At least one invalid signature was encountered.
#0 0.494 Reading package lists...
#0 0.504 W: GPG error: http://deb.debian.org/debian bookworm InRelease: At least one invalid signature was encountered.
#0 0.504 E: The repository 'http://deb.debian.org/debian bookworm InRelease' is not signed.
#0 0.504 W: GPG error: http://deb.debian.org/debian bookworm-updates InRelease: At least one invalid signature was encountered.
#0 0.504 E: The repository 'http://deb.debian.org/debian bookworm-updates InRelease' is not signed.
#0 0.504 W: GPG error: http://deb.debian.org/debian-security bookworm-security InRelease: At least one invalid signature was encountered.
#0 0.504 E: The repository 'http://deb.debian.org/debian-security bookworm-security InRelease' is not signed.

このエラーが発生しました。

考えられる原因

考えられる原因としては、

Dockerビルド時のリソース不足
ネットワークの問題
Dockerのバージョンに関する問題
Dockerのイメージやコンテナ・キャッシュによる問題

が考えられます。

最終的には、

Dockerのイメージやコンテナ・キャッシュによる問題

が原因でした。

Dockerビルド時のリソース不足

デフォルトで割り当てられたCPUやメモリについて、

複数立ち上げを行っていると、

PCのスペック的には、

ビルドのプロセスでリソース不足が発生します。

ただ、今回の自分の環境では、

特に問題はなさそうでした。

ネットワークの問題

この点に関しては、

特に他のDebian系の環境で

apt-get update

を動かしてみても、

特に問題ない状態ですし、

自分のPCからの外部アクセスについても、

特に問題見当たらなかったため、

この点は影響なしと考えました。

Dockerのバージョンに関する問題

Dockerのバージョンについては、

バージョンごとに、

うまくいかない点が出てきますが、

自分は比較的バージョンを上げて対応しており、

同じビルドしている設定とは、

特にバージョンを変えていないので、

この点も問題なしと判断しました。

Dockerのイメージやコンテナ・キャッシュによる問題

上記に記載した点は問題なかったので、

最後の考えられることとして、

現在の自分の環境にあるDockerイメージや、

使っている・使っていたコンテナ・キャッシュ周りが影響して、

うまくビルドが動いていないことが考えられます。

キャッシュされたイメージやコンテナが原因で、

問題が発生していることもあるようなので、

まずは、（これは解決策ではありません）

docker-compose -f docker-compose.sample.yml build --no-cache

こちらで、

ビルドしているキャッシュ自体を使わないで、

ビルドプロセスを試してみます。

しかし、同じようなエラーとなります。

ビルドプロセスで使用されるベースイメージが更新された場合など、

キャッシュされた状態が原因でビルドが失敗することがあるようなので、

Dockerイメージやコンテナのキャッシュをクリア

を行います。

コマンド

docker system prune -a

こちらを実行すると、

今までのイメージやキャッシュがクリアされます。

こちらでクリアしたのちに、

再度、ビルドプロセスを試します。

docker-compose -f docker-compose.sample.yml build

こちらを実行したら、

うまくビルドが完了しました。

これで解決ですね。

プログラミングの独学におすすめのサイト・サービス一覧

初心者の方が、

プログラミング学習を独学で進めていくと、

なかなか、プログラミング学習がうまく進まない…
どうしたらいいかな。
独学のためのサイトやサービスはないかな…

という感じで、

独学をする中でも、

書籍での学習挫折しそうになって、

せっかく始めたプログラミング学習をやめてしまうことがあります。

プログラミング学習の中では、

色々なことで、うまくいかないことはありますが、

プログラミング学習を諦めずに、もう少し学習を続けてみること
学習内容としてインプットだけでなく、アウトプットもできること
学習の進捗や今後の流れなどがある程度、把握できること

という点のどれか、

または、複数満たせることが大切だと考えています。

そんな中で、

独学の時に書籍についても、

全体像把握という点ではおすすめな点はありますが、

１つの独学の方法として、

独学におすすめなサイトやサービスを活用してみる

ということが１つの選択肢になります。

そんな独学のサイトやサービスについてですが、

初心者の方には、

独学での学習をしていく中で、
自分の現時点での学習状況・理解度を把握することが大切
ということがあります。
その点を自分なりに考えた上で、
自分なりにあったサイト・サービスを見つけて活用すると良いでしょう。
また、人それぞれ、おすすめなサイト・サービスであっても、
使う中での好料の相談ができるところが多いので、
いくつかサイトやサービスはありますが、
一度、いくつか試してみて自分のに合っているのかを試してみることが大切です。
「使いやすい」とか「やっていて楽しい」など、
ちょっとしたことでも構いません。
自分なりに取り組みやすいサイト・サービスを活用しましょう。

とお伝えしています。

この記事では、

個人的にピックアップしたおすすめのサイト・サービスを載せています。

私なりのサイト・サービスに対する主観になりますので、

気になったものは、一度、自分なりに試してみてみることをお勧めします。

随時、初心者向けにオススメできるサイト・サービスを見つけたら、

追加していっているので、少しでも参考になれば嬉しいです。

プログラミングの独学におすすめのサイト・サービス一覧

スクール名	オススメポイント	サイト
Progate	初心者に特におすすめで、スライド形式で分かりやすく、RPGゲームのようなレベルを積み上げるサービスです。ブラウザ上でプログラミングができ、開発環境構築でのトラブルがないため、学習に集中しやすいです	公式サイトに移動
ドットインストール	3分程度の短い動画で学べるサイトで、テンポよく学習できます。プログラミング言語だけでなく、フレームワーク、インフラ、ツール関連の知識も学べるのが特徴です	公式サイトに移動
Paizaラーニング	Progateとドットインストールを合わせたようなサイトで、3分程度の短い動画で基礎を学んだ後、ブラウザ上でコーディングが可能です	公式サイトに移動
Codecademy	英語のサイトですが、高校生レベルの英語力があれば利用可能です。指示に従いながら実際にコードを書き、プログラミングを学べます	公式サイトに移動
CODEPREP	コーディング演習を提供し、特に初心者向けのコンテンツが豊富です。無料で利用でき、インタラクティブなコーディング演習が特徴です	公式サイトに移動
CODEGYM Monthly	初心者で毎月の費用でサポートしてくれる人が欲しい方におすすめ。プログラミングスクールの中では比較的リーズナブルなので、無料相談をしてから数ヶ月試してみるのがおすすめ。	公式サイトに移動

Progate

初心者に特におすすめで、

スライド形式で分かりやすく、

RPGゲームのようなレベルを積み上げるサービス

というのが特徴として感じます。

ブラウザ上でプログラミングができ、

開発環境構築でのトラブルがない

という点が初心者に優しく、

学習に集中しやすいです。

ドットインストール

3分程度の短い動画で学べるサイトで、

テンポよく学習できます。

プログラミング言語だけでなく、

フレームワーク
インフラ
ツール関連

など、

幅広く知識も学べるのが特徴です。

自分が気になるカテゴリの、

自分が気になる部分の内容だけでも、

動画を見るとヒントになることもあるので、

気になったものは見てみるという感じで使うのもオススメです。

Paizaラーニング

個人的な感覚ですが、

Progateとドットインストールを合わせたようなサイトで、

3分程度の短い動画で基礎を学んだ後、

ブラウザ上でコーディングが可能なので、

実際に手を動かしながら試せる

という点がすごくオススメなポイントです。

この手を動かして試せるという点は、

初心者がハマりやすい環境構築が不要
実際にコードを書くことでアウトプットの練習になる

ということが大きいので、

この点は実際に試してみてもらえると、

オススメポイントがわかっていただけると思います。

Codecademy

英語のサイトですが、

基礎的な英語力があれば利用可能かなと個人的には感じます。

私自身も英語音痴でしたが、

プログラミング自体はIT業界で取り組んできたので、

それを踏まえて、英語に慣れていきたいなと思った時に、

このサイトを見つけて少し取り組んでいました。

このサイトを使う中で、

英語なので、使っていく中で英語に慣れていく
指示に従ってコードを書くというトレーニングができる

という点が、

取り組んでいく中で身につけることができる可能性があるので、

プログラミングだけでなく、合わせて英語も取り組みたい

と考えている方にはオススメします。

CODEPREP

コーディング演習を提供し、

特に初心者向けのコンテンツが豊富です。

インタラクティブなコーディング演習が特徴です。

自分なりに考えて取り組んでいく要素があり、

ヒントを見て自分なりに考える
TIPSとして各種概要を理解する

という点が合わせてできるのが良いと感じています。

他のサービスに似た部分もありますが、

この構成や進め方が好きな人にはすごく合う

と感じています。

コンテンツ量も少しずつ増えていっているので、

最新コンテンツやサイトやサービスを確認してみると良いでしょう。

Railsでdb:migrate:resetがうまく動かなかった時の対応メモ

まとめ（おすすめサイト・サービス一覧）

スクール名	オススメポイント	サイト
Progate	初心者に特におすすめで、スライド形式で分かりやすく、RPGゲームのようなレベルを積み上げるサービスです。ブラウザ上でプログラミングができ、開発環境構築でのトラブルがないため、学習に集中しやすいです	公式サイトに移動
ドットインストール	3分程度の短い動画で学べるサイトで、テンポよく学習できます。プログラミング言語だけでなく、フレームワーク、インフラ、ツール関連の知識も学べるのが特徴です	公式サイトに移動
Paizaラーニング	Progateとドットインストールを合わせたようなサイトで、3分程度の短い動画で基礎を学んだ後、ブラウザ上でコーディングが可能です	公式サイトに移動
Codecademy	英語のサイトですが、高校生レベルの英語力があれば利用可能です。指示に従いながら実際にコードを書き、プログラミングを学べます	公式サイトに移動
CODEPREP	コーディング演習を提供し、特に初心者向けのコンテンツが豊富です。無料で利用でき、インタラクティブなコーディング演習が特徴です	公式サイトに移動
CODEGYM Monthly	初心者で毎月の費用でサポートしてくれる人が欲しい方におすすめ。プログラミングスクールの中では比較的リーズナブルなので、無料相談をしてから数ヶ月試してみるのがおすすめ。	公式サイトに移動

Railsで初期テーブルデータをseedで設定

Railsでアプリケーションを作って、

そのアプリケーションを運営する中で、

現在のテーブルの項目を調整することは、

実際によくあることだと思います。

そんな中で、

既存のカラムを削除する
既存のカラムを変更する
新規のカラムを追加する

という時に、

既存のテーブルに対して、

変更を加えた際に、

rails db:migrate:reset

などを実行してしまうと、

全てのテーブルがクリアされてしまう。

以下の記事の中のコマンドです。

こちらの対応ではなく、

対象のテーブルだけ、

設定情報を反映させることが必要でした。

この時の対応は、

Railsで特定のテーブルを再作成する方法

こちらの記事にメモしています。

今回は、

この対応の後に、

テーブルの初期データ作成のために、

seedでの処理を動かした時のメモです。

備忘録として記載しておきます。

Railsのマイグレーションの状況確認

まずは、

Railsのマイグレーションで作成したテーブルの、

作成状況をコマンドで確認します。

rails db:migrate:status

のコマンドを実行すると、

$ rails db:migrate:status
Running via Spring preloader in process 428491

database: sample

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20220101000000  Sample1
   up     20220207000000  Sample2
   up     20220207010000  Sample3
   up     20220207020000  Sample4
   up     20220207030000  Sample5
   up     20220208000000  Sample6
   up     20220222010000  Sample7
   up     20220223000000  Sample8

このようにRailsのマイグレーションの状況が表示されます。

こちらを見てわかるように、

Railsの各種テーブルのステータスが「up」の状態である

ということが言えます。

「down」だとうまくテーブル自体の作成が行われていないので、

まずは、こちらを確認、対応してください。

Railsで特定のテーブルを再作成する方法

Railsでseedを使って初期テーブルデータを作成

先ほどのテーブルの一覧に対して、

必要なテーブルの初期データを設定します。

指定テーブルの初期データを「seeds.rb」に記載
Railsコマンドで「seed」を実行

という手順で対応します。

設定ファイルとして、

「seeds.rb」

については、

db/seeds.rb

にあるので、

こちらのファイルで初期設定データを準備してください。

Railsコマンドで初期データ追加

先ほどの初期データ設定ファイルを準備した上で、

実際のRailsコマンドを実行します。

基本は、

rails db:seed

ですが、

自分の環境に合わせて

rails db:seed RAILS_ENV=development
rails db:seed RAILS_ENV=test

このように環境指定することもできます。

実際に実行すると、

$ rails db:seed
Running via Spring preloader in process 2735808

このように

実施された結果のプロセスIDが表示されるので、

データベースの方で実データを確認すると、

うまく初期データが追加されており、

問題なく処理が完了しました。

docker-composeでコンテナを立ち上げて、コンテナにアクセスするための流れをメモ

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

https://docs.docker.jp/compose/reference/overview.html

こちらを参考にしてください。

今回は、

docker-compose

を使っているのですが、

対応後の問題の対応は記事等でメモしていましたが、

実際のファイル準備後の

docker-composeコマンドで立ち上げる際の手順

をよく忘れてしまうので、

自分の備忘録として、

忘れないうちにメモを残しておきます。

事前準備

ファイルとしては、

docker-compose.sample.yml

というファイルを準備します。

このファイルの中身自体のサンプルは、

また別途、気が向いたら、機会があれば、

記事としてシンプルなものを記載しようと思います。

docker-composeコマンドでの立ち上げの流れ

立ち上げの流れとしては、

「build」コマンドでビルドを実施
「up」コマンドでコンテナを立ち上げ

という流れになります。

参考サイト

まずは、

「build」コマンドでビルドを実施

という対応を行います。

docker-composer -f docker-compose.sample.yml build

上記の「-f」オプションは、

ファイル指定が必要なので、

オプションとして使用しています。

次に、

「up」コマンドでコンテナを立ち上げ

を行います。

コマンドとしては、

docker-composer -f docker-compose.sample.yml up -d

という「up」コマンドで、

立ち上げを行っています。

ちなみに、

「-d」オプションについては、

このように、

バックグラウンドでの立ち上げオプションです。

ここまで実行できたら、

Dockerコンテナの状況を確認する

という形で、

実際のDockerコンテナが立ち上がっているか、

コマンドを実行して確認します。

コマンド

docker ps

こちらで、

自分が作成したDockerコンテナが、

リストに表示されるので、

docker exec -it sample /bin/bash

のように、

コンテナにアクセスすることができました。

こちらで、

うまくdocker-composeが挙動しましたので、

次回以降は忘れないように、

この記事を見ようと思います。

DockerコンテナのMySQLでクライアントで日本語データ確認したら文字化けしていたので調整

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

こちらを参考にしてください。

今回は、

すでにMySQL用のコンテナを立ち上げており、

このMySQLへの各種アクセスや処理は問題ないのだが、

このコンテナ内のMySQLクライアントで、

接続してからデータを見ると文字化けする事象が発生。

その際に、試した時の対応を、

自分の備忘録として、

忘れないうちにメモを残しておきます。

事象メモ

実際のMySQLクライアントで、

データを確認を

select * from table_name

のように確認すると、

実際の値の表示が、

このように、

うまく文字列（日本語）が表示されなかった。

対応方法のメモ

今回の対応については、

MySQLコマンドで実行できました。

調整は、

現在の文字コードの状況を確認
文字コードを調整

という流れで、

まずは、確認から。

確認コマンド

SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';

確認結果

> SHOW VARIABLES LIKE 'collation%';
+----------------------+--------------------+
| Variable_name        | Value              |
+----------------------+--------------------+
| collation_connection | latin1_swedish_ci  |
| collation_database   | utf8mb4_0900_ai_ci |
| collation_server     | utf8mb4_0900_ai_ci |
+----------------------+--------------------+

確かに、

collation_databaseとcollation_serverがutf8mb4_0900_ai_ciに設定されており、

これはUTF-8の4バイト対応版であるutf8mb4の文字セットを使用していることを意味します。

これは、データベースとサーバーが日本語を含む多様な文字を適切に扱える設定になっています。

しかし、

collation_connectionがlatin1_swedish_ciになっているため、

クライアント（アプリケーション）と

MySQLサーバー間の接続で使用される文字セットがLatin1（西欧言語用）に設定されています。

これが原因で、日本語が正しく扱われずに文字化けしてしまう可能性があります。

調整としては、

utf8mb4_0900_ai_ci

に変更します。

調整コマンド

SET NAMES utf8mb4 COLLATE utf8mb4_0900_ai_ci;

こちらを実行して、

再度、

SHOW VARIABLES LIKE 'collation%';

で確認すると、

> SHOW VARIABLES LIKE 'collation%';
+----------------------+--------------------+
| Variable_name        | Value              |
+----------------------+--------------------+
| collation_connection | utf8mb4_0900_ai_ci |
| collation_database   | utf8mb4_0900_ai_ci |
| collation_server     | utf8mb4_0900_ai_ci |
+----------------------+--------------------+

となりうまく対応できました。

今回のMySQLクライアントだけで対応しているので、

コンテナ自体の設定を調整したわけではないので、

コマンド実行に際して、コンテナの停止は不要

という部分は、

今回の調整方法としては、

対応としてよかったのかなと思います。

コンテナ作成時に、

同じ事象が発生する点については、

別途、再立ち上げが必要なタイミングで、

調査対応を行おうと思います。

Laravelで「Allowed memory size of 134217728 bytes exhausted」でメモリサイズのエラーが発生した件

Laravelを使用していて、

必要なデータを集計して、

様々な処理を行うことがあります。

そんな時に、

ファイルダウンロードでエラーになることが発生しました。

この時のエラーについて、

確認方法をメモ。

Laravelのバージョン

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 10.13.5

というバージョンであることがわかります。

発生した事象

ファイルをダウンロードする処理を行うと、

エラー内容が残っており、

以下のように、

メモリサイズのエラーが記載されていた。

Allowed memory size of xxxxxxxx bytes exhausted 
xxxxxxxはエラーになったサイズ

実際にこのエラーになったサイズでは、

メモリサイズの指定としては、

許容を超えているのでエラーというところ。

メモリサイズの設定

自分が動かしている環境では、

php8.1-fpmを使っているので、

以下の設定ファイルを変更する。

/etc/php/8.1/fpm/php.ini

上記ファイルの中の

memory_limit

のサイズを変更します。

ファイル内の、

メモリサイズ（memory_limit）を変更します。

memory_limit = xxxM

xxxには任意のサイズを指定してもらって、

MByteでの指定をしています。

上記の設定変更が終わったら、

php8.1-fpmも再起動させます。

再起動コマンド

sudo service php8.1-fpm restart

こちらで再度確認すると、

うまく処理が完了しましたので、

解決できました。

Dockerのネットワークに特定のコンテナを追加する方法

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

https://slack.dev/bolt-js/ja-jp/tutorial/getting-started

こちらを参考にしてください。

今回は、

コンテナを立ち上げており、

最初から同じネットワークに入れておけばよかったけれど、

後からそのことに気づいきました。

その際に、

コマンドで、指定のネットワークに、

特定コンテナを追加する方法を調べて、

試した時の対応を、

自分の備忘録として、

忘れないうちにメモを残しておきます。

対応方法のメモ

今回の対応については、

コマンドで実行できました。

実行前の確認として、

上記の記事を参考に、

ネットワーク一覧
ネットワークの詳細

の２点を確認します。

ネットワークの一覧

docker network ls

特定コンテナの詳細

docker network inspect [ネットワーク名]

確認した結果、

        "Containers": {
            "xxxxxxx": {
                "Name": "xxxxx",
                "EndpointID": "xxxxxxxxx",
                "MacAddress": "xxxxxxxxx",
                "IPv4Address": "172.29.0.3/16",
                "IPv6Address": ""
            },
        },

このように、

調整前は１つのコンテナのみになっています。

その状態で、

以下のコマンドでネットワークに対して、

特定のコンテナを追加します。

ネットワークへの追加コマンド

docker network connect oms_app-network [コンテナ名]

こちらを実行して、

再度、

ネットワークを確認してみると、

        "Containers": {
            "xxxxxxx": {
                "Name": "xxxxx",
                "EndpointID": "xxxxxxxxx",
                "MacAddress": "xxxxxxxxx",
                "IPv4Address": "111.22.0.3/16",
                "IPv6Address": ""
            },
            "xxxxxxx": {
                "Name": "xxxxx",
                "EndpointID": "xxxxxxxxx",
                "MacAddress": "xxxxxxxxx",
                "IPv4Address": "111.22.0.4/16",
                "IPv6Address": ""
            },
        },

このように、

うまく特定のコンテナが、

指定のネットワークに追加されました。

試してみたところ、

コマンド実行に際して、コンテナの停止は不要

ということがわかったので、

誤ってネットワークに入れ忘れた時も、

この対応を行うことで解決できるかと思います。

Slack API（Slack bolt）の環境設定情報の確認方法

Slackを使っていく中で、

APIを活用して、

便利に使用していこうとしています。

そんな中で、

Slack APIを活用していく中で、

Slack Boltのライブラリを活用して使用しています。

そんな中で、

環境設定値を確認するときに、

どこを確認して良いかわからなくなるので、

ゆくゆく同じことでハマりそうなのでメモ。

公式サイト

まずは、公式サイト。

リンク先を忘れるのでメモ。

以下あたりは注意したいところ。

🔒 全てのトークンは安全に保管してください。少なくともパブリックなバージョン管理にチェックインするようなことは避けるべきでしょう。また、上にあった例のように環境変数を介してアクセスするようにしてください。詳細な情報はアプリのセキュリティのベストプラクティスのドキュメントを参照してください。
Bolt公式サイトより引用

SLACK_BOT_TOKEN

公式サイトにも記載がある通り、

このように公式サイトに載っているので、

実際に確認してみます。

OAuth&Permissionsのページを確認すると、

実際に設定値がありました。

こちら赤枠部分が対象箇所ですね。

SLACK_SIGNING_SECRET

公式サイトにも記載がある通り、

このように記載がありますね。

公式サイトに載っているページを、

実際に確認してみます。

Basic Infomationのページを確認すると、

実際に設定値がありました。

こちら赤枠部分が対象箇所ですね。

Basic Infomationは項目も多いので、

対象箇所を間違えないように注意ですね。

SLACK_APP_TOKEN

こちらのSLACK_APP_TOKENの設定値は、

公式サイトに具体的な場所の記載は見つけられませんでした。

（自分が見つけきれてないだけかもしれません）

実際にSlack APIのページから色々と確認したところ、

Basic Infomaitonページの中にありました。

設定自体は過去に設定はしていた気はしますが、

ここで確認するのかと。

画面表示としては、

このように、

先ほどのSLACK_SIGNING_SECRETを確認した箇所よりも、

下にスクロールしてもらうと、

上記画面部分があります。

こちらをクリックするとモーダルが開き、

このように、

SLACK_APP_TOKENのための値を

確認することができました。

よく忘れるので、またやる時にこれを見よう。

DockerホストからコンテナのアプリケーションにCurlでPOSTしたら動かなかった件

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

こちらを参考にしてください。

今回は、

コンテナを立ち上げて、

その中のアプリケーションに対して、

ホストからcurlを使ってPOSTをしたけれど、

なぜか動かなかったので、

その時の対応を、

自分の備忘録として、

忘れないうちにメモを残しておきます。

起きた事象

ホストのアプリケーションから、

コンテナ内のアプリケーションに対して、

curlを使ってPOSTをしていました。

その時に、

ホストからコンテナへのアクセス等は問題ない
ホストからGETでの処理は問題ない
ホストからPOSTでの処理が動かない

という事象が発生しました。

調査時のメモ

上記の起きた事象で、

もう少し細かく調べた時のメモ。

ホストから

コンテナ内のアプリケーションに、

curlでPOSTを実行した時、

ステータスは、

'http_code' => 200,

のように正常系で終了。

コンテナ側のアプリケーションでログを確認したところ、

何もログが表示されなかった。

実際にPOSTのデータの中身に問題あるかと考え、

CurlのPOSTで送っているデータを空にしたところ、

データを空にするとうまく挙動する

ということがわかったので、

POSTデータサイズの影響で問題が起きている

ということがわかりました。

この辺りで、

今までの知見で、

自分が実行している環境では、

post_max_size

の設定値がデフォルトの時に、

サイズ問題でエラーになったことが多かったので、

この部分の調整に取り掛かりました。

最終的な対応方法

先ほどのPOSTのサイズ問題を調整していきます。

実際に自分が動かしているPHPの環境では、

このようにサイズが初期状態でした。

動かしている内容が、

サイズ的にはこれを超えているので、

Docker内の設定を調整して反映させる

ということを行うことにしました。

設定ファイル

/usr/local/etc/php/php.ini

変更箇所

post_max_size = 20M
memory_limit = 20M
upload_max_filesize = 20M

上記に関して、

必要プロパティや他の必要なプロパティを追加。

こちらを反映させます。

反映方法としては、

Dockerを再起動することで反映させます。

再起動コマンド

docker restart [container id]

上記で、

コンテナを再起動して、

実際の設定情報を確認してみます。

うまく変わっていますね。

こちらの状況で、

再度、

元々うまく動かなかった処理を動かすと、

問題なく処理動きました。

無事に解決できました。

Ubuntuでdocker-composeがエラー「command not found: docker-compose」

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

こちらを参考にしてください。

今回は、

docker-compose

を使っているのですが、

特定のサーバーで環境を構築するために、

コマンドを実行したところエラーになりました。

その時の対応を、

自分の備忘録として、

忘れないうちにメモを残しておきます。

エラー内容

普段から、

docker-composeを使ってビルドをしていましたが、

別のサーバーでも環境を作ろうとして、

実行したところ、エラーが発生

実行コマンド

docker-compose -f docker-compose.sample.yml build

エラー内容

$ docker-compose -f docker-compose.sample.yml build
command not found: docker-compose

ということで、

docker-composeが見つからないとのこと。

最終的な対応方法

こちらはシンプルに、

サーバーにdockere-composeを導入

を行うことで解決しました。

解決するための過程等をメモ。

念のために、

Docker自体が動いているか確認。

確認コマンド

docker ps

確認結果

$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

こちらで、

Docker自体は問題ないですね。

それでは本題の方の、

docker-composeを導入します。

docker-composeのバイナリを取得します。

ベースのコマンドはこちらです。

sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

こちらのコマンドで、

環境にあったバイナリが取得できると思いますが、

必要に応じて、

download/docker-compose-$(uname -s)-$(uname -m)"

の部分で指定することで、

任意のバイナリを取得することも可能です。

のバージョンを調整してください。

取得できたら、

実行権限を調整します。

コマンド

sudo chmod +x /usr/local/bin/docker-compose

こちらで権限の調整が終わるので、

実際にコマンドで確認してみましょう。

確認コマンド

docker-compose --version

確認したところ、

$ docker-compose --version
Docker Compose version v2.23.0

このように、

うまくdocker-composeが挙動しましたので、

無事に解決できました。

Dockerでエラー「dial unix /var/run/docker.sock: connect: permission denied.」

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

こちらを参考にしてください。

今回は、

docker-compose

を使っているのですが、

特定のサーバーで環境を構築するために、

コマンドを実行したところエラーになりました。

その時の対応を、

自分の備忘録として、

忘れないうちにメモを残しておきます。

エラー内容

docker-composeを使ってビルドをしていましたが、

エラーになっているので、

そもそも、

Docker自体が動いているのかを確認してみました。

実行コマンド

docker ps

エラー内容

Got permission denied 
while trying to connect to the Docker daemon socket 
at unix:///var/run/docker.sock: 
Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json": 
dial unix /var/run/docker.sock: connect: permission denied

ということで、

Docker自体が正しく挙動していませんでした。

最終的な対応方法

いくか設定を変更したりしていましたが、

結論として、

権限を調整して、Dockerを再起動

を行うことで解決しました。

権限を調整

sudo usermod -aG docker $USER

こちらで、

現在のユーザーをdockerグループに追加しています。

Dockerの再起動

sudo systemctl restart docker

こちらで、

先ほどの設定を反映するために、

Dockerのデーモンを再起動します。

もし、

SSHなどで接続している場合は、

現在のシェルに反映するためには、

現在のシェルに反映させるためにコマンドで対応
一度、ログアウトして、再度、SSHで接続

のどちらかが必要です。

直接、

現在のシェルに反映させるには、

以下のコマンドが必要です。

現在のシェルに反映させるコマンド

newgrp docker

ここまでの対応を行うことで、

エラー自体が解決できました。

実際に、

docker ps

のコマンドで確認したところ、

$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

このように、

うまくDocker自体が挙動しましたので、

無事に解決できました。

エラー「ERROR: Version in “./docker-compose.authentication.yml” is unsupported.」

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

https://docs.docker.com/compose/compose-file/

こちらを参考にしてください。

今回は、

docker-compose

を使っているのですが、

別のサーバーに入って、

コマンドを実行したところエラーになりました。

その時の対応を、

自分の備忘録として、

忘れないうちにメモを残しておきます。

エラー内容

docker-composeを使ってビルドをしていました。

実行コマンド

docker-compose -f xxx.yml build

エラー内容

ERROR: Version in "./docker-compose.authentication.yml" is unsupported. 
You might be seeing this error because you're using the wrong Compose file version. 
Either specify a supported version (e.g "2.2" or "3.3") 
and place your service definitions under the `services` key, 
or omit the `version` key 
and place your service definitions at the root 
of the file to use version 1.
For more on the Compose file format versions, 
see https://docs.docker.com/compose/compose-file/

ということで、

上記に関して記載のある公式サイトのリンクはこちらです。

最終的な対応方法

いくか設定を変更したりしていましたが、

結論として、

バージョンを確認時点の最新に変更

を行うことで解決しました。

古いバージョン

$ docker-compose -v
docker-compose version 1.25.0

こちらのバージョンを、

新しいバージョン

$ docker-compose -v
docker-compose version 1.29.1

になるように調整することで、

エラー自体が解決できました。

この時のバージョンアップの具体的な方法は、

以下の記事にメモしています。

docker-composeのバージョンのアップデート

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

https://qiita.com/ma-me/items/090c3e9befc31e68f063

こちらを参考にしてください。

今回は、

docker-compose

を使っているのですが、

このバージョン自体を上げたい環境があり、

その時のコマンドを、

自分の備忘録として、

忘れないうちにメモを残しておきます。

docker-composeのバージョンを確認

以下のコマンドで確認していきます。

確認コマンド

docker-compose -v

確認結果

$ docker-compose -v
docker-compose version 1.25.0

こちらで、

現在のバージョンが1.25.0であることがわかります。

docker-composeのバージョンアップの方法

先ほどのバージョンから、

バージョンを確認時点の最新に変更します。

古いdocker-compose自体を削除

rm -rf docker-compose

バージョン指定で取得

sudo curl -L "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

権限を調整

sudo chmod +x /usr/local/bin/docker-compose

上記をしたあと、

SSHで接続をしているので、

１度、ログアウトしてから、再度ログインしました。

こちらでバージョンを再確認します。

確認コマンド

docker-compose -v

確認結果

$ docker-compose -v
docker-compose version 1.29.1

こちらでうまくバージョンがアップデートできました。

Docker+Python3+Seleniumで「chromedriver unexpectedly exited. Status code was: 255」

Docker上に、Python3.8ベースで環境を作り、

seleniumで試そうとしていたところ、

うまくいかない事象が起きて、

エラーが起きたのでメモを残す。

個人的な備忘録のために、

この記事に残しておく。

エラー内容メモ

コンテナ内で、

seleniumを立ち上げる中で、

chromedriverの処理として、

    try:
        self.driver = webdriver.Chrome(options=chrome_options)
    except Exception as e:
        print(f"An error occurred: {str(e)}")

この部分でエラーを確認すると、

An error occurred: 
Message: 
Service /root/.cache/selenium/chromedriver/linux64/118.0.5993.70/chromedriver 
unexpectedly exited. 
Status code was: 255

このようなエラーが発生。

参考サイト

以下の２つ。

https://github.com/googlecolab/colabtools/issues/3347

個人用のコードメモ

上記サイトを参考に、

以下のコードを作って実行。

vi update_selenium_for_debian.sh

#!/bin/bash

# Ubuntu no longer distributes chromium-browser outside of snap
#
# Proposed solution: https://askubuntu.com/questions/1204571/how-to-install-chromium-without-snap

# Add debian buster
cat > /etc/apt/sources.list.d/debian.list <<'EOF'
deb [arch=amd64 signed-by=/usr/share/keyrings/debian-buster.gpg] http://deb.debian.org/debian buster main
deb [arch=amd64 signed-by=/usr/share/keyrings/debian-buster-updates.gpg] http://deb.debian.org/debian buster-updates main
deb [arch=amd64 signed-by=/usr/share/keyrings/debian-security-buster.gpg] http://deb.debian.org/debian-security buster/updates main
EOF

# Add keys
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys DCC9EFBF77E11517
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 648ACFD622F3D138
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 112695A0E562B32A

apt-key export 77E11517 | gpg --dearmour -o /usr/share/keyrings/debian-buster.gpg
apt-key export 22F3D138 | gpg --dearmour -o /usr/share/keyrings/debian-buster-updates.gpg
apt-key export E562B32A | gpg --dearmour -o /usr/share/keyrings/debian-security-buster.gpg

# Prefer debian repo for chromium* packages only
# Note the double-blank lines between entries
cat > /etc/apt/preferences.d/chromium.pref << 'EOF'
Package: *
Pin: release a=eoan
Pin-Priority: 500


Package: *
Pin: origin "deb.debian.org"
Pin-Priority: 300


Package: chromium*
Pin: origin "deb.debian.org"
Pin-Priority: 700
EOF

# Install chromium and chromium-driver
apt-get update
apt-get install chromium chromium-driver

# Install selenium
pip install selenium

作ったら、

sh update_selenium_for_debian.sh

を実行する。

その後、アプリケーション再起動で完了。

Pythonのbottleで作ったものをコンテナで立ち上げるとアクセスできなかった件

Pythonのbottleで、

各種処理を作っており、

今までの環境では、

Nginxをベースに、

サーバー上で直接起動させていた。

環境整備の一環で、

Dockerを使うようになって、

既存アプケーションを、

コンテナに移していく中で、

このbottleで作ったアプリケーションに、

なぜかうまくアクセスできない事象が発生。

この事象について、

個人的な備忘録のために、

この記事に残しておく。

既存アプリケーションの立ち上げ方

ルーティングなどを、

route.py

として作っており、

python3 route.py

で立ち上げるようにしていた。

こんな感じ。

from bottle import Bottle, request, response, route, run, template
 :
if __name__ == '__main__':
    from optparse import OptionParser
    parser = OptionParser()
    parser.add_option("--host", dest="host", default="localhost",
                      help="hostname or ip address", metavar="host")
    parser.add_option("--port", dest="port", default=8080,
                      help="port number", metavar="port")
    (options, args) = parser.parse_args()
    run(app, host=options.host, port=int(options.port))

コンテナに移して起きた事象

コンテナを立ち上げ、

ポートフォワードは、

0.0.0.0:8080->8080/tcp

このようになるように設定している。

コンテナで8080はすでに立ち上げている。

この時に、アクセス状況としては、

以下のようになった。

コンテナ内からのアクセス

コンテナ内で、

curl -l http://localhost:8080

でアクセスを確認すると、

問題なくアクセスできました。

コンテナ外（ホスト）からのアクセス

コンテナ外（ホスト）で、

curl -l http://localhost:8080

でアクセスを確認すると、

curl: (52) Empty reply from server

とレスポンスが空になり、

コンテナ内でアクセスきているのか、

ログを確認してみても、

アクセスされていませんでした。

設定ミスを調整

上記以外にも、シンプルなアプリケーションで、

コンテナ立ち上げ、ポートフォワードのアクセス確認をしたところ、

bottleアプリケーションでブロックしている可能性が高い

という状況判断しました。

この判断して詳しく調べていくと、

from bottle import Bottle, request, response, route, run, template
 :
if __name__ == '__main__':
    from optparse import OptionParser
    parser = OptionParser()
    parser.add_option("--host", dest="host", default="localhost",
                      help="hostname or ip address", metavar="host")
    parser.add_option("--port", dest="port", default=8080,
                      help="port number", metavar="port")
    (options, args) = parser.parse_args()
    run(app, host=options.host, port=int(options.port))

このコードの中で、

parser.add_option("--host", dest="host", default="localhost",

となっていますが、

これが、

localhost

となっているので、

コンテナ内からのみアクセスが可能になっていました。

そのため、

この部分を、

0.0.0.0

に変更します。

parser.add_option("--host", dest="host", default="0.0.0.0",

このように調整して、

アプリケーションを立ち上げ直すことで、

うまくホスト側からでもアクセスできました。

シンプルな事象ですが、

今後のためにもメモしておきます。

Next.jsで「no_secret」のエラー発生

Nextjsで実装していたときに、

Dockerコンテナで立ち上げて、

検証環境に色々と試していたのだが、

上記の画像のようなエラーが発生した。

最初に設定情報をこの環境に入れるのを忘れて、

その後に調整してコンパイルしたのだが、

最初にコンパイルした時のゴミが残り続けた影響な気もする。

今後のために

個人的な備忘録としてこの記事に残します。

エラー内容

エラーに関しては、

このようなエラー表示になっていた。

実際のログを確認すると、

以下のようにログが表示されていた。

no_secret Please define a `secret` in production. MissingSecret 
[MissingSecretError]: Please define a `secret` in production.

設定ファイル周りで、secretファイルは、

開発環境などでは問題なく設定・動作しているので、

基本的に影響はないとは思うが、

１つの調整方法として、

以下を試したのでメモ。

ファイル

pages/api/auth/[...nextauth].js

調整箇所

直接、secret設定を追加。

ただし、開発環境では、なくても動いたので不要なのかもしれない

export const authOptions = {
  :
  secret: process.env.NEXTAUTH_SECRET
}

参考

stackoverflowのページ

再コンパイルが反映されていなかった？

プロセス常駐していたのだが、

こちらを停止して、

色々と確認している中で、

npm run dev

で試しにコンパイルではなく、

シンプルに立ち上げて確認しようとすると、

Error: listen EADDRINUSE: address already in use :::3000

というエラーが発生した。

そのため、

使用ポートを確認するコマンド

lsof -i :3000

こちらでプロセスIDを確認して、

kill -9 [process-id]

でプロセスを終了させて、

再度、起動させるとうまく挙動した。

どちらかというと、

こちらの３０００ポートが、

停止しても残り続けていたのが影響していたのかもしれない。

Dockerコンテナのネットワーク状況の確認コマンド

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

こちらを参考にしてください。

今回は、

複数コンテナを扱う上で、

個人的に使うコンテナのネットワークを確認するコマンドを

自分の備忘録として、

忘れないうちにメモを残しておきます。

Dockerコンテナでよく使うコマンド

コンテナ一覧

docker ps

対象コンテナへの接続

docker exec -it [docker name or id] /bin/bash

Dockerコンテナのネットワーク状況確認のコマンド

複数コンテナを扱う中で、

ネットワークの扱いを確認するときに、

確認するコマンドを調べて、

よく確認するようになったので、

忘れないうちにメモ。

ネットワーク一覧

docker network ls

対象ネットワークの詳細を確認

docker network inspect [network name]

対象ネットワークの削除

docker network rm [network name]

すべてのネットワークの削除

docker network prune

Docker Desktop For Macの導入と基本動作

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

この辺りは、

コマンドで実行したことがあるので、

その辺りは、

Install Docker Desktop on Mac

こちらを参考にしてください。

今回は、

GUIを使う時の画面操作のメモを残すために、

Docker Desktop For Mac

を使って、

画面操作した時のメモを残しておきます。

Docker Desktop For Macのインストール

まずは、

Docker Desktop For Mac

をパソコンにインストールします。

インストールするには、

以下のリンクから、

dmgファイルをダウンロードします。

上記のページで、

この画面で、

Docker Desktop for Mac with Intel chip
Docker Desktop for Mac with Apple silicon

を選んで、

インストールします。

自分自身のパソコンのチップを確認して、

どちらかをインストールします。

状況によっては、既存フォルダを削除

既存で１回入れたことがあるなど、

古いdocker関係の環境があると、

Docker Desktop For Macを起動しようとするときに、

エラーになってしまうことがあります。

自分自身も最初に起きたので、

rm ~/.docker

を削除すると、

うまく起動することができました。

Docker Desktop For Macを起動

実際に、

Docker Desktop For Macを起動

$ docker ps
CONTAINER  .... PORTS                                        NAMES
111        .... 0.0.0.0:8080->10000/tcp, :::8080->10000/tcp  test

エラー内容

エラー内容としては、

サーバーの中（Dockerの外）から、

curlコマンドで実行を確認すると、

確認コマンド

curl -l http://localhost:8080/test

確認結果

$ curl -l http://localhost:8080/test
curl: (52) Empty reply from server

という感じで、

「Empty reply from server」

というエラーが発生しました。

Dockerの中で、

「10000」というポートで立ち上げたサーバーの中で、

このポートにアクセスできるか確認すると、

$ curl -l http://localhost:10000/test
test　←これは検証で試した返却値

という形で、

問題なくレスポンスが返却されていました。

対応方法

解決方法としては、

Docker内で起動しているサーバーのホスト名を、

「localhost」ではなく「0.0.0.0」

に変更するとうまく動作しました。

Dockerの外から、

$ curl -l http://localhost:8080/test
curl: (52) Empty reply from server

というエラーになっていたものが、

$ curl -l http://localhost:10000/test
curl: (52) Empty reply from server

というレスポンスになっているので、

うまく挙動していることが確認できました。

PythonからMySQLへの実行で「Not all parameters were used in the SQL statement」のエラー

今回は、

PythonでMySQLのレコードの追加時に、

Not all parameters were used in the SQL statement

のエラーが発生して、

うまくデータの追加処理ができない事象が発生した。

この対応を行った際に、

うまく調整できずに、

単純なことなのにハマっていたので、

個人用の備忘録としてメモを残しておきます。

使用したMySQLのバージョン確認

mysqlのコマンドラインで確認

mysql -V

実行結果

$  mysql -V
mysql  Ver 8.0.31-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

実行時のエラーログと対応方法

実際に実行した時の、

エラーログをメモ。

<class 'mysql.connector.errors.ProgrammingError'>, 
ProgrammingError(-1, 
'Not all parameters were used in the SQL statement', 
None),

こちらのエラーで、

私のやってきた状況としては、

今までは正常に動いていたのだけれど、

しばらく放置していて、

久しぶりに処理を動かしてみたところ、

エラーになっていた。

こちらを確認すると、

自分の場合はシンプルに、

実際のカラム数と実行時のカラム数が異なっていた

ということだったので、

Pythonのレコード追加の処理の部分を調整したらうまくいった。

今後、カラム追加したときは、

この辺りも注意すること。

メモ、以上。

Reactで配列をmapで繰り返しながら表示しようとするとレンダリングで何も表示されなかった件

Nextjsで実装していたときに、

JavaScriptのmapの処理で、

繰り返しながらレンダリングして、

描画をさせようとした時に、

なぜか描画されない事象が発生した。

ちょっとしたコードの書き方だが、

個人的にハマって時間を使ってしまったので、

今後のために

個人的な備忘録としてこの記事に残します。

うまくいかないパターン

配列を

const numbers = [1, 2, 3, 4, 5];

このように準備して、

mapで繰り返した時の書き方で、

以下の書き方ではうまくレンダリングされなかった。

{
  numbers.map((number) => {
    <>{number}</> 
  })
}

うまくいったパターン

上記のコードを調整して、

変更後のコードはこちら。

{
  numbers.map((number) => 
    <>{number}</> 
  )
}

LaravelのQueueで「XXXX has timed out.」でタイムアウトのエラーが発生した件

Laravelを使用していて、

Queueを用いることで、

様々な処理を行うことがあります。

そんな時に、

なぜかQueueがエラーになることが発生しました。

この時のエラーについて、

確認方法をメモ。

Laravelの公式情報

関連するQueueの情報については、

以下の公式サイトを参照

https://laravel.com/docs/10.x/queues#dealing-with-failed-jobs

Laravelのバージョン

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 10.13.5

というバージョンであることがわかります。

発生した事象

QueueのFailed用のテーブルに、

エラー内容が残っており、

以下のように、

exceptionのカラムにタイムアウトエラーが記載されていた。

XXXX has timed out.

タイムアウト時間の設定

デフォルトの内容に関しては、

公式サイトに以下のように記載がある。

Often, 
you know roughly how long you expect your queued jobs to take. 
For this reason, 
Laravel allows you to specify a "timeout" value. 
By default, the timeout value is 60 seconds. 
If a job is processing for longer than 
the number of seconds specified by the timeout value, 
the worker processing the job will exit with an error. 
Typically, 
the worker will be restarted automatically 
by a process manager configured on your server.

上記に記載がある通り、

By default, the timeout value is 60 seconds.

とのことなので、

こちらを調整する必要がある。

こちらは、

Queueの実行時に、

オプションとしてタイムアウトの時間を設定できる

php artisan queue:work --timeout=300

こちらで、

実行時間が300秒に変わるので、

必要に応じてタイムアウト時間を調整すると良いでしょう。

LaravelのQueueのエラーログを確認する方法

Laravelを使用していて、

Queueを用いることで、

様々な処理を行うことがあります。

そんな時に、

なぜかQueueがエラーになることが発生しました。

この時のエラーについて、

確認方法をメモ。

Laravelの公式情報

関連するQueueの情報については、

以下の公式サイトを参照

https://laravel.com/docs/10.x/queues#dealing-with-failed-jobs

Laravelのバージョン

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 10.13.5

というバージョンであることがわかります。

発生した事象

Queueの処理を行っていたのだが、

Laravel内のモデルの処理で、

なぜか途中で停止してしまう。

また、

停止されると、

Jobsのテーブルからも削除されていた。

Queueのエラー（失敗時）のログ確認

確認したい内容としては、

エラー時（失敗時）のログとして、

理由が知りたかったので、

そちらについては、

Queueのfailed用のテーブルがあるので、

そちらを準備して実行すると確認できます。

php artisan queue:failed-table

php artisan migrate

こちらで、

failed_jobs

というテーブルが作成されるので、

実行すると、

エラー時（失敗時）の内容が、

そちらに記載されるので、

内容を確認すると良いでしょう。

SSHの設定

SSHの設定に関して、

VPSや各種クラウド上のサーバー等で、

設定していた時のメモ。

個人用の備忘録として残しておきます。

SSHの設定ファイル

設定ファイル

/etc/ssh/sshd_config

Vimでの修正

vi /etc/ssh/sshd_config

リロード

sudo systemctl restart ssh

SSH設定内容

Rootユーザーのログイン許可

Rootユーザーでのログインを許可または禁止する

対象プロパティ

PermitRootLogin

設定例（禁止設定）

PermitRootLogin no

パスワード認証の許可・禁止

パスワードでの認証を許可または禁止する

対象プロパティ

PasswordAuthentication

設定例（禁止）

PasswordAuthentication no

公開鍵認証の許可・禁止

公開鍵認証での認証を許可または禁止する

コメントアウトされている時のデフォルトはyes。

対象プロパティ

PubkeyAuthentication

設定例（禁止）

PubkeyAuthentication yes

TypeScriptで「Type error: Argument of type ‘String’ is not assignable to parameter of type ‘string’.」エラーの件

Nextjsで実装していたときに、

TypeScriptを取り入れて、

コードを変更していた際に、

調整していた時のメモ。

発生したのは、

Type error: 
Argument of type 'String' is not assignable 
to parameter of type 'string'.
'string' is a primitive, 
but 'String' is a wrapper object. 
Prefer using 'string' when possible.

のエラーが発生。

このエラーを対応した時のメモ。

個人的な備忘録としてこの記事に残します。

エラー

Next.jsで、

TypeScriptを導入して、

コード調整した上でコンパイルするために、

以下のコマンドを実行

npm run build

調整内容

上記のエラー内容を見てみると、

Type error: 
Argument of type 'String' is not assignable 
to parameter of type 'string'.
'string' is a primitive, 
but 'String' is a wrapper object. 
Prefer using 'string' when possible.

という表示。

他のコードと同じように、

TypeScriptを導入して、

型定義の対応が漏れているので調整が必要。

コードの中で、

String（先頭大文字）
string（先頭小文字）

この２つでは、

型の扱いが違うので、

その点を調整。

詳しくは、

TypeScriptのStringとstringは何が違うのか

を参照。

調整前

const sample = (sampleText: String) => {
  :
}

調整後

const sample = (sampleText: string) => {
  :
}

上記で対応。

TypeScriptで「Type error: Property ‘value’ does not exist on type ‘EventTarget’.」エラーの件

Nextjsで実装していたときに、

TypeScriptを取り入れて、

コードを変更していた際に、

調整していた時のメモ。

発生したのは、

Type error: Property 'value' does not exist on type 'EventTarget'.

のエラーが発生。

このエラーを対応した時のメモ。

個人的な備忘録としてこの記事に残します。

エラー

Next.jsで、

TypeScriptを導入して、

コード調整した上でコンパイルするために、

以下のコマンドを実行

npm run build

調整内容

上記のエラー内容を見てみると、

Type error: Property 'value' does not exist on type 'EventTarget'.

という表示。

他のコードと同じように、

TypeScriptを導入して、

型定義の対応が漏れているので調整が必要。

Eventの中の特定プロパティの中で、

さらにvalueのプロパティを取得しようとしていたので、

その点を調整。

調整前

const sampleActions = (event: Event) => {
  :
  if(event.target) {
    console.log(event.target.value);
  }
}

調整後

const sampleActions = (event: Event) => {
  :
  if(event.target) {
    const target = event.target as HTMLInputElement;
    console.log(target.value);
  }
}

上記で対応。

TypeScriptで「Type error: ‘event.target’ is possibly ‘null’.」エラーの件

Nextjsで実装していたときに、

TypeScriptを取り入れて、

コードを変更していた際に、

調整していた時のメモ。

発生したのは、

Type error: 'event.target' is possibly 'null'.

のエラーが発生。

このエラーを対応した時のメモ。

個人的な備忘録としてこの記事に残します。

エラー

Next.jsで、

TypeScriptを導入して、

コード調整した上でコンパイルするために、

以下のコマンドを実行

npm run build

調整内容

上記のエラー内容を見てみると、

Type error: 'event.target' is possibly 'null'.

という表示。

他のコードと同じように、

TypeScriptを導入して、

型定義の対応が漏れているので調整が必要。

Nullデータである可能性があるので、

その点を判定処理して対応させる。

調整前

const sampleActions = (event: Event) => {
  :
}

調整後

const sampleActions = (event: Event) => {
  :
  if(event.target) {
   :
  }
}

上記で対応。

TypeScriptで「Type error: Parameter ‘event’ implicitly has an ‘any’ type.」エラーの件

Nextjsで実装していたときに、

TypeScriptを取り入れて、

コードを変更していた際に、

調整していた時のメモ。

発生したのは、

Type error: Parameter 'event' implicitly has an 'any' type.

のエラーが発生。

このエラーを対応した時のメモ。

個人的な備忘録としてこの記事に残します。

エラー

Next.jsで、

TypeScriptを導入して、

コード調整した上でコンパイルするために、

以下のコマンドを実行

npm run build

調整内容

上記のエラー内容を見てみると、

Type error: Parameter 'event' implicitly has an 'any' type.

という表示。

他のコードと同じように、

TypeScriptを導入して、

型定義の対応が漏れているので調整が必要。

調べた時の参考

TS7006: Parameter ‘event’ implicitly has an ‘any’ types

上記にも記載があるが、

自分の環境のコードだと、

調整前

const sampleActions = (event) => {
  :
}

調整後

const sampleActions = (event: Event) => {
  :
}

上記で対応。

Lintで「Warning: React Hook useEffect has missing dependencies:」エラーの件

Nextjsで実装していたときに、

Lintチェックをしたときに、

Warning: React Hook useEffect has missing dependencies: 
'xxxxxx' and 'xxxxxx'. 
Either include them or remove the dependency array.  
react-hooks/exhaustive-deps

のエラーが発生。

このエラーを対応した時のメモ。

個人的な備忘録としてこの記事に残します。

Lint実行コマンド

Next.jsで、Lintでコード確認したいので、

以下のコマンドを実行

npm run lint

エラー内容

先ほども記載した通り、

上記のLintを実行すると、

Warning: React Hook useEffect has missing dependencies: 
'xxxxxx' and 'xxxxxx'. 
Either include them or remove the dependency array.  
react-hooks/exhaustive-deps

このような表示が出ていた。

調整内容

上記のエラー内容を見てみると、

Warning: React Hook useEffect has missing dependencies: 
'xxxxxx' and 'xxxxxx'. 
Either include them or remove the dependency array.  
react-hooks/exhaustive-deps

の中で、

依存関係周りがうまくいっていないので、

対象を依存関係に含める
依存関係の配列を削除

のどちらかを対応する必要があるらしい。

上記に関して、

useEffectの依存関係を調整。

調整前

  useEffect(() => {
    :
  }, []);

調整後

  useEffect(() => {
    :
  });

上記のように、

依存設定自体の配列を消す対応を行った。

こちらで、

Lintのエラー表示が消えました。

Vue＋TypeScirptでPromise.allをaxiosで並列実行を試した件

Vue+TypeScriptをフロントエンドで使う中で、

APIの処理を並列処理させたいと考え、

Promise.all

を使って、

処理を実装する方法があることを知り、

そちらを試した時のメモ。

処理の実装部分で、

自分自身の環境において、

色々と試したいことがあったので、

そちらについても、

今後のためにメモを残す。

Vueのバージョンについても、

バージョン２系ではなく、

バージョン３系を導入して、

Vue+TypeScriptの構成で試している。

個人用の備忘録としてメモを残しておく。

色々と試しながら、

挙動を確認している感じなので、

この記事に関しては、

必要に応じて、

記事追記、または別記事を追加。

Promise.allの実装時の参考記事メモ

こちらの実装に関しては、

こちらのサイトを参考にしました。

リンクをメモ。

Aggregate Multiple API Requests with Promise.all()

Promise.allを使った部分のベースコード

上記の参考記事などをベースに、

Promise.all

を使ったコードは、

axiosを使うとすると、

以下のようなコードになります。

await Promise.all([
   axios.get("url of api"),
   axios.get("url of api"),
   axios.get("url of api"),
   axios.get("url of api"),
])
.then((response) => {
  console.log(response);
})
.catch(function (response) {
  console.log(response);
});

エラー「TypeError: Cannot read properties of undefined (reading ‘post’)」の対応

上記のコードをベースにしたときに、

エラーとして、

TypeError: Cannot read properties of undefined (reading 'post')

が起こりました。

こちらに関しては、

https://github.com/axios/axios/issues/5262

対策で試したことは、

axiosのバージョンを0.27.2以降に調整
axiosのデフォルト設定を処理に追加

の２つを調整で試みました。

バージョンは、

NPMパッケージで調整してもらえると良いので、

そちらで調整を完了させ、

デフォルト設定についても、

上記サイトの内容を参考に調整しました。

調整したコードとしては、

const axios = require('axios').default;
await Promise.all([
   axios.get("url of api"),
   axios.get("url of api"),
   axios.get("url of api"),
   axios.get("url of api"),
])
.then((response) => {
  console.log(response);
})
.catch(function (response) {
  console.log(response);
});

このようなコードになります。

自分の環境では、

getではなくpostで試したので、

そのあたりはコードが少し違いますが、

ベースとしては、

同じような記載になるかと思います。

TypeScriptでメソッドにする調整

先ほどの、

const axios = require('axios').default;
await Promise.all([
   axios.get("url of api"),
   axios.get("url of api"),
   axios.get("url of api"),
   axios.get("url of api"),
])
.then((response) => {
  console.log(response);
})
.catch(function (response) {
  console.log(response);
});

こちらのコードをベースに、

syncのメソッドとして、

実行されるように調整します。

その調整したコードが、

async actionsStores(): void {
  const axios = require('axios').default;
  await Promise.all([
     axios.get("url of api"),
     axios.get("url of api"),
     axios.get("url of api"),
     axios.get("url of api"),
  ])
  .then((response) => {
    console.log(response);
  })
  .catch(function (response) {
    console.log(response);
  });
}

こちらです。

上記で調整したメソッドをベースに、

必要なaxiosの呼び出しは、

URLなどを変えるために、

ベットメソッドにしましたが、

そちらについては、

機会があれば、

追って追記予定。

XServer VPSでSSHキーを使って接続する方法

XServer VPSを試しに使い始めて、

SSH Keyでの接続について、

設定方法など、

備忘録としてメモしておきます。

XServer VPSの公式サイト

この記事で紹介するXServer VPSのサイトについては、

こちらのリンクから確認してみてください。

<div class="simple-page-link">
<a href="https://px.a8.net/svt/ejp?a8mat=3TB7JM+679KMQ+CO4+25EKCY" rel="nofollow">Xserver VPS</a>
<img border="0" width="1" height="1" src="https://www18.a8.net/0.gif?a8mat=3TB7JM+679KMQ+CO4+25EKCY" alt="">
</div>

XSever VPSのSSH Keyの作成

XServer VPSの管理画面に入って、

こちらの画面の中で、

「SSH Key」

のタイトルの右の方に、

こちらの

「SSH Keyの登録」

から、

新たなSSH Keyを追加できます。

名前の部分に、

作成するキーファイルの名前を設定。

登録方法は、

自動生成を使うと楽なので、

そちらで進めます。

「確認画面へ進む」

を選択すると、

こちらのように、

確認画面が表示されるので、

「登録する」

をクリックします。

注意点としては、

この画面の後のダウンロードは必ず行って、

ファイルは無くさないようにしましょう。

注意ポイント：登録した後の以下のダウンロードのファイルは無くさないように注意です

上記のポイントの画面として、

先程の

「登録する」

の画面の次に、

こちらの画面が表示されるので、

「ダウンロードする」

からファイルをダウンロードしてください。

SSH Keyを使って接続するコマンド

先程の画面で、

ダウンロードしたファイルを使って、

XServer VPSに対して、

接続してみます。

実際の対応自体は、

自分の環境がMACですので、

その環境での対応方ですが、

Windowsでも行う流れは似たような対応になります。

まず、ファイル自体は、

sample_key.pem

というファイル名でダウンロードしたので、

「.ssh」フォルダにSSH Keyファイルを配置
ファイルの権限を「600」に変更
sshコマンドでSSH Keyファイル指定で実行

という流れで、

対応を進めていきます。

まず、

「.ssh」フォルダにSSH Keyファイルを配置

こちらに関しては、

ファイルを上記の「.ssh」フォルダに配置して下さい。

そして、

ファイルの権限を「600」に変更

を対応するので、

以下のコマンドで変更します。

コマンド

chmod 600 ~/.ssh/sample_key.pem

こちらのコマンドで、

権限を変更が完了です。

最後に、

sshコマンドでSSH Keyファイル指定で実行

で実際にXserver VPSへの接続を試します。

sshコマンドにオプション指定で、

実行することで接続できるので、

コマンド

ssh -i ~/.ssh/sample_key.pem root@VPSのIPアドレス

で接続できます。

うまく接続できたら、

SSHで接続できるアカウントの変更や権限など、

セキュリティを調整していきましょう。

国内VPSでコスパを重視するなら「XServer VPS」がおすすめ

アプリケーションのサーバーを

クラウドで用意する際に、

AWSやGCPを使うことが多いです。

この点で、

従量課金の仕組みが心配などある方がいれば、

国内VPSを試してみるのも良いでしょう。

VPSに関しては、

国内VPS
利用料金がリーズナブル
管理画面の使い勝手が良い
安定性も高い

という点で、

「XServer VPS」

Xserver VPS

を使う機会があり、

おすすめできそうだと思ったので、

この記事で概要を共有します。

XServer VPSのサイトをチェック

まずは、

XServer VPSの公式サイトをチェック

Xserver VPS

XServer VPSとは

XServer VPSは、

海外運用が多いVPSの中で、

数少ない国産のVPSです。

個人的には、

VPNの中で、

国内VPS
利用料金がリーズナブル
管理画面の使い勝手が良い
安定性も高い

という点を考慮して、

おすすめできると判断しています。

コストパフォーマンスが高く、

安定性もしっかりしているので、

まずは、公式サイトでチェックしてみましょう。

Xserver VPS

Laravelのバージョンアップデートを試した時のメモ

Laravelを使用していて、

フレームワーク自体のバージョンの

アップデートを行おうとして、

その時に調整したことなど、

個人用にメモを残しておきます。

Laravelのバージョン

現在のバージョン確認

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 9.5.1

というバージョンであることがわかります。

バージョンのアップデート

同一バージョンのアップデート

バージョンとして、

９.x系の最新にしたいので、

今のバージョンである

Laravel Framework 9.5.1

から、

バージョンを9.x系での更新を行います。

コマンド

composer update

このコマンドを実行すると、

アップデートが行われます。

終了したら、

バージョンがアップデートされていることを確認します。

php artisan --version

$ php artisan --version
Laravel Framework 9.52.9

うまくバージョンが変わっていますね。

こちらでバージョンのアップデートが完了です。

Laravel 9系から10系へのアップデート

先ほどのバージョンのアップデートは、

composer.json

で指定されているバージョンの中で、

アップデートを行いました。

しかし、

大きなメジャーバージョンの変更についても、

行うことがあるので、

Laravel 9系から10系へのバージョンアップデートについて、

以下の対応でアップデートが可能です。

設定ファイルとして、

composer.json

を変更します。

アップデートする際の設定情報については、

以下の公式サイトに記載があるので、

そちらを参考にしてください。

https://laravel.com/docs/10.x/upgrade#updating-dependencies

こちらの中で、

環境状況として必要な要件を満たす
composer.jsonの指定バージョンを変更する

ということを行うことで、

バージョンアップデートが可能になります。

この辺りのバージョンの依存関係と呼ばれる環境や設定情報は、

「Updating Dependencies」

という部分に記載があり、

このような形で、

必要な環境や変更する設定などがありますので、

そちらを対応してください。

対応が完了したら、

composer update

のコマンドを実行することで、

バージョンアップデートが行われます。

実際にアップデートが完了したら、

php artisan --version

のコマンドで、

バージョン情報を確認してみると、

$ php artisan --version
Laravel Framework 10.13.5

うまくバージョンが、

9系から10系へアップデートされています。

こちらのように、

フレームワークのバージョンアップデートを行ってください。

VPNを使うならノーログポリシーの国産VPN「MillenVPN」がおすすめ

フリーWifiを使うときや、

海外のサービスを活用するときなど、

有料のVPNを活用することで、

よりセキュアに使うことができます。

そんなVPNの中で、

国産VPN
利用料金がリーズナブル
ノーログポリシー
海外から日本への接続も対応

という点で、

「Millen VPN」

を使う機会があり、

おすすめできそうだと思ったので、

この記事で概要を共有します。

Millen VPNのサイトをチェック

まずは、

Millen VPNの公式サイトをチェック

MillenVPNのサイト

Millen VPNとは

Millen VPNは、

海外運用が多いVPNの中で、

数少ない国産のVPNです。

個人的には、

VPNの中で、

国産VPN
利用料金がリーズナブル
ノーログポリシー
海外から日本への接続も対応

という点を考慮して、

おすすめできると判断しています。

まず、

フリーWifiなどの安全な利用に関しては、

Millen VPNの方でもYoutubeに説明動画あるので、

以下を参考にしてください。

特徴（料金体系など）

特徴としては、

国産VPN
利用料金がリーズナブル
ノーログポリシー
海外から日本への接続も対応

この４つが魅力的なポイントですね。

国産VPNであるという点に関しては、

不明点がある時に日本語で質問できる

という点が、

非常に助かるポイントです。

利用料金体系に関しても、

非常にリーズナブルな体系になっており、

１年間の利用であれば、

５００円くらい、

２年間の使用であれば、

このように、

長期使用になるほど、

より割引されているので、

継続的に利用されるなら長期利用がおすすめ

と言えます。

また、

VPNを使用する上で、

セキュリティ担保として使用したいのが、

ノーログポリシー

というセキュリティポリシーです。

公式サイトにも、

このようにしっかりと明記しているので、

安心して使用することができます。

さらに、

個人的に機能要件として、

サポートされている点として嬉しいのは、

海外から日本への接続も対応

という点です。

海外にあまり行かれない方は使う機会がないかもしれませんが、

海外から日本のサービスを活用する際に、

IPの問題でうまく使うことができないことがあります。

この点に関して、

Millen VPNでは、

このように、

他の海外運営のVPNとは違い、

国産VPNとして、

海外から日本に接続できる国の対応が、

他のVPNと比べてもしっかりしているので、

この点でも非常におすすめです。

短い期間でも、

試すことができるので、

まずは、公式サイトでチェックしてみましょう。

MillenVPNのサイト

composerのバージョンを変更する方法

composerを使用していて、

各種ああ

バージョン情報

現時点のcomposerのバージョン確認

composer -V

確認結果

$ composer -V
  / ____/___  ____ ___  ____  ____  ________  _____
 / /   / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/
/ /___/ /_/ / / / / / / /_/ / /_/ (__  )  __/ /
\____/\____/_/ /_/ /_/ .___/\____/____/\___/_/
                    /_/
Composer version 2.1.14

バージョンの変更

composerのバージョンを指定バージョンに変更します。

変更するコマンドは以下。

変更コマンド

コマンド

composer self-update 2.5.8

実行結果

$ composer self-update 2.5.8
Upgrading to version 2.5.8 (stable channel).

Use composer self-update --rollback to return to version 2.1.14

実行結果確認

実際に変更されたのか、

バージョンを確認してみる。

確認コマンド

composer -v

確認結果

$ composer -v
   ______
  / ____/___  ____ ___  ____  ____  ________  _____
 / /   / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/
/ /___/ /_/ / / / / / / /_/ / /_/ (__  )  __/ /
\____/\____/_/ /_/ /_/ .___/\____/____/\___/_/
                    /_/
Composer version 2.5.8

これでうまくバージョンの変更が完了しました。

Next.jsで別ドメインの画像ファイルを表示させる方法

Nextjsで実装していたときに、

画像の表示において、

別ドメインの画像URLを表示させる

ということを、

構築しているシステムで試そうとした。

画像管理はバックエンドのシステムの方で行うので、

それを表示させたいという点で、

ドメインをサブドメインで切り分けていたので、

その点でうまく表示されない事象が起きた。

今回は、

上記で行いたかったことに関して、

試したことや起きた事象など、

備忘録としてこの記事に残します。

公式サイトの情報

公式サイトで、

Next.jsに関する情報は確認。

公式サイト

画像表示の基本

画像表示については、

<Image>

のタグを使って、

import Image from 'next/image';
 
export default function Page() {
  return (
    <Image
      src="/profile.png"
      width={500}
      height={500}
      alt="Picture of the author"
    />
  );
}

という形で、

画像表示を行いました。

こちらの画像表示については、

以下の公式サイトも確認。

公式サイト（Imageタグ）

別ドメインの画像表示を試すとエラー

上記の画像表示を使用して、

別ドメインで試したところ、

Unhandled Runtime Error
Error: Invalid src prop (https://sample.com/xxxxx.png) on `next/image`, 
hostname "sample.com" is not configured under images in your `next.config.js`
See more info: https://nextjs.org/docs/messages/next-image-unconfigured-host

上記のエラーが発生した。

エラー内容の中に、

以下を確認するように記載があるので、

こちらも確認してもらうと良いですね。

https://nextjs.org/docs/messages/next-image-unconfigured-host

別ドメインの画像表示のための設定

上記の別ドメインの画像表示のエラーの対応方法として、

next.jsの設定ファイルに対して、

ドメインを設定する必要があります。

調整ファイル

next.config.js

調整内容

const nextConfig = {
  images: {
    domains: ['sample.com'],
  },
}

このように、

設定ファイルの中に、

画像用のドメインを設定する必要があります。

こちらを調整した後に、

再コンパイルすると、

うまく別ドメインの画像が表示されました。

Next.jsで環境設定値を表示側でも使う方法

Nextjsで実装していたときに、

環境設定値を試したときに、

表示側に環境設定値を使おうとして、

その時に試したことや、

公式サイトで確認したことなどをメモ。

事前に環境設定値を使う方法は、

Next.js でprocess.envで環境値を設定して使う方法

こちらの記事でも試していたので、

そちらも参考にしてもらえると良いですね。

今回は、上記に加えて、

やりたかったことやうまくいかなかったことを、

備忘録としてこの記事に残します。

公式サイトの情報

公式サイトの中で、

環境設定値に関して、

記載されている部分は、

以下のリンク先にあります。

公式サイト（Environment）

環境設定値を表示側でも使いたい

やりたかったこととしては、

表示側で、

export default function SampleView() {
  return (
    <>
      サンプル表示値
    </>
  )
}

という表示部分で、

サンプル表示値

などの値を、

環境設定値として持たせて、

表示させようとしました。

環境設定値でうまくいかないパターン

環境設定値として、

.env

の環境ファイルに、

SAMPLE_VALUE=サンプル表示値

という設定を行って、

export default function SampleView() {
  return (
    <>
     　{process.env.SAMPLE_VALUE}
    </>
  )
}

で表示させようとしたが、

うまく表示されなかった。

環境設定値を表示側でうまくいく方法

上記で使おうとしていた、

.env

の環境ファイルに、

SAMPLE_VALUE=サンプル表示値

この値を使うには、

公式サイト（Environment）

の中の以下の部分が重要でした。

上記の記載の中で、

In order to expose a variable to the browser 
you have to prefix the variable with NEXT_PUBLIC_. 
For example:
NEXT_PUBLIC_ANALYTICS_ID=abcdefghijk

ということが書かれており、

NEXT_PUBLIC_

というものを、

プレフィックスとして使う必要があります。

例として、

NEXT_PUBLIC_ANALYTICS_ID=abcdefghijk

ということがあるので、

こちらを参考に試してみます。

環境ファイル

.env

設定値

NEXT_PUBLIC_SAMPLE_VALUE=サンプル表示値

表示側での環境設定値の使用

export default function SampleView() {
  return (
    <>
     　{process.env.NEXT_PUBLIC_SAMPLE_VALUE}
    </>
  )
}

上記で試すと、

うまく環境設定値を取得して、

画面にも表示できました。

NginxでHttpをHttpsにリダイレクトさせる設定方法

Nginxで各種ドメインを設定して、

Webサーバーを管理していく中で、

SSL証明書を設定しようとしたときに、

無料のLet’s Encryptから証明書を取得してから、

HTTPをHTTPSにリダイレクトさせる

ということを行おうとして、

Nginxの設定ファイルを調整した時のメモを

備忘録として、個人用に残しておきます。

前提：Ubuntuを使用

前提としては、

環境としてUbuntuを使用しています。

ファイルパスなどを、

必要な環境パスに変えてもらえれば、

Nginxの中の設定は同じ形でいけると思います。

Nginxの設定ファイル

Nginxの設定ファイルは、

設定ファイルの場所

/etc/nginx/conf.d

設定ファイル

個別ファイル.conf

NginxのHTTPとHTTPSのリダイレクトの設定

上記のファイルの中で、

リダイレクトの設定を追加します。

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
     :
}

上記の設定を行って、

Nginxの再起動を行います。

再起動コマンド

nginx -s reload

上記のコマンドで再起動を行ってから、

実際に表示確認をすると、

HTTPからHTTPSにリダイレクトがうまくいきました。

NuxtでSiteMapを生成する方法

Vueを活用する中で、

「Nuxt」

のフレームワークを使用して、

既存で作っていたものを、

試しにリプレイスしようとしている。

そんな中で、

SiteMap

を生成しようとした時に、

調べたことなどを、

個人用にメモ。

ちなみに、

Nuxtのバージョンについても、

バージョン２系ではなく、

バージョン３系を導入して、

Nuxtを試している。

個人用の備忘録としてメモを残しておく。

Nuxt.jsの公式サイト

Nuxt.jsに関しては、

こちらのサイトを参考にしました。

リンクをメモ。

Nuxtの公式サイト（simple-sitemap）

NuxtのModulesを確認

NuxtのModulesを確認すると、

simple-sitemap

というモジュールがあるようなので、

こちらを使ってみます。

simple-sitemapのNPMパッケージ

simple-sitemapを試す

上記の公式サイトにも記載のある、

simple-sitemap

を試します。

コマンド

npm i nuxt-simple-sitemap

こちらで、

モジュールのインストールを実施。

次に設定を行います。

URL指定でファイル取得するwgetで保存フォルダ先を指定する方法

Ubuntuの中で、

ファイル取得の方法として、

wget

を使用して、

ファイル取得を行おうとした際に、

保存先のフォルダを指定して、

動作させたいと考え、

その際に、

wgetのオプションの一部を確認して、

実際に試した時のことを、

この記事にメモとして残しておきます。

wgetのコマンド

今回、実行するコマンドが、

wget

というコマンドで、

オプション指定なしでも使うことができます。

例えば、

wget https://example.com/img/sample.png

という形で、

オプションなしで実行することができます。

取得先のフォルダを指定する

取得先のフォルダを指定して、

wgetでのファイル取得のアクションを実行します。

オプション情報の確認は、

以下のコマンドで確認できます。

コマンド

wget --help

確認結果（一部抜粋）

$ wget --help
 :
 :
Directories:
  -nd, --no-directories            don't create directories
  -x,  --force-directories         force creation of directories
  -nH, --no-host-directories       don't create host directories
       --protocol-directories      use protocol name in directories
  -P,  --directory-prefix=PREFIX   save files to PREFIX/..
  :
  :

という形で、

オプション情報が表示されるので、

必要なオプションを確認して実行します。

今回、実行したい方法として、

保存先のフォルダを指定する

を実施したかったので、

-P,  --directory-prefix=PREFIX   save files to PREFIX/..

のオプションを指定して、

wgetコマンドを実行します。

具体的には、

wget -P /target_folder https://example.com/get_file.png

という形で、

オプションをつけたコマンドを実行します。

こちらを実行すると、

$ wget -P /target_folder https://example.com/get_file.png
HTTP request sent, awaiting response... 200
Length: 55469 (54K) [image/png]
Saving to: ‘/target_folder/get_file.png’

get_file.png     100%[===================>]  54.17K  --.-KB/s    in 0.1s

2023-05-06 20:29:57 (401 KB/s)
‘/target_folder/get_file.png’ saved [55469/55469]

このように、

うまく実行され、

wgetコマンドで指定フォルダに対して、

ファイルが取得されていますね。

NuxtのuseStateでの値保持で値が初期化されてしまう事象に関するメモ

Vueを活用する中で、

「Nuxt」

のフレームワークを使用して、

既存で作っていたものを、

試しにリプレイスしようとしている。

そんな中で、

useState

を使って、

状態管理を実現しようとしているが、

ページ遷移部分で、

１度、設定した値が、

再度、初期化されてしまう事象があり、

うまくいく場合と、

うまくいかない場合を確認したところ、

対応方法によって挙動が違ったのでメモ。

ちなみに、

Nuxtのバージョンについても、

バージョン２系ではなく、

バージョン３系を導入して、

Nuxtを試している。

個人用の備忘録としてメモを残しておく。

Nuxt.jsの公式サイト

Nuxt.jsに関しては、

こちらのサイトを参考にしました。

リンクをメモ。

Nuxtの公式サイト（導入）

Nuxtの公式サイト（useState）

useStateを試した時のメモ

上記の公式サイトのuseStateのコードを参考に、

useStateを活用するコードを書いていきます。

useStateの設定と取得

<script setup>
const counter = useState('counter', () => 0);
const sameCounter = useState('counter');
</script>

画面への表示

<div>
  <div>Counter: {{ counter }}</div>
  <div>Same Counter: {{ sameCounter }}</div>
  <button class="font-mono" @click="counter++">
    +
  </button>
  <button class="font-mono" @click="counter--">
    -
  </button>
</div>

上記を試すと、

このように、

ボタン押下で、

うまく値が変わっていることがわかります。

うまくいかない事象が発生

上記をベースに、

app.vue

だけではなく、

/pages

などのページや、

/components

などのコンポーネントの中で、

同じことを試していましたが、

基本的には、

問題なく動いていました。

うまくいかない事象が発生したのは、

ページ遷移を行った際に、

値がうまく保持できず、

このように値が初期化されてしまっていました。

ページ遷移の方法をNuxtのLinkにすることで解決

上記で、

ページ遷移時に値が初期化されてしまう事象ですが、

うまく値が保持されている部分と、

値が初期化されてしまう事象が発生している部分を、

それぞれ、

細かく確認していったところ、

wondow.locationでは値が初期化される

というところが問題でした。

ページ描画の部分で、

この点を解決するために、

イベント発火を拾って、

window.location = '遷移先画面URL';

としていたところを、

イベント発火させている項目自体を、

<NuxtLink :to="child.page">{{ child.text }}</NuxtLink>

というように、

NuxtLink

を使って、

画面遷移することで、

値の保持がうまく挙動しました。

https://nuxt.com/docs/api/components/nuxt-link

NuxtでuseHeadで.envの環境変数を扱う方法

Vueを活用する中で、

「Nuxt」

のフレームワークを使用して、

既存で作っていたものを、

試しにリプレイスしようとしている。

そんな中で、

useHead

を使って、

<meta name="description" content="メタ情報">

このような、

メタ情報を表示をするために、

設定を試した。

その時のメモは、

以下を参照してほしい。

NuxtでuseHeadを使ってメタ情報を設定する方法

こちらを対応した上で、

一部の値を環境変数として、

.env

のファイルに、

値を持たせたかったので、

その方法を試した。

ちなみに、

Nuxtのバージョンについても、

バージョン２系ではなく、

バージョン３系を導入して、

Nuxtを試している。

個人用の備忘録としてメモを残しておく。

Nuxt.jsの公式サイト

Nuxt.jsに関しては、

こちらのサイトを参考にしました。

リンクをメモ。

NuxtでuseHeadを使ってメタ情報を設定する方法

useHeadを試した時のメモ

Nuxtの設定の中で、

useHeadについては、

SEO and Meta

のページに記載されています。

こちらに関しては、

公式サイトの情報と、

試した時のメモの記事を載せておきます。

Nuxtの公式サイト情報「SEO and Meta」ページ

.envの環境変数の値を使う

上記の対応に加えて、

実際の設定したい値の一部を、

.env

の環境変数に値を持たせることを試します。

公式情報としては、

こちらを参考にしてください。

https://nuxt.com/docs/guide/going-further/runtime-config

上記をもとに、

試していきます。

環境変数のファイルとして、

.env

のファイルに、

SAMPLE="sample value"

このように、

環境変数として値を設定します。

こちらを、

nuxt.config.ts

に設定を追加します。

上記の公式サイトで、

export default defineNuxtConfig({
  runtimeConfig: {
    // The private keys which are only available within server-side
    apiSecret: '123',
    // Keys within public, will be also exposed to the client-side
    public: {
      apiBase: '/api'
    }
  }
})

こちらについて、

When adding apiBase to the runtimeConfig.public, 
Nuxt adds it to each page payload. 
We can universally access apiBase in both server and browser.

と丁寧に書かれており、

値のアクセスに関しても、

const runtimeConfig = useRuntimeConfig()

console.log(runtimeConfig.apiSecret)
console.log(runtimeConfig.public.apiBase)

という形でアクセスができると記載があります。

こちらを組み合わせて試すと、

export default defineNuxtConfig({
  runtimeConfig: {
    // The private keys which are only available within server-side
    apiSecret: '123',
    // Keys within public, will be also exposed to the client-side
    public: {
      sample: process.env.SAMPLE
    }
  }
})

こちらの設定をすることで、

各ページの中で、

<script setup>
const runtimeConfig = useRuntimeConfig();
console.log(runtimeConfig.sample);
</script>

で実際にアクセスでき、

値を確認すると、

sample value

という値が取得できていれば、

うまく動いているので、

こちらの仕組みを使って、

環境変数を扱っていくと良いですね。

NuxtでuseHeadを使ってメタ情報を設定する方法

Vueを活用する中で、

「Nuxt」

のフレームワークを使用して、

既存で作っていたものを、

試しにリプレイスしようとしている。

そんな中で、

useHead

を使って、

<meta name="description" content="メタ情報">

このような、

メタ情報を表示をするために、

設定を試した時のメモ。

ちなみに、

Nuxtのバージョンについても、

バージョン２系ではなく、

バージョン３系を導入して、

Nuxtを試している。

個人用の備忘録としてメモを残しておく。

Nuxt.jsの公式サイト

Nuxt.jsに関しては、

こちらのサイトを参考にしました。

リンクをメモ。

Nuxtの公式サイト情報「SEO and Meta」ページ

useHeadの公式情報

Nuxtの設定の中で、

useHeadについては、

SEO and Meta

のページに記載されています。

上記の公式サイトの中から、

メニューで検索してもらっても大丈夫ですが、

以下にリンクをメモ。

useHeadを試す

上記ページに記載があるので、

そちらを最新情報については、

確認して頂くと良いです。

実際に自分が試した時のメモ。

公式サイトによると、

<script setup lang="ts">
useHead({
  title: 'My App',
  meta: [
    { name: 'description', content: 'My amazing site.' }
  ],
  bodyAttrs: {
    class: 'test'
  },
  script: [ { innerHTML: 'console.log(\'Hello world\')' } ]
})
</script>

という書き方で、

TypeScriptで実装できます。

自分の環境だと、

JavaScriptで試しているので、

上記に加えて、

リンクタグについても、

動かすパターンがこちら。

<script setup>
useHead({
  title: 'タイトル',
  meta: [
    { name: 'description', content: '説明' },
  ],
  script: [ { src: 'https://example.com/script.js' } ],
  link: [{
    rel: 'stylesheet',
    href: 'https://example.com/style.css'
  }],
})
</script>

こちらを動かすと、

このように、

タイトルがうまく変更されました。

メタ情報なども、

検証ツールで確認してみると、

このように、

うまくメタ情報が設定されていますね。

Nuxtでvue-prism-editorを導入して設定する方法

Vueを活用する中で、

「Nuxt」

のフレームワークを使用して、

既存で作っていたものを、

試しにリプレイスしようとしている。

そんな中で、

prismjs

の導入を行い、

このような表示をするために、

設定を試した時のメモ。

ちなみに、

Nuxtのバージョンについても、

バージョン２系ではなく、

バージョン３系を導入して、

Nuxtを試している。

個人用の備忘録としてメモを残しておく。

Nuxt.jsの公式サイト

Nuxt.jsに関しては、

こちらのサイトを参考にしました。

リンクをメモ。

https://github.com/koca/vue-prism-editor

GitHub：vue-prism-editor

今回導入したライブラリの

「vue-prism-editor」

のGitHubのページ。

こちらを参照。

Prismjsの公式サイト

コアとなる

「Prismjs」

の公式サイトはこちら。

テーマパターンなど、

公式サイトを見てもらうと良い。

https://prismjs.com/

Nuxt.jsにPrismjsを導入

まずは、

ライブラリをNPMパッケージで導入。

コマンド

npm install vue-prism-editor

こちらで導入が終わったら、

ファイルにコードを追加していきます。

template

templateの部分のコードは、

<template>
  <client-only placeholder="Loading...">
    <prism-editor 
　　　　class="my-editor" 
　　　　language="js" 
　　　　v-model="code" 
　　　　:highlight="highlighter" 
　　　　line-numbers>
　　　</prism-editor>
  </client-only>
</template>

このように記載します。

ちなみに、

<client-only placeholder="Loading...">
 <prism-editor ....
</client>

のようにしているのは、

以下で起きた事象の対策です。

Nuxtでbuild+previewするとエラー発生した件

次にscriptを記載します。

script

scriptのコードに関しては、

以下のように記載します。

<script>
import { PrismEditor } from "vue-prism-editor";
import "vue-prism-editor/dist/prismeditor.min.css";
import prismjs from "prismjs/components/prism-core";
const { highlight, languages } = prismjs;
import "prismjs/components/prism-clike";
import "prismjs/components/prism-javascript";
import "prismjs/themes/prism-tomorrow.css";

export default {
  components: {
    PrismEditor
  },
  data: () => ({ 
    code: "console.log('hello world')"
  }),
  methods: {
    highlighter(code) {
      return highlight(code, languages.js);
    }
  }
};
</script>

こちらで、

コードがうまく表示れさると思います。

対象言語やテーマを変える

Prismjsを使う中で、

vue-prism-editorを使っていますが、

こちらの上記のサンプルコードで、

対象言語（HTML/CSS/JavaScriptなど）
テーマ（ハイライトの色など）

を変更するには、

以下のように対応します。

言語設定

言語設定については、

import "prismjs/components/prism-javascript";

のインポートを

import "prismjs/themes/prism-okaidia.css";

に変更した上で、

Scriptのメソッド指定で、

  methods: {
    highlighter(code) {
      return highlight(code, languages.js);
    }
  }

となっているところを、

  methods: {
    highlighter(code) {
      return highlight(code, languages.css, 'css'); //returns html
    }
  }

と変更することで、

言語の指定ができます。

テーマ設定

テーマの設定については、

import "prismjs/themes/prism-tomorrow.css";

で読み込んでいるテーマを、

import "prismjs/themes/prism-okaidia.css";

のように変更することで、

テーマを変更することができます。

Next.jsのnext-auth使用してビルド後に実行したらエラーになった件

Nextjsで実装していたときに、

認証周りを構築しようとした時に、

何かライブラリなどを用いて、

GoogleのOAuthでの認証を試そうと考えました。

現時点で調べていると、

「Auth.js(NextAuth.js)」

というライブラリが良さそうなので、

こちらを試してみることにしました。

今回は、

ライブラリ「Auth.js(NextAuth.js)」を用いて、

Google OAuthの認証を試していたので、

その時にビルドまでうまくいったのだが、

実行するとエラーになった時のメモを

備忘録としてこの記事に残します。

公式サイトの情報

公式サイト

まずは、公式サイトでNextAuth.jsのことを確認

自分が確認した時点（2023/04/25）で、

NextAuth.js is becoming Auth.js! 🎉 
Read the announcement. Note, 
this site is under active development.

とアナウンスされているので、

それぞれのリンクをメモしておきます。

nuxt-authでGoogle認証を試した

今回のビルドエラーになったのは、

Next.jsでGoogle認証を試していたのだが、

開発モードではうまく挙動していた。

TypeScriptを使っているので、

ビルド時にエラーになったが、

ベースとなるやっていることは、

以下の記事を参考。

ビルドのエラーは調整済み

ビルドについてもエラーになったが、

以下の対応をやって、

問題なくビルドは完了している。

実行エラー「Please define a `secret` in production.」

実行したら、

エラーが発生した。

エラー内容

https://next-auth.js.org/errors#no_secret 
Please define a `secret` in production. 
MissingSecret [MissingSecretError]: 
Please define a `secret` in production.
 :
code: 'NO_SECRET'

Next.jsのnext-auth使用してビルドしたらエラーになった件

Nextjsで実装していたときに、

認証周りを構築しようとした時に、

何かライブラリなどを用いて、

GoogleのOAuthでの認証を試そうと考えました。

現時点で調べていると、

「Auth.js(NextAuth.js)」

というライブラリが良さそうなので、

こちらを試してみることにしました。

今回は、

ライブラリ「Auth.js(NextAuth.js)」を用いて、

Google OAuthの認証を試していたので、

その時にビルドするとエラーになった時のメモを

備忘録としてこの記事に残します。

公式サイトの情報

公式サイト

まずは、公式サイトでNextAuth.jsのことを確認

自分が確認した時点（2023/04/25）で、

NextAuth.js is becoming Auth.js! 🎉 
Read the announcement. Note, 
this site is under active development.

とアナウンスされているので、

それぞれのリンクをメモしておきます。

nuxt-authでGoogle認証を試した

今回のビルドエラーになったのは、

Next.jsでGoogle認証を試していたのだが、

開発モードではうまく挙動していた。

TypeScriptを使っているので、

ビルド時にエラーになったが、

ベースとなるやっていることは、

以下の記事を参考。

ビルドエラー「Type error: Binding element ‘Component’ implicitly has an ‘any’ type.」

ビルドしようとしたら、

エラーが発生した。

エラー内容

Type error: Binding element 'Component' implicitly has an 'any' type.

元々のコード

import '@/styles/globals.css'
import { SessionProvider } from "next-auth/react"

export default function App({
  Component,
  pageProps: { session, ...pageProps },
}) {
  return (
    <SessionProvider session={session}>
      <Component {...pageProps} />
    </SessionProvider>
  )
}

調整コード

import '@/styles/globals.css'
import { SessionProvider } from "next-auth/react"
import type { AppProps } from "next/app"

export default function App({ Component, pageProps }: AppProps) {
  return (
    <SessionProvider session={pageProps.session}>
      <Component {...pageProps} />
    </SessionProvider>
  )
}

上記の調整で、

この部分の問題は解決。

ビルドエラー「Type ‘string’ is not assignable to type ‘Location | (string & Location)’.」

エラー内容

Type 'string' is not assignable to type 'Location | (string & Location)'.

元々のコード

window.location = "/sample";

調整コード

const win: Window = window;
win.location = "/sample";

上記の調整で、

この部分の問題は解決。

ビルドエラー「Parsing error: Missing initializer in const declaration.」

エラー内容

Error: Parsing error: Missing initializer in const declaration.

元々のコード

window.location = "/sample";

調整コード

window.location.href = "/sample";

上記の調整で、

この部分の問題は解決。

Nuxtでbuild+previewするとエラー発生した件

Vueを活用する中で、

「Nuxt」

のフレームワークを使用して、

既存で作っていたものを、

試しにリプレイスしようとしている。

そんな中で、

devアクションだと問題なく動く
buildアクションは問題なく終わる
previewアクションで表示確認するとエラー

ということが起きたので、

それを対応した時のメモ。

ちなみに、

Nuxtのバージョンについても、

バージョン２系ではなく、

バージョン３系を導入して、

Nuxtを試している。

個人用の備忘録としてメモを残しておく。

Nuxt.jsの公式サイト

Nuxt.jsに関しては、

こちらのサイトを参考にしました。

リンクをメモ。

https://vuetifyjs.com/en/

Vuetifyの公式サイト

デザイン部分に関しては、

Vuetifyを導入しているので、

こちらの公式サイトを参考。

Nuxt.jsでbuild+preview

今回の事象が起きたのは、

開発モード

npm run dev

で動かしている分には、

エラーにならなかった。

そして、

npm run build

については、

問題なく、ビルドは終わった。

しかし、

npm run preview

で起動して、

表示確認しようとするとエラーになった。

エラー発生「CommonJS module, which may not support all module.exports as named exports.」

表示確認時にエラーが発生

画面上は、

上記のような感じ。

エラー分はこちら。

Named export 'highlight' not found. 
The requested module 'prismjs/components/prism-core.js' 
is a CommonJS module, which may not support all module.
exports as named exports. 
CommonJS modules can always be imported via the default export, 
for example using: 
import pkg from 'prismjs/components/prism-core.js'; 
const { highlight: highlight$1, languages: languages$1 } = pkg;

こちらについては、

上記のメッセージで、

import pkg from 'prismjs/components/prism-core.js'; 
const { highlight: highlight$1, languages: languages$1 } = pkg;

という感じで、

こういう風に調整したら良いというメッセージがある。

実際のコードを確認すると、

import { highlight, languages } from "prismjs/components/prism-core";

となっているので、

上記の書き方に合わせる形で、

import prismjs from "prismjs/components/prism-core";
const { highlight, languages } = prismjs;

という形で調整。

エラー発生「The language “undefined” has no grammar.」

画面上の表示エラーは、

The language "undefined" has no grammar.

となっていたが、

previewを起動しているコンソールで、

表示されるログを確認すると、

ReferenceError: getComputedStyle is not defined

というエラーが出力されていた。

こちらで調べると、

https://github.com/koca/vue-prism-editor/issues/32

こちらのページにある対策が、

今回の事象と一致したので、

そちらをメモ。

調整前のコード

<prism-editor class="my-editor" ...省略></prism-editor>

調整後のコード

<client-only placeholder="Loading...">
  <prism-editor class="my-editor" ...省略></prism-editor>
</client-only>

こちらの調整で、

うまく画面表示ができるようになりました。

Nuxt+Vuetifyでv-iconが表示されない

Vueを活用する中で、

「Nuxt」

のフレームワークを使用して、

各種APIを作成するなど、

小さな規模から試そうと考え、

公式サイトを見ながら、

導入して起動するまでを試した。

その際、

レイアウトに関しては、

Vuetifyを用いて構築したので、

そのVuetifyのアイコンが、

うまく表示できなかったので、

その対応をメモ。

ちなみに、

Nuxtのバージョンについても、

バージョン２系ではなく、

バージョン３系を導入して、

Nuxtを試している。

個人用の備忘録としてメモを残しておく。

Nuxt.jsの公式サイト

Nuxt.jsに関しては、

こちらのサイトを参考にしました。

リンクをメモ。

https://vuetifyjs.com/en/components/icons/

Vuetifyの公式サイト

Vuetifyに関しては、

アイコンの使用方法は、

こちらの公式サイトを参考。

リンクをメモ。

Nuxt.jsでの構築時のメモ

今回の事象が起きた件に関して、

Nuxt.jsに関して対応したことは、

以下の記事にまとめた。

Nuxt3のインストールからルーティングの導入までのメモ

Nuxt3へのリプレイス時のエラー「Preprocessor dependency “sass” not found.」の対応メモ

Vuetifyのアイコン表示

Vuetifyのアイコンは、

<v-icon icon="mdi-vuetify"></v-icon>

のコードで、

のように、

アイコンが表示されます。

しかし、

自分の環境ではうまく表示されない。

Nuxt.jsの調整

調整自体は、

必要なライブラリのインストール
設定ファイルへのCSSの追加

の２つを行う必要があり、

ライブラリの方は対応していましたが、

今後のために、

どちらの対応もメモ。

ライブラリ導入

npm install @pictogrammers/memory @jamescoyle/vue-icon

ファイル

nuxt.config.ts

設定（対象箇所のみ記載）

export default defineNuxtConfig({
  css: [
    "@mdi/font/css/materialdesignicons.css",
  ],
})

上記の対応で、

アイコンがうまく表示された。

また、

mdiのアイコン一覧は、

以下を参照。

https://pictogrammers.github.io/@mdi/font/4.9.95/

Next.js でGoogle OAuthをAuth.js(NextAuth.js)で試した件

Nextjsで実装していたときに、

認証周りを構築しようとした時に、

何かライブラリなどを用いて、

GoogleのOAuthでの認証を試そうと考えました。

現時点で調べていると、

「Auth.js(NextAuth.js)」

というライブラリが良さそうなので、

こちらを試してみることにしました。

今回は、

ライブラリ「Auth.js(NextAuth.js)」を用いて、

Google OAuthの認証を試した時のメモを

備忘録としてこの記事に残します。

公式サイトの情報

公式サイト

まずは、公式サイトでNextAuth.jsのことを確認

自分が確認した時点（2023/04/25）で、

NextAuth.js is becoming Auth.js! 🎉 
Read the announcement. Note, 
this site is under active development.

とアナウンスされているので、

それぞれのリンクをメモしておきます。

Google Cloud PlatformでOAuthの設定

Google Cloud Platformで、

「Credentials」の「OAuth 2.0 Client IDs」を作成

を行います。

最終的に、

設定終わると、

このように、

OAuth 2.0 Client IDsに作成できれば、

うまくいっています。

実際に設定を進めますが、

作成は画面上部の「＋CREATE CREDENTIALS」というボタン

で作成ができます。

実際の設定は、

こちらのように、

Authorized JavaScript origins

http://localhost:3000

Authorized redirect URIs

http://localhost:3000/api/auth/callback/google

で設定します。

Google Cloud PlatformのOAuth情報の確認

先ほどの、

Google Cloud Platformの設定を行ったら、

Client ID
Client Secret

が作成されるので、

こちらは、Next.jsの方に設定する情報として、

確認、把握しておきます。

表示される場所としては、

先ほどの設定画面の右側の

この部分に表示されており、

それぞれ、

Client IDとClient Secretが、

上記部分に表示されるので、

この値を使うので把握しておきます。

Auth.jsの導入

Next.jsに今回使うAuth.jsを導入していきます。

コマンド

npm install next-auth

Next.jsでGoogle認証のコードを追加

認証させるためのコードを追加していきます。

コードは、公式サイトにも載っているので、

そちらをそのまま使っていきます。

ページファイル

ファイル

/pages/index.tsx

コード

import { signIn } from "next-auth/react"

export default () => <button onClick={() => signIn()}>Sign in</button>

Google認証用ファイル

ファイル

/pages/api/auth/[...nextauth].js

コード

import NextAuth from "next-auth"
import GoogleProvider from "next-auth/providers/google"
export const authOptions = {
  // Configure one or more authentication providers
  providers: [
    GoogleProvider({
      clientId:  "ここにClient ID",
      clientSecret: "ここにClient Secret",
    }),
    // ...add more providers here
  ],
}
export default NextAuth(authOptions)

Google OAuthの動作確認

実際に設定したので、

動作確認をしてみます。

初期表示のボタンをクリックすると

認証用のボタンが表示される

認証用のボタンをクリックすると、

アカウント選択が表示される

これでアカウント指定してあげると、

画面が戻ってうまく認証できていました。

ここまでの設定で、

うまくnext-authを使って、

Google OAuthの認証ができたので、

こちらの認証を使っていこうかなと思います。

個人ようにメモしましたが、

設定方法など、

誰かの参考になれば幸い^ ^

Nuxtへのリプレイス時に参考にした記事等のメモ

Vueを活用する中で、

「Nuxt」

のフレームワークを使用して、

各種APIを作成するなど、

小さな規模から試そうと考え、

公式サイトを見ながら、

導入して起動するまでを試した。

今回は、

Laravelのフロントエンド部分で、

Vue.jsを使っていたのだが、

それを分離するために、

Nuxtのバージョンについても、

バージョン２系ではなく、

バージョン３系を導入して、

Nuxtを使っていこうとしたので、

その際の対応時に参考にした記事など、

個人用の備忘録としてメモを残しておく。

参考サイト（公式サイト）

こちらのサイトを参考にしました。

リンクをメモ。

Nuxt3のインストールからルーティングの導入までのメモ

Nuxt導入時にやったこと

各種コマンドを実行したりするなど、

個人的に試したことなどは、

以下の記事にまとめた。

Nuxt3へのリプレイス時のエラー「Preprocessor dependency “sass” not found.」の対応メモ

各種対応時に参考にした記事など

Nuxtを使うにあたって、

自分が取り組む中で参考にした記事など、

以下に簡易にメモしておきます。

JavaScript/Vue.js/Nuxt

JavaScript
Vue.js
Nuxt

に関して、

とりあえず、リンク残しているだけなので、

必要に応じて、

この記事見返して変更する。

JavaScriptのexportでconstの呼び出し

constで文字列指定した値を呼び出したかったので、

その時に調べた時のリンク先。

ちなみに、

const sample1 = `
複数行
`
export default sample1;

import sample1 from "./sample_code/sample1.js";

みたいに対応したが、

それに関連する一部の記載方法をStackOverflowで確認。

StackOverflowの対象ページ

「Requested module does not provide export named ‘default’」エラーの対応

「Requested module does not provide export named ‘default’」エラーの対応。

上記のconst呼び出しで記載のコードで対応した。

Borislav Hadzhievさんの記事

Nuxt3へのリプレイス時のエラー「Preprocessor dependency “sass” not found.」の対応メモ

Vueを活用する中で、

「Nuxt」

のフレームワークを使用して、

各種APIを作成するなど、

小さな規模から試そうと考え、

公式サイトを見ながら、

導入して起動するまでを試した。

今回は、

Laravelのフロントエンド部分で、

Vue.jsを使っていたのだが、

それを分離するために、

Nuxtのバージョンについても、

バージョン２系ではなく、

バージョン３系を導入して、

Nuxtを使っていこうとしたので、

その際にやったことを、

個人的にメモを残しておく。

参考サイト（公式サイト）

こちらのサイトを参考にしました。

リンクをメモ。

Nuxt3のインストールからルーティングの導入までのメモ

Nuxt3の導入時の対応

公式サイトの通りに、

順番にコマンドを実行した時の、

構築メモについては、

以下のサイトや記事を参考に。

発生エラー内容

Nuxtに対して、

既存コードを持ってきて、

動作を確認しようとした時のエラー。

コマンド

npm run dev

エラー内容

ERROR  Internal server error: 
Preprocessor dependency "sass" not found. 
Did you install it?                       
  Plugin: vite:css

対応内容メモ

対応としては、

必要な「sass」をインストールする。

コマンド

npm install --save-dev sass

実行結果

$ npm install --save-dev sass

104 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

上記でSassをインストールしたら、

再度、

起動を確認。

コマンド

npm run dev

確認結果

$ npm run dev
Nuxi 3.4.2                                                                                                          13:42:40
Nuxt 3.4.2 with Nitro 2.3.3                                                                                         13:42:40
                                                                                                                    13:42:41
  > Local:    http://localhost:3000/ 
  > Network:  http://192.168.1.3:3000/
  > Network:  http://[2400:4152:6182:bb00:55bc:9eea:77f3:aa8c]:3000/
  > Network:  http://[2400:4152:6182:bb00:70b1:af09:8412:646a]:3000/
  > Network:  http://[2400:4152:6182:bb00:9154:eec:ff2d:8b6f]:3000/
  > Network:  http://[2400:4152:6182:bb00:9d4d:b3f:eb6b:e273]:3000/
  > Network:  http://[2400:4152:6182:bb00:a:b8ef:ffba:a32d]:3000/
  > Network:  http://[2400:4152:6182:bb00:fc76:ad1f:8e7:a4ba]:3000/

ℹ Vite client warmed up in 563ms                                                                                    13:42:42
✔ Nitro built in 188 ms

こちらで、

うまく起動できたので、

この調整で対応できました。

Nuxt3のインストールからルーティングの導入までのメモ

Vueを活用する中で、

「Nuxt」

のフレームワークを使用して、

各種APIを作成するなど、

小さな規模から試そうと考え、

公式サイトを見ながら、

導入して起動するまでを試した。

今回は、

Laravelのフロントエンド部分で、

Vue.jsを使っていたのだが、

それを分離するために、

Nuxtのバージョンについても、

バージョン２系ではなく、

バージョン３系を導入して、

Nuxtを使っていこうとしたので、

その際にやったことを、

個人的にメモを残しておく。

参考サイト（公式サイト）

こちらのサイトを参考にしました。

リンクをメモ。

MySQLのタイムゾーンをUTCからJSTに変更する方法

Nuxt3の導入のコマンド

公式サイトの通りに、

順番にコマンドを実行していく。

導入コマンド

npx nuxi init sample-project

実行結果

$ npx nuxi init sample-project
Nuxi 3.4.2                                                            10:34:27
✨ Nuxt project is created with v3 template. Next steps:              10:34:27
 › cd sample-project                                                  10:34:27
[10:34:27]  › Install dependencies with npm install or yarn install or pnpm install
[10:34:27]  › Start development server with npm run dev or yarn dev or pnpm run dev

実行すると、

上記のように、

Nuxi 3.4.2

とバージョン３系が導入されていますね。

コマンドの処理が終わって、

✨ Nuxt project is created with v3 template. Next steps:

とあるので、

cd sample-project

で対象フォルダに入って、

次の初期設定と起動を試します。

プロジェクトの初期設定と起動

先ほどの

cd sample-project

でサンプルプロジェクトに入って、

NPMで必要なライブラリをインストールします。

コマンド

npm install

コマンド実行結果

$ npm install
npm WARN deprecated sourcemap-codec@1.4.8: Please use @jridgewell/sourcemap-codec instead

> postinstall
> nuxt prepare

Nuxi 3.4.2                                                            10:41:08
✔ Types generated in .nuxt                                            10:41:09

added 622 packages, and audited 623 packages in 1m

104 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

こちらで導入完了。

Nuxtを起動して、初期表示を確認

起動コマンド

npm run dev

コマンド結果

$ npm run dev
Nuxi 3.4.2                                                            10:43:34
Nuxt 3.4.2 with Nitro 2.3.3                                           10:43:34
                                                                      10:43:34
  > Local:    http://localhost:3000/
  > Network:  http://192.168.1.3:3000/
  > Network:  http://[2400:4152:6182:bb00:55bc:9eea:77f3:aa8c]:3000/
  > Network:  http://[2400:4152:6182:bb00:70b1:af09:8412:646a]:3000/
  > Network:  http://[2400:4152:6182:bb00:9154:eec:ff2d:8b6f]:3000/
  > Network:  http://[2400:4152:6182:bb00:9d4d:b3f:eb6b:e273]:3000/
  > Network:  http://[2400:4152:6182:bb00:a:b8ef:ffba:a32d]:3000/
  > Network:  http://[2400:4152:6182:bb00:fc76:ad1f:8e7:a4ba]:3000/

ℹ Vite client warmed up in 499ms                                      10:43:35
✔ Nitro built in 236 ms                                         nitro 10:43:35

上記のコマンドで、

うまく起動でき、

表示用のURLについても、

「Local」で表示されているので、

そちらで表示確認していきます。

表示確認URL

http://localhost:3000/

表示確認結果

こちらが表示され、

うまく起動できていますね。

ルーティングの導入

初期表示としては、

プロジェクト内の

こちらの、

app.vue

が初期表示として、

表示されるページになっています。

個人的に、

元のシステムから、

ページを持ってきて調整する際に、

ルーティングとして

/folder1/sample_first
/folder2/sample_second

という形のルーティングにしたいので、

vue-router

を導入します。

公式サイトは、

Vue-Router

NuxtのRoutingの設定

こちらを参照してください。

実際に導入を進めていきます。

Vue-Routerの導入コマンド

コマンド

npm install vue-router@4

コマンド結果

$ npm install vue-router@4

up to date, audited 623 packages in 2s

104 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

こちらで、

導入できたので、

実際にページのルーティングを試します。

Nuxtでルーティングを試す

プロジェクト内に

/pages

のフォルダを作って、

index.vue

を作ります。

トップページのルーティング

ファイル

/pages/index.vue

コード

<template>
  <h1>Index page</h1>
</template>

また、

初期設定のファイルについても調整します。

初期ファイルの調整

ファイル

app.vue

コード

<template>
  <div>
    <!-- Markup shared across all pages, ex: NavBar -->
    <NuxtPage />
  </div>
</template>

画面表示確認

このルーティング設定で、

実際の初期ページの確認を行います。

確認URL

http://localhost:3000/

確認結果

うまく表示できていますね。

これでうまくルーティングを使ったページが作れそうです。

ここまでの部分でも、

初心者の方の参考になれば幸いです。

Githubへの認証で「Permission denied」を対応した方法

Githubを使い始めるときに、

認証方法として、

認証を行おうとして、

その時の対応方法については、

GithubにSSH認証を設定する方法

上記の記事を参照してください。

今回は、

これらの設定を進める上で、

「Permission denied」

が発生したので、

その際の調査と対応をメモしておきます。

Githubへの認証時のエラー

Githubへの鍵情報の設定などは、

上記で共有した記事を参照して頂いて、

その設定をした上で、

git clone git@github.com:hogehoge/hogehoge.git

というコマンドで、

ローカルリポジトリにファイルを取得しようとしていました。

しかし、

実際に実行してみると、

$ git clone git@github.com:hogehoge/hogehoge.git
Cloning into 'hogehoge'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

このように、

git@github.com: Permission denied (publickey).

というエラーが発生しました。

GithubへのSSHアクセスの確認

ターミナルから、

コマンドでアクセス確認するコマンドが用意されています。

確認コマンド（簡易）

ssh -T git@github.com

確認コマンド（詳細ログあり）

ssh -vT git@github.com

上記のコマンドで、

アクセスした時に、

正常系の終了であれば、

Hi hogehoge! 
You've successfully authenticated, 
but GitHub does not provide shell access.

このように表示されます。

認証自体はうまく成功した旨と、

GithubはSSHアクセス自体はできないよということが、

レスポンスのメッセージで返答されていますね。

本来は、この状態であれば、

うまくいっているのですが、

この確認コマンドを試してみても、

git@github.com: Permission denied (publickey).

となるので、

うまく認証が通っていません。

先ほどの、

ssh -vT git@github.com

でログを確認すると、

自分が認証したい鍵情報が使われていない

という状況でした。

鍵情報を指定してあげることで対応

実際に先ほどの確認コマンドで、

オプションで鍵情報も指定することができます。

確認コマンド

ssh -T -i ~/.ssh/hogehoge git@github.com

最初の、

ssh -T git@github.com

という確認コマンドに、

自分が使いたい鍵情報を、

-i ~/.ssh/hogehoge

という形で、

「-i」オプションで指定できるので、

ご自身の環境に合わせて鍵情報を指定してあげてください。

自分の環境だと、

ssh -T -i ~/.ssh/hogehoge git@github.com

で鍵情報を指定してあげると、

Hi hogehoge! 
You've successfully authenticated, 
but GitHub does not provide shell access.

と返答が返ってきたので、

うまく認証が通るようになりました。

これで、

今回の事象が、

鍵情報が指定できていないことが、

原因と考えられますね。

Gitへの認証時の鍵情報を指定する

今回の事象の対応として、

指定の鍵情報を認証時に使うように、

設定を変更していきます。

調整ファイル

~/.ssh/config

調整内容

Host github.com
  Hostname github.com
  IdentityFile ~/.ssh/id_rsa_hogehoge
  TCPKeepAlive yes
  IdentitiesOnly yes

こちらを調整することで、

githubにアクセス時に、

指定の鍵情報を使ってくれるようになります。

変更後に、

再度、アクセスを試してみると、

git clone git@github.com:hogehoge/hogehoge.git

でうまく自分のリポジトリにアクセスできました。

MySQLのタイムゾーンをUTCからJSTに変更する際のエラーの対応方法

MySQLのデータベースに対して、

時間設定が、

タイムゾーンで、

日本時間からずれていたので、

この点を調整しようとしていました。

その際の対応については、

以下の記事で対応したので、

そちらを参考にしてください。

今回はこの対応を行った際に、

エラーが発生して、

うまく調整できなかったので、

その際の対応のメモを残しておきます。

使用したMySQLのバージョン確認

mysqlのコマンドラインで確認

mysql -V

実行結果

$  mysql -V
mysql  Ver 8.0.31-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

MySQLのタイムゾーン設定に関する公式情報

まずは、

公式情報もチェックしておくと良いですね。

参考となるページのリンクはこちら。

MySQL Server でのタイムゾーンのサポート

MySQLの現在のタイムゾーン変更時のエラー

タイムゾーンの変更を行っていきます。

自分の環境はUbuntuですが、

設定ファイル自体を変更することは同じなので、

対象ファイルのパスは、

環境に合わせて調整してみてください。

今回、実行を試したのは、

こちらの調整です。

設定ファイル

/etc/mysql/mysql.conf.d/mysqld.cnf

追加コード

default-time-zone="Asia/Tokyo"

上記のコードで、

デフォルトのタイムゾーンを記載します。

設定に追加コードを入れたら、

MySQLの再起動を行います。

実行すると、

sudo service mysql restart

こちらで再起動すると、

Job for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xe" for details.

こちらのエラーが発生しました。

エラーログを見てみると、

以下のような内容でした。

エラーログ場所

/var/log/mysql/error.log

エラー内容

[ERROR] [MY-010361] [Server] Fatal error: 
Illegal or unknown default time zone 'Asia/Tokyo'

エラーにならない調整方法

MySQLの現在のタイムゾーンの変更を、

先ほどのうまくいかなかった

コマンドを少し変更します。

元々、試していた調整コード

default-time-zone="Asia/Tokyo"

うまくいった調整コード

default-time-zone="+9:00"

こちらを調整することで、

うまくタイムゾーンが変更されました。

今回の対応に関して、

MySQLのタイムゾーンの変更については、

以下の記事も参考にしてください。

MySQLのタイムゾーンをUTCからJSTに変更する方法

MySQLのデータベースに対して、

時間設定が、

タイムゾーンで、

日本時間からずれていたので、

この点を調整したときのメモを残します。

参考として、

Ubuntu/Laravelに関しても、

タイムゾーン変更を行ったので、

そのときの内容は、

以下を参考にしてください。

LaravelでのタイムゾーンをUTCからJSTに更新する方法

UbuntuのタイムゾーンをUTC→JSTに変更

使用したMySQLのバージョン確認

mysqlのコマンドラインで確認

mysql -V

実行結果

$  mysql -V
mysql  Ver 8.0.31-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

MySQLのタイムゾーン設定に関する公式情報

まずは、

公式情報もチェックしておくと良いですね。

参考となるページのリンクはこちら。

MySQL Server でのタイムゾーンのサポート

MySQLの現在のタイムゾーンを確認

MySQLの現在のタイムゾーンを、

コマンドを使って確認していきます。

コマンド

show variables like '%time_zone%';

確認結果

mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | UTC    |
| time_zone        | SYSTEM |
+------------------+--------+

上記のように、

タイムゾーンがUTCになっているので、

９時間ほど、日本時間からずれていました。

MySQLのタイムゾーンの変更

タイムゾーンの変更を行っていきます。

自分の環境はUbuntuですが、

設定ファイル自体を変更することは同じなので、

対象ファイルのパスは、

環境に合わせて調整してみてください。

設定ファイル

/etc/mysql/mysql.conf.d/mysqld.cnf

追加コード

default-time-zone="Asia/Tokyo"

上記のコードで、

デフォルトのタイムゾーンを記載します。

設定に追加コードを入れたら、

MySQLの再起動を行います。

自分の環境はUbuntuなので、

以下のコマンドを実施します。

コマンド

sudo service mysql restart

こちらで再起動すると、

変更した設定情報が反映されます。

MySQLの現在のタイムゾーンを再確認

MySQLの現在のタイムゾーンを、

コマンドを使って確認していきます。

コマンド

show variables like '%time_zone%';

確認結果

mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | JST    |
| time_zone        | SYSTEM |
+------------------+--------+

上記のように、

タイムゾーンが「UTC」から「JST」に、

うまく変更できていますね。

Rails7でassetsのstylesheetに個別のCSSファイルを追加する方法

Railsでアプリケーションを作って、

そのアプリケーションを作っていく中で、

レイアウトのデザイン部分は、

CSSフレームワークを使って、

楽をしたいと考えて、

環境を構築することがあります。

そんな中で、

アプリケーションFWとしてRails
CSSフレームワークとしてBootstrap

という構成で、

プロジェクトの作成から、

実際にBootstrapを導入することを行っていました。

そんな中で、

個別のCSSファイルを追加して、

実際に反映させる部分について、

メモを残しておきます。

Rubyのバージョン

まずは、

試した時のRubyのバージョンですが、

コマンドで確認します。

ruby -v

のコマンドを実行して確認すると、

$ ruby -v
ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [arm64-darwin21]

このバージョンであることが確認できました。

Railsのバージョン

Railsに関しては、

プロジェクト導入時に最新を取得したので、

その結果としてのRailsのバージョンですが、

コマンドで確認します。

rails -v

のコマンドを実行して確認すると、

$ rails -v
Rails 7.0.4.2

このバージョンで作成されていました。

Rails7でassetsのstylesheetに個別のCSSファイルを追加する方法

先ほどのバージョンにも関わりますが、

Railsのバージョン７で試しています。

個別のSCSSファイルを作成

ファイルは、

app/assets/stylesheets

のフォルダに、

例として、

sample.scss

というファイルを作ります。

中身は、

body {
  background: yellow;
}

など、

必要なCSSの記載を、

ご自身の環境に合わせて設定してください。

application.bootstrap.scssの調整

先程の作成したファイルを、

app/assets/stylesheets

のフォルダ内の

application.bootstrap.scss

というファイルに設定を追加します。

コードとしては、

@import 'bootstrap/scss/bootstrap';
@import 'bootstrap-icons/font/bootstrap-icons';

@import 'sample';

のように、

設定を変更してください。

こちらを調整したら、

以下のアセットの再コンパイルを行なってください。

アセットの再コンパイル

Railsでのアセット自体は、

バージョンにもよりますが、

自分が試していたバージョンでは、

アセットファイルとしてコンパイルして作成される
コンパイルされたファイルを参照する

となっています。

この参照するためのコンパイルされたファイルを、

先程のCSS周りで変更を行ったら、

再コンパイルする必要があります。

再度、

Railsのコマンドを使って、

再コンパイルしてあげます。

コマンドは、

rails assets:precompile

で再コンパイルできます。

表示確認

こちらを実行した上で、

rails s

を実行すると、

問題なくレイアウトが表示されました。

HubSpotとGoogle Contactsの連携方法

CRMとして、

HubSpotを使用して、

メールでは、

Gmailを使用しているので、

そちらの連絡先管理で、

Google Contacts

を利用している状態でした。

この時に、

２つの顧客情報を連携する方法を試したので、

その時の個人的なメモを残しておきます。

HubSpotとは

HubSpotは、

マーケティング、セールス、サービス、CMSのための

オールインワン型のクラウドベースのソフトウェアプラットフォームです。

このプラットフォームは、

企業が、

マーケティング戦略を実行するために必要なツールを提供しており、

HubSpotを使う目的として多いのは、

オンラインマーケティング
セールスプロセスの自動化
顧客管理
顧客分析

などを行うために、

導入されることが多いサービスです。

HubSpotの主な機能には、

CRM
メールマーケティング
ブログ投稿
ソーシャルメディア管理
ランディングページの作成
SEOツール
カスタマーサポートツール

など、

幅広い機能があるので、

様々な場面で使用することができます

小規模から大規模な企業まで、

あらゆる規模のビジネスに適しています。

また、

HubSpot Academyという、

無料のオンライントレーニングプラットフォームも提供しており、

インバウンドマーケティングや、

セールスについて学ぶことができるようなので、

試してみると良いでしょう。

HubSpot

Google Contactsとは

Google Contactsは、

Googleが提供するクラウドベースの連絡先管理サービスです。

このサービスを使うと、

連絡先の管理
連絡先のGoogleアカウントの同期
Googleクラウド上への連絡先のバックアップ

などができるので、

Googleアカウントをメインで使用して、

Gmailをよく使うユーザーには、

非常に使い勝手の良いサービスです。

Google Contactsは、

個人的な使用からビジネスでの使用まで、

あらゆる目的に適しています。

また、

Google Contactsは、

他のGoogleアプリケーションと同様に、

無料で利用できるので、

まずは試してみると良いでしょう。

Google Contacts

HubSpotとGoogle Contactsの連携方法

この記事で紹介した

「HubSpot」と「Google Contacts」

を連携するには、

専用のアプリケーションが、

HubSpot側に用意されているので、

そちらを導入することで対応することができます。

説明自体は、

HubSpotとGoogle Contactsの連携の説明

こちらのページに、

公式サイトとして記載があるので、

そちらを参考にしてもらっても大丈夫かと思います。

実際に試してみた内容で、

必要な部分としては、

以下のアプリ一覧のページを使って、

検索して導入してもらうのが早いかと思います。

HubSpotアプリマーケットプレイス

連携のためのアプリなど、

HubSpotに関するアプリケーションについては、

以下のリンクに、

アプリマーケットプレイスとして、

HubSpotがまとめてくれているので、

そちらで一覧を見ていただくと良いですね。

HubSpotアプリマーケットプレイス

アプリ導入時は、Googleアカウント認証して完了

実際に、

HubSpotとGoogle Contactsを

連携させるためのアプリを入れる際は、

先程のマーケットプレイスから、

アプリケーションの導入を進めて、

HubSpotアカウントにログイン
アプリインストールを実施
Google アカウントの認証を実施

というシンプルな手順だけで、

導入設定が完了するので、

そこまで完了したら、

実際に

HubSpotで顧客情報を追加して、

動きを試してもらえると良いでしょう。

Ubuntuでのサービスの使用状況の確認と不要サービスの停止方法

Ubuntuの中で、

各種サービスとして、

SSH
docker
php-fpm

など、

色々と起動させていると思います。

そんなサービスの状況を確認して、

不要サービスを停止することがあり、

その際に対応したことなどを、

この記事にメモとして残しておきます。

サービスの使用状況の確認

全ての一覧か、個別なのかで、

オプションの有無が違うくらいで、

基本的に

service

というコマンドを使います。

全てのサービス状況を確認する

すべてのサービスを確認するためには、

以下のコマンドで確認可能です。

sudo service --status-all

コマンドを実行すると、

以下のように一覧で確認できます。

$ sudo service --status-all
 [ + ]  apparmor
 [ + ]  apport
 [ + ]  atd
 [ - ]  console-setup.sh
 [ + ]  cron
 [ - ]  cryptdisks
 [ - ]  cryptdisks-early
 [ + ]  dbus
 [ + ]  docker
 [ - ]  grub-common
 [ - ]  hwclock.sh
 [ + ]  irqbalance
 [ - ]  iscsid
 [ - ]  keyboard-setup.sh
 [ + ]  kmod
 [ - ]  lvm2
 [ - ]  lvm2-lvmpolld
 [ + ]  multipath-tools
 [ + ]  mysql
 [ + ]  nginx
 [ - ]  nginx-debug
 [ - ]  open-iscsi
 [ - ]  open-vm-tools
 [ - ]  php7.4-fpm
 [ - ]  php8.0-fpm
 [ + ]  php8.1-fpm
 [ - ]  plymouth
 [ - ]  plymouth-log
 [ + ]  procps
 [ - ]  rsync
 [ + ]  rsyslog
 [ - ]  screen-cleanup
 [ + ]  ssh
 [ + ]  udev
 [ + ]  ufw
 [ + ]  unattended-upgrades
 [ - ]  uuidd
 [ - ]  x11-common

個別のサービスのステータス確認

個別のサービスに対して、

ステータス状況を確認するには、

sudo service サービス名 status

例えば、

「MySQL」について、

サービスの起動状況を確認するには、

sudo service mysql status

というコマンドで確認が可能です。

実行すると、

$ sudo service mysql status
● mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2023-03-27 11:42:05 JST; 1 weeks 0 days ago
   Main PID: 897 (mysqld)
     Status: "Server is operational"
      Tasks: 40 (limit: 4677)
     Memory: 463.5M
     CGroup: /system.slice/mysql.service
             └─897 /usr/sbin/mysqld

（参考）サービスをうまく停止できない事象が発生した

サービスの状況の例として、

 [ + ]  php7.4-fpm
 [ - ]  php8.0-fpm
 [ + ]  php8.1-fpm

のように、

8.1系を動かしているので、

なぜか起動している7.4のサービスを削除（停止）したい状況があります。

この7.4系を停止しようとする時、

コマンドとしては、

sudo service php7.4-fpm stop

というコマンドで、

通常であれば、停止が可能です。

しかし、

上記コマンドを実行しても、

 [ + ]  php7.4-fpm
 [ - ]  php8.0-fpm
 [ + ]  php8.1-fpm

という状況のままで、

なぜか上手く停止（削除）することができません。

この時、

sudo service php7.4-fpm status

で確認すると、

$ sudo service php7.4-fpm status
● php7.4-fpm.service
     Loaded: masked (Reason: Unit php7.4-fpm.service is masked.)
     Active: inactive (dead)

となっていました。

mask状態なので、

シンボリックリンクがあると思われるので、

そのパスなどを確認しようとしました。

フォルダとしては、

/etc/systemd/system

という場所で、

ls -ls php7.4-fpm.service

で確認すると、

php7.4-fpm.service -> /dev/null

となっており、

シンボリックリンク先がない状態でした。

この事象がなぜ発生したかは、

原因自体は掴めていませんが、

この事象自体に対処します。

上記フォルダで、

php7.4-fpm.service

自体を削除してあげます。

シンプルに

sudo rm php7.4-fpm.service

で削除を実行。

その後に、

sudo service php7.4-fpm stop

で停止してあげると、

 [ - ]  php7.4-fpm
 [ - ]  php8.0-fpm
 [ + ]  php8.1-fpm

このように、

うまく停止することができました。

サービスの停止がうまくいかないときは、

今回の事象が参考になるかもしれないので、

チェックしてみると良いですね。

Railsでプロジェクト内の画像ファイルを表示させる２つの方法

Railsでアプリケーションを作って、

そのアプリケーションを作っていく中で、

レイアウトのデザインに、

画像を使うことは一般的にあります。

その際、

画像を設定して呼び出すためには、

どのようにしたら良いのか、

この点について、

簡単にこの記事にメモしておきます。

Rubyのバージョン

まずは、

試した時のRubyのバージョンですが、

コマンドで確認します。

ruby -v

のコマンドを実行して確認すると、

$ ruby -v
ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [arm64-darwin21]

このバージョンであることが確認できました。

Railsのバージョン

Railsに関しては、

プロジェクト導入時に最新を取得したので、

その結果としてのRailsのバージョンですが、

コマンドで確認します。

rails -v

のコマンドを実行して確認すると、

$ rails -v
Rails 7.0.4.2

このバージョンで作成されていました。

画像ファイルを表示させるための２つの方法

Railsのプロジェクト内の画像ファイルを、

レイアウトの中で表示させるためには、

２つの方法があります。

その方法とは、

assetsフォルダにアセットファイルとして使う方法
publicフォルダに公開ファイルとして使う方法

この２パターンになります。

それぞれの方法で、

プロジェクト内の画像が表示できるので、

実際に試してみましょう。

assetsフォルダにアセットファイルとして使う方法

まずは、

アセットファイルとして、

画像ファイルを設置することで、

そのファイルを呼び出して表示する方法です。

画像ファイルの配置場所

画像ファイルを、

プロジェクトフォルダの中の、

app/assets/images/

というフォルダの中に配置します。

例えば、

app/assets/images/sample.png

となるようにファイルを設置します。

レイアウトファイルでの画像ファイルの呼び出し

先ほどの例で、

app/assets/images/

の中にある、

sample.png

というファイルを呼び出すには、

<img src="<%= asset_path( 'sample.png' ) %>" />

のように、

asset_path

をすることで、

画像ファイルを表示することができます。

publicフォルダに公開ファイルとして使う方法

次に、

公開ファイル（publicファイル）として、

画像ファイルを設置することで、

そのファイルを呼び出して表示する方法です。

画像ファイルの配置場所

画像ファイルを、

プロジェクトフォルダの中の、

public/

というフォルダの中に配置します。

例えば、

public/sample.png

となるようにファイルを設置します。

レイアウトファイルでの画像ファイルの呼び出し

先ほどの例で、

public/

の中にある、

sample.png

というファイルを呼び出すには、

<img src="<%= public_compute_asset_path( 'sample.png' ) %>" />

のように、

public_compute_asset_path

をすることで、

画像ファイルを表示することができます。

参考）public_compute_asset_pathを使わない方法

先ほどの、

public_compute_asset_path

を使わなくても、

公開フォルダ（publicフォルダ）であれば、

直接、画像のパスを書くことで、

画像を表示することがでます。

具体的には、

publicフォルダが、トップルートのパスになる

ということが言えるので、

この点を使って、

公開フォルダの画像を表示することができます。

例として、

public/

の中にある、

sample.png

というファイルを呼び出すには、

<img src="/sample.png" />

という形で、

直接、パスを設定することで、

画像ファイルを呼び出すことが可能です。

ただし、

Railsプロジェクトとして、

公開ファイルを使う場合は、

public_compute_asset_path

を使うように統一すると良いでしょう。

Railsで「The asset “application.js” is not present in the asset pipeline.」が起きた時の調整方法

Railsでアプリケーションを作って、

そのアプリケーションを作っていく中で、

レイアウトのデザイン部分は、

CSSフレームワークを使って、

楽をしたいと考えて、

環境を構築することがあります。

そんな中で、

アプリケーションFWとしてRails
CSSフレームワークとしてBootstrap

という構成で、

プロジェクトの作成から、

実際にBootstrapを導入する部分などを、

こちらの記事で試したことをメモしておきました。

今回の事象は、

上記などを試す中で、

Railsのバージョンにもよりますが、

画面上のエラー表示として、

Sprockets::Rails::Helper::AssetNotFound

が起きており、

その中のメッセージとして、

The asset "application.js" is not present in the asset pipeline.

という問題が起きており、

この点について対応したことを、

この記事にメモしておきます。

Rubyのバージョン

まずは、

試した時のRubyのバージョンですが、

コマンドで確認します。

ruby -v

のコマンドを実行して確認すると、

$ ruby -v
ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [arm64-darwin21]

このバージョンであることが確認できました。

Railsのバージョン

Railsに関しては、

プロジェクト導入時に最新を取得したので、

その結果としてのRailsのバージョンですが、

コマンドで確認します。

rails -v

のコマンドを実行して確認すると、

$ rails -v
Rails 7.0.4.2

このバージョンで作成されていました。

起きた事象

先ほどのバージョンにも関わりますが、

Railsのバージョン７で試しています。

今回起きたエラーメッセージとしては、

The asset "application.js" is not present in the asset pipeline.

ですが、

The asset "application.css" is not present in the asset pipeline.

のように、

同じようなアセットファイルのエラーであれば、

今回の対応で問題がなくなることがあるので、

試してみてもらえればと思います。

対象方法

Railsでのアセット自体は、

バージョンにもよりますが、

自分が試していたバージョンでは、

アセットファイルとしてコンパイルして作成される
コンパイルされたファイルを参照する

となっています。

この参照するためのファイルが見つからないことが問題なので、

再度、

Railsのコマンドを使って、

再コンパイルしてあげます。

コマンドは、

rails assets:precompile

で再コンパイルできるので、

こちらを実行した上で、

rails s

を実行すると、

問題なくレイアウトが表示されました。

こちらでうまくいかなければ、

別の問題が考えられますが、

アセット周りの状況を、

１つずつ、確認していきましょう。

GithubにSSH認証を設定する方法

Githubを使い始めるときに、

認証方法として、

SSH認証を行おうとして、

その時の対応方法を、

今後のためにもこの記事にメモしておきます。

全体の流れ

全体の流れとしては、

鍵情報を作成する
公開鍵をGitHubに設定する
秘密鍵をSSHエージェントで設定する

という流れで、

今回のSSH認証のための設定を進めます。

鍵情報の作成

まず、SSHキーを生成します。ターミナルを開き、以下のコンドを実行します。

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

このコマンドは、

RSA暗号化アルゴリズムを使用して、

4096ビットの鍵を生成します。

メールアドレスはあなたのGitHubアカウントのメールアドレスを入力してください。

Enterキーを押して、デフォルトのファイル名と場所を受け入れます。

注意点が１つ。

【注意】設定時の「パスフレーズ」は忘れないように管理すること

という点については、

パスフレーズを後々、使う機会があるので、

どこかにメモを残しておくと良いでしょう。

ちなみに、

実行してみると、

イメージとして、

$ ssh-keygen -t rsa -b 4096 -C "sample@sample.com"
Enter file in which to save the key (/Users/sample/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/sample/.ssh/id_rsa
Your public key has been saved in /Users/sample/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:hogehogehogehogehoge sample@sample.com
The key's randomart image is:
+---[RSA 4096]----+
|    hogehoge     |
|    hogehoge     |
|    hogehoge     |
|    hogehoge     |
|    hogehoge     |
|    hogehoge     |
|    hogehoge     |
+----[SHA256]-----+

このようになります。

まず、

Enter file in which to save the key (/Users/sample/.ssh/id_rsa):

この部分は、

鍵情報を作成する場所になります。

基本的にはこのデフォルトの状態で良いはずです。

そして、

次に表示されている

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

については、

「パスフレーズ」

を２回、同じものを入力してください。

念のために、

注意喚起をもう１度。

【注意】設定時の「パスフレーズ」は忘れないように管理すること

ここまでうまくいったら、

まずは鍵情報の作成が完了です。

GitHubへの鍵情報の設定

公開鍵をGitHubアカウントに追加します。

GitHubアカウントのページで、

右上のアカウントアイコンをクリックし、

「Settings」を選択します。

その後、

「SSH and GPG keys」をクリックします。

「New SSH key」をクリックして、

タイトルと公開鍵を入力します。

公開鍵は、 ~/.ssh/id_rsa.pub にあります。

コマンド

cat ~/.ssh/id_rsa.pub

を実行することで、公開鍵を確認できます。

秘密鍵の設定

先ほど作成した、

鍵情報を使って、

秘密鍵についても設定を進めます。

SSHエージェントを起動し、

秘密鍵を追加します。

次のコマンドを実行します。

SSHエージェントを起動します

eval "$(ssh-agent -s)"

次に、

秘密鍵をSSHエージェントに追加します。

ssh-add ~/.ssh/id_rsa

ここまでを実行すると、

$ eval "$(ssh-agent -s)"
Agent pid 1418
　↑
ここまでで、SSHエージェントのプロセス起動済み。

% ssh-add ~/.ssh/id_rsa_github
Enter passphrase for /Users/sample/.ssh/id_rsa:
　↑
ここでパスフレーズを求められるので、
鍵情報作成時のパスフレーズを使用。

Laravelで環境ファイルの設定情報をコントローラーなどで使用する方法

Laravelを使っていて、

各種データをSQLで取得する際に、

環境変数の設定ファイルとして

.env

のファイルに情報を持たせて、

その値を使いまわすことがあります。

この設定情報を、

Laravelの中で、

Controller
Models

あたりで使う方法を、

この記事でメモを残しておきます。

各種バージョン

Laravel

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 8.83.26

というバージョンであることがわかります。

対応内容

環境変数ファイル

環境変数として、

各種設定値を、

.env

というファイルに設定します。

このファイルはデフォルトで準備されているので、

各種値があると思うので、

その中に、

自分が設定したい値を追加します。

SAMPLE_ENV_VALUE=sample-test-value

このように、

設定値を

設定変数=設定したい値

という形で設定します。

ここまで設定したら、

次にLaravelの設定ファイルを編集します。

設定ファイル

設定ファイルとして、

config/app.php

のファイルに、

先程の環境変数を使った値を、

Laravelの設定値情報に追加していきます。

return [
  :
  :
'sample_env_value' => env('SAMPLE_ENV_VALUE', ''),
  :
  :
]

こちらの設定をすることで、

「app」の設定内に「sample_env_value」という設定値を持たせた

という状態になりました。

Laravel内のコードから呼び出し

ここまで設定してきた、

Laravelの設定情報については、

Config

というクラスを使います。

フルパスで設定するなら

Illuminate\Support\Facades\Config

となります。

こちらを自分が使用したい、

Controller
Models

の中に追加していきます。

そして、

実際に値を使う際は、

Config::get('app.sample_env_value');

このように、

Configクラスを使うことで、

簡単に値が取得ができるので、

こちらを使うことで、

コードの整理にも使えるので、

使っていくと良いですね。

ChatGptのサイトで試してみた件

いろんな記事などで紹介されているが、

Open AIが提供している

「ChatGPT」

というのがすごいということで、

ネット上に投稿が溢れている。

そんな中で、

実際に自分自身でも試してみたいと思ったので、

その時の試した時に内容や、

参考にした記事などをメモ。

公式サイトの情報

Open AIの公式サイト

まずは、ChatGPTを提供しているOpen AI自体の公式サイト

こちらにも情報が載っているので、適時、チェック

Open AI

ChatGPTの公式サイト

ChatGPTは、上記のOpen AIのサイトからも遷移できると思いますが、

リンクメモのためこちらに残しておきます。

ChatGPT

ChatGPTを試してみる

アカウントを作るところは省略するので、

アカウントを作成した状態で、

上記のChatGPTのサイトに遷移すると、

ログインが求められるのでログインしたら、

「Try ChatGPT」

があるので、

そちらをクリックして使用します。

画面を開くと、

上記のような画面になるので、

そちらに対して、

内容を入力して実行（Enterキー）をします。

すると、

このように、

返答が戻ってきました。

内容によっては、

過去データをもとにすごく欲しい情報が返ってくるけれど、

リアルタイムの情報は返ってこないみたいですね。

日本語でも、このChatGPTは質問できるので、

試しにリアルタイムの情報を聞いてみます。

すると、

このように、

リアルタイム取得などは、

アプリケーションを使うように勧められますね。

箇条書きで１０個など、

質問できるので、

このような形で、

非常に使い勝手の良くなってますね。

この他にも、

コードを生成してくれたりするので、

その辺りは、試してみて、

別記事にメモしようと思います。

Next.js でUseContextで共通データとして扱う方法

Nextjsで実装していたときに、

各種共通データを扱うときに、

ベースとなるNextjsの仕組み自体で、

うまくやれる方法があるのかもしれませんが、

自分で調べている範囲だと、

どのような方法があるかなど、

プラクティスが見つからなかったので、

ReactのUseContextを使って、

共通的なデータを扱うことにしました。

この記事では、

そのUseContextでの共通データを扱う方法を、

Nextjsで実際に設定を試してみたので、

その際に参考にさせてもらった記事などを含めて、

メモを残しておきます。

公式サイトの情報

公式サイト

まずは、公式サイトでUseContextのことを確認

Hooks API Reference

React Hooksの基礎部分のおすすめ

UseContextを使うのですが、

そもそも、React Hooks周りで、

良くわからないという方は、

こちらの方の動画がわかりやすいのでおすすめです。

参考にした記事

今回、実際に実装する上で、

参考にさせていただいた記事としては、

こちらの記事です。

記事内の動画がすごく参考になったので、

そちらも見てもらえると良いですね。

Make User State Globally Accessible in Next.js with React Context and Providers

実際に試したコード

実際に試したコードについても、

こちらの記事に残しておくので、

参考になれば幸いです。

UseContext用を別ファイルで準備

ファイルを作成

context/BaseContextProvider.js

コード

import { createContext, useContext } from 'react';

const commonInfo = {
  sample_value : 'sample test value'
}
const BaseContext = createContext(commonInfo);

const BaseContextProvider = ({ children }) => {
  return <BaseContext.Provider value={commonInfo}>
    {children}   
  </BaseContext.Provider>
}

export const useCommonInfo = () => useContext(BaseContext);
export default BaseContextProvider;

上記で、

UseContextを使って、

Providerでのvalue設定も含めて、

ラッピングして呼び出すようにしてます。

アプリの基本呼び出しに追加

アプリの基本呼び出しのファイルに、

上記のUseContextの設定ファイルを使うように変更します。

ファイル

_app.js

コード

import BaseContextProvider from '/context/BaseContextProvider'

function MyApp({ Component, pageProps }) {
  return <>
    <BaseContextProvider>
      <Component {...pageProps} />
    </BaseContextProvider>
  </>
}

export default MyApp

シンプルに、

作成したUseContextのためのコードを呼び出して、

そちらを使うように変更した感じです。

UseContextの値を使ってみる

実際にこのUseContextの値を使ってみます。

どこかのコンポーネントで、

import { useCommonInfo } from '/context/BaseContextProvider'

export default SampleComponent() {
   const common = useCommonInfo();
   console.log(common);
}

とすることで、

実際の値を取得することができます。

今回の例であれば、

common.sample_value

とすることで、

sample test value

という値が返ってくるので、

うまく動いていることが確認できました。

Laravelで取得用SQLをORMではなく、個別SQLを直接、実行する方法

Laravelを使っていて、

各種データをSQLで取得する際に、

ORMを使って、

「select」項目
「where」項目
「join」項目

など、

各項目をORMを使って、

SQLを実行することが、

一般的に良く行う方法かと思います。

そんな中で、

ORMを使って、

実行できるかもしれないけれど、

ちょっと面倒なSQLなので、

個別SQLとして、

直接、SQLを実行したいことがあります。

この個別SQLを実行したいことが、

定期的に発生するので、

その方法をメモを残しておきます。

各種バージョン

Laravel

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 8.83.26

というバージョンであることがわかります。

対応内容

実際に個別のSQLを実行するためには、

selectの引数に直接、SQL文を渡すことで実行できます。

コードとしては、

DB::select('対象のSQL', $params);

このようになります。

例としては、

DB::select('
  select 
    val1,
    val2
  from 
    sample_table
  where id = ?
', array(1));

このように、

条件式などの設定値は、

SQL文の次に配列で渡して使います。

Laravelで「The “” file does not exist or is not readable.」が発生した件

Laravelを使っていて、

各種データをCSVインポート処理を行い、

今までの環境では、

問題なく処理が動いていました。

今回、

新規の環境を作ったことで、

CSVアップロード時に、

「The “” file does not exist or is not readable.」

というエラーが発生したので、

その他王を行った時のメモ。

エラー内容

エラーとしては、

ファイルアップロードした際に、

The "" file does not exist or is not readable.
 {"userId":1,"exception":"[object]
 (Symfony\\Component\\Mime\\Exception\\InvalidArgumentException(code: 0): 
The \"\" file does not exist or is not readable.

このようなエラーログが、

Laravel上で吐き出されていました。

各種バージョン

Laravel

Laravelのバージョンとしては、

php artisan --version

というコマンドで確認すると、

$ php artisan --version
Laravel Framework 8.83.26

というバージョンであることがわかります。

Nginx

Nginxのバージョンとしては、

nginx -V

というコマンドで確認すると、

$ nginx -V
nginx version: nginx/1.21.4

というバージョンであることがわかります。

対応内容

最終的に調べた結果としては、

自分が動かしている環境では、

php-fpmの設定を調整する必要がありました。

修正対象ファイル

/etc/php/x.x/php.ini

上記で自分が実行しているバージョンの設定情報ファイルを編集。

コードとしては、

今回はPOSTのサイズ指定で、

許容サイズを広げるために、

post_max_size = 指定サイズ

こちらの設定を変更。

アップロードとかのサイズエラーの際は、

上記の設定ではなくて、

upload_max_filesize = 指定サイズ

こちらの設定なので、

必要であれば合わせて調整。

これで実行すると、

問題なく処理が行われた。

php-fpmの再起動も必要なので、

以下の記事の一部コマンドで再起動を実行。

sudo service php8.1-fpm restart

対応的には、

以下の記事内容と同じでした。

エラー「Maximum execution time of 30 seconds exceeded」が起きた件

Laravel+Pusherでリアルタイム処理のためのイベント発生を試してみた

アプリケーションを作成していく中で、

各種の処理状況を、

リアルタイムで表示したいなど、

アプリケーションの用途によってはあります。

そんな中で、

Laravelの構成の中で、

実際にリアルタイムの状況表示をするために、

公式ドキュメントでも記載のあった、

「Pusher」というサービスを使って、

リアルタイムの表示を試した時のメモを、

この記事に残しておきます。

Laravelのバージョン

実行環境のLaravelのバージョンとしては、

php artisan --version

のコマンドで確認したところ、

Laravel Framework 8.83.26

というバージョン。

Pusherとは？

Pusherは、

リアルタイムのデータの送受信に関して、

容易に使うことができるようにするために、

設計されたWebサービスであり、APIを提供しています。

Pusherを使用することで、

ウェブやモバイルアプリケーション、チャットアプリなどで、

リアルタイミングの表示機能などを実現することができます。

PusherのAPIは、

WebSocket、HTTPなどのプロトコルをサポートしているので、

自分の環境に合った使い方ができるので、

最新の対応プロトコルなどについては、

公式サイトをチェックしながら、

実際に使ってみることをお勧めします。

「https://pusher.com/」を開く

Pusherの準備（アカウント作成など）

Pusherに関しては、

先ほどの説明のように、

リアルタイムのデータ送受信をできる限り、

簡単に使えるようにするためのサービスなので、

「https://pusher.com/」を開く

こちらのリンクから、

実際にアカウントを使って準備を進めます。

アカウント作成

アカウントの作成に関しては、

トップページから、

「Sign up」

のボタンが右上にあるので、

そちらから、

アカウントの作成を進めます。

アカウント作成は、

上記赤枠で、

メールまたは、Github・Googleのアカウントを用いて、

アカウント作成できるので、

自分の都合の良いもので作成してください。

Puhserチャンネルの準備

アカウントの作成を進めると、

次にチャンネルの作成が表示されます。

ちなみに、アカウントだけ作成で終わったら、

「Create app」のボタンなどでも、

同じように以下の表示で、

チャンネル作成が表示されます。

表示としては、

こちらのような表示になり、

項目としては、

チャンネル名
地域
オプション（作成時のフロントエンド）
オプション（作成時のバックエンド）

を設定していくことになるので、

自分の用途に合った設定をすると良いですね。

作成したPusherチャンネルの情報確認

実際に作成したPusherのチャンネルは、

ログインした画面で、

「channel」

を押して、

その中で、

「Apps」

を選択してもらうと、

このように、

自分が作成したチャンネル（App）が確認できます。

LaravelにPusherの設定コードを確認

Pusherのアカウント登録やチャンネルの作成が終わったら、

LaravelにPusherの設定を追加していきます。

この時、

追加するためのコードについては、

Pusherの管理画面の中で、

この部分を見てもらうと、

実際の参考コードが見れるので、

そちらで自分に合った環境のコードを見てもらえると、

参考にしやすいと思うのでお勧めです

実際に設定したコード

実際に設定したコードを、

こちらの記事にもメモを残しておきます。

Composerでライブラリを追加

composerのコマンドを使って、

ライブラリを追加します。

composer require pusher/pusher-php-server

環境ファイルにPusherの情報を追加

環境ファイルとして、

.env

というファイルに、

Pusherの情報を追加します。

PUSHER_APP_ID=ここの設定はPusherで確認
PUSHER_APP_KEY=ここの設定はPusherで確認
PUSHER_APP_SECRET=ここの設定はPusherで確認

設定ファイルのオプションを変更

Laravelの設定情報のconfigフォルダ内で、

config/broadcasting.php

のファイルを調整します。

調整としては、

'options' => [
  'cluster' => 'ap3',
  'useTLS' => true
],

この部分を調整を実施。

クラスファイルの設定

クラスファイルの設定としては、

公式サイトの参考コードは、

<?php

use Illuminate\Queue\SerializesModels;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Contracts\Broadcasting\ShouldBroadcast;

class MyEvent implements ShouldBroadcast
{
  use Dispatchable, InteractsWithSockets, SerializesModels;

  public $message;

  public function __construct($message)
  {
      $this->message = $message;
  }

  public function broadcastOn()
  {
      return ['my-channel'];
  }

  public function broadcastAs()
  {
      return 'my-event';
  }
}

このようになっているので、

Laravelのネームスペースの環境に合わせて、

app/Pusher/MyEvent.php

というファイルを作成して、

以下のコードに調整

<?php
namespace App\Pusher;

use Illuminate\Queue\SerializesModels;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Contracts\Broadcasting\ShouldBroadcast;

class MyEvent implements ShouldBroadcast
{
  use Dispatchable, InteractsWithSockets, SerializesModels;

  public $message;

  public function __construct($message)
  {
      $this->message = $message;
  }

  public function broadcastOn()
  {
      return ['my-channel'];
  }

  public function broadcastAs()
  {
      return 'my-event';
  }
}

上記でLaravel内の設定は完了しています。

コード内の

my-channel
my-event

などは、

ご自身のPusherの環境に合わせて、

調整をしてみてください。

実行してPusherでログ確認

実際に上記の設定で、

処理を試しに動かして、

Pusherでログを確認してみます。

Laravelでの実行コード

実際にPusherへのイベント通知として、

公式サイトの参考コードを流用して、

以下のように処理を行います。

event(new MyEvent('hello world'));

Pusherでのログ確認

上記の処理を実行したときに、

Pusher側でログを確認するために、

こちらの

「Debug Console」

の画面を開きます。

最初は、上記のように何も表示されていませんが、

Laravelの方で処理を実行すると、

このように、

イベント処理が発生しいます。

さらに、

ログの詳細を確認すると、

上記の画像のように、

取得した値として、

{
  "message": "hello world"
}

という値が、

処理で発生して、

Pusher側で受け取っていることがわかります。

ここまでうまく動けば、

Laravel+Pusherで、

リアルタイム処理のための、

イベント発生を試してみることはうまくいきました。

実際のクライアント側（表示側）については、

自分の環境では、

Vue.jsを使用しましたが、

そちらの設定や表示などについては、

また別の記事で機会があればメモを残します。

Let’s encryptのSSL証明書をCertbotを使って、Nginxに設定する方法

Nginxで各種ドメインを設定して、

Webサーバーを管理していく中で、

SSL証明書を設定しようとしたときに、

無料のLet’s Encryptから証明書を取得して、

設定しようとする方法が、

個人的にはよくやる方法です。

この方法に関しては、

各種コマンドなど、

忘れたりするので、

概要も含めて、

メモを残します。

「Let’s Encrypt」と「SSL証明書」

Let’s Encryptは、

無料でSSL証明書を提供するオープンソースの認証局（CA）

です。

SSL証明書は、

ウェブサイトのセキュリティを強化し、

ユーザーのデータを保護するために使用されます。

有料のSSL証明書もありますが、

中小企業や個人ブログ運営者などにとっては、

予算的なことや、敷居が高いという点がネックになることがあります。

しかし、

Let’s Encryptは、

無料で手軽に取得できることから、

広く使われるようになっていますので、

１度、試してみると良いでしょう。

「Let’s encrypt」の公式サイト

「Certbot」とは

Certbotは、

オープンソースで無料のSSL証明書を自動的に取得するためのツールです。

SSL証明書を使って、

ウェブサイトのセキュリティを強化するために使用しますが、

Certbotを活用することで、

Webサーバーの設定と通信を自動化することで、

証明書の発行と更新を簡単に行うことができます。

ちなみに、

Certbotは、LinuxとmacOSで使用でき、

多くのWebサーバーに対応しているため、

Apache、Nginx、Google Cloud Platformなどの、

クラウド上のサーバーで使うことができるので、

よく使われているWebサーバーの環境であれば、

問題なく、各環境で使うことができます。

Certbotの大きなポイントは、

コマンドラインを使用してインストール、設定、更新することができる

という点です。

初心者でも簡単に使用できるので、

Certbotのインストールと設定などについて、

最新情報に関しては、

公式ウェブサイトのドキュメンテーションを、

参照することをお勧めします。

「Certbot」の公式サイト

「Let’s encrypt」と「Certbot」

Let’s Encryptは、非営利団体であり、

大手テクノロジ企業やファウンデーションから、

支援を受けているSSL証明書発行機関です。

Certbotは、

Let’s Encryptのクライアントであり、

自動的に証明書を生成するためのコマンドラインツールです。

簡単に言えば、

「Let’s Encrypt」はSSL証明書を管理している組織
「Certbot」は「Let’s encrypt」のSSL証明書を使うためのツール

という感じで、

Let’s Encryptは証明書を発行する機関であり、

Certbotは証明書を自動的にインストールするための、

クライアントであるという関係になります。

Let’s encryptのSSL証明書をCertbotを使って、Nginxに設定を試してみる

サーバーOSのバージョン

サーバーに関しては、

Ubuntuを使用しているので、

lsb_release -a

のコマンドで、

バージョンを確認します。

確認すると、

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.3 LTS
Release:	20.04
Codename:	focal

このバージョンを使っていることがわかります。

Nginxのバージョン

Nginxに関しても、

使用している環境のバージョンについては、

nginx -v

のコマンドで、

バージョンを確認してみると、

$ nginx -v
nginx version: nginx/1.21.4

というバージョンであることがわかりました。

Certbotのインストール

まずは、

SSL証明書を設定するためのツールとして、

Certbotをインストールします。

各環境への導入コマンドに関しては、

「Certbot」の環境ごとの導入コマンド確認ページ

こちらのサイトで、

このように、

OSとミドルウェアを自分の環境に合わせることで、

自分の導入したい環境にあった、

Certbotの導入コマンドが確認できます。

CertbotをNginxに設定するためのコマンド

Certbotを自分自身のドメインに設定する上で、

パラメータとして使う値としては、

Webサーバーが「Nginx」
設定したい先の「ドメイン名」

の２つを使用します。

コマンドとしては、

sudo certbot --nginx -d ドメイン名

というコマンドになるので、

例えば、

ドメイン名が「sample.com」だとすると、

sudo certbot --nginx -d sample.com

というコマンドになります。

こちらを実行することで、

sample.comに関して、

こちらの証明書の状況が、

このように変われば、

うまく設定ができています。

今回のように、

Ubuntu＋Nignxに対して、

Let’s encryptをCertbotを使って、

SSL証明書を設定することは多いですが、

The requested nginx plugin does not appear to be installed

が起きた時の対応は、

以下の記事にメモしておいたので、

必要であれば参照ください。

Let’s Encrypt(Certbot)でエラー「The requested nginx plugin does not appear to be installed」が発生した件

RailsでBootstrapのレイアウトデザインを使うために試したこと

Railsでアプリケーションを作って、

そのアプリケーションを作っていく中で、

レイアウトのデザイン部分は、

CSSフレームワークを使って、

楽をしたいと考えるのは、

よくあることだと思います。

そんな中で、

アプリケーションFWとしてRails
CSSフレームワークとしてBootstrap

という構成で、

プロジェクトの作成から、

実際に試したこと、

うまくいかなくて調整した点など、

この記事にメモしておきます。

Rubyのバージョン

まずは、

試した時のRubyのバージョンですが、

コマンドで確認します。

ruby -v

のコマンドを実行して確認すると、

$ ruby -v
ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [arm64-darwin21]

このバージョンであることが確認できました。

Railsのバージョン

Railsに関しては、

プロジェクト導入時に最新を取得したので、

その結果としてのRailsのバージョンですが、

コマンドで確認します。

rails -v

のコマンドを実行して確認すると、

$ rails -v
Rails 7.0.4.2

このバージョンで作成されていました。

BootsrapをデザインFWとしてRailsに導入する方法

先ほどのバージョンにも関わりますが、

Railsのバージョン７で試しています。

このバージョンでは、

CSSフレームワークとして、

Bootstrapをプロジェクト作成時に、

合わせて導入することができます。

基本的なプロジェクト導入のコマンド

ただ、基本的なプロジェクト導入のコマンドは、

バージョンごとに異なることがあるので、

以下の公式サイトも確認すると良いでしょう。

Railsの公式サイト（プロジェクト作成部分）

　↓　↓　↓

Getting Started with Rails

CSS

また、

今回使用するプロジェクト作成時のオプションとして、

CSSオプションを使用しますが、

こちらに関しては、

以下の公式サイトに

The same approach is taken with CSS bundlers that rely on Node. With Rails 7, all they need to be able to produce is a compiled application.css file, and they’ll integrate perfectly. From Tailwind CSS to Bootstrap, from Dart-powered Sass to PostCSS. If you’re willing to accept the complexity of a Node dependency, you can pre-configure your new Rails app to use any of them with --css bootstrap and it’ll use cssbundling-rails. (And exclusively for Tailwind, we even have a version that works without the Node dependency as well!)
Rails 7.0: Fulfilling a vision

とあり、

The same approach is taken 
with CSS bundlers that rely on Node. 
With Rails 7, all they need to be able 
to produce is a compiled application.
css file, and they’ll integrate perfectly. 
From Tailwind CSS to Bootstrap, 
from Dart-powered Sass to PostCSS. 
If you’re willing to accept the complexity of a Node dependency, 
you can pre-configure your new Rails app to use any of them with --css bootstrap 
and it’ll use cssbundling-rails. 
(And exclusively for Tailwind, we even have a version 
　that works without the Node dependency as well!)

この説明の中で、

you can pre-configure your new Rails app 
to use any of them with --css bootstrap 
and it’ll use cssbundling-rails.

とあるので、

そちらのオプションを使ってみます。

プロジェクトの作成

先ほどのオプションを使いながら、

作成のためのフォルダを作成
オプション指定でプロジェクトファイルを作成

という手順で対応します。

作成のためのフォルダを作成

まずは、

新規プロジェクト用のフォルダを用意します。

私の方では、

Ubuntuで、

mkdir sample-project

というコマンドで、

フォルダを作成しましたが、

それぞれの環境に合わせた方法で、

フォルダを作成してもらえたら大丈夫。

オプション指定でプロジェクトファイルを作成

先ほど作成した、

sample-project

というフォルダの中に移動して、

プロジェクトファイルを作成します。

この記事で共有したオプションも使うので、

rails new . --force --css=bootstrap -j webpack

というコマンドを実行します。

実行してみると、

という感じで処理が始まり、

処理の途中で、

assetsフォルダへのビルドファイルなど、

処理が色々と行われ、

という感じで、

無事、処理が完了しました。

Bootstrapのレイアウトを試しに表示してみる

Bootstarapのレイアウトとして、

最終的に上記のようなレイアウトを、

トップページとして表示することを試します。

以下、ファイル名とコードを記載しておくので、

参考に試してみてください。

ルーティング

ルーティングとしては、

config/routes.rb

のファイルを調整します。

コードは、

確認するだけなので、

シンプルに、

Rails.application.routes.draw do
  root "sample#index"
end

このように、トップページのみ設定します。

ビューファイル

レイアウトに関しては、

ビューファイルを作成します。

ビューファイルは、

app/views/sample/

というフォルダを準備して、

index.html.erb

というファイルで作成します。

コードは、

Boostrapを試したいので、

<nav class="navbar navbar-expand-lg navbar-dark bg-dark">
  <div class="container px-lg-5">
    <a class="navbar-brand" href="#!">Sample Bootstrap</a>
    <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarSupportedContent" aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation"><span class="navbar-toggler-icon"></span></button>
    <div class="collapse navbar-collapse" id="navbarSupportedContent">
      <ul class="navbar-nav ms-auto mb-2 mb-lg-0">
        <li class="nav-item"><a class="nav-link active" aria-current="page" href="#!">Item1</a></li>
        <li class="nav-item"><a class="nav-link" href="#!">Item2</a></li>
        <li class="nav-item"><a class="nav-link" href="#!">Item3</a></li>
      </ul>
    </div>
  </div>
</nav>
<header class="py-5">
  <div class="container px-lg-5">
    <div class="p-4 p-lg-5 bg-light rounded-3 text-center">
      <div class="m-4 m-lg-5">
        <h1 class="display-5 fw-bold">Sample Boostrap Layout</h1>
        <p class="fs-4">This is bootstrap sample layout.</p>
        <a class="btn btn-primary btn-lg" href="#!">Button sample</a>
      </div>
    </div>
  </div>
</header>

このようなコードで

今回は試してみます。

コントローラー

コントローラーとしては、

シンプルに表示したいだけなので、

app/controllers

の中に、

sample_controller.rb

というファイルを作成します。

コードは、

表示だけの確認のために、

パラメータ等は特に使わず、

class SampleController < ApplicationController
  def index
  end
end

このようなコードで試します。

表示確認

ここまで、

各種ファイルの準備が完了したら、

プロジェクトの

sample_project

のフォルダ直下で、

rails s

のコマンドを実行することで、

Railsアプリケーションを起動します。

実行できたら、

という感じに表示されると思うので、

http://127.0.0.1:3000/

というURLで、

ブラウザで確認してみましょう。

確認してみると、

このようなレイアウトが表示されたら、

うまくレイアウト表示ができています。

一部、うまく挙動しないので、暫定的に調整

レイアウトとしては、

このレイアウトで問題なく表示できましたが、

サイズを小さくした時の、

この赤枠のアイコン部分をクリックした時の挙動が、

うまくいかない（メニューが表示されない）という事象が起きました。

Bootstrapのjsファイルを読み込み追加で調整

レイアウトの表示部分はうまくいっていて、

ボタンクリックなどの動作挙動ができていない。

この状況から考えると、

JavaScript周りがうまくいっていないようだと考え、

暫定対応で、BootstrapのJavaScriptファイルを、

読み込むように追加しました。

もう少し、

スマートな調整方法があるかもしれませんが、

以下の対応で進めていきます。

調整するファイルとしては、

app/views/layouts

というフォルダの

application.html.erb

というファイルを調整します。

調整前

<!DOCTYPE html>
<html>
  <head>
    <title>Rails7BoostrapSample</title>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag "application", "data-turbo-track": "reload" %>
    <%= javascript_include_tag "application", "data-turbo-track": "reload", defer: true %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

調整後

<!DOCTYPE html>
<html>
  <head>
    <title>Rails7BoostrapSample</title>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag "application", "data-turbo-track": "reload" %>
    <%= javascript_include_tag "application", "data-turbo-track": "reload", defer: true %>
  </head>

  <body>
    <%= yield %>
    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.2.3/dist/js/bootstrap.bundle.min.js" integrity="sha384-kenU1KFdBIe4zVF0s0G1M5b4hcpxyD9F7jL+jjXkk+Q2h455rYXK/7HAuoJl+0I4" crossorigin="anonymous"></script>
  </body>
</html>

上記のように、

<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.2.3/dist/js/bootstrap.bundle.min.js" integrity="sha384-kenU1KFdBIe4zVF0s0G1M5b4hcpxyD9F7jL+jjXkk+Q2h455rYXK/7HAuoJl+0I4" crossorigin="anonymous"></script>

という読み込みを追加しました。

こちらを調整することで、

このような感じで、

メニュー表示がうまく挙動しました。

WordPressでFTP の認証情報が出る時の対処方法

WordPressでFTPの認証情報が表示される場合、

通常はWordPressがファイルやディレクトリに対して、

書き込み権限を取得するために必要な設定が不足していることが原因です。

このエラーを解決するためには、次の手順を実行する必要があります。

Configファイルの編集

wp-config.phpファイルを編集する FTPの認証情報が表示される場合、

wp-config.phpファイルに次の行を追加することができます。

define('FS_METHOD', 'direct');

ファイルの所有者を変更

ファイルやディレクトリの所有者が間違っている場合、

WordPressは書き込み権限を取得できません。

ファイルの所有者をWebサーバーに変更する必要があります。

これは、以下のコマンドを実行することで実行できます。

sudo chown -R www-data:www-data /var/www/wordpress/

上記の例では、

/var/www/wordpress/

というディレクトリを、

Webサーバーのwww-dataユーザーとグループに変更しています。

ディレクトリのパスは、環境に応じて変更してください。

ファイルのパーミッションを変更

ファイルやディレクトリのパーミッションが間違っている場合、

WordPressは書き込み権限を取得できません。

ファイルのパーミッションを変更する必要があります。

これは、以下のコマンドを実行することで実行できます。

sudo find /var/www/wordpress/ -type d -exec chmod 755 {} \;
sudo find /var/www/wordpress/ -type f -exec chmod 644 {} \;

上記の例では、

/var/www/wordpress/

というディレクトリ内のすべてのディレクトリに対して、

755パーミッションの設定を行い、

すべてのファイルに対して、

644パーミッションを設定しています。

ディレクトリのパスは、環境に応じて変更してください。

これらの手順を実行することで、

WordPressのFTPの認証情報が表示される問題を解決できるはずです。

Laravel のORMで結合する際に複数条件を設定する方法

アプリケーションを作成していく中で、

ORMを使用して、

テーブルデータを取得したり、

更新するなどはよく行うこと。

そんなORMの使用に関して、

今回は、

LaravelのORMを使用する際に、

結合条件として、

複数の条件を設定する方法が、

自分の中で書き方をよく忘れるので、

メモとして残しておく。

Laravelのバージョン

実行環境のLaravelのバージョンとしては、

php artisan --version

のコマンドで確認したところ、

Laravel Framework 9.23.0

というバージョン。

MySQLのバージョン

特にORMなので関係ないが、

使用しているデータベースも確認。

mysql -V

で確認すると、

mysql  Ver 8.0.32-0ubuntu0.20.04.2 for Linux on x86_64 ((Ubuntu))

というバージョン。

対応内容

LaravelのORMを使用して、

結合処理を実装すると、

通常では、

DB::table('base_tbl')
->join('join_tbl')
->....

という形で、

シンプルにjoinで実装できる。

今回、やりたかった実装は、

この条件を複数持たせる方法。

その方法は、

DB::table('base_tbl')
->join('join_tbl', function ($join)  {
  $join->on(
    :
  )->on(
    :
  );
}
->....

このように「join」のテーブル条件に、

「function」で関数を与えてあげること。

上記のように実装することで、

複数条件の結合が完了。

忘れた時はここを思い出せば良いので、

リンクをブックマークにメモ。

MySQLの既存テーブルへの更新処理の時のコマンドをメモ

MySQLのデータベースに対して、

テーブルを追加して、

データ更新処理を行うことがよくある。

こんな中で、

Laravelでのデータ移行を行うなど、

同じテーブル定義で処理を行うことは、

Laravelで別のデータベースから同じテーブルカラムのテーブルにデータを移行した件

などを行った例など、

実際によく行うことがあります。

そんな中で、

「既存テーブル」

に対して、

既存テーブルに対して新しいカラムを追加
既存テーブルのインクリメントを初期化

などについては、

時々、実施することがあり、

この時の実行コマンドを忘れるので、

その時の対応内容などをメモ。

使用したMySQLのバージョン確認

mysqlのコマンドラインで確認

mysql -V

実行結果

$  mysql -V
mysql  Ver 8.0.31-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

MySQLで既存テーブルにカラムを追加

既存のテーブルに対して、

新しいカラムを追加するのは、

そのテーブルデータ自体をそのまま残しながら、

新しいカラムを追加してそこに別項目の値を入れることができるので、

使うパターンが個人的に少しだけある。

その際、

ALTER TABLE テーブル名 add column カラム名 カラム定義 after 指定カラム;

という形で、

指定のテーブルに対して、

自分が追加したいカラム定義を追加することができる。

実際の例としては、

ALTER TABLE sample_tbl add column test_new_col varchar(255) after test_exist_col;

という形で使う。

上記の例だと、

テーブル名：sample_tbl
追加カラム名：test_new_col
追加カラム定義：varchar(255）

で追加することができる。

ちなみに、

最後の「after」以降は、

その特定カラムの後に追加されるので、

テーブル内のカラムの順番を指定する際に使う。

MySQLで既存テーブルのインクリメント番号を更新

テーブル定義で、

IDなどをインクリメントしている場合、

自動的に連番が振られていくが、

振られた連番の番号を初期化したい
振られた連番の番号が、途中データ削除で開いたので、変えたい

などの時に、

コマンドで調整できる。

その際のコマンドはシンプルで、

ALTER TABLE テーブル名 AUTO_INCREMENT = 更新したい番号

となるので、

こちらも実際の例としては、

ALTER TABLE sample_tbl AUTO_INCREMENT = 1

などのようにすることで、

「sample_tbl」というテーブルの自動連番の番号を、

「1」という値に初期化することができる。

上記は「1」で設定したが、

他の「60」や「128」などの任意の番号にも更新できるので、

その時のテーブルデータの状況など見ながら、

自分が指定したい連番の番号に指定すると良い。

Slack API（Slack bolt）で特定チャンネルがなぜか動作しなかった簡易なミス

Slackを使っていく中で、

APIを活用して、

便利に使用していこうとしています。

そんな中で、

Slack APIを活用していく中で、

Slack Boltのライブラリを活用して使用しています。

そんな中で、

いつも動かしているチャンネルでは動作するけれど、

Slack Boltで動かしている処理が、

一部のチャンネルでは動かない事象が発生。

すごく単純な理由だったけれど、

ゆくゆく同じことでハマりそうなのでメモ。

Slack APIに関する各種ドキュメント

Slack APIに関しては、

公式サイトに情報がたくさんあるので、

まずはそちらをチェックするのが良い。

この点に関しては、

以下の記事にまとめたので、

そちらを参考にしてもらいたい。

Slack APIを試した時に確認したサイトなどのメモ

今回、起きた事象

Slack APIを活用して、

特定メッセージが来たら処理をするようなこを、

普段使っているチャンネルで行っていたら、

新たに追加していたチャンネルでは、

何故か、その処理がうまく動かなかった。

最初は、

Slack Boltの処理または、設定自体かなと思って、

色々と調べたり、調整を試みていたが特に変わらず。

結果としては、

シンプルなSlackアプリの設定だったので、

以下の対応を実施して解消した。

Slack のチャンネルにアプリを追加して問題を解消

普段使っているチャンネルと、

今回試していたチャンネルとでは、

Slack Boltで動かしているアプリが、

追加されているかどうかの点が、

異なっていたので、その点を対応した。

まずは、

対象チャンネルで右クリックすると、

メニューが開くので、

詳細設定を開く。

これを開くと、

各種詳細設定がまた開くので、

上記のIntegrationsから、

アプリの追加を実施する。

追加自体は、

上記から設定画面を開くと、

追加できるアプリが表示されるので、

指定のアプリを追加ボタンで、

追加設定することで、

チャンネルへのアプリの追加が完了します。

今回のSlack Boltで動かなかった事象も、

チャンネルに対象アプリを追加していなかったことが、

原因だったので、この対象を行なって、

再度実行したら、問題なく処理が動きました。

Seleniumでキャッシュなどのプロファイルを保持するための方法

Seleniumの確認

インストール済みのバージョン確認

pythonのコマンドラインで確認

$ python3
Python 3.8.10 (default, Sep 28 2021, 16:10:42)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import selenium
>>> selenium.__version__
'4.0.0a1'

Seleniumでキャッシュなどのプロファイルを保持

Seleniumのオプション設定を追加

Seleniumのオプション設定として、

--user-data-dir

の設定を追加することで、

その指定フォルダをプロファイルの保存場所として設定することができる。

設定「–user-data-dir」

–user-data-dirの設定をオプションに追加する。

以下のオプション設定で追加。

options.add_argument('--user-data-dir=プロファイルのフォルダ')

こちらの設定を追加しておくと、

フォルダがなければ作成され、

そのフォルダに対してプロファイルが保存されます。

１度、ログインしたなどの情報は、

プロファイル情報として保持できるので、

こちらの設定をすることで、

１度、開いたページ保持などを行うことができます。

エラー「Maximum execution time of 0 seconds exceeded」が再び起きた件

アプリケーションを作成していく中で、

APIを作成して、

WebサーバーとしてNginxを稼働させて、

核処理を実装していたが、

処理的に重たい処理を流したときに、

「Maximum execution time of 0 seconds exceeded」

というエラーが発生した。

このエラーに関しては、

「Maximum execution time of 30 seconds exceeded」

というエラーが起きた時に、

対応を行っていたのだが、

その設定だけでは不足していたので、

色々と調べて試した結果、

PHP-Fpmの設定を変更することでうまくいった。

エラー内容

エラーとしては、

Maximum execution time of 0 seconds exceeded

というエラーが、

Laravelのログの方に出力されていた。

以前、起きたエラー

以前エラーが起きたときは、

Maximum execution time of 30 seconds exceeded

というエラーで、

ほぼエラー内容は同じだったので、

その時は、

以下の記事の内容を調整して対応した。

エラー「Maximum execution time of 30 seconds exceeded」が起きた件

対応内容

今回、Laravelの方でエラーになっていたので、

PHP-fpmの方のエラーと考えて調べたら、

php.iniの設定を変更することになった。

上記のリンクで以前対応したファイルと同じで、

/etc/php/8.1/fpm/php.ini

のファイルを修正。

対象箇所として、

以前調整したのは、

max_execution_time = 30

という設定値があったので、

無制限の値である「０」に

max_execution_time = 0

という部分を対応していた。

こちらの対応とは別に、

max_input_time = 0

という形で、

max_input_timeについても、

同じように設定の変更を行なった。

PHP-fpmの再起動も忘れずに実施

sudo service php8.1-fpm restart

この対応でうまくタイムアウトせずに、

うまく処理が最後まで動くようになりました。

Postした時に「POST Content-Length o xxx bytes exceeds the limit」が発生した件

Laravelを使っていて、

各種データを一括でデータを送りたくなり、

CurlのPOSTメソッドを使うことで、

データの転送処理を行おうとしていました。

この処理自体は、

問題なく実装できて動いていたのですが、

サイズの大きいデータになった際に、

「POST Content-Length o xxx bytes exceeds the limit」

というエラーが発生したので、

その時の対応内容のメモ。

エラー内容

エラーとしては、

ファイルアップロードして、

/var/log/nginx

の対象のエラーログを確認してみたところ、

発生していたエラーログはこれ。

POST Content-Length o xxx bytes exceeds the limit of xxxx bytes ...

対応内容

最終的に調べた結果としては、

自分が動かしている環境では、

php-fpmの設定を調整する必要がありました。

修正対象ファイル

/etc/php/x.x/php.ini

上記で自分が実行しているバージョンの設定情報ファイルを編集。

コードとしては、

今回はPOSTのサイズ指定で、

許容サイズを広げるために、

post_max_size = 指定サイズ

こちらの設定を変更。

アップロードとかのサイズエラーの際は、

上記の設定ではなくて、

upload_max_filesize = 指定サイズ

こちらの設定なので、

必要であれば合わせて調整。

これで実行すると、

問題なく処理が行われた。

php-fpmの再起動も必要なので、

以下の記事の一部コマンドで再起動を実行。

エラー「Maximum execution time of 30 seconds exceeded」が起きた件

Railsで特定のテーブルを再作成する方法

Railsでアプリケーションを作って、

そのアプリケーションを運営する中で、

現在のテーブルの項目を調整することは、

実際によくあることだと思います。

そんな中で、

既存のカラムを削除する
既存のカラムを変更する
新規のカラムを追加する

という時に、

既存のテーブルに対して、

変更を加えた際に、

rails db:migrate:reset

などを実行してしまうと、

全てのテーブルがクリアされてしまう。

以下の記事の中のコマンドです。

Railsでdb:migrate:resetがうまく動かなかった時の対応メモ

こちらの対応ではなく、

対象のテーブルだけ、

設定情報を反映させることが必要でした。

毎回、調べるのも面倒になってきたので、

設定内容を簡単にメモしておきます。

Railsのマイグレーションの状況確認

まずは、

Railsのマイグレーションで作成したテーブルの、

作成状況をコマンドで確認します。

rails db:migrate:status

のコマンドを実行すると、

$ rails db:migrate:status
Running via Spring preloader in process 428491

database: sample

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20220101000000  Sample1
   up     20220207000000  Sample2
   up     20220207010000  Sample3
   up     20220207020000  Sample4
   up     20220207030000  Sample5
   up     20220208000000  Sample6
   up     20220222010000  Sample7
   up     20220223000000  Sample8

このようにRailsのマイグレーションの状況が表示されます。

こちらを見てわかるように、

Railsの各種テーブルのステータスが「up」の状態である

ということが言えます。

Railsの特定テーブルのみ、テーブルの再作成を実行

先ほどのテーブルの一覧に対して、

特定テーブルのみ再作成するためには、

指定テーブルを「down」ステータスに変更
指定テーブルを再度「up」ステータスに変更

という手順で対応します。

先ほど、ステータスの状況を確認した中で、

$ rails db:migrate:status
Running via Spring preloader in process 428491

database: sample

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20220101000000  Sample1
　　　　　　　　↑ ↑
　　　　　　これが対象のID

この「Migration ID」の表示部分が、

対象のIDになるので、

以下のそれぞれのコマンドで、

ステータスを「down」「up」に変更します。

ステータスを「down」に変更（Migration ID指定）

rails db:migrate:down VERSION=ここにMigrationIDを指定

ステータスを「up」に変更（Migration ID指定）

rails db:migrate:up VERSION=ここにMigrationIDを指定

実際に試してみる

先ほどのマイグレーションの状況確認で、

$ rails db:migrate:status
Running via Spring preloader in process 428491

database: sample

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20220101000000  Sample1
　　　　　　　　↑ ↑
　　　　　　これが対象のID

こちらのテーブルを対象にして、

テーブルの再作成を行なってみます。

Migration IDが、

20220101000000

というIDになるので、

ステータスを「down」に変更（Migration ID指定）

rails db:migrate:down VERSION=20220101000000

こちらを実行すると、

$ rails db:migrate:down VERSION=20220101000000
Running via Spring preloader in process 428540
== 20220101000000 Sample1: reverting ====================================
-- drop_table("sample1", {:id=>:integer, :options=>"ENGINE=InnoDB DEFAULT 
CHARSET=utf8mb4", :force=>:cascade})
   -> 0.0844s
== 20220101000000 Sample1: reverted (0.0889s) ===========================

このように処理が完了しました。

この状態で、

ステータスを再度、確認してみます。

$ rails db:migrate:status
Running via Spring preloader in process 428491

database: sample

 Status   Migration ID    Migration Name
--------------------------------------------------
  down    20220101000000  Sample1
 　↑ ↑
　ステータスが変更された

うまく、ステータスが「down」になっています。

次に、ステータスを元に戻します。

ステータスを「up」に変更（Migration ID指定）

rails db:migrate:up VERSION=20220101000000

こちらを実行すると、

$ rails db:migrate:up VERSION=20220228000000
Running via Spring preloader in process 428561
== 20220228000000 Sample1: migrating ====================================
-- create_table("sample1", {:id=>:integer, 
:options=>"ENGINE=InnoDB DEFAULT CHARSET=utf8mb4", :force=>:cascade})
   -> 0.1593s
== 20220228000000 Sample1: migrated (0.1596s) ===========================

このように、

処理が完了しました。

最後にステータスが、

「up」の状態に戻ったことを確認します。

$ rails db:migrate:status
Running via Spring preloader in process 428491

database: sample

 Status   Migration ID    Migration Name
--------------------------------------------------
   up    20220101000000  Sample1
 　↑ ↑
　ステータスが変更された

ステータスが「up」になったので、

変更対象のテーブルの定義を確認したら、

問題なくテーブル定義も変わっており、

対象テーブルのみ再作成が完了しました。

LaravelのMySQLでテーブル作成時に「Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535.」のエラー発生

MySQLのデータベース移行など、

例えば、

Laravelで別のデータベースから同じテーブルカラムのテーブルにデータを移行した件

などを行った時など、

Laravelのマイグレーションなどにおいて、

問題が起きることがあります。

そんな中で、

Syntax error or access violation: 1118 Row size too large.
The maximum row size for the used table type, not counting BLOBs, is 65535.

というエラーが起きることがあったので、

その時の対応内容などをメモ。

Laravelのマイグレーションの公式ドキュメント

まずは関連する公式ドキュメント。

何かあればこちらのLaravelのドキュメントを参照してもらうと、

各バージョンに沿った情報も載っているので、

最初に確認していくと良いですね。

Laravelの「Database: Migrations」ドキュメント

LaravelのMySQLで使用したバージョン確認

mysqlのコマンドラインで確認

mysql -V

実行結果

$  mysql -V
mysql  Ver 8.0.31-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

LaravelのMySQL実行内容とエラー

Laravelでマイグレーションを実施。

その際、以下のエラーが発生。

SQLSTATE[42000]: Syntax error or access violation: 
1118 Row size too large. 
The maximum row size for the used table type, 
not counting BLOBs, is 65535.
This includes storage overhead, 
check the manual. 
You have to change some columns to TEXT or BLOBs (SQL:
　:

こちらのエラーが発生して、

大きなエラー内容としては、

The maximum row size for the used table type

というところで、

１つのテーブルに対して、

１行のデータレコードのデータのサイズが大きすぎることが原因。

今回は、いろいろとたくさんのデータを、

テーブルを正規化せずにテストデータ作ろうとしたことが問題だった。

LaravelのMySQLエラー対応

エラー対応としては、

テーブルを正規化してカラム数を減らす
カラムの型をStringなどの大きなサイズは小さくする

などを対応して、

１つのテーブルの１行のサイズを小さくする。

これを実施すると、

うまく処理が通るようになった。

【独自テーマ】WordPressのパーマリンク設定が「投稿名」の場合に個別ページが404エラーになる件

WordPressを使う中で、

カスタムのテーマを作って、

そのテーマで作り込むことがある。

その際の初期設定に関して、

ミスして４０４エラーが発生したので、

その時の対応をメモ。

発生した個別ページの４０４エラー表示

管理画面などは問題なく表示され、

各種動作なども問題なかったのですが、

実際の個別ページを見たときに、

このように、

４０４エラーが発生しました。

パーマリンクの設定でエラー状況が異なる

WordPressの設定としては、

パーマリンクの設定を

このように、

「基本」

の設定にしていると、

個別ページの表示自体は問題ありませんでした。

しかし、

パーマリンクの設定を

このように、

「投稿名」

の設定に変更すると、

個別ページの表示が４０４エラーになってしまいました。

エラーログを確認すると、フォルダパスがおかしい

WordPressのインストールフォルダとしては、

/var/wwww/wordpress

というフォルダに

WordPressをインストールした状態で、

https://...../hello-world/

のURL自体が、

エラーログでパスがないというエラーになっていました。

Nginxの設定を見直し

先ほどのエラーログを確認して、

パス設定時のファイル読み込みURL周りで、

今まで別の環境で動かしていたものと比較した時に、

設定漏れがあったので見つけました。

  location / {
    index index.php;
    try_files $uri $uri/ /index.php?$args;　← これ
  }

Nginxのlocationの設定で、

デフォルトルートの設定の中に、

try_files $uri $uri/ /index.php?$args;

が漏れていたことが、

今回の個別ページの表示が、

「投稿名」に設定すると、

４０４エラーになってしまう原因でした。

Next.js でprocess.envで環境値を設定して使う方法

Nextで実装していたときに、

各種APIのURLなど、

設定値の情報などを、

環境設定値として使いたいことがあります。

実際の値としては、

画像ファイルのパス
APIのURL

など、

各ページのコードに書くよりは、

共通で管理できると便利なことはよくあります。

今回は、

こちらの設定情報を、

process.env.xxxxx

という形で扱う方法をメモしておきます。

参考にした公式サイトの情報

こちらのサイトを参考にしました。

リンクをメモ。

Next.jsの公式サイト「Environment Variables」

Next.jsの「next.config.js」に設定情報を追加

実際に設定ファイルに追加していきます。

設定ファイルとしては、

以下のファイルを変更します。

next.config.js

変更内容としては、

const nextConfig = {
   :
  env: {
    プロパティ: 値,
  },
}

という形で、

キーとなる値の「プロパティ」
実際の設定情報を持つ「値」

の２つを設定します。

具体的には、

module.exports = {
  env: {
    customKey: 'my-value',
  },
}

このように、

実際のプロパティと値を指定して、

自分なりの情報を設定します。

設定した値を各ページ側で取得する方法

先ほどの設定例として、

module.exports = {
  env: {
    customKey: 'my-value',
  },
}

こちらの設定情報を見ていくと、

「プロパティ」として「customKey」
「値」として「my-value」

という値を設定しました。

こちらをページ側で取得するには、

process.env.customKey

という形で、

実際のプロパティの値を取得できます。

設定値の変更時は、Next.jsの再起動も忘れなく

環境変数を、

next.config.jsに設定または変更した際は、

Next.jsアプリ自体の再起動もお忘れなく。

Railsを起動するときの初期ポートとポート番号変更方法

Railsでアプリケーションを作って、

そのアプリケーションを起動する際に、

基本的には、初期設定のポートで問題はないと思います。

しかし、

他のFWを同じサーバーで動かす
Railsを複数起動させる

という時に、

同じポートを使っていると、

 A server is already running.

のようなエラーが起きて、

既に実行しているので起動できない状態になります。

このような時に、

ポート番号を重複しないように、

ポート番号を指定して、Railsを起動する

という対応をとることで、

意図したポート番号でRailsを起動させることができます。

個人的によく使う設定ですが、

個人的によく使うものについて、

毎回、調べるのも面倒になってきたので、

設定内容を簡単にメモしておきます。

Railsのデフォルトポート番号

Railsを起動するために、

rails s

のコマンドを実行すると、

$ rails s
=> Booting Puma
=> Rails 6.1.4.4 application starting in development
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
  :
  :
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop

このようにRailsが起動します。

こちらを見てわかるように、

Railsのデフォルトのポート番号は「3000」

ということが言えます。

Railsのポート番号を起動時に指定する方法

先ほどのデフォルトのポート番号は、

rails s

のコマンドで実行すると、

デフォルトの「3000」になってしまうので、

コマンド実行時にオプションを設定します。

オプション設定の一覧

rails s --help

上記で確認した結果で、

今回のポート指定部分だけを抜粋。

  rails server -u [thin/puma/webrick] [options]

Options:
  -p, [--port=port]                            
# Runs Rails on the specified port - defaults to 3000.

こちらを確認しても、

デフォルトでポート番号は「3000」を使用していることがわかりますね。

上記のオプション設定を参考に、

rails s -p=7777

このように設定してみましょう。

実行してみると、

$ rails s -p=7777
=> Booting Puma
=> Rails 6.1.4.4 application starting in development
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
  :
  :
* Listening on http://127.0.0.1:7777
* Listening on http://[::1]:7777
Use Ctrl-C to stop

このように、

ポート番号が「7777」に変更されています。

Nginxの再リロード時に「conflicting server name」が発生した件

Nginxで各種ドメインを設定して、

Webサーバーを管理していく中で、

時々、設定内容などをミスして、

エラーではまってしまうことはあります。

そんなNginxの設定に関して、

今回、

conflicting server name

の内容でエラーが発生して、

ちょっと状況を確認して、

対応していたので、

その時のメモを残します。

エラー内容

状況としては、

設定していたドメインを書き換えて、

sudo nginx -s reload

という形で、

Nginxの再リロードを行った。

その際、以下のエラーが発生。

nginx: [warn] conflicting server name "xxxxx.xxxx" on 0.0.0.0:80, ignored

表示内容としては、

サーバー名設定で、

コンフリクトのエラーなので、

既に設定情報がどこかにある模様。

対応内容

自分の設定状況としては、

今回、調整で変更していた中で、

シンプルに

server  {
  :
}
server  {
  :
}

という感じで、

設定情報を持ってきて使う時に、

同じ情報がコメントアウトしたつもりで、

そのまま残っていたのが原因。

こちらを調整して、

sudo nginx -s reload

で再リロードかけたら上手くNginxの再リロードが完了。

【独自テーマ】WordPressで独自テーマを作るための最低限の初期設定

WordPressを使う中で、

カスタムのテーマを作って、

そのテーマで作り込むことがある。

その際の初期設定に関して、

よく忘れることがあるので、

この対応をメモ。

テーマ用のフォルダを作成

WordPressをインストールしたフォルダで、

大きなファイルに関して、

圧縮してのことしておきたいということが、

大きなデータベースファイルについて、

dumpファイルなどを作った時によく起こります。

このLinuxでのtarコマンドでの圧縮・解凍について、

Npmのパッケージ管理をよく使っている。

そんな中で、

パッケージで使っているライブラリのバージョンなど、

現時点の情報を確認する方法など、

自分自身でよく使うけど、よく忘れるのでメモ。

Linuxでのtarコマンドのオプション確認

対象フォルダ

./wp-content/theme

ディレクトリ作成

mkdir new-theme

「index.php」を準備

先程のテーマ用に作ったフォルダ

new-theme

の中に、

index.php

を作成する。

<?php get_header(); ?>

<?php get_footer(); ?>

「style.css」を作成する

先程のテーマ用に作ったフォルダ

new-theme

の中に、

style.css

を作成する。

/*
Theme Name: new-theme
Theme URI: http://new-theme.com
Author: sample author
Author URI: http://sample.com/
Description: Custom new theme
Version: 1.0
*/

「functions.php」を作成する

先程のテーマ用に作ったフォルダ

new-theme

の中に、

funtions.php

を作成する。

注意点としては

「function.php」ではなく「functions.php」で「s」を付けること

ということを気をつけること。

よく間違えるポイントです。

コードはミニマムで大丈夫

<?php

Linuxでtarコマンドで圧縮・解凍する方法

Ubuntuの中で、

大きなファイルに関して、

圧縮してのことしておきたいということが、

大きなデータベースファイルについて、

dumpファイルなどを作った時によく起こります。

このLinuxでのtarコマンドでの圧縮・解凍について、

Npmのパッケージ管理をよく使っている。

そんな中で、

パッケージで使っているライブラリのバージョンなど、

現時点の情報を確認する方法など、

自分自身でよく使うけど、よく忘れるのでメモ。

Linuxでのtarコマンドのオプション確認

オプション確認

tar --help

主要部分を抜粋

$ tar --help
-c, --create               create a new archive
-x, --extract, --get       extract files from an archive
-z, --gzip, --gunzip, --ungzip   filter the archive through gzip
-f, --file=ARCHIVE         use archive file or device ARCHIVE
    --force-local          archive file is local even if it has a colon

Linuxでのtarコマンドでの圧縮方法

圧縮コマンド

tar -zcvf xxxx.tar.gz directory

Linuxでのtarコマンドでの解凍方法

解凍コマンド

tar -zxvf xxxx.tar.gz

Slack APIを試した時に確認したサイトなどのメモ

SlackのAPIを使っていく中で、

もう少し、Slackを便利に使いたい

ということを思い始めて、

Slack APIを使うことで、

もう少し、業務でも便利に使えないか、

調べながら試した。

試して、作る中で、

調べながら、

挙動を確認して、

問題なく使えそうだったので、

実際の業務でも使っている。

その内容に関して、

「チャンネルID」

を必要とすることが出てきました。

この点に関して、

公式サイトのリンクなどを、

この記事にメモとして残しておきます。

忘れないうちにリンク等をメモしていくので、

コードなどは、必要に応じて、

別記事にまとめていくかもしれません。

Slack APIの公式ドキュメント

Slack APIに関しては、

公式サイトに情報がたくさんあるので、

まずはそちらをチェックするのが良い。

Slack APIの公式ドキュメント

Slack APIのSocket Modeのドキュメント

Slack APIを使用する際に、

Socket Mode（ソケットモード）の設定で、

ライブラリや処理を行ったので、

その時の参考に読んだ公式ドキュメント。

Slack APIのSocket Modeのドキュメント

Slack APIを使用するために使ったライブラリ（Bolt）

Slack APIを使っていく中で、

便利なライブラリを探したら、

Bolt

が用意されていて、

公式ドキュメントと併せて確認することで、

実際に処理が実装できたので、

このライブラリ「Bolt」の確認ページ。

Slack APIのライブラリ「Bolt」のドキュメント

必要なことがあります。

例えば、

以下のようなAPI活用の場面などですね。

https://api.slack.com/methods/files.upload/code

Slack APIで表示させるブロックを決めるためのUI Kit

Slack APIで、

処理のトリガーをもとに、

ボタン等のブロックを表示するのだが、

そのブロックがどのようなものがあるのか、

それをコードにするとどうなるのか、

この辺りについては、

「Block Kit Builder」

のページを確認することで、

UIブロックとコードが確認できます。

Block Kit Builderのページ

SlackのチャンネルIDの確認方法

SlackのAPIを使っていく中で、

Slack APIを使って処理を試す

などのように、

「チャンネルID」

を必要とすることが出てきました。

この点に関して、

確認方法をよく忘れるので、

この記事にメモとして残しておきます。

SlackのチャンネルIDを必要とする場面

Slackを使っていて、

もう少し便利に使いたいと思った時に、

Slack APIを活用することで、

便利に使うことができます。

このSlack APIに関しては、

便利に使うのですが、

設定項目として、

「チャンネルID」

がコードの中で、

channels=channel_id,

のように

必要なことがあります。

例えば、

以下のようなAPI活用の場面などですね。

https://api.slack.com/methods/files.upload/code

SlackのチェンネルIDの確認方法

SlackのチャンネルIDを

実際に確認する方法はシンプルです。

まずは、

自分が調べたいチャンネルを選択。

選択したチャンネルの上部に、

チャンネル名が表示されているので、

その部分をクリック。

クリックすると、

以下のような表示が行われます。

上記の中の、

最下部の赤枠部分に表示されるのが、

Slack API で活用するための、

「チャンネルID」

なので、

この設定情報を必要に応じて使いましょう。

このように、

「設定」

のタブをクリックして、

その中の

「このチャンネルを削除する」

をクリックする。

削除確認のチェックをつけて削除を実施

チャンネルの削除に関して、

上記の表示で、

「このチャンネルを削除する」

を押すと、

削除確認のモーダルが表示される。

この画面で、

このようにチェックボックスにチェックを入れて、

「このチャンネルを削除する」

を押すと実際にチャンネルが削除されます。

Rubyの日付処理で今日や過去日のデータの扱い方法

Rubyで処理を作っていく中で、

日付を扱うことはよくあります。

そんな日付周りの処理の中で、

個人的によく使うものについて、

毎回、調べるのも面倒になってきたので、

使うものをメモしていきます。

日付を扱うクラス

Rubyでは、

Date

というクラスが用意されているので、

このクラスを使います。

日付で今日（当日）を扱う

日付を扱う中で、当日を扱うなら、

todayメソッドがあるので、

このメソッドを使用。

d = Date.today

日付で特定日(Y-m-d形式)を扱う

日付を扱う中で、

日付形式の「Y-m-d」を扱うことがあります。

「2022-01-01」や「2022-03-03」など、

こちらをDateクラスを使うときは、

この「parse」メソッドを使用。

d = Date.parse('2022-01-01')

Dateクラスをフォーマットを指定

Dateクラスを使って、

対象の日付に対して、

その日付をフォーマット化するには、

以下のように、

strftimeメソッドがあるので、

このメソッドを使用。

d = Date.today
today = d.strftime("%Y-%m-%d")

BitbucketでSSH鍵認証のキーフレーズを忘れた件

Bitbucketを日頃から個人的に使っていたのだが、

SSHの鍵認証を対応していたのだが、

ある日、しばらく使っていなかったので、

パスフレーズを忘れてしまう事態が発生。

どうしたものかと思ったが、

対応自体はシンプルだったので、

その時の対応したことをメモ。

BitbucketのSSHの鍵認証の設定

BitbucketでのSSHの鍵認証に関しては、

以前、こちらの記事に書いた内容で、

鍵情報の作成やBitbucketへの設定を行った。

その時の基本的な設定の流れは、

以下の記事を参照してもらいたい。

BitbucketでGit Pushしようとしたら、Permission deniedのエラーが発生した件

キー情報とパスフレーズの再設定

状況としては、

id_rsa
id_rsa.pub

で作成された情報のパスフレーズがわからないので、

対応自体は、

鍵ファイルの再作成
作成時にパスフレーズを設定（忘れないようにメモ）

ということを行う。

事前に鍵情報のファイルの、

id_rsa
id_rsa.pub

は削除している。

まずは、鍵ファイルの再作成

ssh-keygen

を実行すると、

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/user/.ssh/id_rsa):

となるので、

最初は空でEnterキー（id_rsaで作成）。

その後にパスフレーズを求められるので、

設定したいパスフレーズを設定・再確認を入力。

これで鍵情報の再作成は完了。

あとは、

再作成した鍵情報の値を、

Bitbucketの設定画面の方で設定する。

設定としては、

id_rsa.pubの値をBitbucketに鍵情報として設定

を行うことになる。

設定方法自体は、以下の記事を参照。

BitbucketでGit Pushしようとしたら、Permission deniedのエラーが発生した件

HTML/CSSでheadタグに設定する項目をよく忘れるのでメモ

HTML/CSSでレイアウトを作っていく中で、

headタグについては、

よく使うけれど、

同じ項目を設定する割には、

設定する値をよく忘れて、

毎回、調べることになっているので、

忘れてしまった時のために、

よく使う設定をメモ。

その時の内容と、

記述する場所

文書情報を記述する場所は、

HTMLファイル内の中にある「headタグ」で囲まれた範囲に記載します。

<!DOCTYPE html> 
<html>
  <head>
    <!-- headタグ内のここから　
            :
         headタグ内のここまで　-->
  </head>
  <body>
    Simple Html
  </body>
</html>

上記にコメントで記載している、

headタグで囲まれた中に記載していきます。

必要に応じて、

ここに記載を追加していきましょう

ページタイトルの設定方法

ページタイトルはheadタグ内にtitleタグを使用して設定します。

<!DOCTYPE html> 
<html>
  <head>
    <!-- タイトルに「学ぶパンダ」と設定する例 -->
    <title>学ぶパンダ</title>
  </head>
  <body>
    Simple Html
  </body>
</html>

実際の追加タグ部分だけは、

以下をコピー。

<title>学ぶパンダ</title>

Faviconの設定方法

Faviconはheadタグ内にlinkタグを使用して設定します。

<!DOCTYPE html> 
<html>
  <head>
    <!-- Favicon（ファビコン）を設定する例 -->
    <link rel="shortcut icon" href="/img/favicon.png">
  </head>
  <body>
    Simple Html
  </body>
</html>

実際の追加タグ部分だけは、

以下をコピー。

<link rel="shortcut icon" href="/img/favicon.png">

LaravelでCSVアップロード時に「local.ERROR: fgetcsv(): Argument #2 ($length) must be of type ?int, string given {“exception”:”[object]」のエラー時のメモ

Laravelを使っていて、

CSVのファイルアップロードをしていた。

この処理自体は、

Laravelの古いバージョンでも使用しており、

何か変わったのかなと思って、

調査して、とりあえずの対策を行った。

その時の内容と、

エラー内容

エラーとしては、

ファイルアップロードして、

 fgetcsv($fp, ",")

で処理を行っている部分で、

エラーが発生していた。

そのエラーログはこれ。

local.ERROR: fgetcsv(): Argument #2 ($length) 
must be of type ?int, string given {"exception":"[object]

対応内容

最終的に調べた結果としては、

PHPのバージョン違いで、

引数の設定が変わっているかと思われる（たぶん）。

上記が確認時のfgetcsvのドキュメント。

こちらを参考に、

コードを以下のように調整。

fgetcsv($fp, 0, ",")

これで実行すると、

問題なく処理が行われた。

【GoogleAppsScript】各種実行中の処理を確認、終了する方法

Google Apps Scriptで、

各種処理を作っていく中で、

実行中の処理がわからなくなったけど、
どうやって確認して、終了させれば良いのかな…

ということが疑問になり、

「実行中の処理はどうやって止めたら良いのか」

という点を調べたので、

この点をメモとして残しておく。

スクリプト実行の状態がわからなくなる

Google Apps Scriptで、

メニューに処理を追加して、

このような形で、

スクリプトを実行していたりすると、

処理を動かして放置すると、

処理自体が終わったのか、

十国中で終わったのかわかないことがありました。

わからなくなることとしては、

処理が長いスクリプトの実行/終了
無限ループで処理が継続しているもの

みたいなことです。

この辺りを確認できる方法が、

Google Apps Scriptには用意されていたので、

そちらで確認するようになりました。

Apps Scriptダッシュボードで実行状況を確認

Apps Scriptの実行状況の確認方法について、

調べていくと、

「Apps Scriptダッシュボート」
と呼ばれるものがあるので、
それで確認すると楽

ということがわかりました。

この「Apps Scriptダッシュボード」については、

このように、

画面が用意されています。

まずは、そのページのリンク。

Apps Scriptダッシュボード（実行履歴）

上記のページを開くと、

このような、

Apps Scriptの実行履歴が表示されます。

実行履歴としては、

このような実行履歴が、

一覧として表示されます。

実行状況の確認と処理の終了方法

上記のリストで、

このように、

ステータスとして、

実行状況が表示されています。

もし、

この部分が「実行中」の表示であれば、

マウスカーソルを当てると、

三点のアイコンがあるので、

そちらが表示されます。

こちらをクリックすることで、

このようにメニューが表示され、

一番上の「終了」をクリックすることで、

実行中のApps Scriptの終了が可能です。

参考リンクまとめ

Apps Scriptダッシュボードは、

自分自身のGoogle アカウントにログインしている状態で、

以下のリンクに遷移してもらえると、

表示されるので、

アカウントのログイン状況は確認してください。

Apps Scriptダッシュボードについて

Apps Script実行履歴

RailsのMySQLへのレコード追加で「ActiveRecord::StatementInvalid (Mysql2::Error: Incorrect string value」が発生した件

RailsのデータベースでMySQLを使用して、

通常通り処理を行う中で、

「ActiveRecord::StatementInvalid (Mysql2::Error: Incorrect string value」

というエラーが発生した。

あれ、何か変更したかな？

と考えながら色々とデータを確認したら、

😆

などの絵文字が入っていたので、

そちらが登録するときに、

エラーが発生していた。

今回のエラー内容と、

対応した内容をメモ。

前提

MySQLの文字コードについては、

MySQLに接続して、

以下のコマンドで状況を確認

SHOW VARIABLES LIKE 'chara%';

確認してみると、

「utf8mb4」

でマルチバイト文字対応している。

mysql> SHOW VARIABLES LIKE 'chara%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8mb4                    |
| character_set_connection | utf8mb4                    |
| character_set_database   | utf8mb4                    |
| character_set_filesystem | binary                     |
| character_set_results    | utf8mb4                    |
| character_set_server     | utf8mb4                    |
| character_set_system     | utf8mb3                    |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

エラー内容

エラーは先ほども説明したが、

対象テーブルへのインサートのタイミングで、

以下のようなエラーが発生していた。

ActiveRecord::StatementInvalid
 (Mysql2::Error: Incorrect string value: '\xF0\x9F\x8C\xBF' 
 for column 'column_name' at row 1):

対応内容

この事象の調整方法としては、

charactor codeを「utf8mb4」に変更する

ということで対応できた。

自分の環境では、

データベースに対しては、

「utf8mb4」

となっているので、

Railsの環境周り、マイグレーションでの作成時に、

「utf8」になっているので、

以下の調整を実施。

修正ファイル

vi config/database.yml

修正内容

default: &default
  adapter: mysql2
  encoding: utf8mb4
  collation: utf8mb4_polish_ci

上記に加えて、

テーブル作成時のcharactor codeの設定も調整

class LazadaGroups ...
  def change
    create_table ...CHARSET=utf8mb4", force: :cascade do |t|

こちらの設定をして、

あとは、

マイグレーションの再実行
サーバー自体の再起動

を実施して、

再度確認するとうまく動いたので完了。

NuxtJSのインストールから起動までの導入方法

Vueを活用する中で、

「NuxtJS」

のフレームワークを使用して、

各種APIを作成するなど、

小さな規模から試そうと考え、

公式サイトを見ながら、

導入して起動するまでを試した。

その時のNuxtJSの導入に関して、

個人的にメモを残す。

参考サイト（公式サイト）

こちらのサイトを参考にしました。

リンクをメモ。

NuxtJSの公式サイト

NuxtJSの導入のコマンド

公式サイトの通りに、

順番にコマンドを実行していく。

導入コマンド

npm init nuxt-app project-name

導入時の設定

プロジェクト名の設定

$ npm init nuxt-app project-name
✨  Generating Nuxt.js project in Office-Management
? Project name: (project-name)　

上記で入力するか、そのままでよければ、何もせず、Enterキーを押す

プログラミング言語の設定

? Programming language: (Use arrow keys)　←JS/TSの選択
❯ JavaScript
  TypeScript

上記で自分が使いたい方を選び、Enterキーを押す

パッケージ管理方法の設定

? Package manager: (Use arrow keys)
❯ Yarn
  Npm

上記で自分が使いたいパッケージ管理方法を選び、Enterキーを押す

UIフレームワークの設定

? UI framework: (Use arrow keys)
❯ None
  Ant Design Vue
  BalmUI
  Bootstrap Vue
  Buefy
  Chakra UI
  Element
  Oruga
  Primevue
  Tachyons
  Tailwind CSS
  Windi CSS
  Vant
  View UI
  Vuetify.js

上記で自分が使いたいUIフレームワークを選び、Enterキーを押す
※何も使用しない場合は「None」を選択

導入モジュールの選択

? Nuxt.js modules: (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◯ Axios - Promise based HTTP client
 ◯ Progressive Web App (PWA)
 ◯ Content - Git-based headless CMS

上記で自分が使いたいモジュールを選び、Enterキーを押す
※選択はSPACEキーで選択/未選択を切り替えます。
※デフォルトはすべて未選択になっています。
※何も使用しない場合はチェックを付けない。

構文チェックツールの選択

? Linting tools: (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◯ ESLint
 ◯ Prettier
 ◯ Lint staged files
 ◯ StyleLint
 ◯ Commitlint

上記で自分が使いたい構文チェックツールを選び、Enterキーを押す
※選択はSPACEキーで選択/未選択を切り替えます。
※デフォルトはすべて未選択になっています。
※何も使用しない場合はチェックを付けない。

テストフレームワークの選択

? Testing framework: (Use arrow keys)
❯ None
  Jest
  AVA
  WebdriverIO
  Nightwatch

上記で自分が使いたいテストフレームワークを選び、Enterキーを押す
※何も使用しない場合は「None」を選択

レンダリング方法を選択

? Rendering mode: (Use arrow keys)
❯ Universal (SSR / SSG)
  Single Page App

上記で自分が行いたいレンダリング方法を選択

デプロイ方法の選択

? Deployment target: (Use arrow keys)
❯ Server (Node.js hosting)
  Static (Static/Jamstack hosting)

上記で自分が行いたいデプロイ方法を選択

開発ツールの選択

? Development tools: (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◯ jsconfig.json (Recommended for VS Code if you're not using typescript)
 ◯ Semantic Pull Requests
 ◯ Dependabot (For auto-updating dependencies, GitHub only)

上記で自分が行いたい開発ツールを選択
※選択はSPACEキーで選択/未選択を切り替えます。
※デフォルトはすべて未選択になっています。
※何も使用しない場合はチェックを付けない。

Githubの設定

? What is your GitHub username? ()

自分が使っているGithubがあれば設定
※何もGithubを使用しない場合はそのままEnterキーを押す。

バージョン管理ツールの選択

? Version control system: (Use arrow keys)
❯ Git
  None

上記で自分が使いたいバージョン管理ツールを選択
※何も使用しない場合は「None」を選択

導入処理の完了

上記の導入設定を行い、

導入処理が完了すると以下の表示になる。

🎉  Successfully created project project-name

  To get started:

	cd project-name
	npm run dev

  To build & start for production:

	cd project-name
	npm run build
	npm run start

起動して表示確認

導入がうまくいったので、

先ほどの導入処理結果に出てきたコマンドで、

実際に起動して表示確認してみる。

フォルダに移動

cd project-name

起動コマンド

npm run dev

実行結果

表示確認URL

http://localhost:3000/

表示確認結果

Npmパッケージ管理でよく使うコマンド一覧

Ubuntuの中で、

サービスを確認していく中で、

Npmのパッケージ管理をよく使っている。

そんな中で、

パッケージで使っているライブラリのバージョンなど、

現時点の情報を確認する方法など、

自分自身でよく使うけど、よく忘れるのでメモ。

Npm自体のバージョン確認

確認コマンド

npm -v

確認結果の例

$ npm -v
8.0.0

Npmパッケージ管理で導入済みのライブラリのバージョン一覧

実際に導入しているライブラリなどが、

バージョンがどうなっているか、

確認したいことが時々起こるので、

その時の確認方法。

コマンド

npm list

確認結果の例

$ npm list
 :
├── react-dom@17.0.2
├── react-dropzone@11.7.1
├── react-router-dom@6.3.0
├── react-scripts@5.0.0
├── react@17.0.2
├── tailwindcss@3.1.6
└── web-vitals@2.1.4

バージョン指定のライブラリのインストール

ライブラリを導入したいけれど、

他のライブラリやミドルウェアなどとの相性で、

自分でバージョン指定して、

インストールを実施したい時の方法。

コマンド

npm install -y library-name@version

PythonでMySQL接続時に「mysql.connector.errors.InterfaceError: sha256_password requires SSL」

MySQLのバージョン確認

mysqlのコマンドラインで確認

mysql -V

実行結果

$  mysql -V
mysql  Ver 8.0.27-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

実行内容とエラー

MySQLでアクセスを実施

import mysql.connector
cnx = mysql.connector.connect(user='user', password='password',
                                host='123.123.123.123')

実行時のエラー

$ python3 test.py
 :
raise errors.InterfaceError("{name} requires SSL".format(
mysql.connector.errors.InterfaceError: sha256_password requires SSL

エラー内容と対応

エラー内容としては、

raise errors.InterfaceError("{name} requires SSL".format(
mysql.connector.errors.InterfaceError: sha256_password requires SSL

というエラーログがあり、

sha256のパスワードでSSLが必要とのこと。

この点を公式の内容で確認してみたら、

実際に記述がありました。

公式サイトのページ

MySQLの「7.1 Connector/Python Connection Arguments」

公式サイトの一部抜粋

公式サイトの文章をメモ

Connector/Python supports authentication plugins available as of MySQL 5.6. 
This includes mysql_clear_password and sha256_password, 
both of which require an SSL connection. 
The sha256_password plugin does not work over a non-SSL connection 
because Connector/Python does not support RSA encryption.

The connect() method supports an auth_plugin argument 
that can be used to force use of a particular plugin. 
For example, 
if the server is configured to use sha256_password by default 
and you want to connect to an account that authenticates using mysql_native_password, 
either connect using SSL or specify auth_plugin='mysql_native_password'.

このようになっているので、

auth_plugin='mysql_native_password'

をオプションにつけてやることで、

うまく実行ができるようになる。

Ubuntuのsystemctlでサービスの起動/終了

Ubuntuの中で、

サービスを確認していく中で、

php-fpmの起動がうまくいっておらず、

うまくパッケージインストールができない事象が発生していた。

その時に、

systemctlのコマンドで、

調整した時の内容をメモ。

個人メモ：動かした時のコマンド

動かした時のコマンド

$ systemctl | grep php8.0
ここの結果で状況確認
$ sudo systemctl stop php8.0-fpm.service
これで停止
$ systemctl disable php8.0-fpm.service
無効化
$ systemctl daemon-reload
サービス設定のリロード

systemctlの特定のサービス状況を確認

systemctlで一覧を出すと、

多すぎて自分の探したい対象がわからないので、

パイプラインでgrepをかけて検索。

$ systemctl | grep php8.1
  php8.1-fpm.service   loaded active running   The PHP 8.1 FastCGI Process Manager

サービスの起動、停止、再起動

今回は停止のみ行ったが、

起動と再起動もあるので、

状況によって使い分ける。

起動コマンド

sudo systemctl start php8.0-fpm.service

停止コマンド

sudo systemctl stop php8.0-fpm.service

再起動コマンド

sudo systemctl disable php8.0-fpm.service

サービスの有効、無効

今回は無効化のみ行ったが、

有効にすることもできるのでメモ。

有効化コマンド

sudo systemctl enable php8.0-fpm.service

停止コマンド

sudo systemctl disable php8.0-fpm.service

再起動コマンド

sudo systemctl disable php8.0-fpm.service

設定（有効、無効）の設定のリロード

設定のリロードのコマンド

sudo systemctl daemon-reload

【翻訳機能】DeepLのAPIをPythonで簡易に試してみた

翻訳機能としてのサービスとして、

DeepL（ディープエル）

というサービスがあります。

Googleの翻訳機能についても、

APIがありますが、

関わっている方から、

こちらの方を使いたいという要望があり、

実際にAPIを試しに使うことになりました。

このAPIを試した時のメモ、

そして内容を自分なりに整理するために、

こちらの記事を残しておくので、

誰かの参考になれば幸いです。

DeepLのユーザー作成

DeepLの公式サイトを確認して、

大きく分けると、

通常のDeepLを使うためのプラン分類
APIを使うためのプラン分類

の２つに分かれますが、

この中の、

APIの分類の方で、

その中で無料版のプランを作成しました。

作成などの概要については、

以下の記事に記載したので、

参考にしてください。

【翻訳機能】DeepLのAPIのための無料ユーザーの作成

DeepLのAPIの仕様を確認

DeepLのAPIに関しては、

「技術資料」

として、

APIの仕様がまとめられています。

公式サイトから、

このように、

メニューの「API」の中の、

「技術資料を読む」

を見てもらうと、

APIのリファレンスが表示されます。

ページとしては、

このような表示の中で、

左側にAPIの各種目次が表示されます。

DeepLのClient Library

今回、DeepLのAPIを試す中で、

Clientのライブラリ

があるので、

そちらを試しました。

上記のDeepLの技術資料のリファレンスの中に、

この「Client Libraries」を選びます。

内容部分が表示され、

このように、

各プログラミング言語に対応したライブラリの説明があります。

この中の「Python」のライブラリを試しました。

Pythonのライブラリを試す

今回試すのは、

Pythonのライブラリなので、

Githubの内容を確認しながら進めました。

PIPで「deepl-python」をインストール。

コマンド

pip install --upgrade deepl

こちらのコマンドでインストールしたら、

実際にコードを書いて動きを確認します。

試すコードのサンプルについても、

Githubに記載があるので、

そちらをそのまま使って試します。

コード

import deepl

auth_key = "ここにはご自身のAuthentication Keyを設定"  # Replace with your key
translator = deepl.Translator(auth_key)

result = translator.translate_text("Hello, world!", target_lang="FR")
print(result.text)  # "Bonjour, le monde !"

これを実行すると、

$ python3 test.py
Bonjour, le monde !

このように、

うまく翻訳されていることがわかります。

日本語でもうまくいくのか、

ちょっとコードを変えて試してみましょう。

コードの内容を少し書き換えて、

import deepl

auth_key = "ここにはご自身のAuthentication Keyを設定"  # Replace with your key
translator = deepl.Translator(auth_key)

result = translator.translate_text("I like programming.", target_lang="JA")
print(result.text)

このように変更してから、

実行してみると

$ python3 test.py
プログラミングが好きなんです。

DeepLの翻訳で、

「I like programming.」

という英文が、

「プログラミングが好きなんです。」

という日本語の文章に、

うまく翻訳されていました。

今回は、

サンプルコードを使いながら、

実際にPythonで試すことをやっていきました。

DeepLには用語集などの機能もあるので、

それらも気になる方は試してみると良いでしょう。

DeepLのPythonのClient LibraryのGithub

【翻訳機能】DeepLのAPIのための無料ユーザーの作成

翻訳機能としてのサービスとして、

DeepL（ディープエル）

というサービスがあります。

Googleの翻訳機能についても、

APIがありますが、

関わっている方から、

こちらの方を使いたいという要望があり、

実際にAPIを試しに使うことになりました。

このAPIを試した時のメモ、

そして内容を自分なりに整理するために、

こちらの記事を残しておくので、

誰かの参考になれば幸いです。

DeepLの公式サイト

DeepLについては、

「ディープエル」

と読むことを教えてもらい、

それまでは、

「ディープル」

と読んでましたが、

恥ずかしい限りでしたが、

読み方は大切かと思うので、

その点も把握してもらえると良いかと。

そんな、DeepLというサービスの公式サイトは、

以下のリンク先になっているので、

まずは、公式サイトをチェックしてみましょう。

DeepLのサイト

DeepLのプランに関して

DeepLのプランに関しては、

プランの内容がそれぞれ分かれており、

通常のDeepLを使うためのプラン分類
APIを使うためのプラン分類

という形で、

２つのプラン分類に分かれています。

そして、

それぞれの中で、

プランが複数に分かれている点が、

DeepLのプランの分かれ方になっているので、

その点をまずは把握してもらうと良いですね。

通常のプラン分類

一般的なプランについては、

自分が確認した時点では、

４つに分類されており、

内容部分だけみると、

このように、

ファイル指定で翻訳できる上限のファイル数
用語集を作れる数や登録できるペア数

という点が、

それぞれのプランで違うようです。

実際の最新のプランの違いは、

公式サイトでチェックしてもらうと良いですが、

ちょっと翻訳を試すくらいであれば、

無料プランのユーザーで良いと思います。

APIのプラン分類

APIのプランについては、

２つのプランに分かれており、

無料版
有料版

という分類で考えると、

わかりやすい分類かなと思います。

それぞれのプランの違いを見ると、

このように、

翻訳できる文字数の制限
処理リクエストの処理の優先度

という点が、

違いとしてありますね。

今回、自分は無料プランで試しましたが、

有料プランは、使った分ごとに「従量課金」される

という点については、

本格的に有料プランでやるときは、

注意しておいた方が良いと思います。

APIのプランのユーザー登録

DeepLのAPIを試すにあたって、

アカウントを作る必要があるので、

まずはメニューの中から、

「API」というメニューがあるので、

こちらのページを表示させます。

表示させると、

APIの内容について、

色々と説明がありますが、

今回、自分が試すときは、

無料プランで十分なので、

こちらの方のプランを使うので、

上記など、

「無料で登録する」

のプランから登録を進めました。

登録自体は、

こちらの設定のページになり、

アカウント情報として、

ログインのための「メールアドレス」
ログインのための「パスワード」

がまずは登録が必要です。

そして、

この次のページで、詳細画面は省略しますが、

クレジット情報（無料プランでも登録がいるようでした）

の登録が必要みたいで、

無料プランを使うために設定して進めました。

この登録まで完了すれば、

APIを使うためのユーザー作成が完了です。

APIの仕様確認と実行確認

DeepLのAPIに関して、

については、

実際に自分が試すにあたって、

仕様として把握したこと
簡易に試したこと

という点について、

その時に見たページや注意点など、

必要そうであれば、

そちらについても、

追って記事にしようかと思います。

【エラー】Docker内で立ち上げたサーバーのアクセスで「Empty reply from server」が発生した件

Dockerの立ち上げに関しては、

Dockerfileというファイルを作成する
ビルドしてDockerイメージを作成する
Dockerイメージからコンテナを作成する
コンテナに接続してログインする

という手順を行って、

上記をやってみたあとに、

Dockerのイメージの確認
Dockerのコンテナの確認
Dockerのコンテナの停止と削除

などを行っていました。

これらを行う中で、

Dockerの中で立ち上げたサーバーにアクセスする際に、

「Empty reply from server」

が発生したので個人的にメモ。

Dockerの基本操作

Dockerfileなどを作るなどの基本操作に関しては、

以下にまとめているので、参照してください。

Sending messages using Incoming Webhooks

今回の事象が起きた環境構成

環境としては、

サーバ（Dockerの外）はNginxで起動
Nginxではproxyでポート指定（8080）
Dockerの中では、ポート指定（10000）で起動

という形でサーバを動かしていました。

ちなみに、

Dockerの状況を確認すると以下の状況でした。

確認コマンド

docker ps

確認結果

$ docker ps
CONTAINER  .... PORTS                                        NAMES
111        .... 0.0.0.0:8080->10000/tcp, :::8080->10000/tcp  test

エラー内容

エラー内容としては、

サーバーの中（Dockerの外）から、

curlコマンドで実行を確認すると、

確認コマンド

curl -l http://localhost:8080/test

確認結果

$ curl -l http://localhost:8080/test
curl: (52) Empty reply from server

という感じで、

「Empty reply from server」

というエラーが発生しました。

Dockerの中で、

「10000」というポートで立ち上げたサーバーの中で、

このポートにアクセスできるか確認すると、

$ curl -l http://localhost:10000/test
test　←これは検証で試した返却値

という形で、

問題なくレスポンスが返却されていました。

対応方法

解決方法としては、

Docker内で起動しているサーバーのホスト名を、

「localhost」ではなく「0.0.0.0」

に変更するとうまく動作しました。

Dockerの外から、

$ curl -l http://localhost:8080/test
curl: (52) Empty reply from server

というエラーになっていたものが、

$ curl -l http://localhost:10000/test
curl: (52) Empty reply from server

というレスポンスになっているので、

うまく挙動していることが確認できました。

Slackのチャンネルの削除方法

Slackのチャンネルを管理していく中で、

不要なチャンネルが増えていくことが、

ちょっとした社内で問題になった。

その際に、

Slackのチャンネルを消す方法を、

実際に試した時のメモ。

Slackのチャンネルを選択

まずは、

削除したいチャンネルを選択する。

選択したチャンネルが、

丈夫に表示されている状態。

Slackのチェンネルの設定から削除を押下

上記のチャンネルをクリックすると、

設定のモーダル画面が開くので、

このように、

「設定」

のタブをクリックして、

その中の

「このチャンネルを削除する」

をクリックする。

削除確認のチェックをつけて削除を実施

チャンネルの削除に関して、

上記の表示で、

「このチャンネルを削除する」

を押すと、

削除確認のモーダルが表示される。

この画面で、

このようにチェックボックスにチェックを入れて、

「このチャンネルを削除する」

を押すと実際にチャンネルが削除されます。

Slackのwebhookの設定方法

Slackのwebhookを使用する際に、

管理ページから設定を変更していく。

この変更箇所が、

いつも同じであるが、

よく忘れやすいので、自分用にメモを残す。

公式サイト

Slackのwebhook

管理しているワークスペースに移動

上記の公式サイトのページとして、

このようなページになっているので、

メニューの右側の「Your apps」で、

このように、

自分が使っているワークスペースを選択。

Slackの「Incoming Webhooks」

自分の管理しているワークスペースを開いたら、

左側に表示されるメニューの中で、

このように、

「Incoming Webhooks」

を選択する。

チャンネルの設定と許可

上記の

「Incoming Webhooks」

の中で、

このようなリストがあるので、

このリストの下に、

というボタンがあります。

このボタンをクリックすることで、

チャンネルの設定に進み、

このように、

チャンネルを設定する箇所と、

「許可する」のボタンで設定を進めると完了です。

上記を使ったLaravelでのSlack通知

こちらのSlackの設定を行って、

実際のLaravelでの通知処理の実装をしたのだが、

その時のポイントは、

以下の記事に記載しています。

LaravelからSlack通知の基本

エラー「Cannot truncate a table referenced in a foreign key constraint」が起きた件

MySQLで、

テーブルデータを綺麗にするために、

「truncate」

の構文を使おうとしたときに、

「Cannot truncate a table referenced in a foreign key constraint」

というエラーが出たので、

その対応をした時のメモ。

発生状況、エラー内容

状況としては、

２つのテーブルがあり、

片方のテーブルは、そちらのメインのキーを外部キーとして、

使用しているようなテーブル構成だった。

実行しようとしたコマンド

truncate table target_table;

発生したエラー

ERROR 1701 (42000): 
Cannot truncate a table referenced in a foreign key constraint (....)

エラー対応

外部キー制約を外すことができるので、

foreign_key_checks

という設定を変更することで、

外部キー制約設定を制御して対応することができる。

外部キー制約をOFF

set foreign_key_checks = 0;

外部キー制約をON

set foreign_key_checks = 1;

上記で、

外部キー制約をOFFにしてから、

truncate構文で更新すると上手く動いた。

PHPで日付関連のサンプルコード

アプリケーションを作成していく中で、

PHPで日付関連の操作など、

処理を実装していると、

個人的に同じことをよくやることがあるので、

実際に記載しているコードなど、

随時、こちらにまとめていく。

現在日時のフォーマット

現在日時をフォーマットを行うことは、

データ保存時の日時を管理するなど、

使うことがよくあるのでメモ。

まず、DateTimeを使うので、

Laravelなどでは、

use DateTime;
use DateTimeZone;

が必要なので、

Laravelなどで環境によっては、

必要であれば、上記を追加。

そして、

時間の基準を日本時間に変更したいので、

DateTimeZoneで「Asia/Tokyo」を設定。

実際のコードは以下のようになる。

$nowDateTime = new DateTime('now', new DateTimeZone('Asia/Tokyo'));
$nowFormat = $nowDateTime->format('Y-m-d H:i:s');
echo $nowFormat;

実行結果としては、

以下のようになる。

2022-05-03 12:23:45

エラー「Maximum execution time of 30 seconds exceeded」が起きた件

アプリケーションを作成していく中で、

APIを作成して、

WebサーバーとしてNginxを稼働させて、

核処理を実装していたが、

処理的に重たい処理を流したときに、

「Maximum execution time of 30 seconds exceeded」

というエラーが発生した。

そのときに、

色々と調べて試した結果、

PHP-Fpmの設定を変更することでうまくいった。

エラー内容

エラーとしては、

Maximum execution time of 30 seconds exceeded

というエラーが、

Laravelのログの方に出力されていた。

対応内容

この辺りのタイムアウトに関しては、

Nginxの方でも、

send_timeout 1000;
client_body_timeout 1000;
client_header_timeout 1000;
fastcgi_connect_timeout 600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;
keepalive_timeout 1000;

のように対応していたが、

今回、Laravelの方でエラーになっていたので、

PHP-fpmの方があやあしいと考えて調べたら、

php.iniの設定を変更するとうまくいくようだ。

対象ファイルとして、

/etc/php/8.1/fpm/php.ini

のファイルを修正。

対象箇所として、

max_execution_time = 30

という設定値があったので、

無制限の値である「０」に

max_execution_time = 0

という部分を対応して、

PHP-fpmの再起動も忘れずに実施

sudo service php8.1-fpm restart

この対応でうまくタイムアウトせずに、

うまく処理が最後まで動くようになりました。

Nginxで動かしているAPIのレスポンスの一部がうまく取得できなかった件

アプリケーションを作成していく中で、

APIを作成して、

WebサーバーとしてNginxを稼働させて、

HTTPのコードが「２００」のコードで、

うまく取得できているように見えるのに、

データの一部がうまく取得できない事象が発生した。

そのときに、

色々と調べて試した結果、

Nginxの設定を変更することでうまくいった。

エラー内容

HTTPのレスポンスとしては、

「２００」で返ってきているので

サーバー間での通信自体に問題はなかった。

今回の調査を行なっていたところ、

うまくログの中に該当のエラーらしきものは、

見つけられなかった（見つけられてないだけで、出ていたかもしれない）。

サーバーだけうまくいっているのかに見えたので、

APIのクラインとツールで同じように検証したが、

という感じで、

やはり「２００」コードでうまくいった。

対応内容

環境構成として、

認証用に１つサーバーを経由して、

そちらをポート番号のプロキシにしていたが、

そちらのバッファのサイズ指定を設定することで、

今回の事象が解決した。

各種設定時に、

proxy_buffersなどの調整で色々とSyntax Error的なことが起きたが、

そちらに関しても、

ネット上の内容を確認して、

最終的に、以下の設定でうまくいった。

location / {
　 proxy_pass http://localhost:8000/;
   proxy_buffer_size 50000;
   proxy_busy_buffers_size 50000;
   proxy_buffers  4 50000;
}

POSTで413エラーでログ「client request body is buffered to a temporary」が発生した件

アプリケーションを作成していく中で、

HTTPのコードが「４１３」のエラーコードが発生して、

そのときにNginxの設定を変更した。

あまり起きることはないけれど、

のちのち、自分自身が同じようの設定の変更をしそうなので、

メモとして残しておく。

エラー内容

サーバー間で、

アプリケーション同士でファイルをPOSTしていたときに、

HTTPコード「４１３」のエラーが発生して、

Nginxのログファイルのエラー内容を確認すると、

client request body is buffered to a temporary

というエラー内容が表示されていた。

この内容的には、

POSTしているデータサイズが大きすぎるので、

エラーとして処理が行われていないようである。

対応内容

Nginxの設定ファイルを変更する。

Nginxの設定ファイル

/etc/nginx/conf.d/default.conf

設定ファイル内に、

以下の設定を追加。

追加設定コード

client_max_body_size 10M;

設定を追加したら、

sudo nginx -s reload

のコマンドで、

Nginxの再起動も実施する。

【まとめ】PHP/Laravelを学習するための書籍とサイト

プログラミング学習をしていく中で、

PHP
Laravel

について、

バックエンドの言語やフレームワークとして、

学習を始める方も多いです。

そんな方に、

学習の際に確認しておきたいサイトや、

おすすめの書籍をまとめて紹介します。

まずは、公式サイトは確認する

学習を行う際は、

まずは公式サイトをチェックする

ということは意識すると良いでしょう。

公式サイトには、

最新のバージョン情報
推奨される書き方など
参考にする基礎のコード

などがあるので、

まずは公式サイトをチェックしてみると良いでしょう。

公式サイト：PHP

PHPの公式サイトのリンクは、

以下から確認できるので、

ブックマークしておくと良いでしょう。

ちなみに、

確認する際は、

リンクのページに遷移した内容では、

途中までスクロールすると、

このような、

言語マニュアル部分があるので、

そこから、

気になる内容をクリックして確認すると良いでしょう。

PHPマニュアル

公式サイト：Laravel

Laravelの公式サイトのリンクは、

以下から確認できるので、

ブックマークしておくと良いでしょう。

確認する際は、

Laravelのページを表示させてから、

のように、

「DOCUMENTATION」

というボタンがあるので、

そこから、

フレームワークのドキュメント資料のページに遷移するので、

確認してみると良いでしょう。

Laravelのサイト

「超」初心者は絵本シリーズでイメージを掴む

リンク

プログラミング自体がはじめての方で、

処理を書こうと思っても、

変数
関数
判定処理
繰り返し処理

など、

初歩の部分で立ち止まってしまうようなら、

まずは関連する用語のイメージを掴む

ということから始めてみると良いでしょう。

あくまで「絵本」という形で、

イメージをもとにした理解なので、

初歩の導入として、

「超」初心者の方におすすめする１冊です。

他の言語も絵本シリーズはあり、

以下の記事にまとめています

プログラミング初心者には「絵本」シリーズがオススメの理由

PHPの基礎学習には「独習PHP」

リンク

プログラミング言語として、

PHPの基礎から自分自身で取り組んでいく方には、

おすすめの書籍として、

「独習PHP」

の書籍がおすすめです。

他の書籍よりも、

言語以外に手を広げすぎていないので言語学習に専念可能
独学で学習が進めやすい構成になっている
基礎の導入から少しずつ理解を深める構成になっている

という点で、

基礎部分を動画で見て初めて見たけれど、

何か腑に落ちないという状況や、

もう少し、１つずつ理解したいという初心者に、

おすすめの書籍なのでチェックしてみてください。

Laravelの学習に関して

個人的にLaravelの学習に関しては、

今のところ、

おすすめの書籍としては、

特にないという状況です。

ただ、

Laravelのドキュメントは丁寧にしっかりと作られている

ということが言えるので、

PHPの基礎学習は書籍で行い、

Laravelの学習は、

公式サイトを確認しながら、

試しながらフレームワークになれていくことが、

おすすめの学習方法です。

まとめ

PHPの公式サイト。

関数等の引数など、

使い方の正しい情報が載っている。

PHPマニュアル

Laravelの公式サイト。

ドキュメントがしっかりしているので、

自己学習の際も、

この公式サイトで１つずつ試していくのがおすすめ。

Laravelのサイト

プログラミング自体がはじめてで、

変数や関数、判定処理など、

導入部分で挫折しそうな「超」初心者には、

リンク

この「絵本シリーズ」の書籍がおすすめで、

イメージを掴んでもらうには良いと思います。

また、

PHPの言語の学習として、

公式サイトをチェックしてもらっても良いですが、

基礎的な言語学習から独学で進めていく上では、

リンク

こちらの「独習PHP」の書籍が、

独学でも進めやすい構成になっているのでおすすめです。

Let’s Encrypt(Certbot)でエラー「The requested nginx plugin does not appear to be installed」が発生した件

UbuntuでSSL対応する際に、

Certbotを使用して対応していたが、

新しい環境を作る際に、

「The requested nginx plugin does not appear to be installed」

のエラーが発生したので、

その時の対応のメモ。

実行した環境などの基本情報

実際に実施している環境としては、

Ubuntu＋Nginxという環境で、

Let’s encryptをCertbotを使って、

設定を行っていると状況です。

この辺りの基本的な情報は、

以下にメモしているので、

必要になったら参照。

Let’s encryptのSSL証明書をCertbotを使って、Nginxに設定する方法

発生したエラー

Certbotを実行した際に、

Saving debug log to /var/log/letsencrypt/letsencrypt.log
The requested nginx plugin does not appear to be installed

のエラーが発生。

エラーへの対応

新しい環境なので、

Certbotを動かせる状態ではなかったので、

以下のコマンドでCerbot付随のライブラリをインストール

sudo apt install python3-certbot-nginx

このインストールの後は、

最初の、

「The requested nginx plugin does not appear to be installed」

のエラーはなくなったので、対応完了。

管理ツールとしてGoogle Workspaceを使い始めた件

管理ツールとして、

「Backlog 」

を使っていたけれど、

メールサイズの問題に悩んでいた
メールアドレスの管理方法を使いやすいものにしたかった

ということがあり、

いくつかサービスなどを検討していましたが、

Googleが提供している

「Google Workspace」

を使うようになって、

アカウントの管理が、

すごく簡単で便利になったので、

使ってみると便利なツールだなと感じています。

実際に最初に使い始める前は、

アカウント情報が管理できていないまま

という状況が起きていて、

組織に新しい人が入ったけれど、
新規の設定等がすごく面倒だなぁ…

ということや、

いなくなった人のアカウントを、
きれいにしないといけないけれど、
管理が面倒で大変だなぁ

みたいな感じで、

色々と管理するのが面倒でしたが、

実査に使い始めてみると、

使う頻度は多くないですが、

個人的にすごく楽になったので、

その辺りの経緯など、

この記事に残しておきます。

アカウントが無造作に作られていた

自分がシステム周りを対応し始めて、

組織内でメンバーが使うアカウントを確認していたら、

アカウントの作成に関しては、

アカウント情報が、
それぞれの人が個別に作って、
誰がどのアカウントを使っているかわからない

という状態で、

すごく驚いたことを覚えています。

実際に、

この辺りのことを管理しないまま、

運用を続けているところも多いかもしれませんが、

自分がシステム周りを整備し始めていくなかで、

どうにかしたいなというところを考えて、

「Google Workspace」

が選択肢に上がってきました。

選択肢に上がってきた理由としては、

無造作に作られているアカウントの中で、

Googleアカウントが個人アカウントをそのまま使う人もいた

ということが大きな要因でした。

この点に関しては、

社内でGoogleドライブを使う運用にしていた
スプレッドシートが組織内で１番使うツールだった

ということが、

この問題を発生させている理由で、

この運用自体は変えたくなかったため、

管理しやすい形で、

アカウント情報を整理することになりました。

Googleアカウントをドメインと結びつけて整理することにした

実際に、

Googleアカウントを整理することにしたときに、

どのように整理しようと考えましたが、

今のまま、それぞれが使っているアカウントをどこかにまとめる

という方法か、

作成できるアカウントを絞って管理してまとめていく

という方法で悩みましたが、

最初の方法でまとめ始めると、

結局、

まとまっているように見えて、
それぞれのメールアカウントがバラバラに見える…

ということを、

将来の自分が悩み出しそうだったので、

作成できるアカウントを絞って管理してまとめていく

という方法で取り組むことにしました。

メールの容量と重すぎる問題も合わせて解決したかった

Googleのアカウントが無造作に作られて、

整理されていなかった問題に合わせて、

もう１つ、解決したい問題がありました。

それが、

メールの容量が重すぎて、メールツールで開けないことがあった

ということです。

これに関しては、

組織内で使っていた状況として、

国内大手のメール管理ツールメールクライアントツールを使っていた
メールクライアントツールも合わせて使っていた

という状況で、

それぞれのメンバーが、

違うツールも使っていたこともありますが、

１つ、大きな点として、

過去のメールをどうしても残したいメンバーがいる

ということが、

メールの容量の問題を発生する１つの要因でした。

この点に関しては、

どうしても対応する必要があり、

過去メールを残しながら、

大容量でも対応できるメール環境が必要

という状況になり、

Google Workspaceを調べて、

というプランを導入して、

メールのクライアントもGmailに統一する

という対応で、

メールが重すぎて、

開けないという問題に対応しました。

やはり容量の大きなデータの扱いという点で、

Googleが提供しているサービスは、

メール件数が多くなっても速度が快適
メール件数が多くても検索が快適

という点が、

使っていく中で、

すごく優れていて使いやすいなと感じました。

同じドメインにまとめて、Google Workspaceで管理することで楽になった

メールの問題は解決して、

Google Workspaceで管理していくことで、

個人的に１番、楽になった点としては、

使用しているアカウントが一覧で簡単に管理できる

という点でした。

具体的には、

という感じで、

一覧として管理できるので、

いま、組織でメンバーが使っているアカウントは、
どうなっていたんだっけな

ということを確認するときなど、

すごく便利になりました。

Google Workspaceの導入・活用の始め方

Google Workspaceの導入方法や、

実際の活用の始め方については、

以下のサイトを参考にしてもらえればと思います。

Google Workspaceの導入・活用方法

Ubuntuで各種ミドルウェアのバージョン確認をした時のメモ

Ubuntuの環境周りで、

新しい環境を作る際に、

使用しているミドルウェアに関して、

最新の状況にアップデートして使い始めることが多いので、

その時のコマンドをよく忘れるので、

メモしておく。

Ubuntuのバージョン確認

Ubuntuのバージョン確認のコマンド

lsb_release -a

確認すると、

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.4 LTS
Release:	20.04
Codename:	focal

という感じで把握することができる。

ちなみに、

最新のバージョンのリリース状況は、

以下のリンクのページで確認している。

基本的に、LTSの最新であれば大丈夫かと。

Ubuntu Wiki の List of releases

Nginxのバージョン確認

Nginxのバージョン確認に関しては、

Webページで初期表示させても確認できるような気もするが、

コマンドラインで以下のコマンドで確認。

nginx -V

確認してみると、

$ nginx -V
nginx version: nginx/1.21.6
built by gcc 9.3.0 (Ubuntu 9.3.0-10ubuntu2)
built with OpenSSL 1.1.1f  31 Mar 2020
TLS SNI support enabled

このように、

バージョンが確認できる。

特にエラー等が表示されなければ完了。

Nginxのバージョンのリリース状況は、

以下のリンクで確認。

Nginx newsでのリリース情報

Nginxのバージョンの変更ログ

PHPのバージョン確認

プログラミング言語周りとしては、

Laravelを使うことが多いので、

PHPのバージョンも確認してみる。

php -v

で確認できるので、

上記コマンドで確認すると、

$ php -v
PHP 8.1.4 (cli) (built: Apr  4 2022 13:30:17) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.4, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.4, Copyright (c), by Zend Technologies

このように、

バージョンを確認することができます。

最新のバージョンについては、

以下のリンクのページで確認してます。

PHP Version Log

UbuntuでシェルをZSHに変更した時のメモ

Ubuntuの環境設定で、

ユーザーのシェルの環境をZSHにすることがあり、

その時のコマンドをよく忘れるので、

メモしておく。

ZSHのパス確認

zshのパスを確認する

which zsh

確認すると、

$ which zsh
/usr/bin/zsh

という感じで把握することができる。

ZSHに変更

上記で確認したZSHのパスを使って、

ZSHに変更を行う。

コマンド

chsh

を使って進めると、

$ chsh
Password:
Changing the login shell for conoha-motti
Enter the new value, or press ENTER for the default
	Login Shell [/bin/sh]: /usr/bin/zsh

このように設定を進めて、

特にエラー等が表示されなければ完了。

ZSHの設定情報

設定情報は、

.zshrc

のファイルを編集するので、

Vimを使って、

vi ~/.zshrc

で編集をかければオッケー。

UbuntuのVimの設定でdeinを設定した件

Vimの設定で、

それぞれの環境を設定するときに、

設定方法をちょっと忘れることがあるので、

メモしておく。

deinのGithub

deinのGithubのページを確認。

リンクをメモ。

deinのGithubのページ

deinの設定

Githubに記載がある通り、

以下のコマンドを実施。

curl https://raw.githubusercontent.com/Shougo/dein.vim/master/bin/installer.sh > installer.sh
# For example, we just use `~/.cache/dein` as installation directory
sh ./installer.sh ~/.cache/dein

インストール実施後

上記で実行すると、

Please add the following settings for dein to the top of your vimrc (Vim) or init.vim (NeoVim) file:


"dein Scripts-----------------------------
if &compatible
  set nocompatible               " Be iMproved
endif

" Required:
set runtimepath+=/root/.cache/dein/repos/github.com/Shougo/dein.vim

" Required:
call dein#begin('/root/.cache/dein')

" Let dein manage dein
" Required:
call dein#add('/root/.cache/dein/repos/github.com/Shougo/dein.vim')

" Add or remove your plugins here like this:
"call dein#add('Shougo/neosnippet.vim')
"call dein#add('Shougo/neosnippet-snippets')

" Required:
call dein#end()

" Required:
filetype plugin indent on
syntax enable

" If you want to install not installed plugins on startup.
"if dein#check_install()
"  call dein#install()
"endif

"End dein Scripts-------------------------

このように、

設定情報をdein scriptとして、

追加するように促されるので、

その設定を追加。

あとは、

個別に自分が必要な設定情報を追加。

個人的な初期設定をメモ。

set enc=utf-8
set tabstop=2
set softtabstop=2
set autoindent
set smartindent
set cindent
set expandtab
set shiftwidth=2
set cursorcolumn

if &compatible
  set nocompatible
endif
set runtimepath+=~/.cache/dein/repos/github.com/Shougo/dein.vim

if dein#load_state('~/.cache/dein')
  call dein#begin('~/.cache/dein')

  call dein#add('~/.cache/dein')
  call dein#add('Shougo/deoplete.nvim')
  if !has('nvim')
    call dein#add('roxma/nvim-yarp')
    call dein#add('roxma/vim-hug-neovim-rpc')
  endif

  call dein#add('scrooloose/syntastic')
  "call dein#add('Yggdroot/indentLine')

  call dein#add('posva/vim-vue')

  " color scheme
  call dein#add('tomasr/molokai')
  call dein#add('fmoralesc/molokayo')

  call dein#end()
  call dein#save_state()
endif

if dein#check_install()
  call dein#install()
endif

filetype plugin indent on
syntax enable
colorscheme molokayo

"hi Visual term=reverse cterm=reverse guibg=green
hi Visual term=NONE cterm=NONE guibg=green

set cursorline
highlight CursorLine cterm=underline ctermfg=NONE ctermbg=NONE
highlight CursorLine gui=underline guifg=yellow guibg=NONE

React で環境変数などを「.env」ファイルに変更した件

Reactで実装していたときに、

各種APIのURLなど、

小さな規模であれば、

そのまま書いておくこともあるが、

本来、切り分けて管理した方が良いので、

ローカル環境だけでなく、

別の環境にファイルをアップロードする際に、

分けることにした時のメモ。

参考にしたサイト

こちらのサイトを参考にしました。

リンクをメモ。

Environment Variables

Gitで管理するので、.gitignoreに.envを設定

実際に設定ファイルにしていく。

このとき、

Git管理しているのであれば、

.gitignore

のファイルの中に、

.env

を追加しておく。

環境変数を「.env」ファイルに設定

環境変数に関して設定するときに、

.env

ファイルを作成する。

そして、その中に、

キー
値

の値を設定していく。

Reactのアプリケーションで作っているので、

プレフィックス（キーの先頭につける）として、

REACT_APP_

が必要なので、

「.env」での設定は、

REACT_APP_API_URL=https://api.url

のように設定する。

Reactアプリ内での「.env」の値の取得

環境変数を、

「.env」のファイルに準備したら、

Reactアプリ内での取得方法で、

もともとの文字列を変更する。

取得方法は、

process.env.キー

という形で、

「.env」の値を取得できるので、

上記の「.env」の例の

REACT_APP_API_URL=https://api.url

であれば、

process.env.REACT_APP_API_URL

のように取得する。

設定変更の際はReactアプリを再コンパイル

環境変数として設定した「.env」の値は、

実際に反映させるためには、

Reactのアプリケーション自体を、

再コンパイルする必要があるので、

npm run start

などで、

再コンパイルするとうまく値が反映されるかと思います。

人の少ない会社でエンジニアとして働くメリット・デメリット

IT業界に入って、

１０数年働いてきて、

転職活動も何回か行いながら、

従業員、エンジニアが、比較的に多い企業
従業員、エンジニアが、比較的に少ない企業

でそれぞれ働きましたが、

どのくらいの人数の組織なのか、

エンジニアがどれくらいいるのかで、

働く当事者として感じるものは違うなと。

実際に、

自分の経験の中で、

従業員、エンジニアが、比較的に少ない企業

で働いているときに、

人数少ないから、
すごくこの部分は大変だなぁ…

ということや、

人数少ないけれど、
そのぶん、この点はすごく良く感じるから好きだな

みたいな感じで、

感じたことや経験したことなど、

色々とあったので、

この記事に残しておきます。

最初は大きな企業を目指した

自分のエンジニア経験の中で、

最初に働いた企業から、

ステップアップの目標として、

エンジニアも数十人はいる、しっかりとした企業にいくぞ

と思いながら、

日々、開発などを頑張り、

目標が叶って、

そのような企業に転職することができました。

このときに、

大きな企業を目指した目的としては、

規模の大きいシステムや案件に携わりたかった
上流工程の最初から取り組んでみたかった
エンジニアが多い企業の文化に触れてみたかった

ということがあり、

この点に関しては、

それぞれ、

自分なりに目的として考えたことに対して、

実際に案件に携わったり、

社内勉強会という文化に触れてみることで、

すごく良い刺激を感じることができました。

エンジニア以外も、

色々な職種の方がいることで、

案件で携わる人をみて、

エンジニア以外の方は、
こういう方もいるのかぁ。
面白いなぁ。

と感じることもあり、

貴重な経験を得ることができました。

この辺りの社員やエンジニアが比較的多い企業で、

働いたときに感じたことなどは、

別の日記で書いていこうかと思います。

自分は開発が好きなことを再発見する

社員も多く、エンジニアも比較的多いとなると、

案件の規模自体が大きくなりやすいので、

上流工程から入ると、

規模が多いので全ての工程の期間が長い

ということと、

上流で設計してると、開発に携われなくなる

ということが起きていました。

これは、

それぞれの組織の方針や、

どのようなエンジニアがいるのか、

また、プロジェクトをどのように進めるのかに関わると思いますが、

自分がいた環境であれば、

上記２点をすごく感じていました。

そんな中で、

週末などにプログラミング技術について試していましたが、

だめだ、開発をもっとしたい。
ただ、開発だけでなく、設計から携わりたい

という欲求が芽生え、

「あ、自分はそもそも、開発が好きなんだな」

ということに気づきました。

人の少ない会社でエンジニアとして働き出す

設計から開発まで、

全てに携わろうと考えたときに、

人の少ない会社でエンジニアとして働く

ということを目指しました

零細企業に入って、

給料だけ安くて死にそうになるのは嫌なので、

給与的には前の企業よりも上げてもらう
ベンチャー気質がある
システム開発が自社内でコントロールできる

という点は、

しっかり選んで考えながら、

人が少ない企業で、

エンジニアとして働き出すことになりました。

エンジニアが少ないと、業務量が必然的に多くなる

人が少なく、

エンジニアの数も、

他のエンジニアがやめたりすると、

最悪、自分１人だけでやっていることもありましたが、

エンジニアが少ないことで、

１人に対する業務量が必然的に多くて大変

ということを感じました。

エンジニアも多く、

システム部門も大きくなっているようなら、

これ、よくわからないから、
システム部門の〇〇のチームに言えば良いかな。

となりますが、

人が少ない分、業務を知っている人が限られるので、

これ、よくわからないから、
〇〇さんに聞いてみよう。

となり、

すぐに色々な業務が、

自分のところに回ってきます。

これは、

入社前に思っていた以上でした。

自分のスケジュールにバッファを持っておかないと、

依頼などや調査などで、物事が進まなくなります。

この点はすごく大変でした。

ちょっとした負荷も嫌で、

定時に帰ってみたいな希望の方であれば、

ストレス過多になるなと感じるレベルです。

自分が整理してまとめると、直接的に業務量が変わる

最初はちょっとストレス過多だなとは感じていましたが、

自分に物事が集中する分、

自分が物事を整理して改善すると、直接的に業務量が変わる

ということを感じました。

この点は、

取り組んでいてすごくやりがいにつながることが多く、

感謝してもらえることも多いので憂しい限りです。

ちなみに、

この物事が整理・改善されて業務等も変わっていくと、

システムも不具合がなくなっていくので、

あれ、最近、何も言ってこないな。
この点に関してはすごく暇だな。
なにか言ってきてくれないかな。

みたいに、

ちょっとした寂しさを感じることもあるくらい、

その調整した部分の影響が、

自分の時間を増やしてくれるという点で、

自分と他人の業務量に関して、

直接的に変化をもたらしているなと感じました。

この点に関しては、

人の多い企業で働いているときよりも、

スピード感があって、

直接、目に見える形で物事が変わるので、

好きな人には好きな環境なのかなと思います。

自分で開発を取り組む機会が多くなりスキルが上がった

人が少ない企業であれば、

エンジニアも少なく、

自分が開発できる機会も増えるだろうと、

そのような考えで働き始めましたが、

その点に関しては、

思っていた通り、

開発をする機会が増え、スキルアップに繋がった

ということが言えます。

特に、

社内の状況にもよりますが、

社内での自分の裁量が大きい
社内で使いたい新しいシステムを作る

という状態ができると、

外部が変わらず、

案件的に融通が効くので、

今まで取り入れたことがないスキルや、

自分がやってみたかったスキル、言語など、

取り入れることができるので、

この点で、すごくスキルアップにつながるなと感じました。

裁量は大きくなり、給与も上げてもらいやすかった

ここまで書いてきたように、

人が少ない企業で働くことは、

人が少ない分、業務量は多くなりやすい

という点が、

業務の過負荷的に、

１番、きつい部分かなと思います。

一方で、

開発に携わることでスキルアップにつながる
条件があえば、自分がやりたい技術を導入できる

という点では、

自分に裁量が増えていく分、

自由も聞きやすいので、

働く中で良い点だと感じました。

そして、

もう１つ、個人的に大きかったのは、

裁量が大きくなることで、給料も上げてもらいやすかった

ということがあります。

この辺りは、

その企業の財務状況にもよるとは思いますが、

自分自身がスキルアップができているので市場価値は上がっている

という観点で、

ちょっと業務的にも過負荷になっていることと、
働きだしてから自分の裁量も大きくなったので、
給料あげて欲しいです

みたいなことを言えて、

給料が上がる経験をしたので、

ベンチャー気質のある、

そこまでエンジニアの人数が多くない企業で、

財務状況をみながら、

給与交渉をしていくと、

比較的、状況もわかってもらえるので、

給与をあげてくれるのではないかと思います。

React Hook でReact Reduxを導入した件

Reactで実装していたときに、

React Hookでの実装をしていたが、

ステートメントなどでの管理を考え、

React Reduxの導入を試してみることに。

この記事はその時のメモ。

公式サイト

まずは公式サイトを確認。

リンクをメモ。

React Reduxのサイト

React Reduxの導入

すでにReact自体は導入して、

実際にReact Hooksで実装を進めているので、

公式サイトにしたがって、

NPMでインストールを実施。

npm install react-redux

公式のサンプルも確認しておく

公式サイトにしたがって、

まずは、

サンプルのコードをチェック

こちらのサンプルに関しては、

プロジェクトごと作成する必要があるので、

npx create-react-app my-app --template redux

こちらでインストールをする。

その際、Redux Toolkitも併せて必要なので、

そちらもインストールする。

Redux Toolkit

先程のサンプルで、

Redux Toolkitも、

合わせて導入することが前提となっているので、

npm install @reduxjs/toolkit

のコードで、

NPMからインストールを実施。

Redux Toolkitのサイト

サンプルを動かす

実際にサンプルが表示できるか、

起動して試してみる。

npm run start

こちらで起動すると、

localhost:3000

のポートで画面が開き、

この画面が表示されると、

サンプルコード自体は動いている。

Laravelで別のデータベースから同じテーブルカラムのテーブルにデータを移行した件

Laravelを使っていて、

マスター、スレーブみたいに、

別のデータベースに対して、

バックアップデータや、

一度、別データベースに最新情報を作成して、

本来のデータベースにデータを移すなど、

データを移行しようとした時のメモ。

前提：やろうとしたこと

やろうとしたことは、

別データベースから、

同じカラムを持ったテーブルに対して、

データを移行しようとした。

イメージとしては、

このような感じで、

移行元のデータベースから、

移行先のデータベースに対して、

データを移行させようとしました。

Laravelでの対応内容

Laravelでの対応内容としては、

それぞれのデータベースの定義を準備して、

それのデータに対して、

テーブル内容の削除と、

データを再度、移行元から追加するというシンプルな動作。

Laravelでテーブル単位で移行の方法

dumpとって、

一括で入れてしまうなどの方法も別であるとは思うが、

Laravelの中で、

移行先のテーブルの中身を削除
移行元のテーブルの中身を取得
移行先に移行元のテーブルの中身を追加

という感じで処理を行った。

実際の処理はこんな感じ。

    $tblDataNew = DB::connection('new_database')
      ->table('new_table')
      ->get();
    DB::connection('old_database')->table('old_table')->truncate();
    foreach($tblDataNew as $rowData) {
      DB::connection('old_database')
        ->table('old_table')
        ->insert(get_object_vars($rowData));
    }

この処理で、

データが削除されて、

移行元からうまくデータが追加できた。

パソコンゲームでブラインドタッチを覚えていたあの頃

学生の頃、

本当に最初にパソコンを触り始めたときに、

パソコン、難しいなぁ….
なんか面白いゲーム的なものないかな〜
それでパソコンの使い方覚えれたらいいなぁ

みたいな感じで、

パソコンで遊べそうなソフトを、

ネットでゴロゴロ探していました。

そんなときに、

パソコンゲームとしてインストールしたらずっと遊べる
タイピングゲームなので、パソコン作業に役立つ
比較的、安い価格で買えた

という点で、

「特打」

リンク

と呼ばれる、

タイピングゲームソフトをやっていました。

その時は、

今みたいに、パソコンが１人１台という感じでなく、

家族で１台あるくらいだったので、

隙を見ては、タイピングゲームで遊んでいたのを覚えています。

父はソリティア、囲碁、将棋が合ってたみたい

パソコンに標準でついてくる、

無料のゲームとして、

「ソリティア」

がありますが、

そのころは、

オンラインゲームもまだまだ普及しておらず、

このソリティアでも、

シンプルだけど、このゲームちょっと中毒性あるよな。

って思いながら、

このゲームはそこまでやらずに、

自分はタイピングゲームで遊んでいました。

一方で、

自分の父は、暇な時は、このソリティアで遊んでおり、

今でも実家に帰ると、

ソリティアで遊んでいることを見かけることがあり、

以前、父のパソコンに、

囲碁
将棋
麻雀

が一緒になったソフトをインストールして、

ボケ防止に使ってもらおうと、

ソフトを買って入れておいた記憶があります。

自分の記憶だと、

買ったのは多分これ。

「100万人のためのお得セット 3D囲碁・将棋・麻雀」

リンク

このソフトだったと思いますが、

父のパソコンに入れておいてよかったなと思いますね。

ソリティアはやはり現役みたいですが、

将棋ゲーム
囲碁ゲーム
ソリティア

のどれかで遊んでいますね。

以前、

オンラインで他の人と無料で対戦できるから、
そのソフト使わなくていいんじゃない？

と聞いた時も、

「いや、このソフトがちょどいい」

ということで、

暇つぶしに使ってくれているみたいです。

自分はタイピングソフトでブラインドタッチを習得

ソリティアなどは、

自分はあまりやることもありませんが、

この記事で最初に紹介した、

タイピングソフトの「特打」に関しては、

パソコンゲームで遊びたかった
遊びながら、何かを身につけたかった

という点で、

すごくハマっていたソフトです。

これを使っていたのは、

自分の記憶だと、

大学に入る前に、

ちょっと時間あるし、暇だな。
パソコン使っていいって言われたけど、
いきなりプログラミングなんてできないし、
とりあえず、１ヶ月間くらいやることあれば…

みたいなところから、

このソフトを使って、

ハマって遊んでいた記憶があります。

タッチタイピングを覚えていたので、作業やレポート作成が楽だった

資料を作ったり、

何かをレポートにまとめたり、

自分はそのようなこと自体は好きなのもありますが、

タッチタイピングを事前にやっていたこともあって、

なにこれ、パソコンで資料作るの楽しい。
しかも、手書きでやるより全然らくじゃん。

ということを、

高校までは、

もらった宿題という名の紙切れに、

手書きで一生懸命書いていましたが、

その苦痛から解放されて、

資料作りなども楽しくやっていた記憶があります。

個人的には、

資料作りなどを苦痛に思う１つの要因として、

「そもそも、タイピングが苦手な人は入力作業が嫌い」

ということが、

大きな要因としてあるのではないかと、

個人的に思っていたりします。

ちょっとパソコンでの資料作りなど苦手だなという人で、

タイピングはすごく苦手という方は、

タイピングソフトで、

まずは「遊んでみる」ということを、

楽しみながらやっていくことをおすすめします。

この記事で紹介したタイピングソフト

「特打」

リンク

seleniumで自動化は処理が楽になったけどメンテが面倒な件

日々の業務などをやっていて、

色々と面倒な作業などは、

自分がやったり、

他の人がやったり、

自動化できずに手動で頑張っていることは、

意外と多いなぁと思うことがあります。

そんな自動化していくべき、

今で言えば、

「DX化」

みたいなことにも通じるのかなと思うが、

自動化することで業務は効率化されていきます。

各種の使っているサービスなどで、

APIが用意されている部分は自動化を実施

という形で、

業務の効率化に取り組んで、

ある一定の成果は、

目に見える形で起きたのだが、

面倒な業務は残ったまま。

この面倒な部分に対しても、

自動化することでヒューマンエラーを防ぐ
自動化することで、担当者の負担を減らす
自動化することでチェック結果を蓄積していく

みたいなことに、

どうにか取り組んで、

その後のメンテナンスをやっていったお話。

まずは、APIが用意されている部分を少しずつ自動化した

もともと、

色々なことが、

手動で行われていて、

大変だけど、やるしかないでしょ

みたいな形で、

それぞれが、

それぞれの抱えている業務を、

いつものフローで、

気合で頑張られていました。

ある意味、それでもうまく回ってはいたのです。

ただ、

やはり他の業務や突発的なできごとなどで、

他の対応に追われて、本来やるべき作業の精度が落ちている

という状況が、

側から見た時に見受けられました。

まぁ、

人がやることは、少なからずミスは起きるもの。

そのように、

個人的には考えているので、

業務を自動化していくことになりました。

そこで、

まず取り組んだのは、

各種サービス等でAPIが準備されているところを自動化する

ということ。

この辺りは、

色々と取り組んだので、

取り組んだ内容やよかったことなどは、

別の記事で書いていこうと思います。

今回の記事の前提としては、

このAPIを使った自動化が終わったというところが前提。

APIを使った自動化だけでも、

結構な業務の自動化になったと、

個人的に思っており、

新しく作ってもらった自動化してくれるやつ、
あれで、すごく楽になりました〜

みたいなことも言われるので、

ある程度の成果はでたのかなと。

APIが準備されてない部分でどうするかと悩む

APIでの自動化を進めた上で、

ある程度、業務が効率化できた部分など、

目に見える成果はでてきました。

しかし、

まだまだ人が手動で頑張っている部分があり、

ネットで情報を検索して、その情報をまとめる
古いシステムでAPIなど準備されていない

みたいなこともあり、

APIがあることで、

自動化することもすごく楽で、

APIあるんで、
この部分の業務の自動化は任せてください

と言えていましたが、

どうしたら良いのかと悩む日々。

組織内では、

この前、色々と自動化してくれた分で、
いつもの業務がすごく楽になったので、
あとは、気合でやりますかねぇ…

という人もいて、

やはり、

「気合でやります」

を変えねばと考えて、

API以外での方法を考え始めました。

Seleniumで自動化を行い始める

APIがない時の対応を探っているなかで、

ネット上の情報から情報を取得したり、

知人などから、

そのAPIで自動化できていない部分、
Seleniumでなんとか頑張ったらいけると思うよ。

という話もあり、

「Selenium」

「Selenium」のサイト

の公式サイトや、

実際の使い方を載せている記事などを調べて、

業務の中の処理を、

対応できそうな部分は自動化していきました。

この自動化に関しては、

「BeautifulSoup」

Beautiful Soup のサイト

というライブラリも合わせて使いました。

なので自動化するにあたっては、

処理を実装する言語はPythonでコードを書いた
BeautifulSoup4というライブラリも合わせて使った

ということで取り組んだ形でした。

ゆくゆくは、

サーバー側で同じことをやろうと考えるに至りましたが、

この自動化を最初に取り組んだ時点では、

まずは、PC上で動かすことまでを取り組んでおり、

業務を自動化したものが自分のPCにあり、

処理を行いたい場合に、

自分に連絡をいただいて処理を実施するような流れになりました。

このSeleniumでの処理の自動化をすることで、

簡単にざっくりいうとですが、

１時間作業が、１０分程度で終わるようになった

という結果も、

一部ではでていたので、

やはり自動化して良かったとは思っています。

Seleniumで自動化した部分のメンテが面倒だった

処理を自動化していく中で、

最初に取り組んだAPIでの自動化も含めて、

APIで自動化した業務と対象のコード
Seleniumで自動化した業務と対象のコード

の２つにわけられるのですが、

APIで自動化した方に関しては、

「APIで使用が決まっていて変更もほとんどないので、メンテも楽」

ということが、

私が自動化した部分だけの経験で言えば、

すごくメンテが楽という結果になりました。

一方で、

Seleniumで自動化した部分に関しては、

「操作対象の画面が変わることでの変更が大きく、メンテも大変」

ということが、

自動化した前提で業務を進めていくと、

動くことが前提になっていることもあり、

急ぎの対応にもなることも含めて、

メンテ側がすごく大変になるという結果になりました。

実際にメンテをしていく上では、

そもそも、自分のPC上だと管理が大変
Seleniumの操作対象の画面の変更頻度が重要

ということがあり、

最初の１点目に関しては、

Seleniumの処理をサーバ側に持っていき、

そちらで動かすようにしていきました。

こちらの点に関しては、

別記事で対応のメモだけ残しましたが、

seleniumでドライバエラー:This version of ChromeDriver only supports Chrome version XX

みたいなことがおきながら、

都度、対応して動かすことができました。

ただ、サーバのミドルウェアのバージョンや、

Seleniumのバージョンなどの相性もあり、

うまく動かない場面もでてきたので、

その辺りに四苦八苦することになりました。

この辺りは、

対応した時のメモなどを記事に残していますが、

環境構成で挙動がちょっと怪しくなるなという印象があるので、

実挙動をサーバ側で試してみる（複数回実行など）のが、

チェックとして大切かなと思いました。

この１点目の

そもそも、自分のPC上だと管理が大変

の部分だけでも、

メンテが大変でしたが、

２点目の

Seleniumの操作対象の画面の変更頻度が重要

については、

画面が変わることで、

Seleniumで取得して解析しようとする対象のタグなど、

全てが変わっていくため、

その都度、

あ、画面のHTMLの構造がすごく変わってる…
この部分にクリックして遷移するボタンがあった気が…
いや、ボタンは無くなったのか….泣

みたいになり、

目的の操作をおこうなうために、

「どのような順序でその行動を達成するのか」

という点が、

完全に覆ることもあるので、

その点がすごくメンテナンスをしていく上で、

非常に大変だと感じた部分です。

この点は、

メンテナンスを少しでも楽にするために、

想定していた画面操作を動画で残しておく
想定していた操作対象の要素がどれかを残しておく

ということに取り組むことで、

変更が起きた時の自分が少しは楽になったので、

もし、同じように取り組まれる方は、

上記のことを取り組んでおくと、

同じように楽ができるかもしれません。

また、

この辺りについては、

コードをリファクタリングしたり、

対象の設定情報を設定ファイルとしてまとめることで、

メンテも楽になるという、

一般的なコードのリファクタリングが、

大きく影響を及ぼすなぁと取り組んで感じたので、

この辺りについては、

別記事で書いていこうかなと思います。

Go言語でHttpサーバを立てて、GETリクエストを試した件

ちょっとしたWebサーバを立てるなど、

PythonのBottleサーバなどで行っていたが、

Go言語を試しに使うことを検討した時に、

まずは、HTTPでサーバをたてて、

GETでのリクエストを試した時のメモ。

公式

まずは、公式サイトのリンクをメモ。

基本的なファイルのコンパイルや実行など、

最初に試す時は、

公式を読んで進めていくのが良いかも。

Go言語の公式サイト

参考にしたサイトなど

実際に試す上で参考にしたものとしては、

書籍としては、

リンク

この書籍を読んでみた。

自分はブックオフの店舗でたまたま中古で見つけて、

それを読み始めて、

「Go言語試してみよう」

となったので、

もしよければ読んでみて欲しい。

あとは、

公式のページのnet/httpのページと

いくつかのサイトを参考にさせてもらいながら、

実際にコードを試したり調整したり、

動かすことを色々と試した。

ちなみに、

HTTPのルーティングとして、

「gorilla」

というライブラリを活用した。

Go言語の[net/http]のパッケージのドキュメント

gorillaのGithubのページ

Go言語でGETリクエストを試したコード

実際に試したコードをメモしておく。

作ったファイル

main.go

コード

package main

import (
  "net/http"
  "github.com/gorilla/mux"
)

func init() {
}

func main() {
    r := mux.NewRouter()
    r.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprint(w, "Hello\n")})
}

実行

go run .

LaravelのExcel対応の際にLaravel-Excelを導入しようとした時にエラーになった件

Laravelを使っていて、

Excelファイルを取得するために、

他の環境であれば、問題ない導入処理だったが、

別の環境だとエラーがなぜか発生した。

これを調べて対応した時のメモ。

前提：Laravel-Excelを使用

Excelファイルの読み取りに関しては、

Laravel-Excelというのを使っていた。

この「Laravel-Excel」を、

別の環境でも導入しようとしていた。

実際の使用方法は、

以下のGithubなどを参考。

Laravel-Excel

エラー内容

エラーとしては、

導入しようとした時に、

以下のエラーが発生した。

Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - maatwebsite/excel[3.1.36, ..., 3.1.x-dev] 
　　　　require phpoffice/phpspreadsheet ^1.18 
　　　　-> satisfiable by phpoffice/phpspreadsheet[1.18.0, ..., 1.22.0].
    - maatwebsite/excel[3.1.0, ..., 3.1.25] 
　　　　require php ^7.0 
　　　　-> your php version (8.1.0) does not satisfy that requirement.
    - maatwebsite/excel[3.1.26, ..., 3.1.35] 
　　　　require illuminate/support 5.8.*|^6.0|^7.0|^8.0 
　　　　-> found illuminate/support[v5.8.0, ..., 5.8.x-dev, v6.0.0, ..., 
          6.x-dev, v7.0.0, ..., 7.x-dev, v8.0.0, ..., 8.x-dev] 
          but these were not loaded, 
          likely because it conflicts with another require.
    - phpoffice/phpspreadsheet[1.18.0, ..., 1.22.0] 
       require psr/simple-cache ^1.0 
       -> found psr/simple-cache[1.0.0, 1.0.1] 
          but the package is fixed to 3.0.0 (lock file version) 
          by a partial update and that version does not match.
          Make sure you list it as an argument for the update command.
    - Root composer.json requires maatwebsite/excel ^3.1 
       -> satisfiable by maatwebsite/excel[3.1.0, ..., 3.1.x-dev].

Use the option --with-all-dependencies (-W) to allow upgrades, 
downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, 
e.g. "composer require maatwebsite/excel:*" to figure out 
if any version is installable, 
or "composer require maatwebsite/excel:^2.1" 
if you know which you need.

というエラーが発生していた。

エラー調査

各種バージョンの整合性でうまくいっていないようなので、

エラー表示の中の、

Use the option --with-all-dependencies (-W) to allow upgrades, 
downgrades and removals for packages currently locked to specific versions.

を参考にして、

オプションをつけて実行。

composer require maatwebsite/excel --with-all-dependencies

これを実行すると、

$ composer require maatwebsite/excel --with-all-dependencies
Using version ^3.1 for maatwebsite/excel
./composer.json has been updated
 :
Updating dependencies
Lock file operations: 7 installs, 2 updates, 0 removals
 :
  - Locking maatwebsite/excel (3.1.38)
 :
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 7 installs, 2 updates, 0 removals
 :
  - Installing maatwebsite/excel (3.1.38): Extracting archive
 :
Publishing complete.

このようなログを残しながら、

うまくインストールの処理が完了。

Laravelでパスワード再設定時のテンプレートをカスタム化した件

Laravelでメールを送信させるために、

デフォルトのフレームワークの機能を使って、

実際に送信した時に、

送られてくるメールの内容を、

変更した時のメモ。

前提：Laravelの環境構築

まず、前提として、

Laravelの環境構築を行った。

最終的に、

このような、

初期表示ができるところまで、

環境を構築できていることが前提。

ここまでの導入は、

以下の記事の一部を参考にしてもらいたい。

Laravelでお名前.comのお名前メールでメールを送信させた件

前提：メール送信設定

お名前.comのメールを使って、

メールを送信することを行った。

その時の設定等のメモは、

以下の記事を参照。

LaravelでLang::getでのメール送信時の文字を変更した件

実際の送信処理の部分に関して、

フレームワークのコードを調べて、

JSONファイルを作成する対応をしていました。

この記事で紹介するテンプレートをカスタム化する方法でも、

実際に作れてしまうので、テンプレートの方が楽かと。

LaravelでLang::getでのメール送信時の文字を変更した件

Laravelでの設定の参考資料

今回の対応方法については、

以下のページに記載があったので、

一部、引用。

For this reason, 
Laravel also provides support for defining translation strings 
using the "default" translation of the string as the key. 
Translation files that use translation strings 
as keys are stored as JSON files in the lang directory. 
For example, 
if your application has a Spanish translation, 
you should create a lang/es.json file:

{
    "I love programming.": "Me encanta programar."
}

また、実際のページは、

以下から参照。

「Localization」のページ

Laravelの設定

Laravelへの実際の設定は、

以下の設定を実施。

コマンド

php artisan vendor:publish --tag=laravel-notifications

実行メモ

$ php artisan vendor:publish --tag=laravel-notifications
Copied Directory 
[/vendor/laravel/framework/src/Illuminate/Notifications/resources/views] 
To [/resources/views/vendor/notifications]
Publishing complete

この設定で、

テンプレートのファイルが、

上記の実行ログにもあるように、

/resources/views/vendor/notifications

のフォルダに作成されたので、

そちらを変更すると、うまくメール内容も変更されました。

LaravelでLang::getでのメール送信時の文字を変更した件

Laravelでメールを送信させるために、

デフォルトのフレームワークの機能を使って、

実際に送信した時に、

送られてくるメールの内容を、

変更した時のメモ。

前提：Laravelの環境構築

まず、前提として、

Laravelの環境構築を行った。

最終的に、

このような、

初期表示ができるところまで、

環境を構築できていることが前提。

ここまでの導入は、

以下の記事の一部を参考にしてもらいたい。

Laravelでお名前.comのお名前メールでメールを送信させた件

前提：メール送信設定

お名前.comのメールを使って、

メールを送信することを行った。

その時の設定等のメモは、

以下の記事を参照。

メール送信のフレームワークの対象コード

実際の送信処理部分の

メッセージ等を設定する箇所のコードを確認。

今回はリセット用のメール設定の部分を例。

ファイル

project/vendor/laravel/framework/src/Illuminate/Auth/Notifications/ResetPassword.php

コード

    /**
     * Get the reset password notification mail message for the given URL.
     *
     * @param  string  $url
     * @return \Illuminate\Notifications\Messages\MailMessage
     */
    protected function buildMailMessage($url)
    {
        return (new MailMessage)
            ->subject(Lang::get('Reset Password Notification'))
            ->line(Lang::get('You are receiving this email because we received a password reset request for your account.'))
            ->action(Lang::get('Reset Password'), $url)
            ->line(Lang::get('This password reset link will expire in :count minutes.', ['count' => config('auth.passwords.'.config('auth.defaults.passwords').'.expire')]))
            ->line(Lang::get('If you did not request a password reset, no further action is required.'));
    }

Laravelでの設定の参考資料

今回の対応方法については、

以下のページに記載があったので、

一部、引用。

For this reason, 
Laravel also provides support for defining translation strings 
using the "default" translation of the string as the key. 
Translation files that use translation strings 
as keys are stored as JSON files in the lang directory. 
For example, 
if your application has a Spanish translation, 
you should create a lang/es.json file:

{
    "I love programming.": "Me encanta programar."
}

また、実際のページは、

以下から参照。

「Localization」のページ

Laravelの設定

Laravelへの実際の設定は、

以下の設定を実施。

ファイル

package/resource/js/jp.json

設定

{
  "Reset Password Notification": "パスワードのリセット"
}

この設定で、

実際に送られてくるメールの文章が、

うまく設定した文字列に変更された。

Laravelでお名前.comのお名前メールでメールを送信させた件

Laravelでメールを送信させるために、

デフォルトのフレームワークの機能を使って、

実際に送信した時の設定等をメモ。

前提：Laravelの環境構築

まず、前提として、

Laravelの環境構築を行った。

最終的に、

このような、

初期表示ができるところまで、

環境を構築できていることが前提。

ここまでの導入は、

以下の記事の一部を参考にしてもらいたい。

お名前のメール

レンタルサーバと一緒に、

お名前のメールも使っているので、

そちらを今回は活用しました。

お名前.comのサイト

Laravelに設定

Laravelへの設定は、

以下の設定を実施。

ファイル

.env

設定

MAIL_MAILER=smtp
MAIL_HOST=xxxxx.gmoserver.jp
MAIL_PORT=587
MAIL_USERNAME=[setting mail acount]
MAIL_PASSWORD=[setting mail acount]
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=[setting mail acount]
MAIL_FROM_NAME="${APP_NAME}"

また、

メールアドレスのパスワードに、

特殊文字が含まれると、

Laravelの方でエラーになるので、

＆の特殊文字だけにしてアカウントを作成する必要がある。

LaravelでVue3+TypeScriptの環境で、使えそうだったライブラリ

Laravelの環境構築の際に、

Vue3+TypeScriptの環境で、

環境を構築していたのだが、

UI周りでコンポーネントを気軽に使える、

UIライブラリを試した時に、

個人的に使えると思ったものをメモ。

前提：Laravelの環境構築

まず、前提として、

Laravelの環境構築を行った。

最終的に、

このような、

初期表示ができるところまで、

環境を構築できていることが前提。

ここまでの導入は、

以下の記事の一部を参考にしてもらいたい。

No1. iSPA Element UI

コンポーネント数は、

すごく少ないですが、

Tailwindcssとの相性が良かったので、

個人的に使えると思いました。

インストール

npm install ispa-element

設定

import { createApp } from 'vue'
import iSPAElement from 'ispa-element'

const app = createApp(App)
app.use(iSPAElement).mount('#app')

試す

<template>
  <i-button>Default</i-button>
  <i-button type="primary">Primary</i-button>
  <i-button type="success">Success</i-button>
  <i-button type="info">Info</i-button>
  <i-button type="warning">warning</i-button>
  <i-button type="danger">Danger</i-button>
</template>

表示

このような感じで、

うまくシンプルなボタンが表示可能でした。

よければ、以下のページを参考に試してみてください。

iSPA Element UIのページ

No2. Equal UI

TypeScriptとの相性の観点で、

いくつか探して、

実際に試した中で、

自分の環境では、

こちらのライブラリがうまく挙動しました。

インストール

npm install equal-vue

設定

import { createApp } from 'vue'
import Equal from 'equal-vue'
import 'equal-vue/dist/style.css'

createApp.use(Equal)

試す

<template>
  <it-button>Button</it-button>
  <it-button type="primary">Button</it-button>
  <it-button type="success">Button</it-button>
  <it-button type="danger">Button</it-button>
  <it-button type="warning">Button</it-button>
  <it-button type="black">Button</it-button>
</template>

表示

このように、

うまくシンプルなボタンが表示可能でした。

よければ、以下のページを参考に試してみてください。

Equal UIのページ

小さな部署でもメンバー管理経験は転職アピール強な件

世の中に対して、

１人のエンジニアとして、

自己アピールをしていくときに、

「技術力」

というのは、

ベースとして必要だと思います。

しかし、

この「技術力」だけだと、

転職活動をしていく中で、

年齢を重ねていくほど、

難しい場面が出てくるなと感じています。

そこで、

アピールする中で、

実際にすごく強いなと感じたのが、

「マネジメント経験」

がアピールとして強かったという点です。

このアピールで強かった点としては、

技術力以外のヒューマンスキルとしてアピールできる
組織内で幅広く活躍できる人材としてアピールできる

というところが、

今まで転職活動を何回か行いましたが、

担当者に高評価を頂いて、

「ぜひ、一緒に働かないか」

と言っていただくことに繋がりました。

この点は、

エンジニアとしてのキャリア形成を考える方に、

少しでも参考になる部分もあるのではないかと思うので、

今までの経験を振り返りながら、

この記事にまとめておきます。

まずは、スキルがあることが前提

転職活動に関して、

エンジニアとしてアピールする上では、

やはり、

「スキルがあることが前提」

ということが言えます。

この点に関しては、

転職活動に取り組んできた中で、

自分自身が担当者の立場になったこともありますが、

自分が採用して「もらう」側で、担当者に「求められるスキル」
自分が採用を「する」側で、面接者に「求めるスキル」

ということを経験して、

どちらの経験から考えても、

やはり、

やはり、一緒に働くメンバーとしては、
組織で使用する技術に関して、
最低限求められる水準の技術力を持っていること大切

と考えています。

スキルを磨いていくことで、

色々な企業で求められる技術の水準をクリアでき、

転職活動を行いやすくすることができます。

スキルにプラスアルファの経験を足す

スキルをずっと磨いていくことは前提ですが、

転職活動を何回か行っていますが、

スキルにプラスアルファの経験を足す

ということが、

転職活動の中で、

このちょっとした経験を足したことで、

年収の増加につながる経験をしました。

この点は、

自分が面接する側の立場になった時に、

実際によくわかってきたことですが、

このようなやりとりが時々、起こってました。

人材が欲しいけれど、
何人かいい人いたかね？

この〇〇という人は、
スキル以外にも、▲▲の経験があるので、
うちの組織で開発以外でも、
色々と助けてくれると思いますよ。

という形で、

面接の担当者として、良い人材だとプッシュしやすくなりました。

この点は、

ちょっとしたプラスアルファの経験が大きな違いを生むのだなと、

採用する側になることでわかってきたことです。

たった４人のメンバーマネジメントの経験が大きかった

実際に自分が転職活動をしていく中で、

採用してもらった企業に、

入社後に聞いたことですが、

〇〇さん、そう言えば、自分の採用に関わってましたよね。
なんで、自分を採用してくれたんですか？

あー、正直なところ、
同じような年齢やスキルを持った人は何人か、いたんですよ。
けど、□□さんだけ、少人数ですがマネジメントの経験があったので、
そこが採用の決め手になりましたね。

ということを聞きました。

聞いた時は、

もう少し、オブラートに包んで欲しいとは思いましたが、

自分が採用する側になることで、

この時、言われたことがすごく腑に落ちています。

この

「４人のメンバーのマネジメントをしたことがある」

という経験は、

転職活動の最初のうちは、

「正直、転職活動には使えない」

と思っていました。

しかし、

他の企業で面接に携わっている知人に、

ちょっとした経験に見えるかもしれないけど、
採用する側としては、すごく大きな経験だよ。

ということを言われて、

そんなもんなのかなぁ….。
ただ、アピール材料になるようなら、
転職活動でアピールしてみるよ。

という形で、

実際に転職活動の中でアピールしていくと、

すごく評価されることが多くありました。

このようなちょっとした経験と思っていても、

採用する側から見た時に、

大きな違いになることがあるので、

自分が得た、ちょっとした経験でも、

アピール材料として、しっかりとアピールすることが、

採用の結果を左右することがあるので、

意識していくと良いですね。

小さな経験でも持っていることで任せられる

最初は小さな経験だと思っていた、

「４人のメンバーのマネジメントをしたことがある」

ということが、

実際に転職してみることで、

この小さな経験があることで、

社内にマネジメントができそうな人がいないので、
〇〇さんにお願いしたいんだけど、
やってもらえたりしないかな？

あ、自分でも良ければいいっすよ。
けど、フォローしてくださいね。

おっけーっす。
自分もサポートするんでよろしくです

という形で、

最初のちょっとした経験があることで、

「小さな経験が次の新しい経験を運んでくる」

ということが言えます。

任せる側も、

今までの経験をもとに任せてくるので、

転職活動の中では、

実際に経験した事実を共有する（誇大に共有しない）
得意／苦手の部分を共有する（自己の性格上の特性を伝えておく）

ということを意識して、

アピールするようにしておくと、

嘘偽りない情報になるので、

採用される側、採用する側の両方に有意義な情報になります。

小さな経験も忘れずに、事実としてアピールしよう

今までの経験の中で、

経験した小さなことは、

本当は有意義なアピール材料でも、

人間なので忘れていることがあります。

これを防ぐためにも、

「自分の職務経歴書は常に最新にしておく」

ということがおすすめです。

そして、

ちょっとした経験であっても、

「面接のタイミングで誇大にならないように事実として伝える」

ということを意識して、

面接してもらう方に伝えるようにしていくと、

判断される時に影響を及ぼすことがあるので、

意識して取り組んでいくと良いでしょう。

Laravelの認証周りをStarter Kitsで導入してみる

Laravelの環境構築の際に、

ログイン周りの機能は、

システム開発で使うことがあるのだが、

LaravelのStarter Kitsで、

認証周りを簡単に作成できるようなので、

導入して試してみる。

前提：Laravelの環境構築

まず、前提として、

Laravelの環境構築を行った。

最終的に、

このような、

初期表示ができるところまで、

環境を構築できていることが前提。

ここまでの導入は、

以下の記事の一部を参考にしてもらいたい。

LaravelのStarter Kits

実際に導入する、

LaravelのStarter Kitsですが、

公式サイトに記載があるので、

そちらを使って試すので、

公式サイトもチェックしておきましょう。

Starter Kitsのページ

Starter Kitsを導入してみる

実際に試したことをメモしていく。

まずは、

Composerでパッケージをインストール

composer require laravel/breeze --dev

を実行。

composer.json

で確認すると、

{
    "require-dev": {
          :
        "laravel/breeze": "^1.8",
          :
    }
}

となっているので、大丈夫。

次に、

artisanコマンドでLaravelに導入

php artisan breeze:install

実行すると、

$ php artisan breeze:install
Breeze scaffolding installed successfully.
Please execute the "npm install && npm run dev" command to build your assets

となるので、

Breezeのベースとなる部分のインストールが完了。

インストールされたものを、

webpackでコンパイルしていく。

必要パッケージインストール。

npm install

コンパイル。

npm run dev

コンパイル自体は、

0|admin  | ✔ Compiled Successfully in 1789ms
0|admin  | ┌───────────────────────────────────┬──────────┐
0|admin  | │                              File │ Size     │
0|admin  | ├───────────────────────────────────┼──────────┤
0|admin  | │                        /js/app.js │ 694 KiB  │
0|admin  | │                       css/app.css │ 28.6 KiB │
0|admin  | └───────────────────────────────────┴──────────┘
0|admin  | ✔ Mix: Compiled successfully in 1.84s
0|admin  | webpack compiled successfully

でうまくできている。

DBのマイグレーション。

php artisan migrate

マイグレーション自体も、

問題なく完了した。

導入されたStarter Kitsの認証画面を確認してみる

ログイン画面のURL

/login

これを確認すると、

このようになって、

登録画面

/register

についても、

このように、

いい感じに認証周りのページを作ってくれる。

Vue3のUI Frameworkとして「Vuestic-UI」を導入する

LaravelとVueの組み合わせの環境は、

システム開発で使うことがあるのだが、

この環境構成で、

環境構築をした際に、

Vueのバージョンを３系に変更したので、

その３系に合うUI Frameworkを探していたところ、

「Vuestic-UI」

というのが個人的に良さげだと思って、

実際に導入してみたときのメモ。

前提：LaravelでVue3の環境構築

まず、前提として、

LaravelでVue3の環境構築を行った。

環境の中で、Vueのバージョンとしては、

{
    "dependencies": {
        "vue": "^3.2.31"
    }
}

このように、

バージョンが３系で動くようになった。

ここまでの導入は、

以下の記事を参考にしてもらいたい。

14 Best Vue UI Component Libraries 2022

Vue3に対応するUI Frameworkを探す

実際にVue3に関して、

対応しているUI Frameworkを探していたところ、

参考になる記事を見つけたので、

参考にしてもらえればと思います。

Vuestic-UIを導入してみる

実際に試したことをメモしていく。

まずは、

NPMでインストール

npm install vuestic-ui

を実行。

package.json

で確認しても、

{
    "dependencies": {
        "vue": "^3.2.31",
        "vuestic-ui": "^1.3.4"
    }
}

となっているので、大丈夫。

次に、

Webpack周りで設定を追加していく。

project/resource/js/app.js

または、Typescriptなら、

project/resource/js/app.ts

のファイルを調整する。

Vuestic-uiのGithubに参考として載っているコード。

import { createApp } from 'vue'
import App from './App.vue'
import { VuesticPlugin } from 'vuestic-ui' //(✓)
import 'vuestic-ui/dist/vuestic-ui.css' //(✓)
//...
const app = createApp(App)
app.use(VuesticPlugin) //(✓)
//...

自分の環境で変更した結果。

import { createApp } from "vue";
import App from "./App.vue";
import { VuesticPlugin } from 'vuestic-ui'
import 'vuestic-ui/dist/vuestic-ui.css'

const app = createApp(App)
app.use(VuesticPlugin);
app.mount("#app");

require('./bootstrap');

ここまでで、

導入作業は完了。

試しにVuestic-UIのコンポーネントを使ってみる

Vuestic-UIのコンポーネントとして、

Alertのコンポーネントを試してみる。

Vuestic-UIのサイトで、

この表示を試してみる。

実際の試したコード。

<template>
  <div>
    <h1>Vue 3 App</h1>
    <div>
      <va-alert dense color="success" class="mb-4">
        Dense alert.
      </va-alert>
      <va-alert dense color="info" class="mb-4">
        Alert with color style.
      </va-alert>
      <va-alert dense color="warning" outline class="mb-4">
        Alert with outline style.
      </va-alert>
      <va-alert dense color="danger" border="top" border-color="danger" class="mb-4">
        Alert with colorful border.
      </va-alert>
    </div>
  </div>
</template>

こちらを試したら、

このように表示されたので、

うまくいっているようなので完了。

参考リンクまとめ

最後に、

参考にしたページのリンクをまとめておく。

「Vuestic-ui」のページ

「Vuestic-ui」のGithub

社内情報の整理で、Backlogの機能が豊富でよかった件

社内情報が整理できていないと、

何かと聞かれた時や、

自分自身が確認するときなど、

無駄な時間が発生することがよくあります。

そのような社内の情報は、

あのシステムのログインのURLってなんでしたっけ？

とか、

このタスクっていつ終わるんでしたっけ？

というようなことが、

社内情報や各種ステータスなどを含めて、

色々とシステム管理の方に流れてくることが多いです。

そんな中で、

社内情報の整理をしていく中で、

「Backlog」

「Backlog」のページ

を使って整理していました。

イメージとしては、

こんな感じで、

実際はもう少し、細かくファイルが分かれていますが、

「〇〇に関するURLの一覧」

のような感じで、

そのファイルを開くと、

イメージとしては、

こんな感じで、

対象の概要
対象のリンク

という感じで、

すごくシンプルな形で、

一覧形式にまとめるような運用でした。

社員ごとにまとめ方が違うなどの問題が発生

上記のような形で、

Googleドライブの中で、

スプレッドシートが、

上記のように、

「〇〇についての一覧」

みたいなファイルがたくさん増えていきました。

そうなっていくことで、

何が問題になってくるかというと、

「社員ごとにファイルのまとめ方が違う」

という点と、

「記載している内容が重複している」

ということが大きく問題となりました。

特にまとめ方が違うという点の方が、

確認をする上でも非常に大変でした。

整理するために「Backlog」を導入

そもそも、

情報を管理していく中で、

Googleドライブの中で、

スプレッドシートで管理していくと、

ファイルが無限に増えていく
プロジェクト単位などでフォルダ分けが面倒
決まったフォーマットを作るのが面倒

などの問題があったので、

外部ツールを色々と検討する中で、

「Backlog」のページ

この「Backlog」というツールを、

社内情報の整理のために導入しました。

導入理由として、

実際にメインで使う機能としては、

各種リンク等を整理するための「Wiki機能」
タスク等を管理するための「タスク管理機能」

の２つの機能が、

すごく使いやすそうで、

導入することにより、今までの煩雑な情報管理が、

１つのサービスで管理できると考えたからです。

各種リンク等を「Wiki」機能でわかりやすく管理

BacklogのWikiの機能を使って、

実際のWikiのページを作ると、

このような感じで、

わかりやすく情報を整理することができます。

また、

BacklogのWikiは、

Markdownという書き方を使っており、

最初は慣れるまでが大変ですが、

一般社員でも使い方に慣れていくことで、

いろいろな書き方で整理することができるので、

各プロジェクトや内容ごとに、

フォーマットを決めて管理していくことができます。

社内では、

「〇〇をまとめるための参考ページ」

みたいな形で、

対象のWikiページを作るための雛形のページを、

いくつか準備しておくことで、

必要な情報だけ書き換えると良い状態にして、

運用も楽になるように取り組んでいます。

タスクなどは、Backlogの「タスク管理」の機能でわかりやすくなった

社内のTodoやタスクなど、

スプレッドシートに、

内容とステータスなどを書いていましたが、

内容が増えていく中で、

タスクのステータス管理が大変
自分が対象のタスクがわかりにくい
タスクごとにメモが残しにくい

ということが、

スプレッドシートで運用していくなかで、

問題になることが多かったです。

この点を解消するために、

Backlogの「タスク管理」を使うことで、

このように、

タスクをわかりやすくステータスごとに色がついていたり、

という形で、

変更された内容が、

Backlogの管理画面に入ると表示されており、

メールでも通知が来るので、

自分自身が対象の内容がわかりやすく、

対応漏れもすごく減ったので、

非常に効果的だったと思います。

また、

それぞれのタスクを、

という形で、

タスクの「開始日」
タスクの「終了日」

を入れておくことで、

プロジェクト内のタスクに関して、

このように、

シンプルにわかりやすく表示してくれるので、

ミーティングの際の進捗確認や、

これからのスケジュールの相談など、

すごく便利で助かる部分が多かったです。

Backlogで使いこなせてない機能もまだある

実際に社内にBacklogを導入してから、

社内の情報管理に関しては、

以前よりも、情報共有がスムーズになったと思います。

この記事で紹介した機能以外にも、

いくつも便利な機能があり、

Backlogの公式サイトに紹介されていますので、

気になる方は、公式サイトの機能情報を確認したり、

無料で試したりするなど、運用に活用できるか試してみると良いですね。

社内で運用してみて、

色々と、「こういう風な運用になった」などはあるので、

その辺りも、これから共有していければと思います。

「Backlog」のページ

Laravel-mixにTypeScriptを導入する

LaravelとVueの組み合わせの環境は、

システム開発で使うことがあるのだが、

この環境構成に加えて、

「TypeScript」

についても導入を行いたいと思って、

実際に試した時のメモ。

前提：Laravel8+Vue3の環境構築

まず、前提として、

Laravel8+Vue3の環境構築を行った。

Laravelの画面表示は、

こちらのバージョン表示が、

Laravel8での導入を行った。

併せて、

Vue3についても導入を行い、

{
    "dependencies": {
        "vue": "^3.2.31"
    }
}

パッケージ管理上で、

上記のようにバージョンが３系で動くようになった。

ここまでの導入は、

以下の記事を参考にしてもらいたい。