Github Actionsを使うといろんな作業が自動化できます。また、PHP-CS-Fixerを使うと、PHPのソースコードを定義したフォーマット(コーディング規約)に合わせて整形してくれます。 ということで、今回は、「コミットごとにPHP-CS-Fixerの整形をGithub Actionsで自動化すること」を実現したいと思います。 PHP-CS-Fixerのインストール まずは導入したいと思います。 composer require friendsofphp/php-cs-fixer --dev だけと簡単ですね。 $ composer require friendsofphp/php-cs-fixer --dev Using version ^2.16 for friendsofphp/php-cs-fixer ./composer.json has been updated Lo
こちらはJoolen Advent Calendar 2019 8日目の記事です。 カレンダーのURLはこちら Joolen Advent Calendar 2019 まえがき PHPを書いてるとコーディング規約とか守らない人出てきますよね。 私も気付かず破ってしまうことがあります。 それを防ぐためにPHP-CS-FixerとGitフックを利用して治安保持を目指します。 PHP-CS-Fixerとは コードの整形ツールと呼ばれるものです。 .php_cs.distという設定ファイルにルールを記述することで、コマンド一つでルールに沿ったコードに整形してくれます。 ルールはPHPの配列形式で設定します。 またFinderと呼ばれるものもあり、こちらを設定すると、整形して欲しくないファイルやディレクトリを指定できます。 例: return PhpCsFixer\Config::create()
面白かった。最近ぜんぜんPHPは書いてないんですが。 php-genba.shin1x1.com 感想書かなきゃとおもいながらダラダラしてたらもう次のエピソードが出ていたんだけど、1つ前のエピソードの感想です。 "長谷川さんのところのコードリファクタリングしにいきたい" 新原さんkonmari感ある #phpgenba— ISHIDA Akio (@iakio) 2019年2月26日 いろんな過程を経て、@shin1x1 さんの伝えたいことが熟成されてきている感じがして良い。 途中、interfaceを書くかという話で意見が分かれていた。僕も @shin1x1 さんと同じで、interfaceを使うことに特別な感情はない。 僕も昔はinterfaceを何のために書くのかわからなかったけど、今は「とりあえずinterfaceにしておいて、classでもいいかと思ったらclassにしよう」くら
BASE本社で12月19日にPHP Wayというイベントを開催しました。 PHPで成長したWebサービスを他の言語に移行させる話題を見ることがありますが、PHPを使い続ける企業がどのようなことを考えて、その選択をしているのか?ということを共有するイベントでした。 どこか自信を見失いがちなPHPの利用について、適切に状況判断するための材料を共有し、PHPを使うサービスにエンジニアとして関わっていくにあたって無駄に悲観的に思わないようにするのをイベントのゴールとして設計しています。 (左からコネヒトCTO島田さん、BASE藤川、サイバーエージェント SGE CTO 白井さん) BASE社の発表資料はこちらです。 20171219 / phpway / BASE,Inc. from 真一 藤川 一度採用した開発言語、実行環境やフレームワークは、一定のライフサイクルの後に、それを採用していることそ
PSR-2でLintした結果を見えるようにして、コード品質の最低限を上げる TL;DR Lintの結果をもっと活用しよう。 Lintの結果をもっと見えるようにしよう。 重要なのはコードを介した対話 (総花的だ) Example - PHP_CodeSniffer 例えばこのコード、ifのあとのカッコの前にspaceがない、if () {} else {}のbraceがない。 # test.php <?php if($a==2) echo $a; else echo '3'; これをPHP_CodeSnifferでチェックすると、エラーが表示される。 $ php phpcs.phar --standard=PSR2 test.php FILE: C:\Users\ishida\src\test.php ---------------------------------------------
自分の担当したWebアプリケーションを引き継ぐ際に、予備知識として説明したことのまとめ 注意事項 もともと明確に定義されていない概念や、簡単に説明するため正確さを犠牲にした部分が多い 間違っていることを前提に、疑いながら読むのがベター アプリケーションの層構造 アプリケーションを構成するオブジェクトには非常の多くの種類がある アプリケーションの(より良い)構成をオブジェクト単位で考えるのは難しいので、もっと粒度の大きい単位で考えたい アプリケーションをいくつかの層(オブジェクトの所属するグループ)に分割し、層単位でアプリケーションの構成を考える View層(ビュー層) レスポンスをクライアントにとって都合のいい形(i.e. 画面)に変換する層 View層のオブジェクトは Controller層のオブジェクトから利用される DomainModel層のオブジェクトを利用して、ユーザーに表示した
所要期間 着手しはじめたのが2010年12月ごろ、完了したのが2013年9月だったので何と3年近くかかったことになります。 長引いた原因は、日々の機能追加や運用をしながら孤独に片手間で細々とやってたからです。(単純に人手不足とも言う) また、PHPバージョンアップと同時にCentOSサーバを5から6にあげることにしたのでサーバ再構築のための工数も含まれています。 後半は仕事仲間が増えてその人が専業でバージョンアップ作業をやってくれたのでだいぶ楽できました。 それと専任のテスターさんたちにも参加していただいたので本番で大きなトラブルなく完了することができました。 感謝感謝です。 サーバ入れ替え作業が終わってPHP5.1の入った古いサーバを削除したときの、まさに「技術的負債」を返済し終わった瞬間の、あのスッキリ感、もう言葉にはできません。 終わってみてこの件に関するRedmineのチケットを数
2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。 セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。 今回のテーマはマルチパラダイムデザイン(Multi-Paradigm Design: MPD)の中核を成し、DCI / リーンアーキテクチャ(Lean Architecture)とも深く関係する 共通性/可変性分析 でした。 レポートは @smori1983 が担当させていただきます。 当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントに
2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。 セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。 今回のテーマはマルチパラダイムデザイン(Multi-Paradigm Design: MPD)の中核を成し、DCI / リーンアーキテクチャ(Lean Architecture)とも深く関係する 共通性/可変性分析 でした。 レポートは @smori1983 が担当させていただきます。 当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントに
レガシーコードと戦っていると、「このコードのどこをどう通ってこういう結果になってしまっているのか」がわからなくなることがあります。 初見でコードを理解する能力は、コードを読んできた経験が多ければ多いほど、向上するものだと思います。 とは言っても、構造化やモジュール化が適切でなく、スコープの長大なコードなどは、人間の限界を超えているものもあるでしょう。 ステップ実行のできる IDE などを使う、という選択もあると思いますが、僕は重厚な IDE を好みません。 もっと楽にできる方法で、コードパスを解析する方法があれば、ということで作ってみました。 yuya-takeyama/code_path_analyzer 元になっているのは、仕事の時にコード中にベタ書きした関数です。 Gist に公開したところはてブが 10 ぐらい付いたのと、次必要になったときにすぐ使えるようにしておきたかったので、ラ
プロジェクト名に愛が無い そしてリポジトリ名がncrm(多分New CRMの略)。だったら更に新しいの出たら何になるのか。nncrmか?nnncrm、n5crmとかschemeの仕様みたいになっていくのかと小一時間(略 テストが無い テストぉ?そんなお上品なもんなんざぁ、とんとお目にかかったことねーなぁ? バリデーションが無い バリデーション?そんなお上品なもんなんざぁ(略 サーバーがrootログインの許可+IP制限している セキュリティを高めたいのか低めたいのかどっちなのか。使い辛いわ。 バージョン管理システムがよくわかってない なぜトップにぶち撒けられてる?trunkはどこ?branchesとtagsはなぜ空? メソッドが大文字から始まる あんた絶対Windows畑から来たね?同じ調子でPHP書かれても困るんだヨォ。 全テーブルに共通のプレフィックスが付いている いや、データベース名が
PHPにはvar_dump()という関数があり、階層構造を持つオブジェクト(オブジェクトグラフ)をテキスト表現にできます。この情報を、グラフィカルで直感的に分かりやすい形式で出力するためのユーティリティがprint_oです。@koriymさんが開発されています。 koriym/print_o An object graph visualizer for PHPprint_oのインストール方法print_oはPHPのライブラリとしては単独で利用可能です。Webブラウザへの描画用に外部のJavaScript/CSSを利用していますが、これらはGoogleやGitHubにホストされたファイルを読み込むようになっています。したがってインターネットに接続された環境であれば、print_o本体のインストール以外に特別な手順は不要です。 たとえばcomposerを利用する場合は、composer.jso
Introduction AOP is a PECL extension that enables you to use Aspect Oriented Programming in PHP, without the need to compile or proceed to any other intermediate step before publishing your code. The AOP extension is designed to be the easiest way you can think of for integrating AOP to PHP. AOP aims to allow separation of cross-cutting concerns (cache, log, security, transactions, ...) PHP's AOP
PHPソースをコーディング規約に合わせて修正してくれるツール「PHP Coding Standard Fixer」を試してみました。 PHPでコーディング規約チェックツールとしては PHP_CodeSniffer が有名です。PHP_CodeSniffer はソースをチェックして、問題点を指摘してくれるのですが、ソースの修正は自分で行う必要があります。 PHP Coding Standard Fixerは、コーディング規約チェックだけではなく、規約に従っていないソースを修正してくれるツールです。 PHP Coding Standard Fixerを使う インストール インストールは簡単で、githubで公開されている php-cs-fixer.phar ファイル をダウンロードしてくるだけです。 実行する ダウンロードしたphp-cs-fixer.pharファイルをphpコマンドで実行しま
巨大なアクセスを抱える大規模サイトは経験ないので分かりません。 あと、本当にレガシーな PHP しか考えてません。とにかくイマドキのフレームワークを使ってください。こんなこと気にする必要ないんでしょ? 設定できるだけphp.iniに依存しないまず、PHP のコードで設定できるものは PHP のコードで設定した方がよいそうすれば複数サイトの開発のための切り替えも比較的スムーズに行えるextension など php.ini にしか書けないものは php.ini に書けばよいこれを踏まえたうえで、自分の場合はプロジェクトごとに .htaccess および php.ini を同時に生成する setup 用のスクリプトを用意している。.htaccess に書く rewrite の設定などもここで展開するようにしている。で、このスクリプトをリポジトリに入れてある。 必要に応じて RewriteBas
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く