Category ‘制作日記’

ソーシャルブックマークから「いいね!」

以前、ソーシャルブックマークが流行ってるって事で、このブログにもソーシャルブックマークのボタンを付けたり、マイリリースにもトップと公開ページにもソーシャルブックマークのボタンを付けていたが、時代は移り、最近では「いいね!」ってのを付けてる所が多い。(ソーシャルフィードバックっていうらしい)
なんでも、海外の人気SNS「facebook」で使われてる機能らしく、最近ではmixiやgreeも同じ様な機能を付けている。この「いいね」ボタンを付けるとアクセス数が増加するという事で一気に広まっている。
個人的にはfacebookもGREE(PC版)もやった事ないしmixiも殆どログインしていないのでどんなに便利なのか分からないが、ただ携帯版のモバゲーにmixiのいいね(mixiチェック)が付いていて気にはなっていたので調べてみた。

まず、今までのソーシャルブックマークは基本的にブックマークレットを使って登録するので、ページ制作側は特に何もする必要が無く、ボタンを付けたければボタンをJavaAcriptなどでタイトルとURLを送るボタンを用意するだけでOKで製作者側は楽だった。
ソーシャルブックマークだと「タイトル」と「URL」の2つの情報だけしか無く、ブラウザに付いてる「お気に入り」の様に埋もれてしまう事が多かったが、facebookの「いいね!」の場合はOpen Graph Protocolという書式に従ったタグをHTMLに記載してこの情報を元にブックマーク(?)をするので、ページ概要や画像等の情報を含めた内容が保存出来て埋もれにくそうようだ。
OGPは標準の書式にしておけば良さそうで携帯版が別URLの場合はmixiやGREE様に追記する感じでOK。(画像を載せる場合はmixiの仕様に合わせてリサイズすると他でも使えるかと思います。)

他にもTwitterやEvernoteへのボタンも欲しいところだ。

ソーシャルブックマーク系のもGoogleブックマークとYahoo!ブックマークとLivedoorクリップは人気なので残す事にした。

個人的にソーシャルネットワークを使いこなせてないので、仕様を読んで理解するのにかなり時間がかかってしまったがようやく設置できた。

mixiチェックにamazonからの画像が掲載されなくて悩んだけど、ミクシィ デベロッパーセンターにて許可するドメインにamazonの画像サーバーを登録していない事が原因だったようで、登録すると表示された。

facebookは「いいね」か「シェア」かを最後まで悩んだけど「いいね」にしました。

PHPの高速化

MyReleaseの新規セッションの割合が低下していた。
Yahoo!が検索エンジンをGoogleの検索エンジンに切り替えた為だ。

そこで、PHPの高速化をとスクリプトを調整していたが限界が来たのでサーバーの設定を変更することにしました。
とりあえず「eAccelerator」を入れてみた。
MyReleaseはCPIのVPSで元々PHP4でPleskという環境に、無理やりPHP5を導入してるので不安だったが何の問題もなくインストールできた。体感できるほど速くはならなかったがコンパネから利用状況が分かり頑張ってる様子がわかる。

次に「eAccelerator」と同居できるという事で「ZendOptimizer」もインストールした。
これは入会する手間はあるが簡単にインストールできた。
ただ、バージョンが3.3.9と新しく色んなサイトで紹介されてるインストーラーを使ったインストールができないが、必要なファイルをコピーしてphp.iniにコピーした場所を記述するだけでOKという簡単な作業でインストール完了。

更にmySQLのインデックスも微調整した。query_cacheを調整したりすると、ようやく体感できるレベルに改善された。

このおかげかは分からないけどランキングは約一年ぶりに5位に戻った。

PHPで切り抜き画像を作ってみる

まとめサイトのサイドバナーによくamazonのフィギュアを載ってるのをよく見る。amazon画像編集ツールamacco -あまっこ-も元々CDのジャケット用に作ったのだけど実際は殆どフィギュアばかりだ。
大抵フィギュアの背景は白で味気ない「PhotoShopとかで魔法の杖(マジックワンド)を使ったら簡単に切り抜き画像作れそうだな」と思ってPHPのGDで出来ないか調べてみた。
GDにはそんな機能は無かったがアルゴリズムの紹介にシードフィルというアルゴリズムを使って塗りつぶす方法がC言語で書かれていたのでPHPでもやってみた。
PHP 切り抜き
画像上の切り抜きたい場所を適当にポチポチ数カ所クリックして画像生成を押すと切り抜き画像が出来る。
白(左上の端の色)と画像の各ポイントの色の差を連想配列に入れておいて、画像上でクリックされた各ポイントからシードフィルアルゴリズムで塗りつぶしを繰り返し、(実際塗りつぶす訳じゃなく塗りつぶしのデータはマスク用の連想配列に入れる)処理が終わったら、マスクデータにぼかしをかけたりして、マスクを適用させて画像を生成するという感じ。
今回はテストなので普通に多次元配列を使ったが色情報なのでサイズ固定のSplFixedArrayを使った方が速そうな気もするが・・・。
あまりキレイでは無いので役に立たないかもしれないけどPHPで簡単切り抜き画像が作れることはできるという事が分かった。

Password Matrix

パスワードを記録し、暗号化するための、超アナログな方法 : ライフハッカー[日本版]の記事を見て圧縮して財布の中に入れられるようなモノを作ってみました。(前にも似たような記事を見たような気がするが)
Password Matrix
本家と同じだと財布に入るサイズにすると字が小さくなって読めなくなるので26あるアルファベットを2分割し、13×13のマスにしています。本家だと半角記号も含まれてますが日本では半角記号を許可していないサイトが多くあるのでデフォルトでは外しています。(あと間違いやすい0ゼロとOオーとか1いちとl小文字のLとか間違いやすそうなの文字も外しています。)
年賀状の時期ですので間違えた年賀状に印刷してカードサイズに切るといいかもしれません。

PHPで複数のURLを404チェックする関数の速度比較

amazonのAPIなんかを利用して画像のパスを取得し保存していると稀に画像が削除されてしまってる事がある。
毎回、amazonのAPIを叩く様にしてもいいかもしれないけど頻繁にアクセスするとamazonに怒られるかもしれない。
そこで、ファイルが存在するかチェックする事にしたのだけどPHPには色々関数があるのでそれぞれチェックしてみた。
(さらに…)

マルチバイト文字のtrim

yahoo!の検索エンジンがGooleの検索エンジンになるというニュースはありましたが
とうとう切り替わったのを確認してしまいました。(徐々に切り替わっていくらしい)

Googleはページの表示スピードも見てるらしいので少しでもPHPのスピードを上げたくて最近ではベンチを使って速度を比較している。
他者の計ったベンチがGoogleで調べればすぐに出てくるのになぜ自分で調べるかというと、例えば文字の置換はstr_replaceを使い。
$str = str_replase(“AAA”, “BBB”, $str);
とするが普通で速度も早いが、検索文字(例の場合”AAA”)の出現がレアな場合
if (strpos($str,”AAA”) !== false) $str = str_replase(“AAA”, “BBB”, $str);
と置換する前に先に検索した方が早かったりするので、実際のデータが無いと分からないのでベンチを計る必要が出てきたりする。

そんな中、比較的遅いというmb_ereg_replaceを使ってるマルチバイトのtrimを調査してみることにした。
$str = mb_ereg_replace(“^[  ]+”, “”, $str);
$str = mb_ereg_replace(“[  ]+$”, “”, $str);
昔、Shift-JISで単純にtrimの第2引数に全角スペースを入れてトリムすると文字化けしたのでmb_ereg_replaceを使ってるが、安全だけど遅い。
そこで昔文字化けした理由を調べに文字コードをwikipediaで見てみた。
Shift_JIS
第1バイトが81-9FとE0-FC、
第2バイトが40-7Eと80-FC
EUC-JP
第1バイトがA1-A8とADとB0-F4とF9-FC、(亜種は8FとF5-FEも)
第2バイトがA1-FE(亜種は第3バイトにもA1-FE)
UTF-8
第1バイトがC2-FD、
第2バイト以降が80-BF
trimのデフォルトの第2引数は
” ” (0x20), 半角スペース
“\t” (0x09), タブ
“\n” (0x0A), 改行
“\r” (0x0D), 復帰
“\0” (0x00), NUL バイト
“\x0B” (0x0B), 垂直タブ
とどの文字コードにも危険なコードが含まれていないので普通に使える。
ただtrimはマルチバイトには対応していないのでシングルバイトに変換され削除されるので全角スペースを除去しようとすると下記のように問題が発生する。
Shift_JISの全角スペースは0x8140でtrimの第2引数に全角スペースを入れると81と40が削られアウト
(http://charset.7jp.net/sjis.htmlの81と40が絡む行や列が文字化けする。)
EUC-JPの全角スペースは0xA1A1でtrimの第2引数に全角スペースを入れるとA1が削られアウト
(http://charset.7jp.net/euc.htmlのA1が絡む行や列が文字化けする。)
UTF-8の全角スペースは0xE38080でtrimの第2引数に全角スペースを入れるとE3と80が削られアウト

正しく全角スペースをトリムするならmb_ereg_replaceしか無く、すべての全角スペースが半角スペースになってもよければ
$str = trim(str_replase(“ ”, ” “, $str));
と先に全角スペースを半角スペースに変換するなど、シチュエーションによって使い分けるしか無いようだ。

iPhone対応サイト制作のまとめ

まず、iPod touch(iPhoneも同じ)のSafariの問題点
・Flashが使えない。
・オンマウスで情報を表示する事が出来ない。
・専用に作られていないとクリックミスが多い。
・大きいページはよく落ちる(ホームに戻ってしまう)
・大きいページは動作が読み込みに時間がかかり、動作がもっさりする。
・フォームからファイルがアップできない。
・jQueryを使ったドラッグ&ドロップをしようとするとスクロールしてしまう。(専用にスクリプトを書けば回避できる)

cssやjavascriptが効いてるのでそこそこ見れるが普通の PCサイトをパソコンの様に見れるという訳では無く、Flashが使える分PSPなどのゲーム機の方がマシに思える。
結局、画面が小さいので専用ページは携帯サイト用のものを元に一回り大きく作る感じが効率的で、色々と複雑な事をしたいならアプリを作る方がいい。

■フォント
iPod touch、iPhone 3Gは日本語フォントが「ヒラギノ角ゴシック ProN」 のみだったがiPadには「ヒラギノ明朝 ProN 」が追加されたらしい
。等幅フォントを使いたいときは「font-family:monospace;」
font-family : ‘HiraMinProN-W3’ ;
font-family : ‘HiraMinProN-W6’ ;

■横幅
iPod touch・iPhone 3G
ポートレート(縦向き):320px
ランドスケープ(横向き):480px
iPhone4
ポートレート(縦向き):640px
ランドスケープ(横向き):960px
iPad
ポートレート(縦向き):768px
ランドスケープ(横向き):1024px

■電話番号を勝手にリンクにしてしまう
「-」(ハイフン)を含む数値をSarfariが勝手に電話番号としてリンクしてしまうので下記を記述して、その機能を抑制する。
<meta name="format-detection" content="telephone=no">

■回転させると文字が大きくなる
画面方向の切り替え時にSarfariが勝手に文字サイズを調整してしまうので、CSSを使ってその機能を抑制する。
body {-webkit-text-size-adjust: none;}

■スクロール
「overflow:scroll」が効かない。
http://cubiq.org/scrolling-div-for-mobile-webkit-turns-3
これは、拡大して二本指でなぞるとなんとかスクロール出来ない事はない。

■アイコン
iPod touch、iPhone 3G、iPhone4、iPadのWebClipアイコンは
以前(iOS1時代)は60x60pxで作成し、iPhoneで自動に57x57pxに変換されるのがキレイとされてましたがiOS2以降は57x57pxで作成する方がキレイに表示できる様になりました。
それがiPhone4、iPadの出現で今までのサイズだとボケボケになってしまうようになりました。
各端末のアイコンサイズは
iPod touch・iPhone 3G:57x57px
iPhone4:114x114px
iPad:72x72px
とまちまちです。
ただ大きい場合は縮小され、角を丸めたり、ライティングしたりしてくれるので大きい方が良くなりました。
実際、どんなサイズがいいのかというと、当のAppleは129x129pxなのでこれに合わせて作成した方が無難かと思われます。

使える特殊文字と機種依存文字


今まで機種依存文字として敬遠されていた♥(ハート)なんかの文字もUTF-8でコーディングすると普通に使えたりするので、使いそうな記号を調べ直してみた。
使える特殊文字と機種依存文字
ついでに文字実体参照や文字コードも記載したので特殊文字の決定版と言ってしまう。(まあ誤記があるかもしれないけど・・・)

パソコン(MacとWindows)やiPod touchではあまり気にせず使え、文字色を変えるだけでも結構いい感じになる気がする。
ただ、ケータイを絡めると複雑になってくる。搭載してるフォントに該当する記号が無いと話にならないし、あったとしても記述方法がまちまちな為、ケータイでは素直に絵文字を使った方がよさそう。

あと今回試した機種のせいかもしれないがauのケータイでは天気の記号や星座のマークなどは絵文字に変換された。素敵な配慮だ。他のケータイも変換されるようになると絵文字の変換に気を配らなくてもいい時代が来るかもしれない。

Google Adsenseがスクロールされない

2chビューアーは作成してから色々と弄ったので久々にブラウザチェックをするとIE6(internet explorer6)で表示が微妙に崩れるのは知っていたが(面倒なので直すつもりは無い)、もっと酷いことになっていた。
サーバー代を稼ぐ為に付けたGoogle Adsenseがスクロールされていない。更に調べるとIE7以前のブラウザはアウトらしい。アナライザーを見ると約20%の人に影響がある。
色々と探してみるとobject経由だとスクロールしてくれるらしい。詳しい方法は広告スクリプトを object タグで読み込む方法 : 亜細亜ノ蛾 – Weblogに書いてある。
要約すると空のhtmlを作りそこにGoogle Adsenseのバナーだけを置いて、それをobjectとして読み込ませるというものだ。
記事が古いのでもしかしたら規約違反になってしまうかもしれないし、広告内容がページと関係ないモノが現れてるが、付けないよりまし程度でIE7以前はobject経由で表示する様にした。

docomoの2010年夏モデルとiPad


機能と価格で選ぶドコモ携帯にdocomoの2010年夏モデルを掲載した。
昨日、iPadが発売され結構なお祭り騒ぎだったようだがdocomoの新機種は至って普通な感じ、メーカーも様子見で抑えたラインナップなのかただ飽和状態なのか分からないが、もうちょっと攻めた製品が見たかった。
サービス面は殆ど追加が無かったが個人的には「i Bodymo」が欲しいけどその為に買い替えるほどの機能では無い。

iPadも毎日パソコンの前にいる仕事をしてるオレには今のところ魅力的に感じない、iPhoneの様にパソコン版と解像度が極端に違えば専用のページを作るのに検証用として欲しい所だけど、iPadの場合、Flashを無くすとかボタンを押しやすくするぐらいの配慮は必要かと思うが専用のページを作る程ではない。
ただ、今回はiPhoneの成功の後なので、iPhoneの時の様に「当たるかどうか怪しい端末」ではなく「当たるのがある程度確約された端末」なので開発者も多く参入するだろうし、WEBもiPad向けに最適化されたページを作るサイトが結構出てきそう。