zplug と tpm を導入して hammerspoon を自動更新するようにした

どうもブログの更新が滞ってしまう。日常的に行っていることをトリガーにしてブログを書くようにすればもっと書こうという気になるだろう。

というわけで dotfiles を更新したらその内容を書き出すようにしてみようと思う。(Qiitaに書こうかとも思ったけど、個人的な話題だし個別の何かの説明とかじゃないのでブログに書くことにする)

ちなみに僕の dotfiles は以下。dotfiles の管理そのものには特別なツールは使っていない。

github.com

zplug を使い始めた

これまでも zaw や zsh-completions などの zsh プラグインは使っていたが、すべて git submodules を使って管理していた。2010 年くらいに oh-my-zsh を使って手痛い目にあってから zsh のプラグインマネージャ的なものを使うことに抵抗感を覚えるようになってこういう素朴な運用になったのだけど、さすがに 2017 年ならいいのがあるだろうと思い一念発起して探してみることにした。

調べた感じ世の中的には antigen がよく使われるらしい。Web+DB Press vol.83 (くらい)の zsh 特集でもこれを使っていた。でも

Antigen is to zsh, what Vundle is to vim.

と README に書かれていて、 Vundle があまり好きになれなかった身なので、なんか引っかかる。vim-plug くらいのシンプルさがいいよ。

というわけでもう少し探索したところ zplug を見つけた。 README に

  • 🌺 It was heavily inspired by vim-plug, neobundle.vim and the like.

と書いてある。作者の id:b4b4r07 さんは Qiita でもお世話になっているのでこれを使ってみることにする。 zplug にして今まで zshrc の一番最後で読み込んでいた zsh-syntax-highlighting を好きなところで宣言できるようになったのが地味な進歩。インストール時のアニメーションがかっこいいのもなんか嬉しい。

tpm 使い始めた

zplug の使い方を調べる過程のどこかで tpm の存在を知る。いつの間に tmux にプラグイン機構が入ってたんだ。zsh でプラグインマネージャを導入するんだからついでにこっちも入れてみようと思って導入することにした。特に競合は調べていないけど、たぶんこれしか無いだろう。

色々な便利プラグインがあるみたいだけど、一度に新しいものを導入しても結局使いこなせなくなってしまうので、ひとまず新しい機能を追加するプラグインは 1 つにとどめて、他は今まで .tmux.conf に自分で書いていた設定を置き換えてくれるやつだけにしておいた。

tpm の README をみたらキーバインドでプラグインをインストールする方法が書かれていたけど、更新時に dotfiles が更新されたら自動的にインストールして欲しかったので dotfiles-sync (dotfiles を同期する自前のコマンド)の中で明示的に実行するようにした。

上で書かなかったけど zplug も同様にインストールするようにした。(綺麗な git コミットが無いので割愛した)

hammerspoon を自動更新するようにした

macOS Sierra にしてから hammerspoon にずっとお世話になっている。hammerspoon 以外で触れる機会がないけど Lua 悪くないなって思う。

hammerspoon でだいたいうまくいくんだけど、たまに設定がバグってしまうことがあって、その都度メニューバーから Reload Config を選択していた。流石に面倒なので調べたら公式ドキュメントにそれにキーバインドを当てる方法が書かれていた。ということでそれを追加した。

で、その公式ドキュメントの次の項目が $HOME/.hammerspoon 以下を監視して、 Lua スクリプトに変更があったら自動的にリロードするというものが書かれており、明らかに良さそうだったのでそれも導入した。

その他

ここに書いた以外にも

  • vim で syntastic をやめて ale を使い始めた
  • vim で easy-motion のバージョンを上げたら色々と捗るようになった

などの変化があった。機会があれば書く。

YARD に --fail-on-warning オプションを追加する PR を送った

久しぶりに public リポジトリに対して PR を送ったので記録として日記を書く。

github.com

YARD は YARD 記法と呼ばれるルールでコメントを書いて付属のコマンドを実行すると綺麗なドキュメントを生成してくれる Ruby 界隈では割りとよく使われるツール。便利なので僕もよく利用するのだけど、 YARD 記法に誤りがあるともちろん出力結果がおかしくなる。正しく書けているか CI でチェックして、もし間違った書き方をしていたらテストが落ちてほしい。

しかし、 YARD はなぜかパース中に変な文字列を発見しても [warn] と stderr に出力するだけで status code は 0 で終了する。多くの CI サービスは status code を見るので、これではテストが通ってしまう。しかもヘルプメッセージを調べもそれっぽいオプションがない。マジか。

と思ったら 機能要望の issue だけが作られた状態だった。しかも “Easy” ラベルがつけられている。

面倒だなと思いつつも、いろいろなところで使っているツールでもあるし、間違いなくあった方がいい機能だと思うので一念発起して書くことにした。まぁ数年前に YARD のコードリーディングをしたことがあって、だいたいどこで何が起こっている分かっていたことも大きい。

結果としては途中 yujinakayama にテストの書き方を相談したりしつつ 1 時間くらいで書き上がって送信。マージされるといいな。

レガシーソフトウェア改善ガイド

Twitter で id:hakobe932 さんが言及しているのを見て、週末にちょうどいい具合の隙間時間があったので読んだ。

レガシーソフトウェア改善ガイド

レガシーソフトウェア改善ガイド

この本ではレガシープロジェクト(保守または拡張が困難な既存のプロジェクト)が抱える問題を説明した上で、それを改善するための技術的話題と、それを取り巻く人間の話が出てくる。開発環境をセットアップするのが困難とかドキュメントが間違ってるとか、そもそもそういうことに気を使わない同僚とか(そして気を使いすぎる同僚も)問題の一部として捉えているのが良かった。

コードがレガシーに(というのは、大雑把に言って、保守が困難に)なるには、多くの理由がありますが、ほとんどの原因は、技術ではなく人間に関係しています。

というのはその通りだと思う。(僕の周りにそういう人がいるとかそういうことを言っているわけではない)

2部からの具体的なリファクタリングの話では、リファクタリングタスクを価値(value)、難度(difficulty)、リスク(risk)の3つの軸で評価した上で、難度とリスクが低い「手がとどく果実」か、価値が高い「傷んだ箇所」に取り組みましょう、というのが良かった。これまでも暗黙的に考えてきた視点ではあるけど、明確に評価するようにすると優先順位づけの議論がスムーズになりそう。

f:id:yuku_t:20170220230759p:plain

リファクタリングすべきか、リライトすべきか、という点に関しては、それなりの分量を使っていかにリライトが良くないアイデアであるかを説明しているので、リライトを主張する人には一読してもらったうえで続きの議論をしたい。

総評としては、分量がほどほどで気軽に読めた割に、コードの品質を高めようという意識が高まったので読んで良かった。チームで読んでみるのも良さそう。

ただ残念な点として、紹介されているツールが基本的に Java プロジェクトを念頭に置いているので、そうでない環境では「Java にはこういうツールがあるんだなー」くらいの価値しかなかった。(本職の人が読んで価値がある内容かも定かでない…)

それからコードの品質を自動的に監視して、その情報をチームのメンバー全員が利用できるようにするために色々なツールの話が出てくる。その姿勢は見習いたいが、Jenkinsのセットアップ方法とかいらなかったのではないかという気がする。