一般的な nonce （Nnumber used ONCE、Weblio 英和辞典 によると、ナンス
又は ノンス
と発音）は、Web サイト、特にデータベースに不可逆な変化を引き起こす、意図しない、あるいは重複したリクエストから Web サイトを保護するための、セキュリティが目的のワンタイム・トークンです。
WordPress の nonce は、管理画面に対する CSRF 攻撃 （英語版 Wikipedia によると、シーサーフ
と発音）対策として広く知られているかと思いますが、意外にも Ajax との組み合わせを解説した日本語記事が見当たらなかったので、「いまさら」の共有です。
本記事では、単に Ajax の Tips 的な実装方法だけではなく、CSRF 攻撃の原理や対策についても少しだけ触れたいと思います。またその上で、Ajax に nonce が必要なパターンについて言及します。
さらに、WordPress 3.5 から導入された新しいフィルターフックの使い道を探ってみたいと思います。
WordPress のプラグインを作って公開すべく、基礎からみっちり学習しています。
Codex 日本語版 の プラグインの作成 の項には、外部リソースとして Ozh さんの2009年記事 「WordPress プラグインのコーディングでよくある10個の間違い」 が紹介されています。
Professional WordPress Plugin Development の著者でもある Ozh さんは、WordPress プラグイン・コンペティションの審査員を努めて来た関係上、今までに相当数のプラグインをレビューしているそうです。
私も色々なプラグインのコード・リーディングをしてみましたが、古いけど良質なこの記事が、必ずしも広く認知されてるわけではないことを感じています。
ということで、古くなっている部分を新しい情報で補いながら、この記事を翻訳で共有してみたいと思います。
これまでも サービスAPI の更新や、それに伴う UI の変更など、小刻みな機能向上が図られていましたが、昨年11月、GitHub の ヘッダ、フッタが新しくなった のを皮切りに、12月には Gist のリニューアル と GitHub トップページのリニューアル が立て続けに行われました。
また今年1月には、ユーザー数が、アカウントベースで300万人を超えた そうです。
小さくかつ素早く、不断のサービス向上を図る姿勢が、ここまでユーザーを惹き付けた理由なのでしょう。
一方、公式ブログ を追いかけていくと、単に Git のリポジトリ・サーバーとして便利で使い易くする以上に、「自然に人が集まる魅力的なコミュニティ」を目指し、「誰もが気軽に参加できるオープンソース・コミュニティを創る」という意気込みのようなものを感じました。
人が集まれば、それだけビジネスの機会も増えるというワケです。
そこで今回は、「次の目標：ユーザー数500万」という想定で、リニューアルの狙いを次の5つの仕掛けとしてまとめてみました。
WordPress の WPtouch や Ktai Style とキャッシュ系プラグインを 併用
する場合には、キャッシュさせないように設定するのが一般的でした。なぜなら、同じ URL のページを、デスクトップ用とモバイル用のキャッシュに分ける事が難しく、両者が混在しちゃうという問題が発生するからです。当然、ケータイやスマートフォンは、キャッシュの恩恵が受けらないですよネ。
ところが Quick Cache なら、オプションでたった1行のコードを設定すれば、それぞれのページを別々にキャッシュできちゃうんです。
ということで、前回記事 では wp-config.php にコードを追記しましたが、今回はもっとスマートに、Quick Cache 側に設定する Tips として紹介したいと思います。
続きを読む
今回は、WordPress の人気キャッシュ系プラグイン Quick Cache、W3 Total Cache、WP Super Cache を、3者共通のページを丸ごとキャッシュする 「ページ・キャッシュ」 機能に絞り、比較をしてみました。
これらの情報は既に多数報告されているので、普通に使う分にはそれらで十分なのだと思いますが、性能を引き出すためにも知っておいて損はないかなと思うことをまとめます。
Lacoocan が重たい腰を上げ、今年３月末から MySQL5 が利用可能 になったのを機に、WordPress を 3.4.2 に上げると共に、プラグインを1から見直しています。
すぐに キャッシュ系プラグイン に手を出すのではなく、なるべく素の特性を観ながら、選ぶ楽しさを味わうのもイイかなと。
そんな中、Google Analytics （以下 GA） の集計結果を読み込み人気記事として表示する Google Analytics Popular Posts （以下 GAPP） というプラグインを使いたいと思ったのですが、そのキャッシュ設定をオンにしても、GA との通信で更新に数秒かかってしまうという問題に直面しました。
つまり、たまたま更新のタイミングに当たった運の悪い人にとっては、重たいブログとなってしまうのです。
そこで今回は、そういったプラグインに起因する重たい処理を訪問者のアクセスから分離し、サーバーとのコンビネーションで非同期に処理させる方法を探ってみました。
ここ最近、jekyll に関する記事を目にする事が多くなりました。
以前から WordPress でオリジナルなブログを作ってみたいと思いながらも、なかなか重い腰が上がらなかった私が、なんとなく jekyll でブログを作り始めてみたら、以外にオモシロかった、という話をまとめてみたいと思います。
本来生まれも育ちも違う、WordPress と jekyll を比べる こと自体はナンセンスなので、jekyll でどこまでできるかが本記事のメイン・テーマです。
大抵は 「ブログなら、最低このぐらいの機能が欲しいよネ」 というのがあると思います。例えば、私も使っている Octopress では、カテゴリとタグを使い分けることが出来ません。またカテゴリを階層化したい人もいるでしょう。「続きを読む」的な機能だって、欲しいですよネ。
一方海外では、「WordPress から jekyll に乗り換えました！」 的な記事を目にすることも多く、jekyll はある面で、他の CMS にない魅力を持っているのも事実だと思います。
そこで今回は、「PHP は飽きたんで、Ruby でも始めてみようか」 的な人や、「WordPress でデザイン・テンプレートを作ってみたいんだけど…」 的な人を jekyll に引き込むことを目標に、そのポイントと魅力、およびブログ構築に必要な実際の作り込みについての情報を中心に、話を展開してみたいと思います。
また GitHub に、Twitter Bootstrap を使ったレスポンシブな 実験的テンプレート と サンプル も公開しましたので、合わせて参考にしてください。
2012年2月、Modernizr 2.5 の カスタム・ビルダー から Respond.js が外されました。理由は、HTML5 Boilerplate （以下 H5BP） コミュニティでの決定です。Respond.js は、IE8 以下などのメディアクエリ未対応なブラウザにもその代替え機能を提供するスクリプトで、レスポンシブ Web デザイン
を支えるスクリプトとして、H5BP に長らく （8ヶ月） 採用されてきた経緯があります。
ではなぜ、Respond.js は外されたのでしょう？
今回は、その決定を下した長～い議論 Issue #816: Revert mobile-first media queries and remove respond.js
から、ベスト・プラクティスの要点と、Paul Irish の考える H5BP の理想像を読み解いてみたいと思います。
ヘタクソで読みづらいですが、日本語訳 も作りましたので、どうぞ 
。
6月22日未明、Twitter のサーバーがダウン し、全世界でサービスが停止しました。一部マニアの方々は、動いていた ケータイ用サーバー から この状況を楽しんでいた (?) ようですが、OMG..twitter was down….closest thing to living without oxygen for most of us….
（なんてこった、オレたちに酸素なしで生きろっていうのか） という声に代表されるように、世界各地で悲鳴が上がったようです。
さて純正の Twitter ウィジェット を貼っているあなたのサイトは、この障害でページが真っ白になったり途中で引っかかったりせず、無事にコンテンツを提供できたでしょうか？
ということで、前回 と同ネタですが、こういった フロントエンドの単一障害点
（SPOF） をより簡単にチェックできる Chrome エクステンション SPOF-O-Matic を紹介します。
SPOF
と聞いて、すぐに 「あぁ、Single Point of Failure （単一障害点） のことネ」 と分かる人は、まじめにシステム工学を勉強した人か、ハードウェアを含む情報システム設計に知見のある人だと思います。
では、「フロントエンド」 が付くと、いったい何を指すのでしょうか？
現代の Web サイトの多くは、自分が管理する （あるいは借りている） サーバーで全てのサービスを賄うのは、Yahoo や Google などの超大手以外ではほとんどないんじゃないかと思うほど、サードパーティが提供するサービスを取り込んでいると思います。Facebook、Twitter、flickr、YouTube はもちろん、jQuery などのライブラリ CDN、WebFont、アクセス解析なんかもありますネ。
もしこういったサービスを提供するサードパーティのサーバーがダウンした時、あなたのサイトは、その主たるコンテンツをちゃんとユーザーに提供できますか？ というのが今回のお題です。
さらには、こういった単一障害点を分析し対策を打っておく事が、実はサイトのボトルネックを把握し、レスポンスを上げる事にもつながるという話をしたいと思います。