master への push を禁止するローカル git hook の正しい書き方

git

GitHub などで Pull Request ベースで開発をしていると、master には間違っても push したくないわけです。
GitHub 側には残念ながら master への push を禁止するような設定はできないので、仕方ないのでクライアント側の Hook で対応しようってことになり、この方法についてググるとこことかこことか、いくつか方法を紹介しているページが出てくるんですが、どれもやり方が間違っている*1ので、正しい方法を紹介。

何がまずいのか

上記に挙げた方法では、細かい部分は違ってたりするけど、git symbolic-ref HEAD を使って現在ブランチを見て、master だったら push を禁止する、という方法を取っている。
しかし、push はカレントブランチから行われるとは限らない。dev ブランチにいるときに git push origin master とすれば、当然 master ブランチが push される。この場合上記の方法だと防げない。他にもありがちなパターンだと、git push origin --all などでも master が push される。

正しい方法

pre-push hook を以下のような感じにする。

#!/bin/bash

while read local_ref local_sha1 remote_ref remote_sha1
do
  if [[ "${remote_ref##refs/heads/}" = "master" ]]; then
    echo "Do not push to master branch!!!"
    exit 1
  fi
done

標準入力から push 先のブランチ名の情報なんかがくるので、そこをチェックする。詳しく知りたい人は man githooks の pre-push の辺りを見るとよい。

なぜ間違った方法が出回っているのか

恐らくだけど、master ブランチへのコミットを禁止する pre-commit のスクリプトが流用されたのだと思う。pre-commit の場合は、現在ブランチを見ればいいので、それで正しい。それを pre-push へそのまま適用しようとしてはいけない。

ところで

そもそも GitHub さんがサーバ側で master への push を禁止できる機能を入れてくれると色々と捗るのでそういう機能是非入れて欲しい。なんでないのー。

*1:少なくとも私には正しい方法を記述したページを見付けられなかった

Ruby の Hash で値だけ map で変換したかった

ruby 
hash = {a: 1, b: 2, c: 3}
hash2 = hash.map {|k, v| [k, v * 2] }.to_h
p hash2  # => {a: 2, b: 4, c: 6}

めんどくさい。Scala には mapValues というのがあるらしい。

Ruby で書くならこうかな。

class Hash
  def map_values(&block)
    dup.map_values!(&block)
  end

  def map_values!(&block)
    update(self) {|_, v| block.call(v) }
  end
end


hash = {a: 1, b: 2, c: 3}
hash2 = hash.map_values {|v| v * 2 }
p hash2  # => {a: 2, b: 4, c: 6}

ググると似たような話はちらほらあるっぽい。Ruby にも標準で欲しかった。

無料で使える CI サービス 8 個まとめ

webservice

CI サービスをいくつか触ってみたのでまとめ。
今回の目的は、テストを実行すること。なので、ビルドやデプロイ辺りはちゃんとは見ていない。
ドキュメントで確認しただけの項目などもあったりするので、間違っていたらごめんなさい。教えてもらえると助かります。
ただ、これは記事を書いた時点での比較で、今後のサービスの変更に対応する予定はないです。

触ってみたサービス一覧

アルファベット順。

codeship ってのもあったけど、無料プランは月100ビルドまでとかで常用には耐えないと感じたので中身見てない。

機能比較

機能比較は全て無料プランでのもの。有料だと対応している場合でもここでは x にしている。
比較項目は私の独断と偏見で適当に選出した。

項目 AppVeyor CircleCI Drone IO Magnum CI semaphore shippable Travis CI wercker 備考
YAML による設定 ○ ○ × ○ × ○ ○ ○ リポジトリ内の YAML ファイルからビルド手順を設定できる
Web UI による設定 ○ ○ ○ ○ ○ × × × Web UI でビルド手順のスクリプトを書くことができる
GitHub 連携 ○ ○ ○ ○ ○ ○ ○ ○ GitHub のリポジトリ一覧から新規プロジェクトを作れる
BitBucket 連携 ○ × ○ ○ ○ ○ × ○ BitBucket のリポジトリ一覧から新規プロジェクトを作れる
GitHub PR 対応 ○ ○ × × ○ ○ ○ ○ GitHub の Pull Request を自動でビルドしてステータスを返せる
ビルド環境キャッシュ × ○ × × ○ × × ○ 複数ビルド間を跨ぐキャッシュ領域を利用できる
手動リビルド ○ ○ × ○ ○*1 ○ ○ ○ 過去のビルドを手動でリビルドできる
複数環境ビルド ○ × × × × ○ ○ × 環境変数などで複数の環境に対してビルドできる
private なプロジェクト × ○ × ○ ○ ○ × ○ ビルド状況などを private にできる(かなり未検証)
ビルド時間制限 30分 20分 15分 30分 60分 60分 50分 25分 無出力時間による制限が別途ある場合もある

YAML による設定の利点は、プロジェクト構成の変更とビルド手順の変更を紐付けることができること。
Web UI による設定の利点は、プロジェクトに直接関係ないファイルを置かなくて済むこと。特にファイルを置く権限がない場合などには助かる。

各サービスについて雑感

以下、かなり主観かつざっくりな雑感。

AppVeyor

http://www.appveyor.com/

.NET 向けの CI サービス。
.NET に特化した機能が色々使えるけど、重要なのは、テスト環境が Windows であるということ。他に Windows 環境での CI サービスを少なくとも私は知らないのでかなり貴重。.NET 製じゃなくてもこれを使えば Windows 環境でテストができる。
設定のスクリプトは、Windows のバッチファイル(.bat) と、PowerShellスクリプト(.ps1)の形式で書ける。PowerShell は .NET のライブラリにアクセスできるので、外部からリソースのダウンロードなども可能。
ビルドトリガーが引かれると、新しいビルドは QUEUE に積まれて、実際にビルドが始まるまでに結構時間がかかる。

ビルド時間について、このページでは全てのプランは40分と書いてあるが、このページでは、Free、Professional、Premium は 30 分で Enterprise は 50 分と書いてある。どちらが正しいか不明。

CircleCI

https://circleci.com/

必要な機能は一通り揃っている印象。
YAML での設定において、各ビルドフェーズに、pre(フェーズ前)、override(フェーズのデフォルト動作を上書き)、post(フェーズ後)それぞれに対してスクリプトが書けたり、コマンド毎にカレントディレクトリや環境変数、タイムアウト時間などを指定できるので、柔軟に設定できる。

Drone IO

https://drone.io/

Go 言語製の CI サービス。
他のサービスがビルド手順をいくつかに分割している中、Drone IO のビルド手順は1つのみと、とてもシンプル。
Pull Request 時のビルドは、がんばればできるらしいけど、それでもPR以外の普段の push で API が叩かれたり、ビルドページから Pull Request のページへ飛べなかったりするので、できるとは言わない方が良さそう。

Magnum CI

https://magnum-ci.com/

現時点でまだ public beta の CI サービス。結構前からずっと beta な気がする。
使い勝手については特に問題はない。普通に使える。
beta なので、private リポジトリが無制限で使える模様。いつ beta が取れるのかは不明。

semaphore

https://semaphoreapp.com/

ビルド中にスレッドが使えるのが特徴。ビルドパイプラインの各コマンド単位で、どのスレッドで走らせるか指定できる。無料で 1 ビルド中に 2 スレッドまで使える。
あとはプロジェクト構成を見て、一般的な構成の場合は自動で検出してビルド設定を自動で終わらせてくれるらしい。私が試したプロジェクトは一般的な構成ではなかったので、どこまでやってくれるのかよくわかってない。

shippable

https://www.shippable.com/

Travis CI と互換があり、.travis.yml ファイルが置いてあるとそれを認識してビルドを行ってくれる。ただ、どこまで互換があるのかは不明。Travis CI には language に generic が指定できるのだけど(ただしドキュメント化されていない)、shippable では指定できなかった。
Web UI が開かれるまでに結構時間がかかる。

Travis CI

https://travis-ci.org/

恐らく今回まとめた中では一番有名な CI サービス。
GitHub 限定とは言え、テストをするのに必要な機能は十分揃っている。鉄板。

wercker

http://wercker.com/

他の CI と比べても変わった、box と step という特徴がある。
box はテストの実行環境。ユーザーが作成したものを wercker ディレクトリに登録しておけば、誰でも使えるようになる。特定のツールがインストール済みの環境などを作っておけば、ビルド時間が短縮できる。標準でいくつか用意されているので、それらを使ってももちろんよい。
step はビルドの手順の1つ。bash で言う1つのコマンドで、wercker ではこの step のリストをビルド手順として指定する。step は、特定の動作を抽象化してまとめたもので、Amazon 3S との同期とか、npm install とか、そういう感じのが1つの step として登録されている。最悪 script step というのがあるので、これで bash でやってもよい。この step もユーザーが自作できる。

まとめ

無料でもこれだけの選択肢があるというのがすごい。
よりどりみどりなので、各自のユースケースにあった CI サービスを選んで使うといいと思う。

*1:ブランチ最新のみ

Google の Vim script Guide について言っておきたいこと

vim event

この記事は Vim Advent Calendar 2014 の 25 日目の記事です。

Google が、様々な言語に対する自社内でのスタイルガイドを公開しているのはご存知でしょうか。C++ のものや JavaScript のものなどがあり、この辺りは割と有名かと思います。
では、Vim script のものがあるのはご存知でしょうか?
Google は、Vim script について、2 つのガイドを公開しています。

前者がカジュアルユーザー向け、後者がヘビーユーザー向け、といった位置付けのようです。さすが、Google がまとめているだけあって、なかなかポイントを抑えています。
ただ、これはあくまで Google が社内向けに作ったもの。鵜呑みにしてはいけない、もしくは、一般の人が使う場合は参考にしない方がいい部分もちらほら見受けられます。
そこでこの記事では、この 2 つのスタイルガイドを見るにあたって注意すべき点をまとめようと思います。全て個人の見解です。引用に入っている訳は、私による勝手訳です。

全体について

maktaba が前提になっている

Google が公開している、maktaba と言う Vim プラグイン向けのプラグインライブラリがあります。
これらのガイドでは、事あるごとに、Vim のこの機能は使わないで代わりに maktaba のこれを使え、のように指示してきます。
しかし、誤解を恐れずに言うと、maktaba はその仕組み上使うべきではありません。
ざっくり簡単に理由を言うと、maktaba は $ から移すことができない jQuery のようなものであり、別の言い方をすると、URL にバージョンが含まれていない Web API のようなものです。今後互換性のない変更が入った瞬間に死亡する未来がありますし、今でも、maktaba のバグに依存した動作をするプラグインはバグが修正されると死にます。
と言うわけで、maktaba 云々と書かれている部分は華麗にスルーするのが良いです。

Google Vimscript Style Guide

Regular Expressions

Prefix all regexes with \m\C.

全ての正規表現は \m\C で始めること。

\m は 'magic' がオンの状態で正規表現の解釈を行い、\C はパターン全体を大文字小文字を区別するようにします。
これは確かに誤爆を防ぐのには役に立ちますが、毎回指定するのはやや冗長です。
正規表現を受け取る Vim script の関数のうち、'magic' オプションが適用されるのは search() と searchpos() くらいです。
よく使う =~# も 'magic' の影響は受けません。
'ignorecase' オプションの影響を受けるのは、match()、matchend()、matchlist()、matchstr()、search()、searchpos()、searchpair()、searchpairpos()、substitute() になります。多いようですが、match() とその派生、search() とその派生、substitute() なので、系統としては 3 つくらいです。
この辺りはざっと調べたものなので、足りなかったり違っていたら教えてもらえると助かります。
自信がなければ \m や \C を付けておくのは悪いことではないですが、必須にするほどでもないかな、と思います。

Type checking

Use strict and explicit checks where possible.

可能ならば厳密かつ明示的な型チェックをしなさい。

is# などを使え、というのはその通りですが、全ての変数を使う前に型をチェックするのは冗長になりすぎます。
例えば Ruby を書いていて、全ての関数で、その引数について型のチェックをするコードを書くでしょうか? 書きませんよね。
期待した型でなければ、大体の場合は例外が飛ぶので、きちんと例外を処理すれば問題はないでしょう。たまに運悪く期待しない状態のまま先に進んでしまうこともありますが、その時はその時です。

Python / Other Languages

Python
Use sparingly.
Use python only when it provides critical functionality, for example when writing threaded code.
Other Languages
Use vimscript instead.
Avoid using other scripting languages such as ruby and lua. We can not guarantee that the end user's vim has been compiled with support for non-vimscript languages.

Python は慎重に使いなさい。他の言語は使ってはいけません。

はい。Google なのでお察し、といったところでしょうか。Python だけ許可して他を許可しない理由が全く説明されていません。
個人的な見解を述べるならば、外部インターフェースは余程の必然性がない限りは使うべきではありません。理由は Google が説明している通りで、ユーザーの Vim で使えるとは限らないからです。これは当然 Python にも言えることです。
ただ、あなたが書く Vim script があくまで自分向けのものであれば、書き易いように外部インターフェースを使うことは選択肢となりえるでしょう。他言語であればすでに揃っているライブラリを Vim script でわざわざ書き直すような真似は、一部の変態さんたちに任せて、あなたは使いなれた言語で使いなれたライブラリを使えばよいのです。
…私は変態さんなのでもう手遅れです。

Commands

In the plugin/commands.vim or under the ftplugin/ directory, defined without [!].

plugin/commands.vim か ftplugin/ ディレクトリに、[!] を付けずに定義します。

plugin/commands.vim に、と書いてますが、絶対にやってはいけません。
最近でこそ Vim プラグインはプラグインマネージャでインストールして、runtimepath を追加していく方式が流行っていますが、本来は Vim プラグインは 1 つのユーザディレクトリにまとめていれていくもので、そのような運用も可能になっているべきです。
みんながみんな plugin/commands.vim にコードを書いたら、当然ファイル名が衝突します。
ちなみにどうやらこのファイル名のルールは maktaba によるもののようです。
[!] については、適切なコマンド名を付けていれば、ユーザの定義を上書きすることはほとんどないかとは思いますが、ここはどちらでも良いと思います。

Autocommands

Place them in plugin/autocmds.vim, within augroups.

plugin/autocmds.vim に、augroup 付きで定義しなさい。

Commands と同じファイル名の問題。

Mappings

Place them in plugin/mappings.vim, using maktaba#plugin#MapPrefix to get a prefix.

plugin/mappings.vim に、maktaba#plugin#MapPrefix を使って定義しなさい。

Commands と(ry
maktaba(ry

Naming

Prefix all variables with their scope.

全ての変数にはスコープのプレフィックスを付けなさい。

l: については無理に付ける必要はないと思いますが、一部の変数名が v: と衝突する可能性があるので、付けた方が安全ではあります。
私は省略する派です。

Google Vimscript Guide

こちらはヘビーユーザ向けということで、Style Guide の方の内容も含まれています。重複していない部分について言及します。

Structure

ここに書かれているものの多くは maktaba 前提の構成のようです。

Documentation

Use vimdoc.

vimdoc を使いなさい。

この vimdoc というツールは、私もあまり詳しくないのですが、軽く調べてみた限りだと maktaba の構成に依存しているようです。
あとは変則的な help に対応しているのかがちょっとわかりませんでした。




と言うわけで、個人的に問題があると思う点を挙げてみました。
結構色々書きましたが、最初に言った通りポイントは抑えられていて、maktaba に絡まない部分はかなり参考になります。つまり諸悪の根源は maktaba…。


これで今年の Vim Advent Calendar は終わりです。でも、皆さんの Vim ライフは始まったばかりです。それではまたいつの日か、未来でお会いしましょう！

VimConf 2014 を開催しました

vim event

去る 2014年11月8日、VimConf 2014 を開催しました。
私は、主催、というわけでもないのだけど、本会開催スタッフの中心人物的な感じで関わらせていただきました。
VimConf は本当に多くの人の協力で成り立っています。私は今回、あちこちの人に色々お願いして回るのがメインで、みなさんの協力があって初めて開催することができました。
ボランティアスタッフとして手を挙げ、手伝ってくれた皆さん、発表者の皆さん、そして参加してくれた皆さん。本当にありがとうございました！




とまあ、固い話はこれくらいにして、以下、いつも通り雑に感想書いていくよ！

Identity of the Vim - @

資料: http://koron.github.io/vimconf-2014-koron/
Vim を使うなら色々やろう！と言う話。さすが kaoriya さん、いい話すぎて、最初から感極まりまくりました。
確かに、私もあちこち手を出す習性がある。しかし最近新しいことに手を出せてなくて、いかんなーと思っていたところ。なんとかしたいー。

PM2 - @

資料: https://docs.google.com/presentation/d/1u5A7F3Kd4XwJlIUQZAVmrwWfLcoLf9NURtqAEafi_oo/edit#slide=id.p
vital.vim の ProcessManager version 2 の紹介。
PM2 の正式名、懇親会で決めようと言ってた気がするけど結局決まってない気がする。
あと合法電子ドラッグの Civ5 の紹介もあった。開発が滞っているのはこいつのせいらしい。

f - @

資料: https://speakerdeck.com/rhysd/vimconf-2014-f
f を拡張するプラグインの数々をどどんと紹介。
オチが秀逸だった。便利すぎる。

Hey, Java! Vim is coming. - @

資料: https://docs.google.com/presentation/d/1zaPy82NJ6A3Iw1llKqU-lX88AJNt1EKy5O15nOp085c/edit#slide=id.p
Vim で Java を書くよって話。
幸いにも最近 Java を書く機会はないのだけど、必要になったら色々参考にさせて頂きたい…!

auto closing parenthesis - @

資料: http://www.slideshare.net/cohama/auto-closing-parenthesis-vim-conf2014-41290298
dot repeatable な便利自動閉括弧入力について。
lexima.vim、便利で私も最近使い始めました。閉括弧は私はやってないのだけど、endwise 的な設定がとても便利。
undo の問題も解決するといいなぁ。さっきコード読んでみたけど難しかったのでまた今度見てみる。

怖くないマクロ入門 - @

資料: http://www.slideshare.net/deris0126/vimconf4
初心者向けのマクロ入門。
実演が欲しかった感がある。けどまあ時間的に厳しかったのかな。
マクロはコツを掴むと割と適用できるタイミングあるので、覚えると便利。

Test for Vim script - @

資料: https://gist.github.com/thinca/2cf4ae0df88a99423c9d
私の発表。準備が遅れた結果、事前に全く練習ができず、時間配分とかすごい適当になってしまったけど、適当なりになんとかなった感じはある。…良くはない。
元々、デモで紹介したい themis.vim の機能はいくらでもあったので、残り時間見つつデモで調整する予定だったのだけど、あんまり見せられなかったです。.vimspec はできれば見せたかった。

Let's talk about neovim - @

資料: http://www.slideshare.net/Shougo/lets-talk-about-neovim
neovim に関する topic や、OSS の fork についての話。
neovim は私はほとんど情報を追っていなかったので、ハイライトを知るいい機会でした。
neovim 一度くらいは触ってみた方がいいのかなぁと思いつつ、面倒で触る気が起きない…うう…。

かなりすごい発表（かなり） - @

資料: http://www.slideshare.net/supermomonga/super-cool-presentation-at-vimconf2014
かなりすごかった。(かなり)
ThingsPast.vim かなり前から知ってはいるのだけど、未だに試せていないので今度試す。

XVim with MacVim and smartgrep - @

資料: http://www.slideshare.net/pebble8888/using-xvim-with-macvim
XVim も MacVim も使いたいので、両者を行き来する方法について。
Mac 使ってない勢なので、ふふーん、なるほどね。という感じで聞いてました。
と、チラっと smartgrep の紹介。コメント部分を除外してくれる grep らしい。

/-improved - @

資料: https://docs.google.com/presentation/d/1ie2VCSt9onXmoY3v_zxJdMjYJSbAelVR-QExdUQK-Tw/pub?start=false&loop=false&delayms=3000&slide=id.g4e7add63c_05
検索を高度に使いこなすワザ。私も活用できていないので、もっと活用していきたい…！
上級の光の Vimmer の動きを見ると、ナチュラルにカーソル移動に検索を使っていて、私もやっていきたい気持ちがある。
gn は便利すぎるのでみんな使っていきましょう。

vim script初心者に使ってもらいたい、転ばぬ先の杖「Vint」 - @

資料: https://speakerdeck.com/orgachem/zhuan-banuxian-falsezhang-vint
Vint、発表を見て早速入れてみました。速いらしいし、設定も柔軟らしいし、とても便利そう。
…なのだけど、私の環境で vimrc をチェックしたら Vint 自体がエラーで死んでしまった。後で報告して修正に協力したい所存です。

Jenkins + vimenv で 最新のVimを使おう！ - @

資料: http://www.slideshare.net/raa0121/jenkinsvimenv-vim-vimconf2014
常に最新の Vim が使えて、過去の Vim もいつでも使える環境を整える話。
シェルのコマンドを使って欲しい情報(今回の場合はVimのバージョン)をどうやって取得するかと言うあたりがメインだった。
ちなみに、ビルド済みの Vim を全部取っておくとかなり容量を食うらしいので注意。

懇親会

大量のピザと寿司で懇親会。寿司は大変に良さがあった。
なるべく色んな人とお話しようと、それなりに回ってみたつもりではあったけど、やっぱりそんなに多くの人とはお話できず…。
最後の方で、Vim script テクニックバイブルの来場者プレゼントをしました。Vim のバッファに名前を書いていってもらい、vital.vim の Random モジュールで3名の当選者を一気に出すという方式。結果、@ さんと、@ さんと、@ さんに当たりました。あと一人はどなただったか失念…k_takata さんに教えてもらいました！*1。おめでとうございます！



まとめ: 感極まった。

*1:当選者メモっておくべきだった。失敗した…

Nagoya.vim #2 に行ってきた

vim event

9/20(土) に名古屋で開催された、Nagoya.vim #2 に行ってきた！初名古屋！
お昼前頃に現地に到着し、@ さん、@ さん、@ さんと合流してランチへ。みんなが味噌カツを食べる中私は特選名古屋コーチン親子丼を食べ、満足したところで Nagoya.vim 会場へ移動した。

本会

会場は和室でした！和むー。
全員が自己紹介と本日やることを発表し終えたところで、みんな作業開始。したかったのだけど、私は事前に頼まれていたライブコーディング的なことをしました。
いくつかネタのストックがあったので、その中から、バッファ内に行末スペースとかそういうアレがあった場合に statusline に警告表示を出せるようなプラグイン、を gdgd と作りました。
今回、作るものは本当に↑に書いた程度のことしか決まっていなくて、ユーザーからの設定方法とか内部的にどういう感じにしようとかそういうのが全く決まっておらず、手が止まっている時間がかなり長めになってしまって、参加者の中でも自分の作業の手を止めて私の作業を見ていた人にはすごい申し分けありませんでした。
今回学んだのは、作るものじゃなくてどういう設計にしようかもある程度は考えておかないと駄目だなってことだった。事前に作るのは反則としても、設計くらいは考えておかないとなぁ。
作ったものに関しては所々手直しして後日公開しようと思ってます。面倒になって忘れ去られる可能性もあります。
ライブコーディング以外では、相変わらず themis.vim の時期バージョンの作業をしてた。まだそれなりにかかりそう…ぐぬぬ。

懇親会

本会が早めの時間に終わったので、早めの時間からやってる飲み屋さんで懇親会しました。
色んな話をしたけど、全体的に大体 @ さんと rogue.vim の話をしていた気がする。rogue.vim 以外の話があまり記憶にない。ヤバい…。
あとは名古屋で行くと良いスポットなどを教えてもらったりなどしました。

2日目

2日目って書いたけど、Nagoya.vim は全く関係なく、私と @ さんと @ さんと @ さんの 4 人で名古屋を観光した話なので、完全におまけです。ちなみに夜はホテルに泊まって3時頃までスマブラしてました。観光する気あるのか。
朝食は、懇親会で教えてもらった小倉トーストを食しました。完全にうまかった。トーストに載せる意味があったのかはわからなかったけどアンコうまい。
その後名古屋城まで散歩も兼ねて徒歩でテクテクと行き、名古屋城をグルッと見学しました。途中犬さんなどがベンチで休憩がてら進捗を出したりしていたので、Nagoya.vim っぽいなーとか勝手なこと思ってた。
続いて、同じく懇親会で教えてもらった、喫茶マウンテンへ。

これは普通においしかった！量がちょっと多かったけど。
最後に名古屋駅に戻って、ひつまぶし食べました。完全にうまかった。欲を言えば空腹の状態で食べたかった。マウンテンめっ…。
そんなこんなで名古屋を満喫しました。基本的にどこ行っても食べ歩きしかしてない。




今後 Nagoya.vim は精力的に開催されるとの噂があるので、今後の動きに注目したいです。毎回は無理だけど、機会があったらまた参加したいですね。

momonga.vim #6.2 に行ってきた

vim event

去る週末の土曜日に、momonga.vim #6.2 に行ってもくもくするなどしました。
ポポラマーマでランチにパスタを食べ、夜は寿司でも食べようかと思ったけど人数的に入れなかったので適当にラーメンを食べ、半徹夜明けの日曜はバーガーキングで遅めの朝食を食べて解散するなどしました。
おいしかった。おしまい。




と言うわけにも行かないので進捗の話をします。
私は themis.vim のバージョン 1.2 の作業をしていて、リリース候補版のブランチを push することに成功しました。

https://github.com/thinca/vim-themis/tree/v1.2dev

様子を見つつ遅くても今週中にはマージしようかと考えてます。様子見ると言ってもこれ試して不具合や要望をしてくるような人がいるかどうかかなり怪しいので、まあそのままマージされる可能性が高いです。
できればもうちょっと本体のテストを追加してからマージしたい気持ちはあるけど、面倒になったらやらない可能性もある。しかしできれば増やしたい。つらい板挟み。
ちなみに 1.2 の目玉機能としては、.themisrc ってファイルで色々事前処理ができるようになりました。詳しくは help を。

そんなこんなで、themis.vim はこれの次の 1.3 でようやく個人的に使えると思えるレベルに達する予定です。ここまで行ったら vital.vim で使うよう提案してみる予定。はやく 1.3 まで漕ぎつけたい。
と言うわけで momonga.vim は結構作業捗るのでとても良い感じがあります。次回いつかなー。