いいね! ボタンHTML5

Fbのいいね! ボタンは、押されたあとに、指定された固定URLのOGPを参照するんだけど、そのために通常は1ページに1つだけ「いいね!」ボタンが存在できることになる。

だけど、この仕様では例えば1ページの中に複数の異なる「いいね!」ボタンを配置することができないので、そこを解決する。

今日現在、Facebookの公式デベロッパーページ( http://developers.facebook.com/docs/reference/plugins/like/ )から いいねボタンを作る方法は、HTML5、iframe、xfbmmlが選べるけど、恐らくは複数設置の概念から言って、HTML5がよいだろう。だからHTML5でのやり方を解説。デベロッパーページから入力して、出力すると以下のような感じ。en_USのママだと[LIKE!]ってなるから、[ja_JP]に直したらいいね。でも多言語環境からの閲覧時はどうなるかは分からんです。

<div id=”fb-root”></div>
<script>(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) {return;}
js = d.createElement(s); js.id = id;
js.src = “//connect.facebook.net/en_US/all.js#xfbml=1″;
fjs.parentNode.insertBefore(js, fjs);
}(document, ‘script’, ‘facebook-jssdk’));</script>

 

<div data-href=”http://www.qualitte.com/facebook/001.html” data-send=”false” data-width=”450″ data-show-faces=”false”></div>

このフォーマットが、html5での「いいね!」ボタンの出力になるんだけど、いいねぼたんを出力しているのは、青い部分のコードになるので、このコードを複数用意することで実現する。

今回は、001.html〜005.htmlまでの合計5ページを用意。それぞれに、OGPを設定してあり、そのページをいいねさせるということ。

表面上はうまく実装されているんだけど、OGP側の設定にエラーがあります。というのも、OGPの正確な記述方法には、<meta property=”fb:admins” content=”XXXXXXXXXXXX” />の項目が必要で、これは、facebookのデベロッパー登録してある人の固有番号で、誰が作ったのかをわかるようにしているみたい。(これが何故必要なのかはなんとなくわかる。追記で書きます)しかし、このコードを書くと、Facebookが自動的に恐らくはOGPで設定した「title」に相当する「Facebookページ」を自動的に「登録者」が作ったことにして生成してしまう。

この挙動は驚異で、まだ試してない状況だけど、商品が10000点あれば、おそらくは10000点のFacebookページが生成されてしまうんだと思う。これはなんかおかしい。それを避けるために、あえてfb:admins項目を書かないという選択肢をとっている。

これをどれだけのサイトがきちんと掲載しているのかは分からないけど、ページがどのようにOGPを設定しているのかをデバッグする機能がFacebookにはある。(リンターという名前で呼ばれているみたいだけど、リンターって何?汗)

Input URL or Access Token http://developers.facebook.com/tools/debug

これで、例えば「無印良品のオンラインストア」で特定の商品ページ(例:http://www.muji.net/store/cmdty/detail/4934761081151)をこのデバッガーに入力してみると、いくつか足りないことがわかる。足りなくても別に構わないということだろう。少なくともFb推奨のOGPすべてを記述する必要はないようだ。

そして最後に、このOGPは【メタ】記述であるという点が個人的にはセキュリティホールに近いのではないかと考えている。

この機能を用いると、自分の作った参考例 http://qualitte.com/facebook/000.html のようなサイトであると、いいねを押したあとのfacebookに表示される内容を事前に確認することができない。この機能を逆手にとって、ユーザーの意図しないページの「いいね!」を押させることができる。故意か事故かは別として、

<div data-href=”http://www.qualitte.com/facebook/001.html” data-send=”false” data-width=”450″ data-show-faces=”false”></div>

たったこの部分を編集することで、意図しないページを「いいね!」させることが可能になる。まあ、改訂の速いFbのことだから、そのうち同一ドメインだけとか、それこそ投稿内容の事前可視化&確認が必須になってしまうのかもしれない。

 

Apache 速度向上

VPSのサーバーを借りているんだけど、最近どうにも画像の出力が遅いなあと思っていて、YSlowとか、fire bugで調べていたんだけど
コレと言った対策がみつからなかった。今日一緒に仕事してくれているパートナーさんと話してて、なんか画像の取得にもたつくよねって話で、
電車の帰りにiPhoneで色々ググって帰ったら、よさそうな記事をいくつか発見したので、さっそく試してみた。

httpd.conf の

#EnableSendfile off

EnableSendfile off

#EnableMMAP Off

EnableMMAP Off

こいつで、Apache再起動。

信じられないほどの速度改善。これは必須チューニングじゃねえのかっていう。
参考:http://blog.tufu.org/archives/543

ただ、別の記事ではこの設定の明示的なOFFによる問題もあるようで、なかなかうまいこと行かないです。

評価とは

INAXギャラリーで偶然知った、建築家「前田紀貞」さんの展覧会『建築道』を、大岡山のお茶会の後に観てきた。

私の目当ては、その学生さんたちが、作品を発表するという発表会。そのプレゼンの仕方や、評価の仕方について興味があったからだ。私はwebデザインを10年、実務&経営としてやってきたから、建築とwebデザインという異なる世界とはいえ、「意匠」といったものを伝えるやり方は同じベクトルであると思ったので、ぜひ後学のためにと、参加してみた。

結果で言うと、非常に疑問の残る発表会であった。というのが正直な感想だった。

今回、学生に課せられた課題には自ら設定した「条件」がつくという。その条件があることで、建築が「理想」通りにはならないという制約を儲けることで、前田さんとしてはより「現実的、実戦的」な体験をさせたかったのだと思う。大概にしてクライアントはプロの意見とは異なる制約を付けるのは我々webデザイン界でも日常であるから、そういうポイントは良いと思う。が、この意味が学生に分かっていたのかはどうもプレゼンを聞く限り疑問が残る。

というのも、建築なので、一切の物理現象を無視した構造などあり得ないわけで、そのなかでかつ、一定の居住者条件と、立地条件も与えられているとすれば、これは既に条件としては十分なものであり、この前提条件下において建築家「自らが」設定した制約をつけることが本来の「クライアント」からの我が儘、あるいは政治的制約、宗教上の制約等である必要だと思うのだが。

建築についての意見は私は間違っているかもしれないが、「意匠」という部分については同じ道だと思っている。

また、発表されたプレゼン内容について、「ここが良くない」という意見ばかりが目立ち、答えへつながるアドバイスがなされていないことに非常に疑問を持った。うちの会社も徹底してプライドをぶち壊す期間というものがある。そもそも学生レベルの品質などほとんどビジネスにならないので、下手なこだわりは捨てさせるためにある。そういった時期だったのかもしれないが、問題を指摘した側には、必ずその解決方法を示す必要があると私は常々考えているし、実践している。

文句を言うのは誰でもできる。改善策と合わせて評価しなければ意味が無い。問われているのは難問ではないことは明らかである。難問であれば文句など出ない。答えが自分と違っているから文句が出る訳で、なぜその答えが異なり、正解はどのようなプロセスで導くのかを示す必要がある。

だがしかし、前田さんは本物であることは間違いの無い事実であり、多くの実績がそれを証明している。

私の知識が少なく、建築という全く関係のないジャンルのプレゼンに対してヤジを入れたことのほうがよっぽどマヌケなのかもしれない。

日中のお茶会の掛け軸が心に響く。

明歴々堂々

少しも、うそ、かくしがなく目の前に堂々と現われている真理を無心に眺めることの大切さに気づくことが尊い。

ペンタブレットのペン買い換え!!

実はマウス腱鞘炎なんだよね。俺。

マウスが握れないわけ。もう人差し指が動かせないくらい痛くて、今から7年?8年?前からダメなんだよね。

そんなとき偶然であった、wacomの液晶ペンタブレットに切り替えて、なんとかweb designer人生継続できているんだけど、最近どうにもマウスカーソルが画面から飛んじゃうので、操作にコツがひつようだったりして。

液晶タブレットも、当時1機種しかなかった、15インチから、今使っている21インチに変えたのが2005年くらいだからもう随分同じの使っているけど、液晶の発色も最近のiMacには完全に負けているけど大した寿命だと思うよ。

そもそも40万円以上するからね。これ。今は定価で25万円くらいに下がったと思うけど。

で、ペンもヘタッてくるわけで、どうやら今日知ったんだけどこのペンって「リチウム電池」入っているのね。

アマゾンから届いたパッケージに書いてあって初めて知った。だとすると、ペンの電池が少なくなる→使いにくいってのも納得だけど、そんな消耗品って事実どこにも書いてないんですけど・・・。みんなどうしているんだろうか。

そもそも40万円のマウス&液晶を使う人がいるのかっていう・・・。

歴代のペンは保存してあるので、引き出しから見つけて公開!!

いやあ、なんというか、ほら、マウスとキーボード&ディスプレイって俺たちのUIで一番大事なところだから、使わなくなっても思い出があるんだよね。ああ、あのデザイン死ぬほど辛かったな・・・とか。

でもって、今日届いたこの新ペンが、良い感じで使いやすい!!マウスが飛ばない!!いやあ初めからここを疑うべきだったなあ。

ゆとり世代

ゆとり世代という言葉がある。90年代に小-中学生だった世代である。

私のちょうど10コ下になるのだろうか。

最近その「ゆとり世代」に対するバッシングが多い。

しかも何故かかなりの上から目線だ。「こんなこともできないのか」「ゆとり世代は困る」などと、否定的な意見が殆どである。

言われなければ出来ないヒトを、自発的に収益があがる方向に持って行くのは、経営側の努力であるとこの10年間感じてきた。ここにきて、ゆとり世代という言葉を持ってきて、出来が悪い、使えないと愚痴る人事なんて、甚だ勘違いということである。60年代に育ったら団塊世代。70年代ならバブル世代。80年なら氷河期次代。90年ならゆとり世代。だからなにが問題なのだろうか。

今おかれている状況で、常に会社を、社会を良くしていく努力。それだけである。

ゆとり世代という酷いステレオタイプのおかげで、少しの休憩も許されないような気がして不憫でならぬ。氷河期次代の俺たちも、相当馬鹿だし、ならバブルのおっさん、退職中の団塊じいさんどもは、なにか違ったのだろうか。

若者達よ。何も気にせず、あたらしい道を造ればいい。そして邪魔な私たちのポンコツを壊すといい。

SSL

今回、案件でラピッドサイトというホスティングサーバーと、

グローバルサイン社 クイック認証SSL というSSLをつかったのだけど

ここで盲点だったのが、携帯端末の対応性ということ。

そもそも自分が携帯でウェブを使用しないため、モバイル経験が少なく、

SSLに携帯端末との相性があるとは想像もできなかった。プロとして恥ずかしい限りだ。

今回、運良くグローバルサイン社のものが、主要(?)携帯機種に対応していることが契約後にわかったので

一安心したのだが、契約時のコモンネームには肝を冷やした。要は、www付きかそうでないかの違いなのだが、

これが後ほど訪れる超弩級の恐怖の始まりだったことは誰も知らない。

携帯端末は、PCよりもSSLの通信にシビアで、認証局が確認できなければ絶対に表示してくれないものが

多いようだ。PCの場合は多少疑わしくとも、アラート等が出現してユーザーへ注意喚起をして、まあ良くはないのだろうが

通信を開始してくれるようだが、携帯は認証局が駄目ならそこで終了だ。

今回、既存のドメインを新しいサーバーに移転するため、IPアドレスでの作業を公開3日前まで行っていたことにも

問題があった。つまり、SSLを携帯で実際に試すことができるのが運用3日前が初めてなのである。

そして恐怖は訪れた。

携帯からSSLにつながらないのである。ECCUBEのコミュニティで漁る漁る。

ない。

やばい、これではまずすぎる。

結局、いろいろ試行錯誤するも、そもそもグローバルサイン社の仕様を再度確認してみる。

まず自分の使っているau携帯の仕様と合わなければそれまでだが、会社のau携帯は最新のものだ。

どちらも表示できないのはおかしい。

どうやらサイトには3つの注意書きが。

  • 携帯端末のブラウザにGlobalSignRoot証明書が搭載されていることが対応条件となります。
  • ※ワイルドカードオプションをご利用の場合、携帯電話には非対応となります。
  • ※2wayのwwwなしのアドレスは、携帯電話からアクセスすることができません。

冷や汗がどっと出てくる。

なんだこれは。先に詳しく調べるべきだった。焦りまくる俺。

どうやら2wayのwwwというやつが怪しい。2wayとは、www.でもなくてもSSLが使えるというもの。

これで申し込んだので、サイトはwwwを使わない設定を行っていた。

設定ファイルを何度も書き直し、携帯でテストを繰り返す。携帯を持つ手が震える。全身に緊張が走る。

駄目だ。つながらない。どうしよう。

先輩も焦ってエミュレーターで通信内容を確認する。駄目だ。完全にはじかれている。

一息入れて、再度設定ファイルを良く見直す。mobileの設定欄と2時間ほど格闘した後、

pc欄も再度確認してみると、あったぞあったぞ!wwwが抜けている。

wwwを付加して、再度携帯でアクセス。

つながった。

サーバー移転、DNS変更、メールアドレス移転、SSL設定、ECCUBEカスタマイズ、デザイン、制作

他社で非常にうまくサービスを展開しているところがあるけれど、本当に凄いと思った。

まだまだ、俺の戦いはつづく

連日徹夜

久々に仕事が忙しく、2月は2週連続で週末も出社。

momoと遊べないのでやっぱり寂しくなる。

3月リリースの案件で、ECCUBEちゃんのご機嫌斜めでホントに苦労しました。

でもナイスサイトができたと思います。

そんなこんなで、リリース前週は他の仕事と重なって金曜徹夜&週末出社、PHPいじり&ECCUBEモバイルカスタマイズ。

リリース前日はECCUBEの速度改善で深夜2時まで格闘→早朝システムチェックてな感じで、もうテンヤワンヤと。

んー、これまで如何にトラブルなく案件を進められるか、如何に事前に回避できるかを重要視してたんだけど、

今回の案件で相当勉強になりました。最後はGoogle AnaliticsもPC&Mobile両方セットしたりと(これも中々ハード)

まあホントに疲れました。

今回行ったカスタマイズの主要については後ほどまとめたいと思います。