あと味

たくさん情報を食べて、たくさん発信すると、あとになって味わい深い。

Reason(ML) で簡単な Android アプリを作ってみた

ReasonML

Reason は JSX をサポートしているので、React 関連バインディングが充実している。

bs-react-native という React Native のバインディングもあって、これを使って簡単な Android アプリを作ってみた。

github.com

作ったアプリは入力した英語の文章に含まれる各単語が、Ogden's Basic English の制限語彙の単語であるかどうかをバリデーションして、制限語彙外の単語が赤くハイライトされるもの。

Basic English とは、850単語ですべての事象を英語で説明できることを目的としたシステムで、英語が主言語ではない外国の人（日本人など）が、英語が主言語な人、またはそうでない人たちと、英語を介してコミュニケーションを取れるようにするために生まれたシステム。ただ、類似のシステムと比べて、Basic English は流行らずに化石化しているっぽい。日本語の書籍も大昔に出版されたものしかない。詳しくは前述の Basic English の公式サイトや、日本ベーシック・イングリッシュ協会 のコンテンツを参照されたし。

bs-react-native のはじめ方

下記のような流れでアプリを作る。特にハマりどころはなかった。

  1. create-react-native-app で素の React Native アプリ雛形を作る
  2. bs-react-native の README にあるとおり、bs-react-native 用の各種パッケージを追加する（独自パッチの当たった OCaml をビルドするので時間がかかる）
  3. bs-react-native で使用するコンフィグ (bs-config.json) や npm scripts コマンドを追加する
  4. 自動生成されたファイルを微調整する
  5. Reason ファイルを追加する
  6. ビルドしたり、ウォッチしたり、アプリ起動したり（react-native run-android）

あとは、React Native のように Expo で動作確認しながら実装していく。

作ってみた感想

素の React Native を使ったことがなく、Android アプリも作ったことがないので、それらとは比較ができないが、基本的なパーツを使って、お作法通りの使い方をする分には非常に簡潔に実装できた。

現在サポートしているコンポーネントや API は下記で参照できる。

サンプルが下記ぐらいしかないので、bs-react-native のリポジトリと React Native のドキュメントを読みながらコードを書いた。

bs-react-native のベースのライブラリになる、reason-react 自体は下記の公式のドキュメントやサンプルがあり、他のリポジトリの実装もある。

Reason は OCaml の JSer フレンドリ AltJS なので、インターフェイスファイルを見て型を合わせていけば、大体動いてくれる感じがする。

Reason について

Reason 自体初めて書いた。直近に Real World OCaml を読んでいたこともあって、Reason 固有のシンタックスに少し戸惑ったが、ほぼ JS なので、すぐに慣れる。JS 書ける人ならすぐに書けるようになると思う。

でも JSX を使わないプロジェクトでは BuckleScript を使う気がする。

reason-cli でインストールされる各種エディタ支援機能が便利で、VSCode が推奨されているので、自分も VSCode を使った。

会社で Haskell 入門読書会に参加しているんだけど、Haskell はまだまだ難しくて、実戦で使えそうにない。OCaml は、Haskell よりシンタックスは冗長だけど、書きたければ全部手続き言語的に書けるし、正格だし、オブジェクトもあるしで、関数型言語的に書きたいし、静的型付けの恩恵も受けたければ、OCaml はコンフォートゾーンだと思う。型推論が超強力なので、型を書く必要もほとんどない。

さらに、Reason は JSer にとって学習コストが低めで、JS のワークフローや既存資産をフル活用できるので、実用的な何かを書く場合は、もしかしたら OCaml よりも便利かもしれない。

Elm は Haskell 風だけど、型クラスがなかったりして、OCaml っぽい冗長さがあるのと、JS との相互運用が Reason ほど楽ではなそうで、今となっては Reason と比較して中途半端に感じる部分がある。

Reason は Reason React で、The Elm Archtecture （Elm Archtecture の発明は偉大）を参考に作られた Redux 風のアーキテクチャでコードを書くので、JSX を使用するコードは結果的に Elm っぽくなる。

今のところは Elm の方が記事等を目にする機会が多いけど、バックに Bloomberg と Facebook がいるという点も安心感があるので、自分は Reason に投資していこうと思う。

今年は初の言語単独のカンファレンスがオーストラリアで開催されることもあって、少しは盛り上がりを見せてくれるのではないかと期待している。

www.reason-conf.com

なお、ドキュメント翻訳の進捗は芳しくないです。

ReasonML のドキュメントの翻訳を始めてみた

ReasonML

昨年末ごろから面白そうだなと思ってドキュメントやコードなどを読んでいた ReasonML のドキュメントの翻訳を、自分の理解のために昨年末からボチボチはじめました。

I'd like to try Japanese 🇯🇵 translation. Should I do it here?

https://github.com/reasonml/reasonml.github.io/issues/3#issuecomment-348730986

時間のある時にボチボチやっていこうかなと思ってたのですが、先日急に翻訳テキストが公式に流れ出てしまったので、今慌てふためいているところです。

翻訳元のソースが最新化されて、少し巻き戻ったところもあり、今現在日本語での30%未満という進捗状況です。

翻訳は Docusaurus で作られたドキュメントの翻訳にも使われている Crowdin というサービスで進行しています。

コードを書くことでコントリビュートすることは自分の能力ではなかなか難しそうなので、せめて翻訳でもコントリビュートできればと思って始めたのですが、英語が得意なわけでもなく、この和訳は害悪と言われてしまうと、なかなか悲しいことなので、もし協力いただける方がいたら、ReasonML の翻訳 に参加いただけると幸甚です。

Crowdin はこれまで使ったことがありませんでしたが、サービス上で機械的な翻訳結果を表示したり、翻訳内容について議論ができたりなど、ソーシャル翻訳サービスって感じで、複数人での翻訳がより生きるサービスだと思います。

また、翻訳されるべき本丸は BuckleScript だとも思うので、BuckleScript の翻訳も誰かやってくれるといいなぉ（他力本願）

自分は平日1時間とかそんな感じでのんびり進める予定です。

背景

元々関数型プログラミングに興味があり、会社でも関数型プログラミング勉強会に参加しています。また、転職により、フロントエンド/サーバサイドのどちらでも JavaScript を扱うことになったので、フロントエンドの関数型プログラミング言語をひとつ習得しておこうというのが ReasonML の学習動機です。

昨年は reason_ml Advent Calendar 2017 - Qiita も出たので、今年は少し盛り上がりを見せるのかもしれないし、盛り上がりを見せないかもしれません。（英語圏でも今時点では流行っている感じはしないので今後に期待です。reddit / stackoverflow 調べ。）

あとがき

Perl プログラマが、今後 OCaml プログラマになるのだとしたら当然の帰結なのかもしれない。（ラクダ的な意味で）

Movable Type と Web Components

MovableType

この記事は Movable Type Advent Calendar 2017 の17日目の記事です。

先日、会社にて、事業部の先輩で、Polymer Japan の運営者でもある @sizuhiko さんより、Polymer のハンズオンを受ける機会があり、遅ればせながら Web Components に入門しました。

Polymer は Google が開発を主導しているライブラリで、Web Components のためのポリフィルでもあり、Web Components を簡単に扱えるようにする機能なども提供するライブラリです。

Web Components は、すでに使える次世代の Web 標準テクノロジーで、下記の4本柱からなるテクノロジーです。

  • カスタムエレメント
  • シャドウ DOM
  • HTML インポート
  • HTML テンプレート

私が下手な説明をするより、ググったり、@sizuhiko さんの下記のスライドなどをご参照いただいた方が良いと思います。

それで何ができるの？

Web Components を使うと HTML, CSS, JavaScript で作られた自己完結したコンポーネント（カスタマイズ箇所の定義も自由）を他者に提供したり、または提供されたものを自分のサイトで扱うことができるようになります。

例を見た方が早いと思うので、webcomponents.org を覗いてみてください。このサイトには共有された Web Components がたくさん掲載されていて、例えば Google Maps の機能を扱う Web Components は下記のように提供されています。

Google Maps の Web Components では google-map や google-map-marker といったカスタムタグと、緯度、経度などの専用の属性を指定することで任意のマップを描画できます。

例: 福井県庁の地図を描画する場合

gistba02fd28ccbf22b65f76ceffbe60f90f

他にも、Android 等の UI などで使用されている Material Design 用のコンポーネントが paper- というプレフィックス付きで提供されていたりするので、Material Design を採用する UI などは、CSS を使った煩わしいスタイリングをしなくても、Web Components の技術を使って専用のタグで宣言的に記述できます。

上記の例は汎用的なコンポーネントの例となりますが、自社用のコンポーネントを Web Components を使って構築するというユースケースも当然あり、YouTube の新 UI などはまさにそれに該当するのかなと思います。

YouTube の新 UI では、ブラウザの開発者ツール等で要素を調査すると、ytd- や yt- というプレフィックスの付いたカスタム要素で、UI が構築されていることが確認できます。

それと Movable Type と何が関係あるの？

MT の肝となる機能の一つに MT タグがあります。

MT で管理されているコンテンツは、MT タグを使って取得・加工・表示することができます。単にそれだけに留まらず、外部の API からデータを取得したり、HTML のプリプロセッサとして動くマクロのように HTML を置換したりなど、様々なことが MT タグを通して実現できるようになっています。PowerCMS のテンプレートタグリファレンスを見れば、プラグインで追加したあらゆる機能が、オリジナルの MT タグを定義することで活用できるようになることがわかります。

MT タグが CMS で管理しているコンテンツを扱うための一種のカスタムタグと考えると、Web Components との共通性が見いだせます。

また、MT で管理するコンテンツや機能を定義して、それらを取り出したり、加工するための MT タグを定義して、テンプレート上で HTML と MT タグを記述し、必要な表現を定義するというワークフローが、Web Components のワークフローのそれと類似しているので、MT を使ったサイト制作やウェブアプリケーション制作のワークフローと親和性が高いように思います。

例えば、MT で管理するコンテンツの内、静的に扱いたいコンポーネントは MT タグで定義して、動的に扱いたいコンポーネントは Web Components で定義するといった使い分けができそうです。

試しに下記のようなカスタム要素を作ってみました。Polymer を使うと、このくらいのものであれば、ロジックを書くことなく簡単に作れました。

github.com

bower install https://github.com/taiju/mt-entries-list-sample.git でインストールした後、下記のように HTML インポートして使います。

gistef21bb0771928287f15974c9660e31d8

mt-entries-list というカスタムタグにサイトの ID や、検索パラメータを属性に指定すると、DataAPI を通して動的に記事一覧のリンクを ul > li > a のリストとして描画することができます。

このサンプル自体に実用性はありませんが、これをベースにして、サイトやアプリケーション専用に作り込めば動的に描画できる最新記事一覧や関連記事一覧など、実用なコンポーネントも作れると思います。

まとめ

MT 7 ではコンテンツタイプという機能が追加されるので、何を、どこに、どのように管理するかを、自由に定義できるようになり、よりコンポーネント指向な情報設計ができるようになります。

MT 7 向けの新テーマである Jungfrau（ユングフラウ） を見ると、テーマでオリジナルのコンテンツタイプを提供することも可能なようなので、コンテンツタイプと一緒に、そのコンテンツタイプを取り扱うための Web Components もテーマに同梱するといったユースケースが想像できます。

例えばアンケートを管理するコンテンツタイプと、DataAPI を経由して、アンケートの描画・回答ができる Web Components をセットで提供すれば、アンケートアプリケーションコンポーネントの配布が、テーマの配布だけで実現できそうだなぁと勝手に想像しています。

単純なサイト制作ではなかなか活用の場がないのかもしれませんが、Web Components は将来当たり前に使う技術になると思われるので、MT でどのように活用できるか考えると、いいろいろ夢が広がりそうですね。

ほなの。

永和システムマネジメントに入社しました

ひとりごと

近況をば。

今年3月の話で今さらではありますが、株式会社永和システムマネジメントに入社しました。と同時に福井に出戻りました。

前職

前職のアルファサード株式会社では、PowerCMSという CMS (Movable Type を拡張した CMS)の開発・保守・サポートを担当し、毎日 Perl のコードを読んだり書いたりする日々でした。

良くも悪くも Movable Type は枯れた技術の結晶という感じの製品だったので、この期間でつぶしが効く、エンジニアとしての基礎技能が身に付いたと思っています。逆に新しい技術のキャッチアップができてなかったのは反省点ではあります。

現在

現在、永和システムマネジメントのITサービス事業部という部署に所属しています。

ITサービス事業部（社内では略してITSと呼ぶ）は、Web やクラウドの技術を使った受託開発が中心の部署で、Web が好きで Web プログラマになった自分的にもマッチする部分の多い部署です。

Java の案件が多く、自分も今は Java を書いてます。

これまで LL しかやってこなかったので、知らないことや慣れないことが多々ありますが、LLer 的に Java に入門するタイミングが、Java 8, 9 世代で良かったのかなという気はしています。

引き続き Java 頑張ります。

ITサービス事業部では、事業部内にいくつかの社内勉強会があります。在宅勤務する人や、東京、沖縄にも拠点があるので、Google Meet や TV 会議システムで接続して勉強会を開催しています。

自分は下記の勉強会に所属しています。

  1. Java 勉強会
  2. 関数型プログラミング勉強会
  3. Kotlin 勉強会

Java 勉強会は、先輩社員の作った問題をドリル形式で解きながら学ぶ形式で進めていて、今は Optional の問題を解いています。人数が多いこともあって超スローペースで進行中です。

関数型プログラミング勉強会は、ラムダ算法の基礎の勉強とプログラミング Clojure 第2版の読書会をしていて、前回はチャーチ数を使った 2 * 3 を簡約するという内容でした。自分は JS で解きました。

Kotlin 勉強会は、今期から始まった勉強会で、今は日本KotlinユーザグループさんのKotlin入門のための助走読本の読書会をやっています。

その他、定期的に事業部の飲み会があったり、事業部を横断した交流イベント（LT大会など）もあったりして、これまでの職場では社内のエンジニアと一緒に新しい技術を学んだり、話しあったりという環境があまりなかったのですが、今後は仕事でも様々な刺激を受けることができそうで楽しみです。

これから

ここ数年、インプットもアウトプットもサボりがちだったのですが、心機一転がんばっていかないとなーと考えている次第です。

この広告は、90日以上更新していないブログに表示しています。

と表示されない程度にはここにアウトプットできればと思ってます。

ほなの。

最近の Chromebook の運用、または、GCE のすゝめ

Chromebook

過去の記事を振り返ると、Chromebook がメイン機となって、1年くらい経つらしい。

taiju.hatenablog.com

書いた当初はあれこれ頑張って、Chromebook で Ubuntu を使えるように悪戦苦闘していたけれど、しまいに面倒になってきたので、シンクライアントは、シンクライアントらしく振る舞うべきというところに落ち着いた。

ということで、最近の Chromebook の運用について書く。

GNU/Linux を使いたい!!!

Chromebook 自体は、素の Chrome OS の端末として使うわけですが、ほとんどの生活をターミナルで行っていた私としては、GNU/Linux または、UNIX 環境がないと厳しい。

以前は、記事に書いていたとおり USB に Ubuntu を入れて頑張っていたのだけど、Chromebook をデベロッパーモードで利用しないと駄目だし、USB 邪魔だし、USB 上の OS の動作も微妙に安定しないしで、Chromebook はシンクライアントなんだから、GNU/Linux が使えるサーバを調達して利用するのが楽ということになった。

具体的に言うと、今は、Google Compute Engine (以下 GCE と表記) を、GNU/Linux のサーバとして使っている。

Chromebook からは、Secure Shell を使って、SSH 接続して使う。*1

GCE の良い所

Chromebook だから Google のサービスを使うのが筋って考えも無きにしもあらずだけど、実際に AWS や Azure も使ってみて、私の用途では GCE が圧倒的に便利という結論になった。

GCE が圧倒的に便利である理由は、

  • プリエンプティブ VM インスタンスが超絶安い

  • 分単位の課金

  • VM の起動や作成が速い

といったところにある。

便利である理由の具体的なところ

プリエンプティブ VM インスンタンスとは、いろんな制限つける代わりに安く使っていいぞ、といったタイプの VM インスタンスのことで、具体的には、24時間以上の連続稼働はできないとかの制限がつく。*2

cloud.google.com

私は、GNU/Linux を使いたい時だけに VM を起動して、使い終わったら VM を停止するので、24時間以上使いたいシーンは皆無で、今の Chromebook の運用的にとても適している。

トイレへ行くぐらいのときは起動したままだが、ご飯を食べる時とか、お風呂に入る時は停止するといった運用方法なので、分単位の課金という点も利点になる。

また、VM の起動がめちゃくちゃ速いので、こまめに停止する運用が全く苦にならない。

ディスクの方がコストがかかるので、基本的には初期値の 10GB を起動ディスクに充てるだけにしている。

逆に Chromebook の購入者特典で、Google Drive に潤沢な容量が与えられているので、drive コマンドをインストールして、必要なデータだけ pull, 永続化したいデータだけ push するという運用をしている。それであれば、起動ディスクの 10GB で事足りる。

余計なソフトウェアをインストールしたり、余計なファイルを設置して、ディスクが一杯になったら、VM を廃棄して、新しく VM を立てる。そのために、基本セットは Ansible の Playbook にした。

github.com

Cloud9 も併用

最近は Cloud9 も併用している。*3

Emacs を快適に使えたりはしないが、クラウド IDE 上からアクセスするターミナルから、ある程度は OS を自由に触れるので、ここで事足りるような作業では、わざわざ VM を起動しなくなった。

制限はきついので、VM でしかできないこともある。例えば、Yesod の試用をしてみようとして、インストールを試みるも、cabal update できないとか、Android の SDK 入れようとしたらディスク埋まるとか、そういうやつ。

余談

前回の記事にも書いた、Secure Shell で日本語入力できないという問題は、未だに未解決で、その点が運用に耐えない理由になるという人はいると思われる。

Chrome OS 上の IM では日本語入力できないだけで、VM 上の IM では日本語入力できるので、前回の記事にも書いたとおり、例えば Emacs で Mozc を使うという方式であれば問題ない。

私は常用シェルが eshell *4 なので、全く問題ない。.bash_profile の最終行に exec emacs を記述しているので、すべての操作を Emacs 上で行っている。

まとめ

おそらく今の運用が Chromebook を使う上で、最も正しい運用な気がしている。

しょせん Chromebook はシンクライアントであって、Chromebook 自体であれこれやろうとするのは間違いな気がしてきている。*5

そういう意味では、一番安い Chromebook （3万以下）で必要十分だと思う。高いスペックが欲しければ GCE で調達すれば良いのだし。

今のところ GCE で、ワンコイン（500円）以上かかったことはない。

安く調達できる分、必要に応じて GCE の VM を立てるという方法を取っても、MacBook Air や MacBook Pro と比較して、普通にお買い得である。

この運用の欠点は VM を停止し忘れることによってコストの増大という事故が起こりうることなのだけど、プリエンプティブインスタンスは、そもそも24時間以上連続稼働することはないので、事故の被害額はある程度制限される。24時間以上の連続稼働ができないという制限が保険にもなっている。実感覚では、数時間で落ちるイメージ。

欲を言えば、Chromebook の特典で GCE の VM の利用料が月一定額無料とかがついてきたら最高なんだけどなぁ。

スマホも Android + 格安 SIM にしたし、メインマシンも Chromebook になったし、コンピューティング生活に全く金をかけないという制約の中で、1年間生活してみたが、なんとかなるもんだった。

むしろ、どんな過酷な状況になっても、快適なコンピューティング生活ができる自信がついた気もする。

ほなの。

*1:エフェメラル IP で運用するので、起動のたびに設定を変更している

*2:作業中に VM が落ちることも多々あるので、作業対象はまめに保存しましょう

*3:永遠にリリースされることのない何かを作っているという体で

*4:出力結果が多いコマンドに対するパイプや、入力のリダイレクトをしたい時は、適宜 shell モードを使う

*5:Chromebook Pixel となると話は変わってくるけど

MT のドキュメントを Emacs から引けるようにした

MovableType Emacs

SLIME をインストールすると同時にインストールされる hyperspec-lookup コマンドのように、MT のドキュメントを検索できると良いなと思ったので、hyperspec-lookup を模倣して、パッケージにした。

mt-doc-lookup

https://github.com/taiju/mt-doc-lookup-el

インストールすると、M-x mt-doc-lookup-tags で、コマンドで指定した MT タグのドキュメントをブラウザで閲覧できるようになる。

同様に、M-x mt-doc-lookup-config-directives で環境変数、M-x mt-doc-lookup-modifiers でグローバル・モディファイア、M-x mt-doc-lookup で MT タグと環境変数とグローバル・モディファイアを横断的に検索し、閲覧できる。

リポジトリにも貼っている、利用時のスクリーンショットが下記。

f:id:jdg:20150517231524g:plain

スクリーンショットでは、ido + smex + ido-vertical-mode がインストールされていて、有効にしている状態での操作内容なので、それらが入っていない場合は、初期状態の Emacs の補完機能と同様、微妙な使用感になる。helm など、他の標準の補完機能を拡張するパッケージが入っているなら、その使用感で使えると思う。

mt-doc-lookup の横断検索は、リストから検索するのに対し、mt-doc-lookup-tags のように用途を絞る検索は、ハッシュから検索するので、多分、用途を絞った検索の方が速いと思う。

特に各コマンドを標準ではキーバインドはしていないので、お好みで。

標準では eww でドキュメントを開くようにした。（mt-doc-lookup-browser-function 変数で変更可能）

ドキュメントを閲覧するには eww で必要十分だし、コピペビリティも高くてオススメです。

検索の各候補は下記のワンライナーで出力したものを加工した。もしかしたら、足りてなかったりするかもしれない。

$ perl -Mojo -E 'say g($ARGV[0])->dom->find(q{a[rel="bookmark"]})->map(sub { sprintf q{("%s" "%s")}, $_->text, $_->{href} =~ s|^$ARGV[0]||er })->join("\n")' http://www.movabletype.jp/documentation/appendices/tags/

最初は Emacs lisp でがんばろうかと思ったものの、標準の道具では厳しそうだったので、やめた。

Mojolicious + Perl でのワンライナーだいぶ便利なので、代替なかなかない。

まとめ

これまでも、タグリファレンス等を eww のブックマークから開いて閲覧していたので、ドキュメントへのアクセスのステップが短くなり、今後多少なり捗る気がする。

ただ、ドキュメントがリニューアルしたら、即ゴミになるのが辛い。可能な限り追従したいとは思っている。

Emacs に衣替えした話

Emacs

たぶん、Emacs に衣替えできたので、その話をします。

いつもですます調だけど、である調で書いた。

プロローグ

普段は Vim を使っているが、数年に一度くらい、Emacs を使いたい欲求がどうしても抑えきれなくなることがある。（Vimmer のあるあるネタだろうか？）（多分、コイツは最近 Lisp の本を読んだ）

欲望のまま Emacs を立ち上げ、ひととおりチュートリアルをこなすと、不思議なことに抑えきれなかったはずの欲求が綺麗サッパリ消えているのだ。本当に微塵もないのだ。 そして、あの気持ちはなんだったのだろうかと我に帰り、Vim を立ち上げ、安堵する。「俺にはやっぱりコイツじゃなきゃダメなんだ」と。 そんなやりとりが、これまで何度もあった。

ところが、最近の Emacs には、Evil という悪魔が存在する。

去年も Emacs を使いたい欲求が抑えきれなくなった。（ねぇ？Land of Lisp でも読んだ？？）

欲望のまま Evil をインストールした Emacs を立ち上げた。

普段であれば、すぐに退散してしまうその世界は、いつもと違い、居心地の良さを感じる。

そして、退散することなく、その世界にとどまってしまった。悪魔がそそのかしたのである。

気がついたら、Evil + Emacs を使い始めて半年を超えていたのだった。

Evil 移行期

前述のプロローグに書いたように Evil + Emacs に移行して結構な日数が経っていたが、実際に移行した実感は薄かった。

シェル操作が必要な時（基本は eshell 使いになっているが、たまに必要になる）に tmux でウィンドウを立ち上げて、vim でちょこっとファイル編集し出すと、ふと気づいた時には Emacs 使ってないみたいな状態になっていることが多々あった。

で、その状態でマシンをスリープして、翌日作業を再開したりすると、気づいたら今日 Emacs 使ってないみたいなこともよくあった。

利用時の違和感がなさすぎると、移行はスムーズだが、逆に移行した意義も見えなくなる。

なので、Emacs らしさを取り戻すために、magit や wanderlust のような大きめなアプリケーション使ってみたりして、移行した意義を再認識するようにした。

葛藤の日々

magit とか wanderlust など、ある程度の大きめなアプリケーションを使う時は、Evil 環境下でも、Emacs チックな操作系等を強いられる。

いつの間にか、ESC でモード変わらなくなって、

C-g「馬鹿め、そいつは残像だ」

・・・そして、画面上には j, k の残骸が無数に転がっていた。

みたいな感じになって辛い。

ウェブで探すと、Evil 向けのカスタマイズ例などが見つかるが、アプリケーションごとに書いていくの厳しそうだし、設定の事例自体少ない。

Emacs を使うと Emacs Lisp を書いたり、読んだりする機会が増えるわけだが、Emacs Lisp のデバッグをしようとして、emacs -Q で Emacs を立ち上げた後の自分の無力感が半端ない。

そういった事情があり、Evil を使っていると、Vim 脳と Emacs 脳の切り替えを強いられる状況が多々起こる。 その状態が半年も続くと、意図せず、ある程度 Emacs のキーバインドに慣れてしまっている自分がいることに気づく。

Evil との別れの時

Evil をやめることにした。

ローマ字入力から、かな入力に移行した経験があるので、移行中はイライラ以外に得るものは何もないけれど、強制的に禁じることでちゃんと移行できる確信はあった。

Emacs でも Evil をアンインストールして、使いづらいからといって Vim にも逃げない日常生活を送ることにした。

やはり、数日は何をするにもイライラした。

C-h b (describe-bindings), C-h m (describe-mode) をひたすら叩いた。

でも、数日で慣れた。

かな入力の時より、移行期間は短かった。

まだ、たどたどしい部分はあるが、Vim を起動すると、一旦心落ち着けないと混乱する程度には Emacs 式キーバインドに慣れた。 たとえば、今 Vim でカーソル移動しようとすると、やたら補完される。

設定の見直しの日々

Vim 使っている時にもあまり大した設定はしていなかったし、あまりプラグインも入れてなかった。

現在の Emacs の設定もそんな感じである。

また、自分はデフォルト厨でもあるので、標準機能で事足りるならば、不便を強いられても標準機能を利用したいという指向性がある。

Emacs ビギナーあるあるだと思うが、最初はいろいろなユーザーのおすすめ設定とか、おすすめパッケージをコピペしたり、インストールしたりしていたが、実は使ってないとか、標準機能で十分ということがいろいろありそうだったので、一旦白紙にして標準機能でまかなえるものは標準機能を使うことを前提に、フルスクラッチで設定書くことにした。

例えば、helm とか auto-complete なんかは、ido で十分な気がしたので、ido + ido の拡張パッケージで済ませるようにした。

Evil 期に、いきなり Emacs の応用から入った感じになっていて、dired とか バッファリストの操作など、Emacs の基本をほとんど把握してなかったが、使ってみたら便利そうな機能もあった。 あと、eshell を常用していたが（今も常用している）、tmux + vim での作業文化を引きずっていただけということにも気づき、利用頻度は少し減った。

Emacs は標準でも普通に便利だし、今は、標準機能の理解をもっと深めようというフェーズにある。

Chromebook で使っている設定が下記で、一度すべてリセットしてスクラッチから書き直している途中。*1

内容も薄いので、起動もそれなりに速い。

Evil 期では、おすすめ設定みたいなのをウェブで拾いつつ、init-loader + 各パッケージごとの設定ファイル（ファイル名先頭が連番）みたいな構成にしていたが、各設定ファイルの記述内容が数行程度で、ファイル名の先頭に連番付けていたけど、途中で不要になったパッケージが出てきた時に、連番が飛んで辛い感じになるので、init.el だけの運用にすることにした。

init.el の中の記述についても、どの設定をどの設定の周辺に書こうか迷うのが面倒なので、パッケージ名のアルファベット順で機械的に判断して記述できるようにした。設定順に依存する依存関係が出てくると面倒なことになるかもしれないが。

また、パッケージを管理するために Cask を使っていたけど、実質的には、ただインストールするパッケージの一覧を可視化したいというだけだったので、標準機能で済ませることにした。

ちょうど、設定をスクラッチで書き直し始めるころに見つけた Emacs Startar kit の手法が良さそうだったので取り入れた格好。

init.el で指定したパッケージが未インストールだったら、標準のパッケージ関連機能でインストールするというもので、これで特に問題ない気がしている。

職種がサポートエンジニアで、普段は広く浅く技術を使うため、特定の言語（Perl は毎日使うのだけど、デバッガ+αという感じ）や技術に特化した設定とかはいらない模様。

Emacs に移行して良かったと思うこと（まとめ）

そもそも Vim を使いなしているユーザーでもなかったので、それ Vim でもできるよというツッコミはあるかもしれないけれど、その点はご容赦を。

Emacs に移行した中で、良かったと思うことは、Lisp (Lisp-1, Lisp-2) が読み書きしやすくなるということはもちろんあるけれど、Emacs のことを Emacs で把握でき、Emacs の定義を Emacs で再定義できるという点かもしれない。

例えば、新しく試すモードを理解する場合、C-h m (desribe-mode) でキーバインドを確認して、そこからコマンドの定義にジャンプできるし、コマンドの定義の中でわからない関数があれば、C-h f (describe-function) でさらに詳細を把握できる。そして、今、キーバインドに対応するコマンド名は C-h k (describe-key) で調べて追記している。

Info ドキュメントが提供されている場合は、C-h i (info) で、Info ドキュメントの閲覧ができるし、その操作もしやすい。

新しい設定を書くような場合も、C-h v (describe-variables) で変数の定義を確認して、書いた設定を C-M-x (eval-defun) すればすぐに反映される。

もっとざっくりと apropos-* で、コマンドや関数、変数を探すこともできる。

Emacs Lisp はどちらかと言えば、Common Lisp 寄りな感じなので、shiro さんの Common LispとScheme という記事で言及されている

全部Lispで完結するCL上のプロジェクトの場合、逆にとりあえず REPL起動してasdfでビルド/ロードして、aproposやタグジャンプを使って Lispの「中から」全体を把握してゆく方向になる。

という体験に近い感じかもしれない。

様々な機能が Emacs Lisp で書かれているので、Lisp の知識で読める。

必要に応じて定義を追ったり、デバッグしたり、機能書いたりできるということは、半永久的に日常で利用するツールとして、それ以上に心強いことはないと思う。（まぁ、そんなにする機会ないから詭弁かもしれないけど）

Emacs は、自分の誕生日より早く生まれているツールで、今日まで発展しているので、自分が死ぬころにも普通にあると思う。その頃には、Emacs 50 は超えているかもしれない。

ということで、新米になったところだが、今後は Vim に戻ることなく、Emacs を使い続けることになりそうという実感が、今のところある感じ。

ほなの。

*1:話は変わるが、今年から Chromebook をメインマシンにしていて、Chromebook のシェルで日本語入力できないクソみたいな問題があるので、Chromebook では、ウェブブラウジングで Chrome を使う以外には、基本的に Emacs ですべてのことをこなしていて Emacs 強制ギブス状態となっている。