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効果が怖かったです。

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

    訴えられそうになった話:経緯、思ったこと、反省点、経過など

    今回、ブログに公開したことによって、様々な意見や考え方に触れることできた。

    しょうがないねとか、嫌だなーとか、もっと粘ってふんだくればいいのにとか、そんな商標権にそこまで権利ないよとか。
    あまり例にない事と言うことや、話題性の高いTwitter上でのトラブルと言うこともあり、色々とあちこちで意見やコメントを見せてもらいました。


    経緯

    で、なんで僕は今回応じるようにしたのか。

    簡単に言ってしまうと、僕は頭悪いし法的な知識はまるでない。そして面倒くさがりである。なのでアカウントIDを譲った。

    それにそんな状態で下手に争って負けて変な前例作ったら、みんなに大バッシングくらいそうだし。例え勝てたり和解で終わったとしても弁護士費用の方が高そうだしそんなお金ないし。
    というか、それ以前に今後このような事例が増えるようなことにもなって欲しくない。
    また、一個人がインターネットにおいて自由にアカウントIDすら使えなくなってしまうことは無論望んでない。
    ただし、もちろん他人の権利(法的に保護されているものもそうでないものも)を意図的に侵害するのは論外。

    とかなんとかいうのは後付けの理由で、僕なりにちゃんとした理由がある。
    最初に挙げたとおり、面倒事はゴメン被りたいというのも一つの理由である。


    いちいち法廷でとか書面でとか対応するのは流石に面倒ゴメンだし、前回書いたとおり、たかがウェブサービスのアカウントIDだ。
    ぶっちゃけて、何かの拍子にTwitterがサービス終了したり、なくなってしまえばそれで終わりなだけ。
    いま、誰が見てもTwitterのサービスそのものには価値はあれど、Twitter上のアカウントIDに価値があるのかと言えば、それぞれの使われ方や気に入り方次第だと思うけれど、一般的にはそんなものは正直皆無。あったとしても、ドメイン名などのパブリックなものと比べれば全然大したものじゃないと思っている。
    で、そんなものに対して金品を対価として相手に提供してまで欲しいというなら、僕は逆に美味しいと感じた。

    たとえばTwitterではなく、別のウェブサービスだったとしよう。
    「君のYahoo!のアカウントID良いね、いくら払うからそれちょうだい」
    「君のBloggerのアカウントID良いね、iTunesギフトカードあげるからそのアカウントちょうだい!」
    というのと道理は同じであると考えている。
    これもYahoo!やBloggerのサービスがなくなってしまえばそれまでの話。(おそらくは数年以上の単位で、そんなことはないと思うけど)

    これがドメイン名だとした場合、ドメイン名が勝手に消失する可能性は、WWWのドメイン名ベースでのアドレス解決を行う構造でも代わらない限りない。あるいは登録者自身の不手際でもない限り、消失することはほぼない。

    というわけで、アカウントID云々で手間をかけるには、僕はそれほど価値がないと考えているのと、そこに対して金銭的価値を見いだしてくれる人がいるなら、それが僅かであってもこちらにとってはおいしい。



    もう一つ。
    今回はAnonymizer, Inc.の社長から直接メールで連絡が来た。
    どのように僕のメールアドレスを知ったかは知らないけれど、僕はメールアドレスを各所に公開していたので、アカウントから照会ページのリンクでも辿って連絡を付けたのだろう。

    そんなことはさておき、今回の件をTwitterの運営元であるTwitter社経由で行っていた場合どうなっていたか。

    このページによると、先方も色々手順を踏んでいかなければならなそうだが、最悪の場合、僕のTwitterアカウントはTwitterによって突如凍結されていた可能性もある。

    といっても、(恐らく)Twitter側も相当悪質なケースを除いていきなり行ってくるとは思わないが、僕はTwitterをかなり利用しているし、万が一にも突然アカウントを凍結されてしまうのは正直辛い。
    なので、それが行われなかっただけでも僕はよかったと思っている。




    あとになって思ったこと、反省点

    反省点としては、まず向こうの要求に応じる応じないはさておき、一旦連絡してもう少し考える時間をもらうこともできたかなと。
    1週間ですべてを決断しろとまではメールでも書いてなかった。(が、提示条件をのんで対応する意志があるなら1週間以内に対応しろとは書いてあった。)返信がなければ法的に権利を主張する(出るとこ出る)よ。とはあったけど。

    ただ、相手が提示する条件を受けるには、結局のところ1週間以内で意志決定し、(ないよりマシ程度にいい条件を取るなら)対応をせざるを得なかったのかなーというのは事実。

    でもね、そんなに欲しいアカウントIDを、Twitterサービス開始から4〜5年経ってしばらくしてからひょこひょこやってきて、お前のそれ、ウチの名前だから。勝手に使ってるなよ、おとなしく寄こさないなら訴えることもあるからな。
    っていうのもなんかなーと思うんです。
    やろうと思えばサービス開始時にでもアカウントを取ることはできたわけで。
    少なくとも日本でTwitterが注目され始めたのは、Twitterのベータサービス開始(2006年7月)から半年〜1年後だったとみてる。(自分を含め、古くから利用している日本人ユーザのアカウント登録日から推測)
    あと商標権が、他者のウェブサービスにおけるアカウントIDにまで範囲が及ぶのも正直微妙。

    ただ、上にも書いたとおり、Twitterの利用規約的にはアウトっぽいのもあったので、下手に争ってアカウント丸々凍結されたら、この場合そっちの方が怖い。


    経過について

    そんなこんなで最初の連絡を受けてから既に1週間経った訳ですが、向こうから連絡が来たのは最初のメールと、その後僕が一度質問を送ったものへの回答メールの2回のみ。

    2回目に来たメールには、今度は丁寧な英語で回答が返ってきた(僕が質問を英語で送っていたので)。
    そのメールには「アカウント変更したら改めて教えてね。そしたら、ウチのサービスを君に提供する準備するから。で、そのとき登録に必要だから、君の情報(メールアドレスとかその程度)教えてね。登録できたらその情報も送るから。」と書かれていた。
    その後改めて、こちらから「アカウント変更したので確認とかアカウント名の取得とかよろしくね」と返信したものの、以降連絡が来なくなってしまった。

    もしかしたら忙しい社長さんなのかも知れないが、せめて1週間以内でという指定で要求してきたのであれば、なおさら素早く対応してくれても良いと思うのは日本人だからですかね。。。

    一昨日に改めて催促のメールも送ってみたけれど、これでまた何も連絡なかったら、ちょっとはこっちも強気に要求してもいいよね。

    後日談
    その後、催促してみたり何度かメールを交わして、最初にメールでもらっていたとおり、最後まできちんと対応してもらいました。

    NGINXのSecureLinkモジュールを使ってみる

    突然ですが SecureLinkモジュール とはなんぞや、というところですが、簡単に言うと、サービス登録時のメールアドレス確認で、下記の様なメールで見たことがあるような、一定時間のみ有効な時限式URLの認証機能を提供するモジュールです。 通常このような機能を作成する場...