先週末、これを作っていた。mtt
という名前のnpmパッケージで、個人的にまとまっていると嬉しいファイル操作をコマンド化したものだ。実装はTypeScriptで行っている。
指定する引数によって機能が変わり、mtt -r
で$EDITOR
を呼び出して行う一括リネーム機能、mtt -c
でファイルおよびディレクトリを個別に圧縮する機能、mtt -i
で画像ファイルを縮小する機能を備えている。npm instal -g @riq0h/mtt
でインストールできる。
特にエディタを用いる一括リネーム機能は以前から様々なツール(たとえばmmvは有名だ)で世話になっていたこともあり、この機会に自分の手で実装して処理を把握しておきたいモチベが強かった。今回の開発を通して最低限の勘所を掴めたと感じている。
あまり頻繁にリネームをしない人はピンと来ないかもしれないが、GUIベースで数十ものファイルの命名規則を合わせたり一貫性を持たせるのは意外に大変だ。その都度、前提条件に沿ったルールを作成したりいちいちスクリプトを書くのも面倒くさい。しかしエディタを――とりわけVimを――自由に扱えるなら話は別だ。どんなファイル群でもたちまちケリがつく。
とはいえ、もともとライブラリの豊富な言語を使っているだけに、機能面の実装に困るところはさほどなくコーディングコストの大半はエラーハンドリングに費やされたように思う。つまり、この開発にチャレンジングな要素は本質的には皆無と言って差し支えない。
にもかかわらず、あえて手を動かさざるをえなかったのは教本を片手にサンプルコードを真似しているだけでは習熟度が緩やかすぎること、業務として振られてから学びはじめていては遅すぎるキャリアになりつつあることなどが挙げられる。なにかを事前に作り上げておかないともはや感覚が間に合わない。
今回、実装にTypeScriptを採用したのも別にこの言語が好きだからではない。興味ありきならたぶんGoとかを選んでいた。春先に投入されるRails案件においてフロントエンド部分がTypeScriptで実装される予定であり、弊社の規模感からいって開発チームの完全な分業化は難しいと考えられるためだ。まず十中八九、フロント側もやらされる羽目になる。
さしあたり地位にも学位にも守られていない凡庸なプログラマが身を立てていくには、こういう時に意欲的とまではいかずとも一旦もさもさと取り組んでみて「やるだけやった」と即興的な実績を積み上げていくことだと思う。
100%どころか80%でなくてもいい。60%ぐらいの成果で構わない。一部の非常に高度な現場では中途半端な人材の参画がかえって負の出力を生んでしまう事例もあるようだが、凡庸なプログラマが勤める凡庸な企業の案件にそれほどピーキーなシリアスさは大抵求められない。
むしろ替えの効く歯車は替えが効くなりに、どの位置にはめてもそこそこ回ってくれる方がありがたいだろう。そういうわけで、僕はなるべく使い勝手の良い歯車の一つにならんとするものである。そのためには速習的、即応的な挙動が要求され、すなわち実装が義務でなければならないのだ。……という方針で今年からうまくやっていきたい。遅れに遅れたキャリア設計、新年の抱負。