もがき系プログラマの日常

もがき系エンジニアの勉強したこと、日常のこと、気になっている技術、備忘録などを紹介するブログです。

Laravel env:encrypt を試してみた

はじめに

こんばんは。

Laravelで知らない機能があったので試してみました。

laravel.com

本題

Laravel 9.32.0 以降では、.env ファイルを暗号化できる機能が追加されてるみたいです。

だいぶ前の機能だなおい。

知らなくてごめんなさい。

暗号化してみる

まず暗号化コマンドを実行します。

$ php artisan env:encrypt

 ┌ What encryption key would you like to use? ──────────────────┐
 │ Generate a random encryption key                             │
 └──────────────────────────────────────────────────────────────┘

   INFO  Environment successfully encrypted.  

  Key .......................................................................................... base64:h1SEMkC5MxPgL+WD0niElLR4qh0wRn+N1ujjc6FzZb8=  
  Cipher ............................................................................................................................... AES-256-CBC  
  Encrypted file .................................................................................................................... .env.encrypted

これで .env.encrypted というファイルができます。

このファイルは .env 全体が暗号化されたものなので、これを Git にコミットしても安全です。

復号してみる

次に復号化してみます。

$ php artisan env:decrypt

 ┌ What is the decryption key? ─────────────────────────────────┐
 │ •••••••••••••••••••••••••••••••••••••••••••••••••••          │
 └──────────────────────────────────────────────────────────────┘

   INFO  Environment successfully decrypted.  

  Decrypted file .............................................................................................................................. .env

暗号化したときに表示された Key を入力すると、.env ファイルが復号されます。

チーム開発での使い方

この機能の便利なところは:

  1. 新メンバー参加時: 暗号化された .env.encrypted は Git にあるので、Key だけ共有すれば復号できる
  2. 環境変数追加時: .env を更新して暗号化してコミット。他メンバーは pull して復号するだけ
  3. セキュリティ: 暗号化された状態で Git 管理できるから、履歴にも残せる

Key の管理は 1Password とかで共有すれば良さそうですね。

dotenvx というツールもあるらしい

調べてると dotenvx というツールも見つけました。

dotenvx.com

こっちは言語非依存のツールで、Laravel じゃなくても使えるみたいです。

Laravel との違い

違いをざっくりまとめると:

Laravel env:encrypt:

  • Laravel 専用の機能
  • .env 全体を暗号化して .env.encrypted という別ファイルに保存
  • キー名も含めて全部暗号化される

dotenvx:

  • 言語非依存(Node.js、Python、Ruby など全部で使える)
  • .env ファイル内の各変数の値を個別に暗号化
  • キー名は見えるけど、値だけが encrypted:xxx という形式で暗号化される

どちらも同じ課題(チーム開発での .env 共有)を解決するけど、アプローチが違うって感じですね。

Laravel 使ってるなら標準機能で対応できるし、他の言語も使うプロジェクトなら dotenvx の方が良さそう。

まぁ自分はLaravelプロジェクトばっかりなんで dotenvx使う場面は今のところをなさそう...

終わりに

チーム開発での .env 共有問題、地味にストレスだったので、こういう機能があるのは助かります。

新メンバーに「Key送るから復号しといて」で済むのは楽ですね。

ではでは。

yarn audit fixがないの知らなかった。

はじめに

yarnでパッケージ管理しているプロジェクトでセキュリティチェックをしたところ、だいぶ色々でてきたので対応した備忘録です。

本題

ある日 yarn audit すると、色々でてきました。

おもむろに yarn audit fix すると存在しないと言われました。

npmなら npm audit fix 叩いてたのでyarnでも出来ると勝手に思い込んでました。

調べてただこの問題は2019年から議論されているようらしい。

参考: GitHub Issue #7075

まぁあんまりフロントエンド界隈はわからないので、ざっと調べなので間違ってたらすいません。

解決方法

なんか色々と解決できそうな方法があったけど

自分が使った方法は npmを一時的に使う方法にしました。

手順は以下の通り:

# 1. npmの管理ファイル(package-lock.json)を一時的に作成
npm i --package-lock-only

# 2. yarn.lockを削除
rm yarn.lock

# 3. npmで脆弱性を修正
npm audit fix

# 4. npmの管理ファイルをyarnに変換
yarn import

# 5. 不要になったnpmの管理ファイルを削除
rm package-lock.json

これで、yarnを使いつつnpmの機能を借りて脆弱性を修正できるみたい。

他の選択肢

yarn-audit-fix というnpmパッケージも存在するみたい。

github.com

ただ、これは公式のソリューションではなく、サードパーティ製のようなので、ちょっと怖くて辞めました。

更新はされてるっぽいけどね。

終わりに

久しぶりに yarn管理のプロジェクト触ったのでちょいハマりました。

ではでは。

何を言うかじゃなく誰が言うかを体験した。

本題

最近まさにこれを体験しました。

ある日、チームで議論になりました。

僕は「Aの方法が良いと思う」と提案しました。

しかし、他のメンバーからは「いや、Bでしょ」という意見が出ました。

僕はあまり納得していなかったのですが、多数決だったので「B」という方針に決まりました。

ところが後日、上の立場の人にこの話をしたところ、「Aの方が良いんじゃない?」と言われ、あっさり「A」に変更になりました。

そして、最初に「Bでしょ」と言っていた人たちも、「そうだよね、Aだよね」と言い始めました。

同じ内容でも、「誰が言うか」で結論が変わるってことですよね。

有名な話ですけど、実際に目の当たりにすると、改めて組織の現実を突きつけられた気がしました。

終わりに

あんまりにも納得いってなかったんで、他のエンジニアさんに相談したところ本を紹介されました。

人生は、運よりも実力よりも「勘違いさせる力」で決まっている

人生は、運よりも実力よりも「勘違いさせる力」で決まっている

Amazon

とりあえず、次のこういった機会のためにこの本読んで準備しとこうと思います。

では。

Django触ってみた続き

最初に

前回はモデル定義とマイグレーションまでやったので、今回は管理画面を触ってみました。

本題

superuser作成

$ python manage.py createsuperuser
Username: admin
Email address: admin@example.com
Password: 
Password (again):
Superuser created successfully.

管理画面にアクセス

http://127.0.0.1:8000/admin/ にアクセスしたら、ログイン画面が出る。

モデルを管理画面に登録

blog/admin.py にこんな感じでかく。

from django.contrib import admin
from .models import Post

admin.site.register(Post)

Postモデルが管理画面に出てきた。

Laravelとかは標準では入ってないから、楽っちゃ楽。

ぶっちゃけそのまま使うのって、そんなに経験ないけど。

終わりに

Djangoの管理画面簡単だった。

まあこのあたりはまじで手が回っている感じある。

買った本めっちゃ簡単でもう読んじゃったので、次はGo言語やろうかな

現場からは以上です。

一度決まったことを、もう一度相談する勇気

はじめに

仕事をしていると、こんな場面に出くわすことがありませんか？

クライアントと打ち合わせをして、ある方針で「よし、これで行こう」と決まった。

でも、実際に作業を進めていくうちに、「あれ？この方向性、本当に正しいのかな？」と疑問が湧いてくる。

もっと良い方法があるんじゃないか...でも、一度決まったことを今さら...

結構あるあるじゃないかなと思います。

本題

こういう時、頭の中でこんな２つの声が聞こえてきます。

慎重派の声:

  • 「一度決まったことなんだから、今さら言うべきじゃない」
  • 「クライアントの意向を尊重すべきだ」
  • 「蒸し返すなんて、面倒くさい人だと思われるかも」

責任感の声:

  • 「専門家として、より良い方法を知っているのに黙っているのは無責任では？」
  • 「後で問題になるくらいなら、今言うべきでは？」
  • 「クライアントのためにも、正直に伝えるべきだ」

僕もこういった場面はよく出くわします。

慎重派の声と責任感の声が頭の中で聞こえてきて、いつもすごく悩みます。

「一度決まったことを覆すなんて...」という気持ちと、「でも、これは言わないと...」という気持ちがいつも綱引きをしています。

どう判断するかっていうのは時と場合だと思いますが、極力僕は提案することにします。

その際の自分の中で決めていることはいかです。

1. 謙虚な姿勢で伝える

例えば「一度お決めいただいた内容について、改めてご相談したいことがありまして...」といった形で、まず謙虚な姿勢を示すことを心がける。

あくまで「より良くするための相談です」というスタンス。

2. 理由を明確にする

「なぜそう思うのか」を具体例を踏まえて伝える。

  • 他の事例
  • 将来的なメリット・デメリット

感情ではなく、客観的な根拠を示して、しかし、ポジショントークになりすぎないよう細心の注意を払う。

3. 押し付けない

あくまで「再検討の余地があるのではないか」という提案であり、最終判断はクライアントに委ねる。

「こうすべきです」ではなく、「こういう選択肢もありますよ」というスタンスで話す。

終わりに

とにかく「伝え方」が一番大事だと思います。

丁寧に、理由を添えて、「より良くするために」という姿勢で伝えれば、きっと相手も耳を傾けてくれます。

そして何より、「後で後悔するくらいなら、今言おう」この勇気が、必要なのだと感じました。

一度決まったことを覆すのは、確かに勇気がいります。

でも、冷静に、誠意を持ってて伝えれば伝わるはずだと思います。

もし馬鹿にされたりしたら、そんな会社はやめてしまいましょう。

ではでは。

DjangoのModel定義とマイグレーションやってみた

最初に

前回はプロジェクトを立ち上げただけだったので、今回はモデル定義とDB周りを触ってみました。

本題

アプリケーション作成

$ python manage.py startapp blog

Djangoでは機能ごとに「アプリ」を作る思想らしい。 ほぇ〜

モデル定義

blog/models.py にこんな感じで書いてみた。

from django.db import models

class Post(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

PHPエンジニアとして感じたこと

  • マイグレーションファイルを自動生成してくれるの、めっちゃ便利
  • CharField, TextField とか型が明示的。
  • auto_now_add と auto_now で自動的にタイムスタンプ管理できるのはいい。
  • PHPの $this-> みたいなのが self. になってて、最初戸惑った
    • まぁここはなれか。

マイグレーション実行

$ python manage.py makemigrations
$ python manage.py migrate

makemigrations でマイグレーションファイル作成、migrate で実行。

Laravelの php artisan make:migration と php artisan migrate と一緒。

詰まったポイント

終わりに

Laravelと比較しながらやると、理解が早い気がする。 次ものんびりやっていきます。

Djangoやってる

最初に

今回はDjangoに手を出してみました。 Pythonのフレームワークに触れてみた初期段階の感想です。

本題

プロジェクト作成

$ django-admin startproject myproject
$ cd myproject
$ python manage.py runserver

実行したら、とりあえずサーバーが起動。 http://127.0.0.1:8000/ にアクセスしたら、Djangoのウェルカムページが表示されました。

初期段階の感想

  • settings.py で一元管理する思想は、LaravelのConfigに近い感じ。
  • MVTパターン(Model-View-Template)って名前やけど、要はMVCやな。Viewがコントローラーみたいな立ち位置？
  • マイグレーションがフレームワーク標準なのはやっぱやりやすいと感じる。
  • インデントでスコープが決まるPython、まだ慣れない...

とりあえず動いたので、次はモデル定義とかDBまわりを触ってみます。

終わりに

とりあえず最初ということで。

次からもやる気出していきます。