スキップしてメイン コンテンツに移動

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 !!

    コメント

    このブログの人気の投稿

    さくらのクラウドでマストドンのインスタンスをサブドメインで作る

    タイトルに「の」と「で」が多すぎますが気にせずいきますこんばんは。

    さくらのクラウドで、いま話題のMastodon(マストドン)のインスタンスを作成してみました。
    Mastodonは普通にソースを展開して自分で普通にセットアップする方法や、Docker-composeを用いた方法などがありますが、さくらのクラウドでは、スタートアップスクリプトを用いて、管理画面から必要な項目を入力、スクリプトを選択するだけで簡単に立ち上げることができるようになっています。

    さくらのクラウドのMastodonスタートアップスクリプト 実は少し前にこの方法で立ち上げたりもしていたのですが、本当に簡単でサクサクできてもの自体は30分程度で完了します。
    管理者ユーザーを作成するには、通常のユーザー登録と同じ手順で画面からユーザーを作成後、一度コンソールからログインして、mastodonユーザーで下記のコマンドを実行する必要があります。

    # su - mastodon % cd ~/live % bundle install % RAILS_ENV=production bundle exec rails mastodon:confirm_email USER_EMAIL=登録時のメールアドレス % RAILS_ENV=production bundle exec rails mastodon:make_admin USERNAME=作成したユーザーID mastodon:confirm_email でメール受信確認をスキップして承認済みに、mastodon:make_admin で指定したユーザーを管理者に設定します。

    これでインスタンス管理者として様々な操作をGUI上から行えます。

    同類の記事は恐らく既にたくさんあるので、詳しい作り方に関してはそちらを参考にしてください。

    気になるところが 上記のさくらのクラウドニュース内で記載されているMastodonスタートアップスクリプトでの構築方法に関する記事内で、一つ気になるところがありました。
    それが
    ※サブドメイン(例:mstdn.example.com)には対応していません。 という記述部分です。

    つまり、このスタートアップスクリプトを利用した場合、サービス専用のドメインを用意する必要があります。
    既存のドメインをなるべく利用したい場合には向…

    iPhone7はApple Payでゲーム系ICカードとしても使えるか?

    先日発売されたiPhone7をはじめiPhone6以降の機種で、日本でもようやく、Apple Payが使えるようになりました。
    iPhone7は長年ユーザーが待ち望んできた防水対応もさることながら、日本向けiPhone7/7 Plusでは、NFCだけでなくFeliCaを搭載し、Apple PayではJR東日本のモバイルSuicaやEdyが使える、というのが今回の注目にもなりました。
    Apple Payが始まることで、こちらも日本のユーザーが待ち望んでいたモバイルSuicaをはじめとする、国内の様々な場所で使われている非接触IC系サービスの恩恵を受けられるようになります。



    ということは、非接触系ICカードを利用している場所の一つである、ゲームセンター。ここにある数々のゲーム筐体、最近では非接触ICカードリーダーが備え付けられていて、独自の電子マネー機能を持ち合わせたり、カード情報を読み取ってプレイヤーのプレイデータを読み込むのに使用されたりしています。これらは果たしてiPhone7でも使えるのか…。
    検証
    まず、現在国内で主流の非接触IC系ゲームプレイカード(以下、プレイカード)は下記の種類があります。

    e-AMUSEMENT PASS (コナミ)
    Aime (セガ)
    バナパスポート (バンダイナムコ)
    NESiCA (タイトー)
    ※これ以外にもあるかもしれませんが、自分が主に音ゲーを好んでやるため、音ゲー機種が出ているサービスのみを対象にしています。

    これらのサービスに対応する機種でiPhone7のApple Payが使えるか検証してみます。

    PHPで相対パスから絶対URL(URI)を作成する

    HTMLページをパースしてURLを取り出す処理を書いていたのですが、ページ内のリンクなどが全部絶対URLで記述されていれば非常に楽なのですが、現実としてそうでもなく、ページによっては相対パスで書かれていたりして、正規表現で偏にリンクからURLを抜き出すだけではうまくできませんでした。

    そこで少しググってみたら

    PHPで相対パスから絶対URL(URI)を作成する|PHPプログラムメモ|プログラムメモ

    という記事を発見!おぉ、これは便利!
    と思って使わせてもらおうと思ったのですが、いくつかテストしてみて、相対パス処理で不備があるなーと思ったところがあったのでちょっと改良させてもらいました。

    37~38行目は正直いらない気がしたのですが、 PHP 5.3 のCLIでWindows上でテストした際に、なぜか \/ (アルファベットのVではなく、\/ ) で出力されたのが気になったので、無駄かもしれないけどあえて記述。
    あと $parse の初期化もここまでする必要ないけど、念のためNotice対策を…w

    相対パスから絶対URLする関数

    < ?php
    /**
    * 相対パスから絶対URLを返します
    *
    * @param string $base ベースURL(絶対URL)
    * @param string $relational_path 相対パス
    * @return string 相対パスの絶対URL
    * @link http://blog.anoncom.net/2010/01/08/295.html
    * @link http://logic.stepserver.jp/data/archives/501.html
    */
    function createUri( $base = '', $relational_path = '' ) {

    $parse = array (
    'scheme' => null,
    'user' => null,
    'pass' => null,
    'host' => null,
    'port' => null,
    'path' => null,
    'query' => …