So-net無料ブログ作成
検索選択
ソフトウェア/PC関係 ブログトップ
前の10件 | 次の10件

Windows 7のガジェットが密かに廃止になっていた... [ソフトウェア/PC関係]

WESTERN DIGITAL 3.5インチ内蔵HDD 3TB SATA6.0Gb/s IntelliPower 64MB GP1000S WD30EZRX-1TBP
3TB HDDのGB単価が安い。こちらはWestern DigitalのWD30EZRX

週末,遂に決心して,TV録画マシン1台をWindows 7に入れ替えた。その最大の理由は,HDDの価格だ。GPTをサポートしない32bit XPでは,2TBが限界。しかし2TB HDDの価格は,円安もあってかじわじわ上昇し,今や1GB単価が約4円。かたや,現在最安と思われる3TB HDDは,1GB単価が約3.5円。2TB HDDは,同容量で計算すると1000円ほど割高ということになる。これは意外と馬鹿にならない差である。もとより貧乏症の私としては,どうせ買うなら3TBの方を買いたい。でも32bit XPでは使えない。

とは言え,当面はまだなんとかなる。GPTをサポートしている別のPCの2TB HDDを3TBに置き換え,それを流用すればよいのだ。実は,これまでも数回同じことをしてきた。しかし,それも残りはあと2台。これまでのペースで考えると,早ければあと半年ほどしか持たない計算だ。そろそろ潮時ということかも知れない。

そんな訳で,元のXPは残したまま,別のパーティションにWindows 7をインストール。TV録画マシンは安定性が命なので,元々必要最小限のソフトしかインストールしていなかったため,ほぼ同等の環境をセットアップするのに,それほど時間はかからなかった。録画ソフトの動作も問題はない様子。まずはめでたし。これで今後は,3TB HDDに録画データを保存できる。XPに限らず,GPTに対応していない機器はまだあるので,2TBが望ましいのは変わらないのだが,まぁ仕方がない。これも時代の流れというものだろう。

ところでこのマシン,他のマシンと同様,普段は5分放置すると,自動的にスリープに移行するようになっている。TV録画だけならこれで問題ないのだが,このマシンはメディア・サーバーとしても使用している。PS3からこれに接続して,動画を視聴している時に,スリープに移行してしまっては具合が悪い。そのため,動画視聴時にはスリープしないように,電源オプションを変更しておく必要があるのだ。ところが,XPには存在した,電源オプション変更のためのタスク・トレイのツールが,Windows 7ではなくなってしまったのである。こういうところ,Microsoftはまことに気が利かない。

これは別のWindows 7マシンをセットアップした時にも経験していて,結果的に「ガジェット」を使うことで解決していた。そこで,今回も同じガジェットを登録しようと,「オンラインで追加のガジェットを取得」を実行してみると,ブラウザが立ち上がって,なんとも衝撃的なメッセージが! 「ガジェットは廃止になりました」。何? そんなニュースあったっけ。調べてみたところ,もう1年近く前には廃止になっていたらしい。セキュリティ上の理由とのこと。う~む,困った。

デスクトップに「電源オプション」のショートカットを置いておけば,切り替えにさほど手間はかからないのだが,今までのワンタッチと比べると,だいぶ面倒な気分になる。自分でプログラムを書くのはかなり面倒臭いし(そもそも,最近Windowsのネイティブ・アプリを書いてない...)。という訳で,あれこれ調べて,次善策を考えついたのだが,ここまで前置きが長くなってしまったので,続きは次回。


crontabの罠 [ソフトウェア/PC関係]

Linuxで,タスクをスケジュール実行するのに使用するcron。cronの設定をするのに,crontabというコマンドが使える。しかし,こいつが意外と曲者

crontabで現在の設定を見るには,

crontab -l

とlオプションを使う。編集するには

crontab -e

とeオプションを使う。ところが,rオプションというのがあって,

crontab -r

とやると,設定が綺麗さっぱり消えてしまう。「r」は「e」の隣にあるから,打ち間違えると大変だ。そんな訳で,気を付けなければいけないというのは知っていた。実際,間違えてrオプションで実行してしまったことはない。ところが,罠はそれだけではなかった。

私がやってしまったのは

crontab

つまり,オプションを付け忘れて実行してしまったのだ。後から思えば,ここまでならまだ良かった。しかし,問題はその後だった。何も表示されずに止まってしまったところで,オプションを付け忘れたのに気が付いたのだが,ここで何となくctrl-Dを押してしまったのである。そして,改めて,"crontab -l"を実行してみてびっくり。設定してあったはずのタスクがなくなってしまった。

何故こんなことになったのだろうか。crontabのmanual pageには,そもそも引数なしの形式が載っていないのだ。しかし怪しいのは,

crontab [ -u user ] file

という形式。crontabにファイル名を指定して実行すると,そのファイルの内容で設定を置き換えてしまうようになっている。そしてどうも,ファイル名を指定しないと,勝手に標準入力から読み込んでしまうようだ。manual pageには,擬似ファイル名として「-」を指定した時に標準入力から読み込む,と書いてあるのだが,「-」がなくても同じ動作をするっぽい。ここでctrl-Cを押せば,実行が中止されたものを,ctrl-D,つまりEOFを押してしまったために,標準入力から空のファイルを指定したことになってしまったのである。

なんで,「-」のない場合をエラーにしてくれなかったのだろう。咄嗟にctrl-Dを打ってしまうのは手癖のようなもので,単純なキーの打ち間違いとはちょっと違う。矯正しようと思っても,なかなか簡単にはいかないだろう。こういう罠にハマる人は他にはいないのだろうか。困ったものである。せめて確認メッセージを出して欲しかった。

因みに,Debianの古いバージョン(新しいのが手元にないので)では,引数なしの場合はUsageが表示された。


IAStorDataMgrSvcの謎 [ソフトウェア/PC関係]

なんだか奇妙な話。

メイン・マシンのWindows 7の動作が,どうも重いので,タスク・マネージャをチェックしてみた。[プロセス]タブで,「すべてのユーザーのプロセスを表示」を押してから,CPU利用率の高い順にソートしたところ,「IAStorDataMgrSvc.exe」というプロセスが,40%以上のCPUを食っている。しかも,一時的なものではなく,延々とCPUを食い続けているのだ。これじゃぁ,動作が重くなるはずである。で,一体これは何なのか。

「IA」って接頭辞からある程度想像は付いたのだが,取り敢えずプロセスのプロパティをチェックしてみると,「Intel(R) Rapid Storage Technology」というディレクトリの下にある実行ファイルだということが分かった。HDDのアクセスを高速化するらしい,Intel純正ユーティリティ(ドライバ)のひとつですな。しかし,高速化するためのものが,CPUを食い潰してしまうのでは本末転倒。以前はこんなことなかったはずなのに,どういうわけだろうか。

バージョンが古くなってしまったのかと思って,タスク・トレイのアイコンを見てみると,Rapid Storage Technology(以下,RST)のアイコンのツールチップに,"Not running"とか書かれている。おや? さらに,アイコンをクリックして出てくるメニューから,"Open Application"を選択すると,エラーになってアプリケーションが起動しない。これは一体どういうことなのか。

仕方ないので,新しいバージョンでもインストールしてみようと,最新のらしい,バージョン13.1.0.1058をダウンロードしてきた。ところが,実行してみると,.NET Framework 4.5が必要だという。ドライバのインストールごときのために,なんで.NET Frameworkの新しいバージョンなんてインストールしないといけないんだろう。釈然とはしないが,言われるままにインストールして,システムを再起動。もう一度RSTのインストーラを起動すると,「このプラットフォームはサポートされていません」だと。バカにしてるのか?

軽く殺意を覚えつつも,Readmeをチェック。デバイス・マネージャで,「Intel(R) SATA RAID controller」か「Intel(R) SATA AHCI controller」のどちらかがあるかチェックしろと? ところが,これが見当たらない。AHCIは,以前見たことがあったはずなのだが,今はどこにもない。AHCIで構成してあるはずなのに何故?

もしや,BIOSの設定がリセットされているのでは? ふと思い付いて,再起動し,BIOSの設定画面を開く。すると,あろうことか,SATAのモードが,AHCIではなくIDEになっていた...。恐らく,何かの時にBIOS設定がリセットされてしまったのだろう。デバイス・マネージャに出て来ない訳だ。早速,AHCIにセットし直して,再起動。タスク・トレイのアイコンのツールチップに"Not running"も出なくなり,アプリケーションも起動するようになった。タスク・マネージャのIAStorDataMgrSvc.exeも,ほとんどCPUを消費しなくなった。ひとまず一件落着...ではあるが,なんとも人騒がせな話である。

なお,RSTの最新バージョンは,AHCIを有効な状態にしてもインストールできなかった。原因は不明。まぁ,もはや必要もないので,良いのだけれど。結局,.NET Framework 4.5のインストールは,完全に余計な手間だったというわけで,ちょっと腹立たしくもあるが。。


Perlのunpack関数 [ソフトウェア/PC関係]

デジタル放送を録画したMPEG2 TSファイルを,ちょっと加工する必要が生じたので,以前書いたプログラムを引っ張り出して来た。TSファイルはバイナリ形式なので,そのプログラムはC++で書いてあったのだが,いちいちコンパイルして実行という手順が煩わしい。加えて,C++で書こうとすると,データ構造やらオブジェクト指向やら,ついついちゃんとしたデザインを考えようとしてしまって,これまた面倒臭い。一時的な目的を達成するためのやっつけプログラムなら,Perlで書く方が遥かに楽なのだ。最近はすっかりその楽さ加減に慣れ切ってしまっている状況。これも年齢のせいだろうか。

という訳で,元のC++プログラムをPerlで書き直すことにしたのだが,これがとても快適。仕様の理解があやふやなところがあるので,少しずつ変更して試してみるのに,スクリプト言語は便利である。これではますますC++に戻れない。

ところが,程なく問題に遭遇。予想していたことではあるが,処理が遅いのである。1つ約3GBのファイルの読み書きに,10分もかかってしまうのだ。数が少なければそれほど問題はないが,それが50個になると500分=8時間以上になる。やっぱりC++でないとダメなのだろうか。

そこで,C++とPerlの処理速度の比較をしてみることにした。まずは最も単純に,TSファイルをコピーするだけの処理。MPEG2 TSは,188バイトのパケットの集合体なので,それを順に読み込んでは,別ファイルへ書き出す。3GBのTSファイルだと,1500万回以上の繰り返し処理となる計算だ。これを,それぞれのプログラムで実行してみたところ,いずれも約3分と大きな違いはなかった。確かに,ファイルの読み書きは,PerlでもOSのシステム・コールを呼び出しているだけだろうから,C++とそれほど差がつくはずがない。

どこで時間を食っているのかを調べるために,Perlのプログラムに少しずつ肉付けをしていくことにした。しかし,意外にもすぐに原因が判明した。unpack関数である。スカラ変数に読み込んだ188バイトのTSパケット・データを,処理しやすくするために,unpack関数で配列に変換しているのだが,これに思いのほか時間がかかるようなのだ。試したプログラムは次のようなものである。

for(;;){
	my $buf;
	my $len = read(STDIN, $buf, 188);
	last unless defined($len);
	my @buf = unpack("C*", $buf);
	syswrite(STDOUT, $buf, $len);
}

この中で,unpackの行をコメントアウトして実行すると約3分,コメントを外すと約10分となる。つまり,その他の本質的な処理には,Perlでもあまり時間はかからず,unpackでほとんどの実行時間を食っているという訳だ。しかし,unpackを使わずに,どうやってバイナリ・データを処理すればよいのだろう。

これについての根本的な解決策は未だに不明。ただ,今回のケースに限っては対策が見つかった。ふと思い付いて,最初の5バイトだけをunpackするように変えて試してみたのである。

for(;;){
	my $buf;
	my $len = read(STDIN, $buf, 188);
	last unless defined($len);
	my @buf = unpack("C5", $buf);
	syswrite(STDOUT, $buf, $len);
}

すると,実行時間は3分強にまで激減。つまり,unpackの処理時間は,unpackするデータの数に依存するということだ。今回のケースでは,そもそも全てのTSパケットのデータをチェックする必要がなかった。TSパケットの最初の数バイトからパケットIDが分かるので,必要なパケットだけ,全体をunpackするようにしたところ,1ファイル当たり3分強程度で処理できるまでに改善された。ファイルの読み書きのバッファリングを工夫すれば,もっと高速化出来る可能性はあるが,取り敢えず現状はこれで充分である。

しかし,意外なところに落とし穴があるものだ。もしかしたら,Perl遣いの人には常識なのかもしれないが。とはいえ,全パケット処理しようとすると,やはり時間がかかるので,引き続き手はないものか調査してみるつもりである。


自動スタンバイにならない時は... [ソフトウェア/PC関係]

以前も書いたが,自室のWindowsマシンは,全て5分間操作しないと,自動的にスタンバイに入るように設定している。といっても,最近はほとんどVM環境に移行してしまったので,メイン・マシンと,2台のTV録画用マシン,計3台のみになってしまったが。ともかく,そのお陰で,作業した後ほったらかしておいても,勝手にスタンバイになってくれるので,多少なりとも省エネになっているはず。ところが,これが時々不調になることがある。何がきっかけなのか分からないが,気が付くと自動スタンバイにならなくなってしまうことがあるのだ。寝る前に作業していて,朝起きたら電源が入りっぱなしでびっくり,という具合だ。僅かな金額とはいえ,無駄な電気代がかかってしまったことに罪悪感を感じてしまうのである。

困るのは,自動スタンバイに入れない場合でも,画面に通知メッセージのようなものは何も表示されないということ。ただ黙々と電源オン状態を続けるだけなのだ。もちろん,いくつか明らかな原因に心当たりはある。例えば,リモート・デスクトップで,他のマシンに接続している場合など。実行中のプログラムが,処理の都合上,スタンバイや画面表示オフになってては困る場合,SetThreadExecutionStateというWindows APIを使って,システムに通知することが出来るようになっている。自動スタンバイにならない一般的な原因は,これだ。PCで映画を観ている時など,何も操作はしないが,画面が消えたり,スタンバイになっては困るケースはあるので,これは必要な機能なのである。しかし,どのプログラムがどの状態を設定しているのか,調べるためのAPIはどうもないようなのだ。仕方ないので,起動しているプログラムを1つ1つ終了したりして,原因を探すしかない。といっても,中にはシステムのプロセスもあるので,これがなかなか一筋縄ではいかない。

こうしたことは,最近に始まったことではないので,以前からいろいろ調べていたのだが,情報が見つかっていなかった。ところが,今日ふと思い付いてググってみたところ,なんと解決策が見つかった! 同じようなキーワードで検索したことは過去にもあったはずなのだが,何故今まで見つからなかったのは謎である。検索のアルゴリズムなども日々更新されているはずだから,有り得ることではあるのだが。

で,その肝心の解決策とは,Windowsに付属する,"powercfg"というコマンドだ。ハイバネーション(休止状態)を無効にするために,使ったことがある人もいるだろう。「powercfg -?」として,ヘルプを見てみると,様々な機能を持っていることが分かるのだが,今ひとつ説明が不十分なため,よく理解できていなかった。まさかそんな機能があったとは。

使ったことがない人もいるだろうから,一応説明しておくと,powercfgはコマンドラインのプログラムなので,コマンド・プロンプト内で実行する。但し,管理者権限が必要となるので,普通に実行したコマンド・プロンプトではダメ。スタート・メニューの「コマンドプロンプト」を右クリックして,「管理者として実行」を選んで起動する必要がある。そこでおもむろに

powercfg -requests

を実行する。すると

DISPLAY:
なし。

SYSTEM:
[SERVICE] \Device\HarddiskVolume1\Windows\System32\svchost.exe (CryptSvc)

AWAYMODE:
なし。

というような情報が表示されるはずだ。この中で「DISPLAY:」,「SYSTEM:」,「AWAYMODE:」というのが,SetThreadExecutionState APIに指定する,ES_DISPLAY_REQUIRED,ES_SYSTEM_REQUIRED,ES_AWAYMODE_REQUIREDに対応する。DISPLAYはディスプレイのアイドル・タイマー(タイマーが0になったら消灯する)をリセットするもの,SYSTEMはシステムのアイドル・タイマーをリセットするもの,AWAYMODEはバックグラウンドで時間のかかる処理をするものだ。つまり,ここに表示されているプログラムが,自動スタンバイを阻止しているという訳だ。

早速,当該マシンで実行してみたところ,あっさり原因が判明。うっかりと言えばそれまでなのだが,DaemonToolsに,ネットワーク・ドライブ上のISOイメージをマウントしたまま忘れていたのがまずかったようだ。アンマウントして再び実行したところ,全て「なし」に変わり,めでたく5分後にスタンバイに移行した。

因みに,上の例に出ている「CryptSvc」というサービスは,何者かはよく知らないが,リモート・デスクトップで接続されている側で実行されるものらしい。このお陰で,リモートから操作中に,勝手にスタンバイにならなくて済むのだろう。

今回は「powercfg -requests」だけで解決してしまったが,もっとややこしいケースにも対応できる方法がある。一つは,

powercfg -energy

というコマンドで,電源関係のより詳細な情報を収集して,結果をHTMLファイルに出力するものだ。そしてもう一つ,どうやっても「powercfg -requests」の結果が空にならない場合に,強制的にスタンバイ等にすることができるコマンドがある。それが

powercfg -requestsoverride <呼び出し元の種類> <名前> <要求>

「呼び出し元の種類」には「PROCESS」や「SERVICE」等を,「名前」にはそのプロセスやサービスの名前を指定する。これらは,「powercfg -requests」で表示されたものを使えば良い。<要求>には,「DISPLAY」,「SYSTEM」,「AWAYMODE」を指定する。これで,各プログラムが設定している状態を無視して,スタンバイ等に入るようにできるようだ。

とても頼もしいツールを手に入れた気分。他にもまだ,自分の知らない強力なツールが隠れているのかもしれないが,こうやってたまに新しい発見があるのも面白いものだ。


Windows8.1のアカウントをローカルに戻す [ソフトウェア/PC関係]

最近,メイン・マシンの調子が悪いので,予備のマシンの環境を整えておこうかと,久し振り(1年振りくらいか?)に電源を入れてみた。てっきりWindows 7がインストールしてあったと思ったのだが,なんと起動したのはWindows 8。インストールしたことすら忘れていた。

あまりWindows 8を常用したいとは思わないのだが,Windows 7を入れ直すのも面倒。完全に移行する訳ではないし,取り敢えず耐えられなくなるまで使ってみることにした。で,折角なので,まず8.1にアップグレード。

8から8.1には無償でアップグレード出来ると聞いていたのだが,どうやってやるのだろう。調べてみると,Windowsストアで出来るそうだ。実はWindowsストアを利用するのは初めて。(既にうろ覚えだが)ストアにアクセスしたら,「8.1にアップグレード出来ます」というようなメッセージが出たので,それにしたがって進めると,ダウンロードが始まった。時間がかかりそうなのでしばらく放っておいたら,アップグレードまであっさり終了。再起動を要求されるので,その通りにする。起動すると,初期セットアップが始った。たかがアップグレードなのに,何をそんなに設定することがあるのだろう,と不審に思いながらも,言われたままに情報を入力する。これが罠だった。セットアップが終了したら,ログインがMicrosoftアカウントになってしまっていたのだ。確かに,8.1のリリースの時に,何かの記事で読んだ気がする。しかし,全く忘れてしまっていた。8.1なんて縁がない,と思っていたせいもあるだろうが。

試しにそのまま少し使ってみたのだが,どうも気持ちが悪い。ファイル共有などは,アップグレード前のアカウント名で出来るらしい。コマンドプロンプトで,"net user"とやって表示されるのは,Microsoftアカウントではなく,元のアカウント名だ。どうもこれを「ローカル・アカウント」と呼ぶらしい。しかし,Windowsへのログインは,Microsoftアカウントとそのパスワードだ。コントロール・パネルのユーザー・アカウント・アプレットで見ても,対応するローカル・アカウント名は表示されない。今回はアップグレードだったが,8.1をクリーン・インストールした時は,どうやってローカル・アカウント名を知るのだろうか。

さらに気持ち悪いのは,Microsoftアカウントとパスワードで,家のマシンにログインできてしまうこと。もしMicrosoftアカウントの情報が漏洩したら,家のマシンにもログインできてしまう訳? まぁ,実際は外部から直接アクセスできるようにはなっていないので,それほど心配はないが,やはり一抹の不安はある。8.1って,Microsoftアカウントでないと使えないのだろうか。

ということで,またまた調べてみたところ,ユーザー・アカウント・アプレットで,Microsoftアカウントとの「関連付けを解除する」ことが出来るそうだ。「PC設定でアカウント変更」をクリックすると,「関連付けを解除する」という項目が現れる。いや,確かにそういうのがあるのは目に入っていたが,「関連付け」じゃ分かりにくいだろう。とにかくクリックしてみる。すると,パスワードの入力画面が現れる。ローカル・アカウントのパスワードをここで設定する訳だ。かくして,私のWindows 8.1は,めでたくローカル・アカウントの設定に戻った。

それにしても,毎度のことながら,たかが小数点以下のマイナー・アップデートごときで,押し付けがましい使い勝手の変更である。元に戻せるくらいなら,デフォルトでは元のままにしておいて欲しいものだ。Microsoftアカウントに関連付けていないことのデメリットがあるのか分からないが,しばらくこのまま様子を見てみたい。


Pythonモジュールのインストール [ソフトウェア/PC関係]

最近ちょこちょことPythonを利用する機会がある。以前から勉強しようと思っていたのだが,やはり必要に迫られないと,なかなか身が入らないものだ。で,取り敢えず,新しく覚えたことのメモ。

とある機能を実装するのに,PyCryptoというモジュールが必要なことが分かった。これはPython本体とは一緒に配布されていない。PerlならCPANで探せば良いのだが,Pythonの場合はどこへいけばよいのだろう。

調べてみたところ,Pythonでは"Python Package Index(PyPI)"というのが,PerlのCPANに相当するものらしい。"PyPI"ってどう発音するんだろう。「パイピーアイ」とか「パイパイ」とか,いくつかの説が見つかったが,よく分からない。それはともかく,PyPIは,Pythonの公式サイト(http://www.python.org/)へ行って,ページ上部のメニュー・バーから"PyPI"をクリックすれば到達できる。検索ボックスに"PyCrypto"と入れてsearchボタンを押せば,検索結果が表示される。但し,ここでは紹介されているだけで,CPANのようにダウンロードは出来ないようだ。パッケージを手に入れるには,ここに載っている公式ページに行って,そこからダウンロードする必要がある。

最新版のバージョン2.6.1のアーカイブをダウンロードしたら,適当なディレクトリに展開する。この時,cygwinなどの,gzip+tar形式を展開できるツールが必要。で,展開したら次はどうするのか。Perlの場合は,「perl Makefile.PL」として,Makefileを作るのが常道。ではPythonの場合は?

Pythonモジュールのインストールは

python setup.py install

とするのが一般的らしい。これで,必要なビルドとインストールがまとめて実行される。あるいは,

python setup.py build
python setup.py install

のように,ビルドとインストールを分けて実行することも出来る。Perlのようにmakeを使用せず,Pythonだけで完結するのは分かりやすい。

しかし,早速試してみたところ,"vcvarsall.batが見つからない"というエラー・メッセージが。vcvarsall.batというのは,Microsoft Visual Studio(VS)の,C++コンパイラの実行環境を設定するバッチ・ファイルである。VSならちゃんとインストールしてあるのだが,一体どこを探してないと言っているのだろう。

Stack Overflowで見つけた情報によると,私の使っているPython 2.7のsetup.pyは,"VS90COMNTOOLS"という環境変数を見ているらしい。これはVS 2008のもので,同じVSでも,バージョンが違うと環境変数の名前も変わる。私の場合は,VS 2013 (Express版)をインストールしてあるので"VS120COMNTOOLS"となる。しかし,setup.pyは,VSのバージョンに関わらず,"VS90COMNTOOLS"を探してしまうのだそうだ。対策としては,自分で""VS90COMNTOOLS"を"VS120COMNTOOLS"と同じ値にセットしてやるしかない。

思いがけず時間がかかったが,これでなんとかモジュール・インストールは完了。こういう手間があるから,ついついよく知ってる言語でプログラムしたくなるんだよねぇ。だから,必要に迫られないと,新しいものを覚えられないという訳ですな。


EZwebメールでIMAP [ソフトウェア/PC関係]

auのスマホやケータイで使われている,EZwebメール。所謂キャリア・メールで,基本的に端末でしか利用できないものだ。しかし,去年の9月末までは,au oneメールという,Gmailをベースとしたサービスを使って,PCからも読み書きできていた。ところが,au oneメールのサービス終了が発表され,後継サービス提供がアナウンスされるも,当初の予定より延期。結局,いまだ後継サービスは開始されず,不便な状態が続いている。こういうところに,auの企業ポリシーというか,サービス品質の低さを感じざるを得ない。

この後継サービス,最後の発表によれば,今年春に開始されるはずだった。もうあと2週間ちょっとで4月。気づかない間に,もしや何か新しい発表があったのではないか,と調べてみたところ,期待はあっさり裏切られたが,まったく別の,興味深い情報を見つけた。

なんと,EZwebメールが,IMAP経由で読み書きできるというのだ。これは,EZwebメールをiPhoneでサポートするための仕組みらしく,auからやり方が公表されている訳ではないらしい。しかし,もし出来るのなら,こんなに便利なことはない。au oneメールの時と違って,PCから送信しても,本当にスマホから送信されたように見えるはずだ。そうなれば,厳密にケータイ以外からのメールを拒否する受信フィルタをかけている相手にも,PCからメールが送れるということになる。iPhoneサポートのためということだから,そんなにきわどいやり方ではないだろうと考えられるので,早速試してみることにした。

まずやるべきことは,「#5000」という宛先に,「1234」というSMSメッセージを送ること。機種によって,標準のSMSアプリではダメだったりするらしいのだが,私のAQUOS PHONE SERIE(ISW16SH)では問題なく送れた。すると,すぐにSMSの着信があり,その中にURLが含まれているので,そこへブラウザでアクセスする。

このURLのページは,iPhoneからのアクセスを想定しているので,Androidなどからアクセスするとエラーになる。ではどうすればよいかというと,ブラウザのUser-Agent偽装で回避する。

User-Agentというのは,HTTPプロトコルで,クライアント(ブラウザ)からサーバーに送られるヘッダの1つ。これで,ブラウザは自分が何者かをサーバーに通知するのだが,サーバー側では,これを使って,ブラウザの種類に応じて違うレスポンスを返すことが出来る。逆に言えば,User-AgentにiPhoneと同じものを指定して送れば,サーバーはクライアントがiPhoneだと信じ込むという寸法だ。

とは言え,普通のブラウザは,そのままではUser-Agentを変更する機能を持たない場合が多い。「そのままでは」と書いたのは,プラグインやアドオンで可能になる場合があるからだ。AndroidのFirefoxの場合,"Phony"というアドオンが使える。こいつをインストールして,メニューから「Phony」を選ぶと,User-Agentを設定するパネルが表示される。その中から,予め用意されている「iPhone」を選び,先ほどのURLをもう一度表示する。今度はちゃんとページが表示されるはずなので,その中から「手動設定」というリンクを探す。そしてそれをクリックすると,別のページが表示され,そこに「設定情報送信」というリンクがみつかる。これをまたクリックする。ページは,IMAPのサーバー情報の表示に切り替わり,程なく別のSMSメッセージが届く。このSMSメッセージが重要で,その中に,IMAPサーバーのユーザーID(EZwebメールIDとは異なる)とパスワードが書かれている。これらの情報を使って,IMAPをサポートしている好みのメール・アプリケーションにアカウントを作ることができる,という訳だ。

なお,このままだと,スマホの方には,EZwebメールの新着通知が行われなくなるらしい。そこで,もう一度,今度は宛先「00090015」に,「1234」というメッセージを送る。すると,「iPhoneからの機種変更設定が完了しました」というSMSメッセージが届く。これで,元通り新着通知がなされるようになる。

早速,Thunderbirdにアカウントを作り,メールを同期させてみた。確かに,最近受け取った記憶のあるメールがリストされる。なるほど,これは便利だ。しかし,どうもメールの数が少ないような。ググってみたところ,EZwebのメール保存期間は30日らしい。その通り,メールの日付が,最近30日程度の範囲に収まっている。しかし,IMAPでメール削除されるのは困る。せっかくPCにダウンロードしておいても,サーバーから削除されたタイミングで,同期する時にPC上のメールも消えてしまう。そもそも,IMAPとはサーバーにメールを溜めておくシステムなのに,これでは意味がない。サーバー側の必要ディスク容量が増大するので,IMAPのサポートを嫌がるメール・プロバイダもあるくらいだ。

もしかしたら,30日の期限はEZwebのもので,IMAPに切り替えた後は,30日で削除されることはなくなるのかもしれない。これについては,引き続きチェックが必要だ。ただ,その間,本当にメールが消えてしまっては困るので,EZwebメールの設定で,メールをGmailに自動転送するようにしておいた。

かくして,au oneメールの後継サービスを待つことなく,同等以上の手段を手に入れることができた。満足。やり方を調べてまとめてくれた先人たちに感謝である。しかし,こんないいものがあるなら,auも積極的に公開すればいいのにねぇ...。


Twitter APIがSSLのみサポートに変更 [ソフトウェア/PC関係]

Twitterの「本日のつぶやき」の記事がblogに上がっていないことに気が付いた。記事の投稿は,以前作ったPerlスクリプトで自動化している。何かまたトラブルがあったのだろうか。そのスクリプトをコマンドラインで実行してみると,"403 Forbidden"というエラーが表示された。場所は,Net::Twitterのインスタンスで,user_timelineメソッドを呼び出したところである。一体何故急にエラーが起きるようになったのか。

取り敢えず,Net::Twitterモジュールの最新版が出ていたので,ppmを使って更新してみた。しかし,状況は変わらない。「Net::Twitter 403」でググってみたが,いくつか情報が見つかるものの,該当するものはない。さて困った。

何かAPIの仕様が変わったのだろうか。今度は「Twitter API」でググってみると,ビンゴ!! 検索結果のトップに来たのはhttps://dev.twitter.com/だが,サマリーの中にこんな記述が。

January 14, 2014 api.twitter.com now requires SSL/TLS for all connections as of today

げげっ。HTTPSでの接続しか受け付けなくなったってことか。日付的にも,投稿に失敗した時期とぴったり合う。早速,スクリプトを下のように変更してみた。ベースとなっているのは,昨年6/13の記事で説明した,Twitter API v1.1対応版である。

my $handle = Net::Twitter->new({
	authenticate => 0,
	traits => [qw/OAuth API::RESTv1_1/],
	consumer_key => "xxxxxxxxxxxxxx",
	consumer_secret => "xxxxxxxxxxxxx",
	access_token => "xxxxxxxxxxxxx",
	access_token_secret => "xxxxxxxxxxxxx",
	ssl => 1,
});

変更点は,Net::Twitterインスタンスをnewするところで,パラメータに「ssl => 1」を追加している1行のみ。これで,HTTPの代わりにHTTPSを使うようになるはずだ。実際に変更後のスクリプトを実行してみると,今度はエラーも起こらず,無事Tweetの取得ができて,まとめ記事も投稿された。

しかし,こんな変更全然知らなかった。メール・アドレス登録してるんだし,自作アプリの登録もしてるんだから,通知メールを送ってくれればいいのに。不親切な会社。


ThinkPad万歳! [ソフトウェア/PC関係]

昨晩,家路を急いでいた時,突然背後で「バッターン!」という,何かが倒れたような音が聞こえた。驚いて立ち止まり,振り返ってみると,あろうことかバックパックに入れてあったはずのノートPCが,地面に落下しているではないか。一体どういうこと?? バックックを下ろしてみると,チャックが完全に開ききり,蓋の部分がアッカンベーをしてるように,べろんとひっくり返ってしまっている。一体何故??? チャックが勝手に開いてしまったのだろうか? あるいは,そもそも自分がチャックを閉め忘れてしまっていたのだろうか。確かにチャックの閉め忘れはたまにあるのだが,いくらなんでも全開のまま背負ってしまうことはない。とすると,少し開いていたチャックが,PCの重さか何かで勝手に開いてしまったと考えるのが妥当かも知れない。しかし,そんなことってある? バックパックの仕様上の欠陥じゃないか? 危険だ。今後は注意して使わなければ。っていうか,買い換えた方がいいかも。

なんてことを呑気に考えている場合じゃない。問題はPCだ。落下したのはこともあろうに舗装路の上。一応,クッション・バッグには入れてあるのだが,だいぶ古いので,買った当初ほどの衝撃吸収力はなさそうだ。事実,落下音からして,かなりの衝撃があったはず。本当はすぐその場で無事かどうかを確認したかったのだが,周囲の目も気になるし,もし破壊していたとすれば手遅れなので,家に帰ってからにすることにした。

帰宅後,恐る恐るPCを取り出してみると,少なくとも外側には傷はなさそう。バッテリーが外れかかっていたくらい。しかし,液晶はどうだろう。ゆっくりとPCの蓋を開けてみると,意外にも無傷。割れたりはしていなかった。まずはひと安心。次なる心配はHDD。今時のHDDは,稼働中でなければ衝撃にも強いはずだが,確実とは限らない。怖々スイッチを入れてみる。もしかしたら,液晶だって外傷がないだけで,内部が断線していないとも限らない。画面に表示が出るまでの数秒が,数分にも感じられる。そして...表示が出た! 液晶は大丈夫みたい。でもHDDのデータは? 数秒後,Windowsの起動画面が現れる。まだまだ予断は許さない。果たして,このままちゃんとWindowsが起動するだろうか。待つことしばし。なんと,無事Windowsが起動し終わった! 普段使っているアプリケーションも問題なく動作する。良かった。壊れてなかった...。張り詰めていた気持ちが一気に緩む。

という訳で,下手なホラー映画よりもよっぽど怖かったPC落下物語は,ハッピーエンドで終了。きっと,落ち方が良かったんだろう。ラッキーだった。しかし,次また大丈夫という保証は何もないので,今後は十分注意しなければ。

因みに,落下したノートPCは,LenovoのThinkPadである。素晴らしい堅牢性だ。メーカー・テストで,落下試験をやっているのは知っていたが,実験室とは条件が異なるだろうし,現実の状況でも大丈夫とは,正直信じていなかった。考えを改めなければ。ThinkPad万歳! 開発者の方にも感謝感謝である。


前の10件 | 次の10件 ソフトウェア/PC関係 ブログトップ