その手の平は尻もつかめるさ

ギジュツ的な事をメーンで書く予定です

Javaで空いているポート番号を取ってきたい

java

Javaで空いてるポート番号取ってきたかったんで，以下のように書いたらポート番号取れて便利でした．

int port;
try (Socket socket = new Socket()) {
    socket.bind(null);
    port = socket.getLocalPort();
}

ドキュメントによると，Socket#bind()の引数にnullを渡すと「アドレスがnullの場合は、システムにより一時的なポートと有効なローカル・アドレスが選択されてソケットがバインドされます」とのことなので，それを使ってbindしてポート番号を取得してからそのSocketをcloseすればそのポートが空くので空きポートが取れる，という寸法です．

try-with-resources使うとcloseのし忘れとかが無くなって便利ですね，便利！

[追記]


とのことです！

実行中のプログラムの進捗度を手っ取り早く確認したい

完了するまでに結構時間がかかるプログラムを実行している時，そのプログラムの進捗度を確認したくなることがままあると思います．ほんとに動いてんのかお前，みたいな．


そうした時に考えうる最も簡単な方法は，こんな感じで進捗度を標準出力に流してしまうという方法でしょう．

(1..100).each do |i|
  # 例えばここで何らかの重い処理をする (下のsleepはその「何らかの処理」の例)
  sleep 0.1 
 
  # ここで進捗を表示 (プログレスバーみたいなもっとリッチな感じでも可)
  puts "#{i}%"
end

簡単なものだとこれで良いでしょうが，途中で端末のセッションが切れると「アッアッ」という感じになったり，そもそもプログラムの実行に際して端末が割り当てられいるとも限らないし，というか時間のかかるプログラムがその処理中ずっと端末を占領しているのはつらいので別の方法が欲しかったりします．


というわけで

orig_program_name = $0
 
(1..100).each do　|i|
  # 例えばここで何らかの重い処理をする (下のsleepはその「何らかの処理」の例)
  sleep 0.1 
 
  # ここでプログラム名上書きして進捗を載せる
  $0 = "#{orig_program_name}(#{i}%)"
end

このように自分のプログラム名を書き換えて進捗を追記すると良さそう．ps | grepとかで引っ掛けることで進捗を確認できるので便利！

プログラム名に表示される進捗を別のプログラムが監視して，ある閾値を超えたら特定の処理を走らせる，みたいなこともまあ出来そう．原始的なIPCっぽさを感じる今日このごろです．

Validation Nightやります

ちょっと色々立て込んでいて，テンプレートエンジンNightやりましたよエントリを書きそびれてしまったんですが，
テンプレートエンジンやりました！　発表者の皆様，参加者の皆様まことにありがとうございました！

さて，きたる12/4 (木) ですが，前回のテンプレートエンジンNightでお知らせしたとおりValidation Nightを開催します．

Validation Night - connpass
Validationに関する知見が惜しげも無く披露されることが予想されますので，皆様ふるってご参加下さい！

LTで発表してくださる方も募集中ですので，そちらの方もよろしくお願いします．

文字列内のバックスラッシュを区別したい的な

perl

タイトルが適当すぎて何を言っているのかわからないと思いますが，まあそういう事がごくごく稀にあります．結論から言うとヒアドキュメント使えば良いです．

以下の様な文字列を考えた時，

my $string = '\n\\';

これを1文字ずつ処理しようとすると，

say $_ for split //, $string;
# 以下出力
# \
# n
# \

という風になります．

さてこうした時，エスケープの為のバックスラッシュと純粋なバックスラッシュ (つまりエスケープされたバックスラッシュ) との区別がつかなくて困るということがごく稀に生じます．エッ，生じない？　俺はRegexp::Lexerで生じたんだよ！！！！

で，困ったので以下のように解決しました．

use B;

# 文字列をregexp quotedな変数にする
my $string = qr(\n\\);

# B::cstringでバックスラッシュをさらにエスケープする
my $cstring = B::cstring($string); # => '"(?^:\\n\\\\)"'

# 先頭の `"(` と末尾の `)"` が邪魔なので消しておく
$cstring = substr(substr($cstring, 2), 0, -2);

# B::cstringはダブルクォート文字もエスケープするのでそれは元に戻しておく
$cstring =~ s/\\"/"/g;

# 正規表現のmodifierが邪魔なので消す
$cstring =~ s/\A[?]([^:]*)://;

# 余計なバックスラッシュをまとめる
$cstring =~ s/\\\\/\\/g;

と処理してやって，一文字ずつ処理してやると

\
n
\
\

という具合にめでたくエスケープの為のバックスラッシュと純粋なバックスラッシュが区別できるという塩梅です．
reqexp quotedな変数にする*1 というのとB::cstring()を使う*2 という方法に至ったのですが，実際にはヒアドキュメントを使うと楽．

my $string = <'...';
\n\\
...
say $_ for split //, $string;
# \
# n
# \
# \

ヒアドキュメントを使うとこういう七面倒臭いことをしなくても済みます！！！
ヒアドキュメントを使える場面では使ったほうが良さそう！　とは言え色々事情はあると思うので適宜使い分けという感じで．

*1:今回はたまたま解析対象が正規表現だからこれでも問題なかったけど……

*2:ちなみにB::cstring()を使っているのは文字列中の改行とかに対応するため

Regexp::Lexerってやつを書いた

perl

https://metacpan.org/pod/Regexp::Lexer
https://github.com/moznion/Regexp-Lexer


Perlの正規表現を解析したいなー，と思った時にまず目につくのはRegexp::Parserだと思うのですが，このモジュールは解釈できないメタ文字や構文が多い為，実用にあたってはかなり厳しいという印象があります (モンキーパッチなんかを当てまくると使えるかなって感じ)．
ついでに言うと，メンテナのTODDR氏がここで言っているように，氏はこういった分野にあまり明るくないらしく，積極的なメンテナンスが成される可能性は高くありません．パッチを送ろうとも思いましたが，結構複雑なことをやっているモジュールなのでモチベーションがもげた……


で，Regexp::Parserで頑張るのつらいし，それほどもりもりで機能要らないから自分の欲しい機能だけ搭載したミニマルな解析器が欲しいよね〜ってなった時に，まあとにかく自分で書くしかねえかなーと思って，ひとまずその前段階としてRegexp::Lexerというモジュールをしたためました．
名前の通り，正規表現文字列 (正確にはregexp quotedな文字列) を食べて，それをトークン列に分割して返してくれる君です．


このモジュールが吐き出すトークン列を煮るなり焼くなりして自分だけの解析器を作って育てて戦わせれば良いのでは，という思想のもとに生まれました．
とは言えやはりパーザ実装があると便利なので，次はパーザを書きたいという気持ちでいっぱいですが，Regexp::Parserという名前空間を取られているのでどうしたもんかと悩んでいる今日このごろです．何か良い名前あったら教えて下さい．

location-utilってやつ書いた

javascript

JavaScriptのライブラリです．

npmとbowerにも出しておいた．
https://www.npmjs.org/package/location-util


URLを食べて，

  • よしなにURLの一部分だけ抜き出したり
  • よしなにURLの一部分を書き換えたり
  • よしなにURL組み立てなおしたり

出来る君です．使い方などはSynopsis読めば大体理解して頂けるのではないかと思います．

Angular.jsの$locationが便利っぽいなーと思って，似たような機能を手で書いてみた次第．

他に対する依存が無いのと，ブラウザでもnode.jsでも使えるのでまあまあ便利かなと思います．とにかく自分が欲しかったから書いた……

追記

というか，

という極めて優れたモジュールがあるので，まずこれを使うと良いと思います．

location-utilはAngularが提供しているようなインターフェースをパクって，いくらかパワフル (?) なメソッドを余分に提供しているんですが，それが必要なかったらmicro-locationが良いと思います．趣味の話っぽい．

追記2

あと，location-utilはプロトコル (http:// みたいな) を省略したURLでも扱えるという裏機能があるんですけど推奨はしません！！！

トークナイザーとパーザーについて，結合するということについて

トークナイザーとパーザーについて，それに準ずる物を書いていて，その最中ふと思った事について記す．

基本的にトークナイザーは対象となる文字列を，或る最小限の意味を持つトークンに分解してトークン列を導出するというのが責務で，これのみに着目するのであれば実装は (それほどまで) 難しいものにはならない *1．
厄介なのはパーザーの方で，パーザーはトークナイザーが吐き出したトークンを組み合わせてある意味のある文節というか文脈というか，そういう感じの扱うのに際して便利な単位に落としこむのが仕事なのだけれど，こちらの方は様々な組み合わせが存在するために複雑になる．伴ってコードの量も多くなる．圧倒的にトークナイザーを書くよりも実装のコストが高い．
そうした状況を解決する為に，愚鈍なトークナイザーを賢いトークナイザーにしてしまうという方法が考えられる．トークナイザーが単純な文字列の分解だけではなく，その過程で附随的な情報をトークンに付け加えたり，或いはトークナイザーのレベルでいくつかのトークンをひとまとめにしてしまうというような「賢い」処理を行い，トークナイザーの成果物をパーザーフレンドリーにすることで，パーザーの実装コストを緩和するという方法だ．
これは大抵の場合，トークナイザーとパーザーが完全に独立している時の総合コストよりも低くなる感じがするんだけど，そうなるとトークナイザーとパーザーが結合を始めてしまい，トークナイザーを別の所で使ったり，或いは逆でパーザーのトークナイズエンジンを変えたりすることがままならなくなる．
と，ここらへんトレードオフだと思っていて，まあよく考えたほうが良いですよねという話で，実際誰も使わないようなトークナイザー・パーザーだったら密結合させてエイヤで実装したほうが良いと思う．逆に超有用 (だと思われるよう) なものの場合はやっぱり双方独立させたほうが良いのだろうとも思うけど，そこまで有用なものなのだったら書かずとも既にこの世に存在している可能性が高いし，もしかしたら密結合でソイヤと実装してしまってもどこからともなく神コミッターが現れて一晩で結合をひっぺがしてくれるかも知れないのでとにかく書いてしまうというのが重要である．

*1:例外はあると思う