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

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

Text::LTSVの新しいバージョンではメソッドにファイルハンドルを渡せるようになって便利

perl

Text::LTSVのparse_fileとparse_file_utf8には元々ファイルパスしか引数として与えられなかったのですが，Version 0.08以降はここにOpenしてあるファイルハンドルを渡せるようになって便利です．

処理がスマートに書けるようになって大変満足！

git-checkout-here.vimというプラグインを書いた

vim
git-checkout-here.vim

https://github.com/moznion/git-checkout-here.vim


何をやるプラグインかと言うと，カーソルの現在行が所属する部分 (後述) をgit checkout HEADするというプラグインです．
プログラムを書いていると，「ここの部分は残しておきたいけれど，ここの部分はHEADに戻したい」みたいな事がままあって，そういう時はgit checkout --patch HEAD*1 したり，あるいは手で書き直したり（！）すれば良いわけですが，一回エディタを抜けてgitコマンド叩くのもアレだし，ましてや手で書きなおしたりするとミスを犯す可能性があるので，それだったらエディタ上で処理を完結させたい！　というモチベーションに基いて書きました．


内部的にはやはりgit checkout --patch HEADを実行していて，上記の「カーソルの現在行が所属している部分」というのは，つまりgit checkout --patch HEADした時のパッチレベルのことです．
（従ってこのプラグインでは，git checkout --patch HEADよりも細かい粒度でcheckoutする事は不可能です）
（--patchオプションは普通に使うとコマンドの処理はインタラクティブなモードになるんですが，echo -e "\n\n\y\y" | git checkout --patchという風に標準入力で渡して使ってやると，非インタラクティブモードでコマンドを実行できるので便利ですね）


まあ，便利なのかどうかイマイチわからない……というか，まあ僕は便利だと思って使っているんですがどんな塩梅でしょうか．


それはそうと今改めてこのプラグインの説明文を読み返しましたがわかりにくいですね！　日本語難しい！

*1:https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html

CROSS 2014のぶつかり稽古に出演します

― あのぶつかり稽古がまた来る...


http://www.cross-party.com/programs/butsukari/

明日1月17日（金）にCROSS 2014で催される異色のイベント，ぶつかり稽古に弟子役として出演します．
色々あって色々大変な感じになりました．ほんとうにもう！！！！

当日はYappoさんにボコボコにタコ殴りにされる僕の姿が見れますので，是非見に来て頂きたく存じます．

VimでもJavaScriptのfunctionを寿にしたい

vim

http://hitode909.hatenablog.com/entry/2013/10/26/132041
ここで書かれているように，JavaScriptをいじっている時にfunctionが寿になると嬉しい．
(最初は寿じゃなくてλだった気もしますが，この際それは脇に避けます)

2014-01-15 17:50 追記

結論から言って，
http://labs.timedia.co.jp/2011/04/javascript-function-lambda-vim.html
を見ると良いです．コメントで教えてくださったid:thincaさんありがとうございます！
[追記ここまで]

2014-01-16 0:35 追記

いちいちsyntax/javascript.vimに書くのだるいし，複数マシンで共有するのも面倒だったので，
NeoBundle等でさくっとインストール出来るようにリポジトリ立てました．
https://github.com/moznion/jskotobuki-vim

:Kotobukiや:NoKotobukiといったコマンドもサポートしています．
(:Kotobukiするとfunctionが寿になって，:NoKotobukiすると寿になりません)

また，g:jskotobukiCharacterに任意の文字を代入すると「寿」以外の文字で置換されるようにしました．
[追記ここまで]


!!! という訳で以下に書かれている内容は本当に良くないので参考にしないで下さい !!!


Emacsだとid:hitode909さんの記事に書かれているようなEmacs LISPを書くと動くわけですが，
Vimだとどうやれば良いのかよくわからなかったのでざっくり適当に書きました．


gist8431877


この実装，「寿」を1文字削除しようとすると理想的には“functio”になるべきなのに全部消え去ってしまったり，
JSのキーワードではない文字列の「寿」も置換されてしまったりと，諸般の問題を抱えていてあまり良くない感じがします．

というか，そもそも見た目だけを変えたいのにファイルごと書き換えていてマズい．
Vimが途中で不慮の事故で落ちると，JSのファイルは寿のままになってしまって具合が悪い．

発想が乱暴だし実装も乱暴だし，実装者も乱暴なので，乱暴そのものと化してしまっていて厳しい．


もっと良いやり方があるはず．教えてください！！！！！！

Text::XslateにテンプレートのSyntaxをチェックするメソッドが追加されて便利

Perl

Text::Xslateのバージョン3.1.0から，テンプレートのSyntaxが正しいかそうでないかをチェックするメソッドが追加されていて便利です．


以下のように，テストしたい対象のテンプレートファイルをvalidate()メソッドの引数として食べさせてあげると，そのテンプレートファイルのSyntaxをチェックしてくれます (@filesの中身はテスト対象となるテンプレートファイルのパスのリスト)．

use Text::Xslate;

my $tx = Text::Xslate->new;
for my $file (@files) {
    $tx->validate($file);
}

Syntaxが正しい時には何も起きず，Syntaxが誤っている時は以下のようなメッセージと共に例外が送出されます．

Text::Xslate::Syntax::Kolon: Expected a semicolon or block end, but got 'content', near verride, while parsing templates (/Users/owner/MyApp/tmpl/index.tx:3) at bin/check_tmpl.pl line 16.
----------------------------------------------------------------------------

: verride content -> {

----------------------------------------------------------------------------


以下のように書くと，簡単にテンプレートファイルのSyntaxのTestが一括で出来て便利では無いかと思った次第です．

use Test::More;
use Text::Xslate;

my $tx = Text::Xslate->new;
for my $file (@files) {
    eval { $tx->validate($file) };
    ok !$@, qq/Xslate Syntax OK: "$file"/;
}

done_testing;


大変便利な機能でgfx++という感じですが，なぜかundocumentedな機能だったのでさっきドキュメント書いてPull Requestしました！


[2014/01/08 22:44 追記]
gfxさんにマージしてもらったので次のバージョンあたりから当該機能はドキュメント化されていると思います！
ありがとうございます！

Hokkaido.pm #11に参加した報告とTestとDocumentの甘い関係に関して

Perl

Hokkaido.pm #11に参加してまいりました．
以下が僕の発表スライドです．


言いたいことは大体スライドに書いてある通りで，

  • TestとDocumentは同じ方向 (どちらも正しいソフトウェアの動作について論じている) を向いている
  • 従って協調できるのではないか
  • 協調するメリット
    • Documentの不整合や陳腐化を防げる
    • DocumentとTestをそれぞれ別個に書くよりもコストを低減出来るかもしれない
  • 方法は2つあると思う
    • Documentにテストケースを埋め込む方法
    • TestからDocumentを生成する方法

という感じです．


“TestとDocumentを同居させる方法”というのは割と以前からある考え方っぽくて，PythonではDoctestというテストモジュールが一般的なようですし*1，JavaScriptにおいてはpower-doctestという大変クールなテスティングフレームワークが開発されています．
PerlにもTest::Inlineという似たような働きをするモジュールがありますが，こちらは毎回毎回*.pmファイル (つまりドキュメント) をTestスクリプトに変換してからテストを走らせなくてはならなかったりしてお手軽感が薄い感じです*2．こうした用途で他の言語のモジュールと使い勝手を合わせるとするならば，ドキュメント自体がRunnableかつTestableである必要があるのでは無いかと考えた次第です．
Documentを書けば書くほどテストケースが増えていくというのは割と良いのではないかと思いました．


“TestからDocumentを生成する方法”はかなり良いのでは無いかなと思っています．
Testによって正しい動作が保証されているものをそのままDocumentにすれば，その生成されたDocumentの内容ももちろん正しいはずです．
更に，Testを走らせるたびに正しいDocumentが生成・更新されるというのは，スピードの早い開発において後回しにされがちなDocument作成作業を気にしなくても良くなるということになります．CI環境が整っていれば，CIに通るたびに最新かつ正しいDocumentの存在が保証されるというのはコスト的にも心理的にも負担が軽減されるのではないでしょうか．
ただ，この方法がマッチするドメインというのはあまり思いつかなくて，威力を十分に発揮できるのは (Web) APIくらいなのかなぁという感じです．他に何かあったら是非教えて頂きたいです．


今年出てきた，id:r7kamuraさんのautodocの考え方は革新的で非常によいなあと思いました．
「DocumentとTestの協調」は最近個人的にキているので，来年はその辺に注目して行きたい感じです．


最後に北海道の様子をお伝えします．

http://instagram.com/p/ikfIltAdO3/
ラーメン見た
http://instagram.com/p/idhe9kgdO7/
papix papix papix

*1:http://docs.python.org/3.3/library/doctest.html

*2:素晴らしいモジュールであることに違いはありませんが