Posts tagged ‘Google’

Chromebook を手に入れた

以前から気になっていた Chromebook をついに購入してしまった。国内では法人向けの販売に続いて個人向けの販売も始まっている。購入にあたって英字配列キーボードを必須としたが、現時点で英字配列キーボードを搭載している機種は ASUS C300MA(カラーバージョン) しかなく、しかもこれらはメモリが2GBしかない。他の機種が概ね4GBになっている状況で2GBでは先々がちょっと不安。というわけで国内正規版の入手を諦め、amazon.com 経由で東芝製の CB35-B3340 というモデルを購入した。本体価格は$279で送料その他諸々含めて、合計$327.45。実際に日本円で支払ったのは40,039円だった。同程度のスペックの国内正規品が概ね3万円台後半の値付けになっていることを考えると、この価格は悪くない買い物だったと思う。

20141220_124840

TOSHIBA CB35-B3340 (購入機種) ASUS C300-MA (参考)
CPU Celeron N2840 2.16GHz Celeron N2830 2.16GHz
メモリ 4GB DDR3 1600MHz 4GB DDR3 1333MHz
ディスプレイ 13.1 inches 1,920 x 1,080 13.1 inched 1,366 x 768
外部記憶域 16GB eMMC 16GB eMMC
バッテリ駆動時間 約9時間 約10時間
重量 約1.3Kg 約1.4Kg
価格 40,039円(送料等込) 39,744円(amazon.co.jp)

IMG_20141220_125154

筐体については値段相応で plasticky 感が強いのだが、そのことが逆に気楽に使える道具の印象となっていて個人的には嫌いではない。PC としての使い勝手については、ほかのブログなどでも書かれているように、良くも悪くも Chrome ブラウザしか動作しないノートPCということに尽きる。従って普段から Google 提供の各種サービスを使っているユーザでないと Chromebook を持つ意味はないかもしれない。しかし、GmailやGoogleカレンダーだけでなく文書作成からプログラミング作業の一部までを Chrome ブラウザ環境でまかなっている状況では、有用なモバイルツールになる。実際、自分の場合もメールはもちろん、ドキュメント作成のかなりの部分を Google に依存しており、加えてシステム開発の一部もブラウザ経由で作業しているため、起動が早くてバッテリの持ちも良い Chromebook は重宝している。

Chrome の不具合

10日ほど前からだったか、Windows7 64bit 環境でChromeが変な動きをするようになった。まず、Chrome上で文字入力するとき、文字の表示やバックスペースが極端に遅くなる。また、マウスクリックやホイールの動きに画面が追いつけないような状態になる。これらの現象が特にGmailとGoogle Driveまわりで顕著だった。

当初はChromeの拡張機能に原因があるのかと思い、キーボードやマウスの入力に絡みそうな拡張機能を無効にするなどしてみたが解決出来なかった。とにかく文字入力の効率が極端に落ちるためストレスが溜まる一方で、常用ブラウザをFirefoxへ変えないとならないかなぁと、ここ数日は落ち込み気味だった。

それでも暇を見つけては情報収集していたら、Googleプロダクトフォーラムで解決策にたどり着くことができた。原因はグラフィックドライバだった。手元の環境のディスプレイアダプタはAMD Radeon HD5750で、このドライバを最新のものにしたら、見事に問題が解消した。

https://productforums.google.com/forum/#!topic/gmail-ja/N8F0o2t08ig
https://productforums.google.com/forum/#!category-topic/chrome-ja/6x3uRPTmUtE

最新版のドライバは次のところで入手可能。

http://support.amd.com/ja-jp

AMDのサポートサイトには、既存ドライバ関連ファイルを削除してから新しいのをインストールするように、みたいな記述があったのだが、そういった事前準備することなくダウンロードしたインストーラをすぐに実行したところ、いまのところ問題なく動作している模様。Chromeの状態もトラブル発生以前のように快適に動作している。

パソコン自作していた頃は、グラフィックドライバなどのバージョンアップ情報はいつもフォローしていて、最新版が出たら速攻でバージョンアップして悦に入っていたけれど、最近ではもうそのあたりは完全にほったらかし状態で、今回の件ではドライバのバージョンがすごく上がっていたことや、ATIブランドがいつのまにか完全にAMDになっていたことなんかも、全然知らなかった。

majordomo におけるフッタ追加機能

運用の管理を担当しているメーリングリストで、このところ文字化けの問い合わせが増えてきた。調べてみたところ majordomo がメール本文に追加するフッタ文字列が原因らしい。majordomo は本文のエンコード状況に関わらず、そのままプレーンテキストのフッタを追加しているようだ。そのため本文がプレーンテキストでない場合、本文中には複数のエンコーディングが混在してしまうが、マルチパート用にメールヘッダを書き直すことはしない。そして結果的に受け取り側メールクライアントによっては、正しく表示できない状況が発生する。

ここのメーリングリストには、ほとんどプレーンテキストしか流れていなかったので、これまでは問題にならなかった。しかし、プレーンテキストにも関わらずエンコードされたメールが、最近発信されるようになったため不具合が顕在化してきた。ちなみに問題のメールのヘッダはこんな感じになっている。

Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: base64

このようなデータであっても、大抵のメールクライアントはエンコード部分をデコードしてくれて、なんの問題も無く読めてしまう。もっとも majordomo が追加したフッタの表示はおかしくなっていたり、まったく表示されなかったりするのだが、本文が読めているため気付きにくくなっている。ところが Gmail でこのメールを表示させると、肝心の本文部分のデコードは行われずにエンコードされたままのテキストが表示される。不具合の問い合わせをしてきた利用者も Gmail を使っていた。

結局、これまでフッタに追加していた情報は、それほど重要なものではなかったので、majordomo におけるフッタ追加の機能を無効にすることで、この不具合を回避することにした。

ところで、そもそもこの不具合に気付いたのは、単純なプレーンテキストがわざわざエンコードされてきたからだった。実はこれにも Gmail が絡んでいた。Gmail に限らずいわゆる Web メールの GUI でメール本文を入力するとき、利用者が改行を入力するまでいくらでも長い文字列を1行として入力できてしまう。このような本文を書いて送信すると、Gmail はどうも自動的に base64 でエンコードするようだ。この仕様はたぶん間違っていないと思う。ちなみに文字コードに utf-8 を指定している場合は、行の長さに関係なく無条件にエンコードされるようだ。

これからはどう考えてもエンコードされたマルチパートで構成されるメールが増えてくるだろうから、majordomo では対応しきれなくなってくるだろう。今回のようにメーリングリストの中継点でメール本文にヘッダやフッタを追加するには、送られてきたメール本文のエンコード状況を解析し、マルチパート化するような処理をしなければいけないのだと思う。最近はあまりメーリングリストに関する技術情報が出回っていないような気がするが、Mailman だったらこんな要求に対しても対応できるのだろうか。この際だからいっそのこと Google Groups のような既存の無料メーリングリスト・サービスなどに身を委ねてしまえば楽になれるのかもしれない。

Amazon Elastic MapReduce というサービス

Amazon が Elastic MapReduce というサービスをリリースした。これは Google の中核を形成する大規模分散並列計算システムを模したもので、オープンソースの Hadoop によりサービスが提供されている。Hadoop は Apache Hadoop プロジェクトにより公開されているオープンソースソフトウェアで、Google が発表した MapReduce に関する技術論文に基づいて実装されたものだ。この MapReduce が EC2 や S3 と同様の価格体系で利用することができる。かなり画期的なことなので、開発関係者などの間ではしばらく話題になると思う。このようなサービスが普及するほど、既存のデータセンターあたりは厳しい状況になるだろうと素人は考えるのだが、そういった筋からの噂によると、それほど危機感を持っていないらしい。セキュリティだとか会社の信用といった面で、まだ自分たちのほうが優位にいると考えているらしい。本当にそうなのだろうか。