2014-06-27

PerlでIPアドレスからホスト名をLookupするベターな方法。

Perl

gethostbyaddr()は使いにくいしどうもIPv6対応が怪しい。

IO::Socket::IPはそろそろ標準モジュールに入るらしいが、それは普及にはもうちょっとかかるってことでもある。オーバースペックな気もする。

ということで、普通にSocket.pm使ってみる。

use Socket qw(getaddrinfo getnameinfo);

sub addr_to_hostname {
    my $addr = shift;

    my ($err1, @result) = getaddrinfo($addr);
    die $err1 if $err1;

    my ($err2, $hostname) = getnameinfo($result[0]{addr});
    die $err2 if $err2;

    return $hostname;
}

print addr_to_hostname('127.0.0.1'), $/;
print addr_to_hostname('2001:4860:4860::8888'), $/; # Googleのアレ

んー、これはこれで微妙か。

2014-06-24

WebブラウザでKindleの本のサンプルを読めるらしいという話。

JavaScript

WebブラウザでKindleの本のサンプルを読めるらしいという話をGIGAZINEの記事経由で知って、とりあえずブックマークレットのコードを読んでみた。

ら、コードがいまいちだったので、書き直すことにした。

ASINの取得方法が微妙→windowオブジェクトにあるらしいのでそこから取得。十分な方法ではなさそうだが、URLから取るよりはマシそう。

変数を使わなくなったので(function () { ... })()でスコープ作るのをやめて、戻り値はvoid()で対処。

こんな感じになりました。だいぶすっきり。

Kindle立ち読み
このブックマークレットはオリジナルと違い、削除されてしまった本のサンプルの閲覧はできない、注意。

久々にgolfがやりたくなった。

追記

URLを参照しないタイプなので『ストアから削除されてしまったKindle本』のサンプルは閲覧不可。

Kindle本の立ち読み版（サンプル）をブラウザで閲覧するための新ブックマークレット - 忌川タツヤのブログ

おー、なるほど。

追記2 (2015/04/03)

Amazonの仕様変更によって動かなくなってたっぽい。ので、下に直したものを置いとく。

Kindle立ち読み

2014-06-18

最近はまったこととか。

Perl Linux

ちゃんと定期的にブログ書くのってむずかしいね。

Firefoxでcontenteditable="true"が奇妙な動作。HTMLの文法的に？　入力できないようなHTML文字列を貼り付けたりすると、変な位置に貼り付けられてしまい、またcontenteditableが効かなくなる。contenteditableはまだまだ微妙だねー。
rsyncで、更新(予定)のファイルリストだけ取る。どうもできない模様。-vは-qで完全に沈黙させられるし、--list-onlyはまったく無関係の機能だし。
rsyncで特定のディレクトリのみ含めるオプション。--include 'dir/'とかじゃ駄目で、--include 'dir/**'とかでも駄目で、--include 'dir/***'. アスタリスク3つは初めて見ました。
Perlで``でautodie. どうもできない模様。system()とかexec()は行けるのに。
tmuxinatorで、AAAというセッションが動作しているときにAAA1のようなセッションを実行すると、開始せず、AAAに移動する。tmuxのhas-sessionが前方一致という狂った仕様っぽい。で、tmuxinatorがそれに気付いてない。

はてなブログの書き方忘れた……。

2014-03-27

evergreenって新しい公式テーマ試そうとしたら、

はてなブログ

はてなブログにバグ発見。テーマのプレビューで次のページに行けない。

相変わらずバグだらけだねー。

2014-03-23

ブラック・スワンという本を読まなかった。

プロローグちょっと読んだだけだが、いくらなんでも頭悪過ぎて……。

まず、黒い白鳥が見つかるまでの白鳥に関する事実だけど、

白鳥の羽は白いという証拠が大体そろっている。

という考えがそもそも間違えで、

現在のところ白以外の羽をもつ白鳥が存在する証拠はない。

がせいぜいだろう。基本的な科学のやり口を理解していない人間にありがちな間違えである。

この時点でもう非科学的すぎてやめたくなったが、もう少しだけ読んだ。突っ込み所は指数関数的に増えていったが、読むのをやめた部分だけ突っ込む。

　二〇〇一年九月一一日のテロ攻撃を考えてみればいい。九月一〇日の段階で、ああいうことが起こる可能性がそれなりに想定できていたなら、そもそもああいう事件は起こらなかった。そういう可能性にも気をつけた方がいいということになれば、戦闘機が世界貿易センターの上をぐるぐる回っていただろうし、旅客機のほうも防弾ドアをつけて鍵をかけていただろう。テロ攻撃は起こらなかった、マル。

(傍点は除いたというかHTMLでは書けないので)

日時や場所を相当なところまで絞り込めているのを「それなり」という不自然さ。
そこまで絞り込んでおいてやってることが戦闘機旋回という微妙さ。

は置いといて。

まあここまで予測できていれば確かになんとかなると思う。戦闘機を旋回させるだけじゃ被害はまだ大きくなるだろうけど、空港のガードも厳しくするなりすればかなり減らせただろう。

問題はそもそもそんな精度の高い予測なんてできないことにある。予測自体はできる。大規模テロの可能性をアメリカが認識していなかったとは考えられない。

東日本大震災だって、可能性というレベルでは起こり得ることはわかっていた。

今後確実に起こるだろう、破局噴火や巨大隕石の衝突、核によるさらに大きなテロや致命的かつ感染力の高いウィルスの蔓延、それらをきっと防げないのは、起こらないと考えられているからではない。

起こる確率が低いため、短期的に見るとリスクが小さく、
あるいは/また、精度の高い予測ができなかったり、単純な難しさから、対策に大きなコストがかかり、
そのコストを回収できるかが難しいため、コストが支払えない。

からである。

人間には大きな変動は見えない、のも確かだろうが、問題の本質はそこではない。科学的に考えれば黒い白鳥の存在はなんの問題もなかったし、大規模テロの可能性は、見えなかった人もいるだろうが、そのせいで対応できなかったわけではない。

精度の高い予測ができないことが問題の本質で、それは人間個々人の性質とはあまり関係ない。

プロローグのほんの一部でやめたのでこの批評は的を外しているかもしれないが、この本を読み続ける価値がないのはそれなりに予測できたので読み続ける気はない。

2014-03-14

次へと前へだけじゃないページングはやっぱり必要だと思う。

YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか

これ見て、

世の中SQL_CALC_FOUND_ROWSとか使っても大丈夫な規模のデータは少なくないし、
そもそも次へと前へだけじゃないページング(以下ページジャンプ)は便利だし、
無能なプログラマのために変な対処療法しても意味ないし、

適当なこと言ってるなと思った。下二つについて以下説明。

そもそも次へと前へだけじゃないページング(以下ページジャンプ)は便利だし、

もちろん「前へ 1 2 3 4 5 6 次へ」みたいなリッチなページングの実装には役に立たないかもしれません、でも果たしてそういったページング処理は本当に必要なんでしょうか?

常にとは言わないが、少なくない場合で必要だと思う。

そもそも、どういう場合に次にではなく、いくつか先にジャンプするか。

欲しいものが現在のページにない。
欲しいものが次のページにもない気がする。
でももっと先には欲しいものがあるかもしれない。

このような状況はなぜ起きるか。

検索機能に不足があるか、検索精度の問題で、検索結果を欲しいものだけに絞り込めない。
だが、検索結果が二分探索可能な順番で並んでいるので、ページジャンプが事実上の絞り込みになる。

常に十分な検索結果を提供できたり、あるいは二分探索的な絞り込みをページジャンプ以外のUIで可能にするなら、ページジャンプはいらないかもしれない。

でもそれができないうちは、気をつけつつ使う、のがいいんじゃないかな。

技術の都合で適切なUI提供しないのは間違ってる。

無能なプログラマのために変な対処療法しても意味ないし、

なぜなら自分以外の誰かがメンテナンスをする事になった時に、その誰かが良くわからないでコピペで新機能を作ってしまう、その新機能がわりとデカイデータを取り扱う仕様だった！

よくわからないコピペをしちゃうようなプログラマは、そうしないよう教育すべき。教育せずに、重いページング処理を書かせないよう対処療法で対応してもどうせ別の問題を起こしてしまう。

2014-01-26

XML::LibXMLでHTMLを扱うのはやめておいた方がよさそう。

Perl

HTML::Parserはあまり速くなかった気がするので、XML::LibXMLでHTMLを扱おうとしてはまった。XML::LibXMLは、load_html()みたいなメソッドもあるから大丈夫かなー、なんて思ったのが甘かった。

HTMLをパースして、データ構造にする。
データ構造を走査したり操作する。
データ構造を出力する。

とうい一連の流れのうち、1と3が問題になる。

パースするには、load_xml()かload_html()というクラスメソッドを使う。parse_fileやparse_html_fileなどというインスタンスメソッドもあるが、こちらも実質的には同じである。

2つのクラスメソッドのうち、load_xml()は、<br>のような終了タグのないタグを読み込めない。それだけならXHTMLにしてしまえばなんとかなりそうに見えるが、<textarea></textarea>を<textarea/>に無理矢理まとめてしまう。この表記は、現状のブラウザであれば一応対応している場合が多いが、XHTMLとして扱われなかった場合には表示が崩れることを考えると使いづらい。

そして出力がまた問題である。toString(), toStringHTML(), toStringC14N(), toStringEC14N()の4つのメソッドが基本となるが、

toString()はload_html()で読み込もうが、<textarea/>のようにまとめてしまう。
逆にtoStringC14N(), toStringEC14N()は、<br>を<br></br>のように分離してしまう。
toStringHTML()は一見問題なさそうに見えるが、日本語文字列が実体参照に変えられてしまう。

というような感じで、"HTML"を扱うにはあきらかに不便すぎる。多少遅かろうが、HTML::Parser系のモジュールを使うべきだろう。HTML::TreeBuilderとかね。あれはあれでいろいろ問題あるけどね。

とはいえ動作確認は完全ではないので、もしまともにHTMLを扱う方法があるなら誰か教えてください。