投稿者: Toro_Unit

  • Sass から Stylus に移行しようと本気で決意しました。

    CSSプリプロセッサを使い始めてだいぶ長いこと経ったような気がします。 最初に触ったのは、LESS でした。その次に Compass が便利ということで、Sass に移行したような記憶があります。

    そして、Stylus いいなぁと思い始めて早4年以上経ちました。出会った頃からステキだなぁと思い続けてはいたのですが、Sass の方が普及してるし、Stylus を使うような人は Sass も触れるし・・・ということで、Sass を延々と使い続けていたんですが、ちょっと Stylus に移行しようと本気で考えています。

    Stylus とは

    Stylus は、node.js 製のCSS プリプロセッサです。リリースは2010年で、LESS や Sass より後発。

    詳しい機能は、http://stylus-lang.com を参照すればすぐに解ると思います。

    移行した理由

    1. extend が便利。

    たとえば、Media Object みたいなのって、HTML / CSS を書いていく上で出現頻度が高いとは思うんですが、結構細かいデザインの違いが発生したりします。

    .media {
    display: flex;
      &__figure {
        flex: 0 0 auto;
      }
    }

    出現頻度が高いと言うことは、そのぶんデザインのバリエーションも多いわけです。それに対応するために、BEM の Modifier を作ったりするのですが、Modifier が増えすぎてカオス化したりします。そして管理出来なくなって、似たようなモジュールが大量生産されて、結局 Media Object なんて存在しなかったんや・・・状態になったり。mixin を作りまくって解決するのも結局解りづらくするだけな気がしてます。結局、Media Object に依存するモジュールが出来てしまったりで、管理出来ないなぁと。

    こんな感じで、別のモジュールに依存してしまったり、

    <div class="media profile">
        <div class="media__figure"></div>
        <div class="media__body"></div>
    </div>
    .profile {
        .media__figure {
            
        }
    }

    もしくは

    <div class="media profile">
        <div class="media__figure profile__figure"></div>
        <div class="media__body"></div>
    </div>

    こんな感じで、めちゃくちゃ冗長になったり、セレクタの管理が煩雑になったりしてました。

    CSS を管理しやすくちゃんと設計しようってことなのに、結果、CSS がより使いづらくなった気がしてました。結局 HTML を書くときに、CSS側の依存関係を知らないとダメってのは非常に開発もメンテナンスもかったるい。

    プログラミングにおけるクラスの継承みたいなことが出来たらだいぶステキかなーとぼんやり悩んでました。

    要は、ある BEM でいうところのブロックを継承した、新たなブロックを作れたらだいぶすっきりするんじゃ無いかとってことです。

    そこで、Stylus でこんなコードを書くと、

    .media {
      display: flex;
      &__figure {
        width: 30%;
        flex: 0 0 auto;
      }
    }
    
    .profile {
      @extends .media;
      &__figure {
        width: 20%;
      }
    }
    

    こんな感じにコンパイルされました。

    .media,
    .profile {
    display: flex;
    }
    .media__figure,
    .profile__figure {
    width: 30%;
    flex: 0 0 auto;
    }
    .profile__figure {
    width: 20%;
    }
    
    

    このおかげで、HTML側はすっきりこんな感じで書けます。

    <div class="profile">
        <div class="profile__figure"></div>
        <div class="profile__body"></div>
    </div>

    非常にオブジェクト指向っぽく、解りやすくCSSが書けるんじゃ無いかと。

    ちなみに LESS でも同じことは出来ますが、Stylus のほうが書き方がシンプル。

    2. npm や gulp や grunt を当たり前のように使うようになった。

    昔は、Compass 一択だった気がしますが、状況も変わってきましたし、ビルドタスクをちゃんと定義しておけば、ユーザーの環境などに依存せずにプリプロセッサなどが使えるようになりました。$ npm run build とかでビルドできるようにしておけば別に問題ないわけで。watch とかも、Compass 等を使わなくても、mikeal/watch や gulp.watch や、floatdrop/gulp-watch 等で片付くので、別に要らないんじゃ無いかと。

    また、npm で normalize.css とかも取って来た際に、それを何も考えずに @import 出来たりするのも楽だなぁと。Sass でコンパイルしたのものを PostCSS等で @import を解決する等も出来ますが、それくらいはプリプロセッサ側でやっつけて欲しいなぁとは思います。Sass も SCSS 記法なら、CSS のスーパーセットなわけで。@import で CSS を取ってこれないのはすごいもやっとします。

    これもやっぱり LESS でも出来たりします。

    3. File globbing ができる

    要は、 @import "dir/*" みたいな奴です。sass-globbing とかもありますが、やっぱり拡張文法なのでなんだかなーと。

    感想

    そもそも、プリプロセッサなんか使わなくてもCSSが書けるようになってくれれば良いんですが、まだまだそういった時代にはしばらくならなさそうですよね。PostCSS も autoprefixer 等使ってはいますが、CSS の文法を拡張してオレオレCSS方言を作るのは、結局面倒くさいことになる気しかしていないので、既存のプリプロセッサと仲良く付き合っていくのも大事だなと思う今日この頃です。

  • WordPress のプラグインも composer に対応させて packagist に登録するといいよ!

    WordCamp Kansai 2016 でもこんなセッションがありました。

    WordPress 本体やプラグイン・テーマを Composer で管理すると様々なメリットがあります。WordPress + Git でサイト制作するときの悩みだった「どのディレクトリをGitで管理するの?」 という話がかなりすっきり片付くのはとても大きいんじゃないかと。また自動デプロイなどもかなり簡単に行えるようになったり。

    こんな感じで、WordPressを用いたプロジェクト管理がかなり簡単になったりします。

    Github で公開しているプラグインやテーマも Composer に対応させよう

    WordPress Packagist もありますし、あまり苦労はしませんが、それでも、プラグインやテーマを Composer に対応させておくといろいろ便利で楽しいです。npm でやるのと、同じようなノリでプラグインを使ったり、フォークしたりが出来ます。開発版とかを使ったりも簡単にできるので、テストとかにも便利だったり。

    プロジェクトのディレクトリに入った後に、

    $ composer init
    

    とすると、いろいろ聞いてくるので、名前や説明などを入れつつ、Package Type を聞かれるので、プラグインであれば、

    Package Type []: wordpress-plugin
    

    テーマであれば、

    Package Type []: wordpress-theme
    

    としてやればOKです。もし、composer.json が既に存在する場合は、そこに一行、

    "type": "wordpress-plugin",

    と足してあげればOKです。参考:Automattic/jetpack

    ここまで出来たら、あとは、ライブラリ | Composer ドキュメント日本語訳 のチュートリアルのように WordPress のテーマやプラグインを Composer で管理出来るようになります。

    Packagist に公開する

    ここまで来たら Packagist にもついでに登録しましょう。composer.json にいろいろ書かなくても一行追記するか、コマンドを叩くだけで取ってこれるようになります。

    Packagist にログインした後、Submit を開いて、レポジトリのURLを入れるだけです。めちゃくちゃ簡単です。

    packagist

    こういったエコシステムをうまいこと使えるとなかなか楽しいですよー

     

  • WordCamp Kansai 2016 で、プラグイン作成のハンズオンもしてきました。

    WordCamp Kansai 2016 で、プラグイン作成のハンズオンもしてきました。

    先日の WordCamp Kansai 2016登壇させて頂きましたが、それとは別に、WordPress プラグイン作成のハンズオン の世話役も担当させて頂きました。といっても内容はほとんど一緒に世話役をやった宮崎さんに丸投げしたような記憶があります。

    WordCamp Kansai 2016 プラグイン作成のハンズオンで進行役などをしてきました! | memocarilog

    当日の資料はこちら。wckansai2016/plugin-hands-on

    「この記事は○分で読めます」みたいなプラグインを作ると言うことで、自分は話のネタ用のプラグインを作りました。

    wckansai2016/plugin-hands-on-sample

    とりあえず、add_actionadd_filteradd_shortcode の3点セットの話が出来れば良いかなーということで作ったので結構ガバガバです。なのでおかしいところを発見したらプルリクエストくださいー。

    フォローアップというか補足みたいなもの

    プレフィックスについて

    三好さんも指摘していたことですが、WordPressのプラグインやテーマは普通に実行中に include されるので、一般的な名前を使うと関数名、アクションフック、フィルターフック等が衝突したりします。関数名の衝突が起こると、画面真っ白になりますしフックが衝突するとよからぬ挙動が発生します。

    なので、必ずプレフィックスをつけることをオススメします。今回のプラグインだったら、

    function plugin_hans_on_sample_func()
    

    みたいな感じですかね。すべての関数にこれを付けたりするのが面倒だという場合は、クラスを活用したりするという手があります。

    もしくは PHP 5.3 以前をサポートしないならば、名前空間を使うという手もありますが、WordPress 本体が PHP 5.2 を現状サポートしているので、使うならば、古い PHP の場合に白い画面にならない工夫や、エラーメッセージの表示など、気をつけないといけないことがいろいろ出てきます。

    管理画面に機能を追加する

    当日の質問で時間が足らずにお答え出来なかったのですが、この話をやり出すと時間が1時間以上かかってしまう気がするので、とりあえず サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル の8章あたりを読んでみるといいと思います。

    また、megumiteam/hatamoto を使って開発を始めるのもアリでしょう。シンプルな管理画面がはじめから付いているので、CSRF対策の具体的な方法を勉強するにはちょうど良いサンプルかなと。具体的な使い方は宮内さんの記事を参考にどうぞ。

    https://firegoby.jp/archives/5604

    あとこれとは別に、Settings API なんてものもあります。既存の管理画面に項目を追加したりする場合に用います。

    ちゃんと使うと値の保存とかバリデーションとかも出来るようですが、結構大変だったりします。使いこなすとめちゃくちゃ強力だと思いますが、まずは普通にプラグイン専用の管理画面を作れるようになれば十分かなと思ったりします。

    WordPressの管理画面に独自のオプション保存をするためのSettings APIの使い方 – Shinichi Nishikawa’s

    プラグインの国際化

    公式ディレクトリへの登録や配布などを考えたときにプラグインを翻訳を考える必要が出てきたりします。やっぱり公開するとフィードバックが欲しくなるもので、そうなると国際化ってとても大事なテーマかなと思います。

    今回のハンズオンでは取り扱いませんでしたが、Codex に詳しい資料があるので興味のある方は見てください。

    I18n for WordPress Developers – WordPress Codex 日本語版

    また、サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブルの13章にも詳しい解説があります。

    このプラグインの作りかた

    本題とずれまくるので今回は説明しなかったことをつらつらと。

    このプラグインは、WP-CLI 使ってプラグインのひな形を作成しています。

    $ wp scaffold plugin plugin-hans-on-sample
    

    地味ですがすっごい便利だったりします。そこから生成されたファイルにコードを書いてます。

    また、PHPUnit によるテストも書いています。

    ここら辺の環境構築をサクッと行いたい場合は、VCCW が便利です。

    まとめ

    プラグインそのものを作るのはホントに簡単です。コメントを書いたPHPを用意して、せいぜいreadme.txt を用意するだけでOKです。Hello Dolly や Nothing Much のような何もしないプラグイン、Hello Kushimoto といった完全にネタとしか思えないもの(実はそんなこと無いんですが・・・w)もあったりします。

    ですが、WordPress が用意している API も山ほどありますし、本当に出来ることも多いです。WooCommerce や、BuddyPress など WordPress サイトにかなり大幅な機能追加をするプラグインもあったりします。

    MySQL の知識や、高度な PHP や、JavaScript の知識が必要なカスタマイズなども様々です。

    とりあえず、バイブル や Codex を読みつつ、自由な発想でプラグインを作れば良いんじゃ無いかと思います。

    これを機会にプラグイン作ったよーってひとが居たらぜひぜひお声かけくださいませませ。

    プラグインとか作ると楽しいよーってセッションもしたのでこちらもどうぞ。

    Custom Post Type Permalinksを公式ディレクトリに公開しました。

     

  • WordCamp Kansai 2016 でオープンソースの楽しさみたいな話をしてきました。

    WordCamp Kansai 2016 でオープンソースの楽しさみたいな話をしてきました。

    先日行われた WordCamp Kansai 2016 に参加してきました。今年は初めて実行委員として、主にセッションチームの仕事を、またセッションとハンズオンをそれぞれスピーカーとして担当させて頂きました。

    懇親会で飲み過ぎて二日酔いだったり、そもそも移動の疲れや大阪の蒸し暑さで体力ゼロでした。そんな体が悲鳴を上げる中で、ワクワクしてセッションを聞きに行ったり、「裏番組のセッションとかハンズオンも絶対面白いじゃん!どうして体が2つ無いの!」って思いながら当日過ごして居たので、それはとても良かったのかなーと思う次第です。おかげさまで昨日は熱出して寝込みました。

    WordPress.tv に後日動画がアップロードされるので、ゆっくり見ようと思います。

    実行委員・スピーカー・そのほか支えてくれた皆様お疲れ様でした。ありがとうございました。

    実行委員としての話はながーくなるので、とりあえず、自分の担当セッションのフォローアップ的なものを。

    「WordPressのプラグイン作ったりコアコントリビューターになった話。 そして、その楽しさと意義。」

    自分のオープンソースへの取り組み、というと大げさですが、そういったことに関わったことでの個人的な感想・体験などを共有出来ればと思いました。

    オープンソースにすることやコントリビューションすることで発生するコミュニケーションってのは楽しいですし、また、いろんな人の小さなコントリビューションの積み重ねでいろんなものが便利になっていくってのは、とってもステキなんじゃ無いかと思ったりするわけです。

    今回だと、GitHub と Travis CI で WordPress テーマをテスト、ビルド、そして自動化 というテーマで今回登壇して頂いた羽野さんの amethyst というテーマにプルリクエストを送ったりしていたんですが、めちゃくちゃ勉強になりました。また、当日初対面だったのですが、その件でいろいろ話し込んだりすることが出来たのがすっごい楽しかったです。

    去年の WordCamp Kansai でも実は初対面だったキタジマさんと飲みに行ったり。

    初対面の人に話しかけたりすること等が苦手で、テレビとかに出てくるナンパ師みたいなコミュ力お化けみたいな人からは全力で逃げるタイプの人間ですが、そんな僕とってのコミュニケーションの方法がオープンソースなのかなと、終わってみて改めて気づいた今回の WordCamp Kansai でした。

     

    プラグインを公開したときの記事があったのでそちらもどうぞ。

    Custom Post Type Permalinksを公式ディレクトリに公開しました。

  • Composer WordPress Development Kit 3.0.2 をリリースしました。

    Composer WordPress Development Kit という、Composer と PHP のビルトインサーバーを使って、WordPress 環境をサクッと立ち上げるものを以前作ったんですが、バージョンアップしました!

    Composer で WordPress 環境をさくっと立ち上げるやつを作りました。

    使ってみていろいろ気になったところなどが出てきたのでかなり大幅に変更しました。

    変更点などなど

    ドキュメントルートをディレクトリ直下に変更しました。なので、サーバー上 で WordPress を立ち上げるときも同じコードをそのまま使えるようになりました。Git の Webhook を使って、レポジトリが変更されるたびに、自動デプロイ出来るようになったりしてます。デプロイ自動化などは、第2回 Gitリポジトリからテスト環境への自動デプロイ – CPIエバンジェリストコラム 等を参考にすれば良いんじゃ無いかなと。

    WordPress を丸ごと composer で管理出来るといろいろ便利ですね。

    そのほかコマンド追加など

    $ composer import-theme-unit-test

    で、テーマユニットテストがコマンド一発でインポートできるようにしてあったりしてます。

    $ composer provision

    でWordPressのインストールをするように変更したり、

    $ bash ./bin/server.sh
    

    でビルトインサーバーの起動をするように変更しました。

    そのほか、サーバ上で運用するために、config.php ファイルというのも新しく作ったり、config.json を local-config.json って名前に変えたりしてます。

    詳しい使い方はドキュメントを参照してください。

    気づいたこと

    以前、WordPress Packagist を使うと、WordPress のプラグインも Composer で管理出来ることは知っていたのですが、プラグイン側の composer.json に、

    "type": "wordpress-plugin"

    と書いておいて、Packagist に登録しておくと、ちゃんと WordPress のプラグインとしてインストール出来るようです。
    https://github.com/Automattic/jetpack とかもちゃんと書いてありますね。

    使うには、composer.json にディレクトリの指定を書いたりする必要があります。こんなかんじ。ベータ版などを試すときとか地味に便利そうです。

    WordPress でも PHP のエコシステムをうまいこと使っていければ、かなり便利に開発を進めていけそうですね。

    レポジトリ

    何かあれば issue とかプルリクとかくださいー。

     

  • 別に $ npm install -g gulp しなくても大丈夫って話。

    別に $ npm install -g gulp しなくても大丈夫って話。

    $ npm install -g gulp-cli

    みたいにグローバルにモジュールをインストールさせる風潮ってどうなんだよ!みたいな話をしてまして。

    僕自身もいろいろそれには非常に違和感を持っていたり、そもそも node.js のバージョンを変更したときとか、グローバルに入っているモジュールの面倒も見ないといけないことが非常に面倒くさいんですよね。grunt-cli も gulp-cli も bower も入れたくないし、可能な限りプロジェクトの node_modules で完結させたいんですよね。バージョンアップとかも面倒ですし。

    そんなわけで、いろいろ試してみたんですが、

    $ ./node_modules/.bin/gulp hoge

    とかやるのは、実際面倒くさいし、現在のディレクトリの位置次第で変わったり。

    $ $(npm bin)/gulp hoge

    とかやるのも最初の奴よりはマシですが、面倒。bashrcとかを使って、./node_modules/.bin にパスを・・・というのは流石に論外。Windows の人はどうすんねんとか言い出すとキリは無いわけで。

    というわけでいろいろ試してみたんですが、どうやら npm 2系以上からは、npm scripts にサブコマンドを渡せるようになっていたようです。だいぶ前から出来たんですね…

    つまりどういうことかというと、package.json の “scripts” のところに、以下のように書いておきます。

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

    そうすると、以下のコマンドで gulp を走らせることが出来ます。

    $ npm run gulp

    そして、それに加えて、gulp で定義したサブコマンドなども渡せるようです。

    $ npm run gulp build

    grunt 等の他のタスクランナーなどでも同等のことは出来るはずです。これで面倒くさいグローバルなモジュールの管理をしなくて済みますね!!! バージョンの不整合などに悩まされる心配も無さそうです。

    とりあえず、gulp をお使いの皆さんは今すぐ package.json に1行足しましょう。

    npm scripts を使うと、npm install したあとに勝手に CSS や JS をビルドしたりいろいろ便利なことが出来るので面白いですよー。

    参考: npm で依存もタスクも一元化する – Qiita

    コメント欄の議論も含めてなかなか濃いですね。

  • WP-D Week で CSS の話をしました。そして CSS 設計と部屋の掃除について。

    トトロのTシャツをソラマチで買ってきました、どうもトロユニさんです。先週、WP-D Week という1週間ぶっ続けで勉強会をするというやばいイベントが行われましたが、緑の本の著者でおなじみの谷さんと一緒に、CSS 設計の話をずーっとさせて頂きました。

    最近、CSS は難しいとかいうことも耳にするようになりましたが、そもそも、「簡単だったはずの CSS が最近 CSS3 やマルチデバイス対応だとかで難しくなった」、ということじゃ無くて、そもそも昔から、ちゃんと作るには難しいシロモノだったのでは無いかと。

    なので、CSS を見た目が出来た段階で終わりにしないで、常に整理整頓しながら書いていくのがとても、実は開発効率・保守・拡張等でとても大切だ!って話です。

    開発効率って話はあまりしませんでしたが、それなりのページ数の HTML/CSS を作成する場合において、CSS を書かずに、もしくは最小限の CSS の追加で済むケースが、特に中盤から終盤になってくると増えてきます。こういった意味でも、CSS 設計をちゃんとやることってのはメリットが大きいのかなとも思っております。

    部屋の掃除と CSS 設計

    要は、ソフトウェアとして CSS の設計もちゃんとやろうぜ!って話なんですが、やっぱり、「難しかった」みたいなお話はちらほらともらいました。というわけで、綺麗な部屋を保つことと、良い CSS を書くことって一緒だよって話をしようかと思います。

    リファクタリングと日々の掃除

    部屋が綺麗な人って別に毎週末大掃除をしてるわけでは無いんですよね。毎日ちょっと掃除をしたり、ご飯を食べたらすぐに食器を洗って片付けたりしてるんですよね。

    これを一気にまとめてやろうとすると、ホコリはたまってて大変だし、キッチンに至ってはシンクがヌメったり、酷いときはリアル腐海に墜ちてたりするんですよね。

    しかしまぁ、そこでなんとかするならまだ良いんですが、やっぱりその状況って触りたくないんですよね。結果さらにシンクはやばいことになり、机の下のホコリは掃除機で吸うのも大変な量になってしまったり。。。

    結局大事なのは、大ごとになる前に掃除をすることだったり、掃除を日々の習慣でやることなんですよね。

    良い CSS 設計と片付けやすい部屋

    自分の部屋の片付けというものが根本的に苦手なんですが、それでも一人暮らしも長いので、昔よりはマシになった気がします。その経験からなんですが、ヤバイって気づいて片付けよう!って思ったりするんですが、いざやろうとすると、そもそも「どうやって片付けて良いかが解らない」って現象に陥るんですよね。

    で、とりあえず、食器は適当に食器棚に押し込んでみたり、服も適当にクローゼットに押し込むんですが、結局それだと、だいたい状況は改善しなくて、結局足の踏み場も無い状況に戻ってしまうんですよね。「『とりあえず何も考えずに突っ込む』というメンタリティ」そのものに実は大きな問題があるんじゃ無いかと。

    自分の家のスペース、収納、ライフスタイル等を鑑みた上でどのように片付けるか、どうしたら使いやすいか、をちゃんと考えることが必要で、これが CSS を設計するということなのでは無いかと思います。

    断捨離の必要性

    片付けできない人によくあるのが、物を捨てられないというやつです。まぁ僕が全くその通りの人間なのですが、物があるから片付ける必要があるわけで、そしてそれが大量にあるから大変なんですよね。片付け上手な人って、着なくなった服とかすぐ捨てますよね。CSS も一緒で、使わないならすぐ消すというのがやっぱり大事だなと思います。

    ただ、物を捨てたりするのって、勿体ないっていうか、すっごい抵抗あったりするんですよね。いつか使うかもみたいなことも思ってしまうし。ただ、幸いソフトウェアの世界に生きているので、git 等を使いバージョン管理をしておくと過去に消してしまったコードに簡単にアクセスできます。そういう人こそ、バージョン管理をすると幸せになれるんじゃ無いでしょうか。

    自分の部屋もバージョン管理したいです。

    人に見せることの重要性

    自宅で、友人に料理を作ったり、ボードゲームしたりという機会が増えました。

    やっぱり人が来るとなると、頑張って片付けるんですよね。こういう機会が増えてくると、毎日の生活で、部屋を片付けようって意識が芽生えたりします。というか足下にいろいろ落ちてたりすると、物は壊れるしケガさせてしまうし。

    CSS 設計の闇のとして良くあるのが、「人の書いた CSS 良く解らない問題」があるとは思いますが、そもそも、「誰かが見るかも…」しれないという意識を持ってコードを書くってのは出発点なんじゃないでしょうか。

    書く前にチームで相談してルールを決める

    家族と暮らしていると、だいたい片付ける場所がルール化されてたりして、それを適当にやって母親に怒られる男子・お父さんなんてのは良くある話かもです。主に自分は母親が非常にきれい好きでマメな性格ということもあってそんなことが良くあった思い出があります。

    あれって最初に家族というチームの中で、日用品などの場所が決まっているからこそなんですよね。それを決めずに各自でやったらやっぱりトンでもないことになるでしょう。

    そういう意味で、まず CSS を書く前にルールの整備ってのは大切です。しかしそれを会議して決めていくのは案外難しかったりしたりルールの不備などに弱いです。

    そういった意味で、ドキュメントを残したり、コメントを残してわかりやすくするというのは大切です。

    棚とか引き出しに、シールとか張ったりするじゃないですか。大事なのってきっとそういうことです。

    まとめ

    どんな人にも使いやすい完璧な部屋、みたいなのって結局存在しないですよね。CSS 設計もその通りで、そのサイトやアプリケーション、運用方法によって異なります。

    なのでやっぱり答えは無かったりしますが、それでも、「服はちゃんとたたんで、種類ごとにまとめる」、「本や漫画はジャンル・シリーズごとにまとめて並べておく」、「山積みにして下の物が取り出せない状況にはしない」等の基本的なことって一人暮らしの六畳一間でも、大家族の住む一軒家でも、大金持ちの住む豪邸でも通じる方法論なのでは無いでしょうか。

    CSS に限らずプログラミングなどでも、オブジェクト指向等の話があったりしますが、結局のところそれは手段で、どうやって整理整頓するかというひとつの方法論です。そういった目線で CSS と付き合っていくとまた別の見方が出来るのかなと思います。

    突き詰めると答えも無く、キリも無い話なんですが、でも所詮言ってることは、部屋の片付けと同じ話と思ってもらえると取っつきやすいのかなと。リアルの部屋の片付けよりは簡単だと思います。

    というわけで、こちらにお越しの際は、ぜひぜひ一緒に、モノポリーでも、カタンでも、ごきぶりポーカー一緒に遊んでください。

  • WP-D Week にて CSS設計のお話をしてきます。

    WP-D Week にて CSS設計のお話をしてきます。

    年度末や WordBench 長野 でわたわたしている間にすっかり4月になってしまいました。花粉がつらい。。。。

    そんなワタクシですが、来週 WP-D Week というまるまる一週間勉強会をやるという、どう考えてもやばい勉強会にて、CSSの話をします。

    タイムスケジュール平日

    Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法」でおなじみの谷さんと登壇させて頂きます。

    僕が勝手に師匠認定してる人と一緒に登壇するということで、たぶんテンションが迷子だと思いますが、たぶんきっとそれが平常運転だと思うので、そんな空気をぬるっと楽しんで頂ければ幸いです。

    CSS設計の具体的な話というよりは、考え方みたいなところにフォーカスした話をしようかなと思っております。ふわっとした話になるかもしれないので、質問などお待ちしてます。なかなかこういった機会もないので、是非コミュニケーションを楽しんで頂ければ幸いです。

    そんなわけで、1週間くらいは山の上から群馬やら埼玉やら東京付近でうろうろしているはずなので、かまってくださいませませ。

  • CSS フレームワークの Basis 2.1.2 がリリースされてました。

    CSS フレームワークの Basis 2.1.2 がリリースされてました。

    カスタムフィールドのプラグインフォームのプラグインで闇を抱えているらしい、長崎のエンジニア / WordPress のテーマ作者でもあるキタジマさんが 、Basis という CSS フレームワークを作っているのを発見したので、暇つぶしに大量のプルリクを送りまくるという嫌がらせを行いました。

    僕が投げつけた issue と Pull Request の一覧。自分でもちょっと引いた。

    ちょっと最近忙しくてプルリクも全然送れなかったのですが、無事バージョン 2.1.2 が先日リリースされました。

    Basis の特徴

    レイアウト周りで CSS をあんまり書きたくない人向けのフレームワークかなーと思いました。というかたぶんキタジマさんが書きたくないんだろうなーって思います。

    なので、他のフレームワークと比べるとだいぶ Grid 周りに特徴が有ります。グリッドのマージンが複数有るケースとかは実務でも結構発生するのですが、そこら辺をケアしているのはかなり使いやすいのかなーとは思いました。あんまりデザインに左右されずに使えるというか、実務でHTML/CSSを書いてる人ならではの機能が結構盛り込んであります。

    Foundation のように、ちゃんとモバイルファーストで設計されているのも、実践的かなと思いました。

    また、FLOCSS を採用しているのは、国産ならではですね。FLOCSS はモジュールごとにプレフィックスをつけることを推奨しているのですが、既存のフレームワークと組み合わせるのが結構気持ち悪いんですよね。そうなってくると、FLOCSS で書かれたフレームワークって結構取り込みやすいんじゃないですかね。また、_s 等の既存のテーマに CSS を当てていくみたいなことをやろうと思ったときって、既存のクラス名と、自分でスタイリング用に書いたクラス名の区別が付かなくて結構泣けたりします。そういう人にもおすすめ。

    プルリクを送りつけまくった感想

    セマンティックバージョニング警察みたいなことしたりしているうちに楽しくなってきて、いろいろツッコミを入れてみたりしました。

    元々が、かなーりエッジの効いたフレームワークだったので、npm install 時に、Sass から CSS を自動ビルドさせてみたりとか、普段だったらやる機会のないものもプルリク投げたりしていろいろ遊んでました。その結果、node 4系だとだめー、npm 2系だとだめーみたいな現象にぶつかったり、結構楽しい経験でした。(そのせいでそもそもリリースが1ヶ月もずれたんじゃ無いかと。。。。)

    僕は元々マークアップやデザインの方面からスタートしている人間ですが、彼はがりがりのエンジニアなので、同じ SCSS をという言語のはずなのに、こうも違うもんかーとかいろいろ参考になったり変態過ぎてならなかったり等、いろいろ新鮮な驚きと面白さがありました。やっぱりプロダクトって設計やコードに考え方、人間性みたいなのものがにじみ出てくるんで、Twitter で雑談してる気分で楽しいです。

    また、読んでるうちにコードの理解が進むので、自分自身も使いやすいです。キタジマさんはだいぶ前から使っていると言ってたのですが、バージョン 2 がリリースされたので、僕もちょくちょく使ってみようかと思います。

    今回はがりがり日本語でやりとりしてたので、そこら辺はどうなのかなーとは思ってたりしますが、FLOCSS 自体が現状日本語しかないので、別に良いのかなとも。そこら辺はもっと流行ってから考えれば良いし、とりあえずはじめてみるのは大事だなーとは思います。

    あと、キタジマさんが、こんなこと言ってました。

    普段 CSS フレームワークを使っていない方でも何らかのオレオレ CSS フレームワークなり使い回し用 CSS 的な物は持っていると思うんですよね。毎回同じような初期設定のスタイルとかを全て一から書いたりはしないと思うので。

    で、その時はそれなりに使い勝手が良くて使い回すんだけど、ちょっとイレギュラーなところになるとあれ?ってなったり、ちょっと複雑になると設計の不足やそもそも設計なんて無かったというのが気になったりとかあるんじゃないかなーと思うんです。僕がそうなので。

    そういう物をいっそ公開しちゃえば、そうやってアドバイスをもらってブラッシュアップするチャンスがでてきたりもするし、もしその公開したものがすごく良いものだったら多くの人が幸せになったりもするし、公開するのって改めておもしろいなぁと思ったんですよね。だから皆さんも手元に隠してないでどんどん公開したら良いんじゃないかなーと。それを見て僕が参考にしたいだけなんですけど。

    まさに オープンソースのメリットってこういうところにあるんじゃ無いかなーとは思います。が、CSS をここまでモジュール化して汎用性を持たせてってことふつーの人やらない気がするんですよ。正直。

    そういう人こそ、こういうものを使ったりするのって大きなメリットなんじゃ無いかなーとは思いました。当然、最初は自分のオレオレ CSS のほうが使いやすいんですが、どうせ1年経てば別物になってたりするので、だったらその分こういったものを使うメリットは大きいのでは?と僕自身いろいろ考えさせられました。

    ドキュメント作るのがかったるくても、ドキュメントに一つセクションを足すのは結構簡単なので、そういったノウハウを issue を送りつけてみたり、プルリクエストを投げることで、使い回せる形にしていくってのは、みんなが幸せかどうかは置いといて自分は幸せになれるんじゃ無いかなーと思ったりしました。別に変なの送ってもマージされないだけなんで、とりあえず送ってみれば良いんじゃ無いかと思います。

    キタジマさんが、issue を送れと言ってるので、またちょっと暇が出来たときにスパムのごとく送りつけてやろうと思います。

  • WordBench 山梨 Vol.2 でライトニングトークしてきました。

    先週の土曜日に行われた、WordBench 山梨 Vol.2 で、ナツミーヌさんに「LTしないとお前もベジェ曲線にするぞ」とデーモン閣下風に脅されたので(嘘)LTしてきました。

    とろゆにっとさんは非常にまじめな人間です。ですので当然、まじめなLTをやるはずだったのに、芸人枠と紹介されたのは非常に心外です。抗議も辞さない!

    というわけで当日のスライドです。

    カスタムフィールドの便利さと、技術的負債、そして愛について熱くしゃべってきました。WordPress をただ使うのでは無く、いろんな選択肢の中から WordPress を「選択する」ためのヒントになれば良いなーと思います。

    ウケたかどうかは良く解りませんがなんとかやりきりました。実はLTってあんまりやったこと無かったりするので、楽しかったです。

    ほかにも、たぬきさんや、なま&はげのはげの人(はげてない)や、人狼の人など、全般的に妙な方向に濃かった会だった気がします。

    http://www.slideshare.net/GOUTEN/ss-58786247

    質問コーナーなどもあってそれも妙に濃い話になってたのが僕的には面白かったです。割とかみ砕いて話したつもりなんですけど、実際どうだったんでしょうかね。

    とりあえず、懇親会も楽しかったです。WordBench 長野も頑張ろうと思いました。ナツミーヌさんありがとうございますー。

    おまけ

    カスタムフィールドの闇は深い。

  • Powerful Posts Per Page 0.9.0 をリリースしました。

    Powerful Posts Per Page 0.9.0 をリリースしました。

    管理画面から、カテゴリー・カスタム投稿・タクソノミー等のアーカイブの表示件数を、管理画面から変更できるプラグイン Powerful Posts Per Page (PPPP)  をバージョンアップしました。

    screenshot-1
    管理画面こんな感じ。

    最新版でテストをしたり、PHP 5.3 でテストしたり、ついでにカバー画像を変えたりしました。

    たぶんコーポレートサイトで製品紹介とかやるときとか、ギャラリーをやったりするときとかで使えるんじゃ無いかなーとか思ったりしてます。

    プルリクくださーい。

  • Composer で WordPress 環境をさくっと立ち上げるやつを作りました。

    普段は VCCW を好んで使っているんですが、ちょっとお手軽環境もほしいなぁとか、Composer をもっと積極的に WordPress に導入する方法は無いんだろうかとかいろいろ考えてた訳ですが。

    というわけで、Composer WordPress Development Kit なるものを作りました。

    Composer WordPress Development Kit

    まぁ名前通りそのまんまですが、Composer で WordPress の開発環境作ったよ的な奴です。WordPress Packagist を使うと、WordPress のテーマやプラグインも Composer で管理出来ます。

    プラグイン・テーマの検証とかフォーラム回答とかで、さくっと起動してさくっと使い捨てる環境ほしいときに便利です。たぶん。

    また、WordPress と外部の PHP ライブラリや、JS フレームワークを組み合わせたアプリケーションのひな形的なものとして使えれば良いなーと思って作りました。

    使い方

    とりあえず、php・mysql・jq・composer を動くようにしてください。OS X の人は homebrew を使えば楽です。別に composer は phar をダウンロードして使っても大丈夫です。

    $ brew install mysql jq composer

    その後、適当なディレクトリに、composer create-project をすると、ひな形が作成されます。

    $ composer create-project torounit/composer-wp-dev-kit path/to/project

    その後、config.json を編集し ./bin/provision.sh 実行すると、PHPのビルトインサーバーで、WordPress 環境が立ち上がります。

    $ cd path/to/project
    $ atom config.json
    $ ./bin/provision.sh

    また、ディレクトリ構成を通常の WordPress からいじってあります。本体は、www/wp にインストールされますが、wp-content は www/wp の外側に出してあります。テーマとかプラグインをレポジトリに突っ込んで管理するにはやりやすいのかなーとは思います。

    また、Composer でインストールされたものは、 mu-plugins に突っ込んで有り、autoload されるようになってるので、Composer で適当なライブラリをゴリゴリ放り込んでつかうのも有りかなとは思っています。

    Built-in Server Helper

    また、これを使ってると、WP-Cli で PHP のビルトインサーバーが起動するんですが、パーマリンクの設定画面を見ると、index.php が入ってしまうんですよね。

    これをどうにかするためのプラグイン、Built-in Server Helper を作成しました。プラグインディレクトリにも公開してありますし、Composer WordPress Development Kit にも同梱してあります。

    一応 PHP -S のほうでのビルトインサーバーのほうにも対応してますが、ルータースクリプトが無いので、URLに拡張子がついていると、そのファイルへのアクセスになります。そうすると 404 になるので、その場合は index.php 付きの URL をセットします。まぁ、WP-CLI 使えばいいと思います。

    そのほか

    とりあえず、WordMove にも申し訳程度に対応してますが、mu-plugins を使っているので、preバージョンの 1.4 からの対応です。

    とりあえず、プラグインの検証とJS フレームワークと REST-API を組み合わせたアプリケーションのひな形として使っていこうかなと思ってます。

    何かあれば issue とかプルリクとかくださいー。