たかちゃん。

9月 182014
 

タイミング的には ZTE Blade Vec 4G が手元に届いて Nokia Lumia620 から SIM カードを抜いて、 ZTE Blade Vec 4G の動作確認が完了したあとに SIM 無しで Lumia620 を起動しようと思ったら、あれ? 起動しなくなった・・。orz

SIM カードを入れ直したり、 MicroSD カードを入れ直したり、バッテリを予備のヤツに交換して試しても一向に再起動しない状態。電源を入れたときに以下のように表示されます。

WP8_stop_1

これ、Windows の『ブルーサンダー』とでも言えば良いのでしょうかねぇ? “:(” ってのがイマイマしぃですか・・。ぶつぶつ。

まぁ、ちょうど SIM カードを ZTE Blade Vec 4G に入れ替えたところで、そっちをいじるのが楽しかったので Windows Phone はすっかりと相手にされない状態だったのですが、いよいよ原因を追及してみるとこにしました。

すると、 Nokia の Lumia シリーズは OS がブートしなくなった場合にはキーを押しつつ電源を入れると復活する場合がある。と、いうのがたくさんありました。以下はその例です。

o. 音量下げるボタン + 電源ボタン + シャッターボタンの同時押しで起動
o. 音量下げるボタン + 電源ボタンの同時押しで起動

などなど。ボタンの同時押し(五秒以上の長押し)で復活するパターンが見受けられましたが、僕の Lumia620 ではダメでした。
ちなみに上と下の違いは Lumia の数値の大きさで違うみたいです。数値が大きくなる機種の場合は下ので良いみたいです。

それにしても僕の Luma620 は復活しないので『どーしたもんかいのぉ・・。』などと悩んでいたのですが、機体を見ると、バッテリ接続ピンの辺りがとけてないかい? とか思えてきました。

WP8_stop_2

本体とバッテリは三本のピンで接続しているのですが、一番左側のピンの上の部分がなんか溶けているような気がしないでも無いですが・・。きっと気のせいかなぁ・・。

などと、思いつつ、更に調べを続けていると、おぉっ!! 上記とは違うやり方で復活した人がいるようですねぇ。

http://bleign.net/blog/2013/04/28/202

ありがとうございます。上記サイトを参照し以下の手順で試してみました。

1). 電話の電源を切ります。
2). 音量下げるボタン を押しながら充電を開始(MicroUSB ケーブルを接続)します。
3). 電話が起動して画面に “!” が表示されると一安心。ふぅ。
4). 音量上げる ボタンを押します。
5). 音量下げる ボタンを押します。
6). 電源ボタン を押します。
7). 音量下げるボタン を押します。

しばらくすると自動的に再起動するのでそこで以下の画面が表示されて工場出荷状態の設定になります。

WP8_stop_3

いやー。このギアのマークが出たのでホッとしました。ここからしばらくすると Windows Phone8.1 が起動するようになります。
そもそも Lumia620 を購入したときには Windows Phone8.0 だったので、『工場出荷時』というのは 8.0 か 8.1 かどっちになるのだろう? とハラハラドキドキしていたのですが、復活してブートしてきたヤツは 8.1 が起動して来ました。

その後 17 個くらいの OS 付属系アブリのバージョンアップを行い、その後自分の必要なアプリを再インストールすると無事に復活します。

いやー。もうダメだと思っていた Lumia620 ですが、無事に復活して良かったです;-)。

ただ、 Lumia620 は技適は通っていないので羽田や成田の出国ゲートを通った後に色々いじりましょう;-)。

9月 142014
 

NTT コムストアから Android のスマートフォンで docomo の Band1,19 に対応する ZTE Blade Vec 4G というのが出たのですかさず購入してみました。今回はそのインプレッションをレポートしてみたいと思います。

ちなみに僕は rakuten で購入しました。 09/05 発送組だったのですが、届いたのは翌日の 19:00 頃。 09/07 から北海道に旅行に行く予定だったのでギリギリセーフ。ふぅ。

ZTEBladeVec4G_1

と、いうことで今回は北海道の旅でこってりと使い込んできて、そのレポートになります。

最初に ZTE Blade Vec 4G を利用する僕の環境から書いてみます。

o. 僕は既に ASAHI ネット の「ASAHIネット LTE」の 1 ギガプラン を契約しているのでそれを利用し、付属の「OCN モバイル ONE」は塩漬け。
o. 050 の番号は月額基本料無料の FUSION IP-Phone SMART を既に契約しているのでそれを利用する。

と、いうような感じでしょうか。

今回購入した ZTE Blade Vec 4G との比較は Android 4.0.4 の NEC MEDIAS N-04D と Windows Phone8.1 の Nokia Lumia620 です。それぞれの比較図などを書いてみると、以下になるでしょうかねぇ。これらの機種は MVNO で利用できる端末です。

機種名 ZTE Blade Vec 4G NEC MEDIAS LTE N-04D Nokia Lumia620
LTE Band1 OK OK
LTE Band19 OK NG
HSDPA(3G) Band1 OK OK OK
HSDPA(3G) Band19 OK OK NG
テザリング OK NG OK (だけど遅い)

 
と、いうことでここから先は順番に見ていくことにしましょう。

 
1). 電波について
MEDIAS LTE N-04D は LTE においては domoco の 800MHz 帯である Band19 が利用できませんでした。自宅では Band19 が入らずに、頻繁に 3G になったりしていたんですけども ZTE Blade Vec 4G では Band19 に対応しているのでバッチリです。

Nokia Lumia620 は 3G のみので LTE が利用できないのですが、都会においては遅さをガマンすれば Band1 である 2.1GHz 帯の 3G のみでも問題は無いのですが、山間部に行くと Band19 が入らないのは致命的で”圏外”になることが多かったです。

その点 ZTE Blade Vec 4G は HSDPA/LTE 共に Band19 に対応しているというのは非常に大きいですね。

以上が Band19 対応における各機種の違いになります。

次に ZTE Blade Vec 4G の 3G と LTE について書いてみます。

ZTE Blade Vec 4G は LTE が届かないところでは LTE -> 3G へと自動フェイルオーバーはしてくれないようです。 Android マーケットには LTE OnOff というアプリがあるのですが、それが利用できました。僕は MEDIAS LTE N-04D の時代から利用していたので、今回の機種でも試してみましたが無事に動作したので、どの電波を拾うかは LTE OnOff を利用すれば良いと思います。

ZTEBladeVec4G_2

ただし、キャリアの SIM は入れてないので 090 で始まる電話については僕には解りません。

 
2). バッテリーについて
次にバッテリーの話についてですが、比較対象は NEC MEDIAS LTE N-04D とになります。

が・・。うーむ。すばらしいっ!! の一言。 MEDIAS LTE N-04D は何をしているのだっ!? って感じです。

“セルスタンバイ問題” は発生しません。と、いうか、発生しているのでしょうけど、バッテリが激減する事象には陥りませんでした。と、いうのも、今回は上に書いたように北海道の旅で一週間みっちりロードテストしてきました。大洗からフェリーで苫小牧まで渡り、道東方面を車で移動していたのですが、フェリーの上では LTE/3G/圏外 の三者の移行が頻発しますが一晩でバッテリー消費がが 3% 程度と、異様に抑えられています。

Android 4.4.2 がすばらしいのか ZTE Blade Vec 4G 側でカスタマイズしているのか解りませんがバッテリーについては電波状況や MVNO の契約状態がどうであれ、非常に長持ちします。

また、 GPS を常時オンにしていてマップアプリを起動した時に GPS を利用したとしてもマップアプリを閉じると GPS マークが消えたりするので GPS でバッテリーを大量に消費する。と、いうことも無いです。

この点は一晩でバッテリーが半分以上消費されてしまう MEDIAS LTE N-04D とは雲泥の差です。

まぁ、色々ネットやゲームなどで使っている場合にはバッテリーは消費されてしまいますが、それはしょーがないですね。

 
3). 050 の IP 電話
050 は上にも書きましたが FUSION IP-Phone SMAR を利用しています。アプリは SMARTalk の Version1.1 を利用しています。 Lumia620 の場合は IP 電話アプリを表示(起動)していないと着信できませんでした。バックグラウンドで動作していても着信できない状態です(Windows Phone アプリの場合には着信があったことをメールで知らせることができます)。

ZTE Blade Vec 4G では SMARTalk を起動するとバックグラウンドで省電力で動作しているようで、電話がかかってくるとちゃんと着信音が鳴り、話をすることができます。この点は大きいですね。

バックグラウンドで IP 電話アプリが動作していてもバッテリーの消費は極端に多くなるようには感じません。

 
4). その他使い勝手
ZTE Blade Vec 4G は確かに大きいですね。ディスプレーが 5 インチなので当たり前ですが。『ちゃちぃ。安っぽい。』と言われていますが、まぁ、確かに;-)。しかし、プラスチック筐体なのでそれはそれでしょーかないでしょうかね。
しかし、ローガンの人には中々良い感じの大きさです;-)。

送られてきた箱の中には液晶保護シールが付いていたのが嬉しかったです。でもってたまたま偶然綺麗に貼れたので尚嬉しい;-)。

MicroUSB コネクタが上部にあるのですが、充電中は横向きにしてやるしかないでしょうかねぇ。雨の日とかキャップが必要そう・・。
それにしても接触がどうもイマイチで安っちぃ USB コードだと接触不良が発生して充電できない場合もありました。
まぁ、 Lumia620 も MicroUSB のコネクタは怪しかったので『そーいうモンだ。』と割り切るのが良いかも;-)。そー考えると Apple の独自路線ソリューションも”有り”だとは思いました。

上にも書いた通り、僕は Asahi-Net の MVNO を利用していますが、この機種ではテザリングが利用できます。嬉しいですね。

僕は今までずっと iPhone をメインで利用して来たので SD スロットが無いことについては特に不自由は感じてないです。

 
5). 総評
と、いうことでここまでツラツラと書いてきましたが、最後に総評です。一番嬉しいのはなんと言っても SIM フリーの端末で docomo の Band19 (俗に言う 800MHz 帯) が利用できる点でしょうか。この周波数帯の電波が入るとどこででも利用できるようになります。

あと、バッテリーが長持ちする点。比較は同じ Android の MEDIAS LTE N-04D になるんですけども。今でもコツコツと N-04D を利用している人がいるのであれば直ちに ZTE Blade Vec 4G に変えたほうが良いのではないのかなぁ・・。などと、思います。が、通話に関しては僕には解りません。

値段の割には良くできているな。 docomo 謹製の Android スマートフォンよりも遙かに良いと思います(ただ、僕は最近の docomo の Android は知りません;-)。

 
MEDIAS LTE N-04D で Android がすっかりとキライになったのですが、今回、この機種を購入してみて『ふーん。 Android も中々やるんだねぇ。』などと、ちょっと考えが変わりました。やはり最新の機種は良いのでしょうかねぇ;-)。

 
購入を考えている方で、上記以外で質問などありましたらコメント頂ければ、解る範囲でお答えしますので、ご連絡頂ければと思います。

8月 312014
 

久しぶりに『CPU コレクション』なカテゴリ掲載です。いやね。CPU はまだまだいっぱい持っているのですが、自分の中ではある程度完結しつつあって、残りの CPU は今でも現役チックなものが多いかなぁ。と、いう感じでして。

しかしまぁ、それにしても今年は Pentium CPU が 20 周年らしいので、むむむ。それは是非とも手持ちの Pentium を掲載しなければならんなぁ。などと思った次第であります。

まぁ、僕は Intel の CPU は好きではないのですけども、お祝いですしねぇ;-)。

で、今回登場するのは Socket478 の Pentium4 です。以前に掲載している Pentium4 は Willamette コアのやたらとでかい CPU でした。消費電力があまりにも多くて AMD の Athlon との勝負でケチョンケチョンに負けた CPU なんですけども、これで起死回生の一撃でしょうかね。

Socket478_Pentium4_ Northwood_1

こちらが表側で、下の写真が裏側です。 Socket478 な CPU は色々なアーキテクチャなコアが出たので、CPU の裏側もビミョーに違ったりしていて中々面白いんですよね。なので、表ばかりでなく裏側も気にしたいモノです;-)。

Socket478_Pentium4_Northwood_2

ピンの中にチップが埋まっているのですが、これがビミョーに違うんですね。今回は Northwood の Pentium4 です。

ところで Northwood ってのは『北森』とかいう人もいますよね。それだけありふれたというか、たくさん売れた CPU でした。会社のジャンクの PC とかサーバを開けるとゴッソリとこの CPU が出て来たりして、僕の手元にもたくさんあります。

いやー。これで対 AMD の勝負も対等に渡り合えるようになった CPU ですねぇ。

あうー。 Socket478 はコアアーキテクチャの他に『ステッピング』ってのがあるんですなぁ。この CPU は SL5ZT なので B0 ステッピングですねー。他にも今後登場する Intel の CPU はこの『ステッピング』を書いて行かないとなぁ・・。

8月 122014
 

以前のエントリで SkyDrive に FreeBSD からネーテブアプリでアクセスしようぜぃ。ってのを二つ書きました。以下のエントリになるんですけども。

SkyDrive を FreeBSD に mount して使う。
SkyDrive を FreeBSD に mount して使う。そのに。

当時はまだ OneDrive ではなく SkyDrive と言っていたんですね。

そもそも、 FreeBSD から直接 OneDrive に(ネーテブなアプリで)アクセスすることは不可能で、中間的サービスを利用することになります。そのサービスは Storage Made Easy (以下 SME と記述)と、いうものです。

ここでアカウントを作成して、無料のサービスを利用すると SME のストレージサービスが利用できる他に、色々なクラウドストレージサービスプロバイダも合わせて利用できる。ってシロモノです。
簡単にいうと SME のサービスはプロキシみたいな感じで OneDrive とか Box 、 更には DropBox などにもアクセスできるようになります。

これは是非ともアカウントを一個くらいは作っておきたいですねぇ;-)。

SME のサービスはマルチプラットホーム対応で色々な OS 用のアプリがあり、スマートフォン・PC・Mac や Linux からもアクセスできます。 Linux 用はソースコードまで公開していて、そのソースコードを FreeBSD 上でコンパイルすると、 FreeBSD のネーテブアプリから OneDrive や DropBox にアクセスできる。と、いうすごいことになるんですねぇ。

以下の Lunix 用アプリについて書かれている URL です。

http://storagemadeeasy.com/LinuxDrive/

ここから CentOS の rpm をダウンロードして make してしまう ports を作ってみました。上にあるエントリでは随分と古い話でしたが、最近のソースコードは随分と美しくなり、起動するアプリケーションも直感的になりました。

 
話はガラっと変わるのですが、 Windows8.1 の場合、 OneDrive にアクセスするときには Windows Live アカウントでないとアクセスできない(ローカルアカウントでログインしている場合には一旦切り替えなければならない)ので非常に厄介です。

その場合、SME の Windows 版アプリをダウンロードして来て Windows8.1 の場合にはそれを利用するとローカルユーザーでも OneDrive にアクセスできるようになります。うひひ;-)。

Windows8.1 な人も是非利用してみてください。

 
さてさて。話を戻して、上記 URL より SentOS の storagemadeeasy-4.1-0.noarch.rpm をダウンロードしてサクっとインストールする ports を書いてみたのでもしよければ利用してみてください。

以下に ports の仕様を書いてみたいと思います。ダサいところが多々残っているんですが、僕には ports の書き方が判りませんでした・・。orz

あ。 ports は当然ながらノラ ports です。これがちゃんと ports のルールに従えられれば、前回のノラ ports である QtWeb とこれは commit してメンテナになってもも良いかなぁ。などと思っているんですけどもねぇ・・。

以下の URL にノラ ports はあります。ダウンロードしたら /usr/ports/net/ に展開して頂ければと思います。

http://icmpv6.org/Prog/FreeBSD_ports/ports-storagemadeeasy-20140812.tgz

ports の仕様は以下のような感じ。まぁ、Makefile を見て頂ければ解ると思いますf(^^;;。

1).ダウンロードはちょっと違うファイル名
https://storagemadeeasy.com/files/ から 380f74d2fcd051b21a64858ecb3f0923.rpm と言うファイルをダウンロードしてきます。

2). post-patch はダサいねぇ・・
${WRKDIR}/usr/share/sme_install/*/* のディレクトリのパスを変更します。 それにしてもダサいのが、僕は SED マクロが書けませんでした。 find して xargs から perl -e で置き換えています。ここはもっちっと改修する必要が絶対にあります。

3). コンパイル
SME のアプリは Qt4 を利用しているので qmake-qt4 実行後に make します。 LIB_DEPENDS や USE_ は多分全てを読み込んでいて、モレはないと思います。

4). インストール
SME のアプリの make は make install が無いので ports の中で吸収する必要があります。PLIST_FILES に書かれたものがインストールされます。
が、しかし、これだけでは足りないんですよねぇ・・。 pkg-plist の書き方が解らなかったので pkg-message にイントール後にもう一個インストールするようにコマンドイメージを書いておきました。
ports の中に smeclient.tgz を同梱しているのですが、これは ${WRKDIR}/usr/share/smeclient/ ディレクトリのアーカイブになります。
なので tar でなくとも、以下のコマンドでも十分に OK なんですね。

# cp -pr work/usr/share/smeclient /usr/local/share/

 
以上が ports の仕様です。随分とダサいところ満載ですねぇ・・。書き方が解らない部分が多いんですよねぇ・・。この間作った QtWeb の ports のほうがまだ楽ちんでしたf(^^;;。

 
と、いうことで、インストールされたあとは /usr/local/bin/smeexplorer を起動してアクセスすれば色々なクラウド上のファイルの閲覧が可能になります。

SME のサービス自体が中々良い感じなのでそれが FreeBSD 上からウェブブラウザ経由ではなく、ネーテブアプリからアクセスできる。と、いうのが良いのであります。

あ。今回はキャプチャはありません;-)。

ただ、 SME のアカウントを作成しなければならない。と、いうのが煩わしいとは思うのですが、iOS や Android 、 Windows などと同じレベルで FreeBSD からもするーっとクラウドストレージへのアクセスが可能になるので、これはこれで利用すると非常に嬉しいですねぇ;-)。

 
皆さんも是非利用してください。とは言いませんが、あ。そーそー。最後にですが、当該 ports を ports のルールに乗っ取ったものに改修してくださる方絶賛募集中です。どうか宜しくお願いします。

 
2014/09/05 加筆
ちゃんと一発で make install と make deinstall できるように ports を更新しました。
改修点は以下になります。

・post-patch: の部分で perl で一括置き換えしていたものを REINPLACE_CMD を使うようにした
・最後に tar でインストールしようとしていたたくさんのファイルを do-install: で行うようにした

が主な改修点です。これで多分完璧;-)。

以下の URL にあるのでよかったら利用してください。

http://icmpv6.org/Prog/FreeBSD_ports/ports-storagemadeeasy-20140905.tgz

7月 232014
 

さくらの VPS を契約して一年が経ちました。で、ちょうどさくらインターネットから「契約更新するなら何もしなくて良いよ。」メールが届いたのですかさず解約してしまいました。

大阪リージョンはちょっと不憫だぁ・・。

・IPv6 無いしぃー。
・最近、僕の仮想マシンが載っている環境がやたらと遅いしぃー。

ってことで IPv6 は確か 07/20 に大阪リージョンも対応してくれるんだっけかな? なのでもう少し待っていればよかったんだろうけど、契約の更新時期と重なったし・・。

仮想マシンがやたらと遅いのは HDD と CPU がどうも遅い。例えば apache22 を worker で起動していても反応が(ブラウザでの表示)が遅い。まぁ、 WrodPress なので php と MySQL の影響もあるんだろうけど・・。

と、いうことで今回のエントリはさくらの VPS について、大阪リージョンを解約して石狩リージョンを別途契約したときの顛末を書いてみたいと思います。

 
1). 回線速度について
さくらインターネットのバックボーンについては以下の URL が参考になるかと思われます。

国内最大級の大容量バックボーン

これを見ると石狩より大阪のほうがネットワーク的には恵まれているかなぁ。と、いう感じはします。JPIX 東京で接続している ISP などの場合、大阪に行くパケットは大阪からではなく、東京から流れることになるので東京・大阪・石狩で、ネットワーク的にどこが一番良いか? となると、多分東京が一番良いような気がします。

ちなみに JPIX 東京に接続している某 ISP から色々調べてみましたが、石狩よりも大阪のほうがネットワーク的には早かったです。とわ言ってもその違いは 10ms 程度でしか無いんですけどね;-)。

 
2). サーバについて
と、いうことで石狩にサーバを作ってみました。こっちは速いですねぇ。って、それはそーですよね。このあと、バシバシ他の新規契約サーバが載ってくるんだから作った当初は随分と早く感じるはず;-)。

ちなみに今回作成したサーバは FreeBSD/amd64 9.2-RELEASE です。さくらの VPN でサポートされるようになったようなのでインストールしました。virtio や vtnet が利用できるのでカスタムカーネルを作る必要はありません。

ただ、インストール後、インストールが無事に終了して再起動したときに CD ブートしてしまうのには困りました。インストール完了後は再起動せずに電源断しないと CD がアンマウントしないしようになっているのですね。仕様のようです。なので、インストール後はきっちりとパワーオフしましょう;-)。

 
3). サーバの移設
大阪で動作しているサーバの情報を新しく動作した石狩のサーバに持っていきます。僕の場合は rsync で持って行きました。比較的早くデータの移設が完了します。

大阪の apache は apache22 で石狩の apache は apache24 にしたので、その点がちょっとややこしかったかな。 FreeBSD の ports-current は default が apache22 から apache24 に変わったので今回のタイミングがちょうど良くてバージョンを上げました;-)。

大阪 – 石狩 の間はさくらインターネット網内を抜けていくことになるので外部に出ません。ただ、大阪 – 石狩間ってのはネットワーク的にあまり早くないですね。
ってのは僕の気のせいかもしれません・・。石狩での二週間のお試し期間中にデータ転送するとむちゃくちゃ遅い 200kbps 程度しか出てなかった記憶があるのですが、本契約したらサクッと速度が出ますねぇ(@_o)。
お試し期間中にデータの移動をする方はご注意ください;-)。

 
4). DNS の移設
これが一番面倒でしたね。
僕はさくらの VPS 上で DNS のプライマリサーバを起動していて、さくらインターネットにセカンダリを持ってもらっています。
大阪から石狩にサーバを移動したとき、さくらインターネットで持ってもらっているドメインの情報は一旦削除して、ゾーンファイルの NS RR から削除して、whois から削除して、再登録しなければなりません。以下にその手順の詳細を書きます。

まずは構成図から。

sakura_vps_DNS

o.右側の二つの DNS: ns[12].dns.ne.jp はさくらインターネットの DNS でセカンダリ DNS を担当してもらっています。
o.左側の DNS はさくらの VPS 上に起動した DNS で FQDN は dns.icmpv6.org になります。

icmpv6.org のゾーンファイルの NS レコードは以下のようになっています。

        IN      NS      dns.icmpv6.org.
        IN      NS      ns1.dns.ne.jp.
        IN      NS      ns2.dns.ne.jp.

 

whois に登録してある DNS の設定も上記のようになっています。

さくらの VPS のコントールパネルから 会員メニュー > ドメイン > ゾーンの追加 では DNS の登録時にセカンダリを持ってもらうように設定しています。さくらインターネットから見えるプライマリ DNS は大阪のアドレスになっています。

この設定を新しく設置した石狩のサーバの IP アドレスに変更しようとしても受け付けてくれません。サポートに連絡したところ以下の URL を教えてもらいました。

http://sakura.custhelp.com/app/answers/detail/a_id/1451

さくらの VPS のリージョンを変更してサーバを引っ越しする場合 DNS が一番面倒だったりします。

1. ゾーンファイルの NS RR から ns[12].dns.ne.jp を削除
2. whois の DNS の設定に ns[12].dns.ne.jp が書かれていればそれも削除

上記の二点の作業後でないと DNS の登録を受け付けてくれません。僕が試したときには何回か色々なエラーメッセージが出たのですが、以下のエラーメッセージが表示されるときにはにっちもさっちも行かない状態になっていることになります。

エラーです(1)

登録することができませんでした。このゾーンまたは上位のゾーンが利用中です。(D5-01)

 
D5-01 なコードはぐぐってもサポートサイト検索しても出てこないんですけど・・。orz

と、いうことで上の二点を実施し、 ns[12].dns.ne.jp がどこにも書かれていない状態にしてから再度「ネームサーバ新規登録」の画面に進む必要があります。

さくらインターネットに対してネームサーバの登録が完了したら、登録のために設定した情報をもとに戻しても構いません。

1. NS RR に ns[12].dns.ne.jp を追加
2. whois の DNS の設定に ns[12].dns.ne.jp を追加

さっきと逆の作業を実施します。

あ。whois は DNS が二つないと登録できないので、一個しか無いときに辛いかも・・。僕の場合は自宅サーバがセカンダリの機能を持ちましたが。ふぅ。

 
と、いうことでふぅ。 DNS の登録も無事に完了しました。
サーバのデータの移動も完了して apache22 から apache24 への変更(各種設定や Require all granted への変更などの)作業もなんとか無事に完了しました(多分)。

これで、icmpv6.org と motsuyaki.org は多少早くなったのではないかと思われます。が、今後どんどん石狩も売れていくとまた重くなっていくんだろうなぁ・・。

まぁ、一番安いの契約しているのでしょーがないかf(^^;;。

7月 102014
 

X11 で利用するためのターミナルソフトというのは /usr/ports/ の下を探すと色々あるんですけども、僕なんかは KDE4 を利用していて『konsole あるじゃん。』となるんですが、どーも konsole は使いにくい。その中で色々と試して自分に良い感じのモノを利用したいモノです。

過去にもこのブログでは gtkterm2 のエントリを書いたりもしましたが、今回はそれに続く第二弾。と、いう感じでしょうかねぇ。

今回取り上げるのは xfce4-terminal です。 ports 的には x11/xfce4-terminal/ になります。もともとはウィンドマネージャである xfce4 (ports 的には x11-wm/xfce4)のターミナルソフトとしての役割があるのですが KDE4 を利用している場合においても x11/xfce4-terminal を make install することはできます。

xfce4 本体は利用せずともターミナルだけをインストールすると以下と、それに関連するプログラムがインストールされます。

libxfce4menu-4.10.0
libxfce4util-4.10.1
xfce4-conf-4.10.0
xfce4-terminal-0.6.3

まぁ、これくらいなら許せるかねぇ。って気がしないでもないので僕は使い続けているんですけどもね;-)。

で、xfce4-terminal のインストールが無事に完了し KDE4 で起動するとこんな感じになります。あ。上部のメニューの部分だけのキャプチャです。

xfce4-terminal_1

xfce4 をウィンドマネージャとして利用していると、ツールバーは 文字・アイコン・両方が選択できるのですが、 KDE4 上で利用するとその選択ができずに”両方”しか選択の余地が無いんですね。ちなみに xfce4 でウィンド装飾を設定するには xfce4-appearance-settings というプログラムを利用します。 ports 的には sysutils/xfce4-settings に含まれているのでいつを追加でインストールし xfce4-appearance-settings を起動してツールバーを”アイコンのみ”にしても KDE4 上で起動した場合には”両方”でしか表示できないんですね。

で、しばらくはツールバー無しで利用していたのですが、せっかくある機能、使わずしてどうする?などと、ザラ議長のような発想になってしまい、あちこち調べて格闘してみた。と、いうネタが今回のエントリーです;-)。

 
ウィンドマネージャである xfce4 の各種設定情報は $HOME/.config/xfce4/ に色々保存されます。ウィンド装飾の設定は $HOME/.config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml というファイルに保存されますが xfce4-terminal を単体で起動した場合にはこの設定ファイルを読み込まずにそのまま起動してしまうようです。 xfce4 のセッションを管理している何かしらの管理デーモンが画面全体を制御しているのでしょうなぁ。

では、 xfce4-terminal のソースを書きなおして default が BOTH なのを ICON に変えれば良いじゃないか。とか思い、ソースコードを見たのですが、うーむ。この辺りは GTK2 が管理しているようで GTK2 について詳しくない僕にとっては中々手強いのでありましたf(^^;;。

と、いうことで色々調べた結果、 KDE4 利用時に xfce4-terminal を起動しても無事にアイコンのみを表示できるようになりました。

xfce4-terminal_2

xfce4-terminal と xfce4-appearance-settings を同時に起動しました。

 
xfce4 は設定情報を全て管理していて、 xfce4 のアプリが起動したときに保存してある設定情報をアプリに渡すためのデーモンが存在しているようです。 KDE4 から xfce4-terminal を起動した場合、そのデーモンが起動していないために設定情報を xfce4-terminal に渡すことができなくて xfce4-terminal は default の設定で起動するんですね。

なるほど。では xfce4 の設定情報を渡すためデーモンを KDE4 利用時に起動して上げれば良いんだ。と、いうことになります。ちなみにそのデーモンは xfsettingsd というプログラムで sysutils/xfce4-settings に含まれています。

KDE4 でログイン後に xfsettingsd を起動してあげると xfce4 の各種設定が利用できるようになります。

まぁ、余計だとか CPU の無駄遣いとかイロイロあるとは思うのですが、最近はマシンパワーも余っていることですし、見てくれやツールバーの機能も重要なので今回はこれでヨシとしましょう。

あ。ツールバーが表示されたんだけど、「新規タブ」と「新規窓」のアイコンが表示されません。追加で x11-themes/icons-tango などをインストールしてあげてください。

これであなた好みのツールバーアイコンが利用できるようになるとか思われます。

ちなみに僕は非力なマシンとか仮想環境で X が必要なマシンでは KDE4 ではなく xfce4 を利用しています。機能的にも十分だし軽量なので重宝しております;-)。

 
さてさて。これだけではなんなんで、一個パッチを公開します。

xfce4-terminal ってのはショートカットとかキーバインドなどはソースにハードコーディングしているので変更できないんですね。
一番困ったのがタブの移動で default では Ctrl+Page_Up とか Ctrl+Page_Down なので不便でしょーがない。僕はタブの移動は Shift+Left もしくは Shift+Right にしているので、その部分を変更するパッチになります。

http://icmpv6.org/Prog/FreeBSD_ports/patch-terminal-terminal-window.c

自分のキーバインドにしたい場合には terminal/terminal-window.c の 210 行辺りを変更すれば良いと思います。
上記パッチは files/ の中にほーりこんで make すれば大丈夫なようにしています。

 
と、いうことで今回は xfce4-terminal について書いてみました。皆さんも機会があったら試してみてくださいー;-)。

6月 242014
 

今回は IPv4 のお話ではなく IPv6 のお話です。でもって Path MTU Discovery のお話です。

僕は IPv6 は Hurricane Electric の IPv6 Tunnel Broker を利用しています。以前からここの IPv6 トンネルを利用させてもらっているのですが、とあるタイミングで IPv6 の http や ftp が通らなくなりました。あらま。 ping や ssh は通るので、仕事柄の経験上「あぁ。 Path MTU Discovery にハマったな。」というのはすぐに解りました。

『ハマった』というのは『送受信の二点間において MTU の最小値を決定することができなかった。』と、いうことかな。
どうして『決定できなかった』のかと言えば『Path MTU を探査できなかったから。』と、いうことになると思います。
Path MTU が Discovery できないとパケットのフラグメントが発生しないので MTU サイズ以降のパケットは捨てられてしまうために通信が行えなくなります。

 
しかし、Hurricane Electric の IPv6 トンネルは今まで利用できていたのにどうしてある日突然 Path MTU Discovery ができなくなってパケットサイズの大きい通信が止まるのだぁ? などと不思議に思うのであります。

まず、どうして Path MTU Discovery に失敗するのか?

1). 自分が設定したファイアーウォールで ICMPv6 の Type2 (Packet Too Big)を止めてしまった
2). ISP がある日突然 ICMPv6 の Type2 に ACL をかけた
3). Hurricane Electric で仕様が変わった

が考えられると思います。 1). については自分が設定したファイアーウォールを flush して確認できると思います。
2). の場合、僕は ISP を二つ契約している(自宅でマルチホームっ!!;-)ので両方の ISP で Hurricane Electric のサービスにトンネルを掘って確認してみましたが、どちらも http が止まります。
すると、残りは 3). が原因か、もしかして 2). の二つの ISP の両方が ICMPv6 Type2 に ACL を設定しているか。ですね。

まぁ、どっちにしても通信はできません。orz

 
次に、本当に IPv6 Path MTU Discovery ができていないのかの確認方法です。

1). IPv4 は ping・ssh・http の通信ができることを確認
2). IPv6 で ping・ssh・http の通信ができることを確認
3). ping6 -s 1434 au.kddi.com もしくは ping -s 1280 au.kddi.com

1). の確認において IPv4 で上記プロトコルが全て利用できるようであれば、問題は IPv6 のみに特定できます。
2). では Path MTU Discovery にハマると http の通信のみできなくなります。まぁ、ftp ででかいデータを持ってくるときとか、パケットサイズが 1,500 バイトに近くなる通信では止まってしまいます。
3). は、じゃぁ実際に何バイトのバケットサイズであれば通るのだ?という確認のために ping でパケットサイズを指定します。 1,434 もしくは 1,280 バイトで ping してみて、通る、通らないでサイズを変更して色々確認してみるのが良いかと思われます。

さてさて。これらで確認することにより IPv6 Path MTU Discovery な地雷を踏んだか確認できますが、次にその対応について考えてみたいと思います。

 
まずはネットワーク構成図などを。

Tunnel_NetWork_01

真ん中の黄色いのがトンネルルータで Hurricane Electric に対して gif0 でトンネルを掘っております。 em0 のインターフェースは一個目の IPv6 セグメントです。
また、トンネルルータでは dtcps を起動していて gif10 と gif10 で更に二つのセグメントとトンネルを掘っております。

このネットワークでの IPv6 Path MTU Discovery の状態は・・。

1). 同一セグメント内では通信ができる
2). セグメント 1,2,3 の間ではで通信ができる
3). セグメント 1,2,3 から gif0 を抜けて Hurricane Electric の先にある IPv6 サイトと通信ができない

と、いうことが解りました。 どうやら MTU もしくは MSS の調整は re0 か gif0 で行う必要がありそうです。

 
が、その前に、クライアント PC 側で何か対応する手立ては無いか調べてみました。

1). クライアント PC の MTU を 1434 にする
2). IPv6 より IPv4 を先に利用するようにする

1). の場合は UNIX 系 OS だと比較的容易にできます。以下は FreeBSD で MTU を変更する場合のコマンドです。

# ifconfig re0 mtu 1434

 
IPv6 Path MTU Discovery でハマった時には MTU を1434 にしてあげると通信が復活します。セグメント内にいる全ての UNIX 系 OS で上記コマンドを叩く必要があります。

2). のほうは WindowsOS で有効な手段です。 DOS のプロンプトをアドミン権限で起動し、以下のコマンドを打ちます。

c:\ netsh interface ipv6 show prefixpolicies
c:\
c:\ netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 50 0
c:\ netsh interface ipv6 set prefixpolicy ::1/128 40 1
c:\ netsh interface ipv6 set prefixpolicy ::/0 30 2
c:\ netsh interface ipv6 set prefixpolicy 2002::/16 20 3
c:\ netsh interface ipv6 set prefixpolicy ::/96 10 4

 

一行目のコマンドはステータスの確認です。これを見ると IPv6 のほうが先に利用されるように設定されているので IPv4 を先に利用するようにその後のコマンドでプライオリティを変更してあけます。

もとに戻すときにはこちらのコマンドで。

c:\ netsh interface ipv6 set prefixpolicy ::1/128 50 0
c:\ netsh interface ipv6 set prefixpolicy ::/0 40 1
c:\ netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 35 4
c:\ netsh interface ipv6 set prefixpolicy 2002::/16 30 2
c:\ netsh interface ipv6 set prefixpolicy ::/96 1 3

 

これで WindowsOS もなんとか IPv6 Path MTU Discovery を回避できたのではないかと思われます。ちょっと弱い問題解決ですが・・。

しかし、IPv6 に対応しているスマートフォン(iOS や Windows Phone OS など)は IPv6 サイトが見られないんですよねぇ・・。

さてさて。こんなことばっかりしていても根本的な問題解決にならないので次に根本的な解決をしてみたいと思います。

 
IPv6 Path MTU Discovery ができないときの原因としては ICMPv6 の Type2 (Packet Too Big) パケットのやりとりができず、通信するための最小 MTU サイズが特定できないために発生します。それならばパケットを送信する側でパケットの最小サイズを明示的に指定して送信すれば良い(それはつまりは TCP SYN パケットの MSS オプション値を書き換えてあげる。と、いうことです)わけなんですけども FreeBSD にその機能があるのか?

今回利用しているトンネルルータは FreeBSD 9.1-RELEASE です。こいつには pf(4) があるのでそれを利用することにします。と、いうか、現状では pf(4) でしか制御できないようです。
他にもports に net/tcpmssd があるようなのですが、今回は pf(4) を利用することにします。

ちなみにトンネルルータのファイアーウォールは ipfw で設定しているのですが MSS のサイズは pf で設定することにします。
今回は ipfw の設定は省きます。以下は /etc/pf.conf の設定です。

scrub in  on re0  from any to any max-mss 1280
scrub out on re0  from any to any max-mss 1280
scrub in  on gif0 from any to any max-mss 1280
scrub out on gif0 from any to any max-mss 1280
pass all

 
FreeBSD の MSS サイズを固定に設定するためには max-mss を利用します。サイズは 1280 にします。上記構成図では re0 から抜けるパケットのみが 1,280 バイトになります。通常 IPv4 パケットは別の BB ルータから抜けていく(構成図には書かれていない)のでまぁ、問題は無いでしょ。

re0 と gif0 の両方の MSS サイズを小さくしている設定をしていますが、試した結果 gif0 のみの MSS を1280 に設定するだけで十分でした。

設定が完了したら以下のコマンドを打ちます。

# kldload pf
# kldload pflog
# kldstat
        :
33    2 0xffffffff8104b000 2a4a5    pf.ko
34    1 0xffffffff81076000 9c9      pflog.ko
#
# /etc/rc.d/pf onestart
# pfctl -sr
        :
# pfctl -sa
        :
#

 
カーネルモジュールをロードし、無事にロードできたか確認します。次に /etc/rc.d/pf を onestart で実行します。無事に実行できたかは pfctl の二行で確認(オプション -sr と -sa)しましょう。出力結果は省略します;-)。
無事に動作することができたら /etc/rc.conf などに pf_enable=”YES” などと書きましょう。

 
最後に確認方法ですが、簡単です;-)。セグメント 1,2,3 の各クライアント PC から IPv6 サイトが無事に見えるかどうか。だけです;-)。

au.kddi.com とか running-dog.net とか icmpv6.org などが無事に見えると pf で設定した max-mss 1280 が有効になっている。と、いうことですね。

 
とまぁ、ある日突然 IPv6 Path MTU Discovery が通信できない問題が降ってきたわけですけども、その対応策などをツラツラと書いてみました。皆さん、是非とも IPv6 Path MTU Discovery にハマらないようにしたいと思うわけですけども、もしハマったら pf で回避してみてください。

ふぅ。それにしても復活だぁ・・。

6月 192014
 

GNOME 方面の人にはまるで興味が無いとは思うのですが、 KDE というか Qt を利用している人にとっては、ご存知な方もいるのではないかなぁ?

世の中には超軽量ブラウザというのが存在しています。 rekonq も konqueror に比べると軽量かなぁ。arora も軽量ですね。 rekonq よりも軽量なのが QtWeb というブラウザです。 arora と同じくらい軽量かなぁ。

以下が QtWeb のサイトですね。

http://qtweb.net/

ここを見ると Windows・OS X・Linux と世界の三大ウィンドを制覇しているんですけどもね;-)。で、それぞれバイナリがあるのですが、ソースコードもあるので、それを FreeBSD に持ってきてコンパイルすると FreeBSD 上でも動作するんですけども。

キャプチャはこんな感じです。

Qtweb_1

で、せっかくなので今回は QtWeb の ports を作ってみました。 arora が ports になっているのに QtWeb が ports になってないのは悲しいことですし;-)。
以下の URL にあるのでもしも「僕も私もちょっと FreeBSD 上で QtWeb を使ってみようかなぁ。」などと思った人は試してみてください。

http://icmpv6.org/Prog/FreeBSD_ports/ports-qtweb-20140619.tgz

あ。コミットするつもりはありません。あくまでノラ ports ということで;-)。

QtWeb の ports の仕様やインストール方法などをちょっと書いてみます。

o. QtWeb をコンパイルするには Qt 4.8.6 のソースコードが必要
FreeBSD の ports 的には qt4-* で色々インストールされているのですが、 QtWeb は Qt ライブラリを static link するので FreeBSD の ports 的な Qt ライブラリは必要としません。
GNOME や xfce4 な人も Qt や KDE のコンポーネントをインストールすることなく Qt コテコテなブラウザを楽しむことがてできます。

しかし、裏を返すと Qt ライブラリ部分もコンパイルするのでコンパイル時間が随分と長いです。orz

僕が作成した ports では /usr/ports/distfiles/KDE/ に Qt 4.8.6 のソースがあればそれを利用し、なければとある日本のサイトからダウンロードしてきます。詳細は files/patch-qt-src.sh を見てください。

o. ports がインストールするもの
QtWeb のサイトからバイナリをダウンロードすると、本当に QtWeb 本体のみしかパッケージングされてないのですが、僕の作った ports では QtWeb バイナリの他に icon として QtWeb.png と QtWeb.desktop をインストールするようにしています。インストール直後から KDE のインターネットメニューに表示されるようにしました。

o. QtWeb の起動
ports からインストールすると /usr/local/bin/QtWeb ができるのでそれを実行するのですが、実行後にできるディレクトリが美しくないです。以下の三つのディレクトリができます。

・$HOME/.QtWeb Internet Browser/
・QtWebCache/
・QtWebSettings/

一番上の .QtWeb Internet Browser/ は $HOME にできるので良いのですが、 QtWebCache/ と QtWebSettings/ はどこにできるかわかりません。実行したときにいるカレントディレクトリにできたりとか、ヘタするとあちこちに QtWebCache/ と QtWebSettings/ ができてしまうような感じです。orz
なお、メニューから QtWeb の設定を変更するとその内容は QtWebSettings/ に保存されます。

が、しかし、それにしてもこの二つのファイルはどこにできるのか解らない・・。orz
ソースコードを書き換えてやろうかと思ったほどですが・・。
なのでしょうがない。起動用にスクリプトを一個書きました。

#!/bin/sh

cd $HOME/.QtWeb\ Internet\ Browser
QtWeb > /dev/null 2>&1
#/usr/local/bin/QtWeb > /dev/null 2>&1
#cd  $HOME

 
$HOME/.QtWeb Internet Browser/ 配下に QtWebCache/ と QtWebSettings/ が作成されるようにするためのスクリプトです。
不便やのぉ・・。って感じなのですが、ソースコード的には browserapplication.cpp の数カ所を直せばちゃんとコントロールできるんじゃね? って感じはします。

 
こんな感じの QtWeb というブラウザなのですが、もしよければ皆さんもコンパイルして使ってみてください;-)。

 
あ。最後にですが、 Qt-Webkit は x-sjis と x-euc-jp には対応してないので文字化けします。 rekonq も konqueror も Qt-WebKit を利用しているのでやはり x-* な文字コードは表示できません。最近は少なくなってきましたが、今では僕が知っている有名ドコロは VECTOR が x-sjis を利用しているので表示できません。

この件については以前 KDE 方面で(その昔は) Nokia の Qt のコードを書いている人に聞いたことがあるのですが、非対応だそうです。するっていと同じ KHTML から派生の Apple-WebKit は独自に x-* な文字コードに対応した。と、いうことなのでしょうなぁ。

 
PC に色々ブラウザが入っていると楽しいですよ;-)。 是非、試してみてください。;-)

6月 122014
 

ウェブサイトを斜め読みしていたら「安くて良い音がするヘッドホンが Amazon で売っていて人気になっている。」とのことだったので僕も購入して試してみました。

僕が看過された記事はこちらになります。

http://av.watch.impress.co.jp/docs/review/minireview/20140602_650832.html

なるほど。良い感じなのね。ちなみに今回購入したイヤフォンは iPhone5 で利用する予定です。

現状、 iPhone5 で音楽を聞く場合には iPhone5 に付属の EarPods を利用しているのですが、それについて以前のエントリである「iPhone5 利用してみました。」と「EarPods にスポンジ付けてみました。」に書いています。今回購入したのが、この Apple 謹製の EarPods イヤフォンと比較してどう違うのか、僕の耳と僕の感性でレポートしてたみいと思います。

とわ言いつつ、そんなに音にうるさいということは全然、全くないのですけどねf(^^;;。

 
さて。 Amazon で購入したのは送料込み 3,980yen でした(すごいグッドなタイミング;-)。下にリンクつけておきます;-)。 Amazon からはダンボールな箱ではなく、袋に入っていて届きました。中から出してみましたがこんな感じ。

IMG_7170_BEB_868B_1

付属品としては説明書と、巾着袋。あと、耳あてのゴムの替えパーツがドドドと大量に、色々な形のモノが入っていました。 Audio-Technica のイヤフォンを購入した場合は大・中・小が入っていますが、今回の Blue Ever Blue 868B にはその他にもゴロゴロと色々なのが入っていました。

IMG_7171_BEB_868B_2

さて。実際に音を聞いた感じですが、比較対象として iPhone5 に付属の Apple EarPods とになります。上にある二つの前回のエントリでは EarPods はすげー。ってことに、僕の中ではなっているのですが、今回はどうなったでしょう? ちょっと明らかな違いを箇条書きにしてみますね。

・音の広がり方は Blue Ever Blue 868B のほうが断然良い
・重低音ドドドは Apple EarPods が勝ち

こんな感じでしょうか。上に掲載した URL を見てみると HDSS 技術が素晴らしい。と、書かれていますが、僕にはその技術がどういうモノかよく判りませんf(^^;;。

 
話はガラリと変わるのですが、 docomo の『d ミュージック』から購入した楽曲は AAC 320kbps で iTMS の 楽曲の 256kbps より音が良い。と言われますが、僕にはその違いが判りません。ただ、d ミュージックで購入した楽曲は iTMS で購入した楽曲より音が大きいような気がします。音が大きいと色々な音が拾えるようになるので、だから「良い音の楽曲」に聞こえるのかなぁ。などと個人的に思ってしまうんですけども。

 
さてさて。今回確認のために利用(試聴)した曲目も書いておきましょう。

AKB48 の「Everyday、カチューシャ」はイントロ部分の右側の聞こえない音が聞こえてきます。これは前回書きました;-)。「ポニーテールとシュシュ」は音の広がりが体感できます。メンバのハモッている声までバッチリ聞こえます。
Loudness の「Crazy Night」はイントロ部分はちょっと重低音(フロアバスの音)が抜けるかなぁ。あと、最近は angela の「シドニア」をよく聞いているのですが、この曲は Apple EarPods で聞いたときの音のほうが好きです。

あ。楽曲を作る人は、聴く人が持っている環境(プレーヤーやスピーカー・ヘッドホンなど)に音色を合わせて音作りをする。と、いう話を聞いたことがあるので、もしかしたら新たしめの楽曲は Apple EarPods に合わせてチューニングした音作りになっているモノも多分あるのでしょうなぁ。

それにしても、僕は基本的には重低音好きな人ということになりそうですねf(^^;;。あ。 Blue Ever Blue 868B は重低音が弱い。なんてことは決してないです。7,8 年前のイヤフォンに比べると全然良い感じの音です。そして、それにしても音の広がりについては圧巻です。

 
と、いうことで比較はここまで。

あと、物理的な構造に対しての好き嫌いもあると思うのですが、

・簡単にポロっと耳から抜け落ちてしまう Apple EarPods
・しっかりとしたアルミ筐体で耳にピッタリとフィットする Blue Ever Blue 868B
・ケーブルというかコードの作りはこんがらない素材を利用している Apple EarPods が勝ち
・Blue Ever Blue 868B は耳に入れたりするときにクシャっと音がするのは素材は解らないがコーン紙が圧力で音を立てているのかな?

これらのの四点を音の観点にプラスしてみても Blue Ever Blue 868B を常用したくなります。ただ、最後の一点はちょっと心配ですが、僕の持っている個体の問題なのかな?

そして、あと、一点。

・リモコン機能どうするの?

って話がありますが、僕の場合、 Audio-Technica の AT338iS を持っているのでこれを再登場させることにしました。 iPhone5 → AT338iS → Blue Ever Blue 868B と接続することになるのですが、間に AT338iS が入っても回路的な音の劣化は、僕の耳では感じられませんでした。

 
と、いうことで、 Apple EarPods も定価で購入すると 2,200yen 、 Blue Ever Blue 868B も 3,980yen と非常に安価で良い音が手に入ります(耳に入るのかな?;-)。

 
と、いうことで今回はここまでにしておきます。比較や試聴の対象として皆さんの手元にあるモノを例に取り上げてみました。この文章を書いた人(それはつまりは僕のことですが)は AKB48 好き。なんてことは多分・絶対に無いのではないかと思われます;-)。

 

5月 312014
 

そもそも Flightradar24 ってのはなんぞや? となるのですが、iOS アプリです;-)。

URL 的にはこんな感じ。
http://www.flightradar24.com/35.69,139.75/7

これが iPhone アプリだとこんな感じ。
https://itunes.apple.com/jp/app/flightradar24-pro/id382069612?mt=8

今回は iPhone アプリのキャプチャを撮ってみました。

アウトドア好きの僕にとって、夜、焚き火を見ながらバーボンをコプリと喉に流しているときなど、遠く上空からゴーっと音が聞こえると空を見上げ「あの飛行機はどこに行くのだろう?」と漠然と思うわけです。そんな時にこのアプリに出会いました。

IMG_7141Flightradar24_1

確か有料だったと記憶していますが、これで、自分の位置情報から上空を飛んでいる飛行機がどこからどこに向かって飛んでいるのかリアルタイムに確認できるんですね。すげー。夢とロマンがあるじゃん。みたいな感じだっんですけども。

で、今回久しぶりに起動して驚きました。確かちょっと前にバージョンアップしているんですが、下のキャプチャは羽田空港近辺の地図で Flightradar24 が検知している飛行機がワンサカ写っているんですね。

IMG_7137_Flightradar24_2

飛行機をタップすると地図上に線を引いてくれてどこの空港からどこの空港へ、そして通ってきた経路を表示してくれます。

これだけでも随分と楽しいのですが、飛行機が表示されている下のメニューに “3D” とかいうのがあります。これをタップするとあーた。キャプチャはこんな感じ。

IMG_7138_Flightradar24_3

なんか、その昔、こーいうゲームがあったような気がしますが、キャプチャの画面下には当該機のデータがリアルタイムで表示されていて、そのデータをもとにしてコックピットの風景を動画として表示してくれるんですね。

一番楽しいのが空港に着陸する瞬間でしょうかね。このキャプチャのように滑走路がズンズンと迫ってきます。
東京湾上空の飛行機も楽しくて景色がくるくる変わっていきます。町並みはあまり美しくはないですけどね。

 
Flightradar24 と、いうアプリはもう随分と前に購入したのですが、今回久しぶりに起動してみて、こんなに機能が充実しているとは思いませんでした。

飛行機好きな人、外で飛行機が気になる人はは是非ともインストールしたいアプリですね。おすすめです。今の価格は 300yen かぁ。僕は 200yen くらいで購入したような気がする;-)。

 
あ。僕的には随分と珍しいアプリケーションレビューのエントリでした;-)。