2014-07-08

ローカルSEOセッション@SMX Advance2014

seo SMX Anvance 2014

Search Engine LandのSMX Advance2014レポートを読んだ際のメモその３。
Search Engine Landを見ている限り、いま一番熱いSEOの話題であるローカルSEOのセッション。スライドは無しでフリートーク形式で行われて、会場は満員だったらしい。さもありなん。

Up Close @ SMX Advanced: Local Super Therapy Session

得意分野ではないのと中途半端にピックアップできないので、主な話題だけリストアップ。気になる人は原文を読みましょう。

Google My Business
Local SEOにはインタラクションが大事
- SNSでの顧客とのコミュニケーションやブランディングが非常に重要
サイテーションの考え方を変えよう
- サイテーションはリンクのような物でGoogleの性能アップでNAPの統一などは重要ではなくなった
レビューはランキング要素と考えないように
- 顧客満足度とブランディングという観点の方が重要だとの事。
コールトラッキングはしないこと
- 電話番号はブランドの一部
- 番号が分散するなどもってのほかというパネリストの全会一致
- 単一の番号であれば問題は無いがトラッキング業者を変えるorやめるのができなくなるリスク

2014-07-04

構造化データに関する特別セッション@SMX Advance2014

seo SMX Anvance 2014

Search Engine LandのSMX Advance2014レポートを読んだ際のメモその２。今年のSMXでもっとも注目を浴びた構造化データのセッションではディズニーとBestBuy、Define Mediaグループが発表。
直接参加されて日本語でレポートしている方も多いのでそちら見る方が早いかも。

Up Close @ SMX: Enhancing Results With Structured Data & Markup

マーシャル・シモンズ@Define Mediaグループ

Which Markup Matters? By Marshall Simmonds from Search Marketing Expo - SMX

まずは構造化データの前にMega-SERPs図鑑を紹介。これはいいまとめ。
Mega-SERP: A Visual Guide to Google

次はSERPsにオーサー情報が載るファクターの紹介だけれども、オーサー情報消されてしまったので、なんとも。とはいえサイトやドメインオーソリティを計るには重要な尺度のはずなので紹介。

サイトレベル

サイトのオーソリティ
高品質なコンテンツ
ドメイン年齢
クエリーバリエーションの多さ

著者レベル

評判
コンテンツの品質
サイトに協力してくれている人たち（ゲストブログもOK!）
クエリーバリーションの多さ

最後に各スキーマの流入への影響度

オーサーシップ
- ゆっくり、散在した表示、CTRへの影響は少ない
TVレビュー
- インデックスは早い、表示までは時間がかかる（季節変動）、流入への影響は中くらい
商品レビュー
- インデックスも表示も早い、流入への影響も良い
レシピ
- インデックスも表示も早いが、流入への影響は小さい
アーティクル
- 追跡が難しいしschema.org準拠ではない、大きなブランドではインパクトも大きい
ビデオ
- インデックスは早く、表示はさらに早い。インパクトも非常に大きい

ジェイ・メイヤー@BestBuy.com

Best Buy's Schema Journey: Then and Now By Jay Myers from Search Marketing Expo - SMX

すべての店舗は公開するべき素晴らしいデータを持っている、という戦略で構造化データに取り組む

かなり早いタイミングでRDFaに取り組み始める。初期に重視したのは以下

キーワード以上の価値を持ったデータを提供
きれいでイカしたURL
文法はRDFa
以下のようなオントロジーに対応
- GoodRelations
- FOAF
- GEO

早いタイミングで対応した事が功を奏して、現在はmicrodataで情報を提供し、SERPsにも順調に表示されている

ジェフ・プレストン@Disney

Happily Ever After: Open Graph Twitter Cards And Schema.org By Jeff Preston from Search Marketing Expo - SMX

話した内容はSchema.orgからOpen Graph、Twitter Cardまで幅広く。まずは、構造化データは万能薬ではないという忠告から。

Twitterカードの活用例として、新作映画に個別のURLを用意してツイート時とリツイート時で別イメージを出すように（？）するなどの工夫を。

最後にナレッジグラフに触れて、どのようなデータが影響するのかを解説。Wikipedia、Freebase、Schema.org。というかここまでの調査はナレッジグラフに情報が出まくるコンテンツを持っているディズニーならではかと。

記事での解説は少なめだったけれど、スライドのサンプルは充実しているので必見です。

QAセッション

マーシャルからジェイへの質問で、そこまでSERPsを拡張しているとGoogleのアップデートがされておらず間違ったデータを提供する事は怖くないか？
- 確かに、Googleがクロールに戻ってこなくなったら心配する
- BestBuyではストックデータがあるかどうかのフラグを管理していて、あとはGoogleを信頼している
データへのアクセスを制御したりだしたくないなどはないのか？
- 全員がそれはないという答え、データをアクセシブルにすることはいい事だと言う認識
（SERPsの充実で）サイトにユーザーがこなくなる事を心配したりしないのか？
- 実際に発生しはじめているとジェイ
- ディズニーのジェフは、彼の居るようなエンターテインメント業界での影響は少ないが、スポーツなどでは影響が大きいとのこと。

2014-07-03

Volocity.jsを使ってアニメーションのパフォーマンスを比較してみた

CSS vs. JS Animation: Which is Faster?
CSS AnimationよりもJavascriptを使った方がパフォーマンスが出るよ、というこの記事を見たので実際に試してみた。

結論

アニメーションさせる時は、Velocity.jsを使いましょう

デモ

DEMO1 - 画面下からスクロールインしてくるモーダルウィンドウ

DEMO2 - 120個の丸が一度に動く、シンプルなアニメーション

[source code @ GitHub]

機能比較

ライブラリ	特徴	メリット
jQuery(`animate()`)	標準で組み込まれているアニメーションライブラリ	ライブラリの読み込み不要
Velocity.js	標準の`animate()`と同じ文法で使える拡張ライブラリ	スピード最適化された実装
Transit	CSS Animationを制御するためのライブラリ	3d-transformも使用可能

結果

Windows7とMac Book AirのChromeでテスト。

ライブラリ	DEMO1	DEMO2
jQuery(`animate()`)	△ 動きに引っかかりが発生	× 動きがずれる
Velocity.js	◎ なめらか	◎ なめらか
Transit	○ なめらかだが一瞬ひっかかる	○ 動きのステップが大きい

結果はValocity.jsが圧倒。特にDEMO2でのスムーズさは他を圧倒。
requestAnimationFrameを使用していて、ちゃんとフレーム毎に再描画されるのでスムーズさが違います。
GPUが使えないスマートフォンで見ると、さらに違いが顕著。

解説

Velocity.jsがスムーズな一番の理由はrequestAnimationFrameを使っている事。これはブラウザが画面の再描画のタイミングで呼ばれるフックになっていてきちんとフレーム毎に再描画されるようになり、そのおかげでスピード以上に自然な動きに見えるようになります。その他にも効率化のために色々やっているので、使わない手はありません。既存のanimate()との互換性もあり、呼び出しをvelocity()と書き換えるだけで問題なく動作するようです。

個人的にびっくりしたのはCSSアニメーションがそこまで早くないという事。ブラウザがネイティブで最適化できるんだから一番早いはず！というのは思い込みだったようです。とはいえ、3d-transformをアニメーションさせるにはCSSアニメーション必須なので、使い分けですね。

あと、Transitはアニメーションの終了をフックできません（多分コメントいただきましたがjQueryアニメーションと同じ文法で書けると明記されていました）。リアクションとしての動きだけなら問題ないけれど、インタラクティブなアニメーションをさせる場合、実装ががやや面倒くさくなりますね。

CSS Animationを使用するタイミング

元記事にも有りますが、シンプルなアニメーションで管理をすべてcssファイルで一元管理できるならあり、とのこと。大量の要素を一度に動作させない限りパフォーマンスも悪くないので、使用する事自体は問題ないでしょう。個人的には飾り的な（なくてもいい）アニメーションはCSS、インタラクションに関連する必須なアニメーションはVelocity.jsを使うのがオススメです。

My recommendation is to use raw CSS transitions when you're exclusively developing for mobile and your animations consist solely of simple state changes. In such circumstances, transitions are a performant and native solution that allow you to retain all animation logic inside your stylesheets and avoid bloating your page with JavaScript libraries. However, if you're designing intricate UI flourishes or are developing an app with a stateful UI, always use an animation library so that your animations remain performant and your workflow remains manageable. One library in particular that does a fantastic job at managing CSS transitions is Transit.

結論ふたたび

コストはたったの8kだけなので、Velocity.jsを使いましょう。
互換性もあるので、不具合あってもすぐに戻せるし。

参考リンク

Velocity.js公式

CSS vs. JS Animation: Which is Faster?

Improving UI Animation Workflow with Velocity.js

2014-04-15

compassミニマムスタートの始め方

既存プロジェクトの一部だけにcompassを取り入れてみる。

すでに公開中のサイトにcompassを導入する場合は、sassフォルダに現状のcssをぶち込んでしまえば良い訳ですが、それは一人で管理している場合。

複数人で作業している場合には、全員にcompassに乗り換えてもらわないと行けないので中々めんどうです。。単発のお仕事でキャンペーンページ作成や新機能の追加などの場合は、自分の担当部分だけでもcompassでやりたい！と思うのですが、準備やコミットが面倒くさい事この上ない、、、

ということで、既存のプロジェクトで自分の作業ファイルだけをcompass採用するためのプラクティスです。

メリット

既存のフォルダを汚さない
作業フローがどんな形でもコンフリクトが起きない
フォルダの整理などの事前準備が（ほとんど）不要

どうやるの？

compassフォルダを追加で作成
htmlのcssファイルへのパスを変更
compass w実行
実作業
最後にcommpass compile -e production
htmlの記述を戻して、納品！

フォルダ構成

作業フォルダ/
　└ css/
　└ img/
　└ compass/
　　└ sass/
　　└ img/
　　└ css/
　　└ config.rb

config.rbはこんな感じ

config.rbサンプル @ Gist

やってること

Gruntが書き出すcssを監視して、親ディレクトリ*1のcssフォルダに自動的に移動します。

既存のcssファイルに同じ名前の物が有ったら確認メッセージを表示するので、間違って上書きも発生しません。

注意

cssで使用している画像の移動は手作業で
commpass compile -e production実行時にcssに変更が無いと変換されないので、--forceオプションを付けるか、grunt cleanを実行してから

最後に

compass/*.cssをcss/に移動させているだけなんですが、そこがコントロールできるのがポイント。納品やコミット作業のタイミングまでcompass一式を分離しておくので、共有フォルダで他の人と同時に作業していても問題無いですし、間違って関係ないcssを消してしまう事もありません。

また、最初に色々パスを書き換えて、、、的な準備が不要になるので気楽にcompass導入ができるのではないかと。自動化もされるので、なれないフォルダ構成にあたふたする必要もありません。

画像ファイルの移動ややhtmlのcssパスの書き換えは手作用になるのが難点ですが、ミニマムスタートということでこの形式。完全移行か不採用かっていう葛藤ではなく、とりあえず、コスト0でスタートすることは大事だと思うのです。

*1:config.rb中のcss_distination_dirで指定できます

2012-05-06

【翻訳】JavaScriptのスタイルガイドとプラクティス by Addy Osmani

AOLの開発者で、jQueryチームのメンバーでもあるAddy Osmani氏の記事「JavaScript Style Guides And Beautifiers」について翻訳の許可をいただいて記事にしました。意訳の箇所も多いですし、翻訳は素人なので、間違いがあればご指摘ください。

JavaScript Style Guides And Beautifiers

今回のテーマはJavaScriptのスタイルガイドです。なぜスタイルガイドが大事なのか、参考になるスタイルガイド、きれいなコードの製作をサポートするツールについて、そして、実際にスタイルガイドに沿ったコードを解説していきたいと思います。

「スタイルガイド」ってなに？

始める前に「スタイルガイド」の定義をおさらいしておきましょう。

スタイルガイド（スタイルマニュアル）は、コードをデザイン・記述するための標準（ルール）のセットです。スタイルガイドはでコードのスタイルとフォーマットの画一性を提供します。内容としてはインデント（タブか半角スペースか）や変数、関数の命名規則、コードのどの部分に半角スペースを記述するのがよいかなどが定められています。

なぜ一貫したコードスタイルが重要なのか？

多くの人が「よいコードはそれ自身が仕様書だ」といいます。私自身はそれに完全には同意しませんが（仕様書は重要です！）、重要なのは読みやすいコードを心がけることで、コードのメンテナンスもやりやすくなるということです。

一貫したスタイルガイドを適用することで、このコンセプトの実現を容易にすると同時に、コードのクオリティを高めることにもつながります。これによって、他の開発者の手を借りる際に、容易にメンテナンスができ、（コードの解読などに）時間をとられることも減ることでしょう。

読みやすいソースコードは私たちにも理解しやすいものです。目を通すのも楽ですし、バグの発見や修正も容易になります。また最適化もずっと楽になります。また巨大なソースコードの中で、個々のコードがどのように組み込まれているかも、クリアにイメージもできるようになります。これは別にスタイルがきちんとされていないコードが悪い（記述の）コードという意味ではありません。スタイルがほとんど適用されていないにもかかわらず、全体を通してみれば非常に効率的な記述をされているコードをいくつも見たことがあります。

繰り返しますが、スタイルを適用したコードは

・実装を理解するためのリードタイムを減らすことができます。
・コードの再利用ができることを確認するのを簡単にします。
・実装のアップデートをする際にもどのようにスタイルするか、構成をどのようにするかを明確化できる（覚えておいてください。このような一貫性のあるコードは、たとえチームで記述したとしても一人が書いたように見えるものです）。

実際のところ開発者は作業にスタイルガイドを使っているの？

スタイルガイドの利用は多くの人に支持されています。しかし実際のところ全体の１％しかきちんと使っていないとしたら、役になっているとはいえないでしょう。もう少し実体を把握するために、ツイッター上で「JavaScriptを書くときにスタイルガイドを使っているか」開発者にたずねてみました。

結果、多くの参考になる意見をいただきました。以下にそのうちのいくつかを挙げてみます。

・Rodney: jQueryスタイルガイドをよく使っているよ。あのばかげた量の半角スペースを除いてだけどね。
・Sindre: 当然Idiomatic.jsだよ。シングルクオートとタブインデントにしてね。
・D.Cherman: 僕らのグループでは使ってはないね。でも僕自身はideomatic.jsに従うようにプッシュしてるよ。
・Marek: 参加しているプロジェクトが別のものを使っていない限り、いつもクロックフォードスタイルを使っているよ。
・Jack: 自分で作ったJSスタイルガイドに従っているよ。出回っているガイドラインを組み合わせたもので、大体似ている。
・Matt: 使ってる（jQueryとIdiomaticをベースにして）。でもプロジェクトによってはフレキシブルに対応するよ。
・Jamie: チームに参加していたときには既存のやつを使った。１人じゃないときは標準を決めるね。一人で作業する限りどんなスタイルでもいいと思うよ。標準を使うと一人が書いたように読めるからね。まぁ僕個人の意見ではあるけど（訳注：訳が間違ってるかも）
・Arthifiji: 仕事でgoogleのコーディング＆スタイルガイドラインを使おうと計画しているところ。すごく包括的だと思うよ。

お勧めのJavaScriptスタイルガイド

スタイルガイドを使ってみようかな、と思っている開発者の人のために、以下のスタイルガイドをお勧めします。

１．Idiomatic.js
このスタイルガイドは特に強くお勧めされるわけでも包括的なわけでもありません。しかし、これまで私の参加したいくつものプロジェクトで採用してきました。このガイドの開発者にはjQueryコアの開発者であるRick Waldron氏、jsPerfの開発者Mathias Bynensをはじめとして、jsコミュニティーで著名な開発者が参加しています。すべての開発者が100％同意するものではありませんが、＃forkしやすいスタイルガイドという点でとくに優れています＃。あなたの必要に応じて採用できます。

２．jQuery Core Style Guide
おそらくモダンなJS開発者にとって一番ポピュラーなスタイルガイドで、jQueryコアチーム、jQueryUI、QUnitなど多くのプロジェクトで採用されています。こちらにもRick Waldron氏が参加しており、Adam Sontag氏やJohn Resig氏といったjQueryの有名人が参加しています。

３．Google JavaScript Style Guide
有名なGoogleのJavaScript開発者Robby Walker氏(Closure Linter)によるスタイルガイド。特にソフトウェアエンジニアリングの経験を持つ人にとって、読みやすくするためのベストプラクティスが多く含まれています。詳しいコメントはこちらから見てみてください。

４．Dojo Style Guide
dojo toolkitの開発者による、もうひとつの非常に包括的なスタイルガイドです。面白いことにこのスタイルガイドはJava programming conventions guideの構成を基にしています。これを読んで気に入ったのであれば、dojoのinline documentation guideを読んでみるのもよいでしょう。私のお気に入りのJSファイル中へのインラインコメントの記述方法です。

５．Aloha Editor JavaScript Style Guide
このガイドは組み込み型HTML5エディタAloha Editor（the relatively non-trivial contentEditable-based）の開発者によるものです。ガイド中でjQueryスタイルガイドを参照するように推奨されていますが、どのようにAMDモジュールをスタイルするかなど、いくつかの小さな役立つ追加点があります。

６．Crock's Code Conventions For JavaScript
ほかとくらべてサンプルの詳細などで劣りますが、もうひとつの優良なガイドです。見たところIdeomatic.jsによって取って代わられたようです。しかしあなたがIdeomatic.jsやjQueryコアスタイルガイドに同意できないのであれば、代わりとしてこれを使うことをお勧めします。

２人の開発者からNPM style guideをプロジェクトで使用していると聞きましたが、リストには入れませんでした。このガイドラインは邪魔な視覚要素をはぶいて最小限にしてありますが、実際の内容はその他のガイドラインと同等のもので、軽量版ガイドラインと呼ぶのがふさわしいでしょう。おすすめした１～６のガイドラインはより包括的なガイドラインとなります。

注：私は上にあげたガイドラインをすべてレビューしたうえで、簡易であったり明確でないためにあまり役に立たない（私の意見ですが）スタイルガイドを不採用にしました（the GitHub JavaScript style guideなど）。

実際にIdiomatic.jsのスタイルを適用させるチュートリアル

簡単なチュートリアルをやって見ましょう。ここにどのガイドラインも適用されていない関数があります。

function foo(bar,baz,fum){  
    var hello = "Hello";  
    var ret;  
    var num = 1;  
    for(var i = 0; i < bar.length; i++) {  
        var out = bar[i];  
        if (out === ""){  
            ret = fum(out) + baz(out);  
        }  
    }  
    if (!(ret == undefined)) {  
        return ret;  
    } else{  
       return fum('g2g');  
    }  
}

技術的にはなんの問題もなく動作しますが、まだ改善することができます。

一貫して読みやすいコードを適用させることで、どのような効果があるかをよりよく理解するために、このサンプルにIdiomatic.jsの内容をひとつずつ適用させていってみましょう。

変更前と変更後を比較して、スタイルを適用させるとどう変わるか一目で分かるようにして、ステップごとに解説をしていきます。

1. 関数の宣言

適用前

function foo(bar,fum,baz){

適用後

function foo( bar, fum, baz ) {

・すべての引数の前に一貫して半角スペースを追加
・引数を囲む括弧の内側にそれぞれ半角スペースがあることを確認
・引数の閉じ括弧")"とブロックの開始括弧"{"の間に半角スペースを追加

2. 変数の宣言

適用前

var hello = "Hello";
var ret;
var num = 1;

ループ部分にも変数があるのでそれもまとめます

for(var i = 0; i < bar.length; i++) {
    var out = bar[i];

適用後

var ret,
    out,
    hello = "Hello",
    num = 1,
    i = 0,
    l = bar.length;

・読みやすくするためにひとつの関数にひとつのvarで変数を宣言するようにします。Idiomatic.jsによるとゴミ（訳注："var"？）を減らすことができます。
・ループ部分で宣言されている変数"i"を同じvarの中に含めます。また、bar.lengthを毎回計算しないように変数"l"に代入してキャッシュします。
・ひとつの関数でひとつのvarというルールに基づき、変数"out"もこの宣言に含めるようにします。

3. ループ

適用前

for(var i = 0; i < bar.length; i++) {

適用後

for ( ; i < l; i++ ) {
    out = bar[i];

・ループ宣言で一貫した半角スペースを使用するようにします。
・具体的には(i)"for"と"("の間、(ii)すべての式と文の間、(iii)ブロックの開始括弧"{"の前
・すでに変数"i"に"0"を代入してあるので、これを省略してセミコロン";"だけを記述する。いくつかの開発者はこれでゴミを減らせると主張しています。

注：ループカウンターの宣言を関数の先頭にもってくるのはスタイル的な選択です。これに不都合を感じるのであれば、これを採用しなくても問題ありません。私個人は変数をトレースできるように、普段はインラインで記述します。

4. 条件の評価

適用前

if (out == ""){
    ret = fum(out) + baz(out);
}

適用後

if ( !out ) {
    ret = fum( out ) + baz( out );
}

・"out"が空かどうかの判定は、真偽判定を使用できます（例："!out"）。これによってキーストロークの数も減り、可読性も増します。
・これまでしてきたように、関数呼び出しの引数の前後に半角スペースを記述して、読みやすくします。

5. さらに条件の評価

適用前

if (!(ret == undefined)) {
    return ret;
} else{
   return fum('g2g');
}

適用後

return ret || fum('g2g');

・ここでは"=="による評価は使用しません（どちらにしろここでは"==="を使用するべきです）。
・"!(ret == undefined)"は4.と同様に真偽判定を利用して"!(ret)"と記述できます（ですがこれはさらに改善できます）。
・適用前のような冗長な記述方法ではなく、論理演算子の特性を活かすことができます。"ret"が"undefined"もしくは"false"の場合はつぎの条件にうつるため、これを利用して5行あったものを、ずっと少ない文字数にでき、可読性もあがります。

最終結果

function foo( bar, baz, fum ) {
    var ret,
        out,
        hello = "Hello",
        num = 1,
        i = 0,
        l = bar.length;
    for ( ; i < l; i++ ) {
        out = bar[ i ];
        if ( !out ) {
            ret = fum( out ) + baz( out );
        }
    }
    return ret || fum('g2g');
}

注：このサンプルにはまだまだ改善できる箇所があります。まずは、引数である"bar"、"baz"、"gum"の内容のチェックなどがあるでしょう。ですが、今回はスタイルの適用のチュートリアルということで無視しています。

結論・ティップス

・あなたのコードにおいて、一貫したフォーマットとスタイルを維持することには、いくつものアドバンテージがあります。それには既存のスタイルを利用してもいいですし、自身のオリジナルのガイドを作ってもいいでしょう。多くの開発者が、個人的なガイドラインを作ることが便利と感じていますし、ほかのものより優れていると感じています（訳注：最後のフレーズ違うかもしれません）。
・半角スペースの効果的な使い方をしてください。可読性があがります。
・変数や関数、モジュールの名前には短く意味のある名前をつけましょう。これによって、インラインコメントで詳細を説明する手間を省けますし、開発者がすぐにコードを読み込むことができます。
・繰り返しのコードや、もっと短く読みやすく書き直せるコードを書くべきではありません。これは別に、すべてにおいて第三者のオペレーターを使うとか、今回のサンプル通りにしなければいけないわけではありません。読みやすいのであれば、長い記述でも問題ありません。
・YAGNI（You are not going to need it）やKISS（Keep it short and simple）などの原則に可能な限り従いましょう。冗長な記述をさけ、より簡潔で読みやすいコードを書く助けになります。