いまだに Data::Dumper で消耗しているの？
Data::Dumper::AutoEncode というモジュールがありまして、主に printデバッグのお供に便利な変数のダンプモジュール君です。 デファクトスタンダードであるところの Data::Dumper でダンプすると「\x{304a}\x{3067}\x{3093}」こんな感じにエスケープされてしまうマルチバイトな文字列を、 Data::Dumper::AutoEncode の eDumper という関数を使うと、自動的にエンコードして普通に読める状態で出力してくれます。 use utf8; use Data::Dumper::AutoEncode; # export `eDumper` and `Dumper` my $foo = +{ bar => 'おでん' }; print Dumper($foo); # { bar => "\x{304a}\x{3067}\x{309
nginx でトップページのみリダイレクト
nginx でサーブしているサイトのトップページのみリダイレクトしたいという場合、以下のようでいけるかなと思った。 location / { rewrite / https://example.com/foo permanent; } しかしこれはまったく動かなかった。 あれ、なんだっけ、こうかな？と頭をひねって以下のように書き換えてみた。 location / { rewrite ^$ https://example.com/foo permanent; } しかしこれもまったく動かなかった。 やべ、あわせてこうかな？というのも試してみた。 location / { rewrite ^/$ https://example.com/foo permanent; } とにかく、動かない orz で、実は location ディレクティブ で = が使えたので、以下のように書けば良いだけだった
letsencrypt ふたたび
以前、letsencrypt を試して このブログのドメインを SSL 対応してみたのですが、いろいろあってまともに運用してなかったので、あっという間に90日過ぎて証明書が expire という残念な状態だったのですが、letsencrypt のベータも取れたし大型連休を利用してまともな運用状況にもっていきましょうということをやってみるけどまともかどうかはわかりませんがとにかくやってみるぞっと。 環境 CentOS 6 SCL + python2.7 SSL を受けるwebサーバは nginx 証明書の新規取得、更新時に止めない サブドメインたくさん letsencrypt-auto 0.5.0 初回起動 CentOS6 なので python2.7 のため、まずは SCL をフックします。 scl enable python27 bash python -V; # Python 2.7.5
CLI batch のオプション設計について
CLI batch の類の話である。CLI tool だとまた違った話になる。 さて、CLI batch のオプション設計でよくもめるのは、テスト実行する機能をつけるとき、--dry-run とするか、--execute とするか、どっちをデフォルトとするかという点である。ある人は無闇に実行したがって平和を乱しがちだし、ある人は安全に倒したがって手間を増やしがちになる。プロジェクトの中で、この設計がぶれているのも毎回オプションを確認しないと怖かったりするのでよろしくない。だいたいは、リーダーのポリシーにしたがって手間か安全のいずれかに寄せた方針になっていることが多いが、自分は、実行内容によって適宜判断するのが良いと考えている。 個人的経験則に基づいているので、もっとベターな方針があったら教えてほしいが、自分の場合は、以下のような方針がいまのところベストだと思っている。 まず、判断の根拠は、
なんでも Furl
Webアプリやモジュールに HTTPクライアントを組み込む場合、安心と信頼とスピードの Furl でまかないたいというのは老若男女問わずもがなの夢だと思われる。Furl 自体は、そうした user agent の切り替えが考慮されていて、Furl 開発当時のデファクトであった LWP::UserAgent とは互換が取りやすく作られている。おおむねそのまま挿げ替えて動く。ちょっとうまくいかない場面と言えば、例えば Net::Twitter::Lite で ua を Furl に切り替えたら default_header メソッドが無いと言われる程度だ。それも以下のように Furl を継承したクラスを用意すれば良い。 package MyUA; use strict; use warnings; use parent 'Furl'; sub default_header { my ($sel
俺の CLI コマンドの勘所2
このエントリーは Perl 5 Advent Calender 2015 の5日目の記事です。 3日の記事 から中一日で再び登場の bayashi です、こんにちわわわわー！ 本日は、先日のエントリで書ききれなかった要素をいくらか書き足したいと思います。 Perl CLI ツールのテスト CLI ツールをワンライナーではなくモジュールにして利用するメリットのひとつに、テストを書いて機能の追加や変更などの運用をきちんとしやすくなるという点があります。やっぱりテストは重要ですね。 exitコードのテスト CLIコマンドは、時に exit するかと思います。そんな exit するコマンド実行パターンのテストは以下のように書いています(確か Text::Xslate のCLIツールのテストから拝借したまんま)。 https://github.com/bayashi/App-Randf/blob/m
俺のワンライナー改め CLI ツール群のステマ
このエントリーは Perl 5 Advent Calender 2015 の3日目の記事です。 まだワンライナーで消耗してるの？ Perl で書くワンライナーが便利というのはもうさんざん語られている気がするし自明だろうて、このたびはコマンドラインインターフェースで便利なツール群をドヤ顔でステマしたいと思います。怠惰ゆえ、もうワンライナー書くのも面倒になったらコマンドにしてしまえこのやろう、というノリですぜ、おとっつあん。 手前みそですが、できる限り便利そうなやつをピックアップするので、ひとつお付き合いください。ペコリ。 swoop まずは Statistics::Swoop をインストールすると付いてくる swoop コマンド。これは、ログのあるカラムの合計、最大、最小、レンジ、平均をさくっと算出してくれるコマンド。 $ cat log_file | swoop -f3 -d, .----
Perlでテストがこけて泣きそうなときのTIPS
Perl 書いてりゃ Test::More でテスト書きまくると思うのですが、Test::More っていうか、まあ別に Test::More だけがそうというわけでもないのですが、テストこけたときのケアが十分じゃないなと思うときがけっこうあります。 開発過程で書いてるコードというのは、いつもいつも確信を持って書いているわけではないわけで、それでなくてもうっかり間違うときもあり、せっかくテスト書いているのに何だかよくわからない理由でこけてパスできなくて時間を浪費してしまったりが日常になってたりしませんか？ そういうのを繰り返しているとやがてテスト嫌いになりテスト書かなくなって本番コードにデバッグコードが入り乱れ、リファクタもどんどん不可能になって小回り効かないままプロジェクトが失敗して彼女に振られてしまうわけですね。困ります。 note diag explain Test::More には
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Feedpon良い
Google の Public DNS over HTTP の CLI 書いた