空かどうかを検査するために empty() を使ってはいけない - Qiita
日頃 CakePHP 関連のリポジトリーに送られてくるプルリクエストを眺めていると、実に多くの方が empty() を安易に使用しているのが目に留まります。実例をご覧ください。 ですが、空かどうかを検査するために empty() を使用するのは適切ではありません。代わりに ! 演算子の使用を推奨します。 !empty() の代わりには、何もせずに真偽コンテキストに渡すか (bool) による型変換が良いでしょう。これは CakePHP のコーディング規約にも書かれています。 empty() は検査対象が未定義であっても E_NOTICE レベルのエラーを発生させません。これは検査したい変数がひょっとすると未定義かもしれない場合には便利ですが、それ以外の場合には変数名の打ち間違いを見落としてしまう原因になりかねません。 もっとも、開発に IDE を利用している方は、自分がそんなミスをするはず
【phpenv】MacでPHPのバージョンを切り替える - Qiita
PHPのバージョン違いによる挙動を確認する必要があったので、複数のPHPバージョンを管理するphpenvを導入しました。 導入までにつまづく箇所が多々あるので、その手順と使い方について紹介します。 環境 macOS High Sierra 10.13.6) 導入手順 phpenvをインストール 次のコマンドでphpenvをインストールします。 $ git clone https://github.com/CHH/phpenv.git $ phpenv/bin/phpenv-install.sh : Success. export PATH="/Users/yusuke/.phpenv/bin:$PATH" eval "$(phpenv init -)" Add above line at the end of your ~/.bashrc and restart your shell to
DockerでPHP7.4の環境を整えるときの問題点 - Qiita
DockerでPHP7.4の環境構築をした話 結論 PHPのDockerfileに以下を加える。 DockerでPHP7.4系以上を使うなら、ライブラリの「oniguruma」を入れる。 apk add --update --no-cache oniguruma-dev \を追記。 DockerでMySQLを使うなら、PDOドライバーを入れよう。 RUN docker-php-ext-install -j$(nproc) pdo_mysqlを追記。 対象 DockerでPHP7.4以上を使いたい方 DockerでMySQLの環境構築。 OS Catalina 10.15.4 Docker 2.3.0.3 php:7.4.7-fpm-alpine はじめに phpenvを用いてPHPのバージョン管理すればDockerなんて使わなくていいやと思ってたんですけど、MySQLを使うことになって、5
PHPUnitで「例外が投げられないことを期待する」というテストケースをどのように書くか - Qiita
こんな「困った」時の話 「異常時に例外を投げる、正常に完了したらvoidとなる」というようなメソッドがあるとします。 こんな時に、PHPUnitでどのように単体テストを書けばいいでしょうか？ PHPUnitでは、1つもassertionがないテストを「Risky」としてマークします。これは賢いのですが、しかし「返り値をとれないメソッド」=assertionを置けないテストケースについてRiskyになってしまうのが困る・・・と悩んでいました。 結論: @doesNotPerformAssertions を使えそう テストケースのアノテーションに @doesNotPerformAssertions を入れると、「これはリスキーじゃないぞ」という事を示すことができそうです。 以下、「こうやって対処してきた」「これからは@doesNotPerformAssertionsを使いたいかも」という話をし
PHPUnitの"expectException()"は、例外を発生させる箇所より前に記載する - Qiita
$ vendor/bin/phpunit --version PHPUnit 9.1.5 by Sebastian Bergmann and contributors. $ php --version PHP 7.4.0 (cli) (built: May 27 2020 22:16:49) ( NTS ) expectException()を記載したのに、例外を発生させてもテストが成功しなかった 記載する位置、順番を間違えていたのが原因でした。 PHPUnitには、テストコード内で例外が生成されたかを確認するexpectExceptionメソッドが実装されています。 https://phpunit.readthedocs.io/ja/latest/writing-tests-for-phpunit.html#writing-tests-for-phpunit-exceptions このメ
PHPのリリース日とサポート期限 - Qiita
PHP 7.0 は2018年12月3日に公式のセキュリティサポートが終了し、その前の2018年9月13日に 7.0 系最終リリースとなるはずだった 7.0.32 が公開された。しかし、セキュリティサポート終了後の2018年12月6日に 7.0.33 が公開された。 PHP 5.6 の公式のセキュリティサポートは当初2017年8月28日まで 6 だったが、5系最後のリリースであることを理由に 7 2016年始めに2018年末まで延期された。8 2018年12月6日にリリースされた 5.6.39 が最終リリースになるはずだったが、セキュリティサポート終了後の2019年1月10日に昔のよしみ (for old time's sake)で 5.6.40 がリリースされた。 9 PHP 5.5 は2016年7月10日に公式のセキュリティサポートが終了し、その前の2016年6月23日に 5.5 系最終
cakePHP3のQueue Pluginを使ってみる - Qiita
初、Advent Calendarです。よろしくお願いします(^o^) この記事は、CakePHP 3 Advent Calendar 201513日目用に書きました。 Queue Pluginって？ イケメンのMark S.さんが作ってくれている、CakePHP Queue Pluginのことです。 DBにTaskを追加して、Queue用のworkerを動かしておくと、定期的にTaskを実行してくれます。 なぜ、Queue Pluginを使ったか スクレイピングでデータを貯めて、それを参照するWebアプリを作っています。 定期的にスクレイピングしてデータを貯めていますが、それが追いつかない時に、追加でスクレイピングしてくれる仕組みがあると良いなと考え、調べた結果、Queue Pluginを使ってみることにしました。 ※スクレイピングの実行間隔を狭めれば良いんじゃないかとか思いましたが、ま
PHPUnitでパラメタライズドテストをやってみる - Qiita
概要 チームのメンバーがPHPUnitでのパラメタライズドテストを、都度読み出す形で書いていました。 PHPUnitの機能を使えば、もっと可読性を上げられると思ったので、自己学習も兼ねてやり方をまとめてみます。 パラメタライズドテスト パラメタライズドテストとは、 渡す引数が違うだけで同じメソッドを何度もテストするというテスト方法になります。 今回は下記のFizzBuzzを使って、説明していきます。 declare(strict_types=1); class FizzBuzz { public function toFizzBuzz(int $count) { $result = ''; if ($count % 3 == 0) { $result .= 'Fizz'; } if ($count % 5 == 0) { $result .= 'Buzz'; } if (!($count
phpmdのルール一覧 - Qiita
phpmdとは phpmdは静的コード解析ツールです。 phpmd hoge.php text cleancodeとか1行コマンド入れるだけでさくっとチェックしてくれます。 コマンドの文法はここらへんを参照。 ソフトウェアテストのような厳重なチェックは行いませんが、ソースコードの大まかな問題点をざっと確認してくれます。 いちいち確認せずとも問題外のコードを門前払いしてくれるというだけでだいぶ手間が省けるので、とりあえずpre-receiveあたりに突っ込んでおくと捗るでしょう。 なお、実際に動かすと100%死ぬコードでもphpmdチェックは問題なく通ることもあるので、phpmdを導入したからといってテストを省いたりしてはいけません。 ルール一覧 以下は具体的にどんな指標で弾かれるかのルール一覧です。 確認したバージョンは2.6.0です。 ルールセットはPMDから取り入れたようです。 なお、
PHPで循環的複雑度をコミッタ毎に可視化する - Qiita
目的 コードの複雑度は人に依存するのか、タスクに依存するのかを調べたい 誰が書いたかという点も重要視するが、誰が直せるかに着目したい 直してもらいたい箇所にアサインできるといいなを自動で抽出したい まずは誰が関数を書いたかという定義を策定する 関数の中身を一番変更している人間 できなくもないだろうけど、ただただメンドくさい 関数の宣言箇所をコミットした人 これならイケそう(Git前提) 最初に書いてメンテしていれば複雑度に影響しないはず そもそも、誰かのメンテが必要なものを最初に書いている シグニチャを変えればコミッタは変わるが、それって複雑度にきっと影響するよね ということで、勝手に宣言部を書いた人単位で割り当てしてみる(こういうのは勢いが大事) 実装を考える phpmdがある これで循環的複雑度はわかる 誰がそれをもたらしたかの定義もできた Gitを使っていれば、blameすることで誰
cakephp3における日付のバリデーション - Qiita
今回やりたいこと postされてくる日付を、現在の日付(今日)より、前であればvalidationを有効にしたい 基本 app/src/Model/Table/HogeTable.php POST入力値等の入力値チェックは validationDefault に記述する saveの入力値チェック(Entityチェック)は buildRules に記述する cakephp3のバリデーションは2パターン存在 思考の流れ 自分で考えたbadコードを、プレビューしていただき、 より良いコードになった流れです。 public function validationDefault(Validator $validator) bakeにより、デフォで設定されているのが、 下記の初期段階です。 ※hoge_date は、postされてくるinputのラベル名になります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
必要な時にのみxdebugをオン - Qiita
homebrewでインストールした複数のphpのバージョンを切り替える方法 - Qiita
phpenvインストール手順 - Qiita
phpunitのモックの挙動まとめ - Qiita
LaravelのSeederを利用して、テストデータを生成する方法（1対多, 多対多） - Qiita
CakePHPのアソシエーションがわからなくなったとき用 - Qiita
Composer本体のバージョンを1系に固定化する - Qiita
【Laravel】artisanコマンドでやりたいこと、ここで見つかる - Qiita
PHP静的解析ツール集phpqaを使ってみる - Qiita
