Archives 2018.06.22

Tweets for 2018-06-21

  • RT @redcrab_library: 来月名古屋市の金城ふ頭に護衛艦いずもが来航しますが実はこれが2回目。え?1回目いつよ?という方も多いでしょうが2年前の伊勢志摩サミットの護衛任務で来てました。目的が目的なので一般公開どころか埠頭一帯に一般人が近づく事も不可能でした。 ->
  • RT @t_misono: 弥生美術館さんの「セーラー服と女学生」展に行ってきたんですよー。女学生さんが着るセーラー服に的を絞っていて、セーラー服実物、特に各校独自のタイ結びの実物展示がとってもわくわくしましたー!豊富な資料と原画、実物が組み合わさった、見どころいっぱいの展示で… ->
  • RT @yonemura2006: 開発チームの言い分を無視した営業は論外だけど、開発の事情だけを押し付けて営業サイドの現実的な問題を無視するエンジニアも同様に問題がありますね。同じチームなんだからお互いに協力してやってかないと。 ->
  • 社内や他の取引先に負荷をかけまくる営業、担当管理職がシメるべきだと思う。けど、売上額があるから見て見ぬ振りとかあるだろなあ。 ->
  • RT @Higashiji: 凪のあすから 今日のいちまい
    もうすぐ夏ですね。高い高い雲を見ながらまなかは何を想うのでしょうね。OP1のc005の背景。今回、背景だけでは・・とまなかを置いた瞬間に初めてその空気と風、匂いが溢れる感じがしました。アニメーションって不思議ですね。^… ->
  • RT @itmedia_news: JavaScript実行時、「閲覧者の了解をいちいち得る」ページ登場 「Coinhiveより嫌」「悪夢」と話題
    https://t.co/bFZeCGY0aD https://t.co/T2TP1qDI0s ->
  • jsの実行をオフにする時代が再来するのか…? ->
  • RT @kosaber__13: 現(学)パロウィッチーズ
    エーリカ・ハルトマン
    愛車:SACHS TC50
    A1 license EU
    ウルスラ・ハルトマン
    愛車:SACHS OPTIMA50
    AM license EU
    エーリカ「放課後どこ行こっかな~」
    ウルス… ->
  • そんなズブズブな体制で作られた決済システム使いたくないので、全業界全業種やめてください。実際、銀行のシステムトラブルで取引停止が起きています。 https://t.co/lJsbBJyUzt ->
  • RT @yuichi110: "Linuxバイナリを最適化して性能を向上させる「BOLT」、Facebookがオープンソースで公開。言語やコンパイラに依存せず高速化" https://t.co/QXpo2HH1Wt #tech #feedly ->
  • RT @Una_kowa_korac: 46歳でCG業界に転職されたこの方「日本だと学歴とか資格、経験で判断されることが多いですが、この業界はアメリカだと年齢も聞かないで単純にアウトプットで評価されるので、僕のような人でも働けるんです。」
    日本も過去ばかりを見てないで「この人に… ->
  • RT @kentz1: 設定もしてないのにグーグルがスマートフォンにサッカーの結果を通知してくるの怖いし、次の世界大戦では「ドイツ 70万-110万 ロシア」とか通知されそう ->
  • 災害での死者はなくなりはしないだろうけど、なくすんだという決意で行動していかないと亡くなった人が浮かばれない。 ->
  • RT @Kumappus: Google親会社「そういえばX空いてたわ」(ポンとポケットマネーで100億円)とかなりそう(笑) https://t.co/kmNmz7pRIu ->
  • RT @ayatokura: マイクロソフトを退職した時、多くの人に子どもが大きくなってから辞めればいいのにもったいない、と言われた。日本人のもったいない精神は、時としてブロッキングイッシューになる気がした。新しい挑戦をするからこそ、得られるものが大きいことを感じながら、今日も… ->
  • もったいない精神というよりコンコルド効果に近いのと、「新卒で就職したら3年は勤めるべき」という風習に近い考え。本来、子供の年齢と両親のキャリアは別のこと。ライフステージとキャリアは関係するが、それも収入面に限ることだろう。 ->
  • エンジニアvs営業の仁義なき戦いの果てにあるものは、顧客を無視したプロダクトであり、会社は死ぬ。 ->
  • 現業 with 事務 vs 営業だと現業側は押し切られがちで離職率の向上に貢献します。 ->
  • ここで大事なことは「みんな仲良く」などではなく、きちんと顧客や取引会社の方を見て会社としての対応をしましょうということ。 ->
  • RT @PanthertypeF: 言っとくけど、本物は空転させないように慎重に加減弁開いて発車するからな。シューシューとシリンダーからドレン切りながらは正しいけど。今なら「ある機関助士」という最高の資料見れるんだし頑張ってほしい ->
  • 経済活動やら市民生活を締め上げて絞り出した国力で戦い続けたけど、結局敗戦の日を先延ばしにするしかできなかった上に、もう少し早く終えられる機会があったのに戦い続けた太平洋戦争! \太平洋戦争!/ ->
  • RT @satake_take: ここだ! https://t.co/eN19eSPB9A ->
  • RT @ethica: というかゲンロンは「エビデンスなしで語れるのが『文系』の醍醐味」みたいなことをちょこちょこ言ってて実証を重視するタイプの文系学問が毎回風評被害を受けてる感があるので勘弁してほしい。 ->
  • 日本にのみ存在する学問領域「文系」主に高校生がこの領域の訓練を受け、エビデンスがなくても議論が交わされているという、にわかには信じがたい情報を得た我々は、その真の姿に迫るべく五反田へと赴かなかった! ->
  • ゲンロンカフェは五反田だったんだな。 https://t.co/bc4J7nrole ->
  • RT @maturiya_itto: 「検証そのものを拒絶する界隈はヤバい」と数日前に書いた後で、ゲンロンの東氏が「検証したら破門」とやってたことを思い出した(実際、破門されてた)。 ->
  • RT @maturiya_itto: @korenkan ・ポストモダンは黙っていて
    ・無職は本当に黙っていて
     万能下の句。 ->
  • 同人の 原稿整理がつかず 箱一杯 ポストモダンは黙ってて #万能下の句 ->
  • RT @sleek00: この辺も、先日の「非常にキレイな絵でデッサン的に破綻の無い、空力重心が明らかに狂っているヒコーキ」のパターンで、絵は上手いしデザインも良いのだけど、マシンとしての魅力に欠けている、なのではないかと思いまった。幾ら魔法のある世界でもアレは厳しかった。 ->
  • RT @HAL9152: 去年までのTwitterは「左派っぽい事を呟くと保守派に晒される場」だった。
    それが今では「右派っぽい事を呟くと革新派に晒される場」へと変わった。
    ヴァイマル共和国かここは https://t.co/hBc9EuGbGX ->
  • 空力重心が云々、例えばFw190の水平飛行は機首が若干下がっている。 https://t.co/9cBCoVt5uzフォッケウルフ_Fw190 https://t.co/o0UyXD2gyC ->
  • RT @takumikougei: 兵庫県立松陽高等学校 生活文化科 マスコットキャラクター かこたか姫 かわいい https://t.co/QBeCzHAtfa ->
  • RT @Cthulhu_Vmodoki: 息抜きに。日本で有名なねこたちです。よろしくおねがいします。
    #Vtuber #バーチャルねこアート #ねこですよろしくおねがいします https://t.co/zegHrVgUfl ->
  • RT @Yuto_Kujou: 尾頭「最近ねこを飼い始めまして」
    安田「猫」
    尾頭「うちの子の絵です。見ますか?」
    絵「ねこですよろしくおねがいします」
    安田「うわあぁああああ(感染)」
    尾頭「冗談です」
    #巨災対の日常
    #ねこですよろしくおねがいします ->
  • RT @y_pigeonmilk: こんなん笑うわ https://t.co/ADIOthde3s ->

コミット時にWordPressコーディング規約に自動的に準拠させる方法

GitにはGitフックという仕組みがあります。
Git Documentation 8.3より

Gitのカスタマイズ ー Git フック
Gitにも特定のアクションが発生した時にカスタムスクリプトを叩く方法があります。

これを使って、WordPressのコーディング規約に準拠するようPHP/CSSをコミット時に自動修正します。
また、チェックにパスできない場合はコミットできないようにもなります。
コードのチェックにはPHP Code Snifferを使います。
さらに、Code Snifferが参照するWordPressのコーディング規約
WordPress-Coding-Standards
参考として、大元になるWordPressのコーディング規約集
WordPress コーディング規約 WordPress Codex 日本語版

PHP Code Snifferのインストールと設定

ローカルでPHPの実行環境が必要になりますので、インストールしておいて下さい。
WindowsでのPHP単体インストールは当サイトに記事があります。
参照:PHP7を単体でインストールする
Code Snifferをインストールします。
Composerでも行けるし、公式のGitHubにあるようにcurlwgetでダウンロードでもいいです。

ファイルを入れるだけで動かせます、binフォルダ内のphpcsを実行してバージョンを確認してみます。

$ phpcs/bin/phpcs --version

PHPCSの動作確認
別途、WordPress用のルールセットWordPress-Coding-Standardsをダウンロードしておきます。
今回はルールセットをwpcsフォルダにダウンロードしています。
このフォルダを下記コマンドでCode Snifferのinstalled_pathsに登録します。

$ phpcs/bin/phpcs --config-set installed_paths .\wpcs

コマンドラインで単体ファイルの修正とチェックを行ってみます。

$ phpcs/bin/phpcs --standard=wordpress front-page.php

PHPCSでコードをチェック
2箇所のエラーがありますね。

49行目
「次の関数はエスケープ処理を行うべきです(Codexの『データバリデーション』を参照)、’get_first_post_year’」
50行目
「関数呼び出しの閉じ括弧の後ろのスペースは禁止されています」
最後に
「マークされた1件の違反は、PHPCBFで自動修正が可能です」

50行目は自動修正が可能なようですので、CodeSnifferのphpcbfツールで修正します。

$ phpcs/bin/phpcbf --standard=wordpress front-page.php

PHPCBFにて自動修正
1カ所が修正されました。
もう一度、phpcsでチェックしてみます。
PHPCSで2回目のチェック
50行目のエラーが修正されたので、エスケープ処理がされていないエラーだけ残っています。
こちらは適切なエスケープ処理を書いてやる必要があります。
エラー処理前のコードは下図の通りです。50行目のhome_url()の直後だけ余計なスペースがあります。
また、get_first_post_year関数はfunctions.phpで定義している、年号を返す関数なのでエスケープ処理が必要です。
intvalにて整数型へキャストするようにWordPress Codexに記載があります。
PHPCSでエラーになる例

git hooksファイルの作成

先に試した修正とチェックをコミット前に行うよう、git hooksにスクリプトを書きます。
ローカルリポジトリの.git/hooks/にサンプルがあります。
中身はシェルスクリプトです。簡単に使い方など書いてあります。
githooksのフォルダ
ファイル名から.sampleを削除すると、該当するgitの処理が走る時に実行されます。
今回、pre-commitとして、このようなスクリプトを配置します。

#!/bin/sh
IS_ERROR=0
# コミットされるファイルのうち、.phpかcssで終わるもの
FILES=` git status --short | grep -E "^[M|A].*(.css|.php)$" | cut -c4-`
for FILE in $FILES
do
    ./phpcs/bin/phpcbf --standard=wordpress $FILE
    if ! ./phpcs/bin/phpcs --standard=wordpress $FILE ; then
        ./phpcs/bin/phpcs --standard=wordpress $FILE
        IS_ERROR=1
    else
        git add $FILE
    fi
done
exit $IS_ERROR

スクリプトの処理内容は、下記の通り。

  1. git addされたファイルから拡張子がphpかcssのファイル名を取り出す
    → FILES変数へ格納する
  2. 取り出したファイル一つずつに対し、自動修正をかける
    for FILES in $FILE do 内の処理
  3. さらに、そのファイルにCodeSnifferでチェックを行う
  4. エラーがなかったファイルは、git addでステージングし直す。
  5. エラーコードを返して終了

動作確認

git commitしてみます。
pre-commitフックはコミットメッセージを書くためのエディタが立ち上がる直前に実行されます。
githooksからPHPCSを走らせる
先ほどのように修正してチェックが実行されています。
エスケープ処理は自分で書かなくてはいけないので、エラーで終わっています。
この場合、エディタが起動しません。
SourceTreeからコミットしようとしてもこの通り。
SourceTreeからもgithooksは実行される
また、下記のように「手動で調査が必要」というアラートが出ることがあります。

Detected access of super global var $_POST, probably needs manual inspection.

手動での調査が必要なエラー
コードが規約に準拠していてもアラートが出て、エラーコード1となってしまうため、githooksでCodeSnifferが走る限りコミットできなくなります。
ルールセットの修正などで対応できるのだと思いますが、私は一度エラーメッセージを確認したらバイパスしてコミットしています。  githooksをバイパスする
gitコマンドではgit commit --no-verifyでバイパスできます。
さらにShirohanadaテーマはTravisCIでもCodeSnifferを実行するようにしています。
チェック後にテーマをビルドするので、規約違反のコードはデプロイされません。
(設定はローカルと違って、Warningは可としています)
TravisCIでのチェックログ

やってはいけないことは、できないようにしておく

例えば工場のプレス機など、プレスをするスイッチは両手で同時押しになっています。
手を挟まないように、両手が安全な位置になければ動作しない構造にしているわけです。
(それでも労働災害は、起きるときは起きる)
危険が伴う作業や現場、機械には、さまざまな安全装置があり原則があります。
有名なところでは「フェイル・セーフ」という原則があります。
例えば鉄道はブレーキの信号線が断線すると自動的に非常ブレーキがかかります。
安全に関わる原則の内「やってはいけないことは、できなくしておく」ことは「フール・プルーフ」という原則に含まれます。
私はデスクワークやコーディングも、このような原則を積極的に取り入れるべきだと思います。
今回紹介したように、コミット時とビルド時に自動修正をかけた上でチェックする仕組みを整えておけば、コーディング規約に準拠するコードだけがコミットされていきます。
こういった「安全確認」は本来やりたいこと、やるべきことに対する付随作業です。
また、コーディング規約の準拠は、手作業でやるには煩雑で、目視では間違えやすいところです。
たった一つの丸括弧の後ろの空白を、手作業で探すのは非現実的ではないでしょうか。
なので、機械に任せてしまう方が楽で確実です。

参考

gitのpre-commit hookを使って、綺麗なPHPファイルしかコミットできないようにする MANA-DOT
フェイルセーフとフールプルーフ~意味の違いと事例 レジリエントメディカル より安全な医療システムを実現する