最近業務内外問わず色々な記事を読んだりして知見がたまってきてるが、アウトプットする時間がなかなか取れず、もったいないのでせめて、URLをメモっておいておこうという戦略。 メモして公開しておけば、後から探すときに探しやすくシェアもしやすいなと思ったので、やってみる。 日付にはこだわらず、そういえばこないだ読んだなーってのもてきとーに乗せてく。 後で読んだ感想とか、追記していけたらいいなー。
友人のブログ
16進数から色を当てるやつめっちゃムズイ
DRY原則のやつ、話題になってたので読んだ
phpcon2017に参加したのでざっくりメモ。
※参加しながらのメモなので随時更新します。
スライド：
PHPを実行時はバイトコード命令にコンパイルして逐次実行している。
キャッシュ済みならキャッシュからバイトコード命令を実行する
キャッシュ済みでないならコンパイルしてキャッシュする
コンパイル時に最適化しておけばはやくなるんじゃね？これだ！！
PHP7.2にしよう！！
過去にもリプレースしようとしたが、２年かかる見積もりだったので、ペンドになった。 要因としてソースコードが肥大化していた。ソースコード全体で約60万行くらいあった。
今あるユニットテストを動くようにする。Nginx + php-fpmで動くようにする。
段階的にあげるように戦略を立てた。 推進者一人、インフラ担当一人、アプリエンジニア一人。
アップグレードシェルの実行だけでは動かなかった。変更点のドキュメントを読み修正していく必要があった。 ヘルパーの仕様が変わってた部分については、ラッパークラスを作成する事で対応していった。
アップデートしたブランチを作成し、そこで動作確認しつつ修正を加えていく。 毎週masterから差分を取り込むのが大変、、同じような修正が必要になる。 →オレオレUpgradeShellを作った。
事前にCakePHP1.3でできることは先にやっていく。
まとめて切り替えるのではなく、1コントローラーずつ以降していく事で安全に切り替える。 →1.3と2.8の同居をさせるためにindex.phpに細工を入れる。
PHPのバージョンアップはカナリアテスト。CakePHPのバージョンアップは2バージョンを用意しながら少しずつ進めていく。Codeceptionを利用していく。ユニットテストも2バージョンを用意していく。
スライドは後日公開されるらしい
※諸説ある - イベントドリブン - サーバ単位ではなくイベント単位 - ステートレス - 実行後のコンテナは破棄されるのでステートレスなアーキテクトが求められる
いわゆるLAMPアーキテクチャでは開発者がOSから環境まで、管理する必要がある。 それに対してサーバレスアーキテクチャではイベントを管理、実行を管理する必要がある。 開発者は動くための関数だけを管理すれば良い。
インフラもアプリも一括管理できるデプロイツール
tipsみたいなもの - POST with config - 設定値もステートなので、POSTに含めてしまう - Reserved Timestamp ID - 実は一覧を作るのは難しい - S3を使っている - Instant Job Queue - S3 Object Tagging - Env Sync - デプロイ時の環境変数とfunctionが実行されるコンテナの環境変数に設定する
サーバレスアーキテクトが得意なものとLAMPアーキテクトが得意なものは違う。サーバレスアーキテクトがハマると強力。 Serverless Frameworkを使うとインフラもコードで管理できる。
価値あるコードをよりよくしたい
phpmd, phpcpd, phpdcd, phpcs, phan などを使い複雑そうなところを見つける
アプリケーションベース例外にユーザ向けのメッセージを表示するためのメンバ変数を定義している。 ロギングも例外の中でやってくれるようにしているので、例外を投げるだけでいい。
パフォーマンスモニタリングもできる。 エラーがどこでどれだけ起きてたかなどを見れる。
PHPStormつかってます。
phpcs + php7ccで洗い出しつつ基本はマニュアル読みながら修正。
どんどん使用していないものは削除。テストも合わせて消す。
遅いテストは生産性を落とす。
Redashにたよる。「それRedashでよくない？このクエリでデータ出せますよ」
「最良のコードは、コードなし」いらないコードはどんどん消そう。コードなしで機能を提供できるならない方がいい。
外部ツールにうまく頼ろう！！
PSR-1,2準拠 + php-cs-fixerのci組み込み
@deprecatedをうまく使い、非推奨なコードを明示。消す前に@deprecated入れて本番で出てないかログを見ることで安心して消せる。
まずは守りを固めて、より良いコードをかける体制を作っていく。
必要な事 - ローカルでコンテナを作成 - レジストリにコンテナをPUSH - 本番にリリース
K8S, GKE
マネージドな環境をつかうことで簡単にできる
メモ： 複数のphpのバージョンで実行結果を見ることができるらしい。便利そう。 3v4l.org
php7ではパースした時点でエラーになりうるものをエラーとして扱ってくれる。php7は賢いので。 (絶対実行されないif文の中でも)
php5ではExceptionまたはExceptionを継承したクラス
php7ではThrowableを継承したクラス
エラーと例外(エラー)が混在していて扱いが面倒なので、例外(エラー)に統一してやると楽。
開発時、ユニットテストのときはE_ALLで指定してやって、本番ではE_ALL & ~E_NOTICE & ~E_DEPRECATEDしてやるとよい
手元のMacBookPro上にtmuxを導入してクリップボード共有する記事はよく出てくる。 しかし、自分の場合VPS上で作業することが多いので、VPS上に環境構築をしたいと考えた。 （出先や、違うPCから作業することもあるため、手元のマシンに構築するのが面倒だった。） VPS上のCentOS7上にtmux2.5を導入した上でローカルマシンとクリップボードの共有しようとしたが、 意外と記事がなくハマったので記事として残しておこうと思う。
| ローカルマシン | MacBookPro |
|---|---|
| リモートマシン | CentOS7.3 |
| tmux | 2.5 |
※tmuxはすでに導入済みとする
$ sudo yum install -y xsel --enablerepo=epel
$ vim /etc/ssh/sshd_config X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost yes
のようにしておく
$ sudo systemctrl restart sshd
$ vim .tmux.conf bind-key -T copy-mode-vi y send-keys -X copy-pipe-and-cancel “xsel -ib”
xquartz をインストール$ brew update $ brew cask install xquartz
$ open /Applications/Utilities/XQuartz.app # ~/.Xauthorityを作成してくれます
$ sudo xhost your.server.name
リモートマシンにログインして動作確認する。
$ cat /etc/redhat-release | xsel -bi
実行後にローカルマシンで貼り付けして CentOS Linux release 7.3.1611 (Core) のように出ていれば問題ない
ローカルで適当なものをコピーしてリモートで xsel -bo でコピーしたものが出力されていれば問題ない
上記の手順でtmuxの設定もしてあるので、そのままtmux上のキーバインドでコピペできます。
※tmuxの設定再読み込みしておくことをお忘れなく
お疲れ様でした。
laravelのスケジュールをcronに設定したのに動かなかったので原因調査をした。 その時のメモ
crontab は下記の状態
$ crontab -l * * * * * php /project/path/artisan schedule:run >> /dev/null 2>&1
とりあえずcronが動作しているかを確認した
$ systemctl status crond
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2017-06-17 21:18:06 JST; 2 days ago
Main PID: 1927 (crond)
CGroup: /system.slice/crond.service
└─1927 /usr/sbin/crond -n
→動いてそう
$ tail -f /var/log/cron Jun 20 18:08:01 133-130-116-162 CROND[17721]: (deploy) CMD (php /project/path/artisan schedule:run >> /dev/null 2>&1) Jun 20 18:09:01 133-130-116-162 CROND[17773]: (deploy) CMD (php /project/path/artisan schedule:run >> /dev/null 2>&1)
→動いてそう
出力する設定に変更し確認する
$ crontab -e php /web/pengin-news/current/artisan schedule:run >> /project/path/storage/logs/cron.log 2>&1 $ $ tail -f /project/path/storage/logs/cron.log /bin/sh: php: command not found /bin/sh: php: command not found
→こいつや！！！！
どうやらcronが実行される際のpathが下記になっているようでした
# 確認方法 $ crontab -e */1 * * * * printenv > /tmp/printenv.txt $ cat /tmp/printenv.txt SHELL=/bin/sh USER=vagrant PATH=/usr/bin:/bin PWD=/home/vagrant LANG=en_US.UTF-8 SHLVL=1 HOME=/home/vagrant LOGNAME=vagrant _=/usr/bin/printenv
PATH=/usr/bin:/bin
そう /usr/bin:/bin しか見てないのです。
which コマンドで php のパスを調査しておき crontab に書いておけば大丈夫でした。
$ which php /usr/local/php7/bin/php $ crontab -e PATH=/usr/bin:/bin:/usr/local/php7/bin * * * * * php /project/path/artisan schedule:run >> /project/path/storage/logs/cron.log 2>&1 $ tail -f /project/path/storage/logs/cron.log /bin/sh: php: command not found No scheduled commands are ready to run.
お疲れさまでした。
