yasnippet

Emacs を使い始めて何年にもなるが、その間一度か二度しかトライしたことがなかった yasnippet に再び、そしてついに手をだした。

Emacs で JavaScript を書いているとき、なんともいえない書きづらさ、リズムの悪さを感じていた。 CoffeeScript を書き慣れているから括弧が鬱陶しいのだろう、と思っていたのだが、どうもちょっと違うようだ、という気もしていて、長年悶々としていた。

先日ふと、「苦手な言語だからリズムが悪い、のではなく、リズムが悪いから苦手に感じるのではないか？」と逆転の発想をひらめいて、いつもより少し注意深く自分のコーディングを意識してみたら、どうやら無名関数 function() {} を書くときのリズムの悪さが乱れの原因だった。

自分の Emacs は主要なプログラミング言語のメジャーモードでバッファを編集中に、開き括弧を入力すると自動的に閉じ括弧が補完されるようになっている（これが electric-pair-mode によるものだ、ということは今これを書きながら調べて知った）これが js-mode でも有効になっているため、無名関数のコーディングの打鍵は、

f u n c t i o n ( C-f SPC {
f u n c t i o n ( C-e SPC {

のいずれかになっており、無意識に運指しているものの非常に窮屈だった。その窮屈さを「リズムが悪い」と感じていたようだ。

そこで無名関数を自分で全てコーディングするのはやめて、 Emacs に補完させようと考え、 yasnippet 導入に踏み切ったわけだ。タブで展開できる略語を覚える気はハナからなかったので helm-c-yasnippet もインストールしてもっぱらそちら経由で使い始めているが、 RSpec の desc など、ものによっては略語がいい感じにタブを打てるタイミングに合うのでスムーズに使い始められそうだ。

まだほんの使い始めなのでこれから徐々に使いこなしていきたい、というレベルだが、一点だけ、 RSpec の desc は yasnippet 標準のものだと Class の補完（置換）結果が１２２２２２２２２２２２２２２２２２２２２２壊れてしまうことがあった。自作のもっと単純なスニペットを作ったが、同じ desc というキーワードだとタブでの補完・展開時に選択候補が二つでてきてしまい、その選択がなぜか矢印キーでないとできなくてちょっと嫌だった。 yasnippet 標準のほうのスニペットを無効化する方法がわからなかったので、深く考えずに元からあったスニペットのファイルを削除して乗り切った。

---

yasnippet にあんまり乗り気でなかったのには、「インテリセンスみたいな賢いものと比べると思想も機能も実用的ではあるが原始的でちょっとダサい」と感じていたのもある。要するに長年の IDE コンプレックスの産物なのだが、去年「ヌーに左手の小指を呪われた運命」だと観念した身なのだから潔くあるべし、と心を入れ替えた。

Contents is king

学習サービスのソフトウェア開発に二年半ほど携わってきて、「主役は教材コンテンツである」ということが、ペンキを重ね塗りするように最初はうっすらと、徐々にくっきりと、心の底から納得するというレベルで「理解」できてきた。自分が作っているソフトウェアはコンテンツを利用するためのツールに過ぎない、ということだ。

ツールがヘボいせいで教材が利用しづらくなり、結果的に教材そしてサービスの価値を毀損してしまうことは十分ありうる。しかし、ツールがどれほど素晴らしくても、教材コンテンツがヘボかったら価値はゼロだ。ダメな教材で勉強したいとは思うひとは誰もいない。ツールたるソフトウェアは価値を殺さず・より引き出すための引き立て役なのだ。

その前提に立ってようやく、あの「UI・UX」というやつが、限定的ながら理解できた。主題が明らかになって初めて、引き立て役が「何を」引き立てるのか、という議論が成り立つ。価値あるコンテンツが利用しやすいユーザーインターフェース、コンテンツの価値を毀損しないユーザーエクスペリエンス。これなら合点がいく。

主題なきまま引き立て役を論じるのは意味がない。「何の」インターフェースなのか、「何への」エクスペリエンスなのか、をぼかしたまま一般論を語る「UI・UX論」のようなものは、詭弁といっていいだろう。

「UI・UX」について考えるときは、「主題は何か？」と自らに問いかけよう。それに答えられないうちは、引き立て役のことは一旦脇においておこう。それよりもっと重要な、最も重要なことをやらなければいけないということが、いままさにわかったのだから。

最近思ったこと

ここ数ヶ月、十数年のソフトウェア開発者人生で初めて、悪名高いExcel方眼紙に書かれた仕様書というものに触れる機会を得たのだが、悪評の理由が身を持ってわかった。

• 装飾過多。長過ぎるフローチャートや謎のテーブル風定義一覧の「見栄え」ばかりよくて肝心のデータの見方・読み方がわからない。
• おそらく装飾にパワーを取られすぎているからだと思うが、仕様の説明に不足がある。フィールド文字列長が何バイトとか書いてあるが超過したとき何が起こるか明記されていない、など。
• そのシステムが実現するビジネスにおける仕様について（仕様書なのに）触れられていない。ドキュメントの書き手が読み手に対して「機械のように指示に忠実に実装だけすればよい」と考えているのが見え透いている。
• 実装例・サンプルコードの類に乏しい。コードを見ればすぐ理解できる類のことを無理にコード無しで伝達しようとするので情報の劣化が激しく、資料として不完全。

などなど。普段使い慣れないMicrosoft Excelに苦労してようやく仕様を読み込み、いざ実装し始めると次から次へと「仕様書に書いていないが不明のままだとプログラムを完成できない微妙な疑問」が湧いてきていちいち仕様策定者に質問しなければならない（そして仕様を書く人を仲介してコードを書く人同士の伝言ゲームが始まり、時間をかけて劣化した情報を交換するはめになる）

自分はそういう「いわゆるSIer」の世界をどうにかしようとか崇高な気持ちは一切持ちあわせておらず、かといって積極的に憎悪を燃やすほどの強い想いもなく、そういう風習が滅んでくれるならそれに越したことはないが、自分は必要最小限しか関わらずに済むようにうまいことやるし必要最小限は我慢もできるので、ぶっちゃけどうでもいいんだけど、ともかく長年「都市伝説では？」と思っていた疑問が一つ解決してすっきりしており、貴重な体験に感謝したい。

最近読んだもの

Moving On

Parse 使って商用サービスやってるところどのくらいあるんだろう（そして流行ってる・儲かってるところは）

MBaaS のサービス終了は利用者にとって非常に難しい状況だと思う。こういうときの退避先が無いからだ。

しかし Parse が偉いのは、データのマイグレーションツールだけでなく、 Parse API 互換のサーバ実装をオープンソースにして公開したことだ。

Introducing Parse Server and the Database Migration Tool

データのエクスポートだけなら最低どこでもやるが、 Parse のようなサービスの場合、データだけもらってもユーザーはどうしようもない（クライアント＝ユーザーのサービスそのものを動かし続けるためには自分で API を書かなくてはならない）そこもちゃんと後始末する姿勢はとてもよいと思う（まぁ過去にもそういう幕引き事例はあった気がするが）

Parse 終了から学べるのは、「どこまで他人任せにしてもよいか」だと思う。

• API は自分で書くべき。プロプライエタリな API が利用できなくなった場合、逃げ道がない。
• データベースは（当然）自分で書かなくてよいが、 API 同様プロプライエタリなものは避ける。
• API やデータベースの運用は任せてよい。自前運用に切り替えるというバックアッププランがある。

つまるところ、「ソフトウェアはサービスを構成する基本的なコンポーネントなので、自分で書くにせよありものを使うにせよ、できる限り自分でコントロールできる選択をしよう」ということだ（その結果、 API は自作しデータベースはオープンソースのものを使う、という結論になることがおそらく非常に多いだろう）

最近読んだもの

Why I Left Gulp and Grunt for npm Scripts — Medium

「gulp プラグインがどの API を提供しているかよくわらかなくて苦労する」にはげしく同意。 grunt もそうだったが、結局外部コマンドとか独立したライブラリを叩くだけで、直接使えばなんのことはないのに、プラグイン経由で引数やオプションをどう渡せばいいかわからなくて（当然ドキュメントになんて書かれていない）ソースコードを読まないと使い方がわからない、ということが何度もあった。