2015年2月26日木曜日

Nintendo3DSが4周年

Nintendo3DSが発売から4周年となりました。
私は発売日に購入し、十分遊びつくしました。
実は昨年2014年は3DSのパッケージソフトは買っていないんですよね。
2013年末にキャンペーン開催に合わせて新旧織り交ぜて4本ほど購入して、
昨年はそれをちまちま遊んでいました。まだ一本積んでいるゲームが残っています。
今年はゼルダの伝説 ムジュラの仮面 3Dでもやろうかな。
ちなみにバーチャルコンソールやダウンロード専売ソフトは昨年もいくつか買っています。
ということで、世にはすでにNew Nintendo3DSも登場していますが、
今後特に遊びたいゲームもないため購入は保留しているところです。

正直3DSで一番楽しかったのは[すれちがいMii広場]だったりします。
が、しかし、すでにやることもなくなってきています。
ここ半年ほどで以下のようにやるべきことが達成されています。

2014/9/24 すれちがいガ~デン 花80種コンプ
2014/9/28 すれちがい迷宮 パズルボックスコンプ
2014/11/16 すれちがい伝説I 10周クリア
2014/11/21 すれちがい広場 3000人達成
2014/11/24 すれちがい合戦 別世界の国王と100回あいさつ達成
2014/12/4 ピースあつめの旅 2014/11/13配信分まで完了
2015/2/26 ピースあつめの旅 2014/12/25配信分完了までピンクピースのみであと8枚

今やっていることと言えば、ときたま新パネルが配信されるピースあつめの旅と、
ぼうし集めがあと2つ、すれちがい迷宮の2周目というところでしょうか。
すれちがい迷宮は現在2周目の38階にいるので
2周目をクリアするまではやろうかなとは思っています。
ぼうしについてはすれちがい合戦で別世界の国王と300回勝負すれば全部揃うことになります。
しかしまだ120回ほどしか勝負できておらず、
これまでのペースでならあと3年はかかるので達成は無理かなと。

あとは使い道はなくてもたまっていくコインをそのままにしておくのも何なので、
すれちがいガ~デンではじめての色の花を集めるのに使っています。
残りは120個くらいです。
一応続けてはいくつもりですが、地味な作業です。

2015年2月25日水曜日

ファイル分割

だいぶ前に分割されたファイルを受けとりました。
大容量記憶媒体が普及し、ネットワークが発達したこのご時世に、
なぜにファイルを分割なんかするのかと思ったのですが、
最近私自身ファイル分割するはめに陥りました。
たとえ16GBのUSBメモリであっても、
FAT32フォーマットだと1つのファイルのサイズの上限は4GB程度になってしまうんですね。
まったくこんなところに落とし穴があるとは。

Linuxのext4上に保管されている5GBの"x.tar.bz2"をFAT32なUSBメモリ経由で移動させたいなら
$ split -b 3G x.tar.bz2 x.
$ md5sum x.tar.bz2 > x.tar.bz2.md5
を実行します。
すると3GB程度の"x.aa"と"x.ab"、それにハッシュ値の"x.tar.bz2.md5"ができます。
これら3つのファイルをUSBメモリにコピーして移動させます。
移動先のLinuxにこれらファイルをコピーしたら今度は復元です。
$ cat x.aa x.ab > x.tar.bz2
で"x.tar.bz2"ができているはずです。
ただし、これだけでは元のファイルと復元後のファイルの内容が同一であることは保証されません。
そこで
$ md5sum -c x.tar.bz2.md5
でハッシュ値による確認を行います。

フロッピーディスクもMOも見かけることがなくなった昨今でも、
FAT32やRS-232Cなどレガシーはまだまだあります。
そういえばアナログRGB端子もまだ残ってますね。
5年後には廃止するとか毎年聞いているような気がします。

2015年2月24日火曜日

HTTP/2の足音

以前vpsのウェブサーバをSPDYに対応させていたので、
最近再インストールしたvpsの環境でもSPDY対応させようと思っていたら、
開発元のGoogleがSPDYのサポートを終了するとの発表をしてきました。
Chromeブラウザは2016年初頭にはSPDY非対応となるそうです。
ということで、vpsでのSPDY対応も止めることにしました。

ところでなぜSPDYを止めてしまうのかというと、もうすぐHTTP/2が登場するからです。
Chromeブラウザではver40以降で徐々に対応させていくのだそうです。
HTTP/2については3案出ていて、結局SPDYに近い規格に落ち着いたようですが、
近いうちにRFCが発行され、Apache等のウェブサーバが軒並み対応していくことでしょう。
vpsの環境はそれからアップデートすればいいでしょう。あせる必要はありません。

関連して、HTTPSからSPDYへのプロトコル切り替えにに利用されていたNPNが、
ALPNに移行することになるようです。
大きな違いは、NPNではサーバがサポートプロトコル一覧を送って
クライアントが選んでいたところを、
ALPNではクライアントがサポートプロトコル一覧を送ってサーバが選ぶという
逆の方式に改められていることです。
実はこのALPNはOpenSSL 1.0.2からサポートしているはずで、
1.0.2は先月出たばかりということで、
Googleの発表はこれを踏まえてのことなのでしょう。
OpenSSLも慌ててアップデートする必要もないので、
来るべき時までお預けということで。

ところでHTTP/2ではTLSが必須のはずなので
サーバ証明書の需要が増すかもしれません。
で、思い出したのはLet’s Encrypt。
今年夏から無料サーバ証明書の発行サービスを開始するそうですが、
HTTP/2導入のタイミングに合わせてということですね。なるほど。
ちなみに私がお世話になっているのはStartSSLです。

2015年2月23日月曜日

ServersMan@VPS(Ubuntu14.04-64)のウェブサーバ

ServersMan@VPS(Ubuntu14.04-64)のvpsでは
ウェブサーバとして最初からapache2が動いています。
これを調整してウェブコンテンツの公開等を行っていきます。
なお設定を変更したら、それを反映するために以下を実行しましょう。
# /etc/init.d/apache2 restart

まずはPHPのインストールです。以下を実行します。
# apt-get install php5
スクリプトを書くときに楽なので"<?"でPHPが開始できるよう
設定ファイル"/etc/php5/apache2/php.ini"を
short_open_tag = On
に変更します。

リクエスト処理中にURLの書き換えができるようにしておきます。
設定ファイル内でRewriteRuleディレクティブが利用できるようにします。
私は独自ドメインから外部のブログにリダイレクトするように
RewriteEngine On
RewriteRule ^/(.*)$ /redirect.php?file=$1 [PT,L]
などと設定したりしており、この機能は必須です。
余談になりますが、先の"redirect.php"の内容は以下のようになります。
<?
$file=$_GET["file"];
$url="<リダイレクト先URL>".$file;
header("HTTP/1.1 301 Moved Permanently");
header("Location: $url");
?>
話を戻して、とりあえず以下を実行します。
# a2enmod rewrite

またウェブブラウザからmanualディレクトリにアクセスできるのが鬱陶しいので、
以下を実行して無効にしておきます。
# a2disconf apache2-doc

AirDisplay@VPSはセキュリティ上問題になり得るので
# a2disconf proxy_ajaxterm
で無効にしてしまうのがいいのでしょうが、使えると便利なので、
ウェブページへのアクセスをパスワードで制限し、
SSL接続のみを許すことで安全を担保することにします。
# mkdir -p /etc/apache2/passwd
# htpasswd -c /etc/apache2/passwd/.airdisplay <ユーザ名>
でパスワードファイルを作成し、
設定ファイル"/etc/apache2/conf-available/proxy_ajaxterm.conf"のProxyディレクティブ内に
        SSLRequireSSL
        AuthType Basic
        AuthName "AirDisplay"
        AuthUserFile /etc/apache2/passwd/.airdisplay
        Require valid-user
を追加します。
ちなみにAirDisplay@VPSではApacheは8022ポートへのプロキシサーバとして動作します。
そのプログラム本体は"/usr/share/ajaxterm/ajaxterm.py"です。

ApacheではリクエストURLのホスト名により返すコンテンツを変える
バーチャルホストをサポートしており、それら各サイトの設定ファイル1つを
"/etc/apache2/sites-available/"ディレクトリに置きます。
デフォルトのhttpサイトの設定ファイルが"000-default.conf"、
httpsサイトが"default-ssl.conf"となります。
まずはこの2つのファイルのServerAdminディレクティブで
管理者のメールアドレスを設定します。
これらのファイルをコピーして他サイトの設定ファイル"<ホスト名>.conf"を作りますが、
最低でもServerNameディレクティブでホスト名、
DocumentRootディレクティブでコンテンツを置くパスを設定します。
実際にコンテンツを作成して
# a2ensite <ホスト名>
# service apache2 reload
を実行すればそのサイトが見られるようになります。
sslサイトについては上記に加えて証明書ファイル等の設定が必要になります。
私はStartSSLから発行してもらっており、
SSLCertificateFileにサーバ証明書、SSLCertificateKeyFileにサーバ証明書の秘密鍵、
SSLCertificateChainFileに中間証明書、SSLCACertificateFileにルート証明書を
適切に設定することで動作するようにしています。

最後に有名どころの脆弱性をチェックします。
Symantecのtoolboxでチェックすると、
HeartbleedもPoodleも大丈夫とのことですが、
SSL LabsでテストするとPoodleはあると言われてしまいました。
そこで、設定ファイル"/etc/apache2/mods-available/ssl.conf"の
SSLProtocol all
SSLProtocol all -SSLv3
に変更することで対策しました。
Poodleが世の中を騒がせてだいぶ経つので、
インストールイメージの修正は運営側でしてくれてるかと思っていたのですが、
どうやらこの辺りは自分でしっかりやっていかなければならないようです。
まあそれが面倒ならIaaSでなくPaaSを選ぶべきなんでしょうね。

2015年2月19日木曜日

2014年度の第二種電気主任技術者

第二種電気主任技術者試験の一次試験は、自己採点どおり予想外にも通過していました。
ということで二次試験です。
あまり受かる気もしなかったのですが、とりあえず無駄なあがきをして受験することにしました。
しかしそう時間も取れなくて、直前2週間で電験2種模範解答集 平成26年版
過去問2年分を見た程度という気持ち程度のあがきです。
が、見ていくうちにひょっとしたら受かるかもと思うようになりました。
電力・管理は出題された6題から任意の4題を答えればよく、
機械・制御は同様に4題中2題ということで、
合格ラインが50~60%であることを考えると、
前者は6題中2題を、後者は4題中1題を完璧にこなせば、
あとは部分点狙いで何とかなりそうだからです。
と言っても、今年じゃなく来年の話です。
何しろ来年は一次試験免除になるので早くから二次試験に集中することができるのです。

さて、試験当日受験地の大阪へ向かいました。
会場で掲示されていた受験番号によると、どうやら500人ほどの受験者がいるようですが
一次の受験者1200人ぐらいだったので一次の合格率はそう低くはなさそうです。
部屋に入ってみると結構空席が目立ちます。
私の受験した部屋ではざっとみて受験者は1/2以上2/3以下ぐらいに見えます。
思ったより欠席者は多かったですね。
安くない受験料を払い込んで、試験を受けないとはもったいない。
まあ、受かる気もしないのにやってきた地方在住者の私は
交通費を無駄にすることになるのでどっちもどっちなんですけどね。

で、先日二次試験の結果が届きました。
予想通りの不合格です。
どれくらい得点が取れたのかは分かりませんが、
受験から日が経っているので何を書いたかも覚えていません。
今年は一次試験が免除なのでだいぶ楽ではありますが、
これで落とすとまた一次試験からと考えると余計なプレッシャーがかかります。
でもきっと大して勉強せずに突入するんだろうな。

2015年2月18日水曜日

キーレスエントリーが効かない

9年目の車検を通した愛車WINGROAD。
キーレスエントリーの調子が悪く車検のついでに見てもらいました。

実は一昨年の冬の初め、寒い日の朝にキーレスエントリーをいくら押しても
車の解錠・施錠ができなくなりました。
昼間になって暖かくなるとちゃんと効きます。
その時点でキー内のボタン電池の電圧を確認してみましたが十分あります。
一応新品の電池に替えてみましたが、やはり寒くなるとだめ。
自分で分解掃除をしてみましたが改善せず。
そのうち春になって暖かくなると症状は一機に改善。
というかまったく問題ありません。
しかし季節が過ぎてまた冬になるとやっぱりまったく開かない、閉まらない。
もうあきらめてボタンを押すこともなく鍵を差し込んで回していました。

そんなときに車検です。
ディーラーで状況を説明すると電池を替えていいかと訊かれました。
その費用はボタン電池の相場からすれば高価ですが、まあ仕方ありません。
替えてもらうと…ちゃんと動作します。
その後も使ってみますが、寒くても大丈夫。
この2冬の苦労は何だったんだ?

で、思い当たることが1つ。
使ってたボタン電池は通販で購入した聞いたことのないブランドの激安品なのでした。
一方ディーラーが交換したのがPanasonic製。
本当の原因がどこにあるのかは不明ですが、激安電池の疑いは濃いです。
まあ夏は使えてましたし、記憶では1冬は使えていたので、
決して使えないということではないのですが、
安物買いの銭失いとはまさにこのことですね。

2015年2月17日火曜日

ServersMan@VPS(Ubuntu14.04-64)のDNSサーバ

初期セットアップを終え、その後のセットアップ作業に支障がないくらいになった
私のServersMan@VPS(Ubuntu14.04-64)。
まず行わなければならないのがDNSサーバのセットアップです。
独自ドメインを運用するためには権威DNSサーバを用意する必要があるためです。
まあ私の場合は独自ドメインのトップはgodaddyでホスティングしてもらっており、
vpsはそのサブドメインの権威DNSサーバとなってもらいます。
それではDNSサーバと便利なdigツールのインストールのため以下を実行します。
# apt-get update
# apt-get install bind9
# apt-get install dnsutils

次いで、"/etc/bind"ディレクトリに旧環境で使用していた自作dbファイルをコピーします。
私は所有する独自ドメインについて各ドメイン(サブドメイン)毎に
"db.<ドメイン>"のようなファイルを作成しています。
同じ"db.*"でも、"db.0"、"db.127"、"db.255"、"db.empty"、"db.local"、"db.root"は、
インストールされたファイルをそのまま使うことになります。
ちなみにdbファイルはざっくり言って以下のような感じになります。
$TTL 604800
<サブドメイン>. IN SOA <メールアドレス('@'は'.'に置換)>. <サブドメイン>. (
         1  ; Serial
    604800  ; Refresh
     86400  ; Retry
   2419200  ; Expire
    604800 ) ; Negative Cache TTL
;
<サブドメイン>. IN NS <vpsホスト名(FQDN)>.

<vpsホスト名> IN A <IPアドレス(IPv4)>
<vpsホスト名> IN AAAA <IPアドレス(IPv6)>.
www IN CNAME <vpsホスト名(FQDN)>.

続いて追加したdbファイルの登録です。
設定ファイル"/etc/bind/named.conf"の最後にdbファイル1つにつき1つ以下のような記述を加えます。
zone "<サブドメイン>" {
        type master;
        file "/etc/bind/db.<サブドメイン>";
};

それからセキュリティ対策を施しておきます。
稼働中のDNSサーバソフトのバージョンがバレないように、
設定ファイル"/etc/bind/named.conf.options"の"};"の行の前に
version "secret!!";
を追加します。
また、このDNSサーバはデフォルトではオープンリゾルバにはなっていないようで、
権威DNSサーバとしてだけ運用するのであればこれでいいのでしょうが、
いろいろなケースを想定し、自分自身からと、
vpnで使いそうなプライベートIPアドレス(IPv4)からの要求は通るようにします。
設定ファイル"/etc/bind/named.conf.options"の先頭に
acl "trusted" {
    localhost;
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;
};
を、"};"の行の前に
recursion yes;
allow-query { any; };
allow-recursion { trusted; };
allow-query-cache { trusted; };
を追加します。
なお、vps自身が利用するリゾルバは"/etc/resolv.conf"で設定でき、
デフォルトでServersMan@VPSが用意してくれているサーバになっています。
自身をリゾルバにしても差し支えはないでしょうが、
せっかくなのでそのままにしています。

その後
# /etc/init.d/bind9 restart
で再起動すれば作業完了ですが、
nslookupやdigでIPアドレスがうまく引けない等あれば、
ログファイル"/var/log/syslog"にエラーが出ている可能性があるので、
それを参考にしながら設定ファイルを修正すればいいでしょう。

2015年2月16日月曜日

Kindle for Mac/PC

これまで7冊ほど買ってみたKindleの電子書籍。
レイアウト固定系のコンテンツは画面が小さいスマートフォンだと読むのは結構厳しいですが、
分厚く重い本ではなく、薄くて軽いタブレットを持ち歩けばいいので重宝しています。
それでも用途によっては紙の方がいいかなと思うことはあります。
数ページ離れた内容を比較のため交互に見るなんてのは典型的な紙の本の長所です。

さて、タブレットで電子書籍を読めさえすれば、読書としては成立するのですが、
本の内容を参考にしながらPCで作業するなんて時は、
電子書籍もPCで読める方が作業効率がよくなります。
そんな私の希望がやっとかないました。
Windowsではしばらく前から読めていたのですが、
この度Macでも読めるようになりました。

というわけで、Kindle for Mac
ついでにKindle for PCをインストールして使ってみました。
双方とも使い勝手に違いはありません。
現在読んでいるページも他のデバイスと同期してくれますし機能的にはタブレット版と同様のようです。
が、操作にはやや難があります。
マウスでのスクロース操作でページをめくれるのですが、
その辺り雑に操作する私には1ページずつめくるのにかなり気を遣います。
PCの操作的には、ページを読みやすいように拡大表示させておいて、
スクロール操作で同一ページ内を移動する方が直感的なのですが、
もしかしてこれは旧世代の考え方なんでしょうかね?

2015年2月12日木曜日

Macでパスを通す

「パスを通す」という言葉を誰が言い出したのか定かではありませんが、
DOSを使っているころから使っていた記憶があるので、きっと一般的な言葉なのでしょう。
広辞苑にはないかもしれませんが。

Windowsならシステム設定の環境変数でPATHに追加すればいいですし、
大体のLinuxなら"~/.bashrc"で設定してしまいます。
ではMacではどうすればいいのでしょうか?

最初特に考えもせず存在しない"~/.bashrc"を新規作成して、中身を
export PATH=$PATH:<追加するディレクトリのフルパス>
としてログインしなおしてみたのですが反映されません。

いろいろやってみてダメだったので調べて見たところ
設定ファイル"/etc/paths"の1行に1ディレクトリがかかれており、
最後の行に追加すればいいことが分かりました。
ただしrootユーザしか編集できないので
$ sudo vi /etc/paths
のようにすることになります。

2015年2月11日水曜日

Accessで最適化

データベースは定期的に最適化する必要があります。
通常リレーショナルデータベース管理システムでは、
各テーブルからレコードを削除する際、実際にそのレコードを削除するのではなく
削除したことにするだけでお茶を濁します。
レコードの編集も、更新前のレコードを削除したことにして、
更新後のレコードを新たに追加します。
これは処理の高速化のための措置です。
しかし、削除したことにしたレコードはそのまま残っており、
データベースの実体が大きくなるという副作用があり、
それによりレコードの検索が遅くなってしまいます。
そこで定期的に最適化を行い、削除したことにしているレコードを本当に消す必要があります。
もちろん最適化はそれ以外の処理もしています。

大きなシステムでは夜間バッチ処理で最適化したりしますが、
小さなシステムでもやはり最適化は必要で、
個人で使うようなMicrosoft Accessも例外ではありません。

Access 2007でなら、開いたデータベースファイルについて
左上のOfficeアイコンのメニューから[管理]-[データベースの最適化/修復]を実行するだけです。
ただし、ファイルサーバに置いているデータベースについては他のユーザが開いていないときにしてください。
また最適化前にはファイルをコピーしてバックアップしておきましょう。
実は最適化前のファイルをそのまま維持する方法もあり、
データベースを開いていないときに先のメニューを実行すると、
最適化元データベースファイルを選ぶよう促されるので、
新しい最適化先データベースファイルを指定して新規作成できます。

定期的に最適化するのを忘れてしまいそうなら、
ファイルを閉じる度に最適化するように設定することもできます。
Officeアイコンのメニューから[Accessのオプション]を開き、
[カレント データベース]の[アプリケーション オプション]にある
[閉じるときに最適化する]にチェックを入れておくだけです。
閉じるのに時間がかかる可能性があるので個人的にはおすすめしませんが。
バックアップとセットで最適化する運用にするといいかもしれませんね。

2015年2月10日火曜日

ServersMan@VPS(Ubuntu14.04-64)の初期セットアップ

Ubuntu14.04(64bit)に入れ替えたServersMan@VPSのvps。
徐々にセットアップしていきます。

まずはsshでログインしないと何も進みません。
しかしsshサーバ側のフィンガープリントが変わっているため、ローカルから
$ ssh -p 3843 root@<サーバ名>
でログインしようとすると
Offending RSA key in /home/ttanimu/.ssh/known_hosts:<行番号>
の表示とともにエラーとなるため、
$  vi ~/.ssh/known_hosts 
で開いたファイルの<行番号>行目を削除していきます。
最終的にフィンガープリントを受け入れる("yes"を選択する)ことでログインできるようになります。
パスワードは初期化時に提示されたものです。

ログインするとプロンプトのホスト名が"localhost"になっていて格好悪いので
# echo <ホスト名> > /etc/hostname
を実行しておきます。多分リブート後に有効になります。
また”/etc/hosts”の各行の末尾にホスト名を追加しておきます。

常にrootで作業するのはセキュリティ的に問題なので、
普段使い用の一般ユーザを作っておきます。以下を実行します。
# groupadd <グループ名>
# useradd -m -g <グループ名> -G users -s /bin/bash -N <ユーザ名>
# passwd <ユーザ名>
ついでにrootのパスワード変更しておきます。
# passwd
作成したユーザアカウントでログインできることを確認します。
ローカルから以下を実行します。
$ ssh -p 3843 <ユーザ名>@<サーバ名>
今後はrootで直接ログインしないようにします。

インターネットに晒されているサーバへは、パスワードではなく、
電子証明書+パスコードでsshログインするのがより安全です。
ということで前回保存しておいた"id_rsa.pub"をsftpでサーバにアップロードします。
$ sftp -o port=3843 <ユーザ名>@<サーバ名>
でログインできます。
"id_rsa.pub"はホームディレクトリに置いたとして以下を実行します。
$ cd ~
$ mkdir .ssh
$ chmod 700 .ssh
$ cd .ssh
$ mv ../id_rsa.pub authorized_keys
$ chmod 644 authorized_keys
sshでログインし直し、電子証明書+パスコードでログインできることを確認できたら、
パスワードでのログインを禁止します。
同時にrootでのログインができないようにします。
設定ファイル"/etc/ssh/sshd_config"の
PermitRootLogin yes
PermitRootLogin no
に変更し、
#PasswordAuthentication yes
PasswordAuthentication no
に変更してリブートします。

次にAirDisplay@VPSでログインできることを確認しておきます。
ウェブブラウザから
https://<サーバ名>/airdisplay/?x=30&y=12
にアクセスし、ログインできることを確認します。
このAirDisplay@VPSはウェブブラウザからコンソールにログインできる
ウェブアプリケーションで、sshの設定をしくじってログインできなくなったりだとか、
ssh秘密鍵を持っていないときにログインする必要に迫られたりという場面では
大変役には立つでしょう。
内部的にloginコマンドを叩いているようです。
ただしセキュリティ的には穴ではないにしても壁が薄くなります。
いざというときの保険にもなるので無効にするのはちょっとおしいし、
ということで後々ウェブサーバの設定でセキュリティ強化を図ることにします。

ついでにちょっと毛色が違いますがShellshockの確認です。
これはbashの脆弱性で、
$ x='() { :;}; echo kiken' bash -c 'echo test'
の実行結果に"kiken"が表示されれば脆弱性があることになります。
幸いにして表示されることはなく、既に対応されたbashのようです。
とりあえずは安心です。

最後に以前の環境でバックアップしておいた
"etc.tar.bz2"、"home.tar.bz2"、"opt.tar.bz2"、"local.tar.bz2"、"var.tar.bz2"を
sftpで送信しておきます。置き場所は"/opt/old"ぐらいがいいでしょう。
ただし一般ユーザが"/opt"を扱い易いように
# chmod 777 /opt
を実行しておく方がいいでしょう。
なお、解凍は
$ tar jxf etc.tar.bz2
などとすればいいです。

2015年2月9日月曜日

Windows RTが終了

Microsoftの公式だか非公式だかよく分からない発表によると、
名前からして最初から徒花っぽかったWindows RTは、どうやら完全収束のようです。
2012年の発表当初からその用途に疑問を持っていましたが、
やはり世の中の多くの方は私と同意見だったということでしょう。

RTが生まれたその当時は、
いろいろな意味でiPadやAndroidに対抗できる得るタブレットには
ARM CPUを採用せざるを得なかったのは事実ですが、
過去のWindowsアプリケーションが動かないという時点で
Windowsである意義がなかったというのが実状でしょう。
x86系がタブレットにも載せられる方向で進化していくことは確実だったので、
Microsoft自身も短命に終わることは覚悟の上だったのかもしれません。

今秋登場すると思われるWindows10はARMにも対応し、
スマートフォンはARM版になると思いますが、
技術的には可能であってもARM版をタブレットに持ってきても
x86用デスクトップアプリケーションが動かなければ、
例えARM版が廉価に売れるとしても、
消費者に対してx86版との違いの説明が難しく、
マーケティング的に売りにくいのではないでしょうか。

ですが、ARM版Windows10にはIoTという新市場が待っています。
先日Raspberry Pi 2へのWindows10供給の発表もありましたし、
もしかするとMicrosoftはスマートフォンよりこちらに力を入れてくる可能性があります。

長く組み込み機器のエンジニアをしている私は10年ぐらい前から
人ではなく物がコミュニケーションをする時代になるんだと豪語したことがあります
(だれからも賛同が得られなかったし、
自分自身もキラーアプリケーションがなんなのかは分からなかった)が、
Androidが発表されたときこれこそが物のコミュニケーションに
使えるのではないかとも思ったものですが、
Androidは当初の予想とはかけ離れた方向に走り出してしまいました。
もしWindows10がそこにきてくれるのなら私は大歓迎です。
Windowsのアプリケーションを作ることがなくなって久しいのですが、
Visual Studioが無料で使えるようになったことですし、
何か作ってみるのもいいかなと。

ということで今狙っているのは長野県飯山市へのふるさと納税でもらえる
Windows8.1搭載タブレットWN801V2-BKです。
これがWindows10にアップグレードできることが確認できたら寄付しようかと。
ただ、薄給で住民税も少ない私では寄付の上限金額を越えてしまい
実質2000円で入手はできないので、その辺り見極めながら決断するつもりではいます。
ついでですが、Raspberry Pi 2は対応するWindows10が出てから買えばいいかなと。
なにしろ初代Raspberry Piがいい使い道がなく埃をかぶっていますから。

2015年2月5日木曜日

Super Bowl XLIX

NFLの2014年シーズンを締めくくる Super Bowl XLIX が開催されました。
記憶に残るものすごい試合でした。
録画した方ももう視聴済みとは思いますが、
以下には試合結果が書かれていますのでご注意を。
なお、今回私はどちらかというとペイトリオッツを応援していましたので、
そういう目線になりぎみにはなっています。

コイントスに負け、最初に攻めるのはペイトリオッツとなりました。
ゲーム前、私は
ペイトリオッツはTEグロンコウスキーに戦術的にミスマッチを作り、
ミドルパスを軸に攻めるのが有効ではないかと考えています。
と書きましたが、
ペイトリオッツは短いパスを中心に攻めていきます。
ランは織り交ぜるにしても中長距離のパスは見られません。
序盤にロングパスを見せなかったのがわざとなのか、
余裕がなくできなかったのかは分かりませんが、
多彩なプレーを横に散らすことで
シーホークスD#に的を絞らせないことには成功したようです。
しかし10ヤードを3回の攻撃で獲っていくような展開では、
そう低くない確率で止まってしまうのは仕方なく、
実際ファーストシリーズは2回目の1stDown更新できずパントで終わってしまいます。
次の攻撃シリーズではランアフターキャッチで稼いで
3rdロングにすることなく順調に進んでいきます。
しかし、エンドゾーンまで10ヤードに迫った3rd&6の場面、
それまでもっていたパスプロテクションが2人を漏らしQBブレイディに襲いかかります。
苦し紛れにこのゲームこれまでの最長のパスをエンドゾーンへ投げ込みますが、
そこに味方はおらずインターセプトされターンオーバー。
ブレイディはポケット内にいたようなのでインテンショナルグラウンディングを避けようと
サイドライン方向への投げ捨てをしなかったのかもしれませんが、
FGは十分決まる距離だったのでそのままサックされてもよかったかと。
かなり不用意なパスでブレイディは調子がいいのか悪いのかよくわかりません。
もしここで点が入っていればゲーム展開はまったく変わったでしょうね。

ところでQ1のシーホークスO#はというとRBリンチのランをベースとして…
ではなくほぼRBリンチのランのみで攻めます。
それ以外ではQBスクランブルが2回あり、パスは1投もしませんでした。
ペイトリオッツに時間をしっかり消費されたにしても偏りすぎでしょう。
どうやらDEニンコビッチが一人でうまくQBウィルソンをスパイし抑え、
オプションでのQBランを選択できなくしていたようで、
リンチのラン一辺倒になり、それを人数をかけてうまく止められたようです。
シーホークスO#攻略のお手本のようです。
ということでQ1は両チームとも無得点で終わります。

続くQ2も同様の展開です。
ペイトリオッツは進むときは進んで2TDに結びつけます。
特に2つ目はTEグロンコウスキーのミスマッチを利用した私お勧め(?)のプレーでした。
まあ距離は30ヤード弱と長かったですが。
シーホークスはやはりリンチのランを抑えられますが、
ルーキーWRマシューズへの44ヤードパスで大きく前進し、
エンドゾーン前10ヤード付近とチャンスをつかみます。
こうなればリンチのランが効きます。
一度のキャリーではそう距離は稼げませんが3回持たせてTD。
シーホークスはQ2残り31秒の場面でも、
残りタイムアウト3つ、自陣20ヤードから攻撃開始。
ペイトリオッツD#はウィルソンのQBランを捕まえられず25ヤードほど失い、
さらに痛恨のフェイスマスクを犯しエンドゾーンまで11ヤードまで迫られます。
残り時間6秒で1stDown。定石ではエンドゾーンへのクイックなパスを試して、
だめならFGというところでしょう。
で、そのパスをまたもマシューズがキャッチ。TDで14-14の同点で折り返します。
もしシーホークスが勝ったならこの時点でのMVP第一候補はマシューズでしょうね。
ところで、このマシューズへのTDパス、
ついていたCBがルーズに守っていたのは疑問です。
時間が時間だけにパスインターフェアランスを取られて
エンドゾーン前1ヤードから攻められたとしても、
シーホークスはFGを選択した可能性がありますし、
リンチのランがきても止めて無得点に抑えられたかもしれませんでしたし。
もっとべたべたにいくべきだったでしょう。

前半はペイトリオッツがショートパス中心で堅実に攻めたのに対し、
シーホークスはランがそれほど出ないもののビックゲインで食らいつくという対照的な状況でした。
モメンタムはペイトリオッツ側にありそうですが、一瞬でひっくり返る危うさが感じられます。

さて、今年のハーフタイムショーはケイティ・ペリー。私の知らない人です。
いつもだとそっち方面に疎い私でも知ってる人が出てくるのですが。
気になったのは最後の曲で彼女の手とマイクを結んでいたのが
Wiiリモコンストラップぽかったことです。

後半はシーホークスの攻撃からです。
前半終盤の流れそのままに、リンチのランは相変わらずそれほど出ないものの、
またもマシューズにロングパスが通ってFGで3点加えます。
その次のO#ではリンチとQBスクランブルでのビックゲインがでてTDパスで7点加点。
このTDパス、CBリービスはWRボールドウィンのアクロスパターンに
マンツーマンでしっかりついていたものの、
審判(アンパイア?)と交錯してレシーバーをオープンにしてしまうという不運に見舞われました。
一方のペイトリオッツは攻めあぐねます。
フィールド中央でオープンになって止まったグロンコウスキーへのパスをインターセプトされ、
これが先のTDにつながりました。
このインターセプトのパターンはプレイオフでもありましたし、
インターセプトにはならなかったものの
このゲームのQ2にもWRエデルマンで似たようなシーンがありましたし、危険な香りがします。
その後はプレイオフでブロンコスのQBペイトン・マニングが見せたような
やけくそぎみのロングパスも見られ、結局3&out。嫌な予感がしてきました。
Q3残り3:15で24-14とペイトリオッツは10点のビハインド。
その後は両チームとも3&outが続きます。

Q4残り12:10でペイトリオッツに攻撃権が回ってきますが、サックを喰らい2nd&18。
時間的にも点差的にもペイトリオッツの逆転は十分に可能ではありますが、
諦めムードも漂い始めました。
しかしここまでまったくダメだったロングパスがWRエデルマンに通り、
これで息を吹き替えします。
相手の反則にも助けられますが、
ブレイディーが前にステップすることで局面を打開し、TDパスまでこぎつけます。
3点差に迫られプレッシャーのかかったシーホークスは、
ロングパスを多投するもインコンプリートで3&out。
その後のペイトリオッツはBRバリーンのワンハンドキャッチや、
グロンコウスキーへのミドルパス×2でTDパスまでもっていき24-28と逆転します。
残り時間は2:02、4点を追うシーホークスは自陣20ヤード地点からTDできなければ敗北です。

もはやリンチのランでチンタラ進んでいられない状況。
シーホークスはエンプティでパス攻撃。
で、WRの位置にセットしていたリンチがレシーブし、
ランアフターキャッチで敵陣49ヤードまで入ってきます。
ここで2ミニッツウォーニング。残り1:55秒で時計が止まります。
とにかくTDが必要なシーホークスO#はパスパスパス。
そしてWRカースへ運命のロングパスが放たれます。
しっかりとカバーされされており、ボールを弾くのがやっとでしたが、
なんとカースの体でバウンドして地面にはつかず、そのままパスコンプリート。
SuperBowlXLIIのヘルメットキャッチが思い出されます。
って、あれをやられたのはペイトリオッツで、しかも会場も同じフェニックス大学スタジアム。
ペイトリオッツの負けフラグは立ったも同然です。
残り1:06でエンドゾーンまで5ヤード。
デジャブじゃないですが、リンチのラン×3でTDはほぼ確実です。

こうなるとペイトリオッツがどうするのかに注目が集まります。
思いつくのは、すぐにわざとぎみにTDを奪われて時間を1分残し、
最後のO#にすべてを掛けるパターンです。
この戦術はいつかのSuperBowlで見たような記憶があります。ジャイアンツがらみでしたっけ?
幸いなことに3点差ならFGで同点に追いつきオーバータイムに持ち込めますし、
あわよくばTDで再逆転で勝利となります。
復調ぎみのペイトリオッツO#なら可能性はあります。
が、ペイトリオッツはD#で止めることを選びました。どっちにしても博打です。
で、シーホークスは予想を裏切ることなくリンチのランで攻めてきます。
これで残りは25秒と1ヤードと4thDownギャンブル含めての3回の攻撃。
迷わずリンチにハンドオフと思いきや、プレーコールはパス。
ペイトリオッツD#としてはTDを奪られれば負けはほぼ確定で、
レシーバーをマンツーマンして他の全員で中央のランを止めにかかるのが見え見えです。
その逆をついてパスというのは悪いプレーではないのですが、
レシーバーがクロスするのを見越して回り込んだSSバトラーが会心のインターセプト。
一見エンドゾーン内でのレシーブなので、
そのままダウンすればタッチバックで自陣20ヤードからの攻撃になりますが、
多分奪った瞬間はエンドゾーン外だったので、
バトラーは少しでも前に出ようとしました。
もし刹那にそう判断したのなら非常にクレバーです。

逆転は何とか阻止したペイトリオッツも、自陣1ヤード、残り20秒の場面では
時計を進めるためにニーダウンしてもセイフティで2点献上してしまいます。
そうなれば2点差、攻撃権はシーホークスに移りFGで逆転負けです。
このケースなら、QBスニークで少しだけ前に出つつ時間を流すのが最善策でしょうが、
シーホークスD#としてはあからさまにファンブルリカバーTDを狙ってくるのでリスクはあります。
SuperBowlXLVIIでレイブンズのパンターが見せたように、
ブレイディがボールを持ってエンドゾーン内を逃げまくってできる限り時間を使って、
わざとセイフティにしてしまうという手もあります。
普通のパスプレーのごとくパスプロテクションで時間を稼げるので
あまりあからさまではありませんし、投げ捨ても可能なので、
1プレーあたり7秒稼げれば3回で20秒消費できて勝利というストーリーです。
しかしドラマはあっけなく幕を引きました。
ファンブル狙いの超前のめりシーホークスD#がハードカウントに引っかかって
エンクローチメントを犯し5ヤード罰退。
後ろに余裕のできたペイトリオッツは当然ニーダウン。時計が回ります。
シーホークスは最後のタイムアウトで時間を止めますが、
プレー後グロンコウスキーにアービンが手を出したのをきっかけに
両軍入り乱れての乱闘。
結果アービンは退場に、シーホークスはアンネササリーラフネスで15ヤード罰退。
勝負は決しました。
28-24でペイトリオッツは10年ぶりにSuperBowlを制覇しました。
試合後の紙吹雪は例年勝利チームにちなんだ3色になっていますが、
今年は直前までどっちを撒くか切り替えが大変だったのではないでしょうか。

MVPはQBブレイディでした。
勝利のインターセプトをしたバトラーでもよかったかもしれませんが、
O#、D#、スペシャルチームとも突出して活躍した選手はいませんでしたから、まあ妥当かな。
かなりの好ゲームだったSuperBowl XLIX、BDに焼いておくことにします。

2015年2月4日水曜日

ServersMan@VPSの再インストール

もう4年以上使っているServersMan@VPS。
未だDebian5の32bitを使っているものの、いろいろと不都合も出てきています。
最近になってさくらのVPSから初期費用1000円、
月額635円の[512プラン]なるものも出てはきましたが、
やはり最安値のServersMan@VPSの[Entryプラン]を使いつづけることとし、
そして新しいOSで環境の再構築をすることにしました。
お誂え向けなことにUbuntu14.04 LTSも使えるようになり、
選ぶOSは当然Ubuntu14.04 LTS(64bit)です。
今後4年間はそのまま使えます。

最初に現状のバックアップです。
VPSの"/etc"、"/home/<ユーザ名>"、"/opt"、"/var"、"/usr/local"を
まるごとバックアップしておきます。
基本的にこれら以外に手動で追加したり編集したりしたファイルはないはずです。
以下を実行して"/tmp"ディレクトリに作成された"*.tar.bz2"ファイルをsftpでローカルにダウンロードします。
ここで"/var"内を大胆に削除していますが、これは直後に初期化してしまうことが前提なのでご注意を。
$ su -
# cd /
# tar jcf /tmp/etc.tar.bz2 etc
# tar jcf /tmp/home.tar.bz2 home/<ユーザ名>
# tar jcf /tmp/opt.tar.bz2 opt
# tar jcf /tmp/local.tar.bz2 usr/local
# cd /var/log
# rm -rf *
# cd /var/cache
# rm -rf *
# cd /var/spool
# rm -rf *
# cd /var/lib
# rm -rf *
# cd /
# tar jcf /tmp/var.tar.bz2 var
またssh接続用の公開鍵ファイルは別途ダウンロードしておきます。
私の環境では"~/.ssh/id_rsa.pub"になります。

準備が整ったらいよいよマシンの初期化です。
DTIのサイトでmyDTIにログインし、
[契約中サービス]タブの[ServersMan@VPS Entryプラン]の[確認・変更]ボタンをクリック、
続いて[各種初期化]ボタンをクリックします。
OSの変更後を[Ubuntu 14.04 LTS (64bit)]にして[サーバの初期化]ボタンをクリックし、
さらに[実行]ボタンをクリックします。
IPアドレス(IPv4/IPv6)とrootアカウントのパスワードが表示され処理が開始されます。
もしIPアドレス(IPv4/IPv6)が以前のものから変わっていると、
DNSサーバの設定変更をする必要があるので待っている間にやっておきましょう。
今回のケースでは必要ありませんでしたが。
10分ほどで処理が完了し、自動的にvpsが立ち上がりました。
最後にDTIのサイトにログインして[CPU倍増]をONしておきましょう。

2015年2月3日火曜日

固定電話の転送

固定電話にかかってきた通話をどこかに転送することは可能です。
NTTならボイスワープという有料サービスを使用することになります。
自力で何とかすることも可能です。
過去私は中古小型デスクトップPCを激安で手に入れ、
Linux+Asteriskで家庭内PBXを構築していました。
これにそれなりのモデムカードを挿してアナログ電話回線を収容し、
IP電話をその電話回線経由でPSTNに乗り入れていたこともありました。
知識と機材があれば何とでもなったのです。

時は流れて昨年PanasonicからVE-GDW03DLが登場しました。
単なる家庭用コードレス電話なのですが、
WiFi経由でスマートフォンをIP電話にしたてて子機にできるようになっていました。
これだけだと私にとっては何てことない商品なのですが、
先日その改良版VE-GDW54DLが登場し、
これにはちょっと興味があります。
なんと、スマートフォンを家庭内の子機としてだけでなく、
転送することで出先でも着信できるようになったのです。

それを実現する方法はそう難しくありません。
VE-GDW54DLの親機はアナログ電話とFUSION IP-Phone SMART(インターネット経由)の
合計2回線を外部接続回線として持っていて、アナログ電話で着信した通話を
IP電話側で任意の番号に発信することで転送を実現しているようです。
その発信先をFUSION IP-Phone SMARTのIP電話(スマートフォン)にすれば、
FUSION網内の通話は無料なので料金が発生しないというからくりです。

私はFUSION IP-Phone SMART回線を3つ持ち、
VPSを組み合わせたりしていろいろなことをやっていますし、
技術的には興味がないのですが、
一般の方でもこれができるようになるということについて興味があります。
これを電話機メーカーがやるのは両刃の剣と考えているからです。
というのも、FUSION IP-Phone SMARTで050番号を取得し、うまく使えば、
固定電話もコードレス電話機も必要なくなり、
一般の方がそれに気付くことで市場が萎む可能性を孕んでいるからです。
複数のFUSION IP-Phone SMART回線を持っていて、
転送を使用するだけでも十分実用になりますし、
VPS+Asterikなインターネット上のマイPBXを駆使すればかなりのことが実現可能です。
なんならtwilioを組み合わせてもいいでしょう。
一番の障壁は固定電話の番号を失うことでの厄介事でしょうが、
電話番号を変更せざるを得ない引越しは十分その機になります。
地味な出来事ですが、これが固定電話の終わりの始まりになるかもしれません。

2015年2月2日月曜日

過去を切り捨てるYouTube

YouTubeから一部の古い YouTube アプリのサポート終了がアナウンスされました。
過去いろいろなAV機器メーカーが、自社のテレビ等でYouTubeが見られるように
専用アプリケーションを搭載してきましたが、
それらが機能しなくなる日は製品寿命より前にくることになりました。
私にはもっと便利な視聴環境があるので
わざわざそれらアプリケーションを使うことはなく、影響は皆無なのですが。

そもそも独自ハードウェアの独自プラットフォーム上に
メーカーがお金を払ってそれらアプリケーションを作って載せさせてもらい、
すでに消費者等に売ってしまって後は金銭的な利益を生まないので
修正や更新は理論上はできたとしても、実質的にはできないという
未来のない製品を作ってどうするんだろうと昔から考えていました。

メーカーもアプリケーションの持続性を考慮し始めたのか
より汎用的なプラットフォームの使用を考え、
最近発表されたスマートテレビを見ると、
SonyがAndroid、PanasonicがFirefox OS、SamsungがTizen、LGがWebOSと、
妙なところで独自感を出しています。
ただ、サードパーティーアプリケーションの集まり具合で言えば、
Androidの一人勝ちのような気がするので、
将来的には結局Androidに集合とかいうオチになりそうな気がしています。

そのAndroidにしても決して将来安泰というわけではなく、
Google TVが切り捨てられたように、未来はどうなるかは分かりません。
仮にAndroid自体が順調に進化していくとしても、
現在のAndroidスマートフォンと同様にファームウェアのアップデートが行われるわけではなく、
むしろレガシー化してからの期間の方が長いことが予想され、
結局取り残されることになるでしょう。
スマートフォンなら2年で買い替えも許されるのかもしれませんが、
テレビとなると10年は使うでしょうから。

ということで今私がテレビを企画するなら、
地デジ/BS/CSのチューナーさえついておらず、そのかわりHDMI入力端子が10個付き、
電源と音量と入力切替が操作できるだけのブルーレイレコーダなどのリモコンに
ペタッとくっつけられるような簡易的なリモコンを3個ぐらい追加でつけた、
PCモニタに近いものを考えるでしょう。
上位機種はMiracastでもつけて、4画面分割表示にも対応させるかな。
つまり映像の表示と音の出力以外の機能は全面的に外部機器に頼るということです。
そういう割り切った商品、潜在顧客は少なくないと思うんですけどね。