Mackerel で Nginx と PHP-FPM を監視するやつを Ansible でシュッとやる - QiitaMackerel はそのままだと Zabbix より監視項目が少ないけど、プラグインを使えば、より個々の構成に固有なメトリクスを過不足なく取得できて嬉しいです。 自分はよく PHP のウェブサーバーを Ansible でプロビジョニングしているのですが、そういうお仕事でオススメな監視設定について、理解しながらチュートリアルを進める感じで紹介します。 お膳立てとして、なるべく CLI をシンプルにするために、カレントに ansible.cfg があるものとします。
PHP5.3 対応でも PHPUnit は 6 スタイルの記述へ移行しよう - Qiita
PHPUnit は 6.0 で PHP7.0 未満との互換性を切り捨てました。それとともに、Zend1 式の名前空間を捨てて、PHP5.3 で導入された名前空間に移行しました。 <?php use PHPUnit\Framework\TestCase; class MyTestCase extends TestCase { } PHPUnit >= 6.0 にはもう PHPUnit_Framework_TestCase はありません。use PHPUnit\Framework\TestCase; が今後のスタイルです。 でも、弊社まだ本番に 5.x がいるんですよ、とか、自分の公開しているライブラリ/フレームワークには 5.x 互換性の維持が必要で、とか、完全に 7 になりきれない事情がいろいろありますよね。高い方に合わせると前のやつが動かない、低い方に合わせておけばどうにか両バージョン動
PHP Toolboxプラグインを使ってPhpStormでモッキングを快適に - Qiita
イライラ 素の PhpStorm でイラっとくる箇所といえばダントツ、PHPUnit のモックあたりですよね。こう書かないといけないの。 $connector = new SomeMiddlewareProcess(); /** @var MiddlewareInterface|\PHPUnit_Framework_MockObject_MockObject $processor */ $processor = $this->createMock(MiddlewareInterface::class); $connector->setProcessor($processor); setProcessor の引数定義に MiddlewareInterface のタイプヒント付いてて、docコメントがないと MockObject 型だぜ間違ってるYo! って警告にされちゃうやつ。 最近だと a
PHP でどのように Exception/RuntimeException/LogicException を使い分けるか - Qiita
PHP は各種プログラム言語の中でも比較的高級な (表現力が豊かで最適な記述を選ぶのに知識を必要とする) 例外モデルを持っていると言えます。そんな PHP の例外の各区分とその使い分けを整理し、PHP の例外モデルの設計意図を考察したいと思います。 PHP例外の分類 PHP の例外は Java とは異なり、(Error を合わせると) 合計 4 つの区分に分類されます。Java には 2 区分しかありません。(PHP では Java の Error に相当するものは発生しません。PHP の Error は Java では RuntimeException の一種に分類されています) PHP Java
PhpStormでVagrant上のCLIのPHPをXdebugする - Qiita
基本は http://www.1x1.jp/blog/2014/08/how-to-setup-php-remote-debug-with-vagrant-vm.html こちらからどうぞ。 大事なポイント = CLI で PHP を実行するとき XDEBUG_CONFIG 環境変数が存在しないと Xdebug が動きはじめないことがあります。 VM の php.ini には xdebug.remote_enable や xdebug.remote_host が書いてあって、Webアプリケーションならデバッグできるという状況で、なぜか CLI だとうまくいかないことがあります。xdebug.remote_autostart=Off にしておいてブックマークレットでXdebugをON/OFFしながら Web をデバッグしているんじゃないですか? そんなときは XDEBUG_CONFIG=""
Node.jsの人はちゃんとsleepしてください - Qiita
Node.jsでがんばりすぎると別のプロセスに迷惑だから長いことかかる処理は sleep() みたいなのを挟みながらやりたいなー。 と思ってググった結果がこうですよ。 binding = { sleep: function(s) { var e = new Date().getTime() + (s * 1000); while (new Date().getTime() <= e) { /* do nothing, but burn a lot of CPU while doing so */ /* jshint noempty: false */ } }, だめですね。これCPU使いまくり。 まあ、CPUがいくら発熱してもいいよって思っても、制御が別のタスクに行かないのはアウトです。たとえばこれがサーバのリクエストハンドラに使われてたら、みんな一定秒数遅れてページ表示される、んじゃなく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
