Feb 12, 2016

おととい使い始めた Qiita に引き続き投稿した。

この投稿とは関係ないけど、zaw か peco かという点では Qiita 内では圧倒的に peco のようだけど、 peco を試してみた時(だいぶ前なので今はちがうかも)補完候補選びで画面全体をつかうのがどうにも慣れず...。

zaw はカーソル位置のすぐ下に候補がでるので、

  • 視点移動がすくない
  • 画面大幅に書き換わらないので脳内コンテキストスイッチすくない

という2点が優れてるので zaw をずっと使ってるゾゥ。

Feb 10, 2016

会社で Qiita Organization 作っていくとかもあり Qiita に初投稿してみた。

初投稿をまず下書きしてみようと「投稿する」ボタンの横のプルダウンから「下書き」をクリックしたところ下書き一覧が表示され(下書き画面があるのかという思い込み)、そこに見に覚えのないだいぶ前に作ったらしいこの記事の下書きがあった...。 無駄に2回びっくり。

Jan 16, 2016

そういえばずっと Gem 化しないまま使っていた capistrano-scm-tar を rubygems.org にアップロードしていたのだった(気づいたら年が変わっている...)。

名前の通り Capistrano 3 の scm として振る舞いつつも実際はなんもしなくて、ただ tarball をデプロイするためのプラグイン。

設定は deploy.rb などで scm を指定するのみ。

set :scm, :tar

デプロイは Capistrano 実行環境にファイルをアップロードするなりして、package 環境変数にそのパスを与える。

$ cap deploy package=/tmp/v1.0.0.tar.gz

結局 tar。

Oct 03, 2015

Mojolicious で X-Forwarded-For からプロキシではなくクライアントの IP っぽいものをとってこれるプラグインを書いた。

使い方は SYNOPSIS の通り、

use Mojolicious::Lite;

plugin 'ClientIP';

get '/' => sub {
    my $c = shift;
    $c->render(text => $c->client_ip);
};

Mojolicious 的にはリモートアドレス取るとなったら $c->tx->remote_address を使うのが通常だと思われるけど、これは XFF があったら最後の IP を単に返すだけ。一方このプラグインではプライベートネットワークなアドレスは無視するようになっているので、

X-Forwarded-For: 192.0.2.100 10.0.0.2 10.0.0.1

みたいの受け取った時に、

$c->tx->remote_address;  # => '10.0.0.1'
$c->clien_ip;            # => '192.0.2.100'

こういう違いが出る。XFF がなかったり、全てプライベートアドレスだったりした場合は $c->tx->remote_address が呼ばれるので、環境やミドルウェア的なものにあんまり左右されずに『ユーザーの IP』っぽいものをとりたい時に普段使いできるはず。

通常これだけで事足りるはずだけど、事情があって無視したい グローバル IP があったりもしたので、任意の IP を追加で無視できるようにもなってる。これも SYNOPSIS の通り、

plugin 'ClientIP', ignore => [qw(192.0.2.1 192.0.2.16/28)];

CIDR 使えるので楽。

さすがに手段も目的も当たり前すぎるものなのでもうプラグインあるだろと思ったけどみあたらなかったので作った。

Aug 26, 2015

最後かもしれない YAPC::Asia Tokyo 行ってきた。

久しぶりに2日間参加できてとても有意義だった。 といっても 2006 年の初回から計 9 回行っても素人の域を脱することができないためずっとトークを聞いていた(その割にベストトーク上位3つをどれも聞いていないかった...)。

印象深かったのは以下。

Effective ES6

残念ながらいわゆる片手間でフロントエンドもやっている身としては大変ためになった。 今メインで開発しているサービスでも使い始めたのでいい加減覚える。

TBD

Ruby の反省点として Lisp に(悪)影響を受けた部分のくだりの、 「ユーザーに微妙な使い分けを強いるような似たようで異なるもの導入すべきではない」というの、Web サービスの API 設計に通じるものがありそう。 API 作ってるときはその API を安定させるためにやることを 1 つにさせたいと思って作ることが多い。ただ、実際にはそのせいでクライアントは微妙に異なる複数の API を条件分けして使ったりで全体を通すと API 提供側でよしなにやったほうがテストもし易いのではという気がする。 次、そんな場面に出くわしたらちょっと考えてみよう。

Perl 5.22 and You

5.20 で導入されてた Post Dereferencing は見落としていたので知れてよかった。

ただ、5.24 についてもさらりと触れていたけど、今後並行処理サポートとか(Ruby で検討されてるらしい)Soft Typing みたいな新しい技術は入ってこないんだろうなという気がするのでなかなか寂しい状況。 Perl 5 と Perl 6 は違う言語であるということはさんざん言われてるけど、そうであれば Perl 6 が登場しようとしてる今 Perl 5 が単に死にゆく old version になるのか、別の言語として発展し続けるのか、その辺ちょっとメッセージがほしいかなぁと思った(自分がしらないだけでなんかすでにあるかしら?)。

Adventures in Refactoring

Developer Happiness、いい言葉だった。もろもろ共感する部分あり、身につまされる部分あり、なるほど感あり、とてもいいトークだった。 そいえばテストコードのリファクタリングはどうやって進めてるのか、きいてみればよかったと今更思った。 あとでもう一回スライド見直して脳内再生しよう

Parallelism, Concurrency, and Asynchrony in Perl 6

トークの聞きやすさ、わかりやすさもあいまってか、Perl 6 の並列、平行、非同期部分えらく良さそうに見えた。 言語のコア機能じゃなくてモジュールで実現されてるみたいなっぽいのでなんか変態的な気もするけど、Perl 6 ちょと期待してもいいのかなと思った。


YAPC::Asia は初回の思い出が強すぎるせいか、あの時のような YAPC をもっかい見てみたいという気もする(他力本願)。 一方で Perl の話メインでみっちりトークをするという役目は地域.pm に移ったかなという気はずっとしてたので、自宅の最寄りでもある Chiba.pm がまた開催されるようなら行ってみよう。

またトークばかり聞いてるだけかもしれないけど、そんなに遠くない未来にまた開催されるといいなぁ。