海外からの投稿を弾くスパム対策用WordPressプラグインをリリースします | ゆっくりと…
スパム投稿を選別して弾くプラグインは、Akismet はもちろん、CAPTCHA を使うタイプ、日本語を含まない投稿を禁止するタイプ、ロボット投稿の裏をかく隠しフィールドを備えたタイプなどなど、数多くあります。 それぞれに一長一短がある中で、投稿者の国を選別するプラグインがあっても良いんじゃない？ ということで、これまた一長一短のあるプラグイン IP Geo Block を作りました。島国ニッポンならではの割り切りができる人なら、お試しください 😀 。 IP Geo Block 原理は単純で、投稿者の IP アドレスが属する国を、ローカルのデータベースまたは外部 API を利用して調べます。受け入れOKな投稿はさらに Akismet で選別される手はずとなっています。 また特徴の1つとして、スパム投稿自体を減らしてくれるかもしれない機能を搭載しています。 インストール プラグイン公式ペー
サイト速度とonload再考 | ゆっくりと…
単にウケ狙いなら「革新的！GAのページ平均読み込み時間を劇的に速くする方法」とか「もう3rdパーティーに邪魔させない、超高速スクリプト読み込み術」（笑）とかの煽りタイトルを付けるところですが、今回はもっと本質的なことを論じてみたいと思います。 「プログレッシブレンダリングでUXを向上させるJS非同期読み込みのベストプラクティス」では、スクリプトの読み込みと実行を window.onload 対象から切り離し、見た目のページ速度を速くする方法について書きました。この方法は既存のスクリプトを書き換える必要があるため、Stoyan Stefanov によって 実験的に実装された Facebook SDK か、自前のスクリプトにしか適用できませんでした。 しかし今回、Hatena や Twitter、Pocket、Disqus など、他の 3rd パーティ製スクリプトにも適用できる方法 − “進化
実践GitHub Pages運用のユースケースとワークフローの詳細 | ゆっくりと…
前回、GitHub Pages 活用の概要を書きましたが、実際に運用していくと、master と gh-pages をどう使い分けるか、また両者の同期をどう行うかなど、いくつかの課題が浮かび上がってくると思います。 そこで今回は、実際に GitHub Pages 上で運用されている Dive Into HTML5 をよく知る立場から書かれた記事 「GitHub Pages Workflow and deleting git’s `master` branch – Oli.jp」 の翻訳を中心に、関連するいくつかの記事から、ユースケースと運用のシナリオ、及びそれに応じたワークフローをまとめてみました。 以下は、その参考記事です。 Git post-commit hook to keep master and gh-pages branch in sync by Paul Irish 2011
Respond.jsとレスポンシブWebデザインをめぐるベストプラクティス議論 | ゆっくりと…
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 の理想像を読み解いてみたいと思います。 ヘタクソで読み
document.writeを使った遅いブログパーツ（例えばzenback）を非同期化してサイトを高速表示する方法 | ゆっくりと…
広告やソーシャル系のサードパーティー製ブログパーツを張りたいんだけど、サイトの表示速度が遅くなるのって我慢なりませんよネ。こういったブログパーツの多くが JavaScript で作られています。自サーバーに設置したスクリプトならまだ手の打ちようはあるし、本サイトでも JavaScript 読み込みを高速化するための非同期化ネタを幾つか扱ってきました。例えば Google Analitics の非同期トラッキングスニペット や LABjs、HEAD JS などの非同期ローダーが有名なところでしょう。 ところが困ったことに、こういったサードパーティ製スクリプトに document.write が使われていると、Google Analitics のようなテクニックや非同期ローダーでは、ほとんどの場合でページが白紙となってしまい使えません。Twitter や Facebook など超有名どころは既
IPアドレスからアクセス元サーバーの位置情報を調べるjQueryプラグイン | ゆっくりと…
2000年代前半、荒らし や 掲示板スパム に悩まされていた頃、JPNIC やら RIPE やらの WHOIS データベースで IP アドレスの出所を調べ、「また関西からだよ」 とか 「お、役所からだゾ、串刺されてんのかな」 とかやっていたわけですが、アクセス元を調べたところで結局のところ IP を弾くイタチゴッコを続けていたものでした。当時は、WHOIS にわざわざ アドレスをコピペしてクリック じゃなく、自サイトからオンラインで調べられたら便利だなぁと思っていました。 さて今もそんなニーズがあるのかわかりませんが、jQuery Plugins にそんな思いを実現してくれる jqIpLocation というプラグインが紹介されていたので、試してみました。 実はこのプラグイン、IPInfoDB が無料で提供する DB サービスを利用して、IP アドレスからアクセスポイントの位置情報を引っ張
CSS/JavaScriptのAsynchronous Loadingをめぐる熱い論議 | ゆっくりと…
2011年2月21日 追記 $script も新規参戦してきました。高々 643 バイトで、非同期読み込みや依存性の制御などができるそうです。いずれ紹介したいと思います。← 「新参の超軽量JavaScript非同期ローダー3種を徹底比較」で紹介しました！ これらのローダーのうち、LABjs の作者が 「On Script Loaders」 で HeadJS と ControlJS について意見をしていて、面白そうです。そのうち日本語訳や各ローダーの比較を行ってみたいと思います。 ローディング・スクリプトをめぐる議論 さてさて、本エントリーの本題は前述のローダーではありません。「Prefer asynchronous resources」 や Google Analytics のスニペット に示されているような、ローディング・スクリプトの変遷をまとめてみます。 これらのスクリプトのごく初期は
ブラウザ動作の理解－レンダリングの負荷を測る | ゆっくりと…
転勤・単身赴任というライフ・イベントがあり、すっかり更新が止まっていましたが、前回 に続き、「Rendering: repaint, reflow/relayout, restyle」から後半のレンダリング負荷を測るツールの使い方をお届けします。記事中の リフロー や リペイント といった用語は、前回記事「用語の定義」 を参照してください。 元記事は初稿が2009年12月でツールのバージョンも古いため、現時点の最新バージョンで記事を再構成しています。また実行環境によって観測結果が異なるため （非力なマシンの方がレンダリング負荷の割合が高いけど、サンプルとしては分かりやすい）、以下に本記事で試した環境を記しておきます。 dynaTrace AJAX Edition バージョン：Version: 2.1.0.603, built on 2010-12-15 ブラウザ、PC：IE8 / Wind
ブラウザ動作の理解－リフローとリペイント及びその最適化 | ゆっくりと…
ブラウザ動作の理解の2回目です。今回はレンダリング・ツリーの更新に絡む、リフロー （要素の大きさ、位置などの再計算） とリペイント （描画） に関する解説を、「High Performance Web Pages – 20 new best practices」 の著者 Stoyan Stefanov のブログエントリーから 「Rendering: repaint, reflow/relayout, restyle」 を翻訳してお届けします。 同記事は、前半がリフローとリペイントに関する解説と、表示レスポンスを向上させるためのスタイル変更に関する Tips、後半は dynaTrace AJAX Edition と SpeedTracer を使った IE および Chrome の描画パフォーマンスの計測の解説で構成されてる、長い記事となっています。 今回はその前半部分をご紹介します。 レンダ
GitHub Pagesホスティングサービス（ほぼ）完全活用ガイド | ゆっくりと…
GitHub がオープンソースの場として魅力的な理由は、Git という優れた分散・協調型リビジョン管理システムのリポジトリー・ザーバーとして誰でも利用できるということはもちろん、README などのドキュメント生成機能やコメンティング機能、問題のトラッキング機能など、Git を補助し、オープンな分散・協調開発を支えるサブシステムが充実している点が挙げられるでしょう。無料でもかなりのことができるのに、ビジネスとしてもちゃんと成立している理由はこんなところにあるように思います。 ただ、同種サービスの Google Code や Bitbucket と決定的に異なり、GitHub の最大の魅力となっているのは、GitHub Pages という1種のホスティング・サービスではないかと思います。成果物をただずらずらと味気ないページに並べるのではなく、趣向を凝らした紹介ページを自由に作り、プロジェクト
脱GitHub初心者を目指す人のREADMEマークダウン使いこなし術 | ゆっくりと…
README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。 GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 （マークアップ） されて表示されていることはご存知でしょう。 マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown （略して GFM） という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 （もちろん GitHub 初心者です！） の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ （レンダリング） を気にして
ブラウザ動作の理解－レンダリングツリーの構築と描画のタイミング | ゆっくりと…
HTML5 の Web Worker やら GPU でハードウェア・アクセラレートされる IE9 のレンダリングなど、今年もブラウザの進化が激しくなりそうですネ。一方でフロント･エンド改善によるページ表示の高速化 Tips や Hack も百花繚乱、出尽くした感がありますが、やはり原理原則を知らないと 「どれが正しくて筋が良いか」 中々判断が効かないと思いませんか？ そこで最も基本的な 「ページの読み込みから表示まで、ブラウザって何をどうやってるの？」 を理解していきたいなと思っています。 一番の厳密かつ王道は、ブラウザ間の違いを極力少なくするように注意深く書かれている HTML5 の仕様書 を理解だと思いますが、イキナリではハードルが高いので、まずは周辺を漁っています。そんな中から、ちょっと古いですが、2004年5月の記事 「Testing Page Load Speed」 を今回、翻訳
意外と要注意 HTML5データ属性とjQuery Data APIの関係まとめ | ゆっくりと…
前の記事「HTML5でモダンブラウザのCSS3バグを回避するためのハック方法」に関連して、jQuery で HTML5 データ属性にユーザーエジェント文字列を格納する方法を調べていました。その結果、ちょっと整理をしておいた方が良いかなと思う点を共有したいと思います。 ご存知の方も多いと思いますが、jQuery には .data() や jQuery.data() という、DOM 要素に データ を紐付けて記憶しておく仕組みが元々ありました。jQuery 1.4.3 からは、 API レベルでの 親和性 が考慮された形で HTML5 data-* 属性を取り込む仕様が導入されました。 HTML5 時代では、クライアント・サイドで実行されるコード量も増え、データ属性を扱う機会もちょくちょく出てくるのではないでしょうか。そこで今回は、 HTML5 data-* 属性のおさらい jQuery Da
jQuery DeferredとHTML5 Web Workersでオブジェクト指向な並列プログラミングを | ゆっくりと…
「jQueryのDeferredとPromiseで応答性の良いアプリをー実践編」 で述べましたが、Deferred には次の様なうれしさがあります。 非同期な処理をする部分と、その結果をインターフェースする部分を分離する事によって、（特にアプリケーションに近い部分で） コードの可読性が高まる 複数の Deferred オブジェクトをまとめて監視出来る 一方 Web Workers には、window オブジェクトや DOM へのアクセスが出来ないなど、ちょっと引いてしまう制限がありますが、考えようによっては、表示やマウス入力を扱う ユーザー・インターフェースな処理 と、その中身の 純粋にデータ的な部分を扱う処理 とを分離して Web アプリを作るという、オブジェクト指向的な考え方と極めて親和性が良いのではないかと思います。 ということで今回は、「Deferred と Web Workers
jQueryのDeferredとPromiseで応答性の良いアプリをー基本編 | ゆっくりと…
jQuery 1.6 が既にリリース されていますが、1.5 で追加された Deferred を勉強する意味で、Script Junkie から Creating Responsive Applications Using jQuery Deferred and Promises を翻訳してみましたので、共有したいと思います。著者の Julian Aubourg は、jQuery のコアチーム・メンバーとして、Ajax モジュールの書き換えと Deferred 導入を指揮した方だそうです。 記事の途中、各メソッドの説明部分は、jQuery ドキュメントの翻訳に差し替えていますので、リファレンスとして使ってもらうのも良いかと思います。 Deferred や Promise は、概念や用語が少々分かりにくいところがあるかと思いますので、読んでくださった方の、少しでも理解の助けになれば幸いです
jQueryのDeferredとPromiseで応答性の良いアプリをー実践編 | ゆっくりと…
前回 は、「Creating Responsive Applications Using jQuery Deferred and Promises」 の記事と jQuery のリファレンスを翻訳し、Deferred の解説をお届けしました。が、今一歩、Deferred オブジェクトの うれしさ をお伝えできていなかったように思います。今回はその反省をふまえ、単なる翻訳ではなく、元記事の文脈に沿って、Deferred オブジェクトをどのように使うと／何がうれしくて／どうしあわせになるのか、私が学習して得た事をお伝えしたいと思います。 今回は、4本の jsfiddle を記事に埋め込んでいます。jsfiddle 上で自由に編集してテストしてもらえばうれしいのですが、4本すべて実行すると1.4MBものリソースを読み込む事になり、ブラウザに優しくありません。すぐに タブや をクリックせずに、 タブ
オブジェクト指向なJavaScriptプログラミングのススメ(2) | ゆっくりと…
前回 に引き続き、Microsoft のコンサルタント兼トレーナー （であるらしい） で、本も出版している （らしい） Dino さんの記事 Functional vs. Object-Oriented JavaScript Development の後半を要約してみたいと思います。 今回は、jQuery の関数型プログラミング的な側面とオブジェクト指向プログラミング的な側面、そして JavaScript で OO プログラミングをする時の2つの手法 － クロージャーとプロトタイプについてです。 私の理解不足とヘタクソな翻訳を補うため、Dino さんの論点を先にまとめると、次の様になるかと思います。 jQuery は モナド のコンセプトを採用し、表に見えるところでは関数型のメリットを最大限生かしている。一方、拡張性を重視し、内部はオブジェクト指向で作られている。 JavaScript で
JavaScriptがページの読み込み時間を遅くする理由トップ10 | ゆっくりと…
CSS Sprites 化や画像サイズの最適化、Data URI 化、CSS/JavaScript ファイルの圧縮・結合・読み込み順番の整理やキャッシュ制御など、本サイトでは主に HTTP リクエストの数、データ量およびそれらの順番に関して色々なテクニックを試してきましたが、さらに深く掘り下げるには JavaScript の実行がページの読み込み時間に与える影響を知っておく必要があると思います。 「ウェッブサイトの表示速度を測定するフリーツール集」 でも紹介しましたが、dynaTrace AJAX Edition という優れたツールをフリーで公開している dynaTrace software のブログでこの問題を扱った記事がありましたので共有します。JavaScript 高速化 Tips は （例えば 「JavaScriptを高速化する6つのテクニック」 など） 多々あるかと思いますが、ペ
scriptのdefer/asyncを理解し、ページの高速化方法を探る | ゆっくりと…
Yslow ルールでは、スクリプトはページの最後尾、つまり </body> 直前に置け、と言っています。なぜなら、スクリプトの読み込みや実行により、他のページ要素の読み込みやレンダリングがブロックされてしまうからです。 一方、古くは IE4 の時代から Microsoft はこの問題に対処するため、defer 属性という独自の解決策を実装してきました。これは HTML 4.01、XHTML 1.0、1.1 で仕様として採用され、HTML5 にも発展する形で引き継がれています。 IE 以外のブラウザも既に対応されており、IE の独自仕様という色合いが濃かった従来と異なり、これからは広く利用されていくのではないかと思います。 下のビデオは、スクリプトの位置と defer 属性のあり／なしによる、ページの読み込み／表示速度の違いを Pagetest.com でテストしてみたもので、明らかな差異が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最近海外で流行りのTwitter,Facebook,Google+1,Analyticsをまとめる非同期スクリプトにはてなを加えてみた | ゆっくりと…