栃木,Web,WordPress,スマートフォン,野球,ラグビーなど
Web
スマホサイトのデバッグといえば！Android Chromeリモートデバッグをやってみた
2013年9月9日
ちょい昔に、Android 標準ブラウザでJavascriptのデバッグ方法をメモりましたが、
PCとAndroidをUSBで繋いで、Android Chromeでスマホサイト全体をデバッグするやり方について。
Chromeはver.28からレンダリングエンジンがWebKitからBlinkに変わったこともあり、
昨今「Chromeだけちゃんと動かねー！」とか「Chromeだけ動作がおかしい！」とか、
Chromeでスマホサイトのデバッグが必要な場面が増えてる気がします。
※PC ChromeブラウザでUserAgentを偽造してデバッグすることもできるけど、実機じゃないと正確性に欠けるんで。
まずPC側
(1)Android SDKのadb(Android Debug Bridge)ツールをインストールしておく
続いて、Android側 ※SO-02Eの場合
(2)設定→開発者向けオプション→USBデバッグ をチェックし、ダイアログが出たらOK
(3)Android Chromeでデバッグしたいサイトを開く
そして、コマンドプロンプト
(4)adb.exeがあるディレクトリに移動し、”adb devices”でデバイスが認識されているかを確認
※認識に失敗したら”adb kill-server command to resolve”を実行し停止させる
(5)”adb forward tcp:9222 localabstract:chrome_devtools_remote”を実行
ここでまたPC
(6)Chromeのアドレスバーに、”localhost:9222″を入力
※そうすると、Android Chromeで開いているサイトが表示される
(7)デバッグしたいサイトを選択
あとは、PCのChrome Developer Toolsの使い方といっしょ。
“Elements”タブで、HTML,CSSを確認したり編集したり、
“Resources”タブで、WebStorageやSessionStorage()、Cookieの中身を確認したり編集したり、
“Network”タブで、ネットワークへのアクセスを確認したり、
“Sources”タブで、Javascriptの表示、ブレークポイントを貼ってデバッグしたり、
“Timeline”タブで、パフォーマンスを計測したり、
“Profiles”タブで、CPUやメモリ、CSSセレクターのプロファイルを確認したり、
“Audits”タブで、ネットワーク、ウェブページのパフォーマンスを確認したり、
“Console”タブで、JavascriptやHTMLのエラーを表示したり、
“PageSpeed”タブで、ウェブページを高速化するためのアドバイスをもらったり、
といった、いろんな使い方があるので良いんじゃないでしょうか！！
Google Analyticsのウェブテストを試してみた。A/Bテスト機能として良さげだったのでまとめ。
2013年8月26日
Webサイトを運用していると、何らかの目的を満たすために、
やれページのデザインを修正したり、やれ入力フォームの見せ方を変えたり、やれコンバージョンへの導線を改善してみたり、日常的にやっておられると思います。
その際、”どう変更するか”が一番重要で、且つ最も難しいのだけど、
｢担当者が良いと思った｣とか｢エライ人の好み｣とか、主観的な判断ではなくて、
何パターンかのうちユーザーの実績に基づいた根拠が欲しい！！ってときに使えるのが、
このGoogle Analyticsのウェブテスト機能。
前提条件、手順は以下のとおり。
前提条件：
(1)Google Analyticsのアカウントを持っていること
(2)テストページを2パターン用意していること
手順：
以下Google Analyticsでの操作
(1)メニューから「コンテンツ」→「ウェブテスト」を選択し、「テストを作成」ボタン押下
(2)オリジナルページのURLを入力し「テストを開始」ボタン押下
※成果が高いと想定されるページをオリジナルページとして登録した方が良い
(3)「このテストの名前」「このテストの目的」「テスト対象のトラフィックの割合」「重要な変更内容に関するメール通知」を設定し「次のステップ」ボタン押下
※「このテストの目的」が重要なポイント。コンバージョン,PV,直帰率などが設定できる
(4)「パターン1」のURLを入力し「次のステップ」ボタン押下
※パターンは最大9パターンまで設定可能
(5)テストコードを発行し、オリジナルページ、テストページのhtmlのhead開始直後に埋め込む
※オリジナルページ、テストページのURLに、パラメータが付く
例：http://ohsexybaby.com?utm_expid=12345678-0.abcdefghijk1234lmnop.0
※このコードは、Google Analyticsのタグとは別です。
(6)テストコードおよび、Google Analyticsのタグが正確に埋め込まれているか、チェックしてくれる。
上記以外に検討、準備すること
(7)SEOを考慮し、全てのテストページがクローラーにインデックスされないように、
rel=“canonical”で正規化する必要がある
以上で準備完了。
テストの進捗はこんな感じで出てきます。
最後、Google AnalyticsのウェブテストをA/Bテストで使ってみたまとめ
・テストページを用意し、目標を確定させれば、準備に工数をかけずにテストが可能
・テストページが、動的なURLパラメータを含むページであってもテストは可能
→たとえば、http://ohsexybaby.com/testA.html?id=123456789 と http://ohsexybaby.com/testB.html?id=987654321 (※idは動的)をテストしたい場合、登録は、
http://ohsexybaby.com/testA.html と http://ohsexybaby.com/testB.html でOK。
・テスト終了後、クローズするテストページに関しては、301リダイレクト設定をする
→ブクマしたユーザーからのアクセスがエラーにならないように。
・テスト結果が、Analytics管理画面に反映されるまで数時間を要する(リアルタイムではない)
・「テストページA」「テストページB」のどちらを表示するか、Google側が振り分けてくれるので、
アプリ側でランダムに振り分ける処理が必要ない。
→「テストページA」「テストページB」を検証したい場合、リンク元は「テストページA」のみでOK
・「multi-armed bandit」方式を採用しており、それまでのテスト結果に応じて、成果の高いページをより表示するようにGoogle側がコントロールしてくれる
→たとえば、テスト結果がある程度蓄積されて「テストページA」のCVRが6%、「テストページB」が3%だった場合、テスト期間中であっても「テストページA」に、よりトラフィックが振り分けられる
・テスト対象とするユーザーの割合を設定できる
→たとえば、「テスト対象のトラフィックの割合」を50%にすると、
オリジナルページ→75%(テスト非対象が50%+25%)、テストページ→25%となる。
なかなか素敵な機能だとおもいます。
Chromeブラウザver28で、レンダリングエンジンがWebKitからBlinkに変更されました。その背景とか今後の影響とかの話。
2013年8月22日
カープが明日ついにデニム柄ユニフォームで試合をします☆
http://blog.livedoor.jp/yakiusoku/archives/53987751.html
Chromeのエンジン変更ですが、PC向けもiOS/Androidのスマートフォン向けも変更されました。
いろいろ弄ってみたけども、スマートフォン向けの方が影響が大きいという印象。
もともと、”WebKit”はアップルが開発を主導してきたオープンソースのWebレンダリングエンジンで、Mac OSのWebブラウザ”Safari”で使用するために開発されたものだけど、
GoogleがAndroidとChromeにWebKitを採用したことで利用者が一気に増加したエンジン。
そんな生い立ちのWebKitですが、
・Googleのマルチプロセスアーキテクチャ(※)がWebKitには採用されず、独自に保守をしなければならなかった ※ブラウザプロセス、レンダリングエンジンプロセス、プラグインプロセスにプロセスを分けて、1つのプロセスがクラッシュしても、他のプロセスに影響が出ないアーキテクチャ
・WebKitそのものを改良したくても、他のプラットフォームに影響があり改良ができない
・結果、ソースやビルドシステム環境が複雑化してしまった
こんな問題、課題が付き纏うがために、Googleさんが、
「ブラウザ自体の開発スピードを上げる(開発コストを下げる)」「セキュリティ向上」
このあたりを目的として、WebKitからBlinkに切り替えたように思います。
どう変わったかと言うと、
SSLページから、非SSLコンテンツを読み込む場合のチェックが厳しくなったり(一般的な作りとして、SSLページから取得するコンテンツはSSLで読み込むべきだけど)、iOS/Android向けのChromeでは、HTML5のFullScreen APIへ対応やWebページの翻訳機能などが追加になってます。
SSLページからのコンテンツチェックについては、iframeで読み込んでいるアフィリエイト系のタグとか、外部サービスと連携する通信は確認した方が良さげ。
現状、スマートフォンのデフォルトブラウザは、”iOS→Safari”、”Android→Android標準”だから、
Blinkへの変更があまり目立ってない感じがするけど、docomoのAndroid4.3から、標準ブラウザがChromeになる噂もあって、そうなるとネイティブアプリのWebViewにも影響が出てくるし、
いろいろと騒がしくなるんじゃないかなーと思っております。
Androidの実機でウェブサイトのJavascriptをデバッグする方法
2013年5月31日
スマートフォン向けのWebサイトを作ると、おおむね使われるJavascript。
Androidの実機でデバッグしたい時に、実機にコンソールを表示する方法と、PCに表示させる方法。
その① 実機のAndroid標準ブラウザでコンソールを表示する
(1)Android標準ブラウザを起動する
(2)アドレスバーに“about:debug”を入力してEnter
(3)ブラウザの「サブメニュー」→「設定」に、”デバッグ”をタップ
(4)“Show Javascript Console”にチェックが入っていることを確認 ※“UAString”でユーザーエージェントも変えられたりします
(5)ブラウザに戻って“SHOW JAVASCRIPT CONSOLE”をタップすると、コンソールログが表示される※以下のメソッドが使えるらしい
console.log();
console.info();
console.warn();
console.error();
(6)コンソールを表示した状態でフォームにコードを入力し、“Evaluate”をタップすると、Javascriptが実行できちゃいます
(7)デバッグが終わったら、もう一回アドレスバーに“about:debug”を入力してEnter
その② Android SDKのadb(Android Debug Bridge)ツールを使ってPCに表示する
※実機とPCをUSBで繋いでおく
※実機の「設定」→「開発者向けオプション」→「USBデバッグ」にチェックを入れておく
(1)手始めにAndroid SDKをインストール ※仮にc:直下に保存
(2)コマンドプロンプトをたちあげる
(3)c:\android-sdk\sdk\platform-tools に移動
(4)“adb devices”を打って、接続が認識されているかを確認
(5)“adb logcat -v time | findstr browser”で、ブラウザに関連するログを時間付きで表示
(6)“adb logcat -v time | findstr browser > log_20130530.txt”で、ブラウザに関連するログを時間付きでlog_20130530.txtに吐く
他にも、SDKのadbツールは、apkをインストール/アンインストールできるコマンドだったり、シェルを起動するコマンドもあり、いろんなことができて便利そうです。
Googleがペンギンアップデート2.0で検索エンジンの仕様変更をしたと話題に。
2013年5月24日
検索エンジンの仕様変更にはペンギンとパンダの2種類あって、
ペンギンアップデート…外部リンクの再評価。過剰にリンクを獲得したり、有料で買ったリンクを被リンクに多く持つサイトの順位を下げる。
パンダアップデート…コンテンツの質の再評価。他のサイトをコピーしているサイトとか、内容の薄いサイトの順位を下げる。
いずれも、検索結果をよりユーザーに有益なものにする目的で行われるアップデート。
今回実施したのはペンギン。
変更内容としては、
・検索結果に表示されるドメインの多様性に関する変更
・同ドメインのページでGoogle検索結果に表示される件数が、現状よりも減少する
・より幅広いサイトが検索にヒットするようになる
・検索結果を1ページ目、2ページ目･･･と辿って行くにあたり、同ドメインの
ページが4件表示されたら、それ以後のページには表示しないようになる
この変更で、楽天とかNAVERまとめが影響を受けるんじゃないかと言われている。あとはFC2とかアメブロなどの無料ブログも。
試しに、Chromeのシークレットモードでやってみたところ、米国は既に導入されたけど、日本はまだみたい。(2013/05/24 16:00現在)
具体的にどう変わったか見てみる。先日家のルーターがぶっ壊れたので、
“amazon 無線lanルーター”で検索した場合、今までは検索結果にamazon.co.jpがずらーっと並んでたけど、
今回の変更で、検索ワードに“amazon”を含めているのにも関わらず、検索結果にamazon.co.jpが
上位4件しかいない。
あと、米国版で試して気づいた点は、サブドメインを含めた4件では無いっぽい。
上のアルゴリズム変更以外にもいくつか仕様変更したみたいだけど、結局、ペンギンアップデートなんで、ブラックハットなSEO手法を排除することが目的だから、悪いことしてなければ影響はそんなに無いとおもわれます。
ブラウザストレージと言えば、cookieよりもHTML5のWeb Storage！！
2013年5月6日
広島 屈辱の東京Ｄ１３連敗 ４タコ栗原は２軍落ち
東京ドームでこれっぽっちも勝てません。勝てる方法を知っている方、教えてください(涙目)
んで、ブラウザストレージ用のAPIとしてHTML5で追加された、Key-Value型データストアのWeb Storageについて。
Amazonの「この商品を買った人はこんな商品も買っています」のページ番号をsessionStorageで保存したり、あとは、フォームの入力内容の保存とか、ゲームのプレイ履歴の記録なんかの用途でも使われてると思われます。
従来ブラウザストレージとして使われてきたcookieの後継技術だー、cookieより便利だーなんて言われてるけど、具体的なcookieとの違い、特徴はこんな感じ。
(1)保存容量
cookie：4Kbyte
Web Storage：5Mbyte
(2)データの有効期限
cookie：あり ※指定期限まで有効
Web Storage：なし
(3)セキュリティ
cookie：サーバへアクセスする度に毎回自動送信。自動送信なので、セキュリティは低い。
Web Storage：自動送信なし。セキュリティの確保は実装に依存する。
(4)通信量(トラフィック)
cookie：サーバーに自動送信するから、通信量は多くなる。
Web Storage：Javascriptで登録／参照し、クライアントサイドで処理が完結するから、余計な通信がない。でも結局は実装に依存する。
(1)の容量に関して、Web Storageはオリジン(プロトコル+ドメイン:ポート番号)単位で5M使える。
http://ohsexybaby.com:80 で5M、
https://ohsexybaby.com:443 で5M。
あと、Web Storageには2種類あって、永続的にデータを保存する「localStorage」と、
ウィンドウやタブが開いている間、データを保存する「sessionStorage」がある。
※オリジン単位の「localStorage」と「sessionStorage」を合わせて5Mの保存が可能。
localStorageは、ウィンドウやタブを閉じても残っているけど、sessionStorageは、ウィンドウやタブを閉じると削除される。
(2)のデータの有効期限に関しては、Web Storageは有効期限がない。
ただ、有効期限がない分、「localStorage」にゴミデータが溜まらないような実装が必要。
(3)のセキュリティに関しては、サーバーに自動送信するcookieよりは、Javascriptで制御できるWeb Storageの方がセキュリティは高い。けれども、Web Storageに保存していても、XSSなどの対策をしていないと、データを盗まれる可能性がある。
あと、Web Storageは、http://ohsexybaby.com:80のlocalStorageに保存したデータは、http://carp.com:80からは登録／参照不可。これはまー当然っちゃ当然。
(4)通信量については、Web Storageに登録／参照する分には、サーバーとの通信はない。
Web StorageのデータをDBに登録したり、逆にDBから引っ張ってきたデータを、Web Storageに保存するような実装にすれば、もちろん通信は発生する。
ただ、毎回サーバーに自動送信するcookieと比べて「余計な通信が発生しない」という点で、Web Storageの方がトラフィックは抑えられる。
というわけで、容量たくさん使えるし、レスポンス速いし、セキュリティもcookieより上だしのWeb Storageですが、なんだかんだ最終的には設計／実装に依存するんで、頑張っていきましょう。
スマートフォンの動きが遅い！もっさりしてきた！時の対処方法とその効果。
2013年3月14日
スマートフォンの動きが遅い！もっさりしてきた！って時に、
一番手っ取り早い対処が、端末の再起動。AndroidでもiPhoneでも同じ。
AndroidOSもiOSもマルチタスクで、並行して複数のプログラムが動くことで、
同時にいろいろな処理ができる。その反面、メモリが足りなくなって処理が重くなることがある。
一発再起動することで、タスク終了、メモリ解放、キャッシュクリアをしてくれるんで、
ヒマなときに再起動しましょう。特に古めのAndroid端末は1日1回やった方が良いと思う。
で、1週間ほど再起動してないiPhoneとAndroidで、再起動前後のベンチマークを比較してみた。
使ったアプリは「PerformanceTest Mobile」
Android：https://play.google.com/store/apps/details?id=com.passmark.pt_mobile
iPhone：https://itunes.apple.com/jp/app/performancetest-mobile/id494438360
CPU(演算処理,圧縮,暗号化)・ディスク(ストレージへの読み書き)・メモリ(RAMへの読み書き)の
パフォーマンスを計測。
■Android(Xperia arc)
再起動前→CPU：1307、メモリ：1723
再起動後→CPU：1346、メモリ：1749
※ディスクはなぜか計測不可
【再起動前】
【再起動後】
■iPhone(iPhone4S)
再起動前→CPU：9076、ディスク：3872、メモリ：1813
再起動後→CPU：9072、ディスク：6372、メモリ：2150
【再起動前】
【再起動後】
結果、iPhone4SのCPU以外は再起動後に数値が向上。
再起動で端末のスペックがあがることは物理的にないので、
ずーっと再起動せずに使い続けると、端末のパフォーマンスは低下していくってことなんだと思う。
Googleの検索ワードはどんどん取れなくなる？”encrypted_search_terms”ってなんすか？の件。
2013年2月15日
WordPressのアクセス解析用プラグイン”WordPress.com Stats”をふわーっと見ていたら、
検索キーワードに、“encrypted_search_terms”がたくさん出ている。
こんなワードでアクセスがくるん？？と思いつつ、調べてみたら、
どうやらGoogle検索からの流入らしい。ソース(えいご)
PCブラウザでは、Chromeをはじめ、FirefoxでもSafariでも、Google検索すると、
非ログイン状態でもSSL通信になるので、そのあたりが影響しているのかなと推測してみる。
この、”WordPress.com Stats”の”encrypted_search_terms”の数値と、
Google Analyticsのオーガニック検索トラフィックの(not provided)の数値が同じになるのか？
と思ったけど、Google Analyticsの”(not provided)”の方が約2倍多かった。
一方で、Googleウェブマスターツールだと、”encrypted_search_terms”や”(not provided)”と
ならずに、それらの検索ワードが取得出来る。そのうえ検索ワード毎のCTRまで取れるのであります。
さらに、Analyticsとウェブマスターツールを連携させることも出来るので、一度連携させてしまえば、Analytics上で(not provided)の無い、検索ワードを確認することが可能になります。
Google Chrome(PC)で広告をブロックできる便利なエクステンション
2013年2月1日
去年の秋くらいから、Chromeでブラウジング中に動画広告が勝手に再生されて、
止めても止めても再生される事案が発生。
あらゆるWebサイト上の動画広告が勝手に再生されるので、こんなんじゃおちおち日刊サイゾーも
見ていられない！！ってことで、広告をブロックするエクステンションを探してみる。
Adblock Plusというエクステンションが良さげなので、早速インストールしてみる。
Chromeウェブストアにアクセスして、画面右上の”CHROMEに追加”ボタンをクリックして、
インストールおわり。
アドレスバー右端のアイコンから、サイト毎に広告の表示／非表示の設定ができる。
Adblock Plusインストール後は、広告が表示されなくなり、ロケットニュース24がゆっくり閲覧できるようになりました。
Gmailもほらこの通り。
広告でないっす。
これで一見落着～かと思いきや！！
実は動画広告の犯人は、Chromeのエクステンションだったらしい。
Smooth Gesturesっていう、マウスジェスチャの拡張機能。
こいつが、Webサイト内の広告を動画広告に書き換える、スパイウェア的な仕組みをもっているとか。
マウス大好き人間の自分にとっては、かなり重宝していた拡張機能だったので、ちょっと残念(´Д｀。)
DNSサーバーのお引越しの正しい手順とDNSの浸透問題
2013年1月25日
Webサイトを運営していて、サービスプロバイダーの変更やレジストラの変更の際に発生する、DNSサーバーのお引っ越し。その手順とDNSの浸透問題について。
DNSサーバーの引っ越す際の目的は2つ。
(1)”インターネット上の各キャッシュDNSサーバー”が
名前解決要求をする際、引っ越し先の権威DNSサーバー(新DNS)に向けさせる
(2)”インターネット上の各キャッシュDNSサーバー”に、新DNSの情報を提供する
(1)は、引っ越し元の権威DNSサーバー(旧DNS)に名前解決の要求を出すのではなく、
新DNSに向けさせたいという話で、
(2)は、キャッシュされている旧DNSの情報ではなく、新DNSの情報をいち早く提供したいという話。
(2)に関して、引っ越しの手順を間違えてしまうと、キャッシュDNSサーバーに”旧DNSの情報が消えずに残り続けて”しまいます。その状態を”DNSの浸透問題”と呼んでいるケースが多いらしいけど、正しい手順を行えば回避可能。
※ただし、正しい手順で引っ越したとしても、即時反映ではなく、「旧DNSの情報の消去」を待つ時間は発生する。
実際の引っ越しはこんな感じでやりましょう。
(a)引っ越し元の情報
権威DNSサーバー：ns01.carp.com.
グローバルIP：192.0.1.1
(b)引っ越し先の情報
権威DNSサーバー：ns01.ohsexybaby.com.
グローバルIP：192.0.1.2
①aのns01.carp.com.のゾーンデータを、bの情報に書き換える
②親の権威DNSサーバーに登録している委任情報を、bの情報に書き換える
③a,bのDNSサーバーを並行運用
→aのns01.carp.com.のTTLの指定時間が経過するまで
→親の権威DNSサーバーのTTLの指定時間が経過するまで
④aのns01.carp.com.を停止
この手順のうち、①をやらないと、既にキャッシュされた、ns01.carp.com.がいつまでも応答に使われてしまい、結果的に、192.0.1.1のWebアプリやらコンテンツが表示されちゃうので要注意。
