• Github から WordPress のテーマを自動更新するとめちゃくちゃ快適だった。

    今更ですが、このブログのテーマはGithubに公開されています。

    レポジトリ: torounit/torounit2015

    当然、開発とかも GitHub 上で行っているのですが、とにかくデプロイが面倒くさいんです。

    正直 Typo の修正程度で、FTPとか、rsync とか VCCW を立ち上げて WordMove とかってしたくないんですよね。FTP とかをアプリからやったりすると、たまに間違ったサーバーにつないでるのに気づかないで別の環境を上書きするなんて事故も起きかねない。

    というわけで、デプロイ自動化というのは人類共通の課題だったりするわけです。

    Sass を使ったり、ES6 でバベったりしていたりもするので、単純に GitHub で Webhookして git pull すれば良いということでもない。。。。サーバー側で node.js とか gulp とかインストールするのも面倒ですし。

    というわけで、Travis CI と WP Pusher を使って、テーマの自動ビルド・自動デプロイ環境を構築しました!

    完成図

    図にするとこんな感じです。

    gethub-deploy-theme

    処理の流れとしては、

    1. 開発マシンから GitHub 上の レポジトリの master ブランチへ push
    2. Github が Travis CI に通知
    3. Travis CI がビルドを行い、dist ブランチへ push
    4. Github が WordPress サイトへ通知
    5. WordPress が dist ブランチからテーマを取得、更新

    となります。

    設定さえしてしまえば、GitHub 上のレポジトリに push するだけで、テーマの更新が反映されます。とても楽ちん。便利。

    ビルドタスクで、サーバーに展開するテーマファイルをつくる

    何はともあれ、まずは gulp でテーマをビルドするタスクを作成します。テーマファイルの直下に、dist という名前のディレクトリにビルド済みのテーマファイル一式が展開されるようにします。

    bulid:dist タスクで、CSS とか JS は assets/dist の中にコンパイルされるものとします。ここら辺は環境や好みで書き換えてください。

    'use strict';
    
    var gulp = require('gulp');
    var runSequence = require('run-sequence');
    
    gulp.task('copy', function() {
        return gulp.src(
                [
                    './**/*.php',
                    './assets/dist/**',
                    './style.css',
                    "!./dist/**",
                    "!./node_modules/**/*.*"
                ],
                { base: './' }
            )
            .pipe( gulp.dest( 'dist' ) );
    } );
    gulp.task('build:dist',function(){
        /* ここで、CSS とか JS をコンパイルする */
    });
    
    gulp.task('dist', function(cb){
        return runSequence( 'build:dist', 'copy', cb );
    });

    これで、 dist ディレクトリにテーマの一式がコピーされました。

    また、これを、package.json に指定しておくと、gulp が グローバルにインストールされていなくても

    $npm run dist

    で実行できるようになります。便利。

    {
      "scripts": {
        "dist": "gulp dist"
      }
    }

    Travis CI で自動的にビルドタスクを実行してみる

    Travis CI とは

    travis-ci-logo-light-bg

    Travis CI の CI は Continuous Integration の略で、和訳すると、継続的インテグレーションといいます。

    継続的インテグレーションCI: continuous integration)とは、主にプログラマーアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。

    継続的インテグレーション – Wikipedia

    自動ビルドとかテスト自動化などはこの取り組みの一つです。

    Travis CI はそれをサポートするサービスです。似たようなサービスに Circle CI とか Magnum CI なんかがあります。

    インストール型だと、Jenkins がめちゃくちゃ有名ですね。

    これを使うと、GitHub のコミットを監視して、指定したコマンドを自動的に実行することができます。めちゃくちゃ便利。

    Travis CI とレポジトリの連携の設定

    https://travis-ci.org にアクセスして、Sign Up をクリックして、その後は手順に従っていけばサインインできます。

    サインインできたら、右上のユーザーメニューのなかに Accounts という画面がでてきますので、そこで、レポジトリと Travis CI の連携をセットアップします。といっても1クリックで終わります。レポジトリを選択してボタンを押すだけです。

    travic-ci-accounts

     

    その後、レポジトリ直下に .travis.yml というファイルを作ってください。そこに以下のような内容を記述すると、コミット時にタスクが実行されます。

    language: php
    
    sudo: false
    
    php:
      - "5.6"
    
    before_script:
      - nvm install 4.2
      - npm install
    
    script:
      # Search for PHP syntax errors.
      - find . \( -name '*.php' \) -exec php -lf {} \;
    
    
    after_success:
      # Run npm build task.
      - run npm dist
    

    実行状況は、https://travis-ci.org/ユーザー名/レポジトリ名 で確認できます。要は、GitHub のレポジトリのURLのドメインが、travis-ci.org になったやつです。

    torounit/torounit2015 – Travis CI で僕のレポジトリは確認できます。

    Travis CI からレポジトリにアップロード用のテーマを作成する

    Travis CI でビルドタスクが自動実行されるようになりましたが、実行後にデータが破棄されてしまうので、これをどこかに保存する必要があります。今回は、GitHub Pages みたいに、空のブランチを作成して、そこに push するようにします。

    dist ブランチの作成

    レポジトリのあるディレクトリに移動して以下のコマンド実行してください。

    git checkout --orphan dist
    git rm -rf .
    touch .gitkeep
    git add .
    git commit -a -m "dist branch init"
    git push origin dist

    参考:Creating Project Pages manually – User Documentation

    その後、GitHub でレポジトリを確認すると、dist ブランチが作成されているはずです。

    GitHubへのアクセストークンの取得

    GitHub のレポジトリへのコミットをするのですが、当然ながら認証が必要です。なのでアクセストークンを使って認証します。

    Github の Personal Access Tokens にアクセスして、「Generate access token」をクリックしてください。 適当な名前をつけて、「Generate token」をクリックすると、トークンが表示されますので、とりあえずどこかにコピーでもしておいてください。

    ページ遷移したり、更新したりすると、2度と表示されないので気をつけてください。また、外部に漏れないように厳重に管理してください。

    僕は管理するのが面倒なので、アプリケーションごとに生成しています。

    このアクセストークンを使うと、

    git push "https://${トークン}@github.com/${オーナ名/レポジトリ名}" dist

    みたいな感じで push がデキるようになります。

    トークンの暗号化

    トークンを厳重に管理しろと言いましたが、これだと平文で .travis.yml に記述することになって大変まずいことになります。そこで、travis には、変数を暗号化する仕組みがあるのでそれを使います。公式の gem がありますのでそれをインストールしてください。Ruby が入ってない Windows の人は頑張ってRuby を入れましょう。

    gem install travis

    それができたら、以下のコマンドを適宜読み替えて、暗号化して下さい。

    travis encrypt -r オーナ名/レポジトリ名 "GH_TOKEN=トークン"

    実行すると、

    secure: "なんか文字列いっぱい"

    みたいな格好でこれを .travis.yml に記述してくださいと言われるので、以下のような感じで記述します。

    ついでに Git で使うパラメーターも追記します。

    language: php
    
    sudo: false
    
    php:
      - "5.6"
    
    env:
      global:
        - GIT_COMMITTER_NAME=travis-ci
        - GIT_COMMITTER_EMAIL=Githubに出るメールアドレス
        - GIT_AUTHOR_NAME=travis-ci
        - GIT_AUTHOR_EMAIL=Githubに出るメールアドレス
        - secure: "なんか文字列いっぱい"
    
    before_script:
      - nvm install 4.2
      - npm install
    
    script:
      # Search for PHP syntax errors.
      - find . \( -name '*.php' \) -exec php -lf {} \;
    
    after_success:
      # Run npm build task.
      - run npm dist

    また、

    travis encrypt -r オーナ名/レポジトリ名 "GH_TOKEN=トークン" --add

    のように –add オプションをつけると勝手に .travis.yml に追加してくれます。

    Githubにコミットする

    このまま、after_success にコマンドを追記していくと面倒なので、bin/deploy.sh というファイルを作成して、そこで コミットをするようにします。

    after_success:
      - bash ./bin/deploy.sh

    bin/deploy.sh の中身はこんな感じ。

    #!/usr/bin/env bash
    
    set -e
    
    git clone -b dist --quiet "https://github.com/${TRAVIS_REPO_SLUG}.git" dist
    npm run dist
    cd dist
    git add -A
    git commit -m "Update from travis $TRAVIS_COMMIT"
    git push --quiet "https://${GH_TOKEN}@github.com/${TRAVIS_REPO_SLUG}.git" dist 2> /dev/null

    $TRAVIS_REPO_SLUG で オーナー名/レポジトリ名 が取得できます。https://github.com/torounit/torounit2015.git であれば、torounit/torounit2015 が取得できると言うことですね。また、最後の 2> /dev/null とかを忘れると、見えちゃいけないものが公開されたりで偉いことになります。

    これで完成!と言いたいところですが、このままだと、開発中の機能のブランチも勝手に反映されたり、プルリクエストも反映されてしまったりといろいろ地獄です。

    そんなわけで、プルリクエストの場合と、master ブランチ以外へのコミットの場合を除外します。

    #!/usr/bin/env bash
    
    set -e
    
    if [[ "false" != "$TRAVIS_PULL_REQUEST" ]]; then
        echo "Not deploying pull requests."
        exit
    fi
    
    if [[ "master" != "$TRAVIS_BRANCH" ]]; then
        echo "Not on the 'master' branch."
        exit
    fi
    
    git clone -b dist --quiet "https://github.com/${TRAVIS_REPO_SLUG}.git" dist
    npm run dist
    cd dist
    git add -A
    git commit -m "Update from travis $TRAVIS_COMMIT"
    git push --quiet "https://${GH_TOKEN}@github.com/${TRAVIS_REPO_SLUG}.git" dist 2> /dev/null

    これで自動ビルドの完成!

    WordPress に自動デプロイする

    自動ビルドの設定が終わったので後はもう一息! GitHub の WebHookを利用して、dist ブランチに変更があったときに、WordPressのテーマを更新させましょう。

    今回は、WP Pusher というプラグインを使います。ちなみに Giploy というプラグインでも同じようなことは出来るはず。

    WP Pusherの設定

    WP Pusher のページに飛んで、Try WP Pusher のボタンをたたいて、Download のボタンを押すと、メールアドレスを聞かれるので、おとなしく入力するとダウンロードリンクがメールで飛んできます。

    それをダウンロードしてインストールしてください。

    すると、サイドバーにWP Pusher というメニューが出来ます。レポジトリ名とブランチを正しく入力すればOKです。Push-to Deploy にチェックを入れると自動デプロイ機能が有効になります。

    screencapture-torounit-com-wp-admin-admin-php

    こんな感じです。その後 Install theme をクリックすると、テーマがインストールされます。

    このままでも、管理画面からテーマが更新できるようになります。

    Web Hookの設定

    screencapture-torounit-com-wp-admin-admin-php-1453287725198

    WP Pusher の Themes メニューを開くと、現在このプラグインが管理しているテーマが表示されます。そこの、 Push-to-Deploy URL に表示されている URL をコピーしてください。

    そして、GitHub の レポジトリの Settings 内にある Webhooks & Services から Add Webhook してください。

    そしたら、Payload URL という項目があるので、先ほどの Push-to-Deploy URL を入力して、保存して下さい。

    screencapture-github-com-torounit-torounit2015-settings-hooks-new-1453288236465

    以上で、自動デプロイの設定は完了です。お疲れ様でした。

    プラグインとかも同じ流れでデプロイできるので、これでよりよい CI 環境がWordPressでも簡単に構築できます!

    テーマの自動デプロイなどが出来ると FTP などのアップロード作業から解放されるので、かなり快適に開発を進めることが出来ますよー。Typo とかは GitHub 上から直したり出来るので、スマホから直したりとかもできて非常に便利。

    ただ、面倒なのは WP Pusher が公式ディレクトリにないのでそれがちょっと面倒です。

    プライベートレポジトリとかの機能を削ったバージョンを上げてくれないかなぁ。。。。

  • 今年も目の悪い父親のWEB・PCの利用について観察してきました。

    新年あけましておめでとうございます。昨年は主にWordCampやら、県外のWordBench等で大変お世話になりました。

    今年はまた、フリーとしていろいろやっていこうと思っているので、皆さんよろしくお願いします。

    今回も年末年始は実家でグンマーらしくニューイヤー駅伝をテレビで見たりして過ごしてました。地元を走るのに未だにTVでしか見たことが無いです。

    それだけだとせっかく実家に帰った甲斐が無いので、毎年恒例になりつつある僕の父親のパソコンやスマホやインターネットとのつきあい方について、観察してきました。

    一昨年書いた記事です。

    目の悪い父親を見ていて気づいたこと。アクセシビリティについて考えたこと。

    父親のスペック

    • 64歳になりました。
    • 目がとにかく悪い。50代の頃に白内障の手術をやってるし、緑内障を患ってる。
    • PC-8801とか持ってたし、僕が小学生の頃とかは秋葉原に一緒にパソコンのパーツを良く買いに行った。既製品のPCが自宅で動いていたのはたぶん、Windows 3.1が入ってた98NOTEが最後。
    • なんかiPadも持ってた。

    拡大鏡を使ってPCを使ってた

    Windows10の拡大鏡を使ってPCとにらめっこしてました。

    Windows10の拡大鏡を使ってAmazon.co.jpのトップページを見ているところ
    とろゆにさん実家のリビングにあるPCの画面。

    昔の拡大鏡は、描画されたものが拡大されるので文字とかがジャギジャギで辛かったけど、Windows10の拡大鏡はフォントとかが綺麗に拡大されると言ってました。

    慣れの問題もあると思ったけれど、正直特殊能力にしか見えない。やっぱり画面全体を見ながら僕らはサイトを見たりアプリを使ったりしてるわけなので、結構なカルチャーショック。

    某音楽プレーヤーの最新版について文句を言っていた。

    検証してないので良くわからないのですが、某音楽プレーヤーの最新版とかだと、OSのハイコントラストモードに対応していないらしくアップデートできないと文句を言ってました。

    個人的には、いつも人間がソフトに合わせりゃ良いじゃんと思っているタイプだけど、こういった問題もあるのかと思うと、そうも言えない。これがブラウザだったらと思うといろいろ泣けてきます。

    感想

    正直感想としては、前回の記事と全く変わらないのですが、Web制作者として「アクセシビリティ」って単語が出ると、「音声ブラウザに対応したマークアップ」だとか「文字サイズの変更機能」とかいうことになりがちだと思うんですけど、そうじゃないよなぁってことをなんとなく思った次第です。

    デザインってのは間違いなく必要なんだけど、ちゃんとした情報のデザインをするってのは大切だなと。発信した情報を正しく伝えたいけど、受け手のことを想定するのは、正直限界があるというか、本当に様々人が十人十色にふれ合っているものだなと。

    そのために、制作者としてはいろいろと考えていかねばなと強く感じる今日この頃です。

    正直デザインのレイヤーでどうして良いかは僕はわかっていないのが現実なので、本当の意味でのレスポンシブ・アダプティブなWEBというを考えていかないとなと。

    やっぱり僕もメガネが無いと何も見えないし、視力も年々落ちますし。とにかく人ごとじゃないし。

    そういう意味では、WordPressにREST API等が提供されはじめ、アプリなどで情報の加工がしやすくなったというのは、一つのプラスの材料かなとも。

    ちゃんとAPIも提供するから、お前の見やすいように、使いやすいようにやってくれてええんやで!!!みたいなのが素敵だなぁと思います。

    とりあえず、ちゃんとHTMLも書きましょう。間違ってもCSSのbackground-imageで頑張らない。それがまずは第一歩なのはまだまだ変わらないと思います。

    では、今年も良い年にしましょうー。

  • 今年のWordPress活動の振り返りと、来年の抱負。【WordPress Advent Calendar 2015に参加したかった人達の Advent Calendar 2015】

    WordPressでスターウォーズネタやろうと思ったんですが、正直全く面白いことが思いつかなくて断念しました。

    WordPress Advent Calendar 2015に参加したかった人達の Advent Calendar 2015ということで、今年一年をざーっと振り返ってみようかと思います。

    コアコントリビューターになった。

    WordPress 4.3, 4.4 のコアにパッチを送ったら採用され、コアコントリビューターになりました。

    特に4.4のコードは実際に案件でトラブルに遭遇したところを直したので、嬉しかったのを覚えてます。報告されてたけど埋もれていたチケットだったので、ちょっとどうしたものかと思いましたが、テストコードもつけてパッチを投げたらすんなりマージされました。

    テストコードを書く方が伝わりやすいこともあるのかな、と思うので今後もパッチを送るときは可能な限りテストコードも一緒に送ろうかと思います。英語で「変数の型が変わってる」みたいな話をするのはちとつらい。というか日本語でもバグの説明をするのは容易ではなかったりするので、そのための言語としても良い手段だなとは思いました。

    WordCampで登壇した。

    なんだかんだで、一番大きい出来事は WordCamp Kansai 2015WordCamp Tokyo 2015で登壇させてもらったことですね。あの規模で登壇して話すのはなかなか緊張しました。

    特に関西は実はあったこと無い方々と話せる機会が多く、いろいろ楽しいきっかけがもらえたように思います。それがあったから東京でも登壇しようと思ったので、いろいろな転機になったように思います。

    地方のWordBenchにも行った。

    WordBench 山梨、大阪、京都や、WordFes Nagoyaにも参加しました。

    山梨では、某フルスタック小説家の秘密基地に拉致されたり、大阪では、まさかの2時間トークショーをしたり、京都ではかの有名なWordPressミュージシャンの口タイポを生で聞くことができました。

    WordFesでは酔っ払い生放送をして心身ともにボロボロになったりもしました。何にも覚えてないんですけど。。。。。。。

    基本的に、どこに行っても酒飲んで二日酔いになってる気がします。これはまずい。

    今年のまとめ

    やっぱり実際に会うのは良いなぁと思いました。別に、リモート勤務などありますし、実際に会わなくても仕事が出来たり、SNS等でコミュニケーションができる時代ですが、だからこそ会いに行くのは重要かなと思いました。

    さすがにリモートで焼肉食ったりは出来ないですし、お酒とか飲むにも味見とかしたい。酔っ払ってアホになってる人見るのは現場で見ないと面白くないですしね!!!

    特にこれからも地方でやっていこうとしている僕にはとても重要なテーマかなと感じました。

    来年の抱負

    そんなわけで、まぁ抱負というか、松本市のコワーキングスペースのKnowersさんでとりあえず、週一くらいで、もくもく会とかやらせていただけることになりそうです。

    そんなわけで、WordBench長野も頻繁に行えるようになるかなーと思います。京都、大阪くらいのペースでやれたら良いなとは思っていますが、そこら辺はやりながらうまいペースを見つけていけたらと思います。

    片付けとかがすごい苦手なんですが、人が泊まれる程度には綺麗にしようと思うので、県外からも観光ついでに来てもらえるくらいには頑張りたいと思います。

    そのほか、現在細々と作ってるテーマとかも公式にあげたり、AWSをもう少し勉強したりとやらなきゃいけないことは尽きないですがいろいろがんばりまーす。よろしくおねがいしまーす!!

     

     

     

  • WordPressのコアのテストコードを読んでみようぜー!

    先日の WordCamp Tokyo 2015 でいろいろお話させて頂きましたが、本体のテストや、そこら辺のリソースのまとめです。

    WordPress本体のテストコードを取得する。

    WordPressのテストコードは、WordPressの開発レポジトリから取得できます。subversion が必要なので、Xcodeとか、Windowsの人は TortoiseSVN とかインストールすればいいと思います。

    んで、こんな感じで取得できます。

    $ svn mkdir wordpress-develop
    $ cd wordpress-develop
    $ svn co https://develop.svn.wordpress.org/

    サブバージョンのチェックアウトは、現在のディレクトリに直接行われるので、適当にディレクトリを作ってそこで行います。ホームディレクトリとかでやると結構悲惨です。

    全部取得すると結構な時間(10分弱?)がかかるので、その場合は最新の開発版が入ってるtrunkだけ取ってくればとりあえずいいかなと思います。

    その場合は、先のコマンドの最後の1行を

    $ svn co https://develop.svn.wordpress.org/trunk

    こんな感じに変更すればいいです。

    ex: Using Subversion « WordPress Codex

    ちなみに、読むだけなら、https://core.trac.wordpress.org/browser/ とかでも読めますが、開発時に補完とかあるといろいろ捗るので、チェックアウトしておくことをおすすめします。

    テストコードを読んでみる

    下準備

    チェックアウトできたら trunkや 適当なバージョンのディレクトリに入って、testsディレクトリを覗いてみるととテストコードがあります。

    phpunitとqunitがありますが、基本的にはPHPUnitを扱います。Qunit はJSのテストです。テーマカスタマイザーとかビジュアルエディタのテストが入ってます。

    また、PHPUnitのソースコードをGithubあたりから引っ張ってきて、IDEとかエディタで読み込むようにするとかなり楽になります。

    $ git clone https://github.com/sebastianbergmann/phpunit

    読んでみる

    とりあえず、全部読もうとするとパニクるので、比較的自分が取り扱ってるところから中心に読んでみるのがいいです。どこに書いてあるか解らない場合は、とりあえず関数名・クラス名で検索をかければだいたい見つかります。

    よくわからないという人は、trunk/tests/phpunit/tests/rewrite.php を読んでみましょう。ひとつひとつのテストがかなり短めなので、わかりやすいかなと思います。だまされたと思って、 Tests_Rewrite:: test_url_to_postid あたりを読んでみましょう。

    class Tests_Rewrite extends WP_UnitTestCase {
        /* 省略 */
    
        function test_url_to_postid() {
    
            $id = $this->factory->post->create();
            $this->assertEquals( $id, url_to_postid( get_permalink( $id ) ) );
    
            $id = $this->factory->post->create( array( 'post_type' => 'page' ) );
            $this->assertEquals( $id, url_to_postid( get_permalink( $id ) ) );
        }
    
        /* 省略 */
    }

    投稿を作ってそのIDと、生成されたパーマリンクから逆算した投稿IDが一致してるかどうかを検査してるだけです。読んでみるとこんなもんだったりします。

    長いテストでも、製品のコードとは違って、複数の関数が絡み合ったりとかがないので、結構読みやすいです。

    WP_UnitTest_Factory

    テストコードを読んでいくと、

    $id = $this->factory->post->create();

    とか

    $blog_id = $this->factory->blog->create( array( 'path' => '/example' ) );

    みたいな奴がいますが、$this->factoryが、WP_UnitTest_Factory というClassのインスタンスになっています。これが便利で適当にパラメーターを突っ込むと、不足分のパラメーターを補って、投稿とか、マルチサイトのブログとか、カテゴリーとかその他もろもろを作ってくれます。

    一応プロパティとして存在するのはこれだけあります。

    • WP_UnitTest_Factory::$post
    • WP_UnitTest_Factory::$attachment
    • WP_UnitTest_Factory::$comment
    • WP_UnitTest_Factory::$user
    • WP_UnitTest_Factory::$term
    • WP_UnitTest_Factory::$category
    • WP_UnitTest_Factory::$tag
    • WP_UnitTest_Factory::$blog
    • WP_UnitTest_Factory::$network

    networkとかよくわからんです。が基本的には、create, create_and_get, create_many さえ知ってれば全部使えます。

    WP_UnitTest_Factory_For_Thing

    先ほど上げた、WP_UnitTest_Factory::$post 等の親クラスです。create 等はここに実装されています。

    WP_UnitTest_Factory_For_Thing:create()

    テストコード内の

    $id = $this->factory->post->create();

    等の親玉です。第1引数に、配列でパラメーターを突っ込めばいいです。パラメーターは、wp_insert_postとか、wp_insert_attachment とか、wp_insert_term などそのオブジェクトを生成する関数のパラメーターを渡せばいいです。生成した後、ID が返ります。

    WP_UnitTest_Factory_For_Thing:create_and_get()

    WP_UnitTest_Factory_For_Thing:create() とそんなに変わらないですが、返値が IDではなくオブジェクトが返ってきます。get_postで返ってくる奴だったり、get_termで返ってくる奴だったり。

    WP_UnitTest_Factory_For_Thing:create_many()

    オブジェクトを大量に生成するときに使います。

    第1引数に生成するオブジェクトの個数、第2引数にパラメーターを設定すればその分だけ投稿とかタームとかが生成されます。戻り値はIDの配列です。

    まとめ

    まだまだテスト周りはいろいろクラスや関数がいたりするのですが、とりあえずダミーデータの生成が簡単にできるし、簡単に再現可能というだけでもテスト書く意義ってあると思うのでとりあえず書けばいいと思います。

    あと、テストコードを読むことで、ドキュメントやソースを読むのとはまた別の角度で実装の理解が出来たりします。また、「こういう感じでテストすればいいのかー」みたいなのが解ってくると、WordPress 以外でも使えるアイデアがあったりします。

    テストコード入門編にいかがでしょうか?

    プラグインとか書きながらいろいろ読むと、意外な発見とかもあるのでおもしろいですよー。

     

  • WordCamp Tokyo 2015 のコントリビューターデイで、超すごいプラグインつくりました。#wctokyo

    WordCamp Tokyo 2015 のコントリビューターデイで、超すごいプラグインつくりました。#wctokyo

    WordCamp Tokyo 2015 2日目はコントリビューターデイでした。

    僕はプラグイン班のところにいたのですが、「初心者でよくわからないんです」っていってた人がプラグインを書いて、公式に申請を出していたのがとてもうれしかったです。実はWordPressの公式プラグインはハードルが低いのでぜひぜひ皆さんもやってみましょう。

    まぁ、そんな中僕も新しいプラグインを作り、先ほど承認されたので公開しました!

    作ったもの

    Hello Kushimoto というただのプラグインでは無い、超すごいプラグインつくりました。

    これを有効にすると、管理画面の右上にあの有名なエンジニアのMさんの名言がランダムで表示されます。また、[[kushimoto]] というショートコードを使うことで、記事本文にいつでもMさんの名言を表示することが出来ます!

    かの有名なただのプラグインではないプラグインのフォークでは無いので、同時に有効化しても大丈夫です。非常にシュールです。

    カバー画像は、すぴかあやかさんに書いてもらいました。あの雑な発注でこんな素敵なイラストが納品されるとは…

    レポジトリ

    Githubで開発しています。 https://github.com/torounit/hello-kushimoto

    もちろんTravis-CIで自動テストも行っています!

    https://travis-ci.org/torounit/hello-kushimoto

    じゃんじゃんプルリクエストください。アイコンなどは assets ブランチにどうぞ。

    フィルターフック

    hello_kushimoto_speaker

    表示するキーワードを生成するインスタンスを変更できます。ここで返すインスタンスは Hello_Kushimoto_Speaker インターフェースを継承する必要があります。

    hello_kushimoto_shortcode_name

    ショートコードの名前を変更できます。

    課題

    • 多言語対応
    • ファイルの分割とドキュメントの作成
    • デプロイ自動化
    • テストカバレッジの改善
    • 名言データを外部化API化すべき?
    • メガネさんと清野さんからプルリクエストをもらう

    コメントなど

    https://twitter.com/motchi0214/status/660996910363185152

    たかが Hello Dolly でも大まじめに作ると実は勉強になることが多いので、なんでもいいから作ってみるってのはとても有意義だなぁと思いました。(小並感)

    共犯者を作ろうと思ってたら本人からもプルリクエスト来たので良く解らないことになってますが、復讐されないように気をつけてプルリクエストは投げましょう。Githubなので犯行記録がしっかり残ります。

    記事書いてる間にプルリクエストが飛んできたので、早速マージして更新しようと思います。

  • WordCamp Tokyo 2015 で CI のセッションしたりしてきました。

    というわけで、10/31に WordCampTokyo 2015 にて、「WordPressで行う継続的インテグレーション 入門編 -プラグイン開発・保守地獄から学んだこと-」というセッションをしてきました。

    予想を大きく上回る人数のご参加、ありがとうございました。ちびりそうでした。

    プラグインを作っていて辛かった話さんざんしましたけど、公式プラグインに限った話でもないし、大事なのはその心意気とか考え方だとは思いますので、参考に出来るところがあれば幸いです。

    とりあえず、セッションで笑いが全然とれずに泣きそうだったので、またどこかでリベンジさせてください。

    あと二日酔いでめちゃくちゃしんどかったので、そこら辺も気をつけたいと思います。(3ヶ月ぶり2回目)

    コントリビューターデイはとりあえず好き勝手にいろいろ楽しくやらせていただきました。詳細は近日中に書きたいと思います。

    とりあえず、スタッフの皆様ありがとうございました。お疲れ様でした。相変わらず楽しい3日間でした。またかまってください。

     

  • WordCamp Tokyo 2015 で CI のことをおしゃべりします。

    WordCamp Tokyo 2015 で CI のことをおしゃべりします。

    今更ですが、今週末の10/31・11/1に開催される WordCamp Tokyo 2015 に登壇しまーす。

    「WordPressで行う継続的インテグレーション 入門編  -プラグイン開発・保守地獄から学んだこと-」というセッションをさせていただきます。入門編なので、プラグインを作っている/作って見たいって人向けの内容、特に今回はテスト周りを中心に話す予定です。CI三兄弟の末っ子としてがんばります。

    他には、gulpのハンズオンのお手伝いしたり、コントリビューターデイのお手伝いしたり、お酒飲んだり、お酒飲んだり、お酒飲んだりしています。

    スベったらハンズオンまでSAN値が持たないのでちゃんと笑って下さい。やさしくしてください。

    あと「何言ってるか全然わからんかったぞ!」って人とか、「テーマのビルド・デプロイ自動化について聞きたい」って人は、懇親会などにも居ますので捕まえて聞いください。お酒が入りすぎると分け解らんことを言うのでその前にどうぞ。

     よろしくお願いします。

  • Custom Post Type Permalinks 1.0.5 と RS CSV Importer Media Add-On 1.1.0 をリリースしました。

    Custom Post Type Permalinks とRS CSV Importer Media Add-On をそれぞれアップデートしました。

    Custom Post Type Permalinksの更新内容

    ほとんど何にもしてないです。

    • 4.3でのテスト。
    • 管理画面の設定画面のバグ修正。カイトさんからプルリクエスト貰ったやつです。

    Github: custom-post-type-permalinks

    RS CSV Importer Media Add-On

    テストコードを書いてテストを自動化しました。

    • 4.3でのテスト。
    • テストコードを追加。(Githubのみ)
    • 画像のパスがサーバーの内部パスの場合に対応しました。

    Github: rs-csv-importer-media-addon

    WordPress Importer のテストコードが以外に参考になりました。コアのテストと同じレポジトリにあってちょっとびっくりしましたけど。

     

    何かあればプルリクエストくださいー。

  • WordBench京都 9月号に参加してきました。#wbkyoto

    【WordBench京都 9月号】「CI(継続的インテグレーション)」と「kintone×WordPressハンズオン」に参加してきました。

    本当は日曜日の朝に帰ってゆっくりしようとか思っていたんですが、折角関西に来たのに電車賃がもったいないなぁと思い直しまして。

    前日のWordBench大阪でしゃべってお酒も飲んだおかげで相変わらず死にかけてましたけど。。。orz

    太鼓の岡本さんCI三兄弟の兄貴と一緒にWordFesのときの酔っ払い放送を見てたと言われ、末っ子の私は結構なダメージでした。つらい。

    https://twitter.com/tkc49/status/643048809208016896

    https://twitter.com/tkc49/status/643048765880823809

    口タイポをホソヤさんが全力でさらされてました。口タイポであれだけ面白いとかずるいと思いました。

    感想とか

    CIのセッションをパクろう聞こうと思って参加したのですが、セッションで5回くらい WordCamp Kansaiのときのスライドが「具体的な方法はスライドを見ろ!」って感じで紹介されてました。ヤラレタ!

    やっぱりシステム開発とかをメインにしてる人はCIに対する情熱というか重みが凄い。とりあえず、決意を新たにテストコードを書きたいと思います。

    Kintoneのハンズオンは、単純にKintoneを触ったことも無かったので面白かったです。ドキュメントも読まずに突撃したので結構必死だった記憶しかないです。

    折角開発者アカウントも取ったのでいじって遊んでみようと思います。

     

    とりあえず、この土日のWordBench旅行、楽しかったです。また折を見て遊びに行きたいと思います。

  • WordBench大阪で「使いやすいWordPressのためのCSSのつくりかた」でトークショーをしてきました。#wbosaka

    というわけで、9月12日の第45回WordBench大阪でトークショーをしてきました。

    YATさんの陰謀により、45分×2というタイムテーブルになっていて、戦々恐々としていたんですが、結局120分くらい話してました。後半は時間感覚がかなり麻痺してました。いやはや。すみません。

    当日のスライドはTypoやら、言い回しやら話の展開とかがいろいろバグってたり、当日しゃべりながら補足したところが沢山あったのでかなり加筆修正しました。200枚って凄い量ですね。参った参った。

    とりあえず、当日しゃべった内容はだいたいメロン本に書いてあるのでとりあえず、みんな読めば良いんじゃないかと思います。このフレーズ何度言ったか。。。

    日本CSS界のスーパースターからリプライが飛んできてびびりました。

    編集後記的ななにか

    CSSって文法はとにかくシンプルです。そしてそれなりに歴史も長いです。なので、ベストプラクティスは規模感、システムの機能、利用シーンなどで異なるとは思ってます。

    その上で、TPOにあったCSSを考えないとダメかなとは思います。インラインCSSだけで良い場合あるし、HTMLを増やすごとにCSSを書くというのも決して無しではありません。

    その上でやはりWordPressのテーマのCSSというのは、投稿やページが100件だろうが1万だろうが作成されることを念頭に置かねばならないですし、基本的にはWYSIWYGエディタで記事を増やすことが前提になってくるモノなのかなと思います。その場合、スケーラブルでメンテナンスしやすくWYSIWYGでも扱いやすいCSSというものを考えなければならないものなのかなと思います。

    全部の要素にclassを自動的に設定してくれるようなモノで有ればまた違った考え方もあると思いますし、REST APIでReact.jsとかであれば、JSでCSSも記述したりすることもあるので、また別物かと。

    いずれにしろ、とりあえずOOCSSの考え方はしっかりたたき込んでおいて損は無いと思います。

    スライドを200枚作った感想

    スライドって200枚作れるもんだなーとは思いましたが、こんなに枠を貰ってがっつり話すってこともそうそう無いのでとりあえず良い経験だったなーと思います。次は50枚くらいでやります。

    Decksetでスライド作りましたが、ホントに楽でした。とりあえずコンテンツ作成に集中出来るのが楽でした。リアルタイムでプレビューもできるのもかなり楽でした。

    50人の前で120分しゃべった感想

    めちゃくちゃ緊張しました。いやほんとに。

    関西人の前で、福島県生まれ群馬県育ち長野県在住がしゃべり倒すのは怖かったです。場の空気をつかむのがすっごい大変でした。若干スベったときはホントにどうしようってなりましたけど、なんとか無事小さい笑いも取りつつ、なんとかやりきりました。次はもっとちゃんと笑いを取りたい。

    あと、もう少し時間配分とか上手いことやれたら良かったなというのと、意外に人間しゃべれるものだなーとも。でも終わったあとは、へたり込むレベルで疲れました。

    なんだかんだで楽しかったです。

     

    とりあえず機会があればどんどんこういうのをやって慣れていきたいです。ほんと呼んでいただいてありがとうございました。あと焼き肉うまかった。

    次の日にWordBench京都も行ってきたのでその話も近々書きます。

  • 第45回 WordBench 大阪 「使いやすいWordPressテーマを作るために必要なCSSのつくりかた」でおしゃべりします。#wbosaka

    第45回 WordBench 大阪 「使いやすいWordPressテーマを作るために必要なCSSのつくりかた」でおしゃべりします。#wbosaka

    Doorkeeper: https://wbosaka.doorkeeper.jp/events/30996

    というわけで、9月12日のWordBench大阪でおしゃべりします。いつもはプラグインな人ですけど、今回はWordPressテーマのCSSの話を、本当にがっつりしゃべりますここまでがっつりやるつもりはなかった

    後半は、Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法とか、谷 拓樹さんのスライド読んでおけばだいたいいんじゃないかなって内容だと思うので、良いなと思ったら読んでみると良いと思います。

     

    とりあえず、特番とか講義くらいの時間があるので、がんばってすらいどつくります。がんばります。

    おうえんしてください。

     

    次の日は

    【WordBench京都 9月号】「CI(継続的インテグレーション)」と「kintone×WordPressハンズオン」

    ってのもあるらしいです。

     

  • いい加減 flush_rewrite_rules を書くのはやめてください!!

    恐らく日本一 flush_rewrite_rules に悩まされている男、Toro_Unit です。

    カスタム投稿タイプのパーマリンクがどーのこーのでよく出てくる、flush_rewirte_rules ですが。これをテーマとかに書くのはホントに勘弁してってお話です。

    Flushing the rewrite rules is an expensive operation, there are tutorials and examples that suggest executing it on the 'init' hook. This is bad practice.

    Rewrite API/add rewrite rule « WordPress Codex

    関数リファレンス/flush rewrite rules – WordPress Codex 日本語版

    毎回実行するのはバッドプラクティスとCodexにもしっかり書かれているので、絶対にやめましょう

    と言う前に、そもそも flush_rewrite_rules って地味に有名だけど、正直何の関数なのかサッパリ解ってない人多いとは思いますので、なんでこれがダメなのか、ちょっとしっかり解説しようと思います。

    長いので面倒な人は、一番下のまとめだけ読んでください。

    そもそも flush ってどういう意味なの?

    ポーカーのフラッシュとか顔を赤くするとか様々な意味がありますが、ここでの用法だと、水とかをどっと流すと言った意味合いです。

    プログラムの文脈だと、バッファとかキャッシュをクリアしたりすることを指すようです。

    要はトイレで水を流すようなイメージなんですかね。

     flush_rewrite_rules ってなんだろう?

    flush_rewrite_rules は WP_Rewite::flush_rules の ラッパーです。なのでこっちの話。

    WordPressでリライトルールは、rewrite_rules ってオプションにシリアライズされて保存されています。こいつを参照してWordPressはURLをパースしています。

    なんでわざわざそんな面倒な実装になっているかというと、リライトルールの生成というのが結構コストの高い処理なんです。ただパーマリンク構造なんて運用中にそうそう変更するものでも無いので、ページにアクセスするたびにそんなことやってられないよ!って話です。

    flush_rewrite_rules を実行すると、rewrite_rules 削除し、その後 WP_Rewrite::wp_rewirte_rules を叩いてリライトルールを生成するという流れになります。

    また、flush_rewrite_rules の引数が true もしくは空の場合、.htaccess なんかも再生成されます。

    じゃぁなぜ使っちゃだめなの?

    当然かなり重いと言うのもあるんですが、これをよくわからないタイミングで実行されるとリライトルールがバグったりします。ついでに僕が出してるプラグイン1号2号もバグります。

    カスタム投稿のパーマリンクまわりの不具合のほとんどは、flush_rewire_rules です。ほんと止めましょう。

    検証した結果、flush_rewire_rules 書いてたんかい!!!!みたいなのがあると結構辛い!!!

    代わりにどうしたら良いの?

    管理画面から設定→パーマリンク設定に入り、変更を保存すれば良いです。別に変更し無くても大丈夫です。このとき、デフォルト(http://example.org/?p=123)以外のパーマリンク構造になっていれば、flush_rewrite_rules が適切なタイミングで実行されます。

    とりあえず、カスタム投稿タイプ、カスタムタクソノミー、エンドポイントなどを追加、編集した際はこれやっておけば大丈夫です。

    flush_rewrite_rules を使うシチュエーション

    プラグインなどで register_post_type 等パーマリンク周りを取り扱う場合は、register_activation_hook や、register_deactivation_hook 等で登録しておくと良いかもです。

    まぁ設定画面でボタン押せば良いだけなので、やらなくても大きな問題では無いと思います。

    まとめ

    • flush_rewirte_rules をテーマとかプラグインにとりあえず書かない。毎回実行は厳禁。不用意なタイミングで実行するとバグる。
    • register_post_type とか、 register_taxonomy 等を書いたり、rewriteパラメーターを変更したりした場合は管理画面のパーマリンク設定に行って、「変更を保存」。
    • 日本語Codexにもページ作成したから読んで。ついでに翻訳しよう。