勤務先の複数部署が移転となり、栗橋から西新宿になりました。さらば田園風景...。
栗橋の 田んぼ恋しや 秋の風
栗橋では送迎バスに乗らず40分かけて歩くことが多かったので、こちらでもそうしていますが、普通の道では30分が限界です。街並みの。
サザンテラス口から甲州街道に出て、都庁の裏に入る道を北上し、中央公園を抜け、熊野神社で降りて北上...すると30分なのです。中央公園の北西角から方南通りで山手通りまで達し、中野坂上交差点から戻ってようやく40分。
40分といったら都市部の距離感では2駅分ですから、新宿駅～西新宿駅近くなんて場所でそんなに歩こうと思うのが無茶ではあります。そもそも靖国通りで新宿駅～秋葉原駅が1時間半～2時間ぐらいですから、都心の過密ぶりがわかるというもの。
ちなみに久喜駅からジグザグに歩き、ベルクを通ってジョイフル本田までが1時間でした。さらに杉戸高野台を越えて東武動物公園駅まで行けば1時間半ぐらいではないでしょうか。
さて新宿の地上は歩道が狭く(おまけに自転車が危険)、雨の日は地下道の利用が好ましいところ、台風22号が来たので挑戦してみました。
新宿西口の実は地下じゃないような気もする都庁行き道路から、都庁前駅に向かう地下道に入り、駅を越えて右に折れ西新宿駅で地上に上がるルート。新宿駅ホームを3号車から西口出口まで歩いたこともあり、所要時間は30分でした。
都庁行き地下道は、新宿駅西口地下で空が見える場所があったり、大江戸線の地下道に入る直前で屋根がなくなったりすることから、どうにも地下という感じがしにくいです。下から見ると人工地盤にしか見えません。
屋根は切れないものだと思っていたら、雨が降っているのが視野に入ってきて、それでも誰も彼もが前進し続けるのを見て、なんだかレミングの行進(俗説)にいるような気がしてしまいました。或いは「薔薇の復讐」ジプシー国の最期。
地下道という奴は無機質です。JRの駅近くは地下街と呼んで良い場所ですが、駅と駅の間は何もない通路でまさしくダンジョン。そういえば昔スタークラフトの「ファンタジー」でこんな細長い通路があったっけ、などと思い出しました。
役所(日本年金機構)がフリーメール不可だというので、実家のインターネット環境をホワイトBBから@niftyに変更しました。私の方のプロバイダで追加メールアドレスを取得する手もありますが、私が解約する時に困るので止めておきました。
まず、ネットで調べてみるとそのような情報が少し出てくるのですが、ホワイトBBには解約時に落とし穴がありました。
- 回線撤去日を指定できない(2〜6営業日後のいずれか)
- 回線撤去日を待たずに接続できなくなる(翌日)
要するに、接続できない期間は必ず発生し、しかも週末をまたがざるを得ないということです。
今回は7営業日後にイーアクセスの局内工事がうまく入りましたが、回線撤去の日程が不明だとNTTに承諾してもらえない場合があるそうで、そうなればさらに後ろに延びることになるでしょう。イーアクセスは今ではソフトバンクグループですが、特に融通が利くわけでもないとのことでした。
もう一つの注意点がイーアクセスにありまして、接続プロトコルがPPPoAなのですね。よく「イーアクセスはルーターをブリッジにできない」と言われますが、これはADSLモデム内蔵ルーターがブリッジ非対応なのではなく、市販のルーターがPPPoA非対応だからなのでした。
VPNを設置しておこうかと思ったのですが、今回は時間不足で断念しました。ルーターはWD701CVでしたが、然るべきポート(TCPの1723にGREの47らしい)を転送してBHR-4RVにでもPPTPサーバーを任せようかと思案だけはしているところ。
全体として問題というほどの問題はありませんが、旧MapFanが実用にならないほど遅くなりました。
音楽プレイヤーと歩きナビが主な用途ですから、このままでは困るので結局MapFan+に移行しました。ちょうどオフラインのダウンロード権が値引き中でしたし。でも縮尺が大きいとやはりダメでした。更新待ちです。
iOS6にするのは不可能でした。そういえばSHSHがどうとかJB界隈では言っていた気がしますが、JBする気はないのでこのまま行くしかありません。
(追記2013/10/01)
地図のオンライン/オフライン切り替えボタンなんてものが右上にあることに気付き、無事にMapFan+が動作するようになりました。これでiOS7移行は無事に完了です。
ルーターにDD-WRTを入れました。WZR-HP-AG300Hに米Buffalo謹製のProfessional Firmwareです。ルーター自身でMyDNS.jpを更新させるただそれだけのために。
ちなみに無線LANは社外ファームでは法令に触れるので使ってはダメだとか。送信出力を10dBmにすると同等らしいですが、法律がそうなっているとかで。
さてMyDNS更新ですが、先人の知恵により、サービス名を手動設定にした上でURLに"/login.html?"と記述すれば通りました。
ところがRC_IP_CONNECT_FAILEDが発生してダメになる場合がありました。色々調べていくと、どうもWAN IPアドレスの確認に失敗した場合のエラーメッセージのようでした。
DDNSクライアントinadynはデフォルトでcheckip.dyndns.org使っていました。これはリモートホストのIPアドレスを表示するだけのサービスで、DDNS更新のために用意されている物のようです。DynDNS以外で使われるのは迷惑だろうになあ、と思わなくもありません。
一つのホスト名に複数のIPアドレスが割り当てられている(DNSラウンドロビンとか呼ぶらしい)のですが、inadynは立ち上がるとDNSを一度しか引かないため、落ちていても余所に回りません。こうして接続できない場合にRC_IP_CONNECT_FAILEDが記録されます。
inadynを更新すれば回避できるらしいですが、せっかく米Buffaloが動作確認してくれたバージョンからずらすのも嫌ですし、inadynだけ更新も怖いので、外から何とかすることにしました。
そもそもルーター自身がWAN IPアドレスを把握しているのに、わざわざ外のCGIに調べてもらうなんておかしいだルルォ！？
というわけで、設定画面のInfo.htmからPerlでWANのIPアドレスを取り出して表示するcgiを設置しました。Perlなんて自分で書くのは初めてですが、こんな感じ(後述)で良いのでしょうか。
後は、これをDDNS設定画面の追加オプションで
--ip_server_name サーバーのLAN IPアドレス cgiへの絶対パス
とすればWAN IPアドレスの確認に使ってくれます。詳細はDD-WRT公式のこちらを。
DD-WRTにPerlを入れてしまえば1台で完結できますが、今のところはこのWebサーバーに設置しています。ルーターで完結していませんが、WAN IP確認はローカルで行なわなければならないものでもないので、おまけです。
クラスCプライベートIPアドレスを判別して上記仕組みを動作させ、それ以外なら相手のリモートIPアドレスを表示します(つまりcheckip.dyndns.org等と同じ動作)。
#!/usr/bin/perl
use utf8;
use LWP::UserAgent;
use HTML::TreeBuilder;
print "Content-type: text/plain\n\n";
my $ip = $ENV{'REMOTE_ADDR'};
if ($ip =~ /^(192\.168)/) {
my $ua = LWP::UserAgent->new;
my $req = HTTP::Request->new(GET => 'http://ルーターのLAN IPアドレス/Info.htm');
$req->authorization_basic('ユーザー', 'パスワード');
my $res = $ua->request($req);
if ($res->is_success) {
$tree = HTML::TreeBuilder->new;
$tree->parse($res->content);
$tree->eof();
my $ipaddr = $tree->look_down(_tag => "span", id => "wan_ipaddr")->as_text;
print $ipaddr, "\n";
} else {
print "ERROR.\n";
print $res->status_line, "\n";
}
} else {
print $ip, "\n";
}
勤務先で使っているMacBook MB062J/Bを新調しようとしています。何しろMountain Lion非対応。CPUだってMeromとか懐かしすぎるでしょう。
時期的にMavericksプリインストールのHaswell版MacBook Proが目前ですが、Retinaをどうしたものか。
メインで使うので自力で修理できた方がいいのです。実際、今までもRAMが1枚吹っ飛んだとか、HDDを載せ替えたとか、バッテリーを交換したとか色々ありました。
Retinaモデルは自力修理ができません。それでは困ります。SSDも速いのは良いですが容量が物足りません。非光沢パネルも選択できません。
Windowsのデスクトップ環境を併用する限り、Retinaの解像度は使いづらい面があるという副次的な要素もありますが、アップルにとって眼中にないでしょう。私も同感です。
そういうわけで15インチ非Retinaを本命視していますが、Haswell版は出るのか、出ないのか、終息するのか。
Retina一本化の流れなのはわかりきっています。しかしPCはiPad等と少し違うものですから...というユーザー側の言い分を考慮する企業でないのもまた。
できれば存続してほしいです。
Outlook.comがIMAP対応なんてニュースが飛び込んできたので、早速Thunderbirdの設定変更とフォルダのコピーをしました。
Microsoft的にIMAPのノウハウはいつの実戦投入可能と判断したのでしょう。Office 365が先行していましたが、同じ実装なのかに少し興味があったりします。
また、大陸からサイバー攻撃の可能性ありなんてニュースがあったものですから、MovableTypeを最近サポートが切れたオープンソース版4.38から5.2.7に更新しました。
テンプレートやプラグインで修正が必要なら面倒だなあ、と4.292からオープンソース版に切り替えていたのですが、特に問題なく移行できてしまいました。念のためVMWare上で構築して試したりもしましたが、拍子抜けしたぐらいでした。
元々MT5対応の4.3.8だったPageButeを、一応更新しておきましたが、その程度。
さらにMariaDBとApacheも更新しました。標的になりそうなこともほとんどありませんが、加害者にさせられては困るので一通り。
Apacheは2.2に移行した時にServerTokensとServerSignatureを設定し損ねていたのですが、Include conf/extra/httpd-default.confのコメントを外した上でそのhttpd-default.confの中を弄れば良いということで、久々に元に戻りました。でも2.4への移行準備もしないといけない時期なのでした。
どうしてもレトロにVHSへ出力せねばならない素材があり、どうしたものかと考えました。DVD経由、BD経由、ADVC-100経由...。アナログデッキ群はキャプチャ専用としてPCとしか接続されておらず、DVDにせよBDにせよ設置場所が遠いためそれら経由は面倒です。
というわけでADVC-100経由。iLife '06が入手できたのでMacで。iMovie HD 6はMountain Lionでも動いています。
10年ぐらい前にADVC-100を購入して以来、出力として使ったのはこれが初めてです。
10年! DVも廃れ、アナログソースも廃れ、カノープスもトムソン傘下となり、グラスバレーとなり、思えば遠くへ来たもんだ。
ADVC-100の背面が出力、前面が入力という配置は、DVカメラからPCに取り込んで、それを据え置きDVデッキに出力することを想定しているのでしょうか。一応、背面入力もありますが音声端子がミニステレオなのですね。
ちなみにMacでキャプチャした場合は拡張子dvとなりますが、これはMPEG StreamclipのMac版でDV-AVIに変換できました。設定の仕方がAdobeのフォーラムにあります。
- CompressionをApple DV/DVCPRO - NTSC
- SoundをUncompressed
- Field DominanceをLow Field First(テフォルト)
KeePass223mod.zip
Windows Script Host Object Modelを使いますが、yamamotoWorks様の記事を参考にInteropのDLLが生成されないようにしています。
さすがに某所のようにセキュリティコードごとカード番号が漏れたらどうにもなりませんが、パスワード漏洩は対策しなきゃしなきゃと思っていたところでした。
あの巨大掲示板の●と呼ばれる有料サービスは購入していたことがあります。専門ジャンルの過去ログがどうしても見たくて。今ほど過去ログサイトがなかった頃の話です。
私の個人情報は漏洩していなかったようですが、仮にしていてもカードは何年も前に解約してありますし、メールも捨てアドレスにしていました。ヤクザな場所にはそれなりの用心を。
PlayStation Networkの大規模漏洩の時は、パスワードは使い回しのものではありませんでしたし、カードも登録していませんでした。
今のところ被害はニアミスで済んできましたが、もたもたしていたお陰でKeePassという良ソフトに出会えました。クラウドに依らずMac版KyPass CompanionやiOS版MiniKeePassとデータベースファイルを共有しています。
そういうわけでKeePassを導入し、メールを引っかき回してアカウントを調べ上げ、パスワードを作り直して変更したのでした。
さてこの変更、本家にかけ合うべきでしょうが、経緯の確認もしなくちゃですね。
そもそもの発端は、SendInputでKEYEVENTF_UNICODEを指定すると、OSが気を利かせてIMEをONにすることのようです。未確認ですが内部でIMM経由だとか何とか(そのためIME依存?)。
KeePassのフォーラムでは当時、@に対してAlt+@が発行されるためにIMEがONになっているんだ、なんてことが書かれているのですが、全くそうは思えません。私の環境でAlt+@を押してもIMEはONになりませんが発生しています。
現実に最新2.23でも発生し続けていますし、Alt+@になっていたなら文字として"@"が入力されるはずがありません。
C#なのにKEYEVENTF_UNICODEなSendInputを使っている理由は、SendKeys.Sendが間違ったキーを発行する場合があるのを回避するためで、例えばキャレット(いわゆるべき乗記号"^")を送ろうとするとアンパサンド(アンド記号"&")になります。
言語或いはキーボード依存なのか、他にもあるのでしょう、きっと。それで8種類の文字を決め打ちでSendInput送りにしています。判別しているのはKeePass.Util.SendInputEx.OSSendKeysWindowsで、そこに2.18から"@"が追加されています。
簡単な回避法としてWshShellオブジェクトのSendKeysを使う手があるそうな。本気でやるにはVkKeyScanExとSendInputですが、元々KeePassはDirectInput対応などは考慮していないソフトですから、WshShellでいいのでしょう。
遅ればせながらNV-U75Vを手放そうとして、ACアダプタではVICSビーコンユニットに給電されないことを思い出しました。これでは動作確認ができません。手元のACアダプタを並べることしばし、12Vのものがあったので、DCプラグにスズメッキ線を突っ込みシガーソケットと接触させ、無事に動作させることができましたとさ。
もうちょっと不安定になると思いきや、接点が綺麗だと何とかなってしまうものです。
最近のコメント