• 勉強会とか行ったり、勇気を出して話しかけてみるってのは大切だなと思う今日この頃

    こないだのWordBench 長野で紹介させていただいたVCCWとか、僕にプラグイン制作の公式ディレクトリへの公開をそそのかした、かの有名なプラグイン作者の宮内さんがいろいろ教えてくれました。

    なんか、もう楽しいやらありがたいやら。こういうことを教えてくれる人が居るってのはとってもありがたい。ほんと聞いてみるもんです。いつもいつもありがとうございます。

    コミュニティとか、人のつながりってとっても大事だなと思います。自分で本読んだりコード読んだり写経したり、いろいろ書いてみるとかもとても大事なんですけど、人から話を聞けるってのは時としてかなり大きいです。

    勉強会とかコミュニティに参加するとこんなこともあるし、楽しいです。割とコミュ症だったり人見知りではあるので、人に話しかけたりとか結構苦手なんですよ。ほんとに。でもちょっとの勇気を出して、積極的に名刺交換してみたり、話しかけて見たりするのってほんとに大事なことだよなと、改めて痛感した次第です。

    まぁそんなわけで、また近いうち(1月〜2月くらい)に、WordBench長野でVCCWのハンズオンやります。VCCWって別にただWordPressのローカル環境を簡単に作れるってだけじゃなく、PHPUnitとか簡単にできたり、プラグインやテーマのひな形を簡単に作れたりすっごーい便利なんで、いろいろ布教活動したいと思います。よろしくお願いします。

  • git pushしたときにFTPしたりgruntタスクを実行する。

    FTPしか使えないレンタルサーバーでの案件でGitを入れようとするとき、ソースの管理って結構大変だったりします。なので、git pushしたときに自動でFTPすると、非常に便利でした。

    このgrunt-githooksと、grunt-ftpushを使ってこんなGruntfileを作ります。

    module.exports = (grunt) ->
    
    
      grunt.loadNpmTasks "grunt-ftpush"
      grunt.loadNpmTasks "grunt-githooks"
    
    
      grunt.initConfig
    
        ftpush: {
          build: {
            auth: {
              host: 'example.com',
              port: 21,
              authKey: 'pass'
            },
            src: '',
            dest: '/path/to/dir',
            exclusions: ['.*','node_modules/*','.sass-cache/']
            keep: [],
            simple: true,
            useList: false
          }
        }
    
        githooks: {
          options: {
            dest: '.git/hooks',
            hashbang: '#!/bin/bash',
            template: './node_modules/grunt-githooks/templates/shell.hb',
            startMarker: '## GRUNT-GRUNTHOOKS START',
            endMarker: '## GRUNT-GRUNTHOOKS END'
          },
          setup: {
            'pre-push': 'deploy'
          }
        }
    
      grunt.registerTask 'deploy', ["ftpush"]

    これを設定したら、以下のコマンドを実行します。

    $ grunt githooks

    これで.git/hooks/pre-pushが作成され、pushしたときにgrunt deployが実行されるようになります。grunt deployにこのコードだとFTPしか設定してありませんが、サーバーにアップロードする前にCSSやJSのコンパイル・結合・圧縮などを実行するとより、使い勝手がいいと思います。

    例:https://github.com/torounit/torounit2015/blob/master/Gruntfile.coffee

    サーバーによってはftpushではなく、grunt-rsync等を使ったほうが良い場合も多いですが基本はこんな感じで、push時にサーバーと同期を取る事ができます。

    やっぱりいろいろ自動化しておくと便利で良いですね。ファイルの同期は手動でやるとだいたいろくな事が無いので、自動化の威力がいろいろ感じられて良いかなと思います。

    note

    • gitにsourcetreeを使う場合、環境変数が読まれないので、command not found: grunt とか言われる場合があります。その場合、githooksのテンプレートをいじって、bashrcとかをexportすると良い感じになります。

     

  • WordBench長野でお話しさせていただきました。#wbNagano

    ブログを書くまでが勉強会という事で。

    先週の土曜日にKnower(s)さんでWordBench Nagano Vol.4を開催しました。

    気がつけば満席で大盛況でございました。ご来場ありがとうございます。正直40分しゃべるってのはなかなか疲れました。懇親会では疲れ果てて非常にぐだぐだだったので次回は誰かに懇親会はお任せしようという決意をした所存であります。

    当日話した事

    先日の予告通りこのブログのリニューアルをどんな感じでやったかという話をざっくりとしました。テスト環境作るなら、VCCWがいいよって話と、Theme Unit Testをちゃんとやると良いよっていう話ですかね。

    かなり駆け足&練習不足のためのグダグダなどもあったので、わかりやすく話せた自信は正直薄いので、いろいろググってください。宮内さんのブログとかに情報たくさんあるので、読んで頂ければと思います。

    今後について

    とりあえず、今年度中に何かしら勉強会やれたらなぁと思います。個人的にはCSSとかJSの話もしたいというのもあったり、WordBenchもある程度定期的にやりたいなとは思ってたりします。

    勉強会などのお誘い等は可能な限り参加させていただきますので、よろしくです。

     

  • とあるサイトの高速化についてフロントエンドでやったことまとめ。

    業務で携わっている案件なのですが、アクセス数の急増が見込まれるイベントがありまして。準備期間も少なく、バックエンド側でできることがほぼないという状況でサイトを落とさないようにがんばる!というお仕事でした。レガシーソースてんこ盛り。CSSプリプロセッサとか何それ状態。

    そこで実施した対策のまとめです。サーバー・アプリケーション・サイトの構成によって、効果の大小はありますが、比較的効果があったと思われるものをつらつらと。

    リクエストの削減とファイルサイズの最適化

    まず一番最初に考えなければいけないのがリクエスト数です。すごいおおざっぱに言うと、WEBサーバー(ApacheとかNginxとか)への負荷は、PV数×リクエスト数です。PVがそんなに無くてもそのページのリクエストがめちゃくちゃ多いとそれだけでかなりの負荷になります。リクエストを半分にできれば2倍の人数がさばけるってことに、すげーおおざっぱに言うとなります。

    ファイルサイズについてはそりゃ当然、軽ければ軽いほど良いわけで。

    Lazy Loadを導入して画像を遅延ロード

    Lazy Loadは、画像を遅延ロードするプラグインです。画像がウィンドウの描画範囲に現れるまでロードしないというやつです。

    <img width="160" height="45" src="dummy.png" class="lazy" data-original="http://example.com/example.jpg" alt="" />
    
    <script src="//code.jquery.com/jquery-1.11.0.min.js"></script>
    <script src="//cdnjs.cloudflare.com/ajax/libs/jquery.lazyload/1.9.1/jquery.lazyload.min.js"></script>
    
    <script>
    $(function() {
        $("img.lazy").lazyload();
    });
    </script>

    追記:当然、何でもかんでもLazy Loadにして良いかという話ではないです。HTMLの仕様的にどうだとか、JSが無効だと見れなくなるだとか。個人的には、緊急回避の手段かなと思ってます。

    CSS Spriteで画像を結合

    メンテナンス性とのトレードオフな部分もあるんですが、それでも可能な限りCSS Spriteにするとそれなりにリクエストを削れます。

    また、同じような画像だと、トータルの画像サイズも下がる場合があります。

    CSSやJSも結合

    当然、CSSやJSも結合できるものはとにかく結合。grunt-contrib-cssmingrunt-contrib-uglifyとかを使うと、それなりにメンテナンスせいを保ったまま、圧縮と結合ができるのでなかなか具合が良いです。

    画像の圧縮

    画像の圧縮も当然ですが、grunt-contrib-imageminや、 grunt-imageなどを使って圧縮するのが手軽です。

    ただ、JPEGは元から圧縮されている関係上、この手の方法だとあまり効果が無い場合があります。ファイルサイズが大きいものは、Photoshopで地道に目視で圧縮しました。品質を60%くらいでもそんなに見た目変わらないので、やるなら思い切って削ると良いかなと。

    CSS / JS / 画像などの配信の最適化

    ファイルサイズを削ったり、リクエストを削ったりってのは、CSSの書き方とか静的リソースの作り方そのものの話でしたけど、これをいかにして高速に配信するかというのも結構大事です。

    静的リソース用サーバー立てる

    おいおい、フロントエンドなのかそれは、と言われたらそりゃそうなんですけど。

    静的リソース用サーバーとアプリケーションサーバーに求められるものは当然別です。画像なんて一度アップロードしたら更新しないなんてことはざらにありますし。でもHTMLはそれなりに更新がありますし、CMSとかが入ってるとまた大変な話。

    サーバーからいじれたら、nginxをサーバーのフロントエンドに立てて、直接nginxから見に行くようにするとかいろいろあるんですが、そういうわけにもいかなかったわけで。今回は事情によりApache。

    Amazon S3とか活用するのも有りだと思います。というかたぶんそっちの方がイマドキだし、絶対早い。

    Keep-Aliveを有効に

    普通に、HTTPでリクエストが飛ぶと、TCPハンドシェイクという動作が発生します。1リクエストごとに、これが発生してしまうのですが、Keep-Aliveを設定しておくと、一定時間ハンドシェイクを省略できるというやつです。

    細かいこと言い出すときりがないので何ともいえないんですが、リクエスト数が多ければデフォルト値でもそれなりに有効な気がします。

    <ifModule mod_headers.c>
    Header set Connection keep-alive
    </ifModule>

    サーバーによっては、.htaccessに上記の記述で有効になります。まぁ.htaccessでやる話でもない気はしますけどね。

    Expiresヘッダの設定

    Expireはファイルの有効期限です。この有効期限内であれば、ブラウザのキャッシュを利用してくれます。これが未設定だと1週間くらいで失効してしまうのですが、これを適切に設定することでリクエストをそれなりに削れます。

    今回の案件は、7割か8割くらいはリピーターだったりで初見さんが少なかったのもあって、これもそれなりに大きな効果があったのかなと思います。

    最近では、.htaccessで設定できることが多いです。拡張子ごとに設定できます。以下のコードだと、とりあえずCSSとJS、画像は1ヶ月キャッシュを有効にしてます。

    ExpiresActive On
    ExpiresByType image/gif "access plus 2592000 seconds"
    ExpiresByType image/png "access plus 2592000 seconds"
    ExpiresByType image/jpeg "access plus 2592000 seconds"
    ExpiresByType image/x-icon "access plus 2592000 seconds"
    ExpiresByType text/css "access plus 2592000 seconds"
    ExpiresByType application/x-javascript "access plus 2592000 seconds"
    ExpiresDefault "modification plus 1 week"

    CDNを活用する

    jQueryだとかfontawesomeとか有名どころのライブラリは、CDNから呼びましょう。キャッシュがあれば、当然それを使ってくれます。cdnjs.comなんかは有名ですね。

    また、一つのホスト(origin)への同時接続数はブラウザの標準設定で6つまでなので、そのぶん他のリソースをロードできます。

    まとめ

    フロントエンドの高速化といってもやることめちゃくちゃ多いし、幅広いなーというのが印象でした。これ以外にもサーバーにサブドメインを複数割り当てて、一度にロードするファイル数を水増ししてみるとかいろいろやってみました。

    結果としてとりあえず、Lazy Loadはかなり強力な手段だなと思いました。リクエストが発生しなければそもそもサーバーに負荷はかからないので。細かい画像やバナーも多かったので、リクエストがこれだけでかなりの数削減できました。

    結局フロントエンドチューニングに銀の弾丸はやっぱり存在しないし、システム構成等でもだいぶ変わってくる部分は大きいと思います。

    レガシーなソースでもgruntとか入れるメリットはでかいなぁとも感じました。

    やっぱり、基本的には「塵も積もれば山となる」的発想で立ち向かうしかないのかなと。そもそも画像やCSSにしたって一つ一つのサイズはたいしたことないという事を考えると、その「塵が積もって」サイトを遅くしてるんですからね。

    参考

  • torounit.com をリニューアルしました。あとWordBench長野やります。

    このサイトをリニューアルしました。2週間くらいちまちま作業してましたが、なんとか形になったので、公開しました。

    torounit/torounit2015 にテーマのソースコードはおいてあります。

    リニューアルの理由

    • モバイルからのアクセスがそこそこ増えてたんですけど、正直見づらい。
    • 最近流行の1カラムにしたかった。
    • WordBench長野をやるんですけど、正直ネタに困ってた。

    という感じです。

    とりあえず、WordBench長野 第4回 「WordPress勉強会 in 松本」でブログリニューアルをどんな感じで何を使ってどんな風にやったか、みたいな話をする予定ですので、なにかつっこみどころとか話してみたいことなどあれば遊びに来てくださいませ。

    懇親会もぬるっとやります。一応本日締め切りなので、ご参加くださいませませ。

     

  • 脱カオスなCSSのために実践している7つの事

    突然ですが、CSSってカオスですよね。

    まぁそうですよねー。紳士協定とはうまいこと言ったもんです。言語仕様としてどうしようもない。全部グローバル。JavaScriptとかでやったらまずクソコードって言われるやつです。

    そうはいっても、レスポンシブだとかでどんどん肥大化していく一方なので、何とかしないと身の破滅です。

    とりあえず結論として、FLOCSSやれば良いんじゃないですかね。と言ってしまうのもあれなので、とりあえず実行している事を箇条書きで。

    とりあえず何かしら公開されているCSS設計思想を取り入れる。

    何かしら入れましょう。SMACSSでもMCSSでもFLOCSSでもモジュール組みでも、とりあえずなんでも良いかと思います。大事なのはそれがドキュメントになっていることです。オレオレ設計なんて、1年もすれば、オレオレ設計ver5.0(下位互換性無し)くらいになっている事が多いので、ろくなもんじゃないです。

    そんなにオレオレ設計が良いなら、ちゃんとドキュメンテーション作って、メンテしましょう。

    別のモジュールへのカスケーディング、CSSの上書きは可能な限り避ける

    ここで言うモジュールとは、BEMで言うところのブロックだったり、MCSSでのモジュールだったりです。

    別のモジュールへのカスケーディングを行うと、モジュール同士が密結合になり、モジュールに分割した恩恵がほとんど感じられなくなります。かといって依存性注入はできないし仕方が無い部分があるのですが、あまりに他のモジュールのセレクタが出てくるようであれば、リファクタリングが必要です。

    .mod-a {
    
    }
    
    .mod-b {
        &__body .mod-a {
        
        }
    }

    こんなCSSが乱発するようならリファクタリング、再設計が必要です。

    リファクタリングする。時々モジュールの設計を見直す

    カオスが大きくなると手がつけられなくなり、さらに大きなカオスを生み出すので、小さなカオスが生まれたら(先述の他のモジュールへのカスケーディングが大量発生したとか)即座に解消しましょう。CSSの複雑性ってとんでもないので、放置すると突然でかくなったりします。特に序盤の設計が甘いとなおさらなので、「後でやろう」が効かないことが多いです。

    気になったらすぐに手を打ちましょう。

    命名規則もしっかりと設計しておく

    特に何も考えたくなければ、BEMを採用することをおすすめします。

    CSSには名前空間という概念が存在しないので、classの命名には気を遣わないとすぐに破綻しますし、一般的な名詞を使うと、それが他のCSSと干渉しがちです。

    そこら辺を解決するアプローチとしては、モジュール組みとかもありますが、ぱっと見で干渉しているかどうか等がわからないので、長くて気持ち悪い命名でカバーする方が安全性は高いと思います。

    特に、Bootstrapやらfoundationを使うプロジェクトだと、カオスになりがち感がやばいです。サイト用のCSSにはプリフィックスをつけておく方が良いかなと思います。

    また、これを守らないオレオレclass名が発生すると大変なことになるので、コードレビューなり、スタイルガイド、ドキュメンテーションでしっかりと食い止める作業も必要かなと思います。語彙集なんかを作っておくのも手かなと思います。

    [CSS]BEMの方法論とMindBEMdingという記法 – Qiita

    モジュールごとにファイルを分ける

    面倒くさいと思いますが、PHPとかでClassごとにファイルを分けるくらいのノリで分割しましょう。モジュールの量、粒度が視覚化されやすいです。また、感覚的に一つのモジュールから他のモジュールに触りづらくなります。

    CSSがどんどんプログラミングチックになってきているので、プログラミングで割と使われているやり方を取り入れると都合がいいことが多かったりします。

    CSSプリプロセッサを活用する。

    使ったことが無ければ、SASSのSCSS記法がいいかなと思います。とにかく情報が多い。

    特にBEMを採用するのであれば、”&”がかなり威力を発揮します。それに変数化できるものは極力変数化しておくと、特に後述のメディアクエリ周りでかなり威力を発揮します。

    いわゆるメディアオブジェクトというやつは、こんな感じに書けます。

    <div class="c-media">
      <img src="hoge.jpg" class="c-media__image">
      <div class="c-media__body">...</div>
    </div>

     

    .c-media {
        
        &__image {
            float: left;
            margin-right: 15px;
    
            &_right {
                float: right;
                margin-right: 0;
                margin-left: 15px;
            }
        }
    
        &__body {
            overflow: hidden;
        }
    }

    爆捗! WordPressテーマ作成ショートカット(3):CSSコーディングで泣かないためのSassの基礎知識と10の利点 (1/3) – @IT

    メディアクエリ(Media Queries)を散らかさない。

    メディアクエリの指定が何種類もあると、もうデバッグなんて無理です。とてもじゃないけどやってられない。SCSSを使うのであれば、foundationみたいに、こんな感じにまとめておくといい気がします。

    // Here we define the lower and upper bounds for each media size
    $small-range: (0em, 40em); /* 0, 640px */
    $medium-range: (40.063em, 64em); /* 641px, 1024px */
    $large-range: (64.063em, 90em); /* 1025px, 1440px */
    $xlarge-range: (90.063em, 120em); /* 1441px, 1920px */
    $xxlarge-range: (120.063em); /* 1921px */
    
    // Media Queries
    $screen: "only screen" !default;
    
    $landscape: "#{$screen} and (orientation: landscape)" !default;
    $portrait: "#{$screen} and (orientation: portrait)" !default;
    
    $small-up: $screen !default;
    $small-only: "#{$screen} and (max-width: #{upper-bound($small-range)})" !default;
    
    $medium-up: "#{$screen} and (min-width:#{lower-bound($medium-range)})" !default;
    $medium-only: "#{$screen} and (min-width:#{lower-bound($medium-range)}) and (max-width:#{upper-bound($medium-range)})" !default;
    
    $large-up: "#{$screen} and (min-width:#{lower-bound($large-range)})" !default;
    $large-only: "#{$screen} and (min-width:#{lower-bound($large-range)}) and (max-width:#{upper-bound($large-range)})" !default;
    
    $xlarge-up: "#{$screen} and (min-width:#{lower-bound($xlarge-range)})" !default;
    $xlarge-only: "#{$screen} and (min-width:#{lower-bound($xlarge-range)}) and (max-width:#{upper-bound($xlarge-range)})" !default;
    
    $xxlarge-up: "#{$screen} and (min-width:#{lower-bound($xxlarge-range)})" !default;
    $xxlarge-only: "#{$screen} and (min-width:#{lower-bound($xxlarge-range)}) and (max-width:#{upper-bound($xxlarge-range)})" !default;
    @media #{$small-up} { }
    @media #{$small-only} { }
    
    @media #{$medium-up} { }
    @media #{$medium-only} { }
    
    @media #{$large-up} { }
    @media #{$large-only} { }
    
    @media #{$xlarge-up} { }
    @media #{$xlarge-only} { }
    
    @media #{$xxlarge-up} { }
    @media #{$xxlarge-only} { }

    Media Queries | Foundation Docs

    また、CSS一番小さな画面から設計するのか、大きな画面から設計するのかの方針は最初に決めておきましょう。まぁ基本的にはモバイルファールストが良いとおもいます。

    CSSごとにデフォルトスタイルがモバイル用なのか、大画面用なのかがぶれると最悪です。変数化するなり、Mixinを作るなりで、メディアクエリを書かない努力をすべきです。

    とにかくメディアクエリの指定は必要最小限にとどめる。メディアクエリを書かずに乗り切れるところで使ってしまうと後々デバッグで苦労します。

    結論

    現時点では、FLOCSSをちゃんとやることが最適解かなと思います。ドキュメントも日本語で整備されているし、説明も細かいのでおすすめ。Frontrend in Nagoya で存在を知ってから3ヶ月くらい取り入れてやっていますが、SMACSSとかやっている時のモヤモヤが解決されてていいです。

    最初からBEMを使うことが前提になっていることも良いと思います。

    ドキュメントが長いので最初に躊躇しがちですけど、すぐにどうしていいかわからなくなるので、ドキュメントが長いのはいいことかなと。

    慣れてない人は、メロン本を読みながら繰り返し体にたたき込むのがいいとおもいます。あと、CodeGridのBEM、SMACSSの記事辺りは読んでおきましょう。

    CSSってフリーダムすぎるので、使ってて最初のうちにものすごい不自由で、CSS書く時間が2倍くらいになってしまうこともありますが、それくらいがっちりしないとすぐに破綻しやすいものかなーと思います。

    参考図書

    Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法 Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法

     

     

  • Sublime Text 3 の Asphalt テーマがなかなか良かった。

    Sublime Text 3専用のテーマ Asphalt を使い始めて3ヶ月ほど経つのですが、なかなかグッドです。

    Theme – Asphalt – Packages – Package Control

    見た目はこんな感じです。

    スクリーンショット
    スクリーンショット

    フラットデザインですね。

    Sublime Text 3で追加された、サイドバーのアイコン表示などの新機能に対応してます。

    インストール方法

    コマンドパレットで、Theme – Asphaltというパッケージをインストールしてください。その後、Preferences の Settings – Userを開いて、

    {
        "color_scheme": "Packages/Theme - Asphalt/Asphalt.tmTheme",
        "theme": "Asphalt.sublime-theme"
    }

    の設定を追記してください。

    Sublime Text 3 専用に作られたということで、新しい機能にも早い段階から対応していたりするのがかなりおすすめ。

  • 週末iPhone 6/6 Plusのスクリーンサイズとかの記事がものすごいシェアされたことに思うこと。これからどうしようか。

    5キロやせました。ついでに禁酒中です。WordCampまでにはなんとか禁酒を解除したいところです。

    金曜日に書いた記事がものすごいアクセスになって若干びびっております。10分弱で書いた記事がここまでの閲覧数になるとはびっくりです。はてブとgunosyパワーってすごいと思います。とりあえず深夜テンションでつらつら書いていこうと思います。

    とりあえず実践していること

    1pxをきれいに見せたいという気持ちを捨てる

    当然可能な限りきれいに見せたいんですけど、現実問題、特にiPhone 6 Plusなんかそうですけど、1pxをきれいに見せようってのは無理です。詳しくは、http://www.paintcodeapp.com/news/iphone-6-screens-demystifiedでも見てもらえれば。

    すべてのデバイスで同じようにとかナメた幻想は捨てる

    1pxが4pxだったり、9pxだったり、それを1/1.15倍したものだったり、無理です。device-pixel-ratioが1.5のデバイスとかもありますし。Androidとか。

    ブラウザのCSS対応の話もありますし。
    そもそも、フォントも違うし、WEBフォントも速度の問題で乱用はできないですし。それに耐えうる設計を考えましょう。

    画像は可能な限りSVGとかアイコンフォント

    それでもやっぱりロゴとかはきれいに見てもらいたいもんで、その手の画像は可能な限りSVGにしたり、アイコンフォント(fontawesomeみたいな)にしてます。

    スクリーンサイズとかデバイスに依存しないサイト設計

    いい加減に骨身にしみましたけど、来年の今頃にはどんなデバイスが出ているんでしょうね。iPhoneの次の機種とかどんなスクリーンサイズなんでしょうかね。てかGoogle Glassとか流行ってるんですかね。僕メガネが本体系男子なんでかけれないですけど。全く別業界の営業さんたちがiPadを持たされてなんて話もよく聞きます。

    僕はWEBサイトのフロントエンドを主な飯の種にしている人間ですが、新しいiPhoneが出るたびにリニューアルするわけでもないですし、というかiPhoneだけじゃないですし、自分が想像もできないようなことにどうせなってると思います。それにも可能な限りの想像力を働かせた上でサイト設計をしていくことが大事だと強く感じてます。

    別にユーザーエージェント使ってもいいと思いますし、レスポンシブじゃなくても何でもいいとは思います。適材適所。 

    とりあえずサクッとモックアップ作る

    デザイナーさんやら営業さんやらを説得したり、一緒に考えたりする時にサクッとモックアップを作るようにしてます。
    経験と直感から来る「これあかんよな・・・」ってのは説得材料にならないし、でもかといって言語化は得意ではないので、とりあえずサクッと動くものを作るようにしてます。bootstrapとか使う予定がない案件でも、とりあえずフレームワークでサクッと作ることが多いです。
    デザイナーから来たカンプを見た目通りコーディングすれば良いって時代はとうの昔に終わっているので、そいういうコミュニケーションは取っていく必要があるかと。
    でも、コミュニケーションが増えるのは当然コストになるので、なるべくその質を高める必要もあるのかなと。

    残念ながら銀の弾丸は存在しない

    未来のことなんて誰にもわからないですし、そもそもHTML/CSSでWEB作ってるかもほんとにそうかと思う日々です。いや、たぶんさすがにHTML/CSSはやってると思うけど。日々考え方をアップデートしつつ考えていかないといけないことだと思います。

    実際にちゃんと設計しないととはさんざん言いますけど、ちゃんとした設計って何だよって言われるとパッと答えられない自分が居たりします。

    自動化できることは自動化したり、フレームワーク使ったり、コードの設計をしっかりしたりしてそういう時間を作ることもとても重要だと思います。
    また、ワークフローだったりいろいろ変えねばならない部分は多々出てくると思いますので、周りを巻き込んでいくことは重要だと思ってます。特にエンジニアでない人間も巻き込んで行くことは大切かなと思います。なかなか難しいことだとは思いますが。

    要はこういうことだと思う。

    個人的には、こういうことを考えていくことにWEBのデベロップとかデザインの根本の面白さがあると思ってるんですけどね。
    まとまりのない事をつらつら書いてしまいましたが、とりあえずこんなこと考えてWEBやってるつもりです。

    このブログのデザインもいい加減に直さないと・・・・

  • iOSシミュレーターで見た、iPhone 6 / iPhone 6 PlusのMedia Queriesに関する値について。

    Xcode 6.1 betaのiOSシミュレーターにiPhone6とiPhone6 Plusが居たので、早速調べてみました。
    viewportにwidth=device-widthを指定したときの値です。

    追記:縦向き横向きのサイズも追加しました。

    iPhone 6

    • device-pixel-ratio: 2.0

    縦向き

    • device-width: 375px
    • device-height: 559px

    横向き

    • device-width: 667px
    • device-height: 375px

    iPhone 6 Plus

    • device-pixel-ratio: 3.0

    縦向き

    • device-width: 414px
    • device-height: 628px

    横向き

    • device-width: 736px
    • device-height: 414px

    レスポンシブなコーディングや設計大事ですね。device-pixel-ratioが3.0なデバイスはXperia Zとか、他にもちょこちょこあるようです。
    Device pixel density tests

    Xcode 6.1のダウンロード

    可能な限りSVG等で対処していきたいですね。

    追記:iPhone 6 Screens Demystifiedこんなサイトもありました。仕事早い。そしてiPhone 6 Plusがエゲつない感じ

    追記:9/16日:週末iPhone 6/6 Plusのスクリーンサイズとかの記事がものすごいシェアされたことに思うこと。これからどうしようか。

  • wp_headからコメントのフィードへのリンクを消す。[追記あり]

    クライアントワークとかでコメントを使う機会って少ないですし、自分の中二病的ポエムサイトにコメントがついたりすると死にたくなりますよね。

    そんなわけでコメント欄をテーマに設置しないことが多いんですけど、それだけだとコメントフィードへのリンクがwp_headに出力されてしまいます。

    <link rel="alternate" type="application/rss+xml" title="ほげほげ のコメントのフィード" href="http://example.com/blog/hoge-hoge/feed/">

    みたいなやつ。

    なんだか気持ち悪いので取ってしまいましょう。

    ページ・投稿ごとに、ディスカッションの設定のチェックをすべて外す。

    discussion

    これにチェックが入っていないページであれば、コメントフィードは出力されません。

    投稿のデフォルト設定の「コメントの許可」、「他のブログからの通知を受け付ける」のチェックを外す。

    defaultsetting

    こいつらにチェックが入ってると、新しい投稿を作るたびにディスカッションのチェックを外さなければいけないので、チェックを外しましょう。

    でも忘れるよね・・・ということで、functions.phpにコピペできるコード。

    add_action(“init”,function(){
    update_option( “default_ping_status”, true );
    update_option( “default_comment_status”, true );
    });

    PHP5.3以上じゃないと動かないですけど、イマドキ5.4未満とかあり得ないと思うので別にいいかなと。

    追記:まがりんさんからツッコミ入ったので、修正。

    add_action("init",function(){
        add_filter("comments_open", "__return_false");
        add_filter("pings_open", "__return_false");
    });

    こっちの方がベターですね。

  • VCCWで作ったvagrantfileをgitでちゃんと管理する。

    VCCWといえば、宮内さんが作った、Vagrantで超簡単にWordPress環境を作るやつですが、これを、git cloneして、Vagrantfile.sampleをリネームすれば、vagrant環境が立ち上がります。

    で、これで作ったVagrantfileをgit管理したい訳ですが、そもそもリポジトリはGithubに存在していて、宮内さんのコミットログが山のように入っています。これにコミットしてもいろいろ面倒ですし、バージョンを上げようと言うときに困ったり。そんなときの対処法です。

    VCCWとVagrantfileの場所を変更する。

    実は、Vagrantfile.sampleと別の場所にVagrantfileを作れます。

    https://github.com/miya0001/vccw/blob/master/Vagrantfile.sample#L42

    ここのパスがデフォルトではvccwのディレクトリになっていますが、ここを

    WP_CHEF_COOKBOOKS_PATH = "~/vccw"

    にすると、MacやLinuxであれば、ホームディレクトリの直下にあるvccwを参照します。コメントに書いてありますね。見落としてました。。。

    こうすることで、いちいちvccwをクローンしてこなくても良くなりますし、複数の仮想マシンを立てるときもvccwをいちいちcloneしてくる必要がないです。

    また、
    + Vagrantfile
    + vccw
    + Vagrantfile.sample
    + cookbooks
    + site-cookbooks
    みたいな構成にする時は、

    WP_CHEF_COOKBOOKS_PATH = File.join(File.dirname(__FILE__), "vccw")

    としてやれば良いです。

    僕は、この構成にして、vccwのディレクトリは、gitサブモジュールとして登録してます。プロジェクトによってはこっちの方がベターかもしれません。(windowsの人が混じってるときとかですかね。)

    ちゃんと、コメントは読むもんですね。

  • PHP5.4にAPCを導入した。

    AmazonLinuxにて、PHP5.4用のAPCを導入するときのメモ。

    $sudo yum install php54-pecl-apc

    とすれば良いです。そのあと、php-fpmを

    $sudo /etc/init.d/php-fpm restart

    みたいな感じで、再起動すれば完了です。nginx + php-fpmであればこんな感じです。
    Apacheの場合は、httpdの再起動が必要かもしれません。

    php-pecl-apcは5.3用です。
    基本的に、php-hogeは、5.3用、php54-hogeが5.4用、php55-hogeが5.5用です。php-hogeな名前のパッケージは、大抵5.4、5.5用とそれぞれ存在するので、お間違えの無いように!