プラグイン作者必読！実例に学ぶ脆弱なWordPressプラグインの作り方、又はwp-adminを守る理由 | ゆっくりと…
セキュリティ・コンサルティング Sucuri の 2014年11月の記事 によると、WordPress プラグインの3大脆弱性は、SQL インジェクション（SQLi）、クロス・サイト・スクリプティング（XSS）、ファイル・インクルージョン（FI）とのことです。 冒頭のグラフ は最新の分析結果で、この事実を裏付けています。プラグイン開発の チュートリアル や 手引き には、脆弱性を作り込まないためのポイントが上手にまとめられているのに、なぜ無くならないのでしょうか？ 「ヒトが作るものだから、バグがあって当然」と言ってしまえばそれまでですが、 Sucuri のブログ を読み漁っていると、こと脆弱性に関する限り、 WordPress に特有の「思い込み」や「見過ごし」といった、ヒトの心理的・認知的な盲点が原因の多くを占めているんじゃないかと思えてきます。 だから単に PHP のセキュリティ Ho
スパムの連続投稿によく効くキャッシュを装備したIP Geo Blockの更新告知 | ゆっくりと…
ここ数日間、本サイトではスパムの連投が流行っています 。 こいつらに貴重なサーバー資源を食われるのは1ミリたりとも許せないワケで、かつては日本以外の IP アドレスを .htaccess に手作業で書き込んでいましたが、あまりにも量が多く、馬鹿げているので止めました。 そんなワケで作ったのが、海外からの投稿を Akismet の起動前に弾く IP Geo Block というプラグインなんですが、スパムは激減するものの、IP アドレスの検索に少々時間がかかるのが気になる点でした。 で、この度、一度検索した IP アドレスをキャッシュに保持する機構を付けたところ、思いの外、効果があったので、バージョン 1.1.0 として告知したいと思います 。 バージョン 1.1.0 での変化点 主に次の3つです。 一度検索した IP アドレスと国コードを一定期間キャッシュする機能を追加。 サービス提供元で生
サイトに適したリソース配置とasync/defer完全マスター – レンダリング優先のグッド・プラクティス | ゆっくりと…
タイトル、少し変えました 😉 。 第1部「サイト高速化の「戦略」と「戦術」- GradeAのその先へ」では、YSlow や PageSpeed がアドバイスする Tips のうち、HTTP リクエストの削減を優先すべしという「戦略」の話をしました。 また css や js を束ねて結合し、HTTP リクエストを削減する時の「戦術」の話もしました。 今回は、「サイトの特性に適したリソースの配置を行う」ために、「束ねたリソースをドキュメント中にどう配置するのが適切か」を見い出したいと思います。またそのポイントとなるブラウザの基本的な挙動についても言及します。 ブラウザごとの挙動が確かめられる、実験サイト contentloaded.com を立ち上げたので、以下、同サイトから幾つかの例を引きながら話を進めたいと思います。 リソース配置を決める戦術 基本的な戦術 第1部 では、css や js
ウェブサイトの速度とパフォーマンスをチェックするツール18選+α | ゆっくりと…
以前このサイトでも ウェッブサイトの表示速度を測定するフリーツール集 でも紹介しましたが、hongkiat.com の記事 18 Website Speed and Performance Checking Tools でさらに新しげなツール類が取り上げられていましたので、紹介をしたいと思います。 記事では、サイトレスポンスの向上を狙って闇雲にコードをいじり始めてもダメで、適切なツールを使って分析し、レスポンスを悪くしている原因を突き止めることが基本であると説いています。 1.Pingdom HTML、画像、Javascript、スタイルシート、iframe などのサイトを構成する要素のローディング時間を計測するツールです。各要素のローディング時間、サイズ、全要素数などのレポートにより、どの要素のローディング時間が遅いかなどの改善点を見出すことが出来ます。またドメイン名（例えば cooca
サイト速度とonload再考 | ゆっくりと…
単にウケ狙いなら「革新的！GAのページ平均読み込み時間を劇的に速くする方法」とか「もう3rdパーティーに邪魔させない、超高速スクリプト読み込み術」（笑）とかの煽りタイトルを付けるところですが、今回はもっと本質的なことを論じてみたいと思います。 「プログレッシブレンダリングでUXを向上させるJS非同期読み込みのベストプラクティス」では、スクリプトの読み込みと実行を window.onload 対象から切り離し、見た目のページ速度を速くする方法について書きました。この方法は既存のスクリプトを書き換える必要があるため、Stoyan Stefanov によって 実験的に実装された Facebook SDK か、自前のスクリプトにしか適用できませんでした。 しかし今回、Hatena や Twitter、Pocket、Disqus など、他の 3rd パーティ製スクリプトにも適用できる方法 − “進化
そのコード、本当にjQueryが必要ですか？ネイティブ関数の代替Tips集 | ゆっくりと…
sitepoint から「本当にjQueryが必要ですか？」とタイトルのついた3本の記事を紹介します。 Do You Really Need jQuery? Native JavaScript Equivalents of jQuery Methods: the DOM and Forms Native JavaScript Equivalents of jQuery Methods: Events, Ajax and Utilities 言うまでもなく著者の Craig Buckler さん の趣旨は、「jQueryを使うのは止めよう」ではありません。ネイティブ関数で代替えできるのは、古い IE のサポートが必要なく、ごく簡単なケースに限られます。その代わりに得るものは「速さ」です。そこで、どの程度「速い」のかを所々 jsperf の結果で補ってみたいと思います。 また JavaScri
プログレッシブレンダリングでUXを向上させるJS非同期読み込みのベストプラクティス | ゆっくりと…
本ブログでは、サイトの高速化に直結する「JavaScript 非同期読み込み」の話題を多数取り上げてきました。タイトルに釣られてこの記事を見てくれている方なら Google Analytics の非同期コードスニペット はご存知でしょうし、規模の大きいサイトやアプリ用に RequireJS などのフレームワークを使っている方もいるでしょう。 GA も RequireJS も、動的に生成したスクリプト要素を DOM に埋め込む「DOM 挿入法」が用いられています。さらに遡れば、Steve Souders が 2009年4月の記事 ノン・ブロッキングなスクリプト読み込み で、6つの手法に分類しています。 果たしてこれらの方法は、サイトの高速化にとってベストなのでしょうか？ 答えは2012年12月の海外記事にありました。そこで本エントリーでは、日本ではほとんど取り上げられていない Frame i
やっと理解できた！JSオブジェクト指向プログラミング再入門 | ゆっくりと…
既に多くの方が JavaScript のオブジェクト指向的側面についての解説を記事にされていますが、読み手側から見ると、例えばプログラミング言語への習熟度やオブジェクト指向自体に対する理解度がマチマチなわけで、私自身、「おお、なるほど！」 っていう、頭の中のスイッチがパチンッ！と入るような境地には達していませんでした。 かつて私も オブジェクト指向なJavaScriptプログラミングのススメ なんていう翻訳記事を書いてはいるのですが、正直なところ prototype.constructor の存在は知りませんでしたし、Function.call や Function.apply をどう使えばよいのかなどをちゃんと理解できてはいませんでした。 そんな中、2011年12月に書かれた Doc Center | Mozilla Developer Network の記事 オブジェクト指向 Java
脱GitHub初心者を目指す人のREADMEマークダウン使いこなし術 | ゆっくりと…
README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。 GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 （マークアップ） されて表示されていることはご存知でしょう。 マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown （略して GFM） という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 （もちろん GitHub 初心者です！） の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ （レンダリング） を気にして
ブラウザ動作の理解－レンダリングの負荷を測る | ゆっくりと…
転勤・単身赴任というライフ・イベントがあり、すっかり更新が止まっていましたが、前回 に続き、「Rendering: repaint, reflow/relayout, restyle」から後半のレンダリング負荷を測るツールの使い方をお届けします。記事中の リフロー や リペイント といった用語は、前回記事「用語の定義」 を参照してください。 元記事は初稿が2009年12月でツールのバージョンも古いため、現時点の最新バージョンで記事を再構成しています。また実行環境によって観測結果が異なるため （非力なマシンの方がレンダリング負荷の割合が高いけど、サンプルとしては分かりやすい）、以下に本記事で試した環境を記しておきます。 dynaTrace AJAX Edition バージョン：Version: 2.1.0.603, built on 2010-12-15 ブラウザ、PC：IE8 / Wind
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最近海外で流行りのTwitter,Facebook,Google+1,Analyticsをまとめる非同期スクリプトにはてなを加えてみた | ゆっくりと…