競合するGoogle AppsアカウントでChromeにログインする方法

自分用のメモも兼ねて…

僕は以前から、自分のドメインでGoogle Appsを利用していたのですが、ついこの間まで通常のGoogleアカウントとGoogle AppsアカウントはGoogle内部でも管理が別れており、Google Appsサービスを使う場合はそのアカウントでログインし、Googleサービスを使う場合はGoogleアカウントでログインする、という様な別れ方をしており、Google AppsアカウントでGoogleサービスを使うには、Google AppsアカウントでGoogleサービスに登録する(プロバイダアドレスなどをGoogleアカウントとして登録するのと同じ手順)必要があり、なかなか使い分けが難しかったのですが、1年ほど前からこのAppsアカウントとGoogleアカウントの統合をGoogle側で進めている状態です。

と、いきなり長々と書いてみましたが、文字だけだと意味が分かりづらい。
しかし図を書くのが面倒…なので詳しくはこちらをご覧ください。

競合するアカウント - Google アカウント ヘルプ


通常は特になんの支障もなく、ユーザの気付かないレベルで移行が行えるのですが、僕のアカウントはGoogle AppsのデータとGoogleアカウント内にあるデータとで、データが二重に存在していることになり、統合作業を別途せざるを得ませんでした。
現在も尚、一部サービスについては手動でも移行がなかなか難しい状態となっています。


さて、そんなアカウントでChromeにログインしようとすると


このようなエラーとなり、ログインできません。
同期サーバがビジーのため、と出ますがそんなことはないです。表示されているエラーの理由としては不明ですが、実際のところは競合しているアカウント故に起きています。

では、どのようにしてこのアカウントでChromeにログインするか。


  • 1. Googleに用意された統合移行処置アカウント(user%yourdomain.com@gtempaccount.com)を利用する

  • 2. どうにかしてログインする


1.についてはそのままで、conflict-user%anoncom.net@gtempaccount.comの様なアカウントでログインすると今まで使ってきたアカウントと同じく同期し、利用できます。

しかし、1.のままの場合、Androidでの連携がうまく出来ません。

というのも、今回のそもそもの動機として、Chrome for Androidを使って、モバイルとPCのChromeを同期させたいのです。
ですが、Chrome for Androidはログインユーザの認証にAndroid端末側に登録しているGoogleアカウントから紐付けてログインするのですが、Android側のアカウント処理が、 conflict-user%anoncom.net@gtempaccount.com という形式のアカウントを正常なアカウントとして受付けてくれず、どうしても conflict-user@anoncom.net でログインしなくてはならないのです。

ここからが本題。
ではどのようにしてログインさせるか。


まず、現在のChromeの同期ログインを解除します。
そして、Web上のGoogleサービスでもログインしている場合は一度ログアウトします。

その後、 https://accounts.google.com/Login などのページにアクセスします。
するとGoogleのログインフォームが表示されるため、Chromeと同期したいアカウントでログインします。

認証が成功すると、次のページで以下の様なダイアログが画面上部に表示されるので、同期する(またはOK, sync)を押します。

もし上記ダイアログが表示されない場合、

Mac: ~/Library/Application Support/Google/Chrome/<Default|UserName>/Preferences
Windows: C:¥User¥<username>¥AppData¥Local¥Google¥Chrome¥User Data¥<default|UserName>¥Preferences

※<default |UserName>はChromeのユーザを作成していなければdefault、作成していればUserNameにその宇ユーザ名を指定する

のファイルを開き、中のJSONから "reverse_autologin" を探し、 "enabled" の値を true にし、一度Chromeを再起動てあげればOK。

このダイアログでOKを押すと


上記の様なダイアログが表示されるのでこれもOKを押します。

すると、






画面右上に上記の様なポップアップが表示されます。
そのままChromeを確認すると、


このように、エラーになっていた競合するアカウントでもログインすることが出来るようになりました。

Galaxy Nexusを購入しました

先週、12月19日にSamsung Galaxy Nexusを購入しました。現時点でAndroid OS 4.0を搭載した唯一の機種です。また、その名の通りGoogle監修によるリファレンスモデルのNexusシリーズの最新機種です。
国内では既に12月4日にドコモから日本向けのGalaxy Nexus SC-04D発売されており、その手のレビュー等については他の方が既にたくさんレビューされているので、今回この場では、それ自体に対する使用感などについてはここでは特に書きません。そちらが目的の方は別途探してみてください。

では何を書くかというと、誰も興味ないであろう、既にiPhone4を利用しているのに、どうして買ったかなどを自分の記録のために書いておきたいなと思った次第です。

なんで?動悸は?


Android機は今まで触ったこともあるし、それ向けにモック程度のアプリを作ったこともありました。しかしどちらも仕事として、また会社端末の初代Xperia、初代GALAPAGOSの機種を触ったことがあった程度でした。
この辺りで感じたことは、動作がモッサリ、タッチした箇所が目的でない場所で反応するなど、以前から使っていたiPhoneと比較しても全く使いたいと思える端末ではありませんでした。
なので、今後もAndroidは買いたくないし使いたくないなと思っていました。

しかし、昨今のスマートフォンの普及状況を見ても分かるとおり、端末も安価で多数のメーカーから販売されているAndroid端末の普及速度は、スマートフォンのみならず各種タブレット、さらには一部でカーナビに使われるなど、様々なところで目にするようになってきました。

……なんていう堅苦しい市場動向は、多少は考えていつつもそこまで今回は考えてません。
詳しくは経緯にて。

また、アプリの開発、マーケットへの公開についてもiOS用に開発するよりも開発しやすく(Javaで作れる習得のし易さ、開発環境もeclipse+Android SDKでどの環境でも行える)、AppleのAppStoreに出すよりも容易(実質審査はなく、開発者に年間利用料を請求するのではなく、登録費用登録費用$25を初回に支払うのみ)なため、開発者としても遊びやすいなと思えるところでした。

あとは、先ほど挙げましたが、普及台数が多いのは本当のところで、今までWebアプリを主に作ってきた身として、Android位はせめて手元に実機で欲しいなというところです。
エミュレータでも良いんだけど、確認だけでアレ立ち上げるのは。。。

ぶっちゃけた話しが、ただ携帯の買い換えをしたかっただけです。
本当を言うとWindows Phone 7.5(Mango)の端末が欲しかったのですが、

現状、auの東芝製端末しか出ていない。
auにMNPしたくない。

というところで今回は諦めたのですが、本命としてWP7はまだ欲しいので、どこかでうっかりする可能性がまだまだありそうです。



経緯


今年(2011年)9月頃に仕事で出張したバングラデシュ国内で、それまで使っていたガラケーを紛失。

恐らく、舗装されてない道を移動する際に使ったバイクタクシー的な乗り物に乗ってる最中に、ポケットから飛び出してそのまま。

見つかるハズもなく帰国。

携帯会社の安心保険的なものを使ってもあまり安くそこそこの機種をゲットできそうにもなく断念。

今さら新しいガラケーなんて買う気もなく、iPhone4使っているのにiPhone4 S買う気にもなれず。

現在発売されているAndroidも特に魅力がなく。(
↓→SBMからWP7機が出てたら買ってた

分割購入ではなかったものの、端末代金割引終了まであと数ヶ月。

以前使っていた4年ほど前の携帯を使う。

しかしバッテリーが膨張して破裂寸前状態、また電池も5分程度しか持たない情況でどうにか過ごす。

どうにか3ヵ月粘ったが、無くした端末よりも機能的にも劣り、電源も持たない状態で毎月通信費を取られるにはもう限界。

Android 4.0搭載のGalaxy Nexus発売。

Nexusはリファレンス機なので、メーカーやキャリアのつまらないプリインアプリが無い。
↓→変な制限もなく、素のAndroidがそこそこ最新スペックで使える

ドコモにMNPしてしまおうか(SoftBankを使ってます)
↓→でもドコモ版は相変わらず制限あるし使いづらい。
↓→ドコモはiモードのしがらみで生まれたSPモードがあるのが好きじゃない。
↓→そのSPモードはずっと障害続き
↓→→その矢先にランダムメールアドレス事故。
↓→→ドコモにはやっぱり移りたくない…

Nexusは世界中で売ってるし、この際SIMフリーを探してみよう

意外と安く、5.6万円程度で買える。

よし、買おう!



SIMフリーです


今回は自分では初となる、SIMフリー、そして初の自前Androidということでちょっと楽しみにしてました。
本来であればガラケーからの乗り換えとなるのでSIMフリーとは言え、ショップでスマホ向けプランに契約を切り替えないと行けないのですが、あれこれ調べた結果APNさえ設定すれば諸処の都合上今の契約でもうまく使えそうであることが分かったため、現在はそのまま使っています。
あとガラケー側で利用しているおサイフケータイなどがまだ残っていて、こちらの切り替えが出来てないので通信できなくなってしまうと困るなーというのがあります。

一昨年と昨年は年に2〜3回程度海外に出張に行くこともあったので、今後も出張期間や海外に行く際にはこの端末に現地のSIMを挿して使えば、ローミングで高額にならずに安くすむし良いなーという利点も含めてます。



で、何したの



まずはフツーに起動して、アカウント設定して、アプリ入れて…としていたのですが、フォントがアレ…。
そう、中華フォントと言われているCJKフォント。あれ?聞いてた話しだとモトヤフォントが採用されてリポジトリにも入ってたはず…。
で、見慣れない書体で違和感をぬぐいきれず、フォントの入れ替えについてググってたりしました。

その方法については、以下のサイトを参考にさせて戴きました。
Linux/CGP作業メモ » Galaxy Nexusのフォント入替え方法(非rooted)のメモ

上記のサイトでの補足事項として、最初、DroidSansFallback.ttfの記述の後ろに設定を追加していたのですが、どうもDroidSansFallback.ttfで定義内でマッチしない言語のフォントをすべてを拾ってしまうようだったので、これの直前に追加する形にしたところ、うまく反映できました。

現在はrootを取得してまでしたいこともないので、その辺りについては全く行ってないです。


で、まとめると


そんなわけで、WP7端末が欲しい私がAndroid端末を購入したつまらない話しでした。

さくらのVPSを使いながら行ったウェブサイトの3つの負荷対策

久しぶりのブログ更新になります。
色々と書きたいこともあったけど、サボってます。(継続中)

少し前の日記に書いたのですが、このブログおよび僕が公開しているいくつかのウェブページについては、基本的にさくらのVPS 512を利用しています。
512は最低プラン(初期からあるプラン)でメモリが512MBしかない環境です。そんな環境なのもあり、以前にTwitterのアカウントが商標権問題で変更せざるを得なくなった話を書いた際に、ありがたい事(?)に/.Jに取り上げられたり、はてブも300近いブックマークをもらったりするほどのアクセスとなりました。

当時、記事を公開した日の朝には、はてブやTwitterなどで話題に上げられ、アクセス増からサーバが高負荷状態となり、記事の閲覧が出来ない状態が続いていたりもしました。このときはmysqlやApacheの再起動を繰り返してみたりするも、あまり効果を発揮できず、最終的にはサーバを再起動させたように覚えています。

この時以降、こんなしょぼくれた個人サイトやブログでも、ある程度はサーバ負荷対策やキャッシュをしっかりしておかなければなと思い、いくつか対策を行ってきました。
これはサイトを運営する上で、サーバやサービスを落としてはいけないという下手な使命感のようなのもありますが、自分自身ウェブ系エンジニアを名乗るとして、それだけのことが出来ていないことが恥ずかしくもあったためです。


長い前置きとなりましたが、そんな僕が現在まで行ってきた大量アクセス時の負荷対策をいくつか挙げていきます。



Wordpressのキャッシュプラグインのインストール
WP Super Cache


おいおい、そこかよというツッコミも聞こえてきそうですが、当時、僕はこのプラグインを入れたつもりだったのですが、実際には入っていない状態となっていました。
そのため、記事のリクエスト時に毎回データベースに接続が行われ、データベースへの接続も、要求処理も原因し、結果過負荷となり、ページを表示出来ない状況に陥っていました。
その後このプラグインを正しくインストールして設定することで、ページのキャッシュが有効化され、大量アクセスが発生してもデータベースへの負荷をかけることなくページを表示できる様になりました。
なので、このプラグイン一つをとっても大量アクセスに対しては劇的に変わるため、これはWordpressでサイトやブログを運営するにはほぼ必須だなと実感しました。


Apacheからnginxへ
nginx
php-fpm

今まではApache + phpモジュールという、ウェブサイト構築ではごくごく一般的な構成を取ってきました。しかし、この構成は設定も楽で、管理もしやすく、TIPSも大量にあるため運用するにはとても最適なのですが、大規模アクセスとなるとApacheのメモリ消費量や負荷が目立つようになってきます。また、Apacheの中にphpへの処理が組み込まれるような形となる(具体的には異なりますが)ため、php側の処理にApacheが引きずられることとなり、phpの処理が関係ない部分まで応答が返せなくなるケースにまで至ることがあります。

そこで、メモリやCPUリソースの消費量も少なく、高速にリクエストされたコンテンツを処理して配信することができると話題のnginxを導入してみました。
これを導入することでメリットがあるのは、複数のウェブサーバとアプリケーションサーバで構築された中規模以上の環境でのリバースプロキシとしての利用や、画像などの静的コンテンツを大量に配信するサービスだと思います。

普通のウェブサービスの場合は、運用のし易さの面からも、ある程度の規模なら今までのApache + phpでもなんら問題ないと思います。
僕がこれを導入したのは、負荷対策と言うよりどちらかというと、最近のCGM系コンテンツやUGC系サービスサイトでよく見かけるようになってきたと言う技術的な流行が気になったというところと、個人的な実験的な要素が濃いです。

このnginxはApacheに比べて格段に動作が軽いのと、phpなどのスクリプトはfastcgiとして基本的に切り離していること、細かなところでカスタマイズができること、機能的にもApacheにはない、高速配信のためのキャッシュの仕組みがいくつか設けられていることなどのメリットもあります。
ただし、現時点ではまだまだ新しいサーバで、日本国内における運用系の情報は圧倒的に少ないですが、開発も活発で、また後発のプロダクトと言うこともあり、先発のApacheをはじめとしたサーバのいいところを取り入れて行っていると思い、今後も期待が出来そうかなと思います。
こちらの機能や導入についての詳細は、いくつかのブログで既に書かれているので、そちらを参照してみてください。


CDNの利用
CloudFlare

僕はCDNと聞くと、Akamaiなどを利用した、それこそ大規模なサイトでのコンテンツ配信をイメージしていたのですが、そのCDNを個人のウェブサイトにも簡単に、しかも無料で導入することができました。それがこのCloudFlareです。

CloudFlareは、ウェブサイトを丸ごと、cloudflareが持つCDN上にキャッシュとして持ち、配信してくれます。
簡単なイメージ的には、キャッシュプロキシが入る感じです。

これの導入方法は少々敷居が高いものの、至って簡単で、CloudFlareでアカウントを登録した後、サイトのドメインのDNSをCloudFlareの提供するDNSサーバに切り替え、DNSの設定をするだけ。簡単です。

メリットとしては、

  • キャッシュプロキシとなってくれるため、サイトに一切手を入れず、丸々をキャッシュしてくれるため、導入が楽

  • 高機能なDNS機能もフリーで提供される

  • ほぼ静的なページを大量のアクセスを捌くのに、追加サーバ導入コストを抑えられる

  • 簡易アクセス統計機能付き(リクエスト回数など)

  • キャッシュプロキシだけど、Google Analyticsなどの外部アクセス解析機能などにもしっかり対応

  • リクエストを弾きたいIPなども制御できる

  • これらがすべて無料(ただしある程度以上の規模は利用不可?)

といったところ。
上記を管理するコントロールパネルのUIのよく出来ていて、簡単かつ気持ちよく設定できます。
ぶっちゃけ、CDN機能を使わずに、高機能なDNS機能だけ使わせてもらうことも可能。最近対応していましたが、以前はVALUE-DOMAINのフリーDNSではIPv6には対応していませんでしたが、CloudFlareではIPv6にも対応されていました。

逆にデメリットとしては、

  • ドメイン単位での導入が前提なので、そもそもドメインを持っていないと利用できない。

  • ドメインのネームサーバ変更を必要とするため、サブドメイン毎に複数サービス運用している場合に、一部のサービスだけ利用を試してみるといった利用がしづらい(設定すれば可能だが…)。

  • サーバプログラム内でユーザのIPアドレス毎に制御を行っている場合、そのまま利用できない(一部参照先ヘッダの変更など、プログラムの書き換えが必要)

といったあたりでしょうか。


ちなみに、自分のサーバへのリクエストログには、CloudFlare経由の場合、すべて米国にあるCloudFlareのIPからの接続が残ります。
余談ですが、CloudFlareのキャッシュプロキシサーバは
varnishを利用している最近はnginxベースのものになったようです。
(コメントをいただきましたたくさんありがとうございます)




以上、3つとなります。他にも出来ることはあると思いますが、まずはこれでひとまずと思っています。
というのもあれ以降、大量のアクセスが舞い込むようなことが無いため、これでどれほどの効果が上がるかがまだ検証できていない状態です。


#本当は別のことを書こうと思っていたのに、気付いたらまったく違う内容で書き上げてしまっていたというオチ。

PSNの障害と個人情報漏洩について

話題のPSNのネットワーク障害、いうかセキュリティ問題および個人情報漏洩について、本日14時頃にSCEからメールが来ていたので掲載してみる。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【重要なお知らせ】2011年4月27日
“PlayStation Network”/“Qriocity”をご利用の皆様へのお詫びとお願い
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

※本メールは重要なお知らせとなりますため、
“PlayStation Network”/“Qriocity”にアカウント登録されている皆様へ
お送りさせていただいております。

本内容は下記のURLからもご確認いただけます。
http://www.jp.playstation.com/R/m10427_PSN001


2011年4月21日より“PlayStation Network”および“Qriocity”の障害が
継続しており、お客様および関係各位に多大なるご迷惑をおかけしており
ますことを深くお詫び申しあげます。

弊社では、同日より各サービスの公式Webサイト上に障害の状況を都度告知
すると同時に、本件詳細についての徹底調査を行ってまいりましたが、このたび
“PlayStation Network”および“Qriocity”に対する不正アクセスにより、
2011年4月17日から19日にかけて以下のようなお客様のアカウント情報が漏洩して
いた可能性があることが判明いたしましたので、ここに深くお詫びを申しあげる
とともに、その旨を報告させていただきます。

漏洩した(不正アクセス者が入手した)とみられるアカウント情報: 

・お客様が“PlayStation Network”/“Qriocity”に登録した、氏名、住所、
 Eメールアドレス、生年月日、“PlayStation Network”/“Qriocity”パスワード、
 “PlayStation Network”オンラインID

また、以下の情報につきましても不正アクセス者が入手した可能性があります。

・購入履歴、請求先住所、パスワード再設定用の質問への回答等のプロフィールデータ
・サブアカウントに関する上記情報(お客様がサブアカウントを作成されている場合)

なお、お客様が“PlayStation Network”または“Qriocity”にクレジットカード情報を
登録されている場合、登録されているクレジットカード番号(セキュリティコードを
除く)および有効期限に関する情報が不正アクセス者に入手された可能性を完全に
否定することはできませんが、現時点ではそのことを示す形跡は見つかっておりません。

弊社では冒頭に記載しました不正アクセスの事実が確認された時点で速やかに
以下の措置を講じるとともに、引き続き詳細についての調査を継続しております。

1)“PlayStation Network”および“Qriocity”サービスの一時的な停止
2)本件の調査を情報セキュリティ専門会社に依頼し、実態の把握に努めること
3)個人情報の保護強化を目的とし弊社のシステムセキュリティを更に高度化するため、
  システムの再構築によるネットワークインフラの補強

弊社にとって安全且つ高品質のエンタテインメントサービスをお客様に提供することは
最優先事項と認識しております。弊社では今回の事態を真摯に受け止め、引き続き
個人情報の保護の強化とサービスの速やかな復旧を目指してまいります。

本件に関する追加情報やサービスの復旧時期などが判明した場合には、Webサイト等を
通じて継続的にお知らせしてまいります。お客様には多大なるご迷惑とご心配をおかけ
しておりますことを重ねてお詫び申しあげます。

“PlayStation Network”および“Qriocity”のサービスが復旧した際は、お客様が
ご利用のパスワードを変更されることを強く推奨いたします。併せて、お客様が
インターネット上でご利用の他のサービス等で、“PlayStation Network”/“Qriocity”
と同じユーザーIDやパスワードを使用されている場合は、それらの変更を強くお奨め
いたします。

さらに、お客様に成りすました不正ログインや不正利用を防ぐために、アカウントに
登録されている情報の詳細やクレジットカードの引き落とし履歴等を定期的に確認される
ことを推奨いたします。(クレジットカードに関連する情報についてご不明な点等に
つきましては、ご利用のクレジットカード会社にお問い合わせください)

なお、いかなる場合におきましても弊社からお客様のクレジットカード情報等の
個人情報をEメール等でお尋ねすることはありません。安全のため、お客様各位に
おかれましてはEメール、電話、郵便などを使ってお客様の個人情報を聞き出そうと
する手口には十分お気を付けください。

本件についてご質問等がございましたら、
株式会社ソニー・コンピュータエンタテインメント インフォメーションセンター
および“Qriocity”お客様窓口までお問い合わせください。

≪お問い合わせ先≫
“PlayStation Network”についてのお問合せ
株式会社ソニー・コンピュータエンタテインメント インフォメーションセンター
TEL 0570-000-929(PHS、一部のIP電話の場合 03-3475-7444)
受付時間10:00〜18:00
http://www.jp.playstation.com/support/

“Qriocity”についてのお問合せ
“Qriocity”お客様窓口
0120-365-859
※携帯電話・PHS・一部のIP電話などフリーダイヤルがご利用になれない場合
0466-31-2505
受付時間 月〜金:9:00〜18:00 土日祝:9:00〜17:00
http://www.qriocity.com/support

==============================================================================
本メールの送信メールアドレスは配信専用のため、返信いただいても
回答することができません。不審なメールやメッセージを受け取った方は、
当メールに記載のお問い合わせ窓口へご連絡をお願いいたします。

「お問い合わせ窓口」
ソニー・コンピュータエンタテインメント
インフォメーションセンター
TEL 0570-000-929(PHS、一部のIP電話でのご利用は03-3475-7444)
受付時間 10:00-18:00
http://www.jp.playstation.com/R/support_formjp

-------------------------------------------------------------------------------
<発行>
ソニー・コンピュータエンタテインメント

■“PlayStation Network”のご利用に関する規約
http://www.jp.playstation.com/R/psn_kiyaku

■よくあるお問い合わせ(FAQ)
http://www.jp.playstation.com/support/

■ソニー・コンピュータエンタテインメントの個人情報保護方針
http://www.jp.playstation.com/about/privacy.html

FirefoxからChromeに乗り換えてみた

今までずっとMozilla Firefoxを使ってきていたのですが、起動しただけでメモリは食いまくるし、タブ開きすぎるとすぐ固まるし、重いし…といった調子で、だんだんと使い勝手が悪く感じてくるようになりました。

といってもFirefox本体が悪いと言うより、むしろアドオンの入れ過ぎだったり、タブ開きまくりだったり、(ブラウザを)起動しっぱなしだったり。。。といったことが原因になっているのだと思います。
(しかし便利なアドオンはどれも捨てがたい)
そして他にも、アドオンのインストールやアンインストール、無効化をするにはブラウザの再起動が必要で、アドオンのアップデートが入る度に再起動しなければならないので、そこも面倒くさいなーと思うところでした。

そこで思い切ってGoogle Chromeに乗り換えることにしました。

Chromeに変える理由は、

  • 動作が軽いらしい


  • (ブラウジングとJavascriptエンジンが)早いらしい


  • W3C準拠なので大抵のサイトは問題なく表示できる


  • HTML5に対応(現段階では一部)


  • 開発が盛ん


  • I♥Google


  • という理由なんですが、これOperaでも同じじゃね?ってところですが、個人的には一番下の理由ってのもあります。
    ちなみにOperaは嫌いじゃないです、むしろ好きな方です。これでもかと言うほどW3Cに準拠してて、Web屋さんとしては嬉しい限りなブラウザ。
    なのだけれども、使い慣れないというのもありこっちになっちゃいました。向こうの方がブラウザの歴史も長いんですけどね。


    さて、移行をするにはいくつか現在の環境からもってこないと不便です。
    1から環境を作り直していって、自分にしっくりしたものを作り上げていくのもいいですが、やっぱりなるべく慣れてる環境の方が作業効率もいいし、アレがないコレがないとイライラすることもなくなりますしね。



    ブックマーク

    ブラウザのブックマークなどは各ブラウザが実装してるインポート機能で持ってくればどうにでもなりそうだけど、それほど使っていなかったのでここはまっさらなまま移行。

    アドオン / Extension

    あとはFirefoxで使っていたアドオンと同じような機能をもつExtensionを探してきて入れて、一部のグリモンもそのままインストールし直すことで移行できたけど、それでも一部のグリモンはどうしても動かなかったので、それはExtensionなどで代替になりそうなものを探してカバー。
    それでもなかったら…対応されるのを待つか諦める。
    自分でどうにかできそうならグリモン書き換えるのもありだろうけど、面倒だったのとそこまで困らないものだったので放置。


    Chromeのよい点


  • とにかく早い


  • 本体のアップデートは自動的に行われ、任意のタイミングで終了または再起動したときに最新版になっている!


  • Extensionのインストール、アンインストール、アップデート、無効化はブラウザの再起動無しで行える


  • Googleアカウントを紐づけることで、どこの環境で使っても常に同じ環境で使うことが出来る!


  • 各ブラウザタブがそれぞれ独立したプロセスとして動作している→一部のタブで反応がなくなっても他のタブは生きている。


  • Extensionなしに、ブラウザだけでGreasemonkeyスクリプトに対応している。


  • Web開発に最適!


    • Webデバッグツールが標準で付属する!

      • Windows版ならCtrl+Shift+I、Macなら⌘(command)+option(alt)+Iで起動

      • →Firebug相当のデバッグツールがWebKit標準で組み込まれているためFirebugいらず!(コレとは別にChrome用Firebugも存在します)

      • →このデバッグツールの嬉しいところは、デバッグツールから編集したHTMLやCSSの結果がその場で即時画面に反映されて確認できること。わざわざHTMLの書き換え→リロードといった手間も省けます。


    • WebKitベースなのでiPhoneやAndroid向けサイトの確認もばっちり!

    • HTML5に対応している。→現時点での実装はOperaには負けますが...



  • メモリ管理がすばらしい


    • 参照されていないタブ管理のメモリ消費を抑える


    • しばらく閲覧していないタブはメモリ上から解放し、次に閲覧されたタイミングでキャッシュから表示する。
        →Firefoxでもアドオンを使えば同等の事は再現できるが、Chromeはこれがデフォルトで行われる。



  • ブラウザの機能毎のPCリソース使用率が分かりやすい。


    • タブやExtensionでそれぞれで利用しているメモリやCPUの割合をちゃんと管理しているので、どの部分でどれだけリソースを消費してるかがタスクマネージャですぐに分かる。

    • それぞれがどの処理(JavaScriptの処理や画像や各スクリプトのキャッシュなど)においてメモリやCPUリソースを消費しているのかまでが分かる。


    Chromeの設定画面からGoogleアカウントでログインし紐付けることで、アカウントごとにChrome利用環境を同期させることができます。




    Chromeの微妙な点


  • 起動するだけでプロセスが大量に立ち上がる


  • いつの間にかバージョンアップされている


    • バージョンアップというものをユーザに全く意識させない。反面、ユーザに選択肢がゆだねられていない。

    • → 過去のバージョンを使い続けたかったとしてもそれが行えない。



  • Firefoxに比べてExtensionが少ない。


    • → これはしょうが無いかなぁ。とはいえ、今ではだいぶその数も増えてきているし、今後は同等程度に増えてくる可能性は大いにある。



  • 時々プロセスが暴走し、全体的に停止する。。。


    • → これは僕が開発版であるDevChannel版を使っているせいかもしれないですが、たまにあります。

    • ただほかのブラウザが全停止して再起動する頻度に比べればこのケースは少ないと思います。




    そんなわけで、現在はChromeに乗り換えて開発も閲覧もとても快適に過ごしてます。
    Throw away Firefox, Let’s enjoy the web with Chrome !!

    テスト用の簡易SMTPサーバをPythonで作る

    メール送信処理のテストをしたいのだけれど、わざわざテスト用のメールサーバを用意するのも面倒。
    そんな時に便利なテスト用サーバを簡単に作る方法。

    以下のコードを記述し、Pythonで実行するだけ。


    pythonコマンドで上記スクリプトを実行してコマンドプロンプトまたはターミナルに待機させておくだけ。

    あとはローカル環境からメール送信を実行すると、インターネット上のメールサーバに行かず、送信されたメールは、例え宛先が実在するドメイン名、ホスト名、アカウント名であっても、すべて上記のスクリプト側でキャッチされ、外(インターネット)へは行きません。

    キャッチされたメールの内容は画面に出力されていきます。

    なのでスパムメール送信処理のテストにはもってk
    ループ処理などで一斉にメール送信をする処理のテストであっても、誰にも迷惑をかけずテストをすることが出来ます。

    以下の記事から引用
    テスト用のオレオレSMTPサーバー - Watanabe.Tの日記
    http://d.hatena.ne.jp/watanabe_t/20080808/1218175319

    すごく便利だったのですが、だいぶ前に元記事が消えてしまっていた(この方のアカウント毎無くなっていた)ので、Webアーカイブから引っ張ってきて紹介。(もし問題があるようでしたらこの記事も消します)

    初めてはてブホッテントリに入って分かったこと。

    約1ヶ月前の先月末(2011年1月30日)、僕がこの記事を書いたことにより、僕が今までに経験たことがないことが起こった。

    280を超えるはてブ数、そしてTwitterからの大量のアクセスだった。

    今までそれほどの注目を集めるようなことをしたことがなかった僕は、この事態に驚きつつも、それだけの注目を受けたことに少しばかり嬉しさがあった。
    しかしその反面で、ウェブサイトを運営するに辺り、やってはいけないことに直面する。

    アクセス集中によるサーバの過負荷と、それによる接続障害

    接続障害と書くと少々大げさな気もするが、要はサーバが大量のアクセスを捌ききれなくなり、応答を返せなくなってしまっていた。
    ブログの記事を書いたのが深夜。と同時にTwitterとFacebookにその記事を流した。
    しばらく様子を見ていたものの、特にいつもと変わらない状況であったため、そのまま眠りについた。

    そして翌朝、目が覚めるとブログが表示できない。そう、いつの間にか注目を浴びることとなっていた。
    正直どのタイミングから、どのタイミングでそんなに人が流れてきていたかは分からないが、おそらくはTwitterだろう。
    ブログ投稿時には、他にもいくつかのブログフィードにPingを送っていたのでそちらからかもしれない。

    で、そんなことより朝出勤前から繋がらない。
    これでは仕方が無いので、まずは状況を確認。別なサーバに設置していたmuninと、ターミナルからSSHでサーバに入り、重い中どうにかtopコマンドやfreeコマンドなどで状況を確認。Load Averageがひどいことになっている。さらにSWAPが発生しまくっていたことから、メモリSWAPが原因でLAが高くなり、繋がらなくなったとわかる。
    まず原因として一番はApache、そしてMySQL。なのでとりあえずこの2つを再起動し、状況が治まってきたことを確認し、まずは出勤した。

    稼働環境

    現在のこのブログ及び僕が運用しているいくつかのウェブサイトは、すべて同一の環境下で動いてる。
    その環境とは…

    サーバ: さくらのVPS
    CPU: Core2 Duo 2.4GHz (/proc/cpuinfo の情報に基づく)
    メモリ: 512MB
    サーバOS: CentOS 5.5
    ブログシステム: Wordpress 3.0.4_ja
    HTTPD: Apache 2.2.x
    PHP: 5.3.x
    MySQL: 5.1.5x

    上記がすべて1つの仮想マシン上で稼動している。


    結果

    結果的にはWordpressが参照するDBへの同時接続が多くなり、(またMySQLの設定も動作環境に適していなかった)接続が溜りったことにより(?)SWAPが大量に発生し、LAが上昇するという事になっていたようだ。
    また、キャッシュ機構はMySQL側にもPHPにもWordpressにもそれぞれ有効にしていたが、それでも足りなかったか、Wordpressのキャッシュ機構を適切に設定出来ていなかったため、急激なアクセス増に対して一気に許容範を超え、負荷が上昇することが、その日のうちに度々発生していた。

    一番まずかったのは、その日は仕事中のこともあり、接続できない状態を分かりつつもしばらく対応できない状態が2時間ほど続いたとき、さてサーバにログインし、Apacheの再起動を…と思っていると、ログイン出来ない。それどころか繋がらない(応答しない)。
    muninのグラフを見てもチョチョ切れでもはや計測不能。ただし負荷がかかっていることはその前後にかろうじて観測できたグラフから確認できていた。

    さくらのVPSの管理画面からシリアルコンソールでつなごうとしても反応がない。仕方が無いのでサーバマシン(仮想)を強制再起動しました。その後再起動をし、無事事無きを得ました。

    完全に個人用途で趣味のため、大したウェブサービスが乗っているわけじゃないものの、仕事柄なのか少し焦りました。
    あと、別に広告貼ってたりしてるわけじゃないけど、せっかくのアクセスが機会損失になるのも嫌だし、なによりブログを見に来てくれているにもかかわらずつながらなくて見れないのはやっぱり失礼ですしね。




    TwitterにURLを流して気付くこと

    これはアクセスログをリアルタイムに見ていて気づいたこと。
    時間帯も影響するかもしれないが、TwitterにURLを流した瞬間に、まず多数のURL収集ボットがやってくる。
    今回深夜にURLを流した際はそれほど来なかったが、以前日中に流してみたときは、ドッと複数のURL収集ボット?がやってきた。それらはおそらくUserStreamを常に監視してURLが流れてくるとその先をクロールし、情報を取得してくるのだろう。

    さらに誰かがRTした瞬間に、急激にアクセスが集中する。RTされたタイミングで多くの人がアクセスするのと、自動的にリンク先URLを巡回するクライアント(短縮URLの展開機能?)やボットによってたくさんのアクセスが本当に短時間で集中することになる。
    これらによって本当に何度も処理仕切れなくなって応答を返せなくなっていた。

    なにが言いたいかというとTwitter怖い。


    結論

    スラッシュドットジャパンにも紹介されたりもしましたが、今回においてはスラッシュドット効果よりもはてブ効果と、何よりTwitterによる瞬間的なTwitter効果が怖かったです。

    そんなわけで、ブログというものはそれ専門で運用している外部のサービスにおいて運用していた方が、安全安心だなと思った次第でした。
    (この間のはたまたま集中しただけなので、多分このブログはしばらく動かさないと思います。)

    ウェブページをリニューアルしました+近況

    かなり久しぶりのブログ更新です。 タイトルの通りですが、約6年ぶりにウェブページを刷新しました。 ウェブページを更新しました 前回は2018年頃に、Zend Frameworkをベースに作っていたのをLaravelベースのサーバーに置き換え、AppEngineで動かす形にしていま...