hidekiy blog

ping による疎通は確認できるのに、いざ ssh などで繋ごうとすると No route to host というエラーで即座に接続失敗し途方に暮れる場合、おそらく原因は接続先のホストの iptables によりパケットがブロックされ、到達不能を意味する ICMP パケットが返ってきたことによります。 以下のコマンドで INPUT ポリシーをチェックします。上から順にマッチさせていき、マッチし次第ジャンプして終わるので、デフォルト条件の設定されていそうな一番下の行が肝心です。 # /sbin/iptables -L --verbose を追加してブロックしているポリシーのカウンタを見ながらブロック状況を観察できます。 # /sbin/iptables -L --verbose おそらく問題となっているのは INPUT ポリシー最下行で全てのパケットにマッチするこういう行です ... -j REJECT --reject-with icmp-host-prohibited 追加の説明 ファイアウォールの良くある動作として、不都合なパケットの受信を単に無視する動作ならタイムアウトとなります。しかしクライアントから見て TCP や UDP でパケットを送信した後、ICMP で Destination Unreachable Message が届いたときは親切にも No route to host と案内してくれるようです。 ちなみに icmp-host-prohibited は ICMP Unreachable Message の コード10 であり、経路上の障害などを調査するためのコマンド traceroute の結果に !X や !10 と表示されるようです。 参考 Man page of IPTABLES traceroute - Wikipedia Internet Control Message Protocol (ICMP) - Wikipedia

スタートメニューは一体どこへ消えたのかというと、全画面化して「スタート画面」アプリになったと考えると理解しやすいと思います。 旧スタートメニューの「すべてのプログラム」相当の画面はスタート画面から右クリックして下に出るメニュー右端、もしくは右下または右上隅からチャームを出して検索からアプリを選択すると出てきます。 結局のところ全てのアプリは全画面表示となり、デスクトップも一つの全画面表示アプリであり、Windows 7 以前のアプリケーションを継続して動作させるための互換性維持のために存在するアプリであって、必要なければ使わなくてもよい、という意味だと思います。

ふと思い立って Windows 8 Release Preview をデュアルブートでインストールしてみた感想を書いておきます。手順は最初にパーティーションを縮小して新しい領域をフォーマットし、ISOイメージをUSBメモリに書き込んでブートしてインストールしました。インストール時に高度なオプションみたいな感じで任意のパーティーションにインストールできます。 結局のところ全体的にいい感じで互換性も十分に確保されているように思ったのでクリーンインストールしようと思います。 セキュアデスクトップ遷移が瞬時に終わる 権限昇格確認時に登場するセキュアデスクトップの使用頻度が通常低いためか常にスワップアウトされてるんじゃないか？っていうもっさり感が大きく改善されているようです。 スタートアップアプリを誰でも気軽に殺せる 行儀の悪いアプリはタスクマネージャーからどんどん無効化して欲しいという意図を感じます。Autoruns を使わなくとも、IEのアドオンの管理から無効化する感じでスタートアップアプリ(スタートメニューのスタートアップだけでなく、レジストリから起動するものも含む)を簡単に無効化できます。 エクスプローラーのお気に入りがフォルダ的に動作する Windows 7 のエクスプローラー (MS純正ファイラー) のお気に入りという所を活用していていまいち不便なのが選択した瞬間に実のフォルダを開きなおす動作でチラついていらいらしたり、やっぱりお気に入りのもう一つ下を開きたかったときに上にスクロールする必要があるのがイマイチだったので。 画面遷移のアニメーションに酔わない Windows 7 よりアニメーションが平面的で、奥行き方向に動かない様になって酔いにくく快適です。 Windows Defender の強化 最初から入ってる Windows Defender が Microsoft Security Essentials 相当に機能強化されているようです。 MSE が気に入っているのでこの変更によりそのまま使えるのが良いです。しかしメーカー製PCでは大人の事情により期限付きウイルス対策ソフトが入っていて、期限後アンインストールを要求するとは思えず、代わりに身代金を要求する可能性が大ですｗ シャットダウンが設定の中に隠されてる PC...

Heroku や Google App Engine などのWebアプリケーションを無料からホストしてくれるとてもありがたいサービスで、自分しか使わないデモアプリなどを置いている場合、久しぶりにアクセスすると、そのアクセスしたタイミングでやおらアプリケーションのインスタンスが立ち上がるのでしばらく(数秒程度)待たされます。 この動作があまり格好良くないので、何とかする方法を考えたところ、Webサイトの死活監視を無料で50サイトまで行ってくれるとてもありがたいサービス Uptime Robot を使って監視しておくと、定期的にアクセスしてくれるのでとても快適に動くようになります。ついでにダウンタイムも分かります。 もちろん世の中の全てのホストされているアプリをこのようにしてしまうとメモリ資源が無駄に必要になると予想されるので、良い子は監視対象とするのは必要な分だけにしましょう。 蛇足として Google App Engine では静的なファイルは Google CDN から配信されるのでアプリケーションがレスポンスを出すような URL を設定する必要があります。

Express では app.configure を使うことで、NODE_ENV の本番環境 (production) 、開発環境 (development) の指定に応じて処理を分岐して設定を行うことができます。今回は具体例として、ミドルウエアを淡々と app.use(fn) で追加していく場合を考えます。 この時 app.use() が呼ばれる順番の通りに app の内部状態が設定されるので、production, development の両方に共通したミドルウエアを末尾の方に追加するには、適切なタイミングまで待ってから fn が呼ばれる app.configure(fn) を使う必要があります。app.configure も呼ばれた順番を尊重してコールバック関数を呼ぶことに要注意です。 また他にも、複数の場合に対応する app.configure(env1, env2, ..., fn) もOKです。NODE_ENV が存在しなかった場合のデフォルト値は development です (express/lib/http.js)。 var express = require('express'), app = express(); app.use(function (req, res, next) { console.log('1. before config'); next(); }); app.configure('development', function () { app.use(function (req, res, next) { console.log('2. development'); next(); }); }); app.configure('production', function () { app.use(function (req, res, next) { console.log('2. production'); next(); }); }); app.configure('dev...

Node.js の Web Application Framework の一つである Express において、リクエストハンドラ第三引数の next の使い方について調べてみました。結局のところこれは一体何なのかというと、next の中身は次にリクエストを処理するべき関数を呼び出してくれる関数オブジェクトです。物好きな人用の説明なら、req, res の状態を持って次のリクエストハンドラに goto する continuation のイメージです。 実際にどのように使うかと言うと、何らかの理由でレスポンスを返さない場合に next() という感じで関数呼び出しを行います。引数として、自分のところで対処できないエラー (例外) が発生した場合はエラーオブジェクトを渡し、エラーはないけれど自分のところで対処するべきリクエストでない場合は引数なしで呼び出します。 エラーが発生した場合に適切に伝搬させるの例 var express = require('express'), app = express(); app.get('/error_sync', function (req, res, next) { next(new Error('sync error')); // この場合は throw new Error('sync error') でもOK }); app.get('/error_async', function (req, res, next) { setTimeout(function () { next(new Error('async error')); }, 100); }); app.listen(3000); 自分のところでは対処しないの例: リクエストのパラメータが3の倍数の場合 aho と返す。 var express = require('express'), app = express(); // 例えば http://localhost:3000/say/31 を開くと？ app.get('/say/:num', f...

画面のキャプチャなどを JPEG で保存すると色が急激に変化するところの周りにもじゃっとしたノイズが乗るので通常 PNG で保存すると思いますが、何も考えず保存するとおそらくRGB各色8ビット(True Color) でアルファチャンネルなしの1ピクセルあたり24ビットのファイルが出来上がります。ネットも速くなったので通常これでクライアント側は困ることはないと思いますが、配信側の都合上転送量を削減したいなど極限まで絞りたいという場合は、もっと効率的なビット割り当てで同じような見た目になる インデックスカラー を検討してみる価値があります。 インデックスカラーとはピクセルごとにRGB値を記録するのではなく、あらかじめ色の目次(インデックス)を作ってから、各ピクセルでは目次の何番の色を置いたらよいかを記録する方式です。例えば256色インデックスカラーなら、log2 256 = 8 から、各ピクセルでは8ビットの割り当てで済みます。 GIMP を使ってファイルサイズをケチった画像を作るには、パレットを画像> モードから例えば256色に減色してから、PNGでエクスポートします。スクリーンショットなどはディザリングはオフにした方がごま塩のようなピクセルが入らなくて綺麗だと思います。写真などの場合はディザリングを有効にした方がいい感じになると思います。 True Color 24 bits/pixel (30,920 bytes) Indexed Color 8 bits/pixel (10,708 bytes) ピクセルあたりの単価が 24bit から 8bit になったので、ファイルサイズはだいたい三分の一になっているのが分かると思います。代償として減色時にパレットを使い切ってしまったときはぴったり済んだ場合を除いて情報が失われています。 上の場合は減色されて情報が失われていることが良く見ると分かります。幅広のグラデーションが階段状になっているのが見えるでしょうか？ さらに過激派な方は16色インデックスカラーに挑戦してみましょう！失われるものも多いですがファイルサイズはさらに半分になります。 Indexed Color 4 bits/pixel (5,029 bytes)