トレタ Advent Calendar 2018 の1日目(初日から遅れ書いてる…)の記事として、コードの品質ということについての短文ポエムをだらだら書いてみる。

『Code Complete』、『リファクタリング』、『リーダブルコード』などなどコードの品質的なものを対象として書かれた書籍は結構あって、ほぼ同じようなことかいてあったりもするのだけど定期的に出版されて、自分もついつい買ってしまうたぐいの書籍の一つ。

これらの書籍でよくある分類はこういうやつ。

  • 読みやすさ
  • 理解しやすさ
  • 美しさ
  • テストのしやすさ
  • メンテナンス性
  • 堅牢性
  • 拡張性

整理する、知るという観点ではこの分類大変よい。

ただ、結局このたぐいの内容は日常で実践する自分のスキルとしたいわけで「習慣化できるかどうか」にかかってる。習慣化するというのは、

  • 一回やれば覚えれるような小さなこと
  • 何度もその場面に出くわすこと

というのが結局ある。で、重要なのは後者で、最初に実践する際の少しのコストを惜しまずに出さないと一生コードの品質はあがらない。例になるコードが結構近くにあってそれを参考にコード書いてしまうこともままあるけど、その際に、もう少し良くならないか?を考えることがなければ、スキルは伸びないし品質も上がらない。

コードの品質については上に書いたように「習慣」でできることが多く、習慣化されてるとほぼコストがゼロなものも多い。となると、そこには品質とスピードのトレードオフ、といったものはない。できる人はコストかけなくてもできる、できない人は時間かけてもできないし、品質の意図的な上げ下げは上げたことがある人しかできない。

コードに限らず「品質」というのはなにかひとつで大きなものを生み出すことはなく、小さなことの積み重ね。当たり前のようにやってる毎日のことに疑問感じて、課題を探しに行って、改善に取り組むことでしか差はつけられないので、結局その瞬間瞬間で何考えながら生きていくかってことになる(極端)。


疲れも溜まってるし眠いしで深夜に書き始めたらまったくとりとめない文章になったけど、書いてなんぼのアドベントカレンダーなのでこれでよし。

今年は公私共に人生最大級で忙しく、またブログを書くのが年1になってしまっており由々しき事態だけど、来年はいくつかの状況を打破して自分の時間を少しでも多く技術に投資できるように画策して、ブログも書いていきたい。

この記事はトレタ Advent Calendar 2017の25日目の記事です(2日遅れ…)。

これはなに?

トレタで約半年間 VP of Engineering という肩書(実質的な活動はそれより前からやってたので約1年くらい)で活動した結果、選択ミスだったかな?というのをまとめてみる試み。

前置き

トレタ入社以後、自分が今の役割である VP of Engineering をやるまでに以下のような役割、役職の変化があった。

  • 2016年4月: サーバーサイドエンジニアとして入社
  • 2016年7月: 他部署や他社からの技術に関する問い合わせ窓口担当、採用担当
  • 2017年5月: エンジニアリングマネージャー
  • 2017年7月: VP of Engineering

そして VP of Engineering という職位は 「人・組織のアウトプットを最大化する」 という役割を担うために作られたもので、そのときに役職名と Job Description をセットで提案したものだった。

VP of Engineering という職位が違う役割をもっている場合には当てはまらない。かもしれない。

アンチパターン 1: Playing VP of Engineering

ここで言う Playing は「業務として特定のプロダクトのコードを書く」の意。

人事を中心にみるといえど、VP of Engineering になる多くの人は現エンジニア、または過去にエンジニアだったという経験を持つはず。個人的にはそうでない人がエンジニアの上長として信頼を得るというのは、よほどの魅力があり、対話力があり、人望がある、いわゆる人間力の塊のような人ではないかと思う。それくらい、エンジニアとの上下関係における信頼構築の基礎となるのは技術理解だと思う。

そのひとが業務として特定のプロダクトに開発メンバーとして参加、コードを書き続けようとするとどうなるか?

答えは、簡単といえば簡単。どちらも中途半端になる。

プロダクトのコードを書くという点については、エンジニアの頭数に(うっかり)カウントしてしまうことでプロジェクトの進捗を滞らせる、という事態に陥る。

加えて本業であるべきはずのピープルマネジメントの部分については、プロダクト開発ほど明確・定量的なゴールが設計しづらいため結果として時間的優先度が下がってしまい、ケアがおろそかになることで問題発見がおくれたり、対応が後手になったりする。

さらに、この役職には部署長としての総務業務(勤怠管理や各種申請の承認)や採用関連の業務なんかも一緒にくっついてくるはずで、思っている以上に業務範囲が広い。ますますコード書いてる時間はない。

こういったことを繰り返せば、メンバーからの信頼はおろか、経営層からの信頼もなくなり、あげくプロジェクトの遅延、予算計画未達みたいな自体にまで発展しかねない。そうなると自身の精神的なダメージはもう取り返しの使いないところまで行くと思われる。

おそらくこれが最悪のパターンのはず。

VP of Engineering になったら業務としてコード書くのは(ひとまず)やめておこう。

アンチパターンを用いてもよい場合

基本的に期限のないものや、いつかやりたいリファクタリング、あったらいいよねというテスト、みたいなところのコーディングについては、ありかもしれない。

が、それも本番にデプロイして問題おきたり CI をとめたりする事態に陥ると即対応が必要なので、やはりできれば避けたい。

アンチパターン 2: Technical Management -> People Management

「テクニカルマネジメント」という用語が適切かどうか、というのはおいておく。役割としてはサービスや開発部に関する新規案件や、技術に関することでだれに聞いたらよいかわからない、そもそもその技術が何なのかよくわからない相談などの担当窓口、みたいな感じ。

この役割の人に寄せられる相談、業務とかは以下のようなものがある(あった)。

  • 他部署から
    • 連携して行う業務についてのメンバー、手法、進め方についての相談
  • 顧客から
    • セキュリティチェックシート記載依頼
    • 利用規約、プライバシーポリシーに関しての技術的・データ的な観点の問い合わせ、確認、説明依頼
  • 他社から
    • セキュリティ監査
    • サービス連携に向けての技術的なやりとり、打ち合わせ参加
      • そのままプロジェクトとして取り組むことになればプロジェクトの立ち上げ
  • 開発部として
    • サービスの障害、セキュリティインシデントに関する取りまとめ
    • 社内の一部署としての振る舞いや意志決定
    • 業務委託契約に関する手続きや管理

そもそも上下関係がほぼない小さなフラットな開発組織から一人選抜してこういう業務に取り組むと、他部署との関係からその人がその部を代表する人のようにどうしてもなっていく。結果、最後にあげたような開発部としての対応や開発総務的な業務も結構くっついてくる(きた)。

こういう業務が中心となり社内に既成事実として確立、運用が回り始めたぞ、ってなってからピープルマネジメントにシフトするというのは、しっかり役割を分解・移譲しないと、単に業務が増えるだけになってしまい、パターン1と同じくとにかく業務範囲が拡大して時間に追われるということになる。その結果どうなるか?というのはパターン1と同じ、全部中途半端になってしまう。

可能であればこのパスは避けたほうが良い。

そもそも技術マネジメントとピープルマネジメント、求められるスキルは結構違うはず。マネジメントというところだけでひとくくりにせず、それぞれ別の人を当てれないか考えよう。

アンチパターンを用いてもよい場合

それでももしこのパスを通るなら、緩やかに移行せず、短めの期間(1ヶ月くらい?)でエイヤッと移行すべきである。既存の技術マネジメント業務に関しては、それぞれの担当をエンジニアに移行・移譲しその業務に関してはサポートに周る。そして VPoE はさっさとピープルマネジメントに集中すべきである。

まとめ

まだありそうだが、長くなったのこのあたりでひとまず。

基本的に 「兼務はダメ、絶対」 ということである。マネジメント業はとにかく範囲が曖昧で広くなりがちなので、時間的なバッファはかなり持っておかないと対応しきれない。そして、人・組織のマネジメントについては失敗の影響はとかく大きいし、失敗・成功という結果が見えづらい、見えるのにもエンジニアリングと違って時間がかかる。

ただ、成功すると持続性が高く、1つの成功からの相乗効果みたいなものも結構あると思う。

それが感じれたときの喜びは大きいし、一人のエンジニアとしての技術・行動で解決できる範囲を遥かに超えたものとなるので、人・組織をマネジメントするというのもまた面白いキャリアパスかも知れない。

VP of Engineering という役割、まぁ結構しんどいのだけど、万人がなれるポジションではなく、全く違う視点から物事を見る・捉えるということができるようになるので、機会が訪れたら一度チャレンジしてみると良いと思う。

2016 年いろいろあったのでふりかえる。

仕事

4月にシックス・アパートからトレタへと転職した。約10年ぶりの転職でもあり、とにかく今年はこれによる変化がすべてだった。

業務的にはフルスタックでなんでも兼務状態の前職から、サーバーサイドに集中して Ruby / Rails ゴリゴリ書いていくぞ、と思っていたが、7月からエンジニアリングマネージャー業をやることになって状況が変わった(役職はついてなくて職務としてだけではあるのだけど)。

どれくらいその業務があるかわからんので一旦来るもの拒まず全部やってみよう、と思ってスタートきったとたん一気に押し寄せてきて、ちょうどやってた開発も結構面倒な案件だったこともあり、キャパを超えて体力的にも精神的にも辛くなってしまった。それもあったので開発タスクを自分から取りに行くのちょと控えた結果、スムーズに行くようになってきたが代わりにコード書く機会が随分減ってしまった。

キャパ超えたのもコード書く機会減ってしまったのも、基本的にはタスク管理全然できていないというところが大きくて、そのあたりの改善のために精神的なところやツール的なところ改善する取り組み始めたけど、いまだに習慣化できてるとは言い難い。

エンジニアリングマネージャー業で一番大きなウェイトを占めているのは組織、特に新規採用周りのところだけど、そもそも別に採用担当経験あるわけでもなく何かにつけて時間がかかってしまった。少しづつ改善されてはいるものの、その中で気づいたことベースに新しい取り組み始めたりしてまたスローダウンさせたりしてるので際限がないといえばない。

一方でエンジニアリングマネージャー業は結構楽しい部分もある。組織について、よいところ・足りないところを探す、未来を考える、最適化するための方法を探るといったあたり、コード書いてても全体最適化を考えるのが好きな自分の性分にあってるのか、結構楽しい。製品開発においてもそれは同じ。コードは書けてないけど。

技術

仕事上メインで使い始めた Ruby / Rails はまだどうにもなれない部分がある。Rails のマジックにまだ全然ついていけてないという感じ。社内輪読会で『プログラミング Elixir』を読み始めて Elixir も少し触ってるのだけど、Ruby がまだ初学者段階にある段階で Ruby の文法とよく似た別の言語を同時に学ぶのは結構混乱してよくないかも。ただ、関数型言語は全く異なる考え方や、アプローチなどたくさんあって頭の体操には大変良かった。

Ruby / Rails に関してアウトプットはないのだけど、こうなったらいいのになぁというところはポロポロあった。にもかかわらずアウトプットは無かった。

ブログも年間で7エントリ。アウトプットする数も少なく、またアウトプットすること自体にも時間がかかるという悪循環に入ってて良くない感じ。

毎年読み始めて途中分断することが多かった『エリック・エヴァンスのドメイン駆動設計』本、3週目にしてついに短期集中読破した。いままでの経験もあってか3週目にしてようやく DDD の基礎固めできた感。

個人

4月の有給消化期間で行ったシドニーは本当に楽しかった。歴史もありきれいな街だし食べ物も結構美味しいし散歩好きにはとてもいい街だった。2時間電車のって徹底的に散歩したブルーマウンテンズは最高だった。また行きたい。

7月末、左足親指骨折した。仕事でいっぱいいっぱいになってる状況をさらに悪化させてタイミング的にも最悪だった。そして骨折のきっかけ自体も最悪だった。もう二度とやりたくない。

家庭

娘5歳。日々成長を感じる。アルファベットもかけるようになったし、サンタさんからもらった(補助輪なし)自転車も2時間足らずで乗れるようになった。すごい。

転職して通勤時間が伸びたことで平日家にいる時間が短くなって家族に迷惑かかってる感は否めないし、さらに仕事が変わってやることも変わった結果ストレスためて不機嫌にしてしまうこともまぁまぁあってだいぶ迷惑であっただろう。それでもなんとか平和な正月すごしてるのはひとえに奥さんの忍耐力に尽きると思うので感謝したい。

毎年夏休み旅行として行ってる久米島は相変わらず最高によくて家族全員の楽しみ。次は別のどこかに、とおもいながらもまた行きそう。

まとめ

仕事も個人も家庭もイベント盛りだくさんの年で人生振り返っても忘れがたい1年だった。思考も生活も仕事にベースにあって、それがうまくいかないと何もかもうまくいかないのは改めてわかった。2017年、トレタは成長期でまだまだ変化が多く、また成長痛みたいなのもちらほらあるのでそれらうまく乗り越えつつ、今年達成できなかった個人的な技術力向上やアウトプットは、エンジニアリングマネージャー業続けるのでことさら増やしたい。

2017年はついに40歳となる節目の年。踏ん張りどころであるが何もかも楽しくありたい。

この記事は『トレタ Advent Calender 2016』 の9日目の記事です。開発メンバーの日々の試行錯誤がなんかいい感じにまとめられた記事が続く中、完全に箸休め感ある内容...。

今年もEmacs

4月にトレタに転職してから業務で主に使う言語をPerlからRubyにスイッチしたけど相変わらず Emacs 使い続けてる。 同僚が RubyMine つかってたのみてちょと挑戦したけどだいぶ脳内変えないといけなくていったん挫折...。 GUI な Emacs も挑戦してみたものの Emacs とターミナルとの行き来がどうにも手間でそちらも挫折...。 結局いままでどおり iTerm2 + tmux + (CUI) Emacs 使ってる状況で、これが加齢か...と感じずにはいられない...。

そんな感じで右往左往してた状況だったので、dotfiles 内にある Emacs 関係のファイルの今年のコミット数かぞえてみたら、

➜ git log --oneline --since=2016-01-01 | wc -l
233

➜ git log --oneline --since=2016-01-01 .emacs.d | wc -l
128

となって、dotfiles 全体で半分以上の変更だった...。意外になんかワチャワチャやってたので振り返る。

use-package

今年は use-package を使うようになって設定をまるっと書き直した、というのが結局一番コミットすうに貢献(?)したようだ。 今までゴミゴミ散乱してたやつがだいぶスッキリしたので精神衛生上だいぶ良くなった。特に helm 周りはこれで結構すっきりまとめれた印象。

(use-package helm
  :bind (("M-x" . helm-M-x)
         ("C-x b" . helm-mini)
         ("C-x C-f" . helm-find-files)
         ("C-c y"   . helm-show-kill-ring)
         ("C-c m"   . helm-man-woman)
         ("C-c o"   . helm-occur)
         :map helm-map
         ("C-h" . delete-backward-char)
         :map helm-find-files-map
         ("C-h" . delete-backward-char))
  :init
  (custom-set-faces
   '(helm-header           ((t (:background "#3a3a3a" :underline nil))))
   '(helm-source-header    ((t (:background "gray16" :foreground "gray64" :slant italic))))
   '(helm-candidate-number ((t (:foreground "#00afff"))))
   '(helm-selection        ((t (:background "#005f87" :weight normal))))
   '(helm-match            ((t (:foreground "darkolivegreen3")))))
  :config
  (helm-mode 1))

(色指定のスタイルなんかまざっとるな...)

Projectile

今更感ありつつも Projectile 使い始めた。これはだいぶ具合がよい。helm-projectilehelm-ag でさらに具合が良い。

(use-package helm-projectile
  :diminish projectile-mode
  :bind ("C-c p p" . helm-projectile-switch-project)
  :init
  (use-package helm-ag)
  :config
  (projectile-global-mode t)
  (helm-projectile-on))

最も使うのは helm-projectile-find-file と helm-projectile-ag で、helm-projectile-ag のお陰でコマンドラインに移動して ag する回数がまぁまぁ減った。 「まぁまぁ」にとどまったのは、helm-ag だとマッチした前後の行を表示できなくて、情報たりなくて結局コマンドラインにもどって普通に ag するということがあるというところで(でもあらためて helm-ag の README 読んだらなんか ag に渡すオプション追加できそうなのでひょっとしてできる?)。

ちなみに生 ag もあまり使うことなくて .gitconfig に以下のような alias 追加して git grep と 生ag の出力だいたい揃えてそちらばかり使ってる(gitで管理されてないものがもはやあんまりないし)。

[alias]
ag = grep --heading --break --line-number --color --show-function

Ruby

そう。Ruby を始めた。が、Emacs の設定はいままで使ってきた Perl ほど森っとしてない。

(use-package ruby-mode
  :mode ("\\.rb$" "Capfile" "Gemfile")
  :interpreter "ruby"
  :config
  (defun my-ruby-mode ()
    (custom-set-variables
     '(ruby-insert-encoding-magic-comment nil))
    ;; use flycheck with rubocop
    (setq flycheck-checker 'ruby-rubocop)
    (flycheck-mode t))

  (add-hook 'ruby-mode-hook 'my-ruby-mode))

(use-package ruby-end
  :diminish ruby-end-mode
  :init
  (add-hook 'ruby-mode-hook '(lambda () (ruby-end-mode t))))

(use-package ruby-block
  :diminish ruby-block-mode
  :init
  (setq ruby-block-highlight-toggle t))
  (add-hook 'ruby-mode-hook '(lambda () (ruby-block-mode t)))

(use-package rbenv
  :config
  (global-rbenv-mode))

(use-package robe
  :init
  (add-hook 'ruby-mode-hook '(lambda () (robe-mode)))
  (add-hook 'robe-mode-hook '(lambda () (ac-robe-setup))))

robe はいまのところそれほど役にはたってないかも。auto-complete と dabbrev の補完で概ね事足りてる感。

Cask やめて use-package + package.el へ

Emacs 25.1 にアップグレードしたら、会社の Mac でなぜか Cask でたしてるはずの load-path からまったく読み込んでくれないという現象に陥って、にっちもさっちも行かなくなった。 結局のところバージョン固定もしてないし使ってるパッケージは elpa、melpa に全部あるものだけだったので Cask は捨てることにした。代わりに use-package が package.el を透過的につかってくれるのを当てにして use-package のみで管理することにした。

(require 'package)
(setq package-enable-at-startup nil)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))
(package-initialize)
(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))
(eval-when-compile
  (require 'use-package)
  (setq use-package-always-ensure t))
(require 'diminish)
(require 'bind-key)

コレ入れて Emacs 起動すれば自動でインストールされるし、あたらしいパッケージ使うときも use-package で設定書いて eval すればよし。バージョンアップも Cask でも雑にやってたのでそのへんの雑さは変わらず、Cask と use-package で2重管理する必要もなくなった。大変具合が良い。

まとめ

来年は RubyMine もっかい挑戦します!

  • カテゴリ:  

転職して2ヶ月、つまり Ruby を始めてから2ヶ月がたった。正直まだあんまり慣れた感がない。とりあえず仕事以外では 2ヶ月で以下をやった。

  • Rails Tutorial を完走する
    • Ruby 大変そうだなということを悟る
  • Ruby 言語ミニマム』を読む
    • それなりに深く知ってる他の言語を持ってる人(自分の場合は Perl)向けのドキュメントとしては最高に良いものだった。
    • これのおかげでシンボルが理解できた。
  • 初めてのRuby』読んだ
    • これも良かった。今となっては対象としている Ruby バージョンが古い部分もあるけど、思想的なところに大きな差異はないと思われるし、2016 年においても価値のある書籍だった。
  • Effective Ruby』半分読んだ
    • Ruby も Perl と同じくやりたいことに対していくらでも書き方があるきがするので、この辺理由も含めて抑えることでよりよくできそうなのでさっさと読破したい。
  • ruby-style-guide
    • 一通り読んでなるべくこのスタイルを使うようにしてみてる。が、いくつか「えー?」と思うところもあったりする。虎穴に入らずんば虎子を得ずの精神で。
  • Emacs 設定
    • projectile 使い始めた(helm-projectile のほう)
    • ruby-mode はほぼいじらず、ruby-end、ruby-block を使ってる程度
    • flycheck で rubocop かけるとか
    • robe 入れたけどなんか動いてない

振り返るととにかく Ruby の文化的なものに馴染むこと中心にやった感じで、コードはそこまでたくさん書いてないかも。そして仕事では Ruby 書いているというよりも、Rails や RSpec 書いてる感が強く、Rails や RSpec は Ruby ではないまた別の何か感すらあって何やってるかわからん瞬間もある。も少ししたらなんかブレークスルーやってくるんだろうか分からんけど、積み重ねるしかないかな、という感じ。

息抜きで iTerm2 + tmux + Emacs な環境下でフォントをイタリック表示できるようにしてみた。

バージョンなどは以下の通り。

  • Mac OS X 10.11 (El Capitan)
  • iTerm2 v3.0.0
  • tmux 2.2
  • Emacs 24.5

terminfo

tmux 2.1 以降 screen-256color など screen- で始まる terminal を default-terminal として設定している場合はイタリック表示を無効にされてるらしいので、別の terminfo entry を作って指定する。FAQ の感じで。

$ cat tmux.terminfo
tmux|tmux terminal multiplexer,
    ritm=\E[23m, rmso=\E[27m, sitm=\E[3m, smso=\E[7m, Ms@, ncv@,
    use=xterm+tmux, use=screen,

tmux-256color|tmux with 256 colors,
    use=xterm+256setaf, use=tmux,

El Capitan のシステムの screen-256color だと underline も表示できていなかったので、それの表示に必要な(?) ncv@ もついでに追加。で、このファイルを tic -x tmux.terminfo としたいのだが、xterm+tmuxxterm+256setaf もシステムになかったりしたのでその辺りを ncurses v6.0 から持ってきて追加する。

$ cat xterm.terminfo
xterm+tmux|advanced xterm features used in tmux,
    Cr=\E]112\007, Cs=\E]12;%p1%s\007,
    Ms=\E]52;%p1%s;%p2%s\007, Se=\E[2 q, Ss=\E[%p1%d q,

xterm+256setaf|xterm 256-color (set-only),
    ccc@,
    colors#256, pairs#32767,
    initc@,
    setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
    setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
    setb@, setf@,

xterm-256color-italic|xterm 256color with italic and underline,
    ritm=\E[23m, rmso=\E[27m, sitm=\E[3m, smso=\E[7m, Ms@, ncv@,
    use=xterm-256color,

で terminfo entry 作る。

$ tic -x xterm.terminfo
$ tic -x tmux.terminfo

iTerm2

iTerm2 で、イタリックフォントを有効にしつつ、Terminal の設定に xterm-256color-italic を設定。

tmux

次に tmux.conf で設定。

set -g default-terminal "tmux-256color"

これで、iTerm2 + tmux 上のシェルで italic 出てるか確認できる。

$ echo `tput sitm`italics`tput ritm`

Emacs

最後に Emacs。daemon モードで起動している場合は emacsclient を、そうでない場合は emacs コマンドを italic 対応した term 環境化で起動する感じ。

alias emacsclient="TERM=xterm-256color-italic emacsclient"

コメントをイタリックにしてみたの図。

悪くない。

参考

本日4月18日付でトレタに入社した。

長らく Perl を中心にフルスタックな形でやってきたけれど、今年は Ruby をメインにしつつサーバーサイドに集中して技術を磨きたい。

あと、有給消化期間に行ったシドニーひとり旅では予定どおり英語について打ちのめされた来たので、やはり英語は今年何とかしたい(シドニーはとてもよいところだったのでまた行きたい)。

がんばろう。

  • カテゴリ:  

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

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

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

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

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

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

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

そういえばずっと 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。