WP Super Cache をやめて W3 Total Cache をインストールした

WordPressのキャッシュプラグインは色々あるけど、今までこのブログでは WP Super Cache を使っていた。Automattic製ということもあり、信頼がおけると考えていて、実際「静的HTMLをキャッシュして返す」という部分では特に問題なく動作していた。

しかし、WP Super Cacheはサーバサイドでレスポンスを静的HTMLとしてキャッシュするという用途に特化しており、ブラウザキャッシュの設定などは別途行う必要がある。

カスタムテーマにヘッダーをセットする関数を仕込んだりしてもいいのだけど、WordPressなんだからプラグイン + GUIで設定したいということでいくつか試した結果、 W3 Total Cache が良い、という結論になった。

W3 Total Cacheをインストールすると、WordPressの管理画面に「パフォーマンス」というメニューが追加される。

このメニューから各種設定を行えるのだが、レスポンスキャッシュだけでなく、HTML/CSSの圧縮、データベースキャッシュ、PHPレベルのキャッシュ、ブラウザーキャッシュなど多岐にわたるキャッシュ設定を行うことができる。さらに、CDNとのインテグレーションなどもあり、WordPressのパフォーマンス最適化に関する設定全般を引き受けるプラグインになっている。

ブラウザキャッシュも管理画面から細かく設定できる。

W3 Total Cacheを入れていくつか最適化した結果、PageSpeed Insightsの計測結果は95点になった。

さらなる最適化には不使用cssの削除など、出来合いのテーマを使っていては手を出しづらい領域に踏み入れる必要がある。現状のスコアも悪くはないので、これ以上の最適化はしなくても良いかなーと思っている。

『ノンデザイナーズ・デザインブック』を読んだ

ノンデザイナーズ・デザインブック [第4版]

『ノンデザイナーズ・デザインブック』は、デザインの専門的な訓練を受けたことのない「ノンデザイナー」に向けた、ビジュアルデザインの入門書。

本書でいう「ビジュアルデザイン」は文字を中心としたデザインであり、デザイン例は書籍、雑誌、チラシ、ダイレクトメール、名刺など。

「近接」「整列」「反復」「コントラスト」の4原則に基づいて、情報を整理し、それを的確に伝えるよう構造化することで、ビジュアルデザインは見違えるほど良くなる。

本書はデザイン原則を適用したことによる改善例をこれでもかというほど見せてくれるので、頭で理解するだけでなく、審美眼が鍛えられる。

また、書体(フォント)についての基本的な解説もあり、例えば「serif」と「sans-serif」の何がどう違うのか、はっきり指摘できるようになる。

本書の日本語版については、日本語独特の事情(縦書きの存在やフォントの違いなど)の補足もあり、単なる翻訳ではなく、ローカライズになっている点もポイントが高い。

総じて良くできた書籍で、デザイナーがデザインをする際にどういうことを考えているのか理解する助けになる。

なお、本書のテクニックはWordで作る報告書やPowerpointで作るプレゼン資料といったものにも適用できる。資料作成に特化した書籍としては同著者の『シンプルでよく効く資料作成の原則』もあり、こちらも読んでみたい。

『Collection Pipeline』を読んだ

Collection Pipeline – martinfowloer.com

本ではなくWeb記事だけど、面白かったので読書メモ。

コレクションパイプラインとは

コレクション(配列、リスト等)に対する操作をつなげて書くプログラミンスタイル。たとえば、記事のリストから、「JavaScript」をタイトルに含む記事の総語数を取得したい場合、JavaScriptでは以下のように書ける。

articles.filter(a => a.title.includes('JavaScript'))
  .map(a => a.words)
  .reduce((p, c) => p + c, 0);

初めに記事のリストをフィルタリングし、次に語数の配列へ変換してから、語数を合計している。

これをループを使って書くとこうなる。

let result = 0;
for (let a of articles) {
  if (a.title.includes('JavaScript')) {
    result += a.words;
  }
}

ループの方が決定的に劣るということはないが、コレクションパイプラインを使うと配列に対する操作を宣言的に書くことができる。

コレクションパイプラインは、無名関数(言語によってはラムダ式などともいう)を多用することから、関数型のパラダイムや、関数型っぽい機能といわれることも多い(実際、僕もそう思っていた)。

しかし、本記事によると、コレクションパイプラインの発祥はSmalltalkであるらしい。

Smalltalkでは、コレクションに対する操作を以下のように書ける。構文は独特だが、コレクションに対する操作を連結するスタイルは同じ。

 ((someArticles 
      select: [ :each | each tags includes: #nosql])
      sortBy: [:a :b | a words > b words]) 
      copyFrom: 1 to: 3

一方、初期の代表的な関数型言語であるLispでは、こうなる。

(subseq
   (sort
      (remove-if-not
         (lambda (x) (member 'nosql (article-tags x)))
         (some-articles))
      (lambda (a b) (> (article-words a) (article-words b))))
 0 3)

素朴な関数型のスタイルでは、関数呼び出しが実際の処理の流れとは逆順になる点が、Smalltalkとは異なる。この点、モダンな関数型言語(Closureなど)では、関数呼び出しをシーケンシャルに書く機能が用意されていることが多い。

(1) コレクションのシーケンシャルな操作を連鎖させるというプログラミングスタイルは、初期のオブジェクト指向言語であるSmalltalkから生まれた

(2) 無名関数(ラムダ式)は関数型言語の専売特許ではない(C++、Javaといった代表的なオブジェクト指向言語がラムダ式を採用しなかっただけ)

というのが個人的に面白いと思ったポイント。

Collection Pipelineを避けるべき状況

(1) 言語がサポートしていない場合

本記事では、ラムダ式がなかった時代のJavaが例に挙がっている。他にも、Goにはラムダ式はあってもコレクションパイプラインは使えない。このような言語で無理してコレクションパイプラインを使うと、混乱の元になる。

(2) リスト内包表記を使える場合

Pythonなどの言語には [i for i in range(10) if i%2==0] のように、リスト内でコレクション操作を行える機能が備わっている。

リスト内包表記が使える場合は、 コレクションパイプラインではなくリスト内包表記を使った方が、短く読みやすいコードを書けることがある。

(3) コレクションに対する操作が複雑な場合

コレクションパイプラインで実装できる操作であっても、それが10行以上になるような複雑な操作であった場合、単一のコレクションパイプラインとして実装するのではなく、関数を抽出して、細かいステップに分けるべき。

関連書籍:Refactoring, 2nd Edition

Refactoring: Improving the Design of Existing Code (2nd Edition) (Addison-Wesley Signature Series (Fowler))

『レガシーコードからの脱却』を読んだ

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

ソフトウェア業界が成熟するにつれて、既存のソフトウェア資産をメンテナンスする技術が重要度を増している。比較的歴史の浅いWeb業界でも、10年物のソフトウェアは珍しくない。キラキラしたWebスタートアップも、5年もすれば技術的負債の返済に追われるようになる。

そんな中で、いかにしてソフトウェアを保守し、サービスを継続していくか、という点に注目して、『レガシーコードからの脱却』を読んだ。

レガシーコードを題材にした書籍としては、他にも『レガシーコード改善ガイド』『レガシーソフトウェア改善ガイド』などがある。

『レガシーコードからの脱却』は、これらと比較すると、開発プロセスに焦点を当てている点が異なる。

『レガシーコード改善ガイド』は、レガシーコード(=テストのないコード)をいかにしてテスト可能にするか、という点を徹底的に突き詰めた書籍である。

一方、『レガシーソフトウェア改善ガイド』は、技術的負債はコードだけでなく、ソフトウェアを取り巻くインフラストラクチャーや開発環境にも潜むことを示した。

そして『レガシーコードからの脱却』は、レガシーコードはレガシーな開発プロセスから生まれると指摘し、アジャイルソフトウェア開発を正しく実践することで、レガシーコードから脱却できると説いている。

読者の現在のロールによって、どの書籍が最もフィットするかは変わってくると思う。

現場でレガシーコードと格闘しているソフトウェアエンジニアなら、『レガシーコード改善ガイド』に励まされる部分は多いはず。また、『レガシーソフトウェア改善ガイド』も具体的なテクニックが載っているので、すぐに適用しやすい。

それに対して、『レガシーコードからの脱却』は、コンサルタント的な、開発チームに対して外からアドバイスするような視点をもっている。現場でレガシーコードに取り組んでいるエンジニアが明日役立てられそうなテクニックが載っているわけではない。

一方で、アジャイルがソフトウェア開発のベストプラクティスであることや、まずいソフトウェア開発の方法によってどれだけの経済的損失が出ているか、といった点に十分な議論を尽くしている点が、類書とは異なる。どちらかというと、メンバーよりはリーダーやマネージャ、CTOといったポジションの、開発プロセスの改善に責任を持つ人たちが読むべき書籍という印象を受ける。

『レガシーコードからの脱却』は、バグの多いソフトウェアや開発スピードの遅さに悩まされていて、より良い開発体制を作りたいと願っている人にとっては、読む価値のある本だと思う。

『テスト駆動開発』を読んだ

テスト駆動開発

『テスト駆動開発』は、TDDの先駆者・Kent Beckによる Test-Driven Development: By Example の日本語訳。翻訳者は日本国内におけるTDDの伝道師・和田卓人氏。

原書は2003年に出版された。日本語版も出版されていたが、ピアソン桐原のピアソングループ離脱に伴って絶版となっていた。本書は2017年に改めて翻訳し直された書籍であり、その際に訳者によるアップデートがなされている。ディテールの古さを感じる部分はほとんどない。

僕がテスト駆動開発に興味を持った頃には、旧『テスト駆動開発入門』はすでに絶版になっていたため、Test-Driven Development: By Example の日本語訳を読むのは本書が初めてだった。

退屈そう・お堅そうというイメージから敬遠していたのだけど、実際に読んでみると、とても読みやすかった。実際のコードの例が豊富で、記述も具体的でわかりやすかった。

また、本書の価値を大きく上げているのが、付録Cの「訳者解説:テスト駆動開発の現在」である。これは原書出版後のテスト駆動開発の流れを概観した文書で、本書を読んだ後、さらにテスト駆動開発を深く学びたい場合のブックガイドにもなっている。

テスト駆動開発は抽象的な理論を伴うものではなく、教条主義的に守らなければならないものでもない。ソフトウェア開発におけるテクニックのひとつで、それを身につけておくと役に立つことがある、といった感じで、ほどよい距離感のもとテスト駆動開発が解説されていて、読後感は良かった。TDDについて学びたい人が最初に読む書籍としてオススメ。