Homebrew の pyenv/rbenv/goenv/nodenv/tfenv を anyenv に一本化する移行手順
Homebrew で個別にインストールした pyenv, rbenv, nodenv, goenv, tfenv を anyenv に統合する。シェル設定がスッキリし、brew upgrade による依存関係破壊(expat 問題など)も回避できる。
Homebrew で個別にインストールした pyenv, rbenv, nodenv, goenv, tfenv を anyenv に統合する。シェル設定がスッキリし、brew upgrade による依存関係破壊(expat 問題など)も回避できる。
CloudWatch Logs のログ配信チェックで、nginx の access.log が数日間 0 bytes のままだった。実際にはアクセスがあるのにログが記録されていない状態。
「エンジニアみんなでスカウトメール打ちましょう」をやって、成果ゼロだった経験がある。なぜ失敗したのか、構造的に整理する。
apt update 実行時に以下のようなエラーが出る。
- brew upgrade で Python 3.14 に上がった後、aws コマンドが Symbol not found: _XML_SetAllocTrackerActivationThreshold で死ぬ - brew reinstall --build-from-source python@3.14 でソースビルドすれば直る - 再発防止に brew pin python@3.14
staging と production で同じ VPC CIDR(例: 10.0.0.0/16)を使っていると、普段は問題なくても将来的にハマるポイントがある。
チーム共有 → ルートの CLAUDE.md をコミット 個人カスタマイズ → .claude/CLAUDE.local.md 全プロジェクト共通 → ~/.claude/CLAUDE.md 個人プロジェクトで dotfiles 管理 → ルートの CLAUDE.md を symlink
ElastiCache Redis のパッチ(service update)適用時にどの程度のダウンタイムが発生するのか、公式ドキュメントと実測結果をまとめる。
verify-ai の UI を bdiff に寄せる作業をしていた。テストは414件全パス、実装も完了した。しかしブラウザで確認すると、入力フォームの Source と Target が縦に並んだまま。さじを投げた。
GitHubのプロフィールページ(github.com/ユーザー名)にカスタムREADMEを表示できる機能。 自己紹介、技術スタック、リポジトリの紹介などを自由にMarkdownで書ける。
接続が重い DB(PostgreSQL, MySQL)→ 接続プール 接続が軽い DB(SQLite)→ リクエストごと生成・破棄 Railsがプールをデフォルトにしているのは PostgreSQL/MySQL 前提だから
- Neovim + LazyVim でファイルツリー・タブ・LSP・ファジー検索が最初から揃う - neo-tree をカスタマイズすると、ツリーでカーソル移動するだけでプレビュー表示される VS Code 的な体験が得られる - micro や helix も試したが、プロジェクト単位のコード閲覧には Neovim が一番完成度が高い
- Target Tracking の複数ポリシーは scale-in が AND 動作(全ポリシーが合意した時のみ縮退) - Simple Scaling の複数ポリシーは scale-in が 独立発火(各アラームが個別に scale-in を実行) - CPU と Passenger メトリクスを Simple Scaling で併用した結果、Passenger で scale-out し…
LD_LIBRARY_PATH は本番の恒久設定に使うものではない。ビルド時の RPATH 埋め込みかld.so.conf.d + ldconfig で解決する PKG_CONFIG_PATH はビルド時専用。本番実行 env に存在する時点で、ビルドと実行の分離ができていない /usr/local/lib の解決に LD_LIBRARY_PATH が必要になった時点で、ldconfig 未実行…
「90日間は、何もするな。」というリーダーシップの考え方がある。元ポストでは、ハーバード流マネジメント講座「90日で成果を出すリーダー」を引用しつつ、新しい組織に入った際の最初の90日間で実践すべき4つのことが紹介されている。自分は真逆の「即動く派」だが、過去の経験を振り返ると学ぶことが多かった。