PHP のエラーログを root が作成してしまってアプリから書けなくなる問題 - Qiita
なにかの拍子で root で php を実行してエラーが出力されると /var/log/php/php.log が root 所有の 0644 とかで作成されてしまい、アプリケーションの実行ユーザーからエラーログが書けなくなってしまいます。 この問題を解決するためのいくつかの案。 案：logrotate で 0666 でファイルを作成する logrotate で次のように create 0666 root root を指定します。 /var/log/php/*.log { missingok notifempty create 0666 root root } こうしておけばローテーション時に 0666 でログファイルができるので、root でログに書き込んでしまっても Web アプリからのエラーログが書き込めなくなったりはしません。 と思ったら次のような問題があるらしいです。 logro
APCU の apc.ttl の動き - Qiita
まとめ メモリがいっぱいになると TTL が切れてるエントリが全部クリアされる apc.ttl=0 だと TTL が無限なのでクリアされることはない それでもメモリが足りなければキャッシュがすべてクリアされる TTL が切れていてもメモリがいっぱいにならない限りエントリは有効なまま 詳細 // 100KB ぐらいの文字列をキャッシュしつつ apcu のステータスを表示 $str = str_repeat('x', 1024*100); for ($i=0; $i<10; $i++) { apcu_store("a.$i", $str); print_r([$i => apcu_sma_info(true) + apcu_cache_info(true)]); }
PHP のコルーチンを使ってみる - Qiita
PHP 5.5 でコルーチンが実装されましたが、全く使っていなかったので使ってみました。 コルーチンとは コルーチンとは何なのかというと・・・Wikipedia によると次の通りです。 コルーチン - Wikipedia コルーチンはいったん処理を中断した後、続きから処理を再開できる。 接頭辞 co は協調を意味するが、複数のコルーチンが中断・継続により協調動作を行うことによる。 これだけではよくわからないので動くコードを書いて理解します。 サンプル main() 関数と co() 関数が定義されています。co() がコルーチンです。 <?php function co() { echo "co 1st yield\n"; yield; echo "co 2nd yield\n"; yield; echo "co end\n"; } function main() { echo "main
PHP の RAII なんて幻想 - Qiita
function main() { try { foo(false); } catch (Exception $ex) { echo $ex->getMessage() . PHP_EOL; } try { foo(true); } catch (Exception $ex) { echo $ex->getMessage() . PHP_EOL; } } function foo($ok) { $file = new SplFileObject(__DIR__ . '/hoge.txt', 'a'); if ($file->flock(LOCK_EX|LOCK_NB) == false) { throw new RuntimeException("Unable lock file"); } bar($file, $ok); // この関数を抜けたときにファイルは閉じられるはず } func
PHP で例外を投げるメソッドじゃなく例外を作るメソッドにするただひとつの理由 - Qiita
例外の作成にめんどくさい手続きが必要なとき。例えば、HTTP のレスポンスオブジェクトを元に例外を作成するときとか。 <?php $message = sprintf( "HTTP/%s %s %s", $response->getVersion(), $response->getCode(), $response->getMessage() ); throw new HttpException($message, $response->getCode()); そういうときはそれようのメソッドを作ると便利です。 このとき、例外を作成して投げるメソッド と 例外を作成して返すメソッド の２通りの実装方法が考えられます。例えば下記の raise と create です。 <?php class HttpException extends \Exception { /** * 例外を作成して投げ
PHPStorm で @noinspection を広範囲に適用する - Qiita
PHPStorm はコードを静的解析していろいろなバグの可能性を警告してくれます。 例えば、存在しないメソッドを警告してくれる PhpUndefinedMethodInspection とかですが、マジックメソッドを多用すると警告の嵐になります。これだと PHPStorm と言うよりむしろ Warning Stormです。 <?php class Magic { function __call($name, $args) { return $name; } } $obj = new Magic(); echo $obj->ore() . PHP_EOL; // Method 'ore' not found in class Magic echo $obj->are() . PHP_EOL; // Method 'are' not found in class Magic <?php /**
Composer でパッケージの削除は composer remove が良いと思ったらそうでも無かった - Qiita
Composer で複数のパッケージをインストールしていて、開発を進めるうちにそれらの一部が不要になること、あると思います。そんなとき、どうやって不要になったパッケージを削除しているでしょうか？ 幾つか方法はあると思うので、それらの動作を確認してみます。 まず、実験のために composer.json を a b c d の 4 つのディレクトリに作成します。それぞれ下記の内容です。
インスタンスメソッドから静的メソッドを呼ぶ方法の違い - Qiita
これ「staticメソッドは$this->でも呼べる」を見て、インスタンスメソッドからの静的メソッド呼び出しで self, static, \$this::, \$this-> がそれぞれどのように動作するか気になったので調べたメモ。 PHP のバージョンは手元にあった 5.4.6 です。 <?php class A { public static function public_static($name) { var_dump("$name " . __METHOD__); } private static function private_static($name) { var_dump("$name " . __METHOD__); } public function test() { self::public_static('self'); self::private_static
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CentOS6 で remi から php や mysql をインストールするための yum の設定 - Qiita