ErgoDox EZ を使い始めて1ヶ月ぐらい経った
タイムラインで購入している人がちらほらいて,評判も良好みたいなので ErgoDox EZ というキーボードを試しに買ってみることにしました.購入したのは無刻印+アームレスト付きの赤軸です.
(画像は公式サイトから)
とりあえず購入して1ヶ月経ち,そこそこ慣れてきて違和感なく打てるようになってきたので,この辺りで備忘録がてらまとめてみることにしました.
購入
他の人のブログを読んでいると手続きして2週間以上かかったりしていたので,お盆明けぐらいに届けば良いかなーという気持ちで7月22日に購入手続きをしました.しかし実際は台湾からの発送で1週間で届きました.8月頭に1週間サンフランシスコ出張があったので受け取れなかったら返送されてしまうとヒヤヒヤしましたが何とか直前に受け取れました.
セットアップ
出張前にとりあえずセットアップだけしました.と言っても箱から出して高さを調節して設置してみて,ファームウェアのビルドができることを確認しただけです.
この記事がとても参考になりました.コマンドラインから make
一発でビルドしてファームをキーボードのマイコンに焼きこむところまで出来るのでかなり楽です.
ErgoDox のキーボードファームウェアはオープンソースで開発されているので,リポジトリ を手元に clone してきて必要なクロスビルド用のライブラリを Homebrew で入れるだけで OK です.
他の人のブログ記事を読んでいると qmk_firmware
リポジトリを fork して自分の設定を足している人が多いですが,僕は設定ファイルは極力 dotfiles に置きたいので,clone してきたリポジトリ内に ergodox/keymaps/rhysd
をつくってその中に dotfiles からシンボリックリンクを張りました.この辺は何でも良さそうですが.
なお,デフォルトだと PC がスリープ状態になったときに LED が光って邪魔だったのですが,Makefile 読んでみるとビルド時に指定することでオフにできました.
$ make teensy KEYMAP=rhysd SLEEP_LED_ENABLE=no
キー配置を考える
キーマップいじくるのは好きなのでお盆休みあたりに少し色々試してみました.キーマップは C 言語のプリプロセッサマクロで簡単に定義できます.最終的なキー配置はこんな感じ.(設定ファイル)
- 左側
,---------------------------------------------------. | ESC | 1 | 2 | 3 | 4 | 5 | 6 | |--------+------+------+------+-------+-------------| | Tab | Q | W | E | R | T | { | |--------+------+------+------+-------+------| | | LCtrl | A | S | D | F | G |------| |--------+------+------+------+-------+------| } | | LShift | Z | X | C | V | B | | `--------+------+------+------+-------+-------------' |C-Left| | | LAlt |LG/Eisu| `-----------------------------------' ,--------------. |LGuiEnt| | ,------|-------|------| | | | Home | |Ctrl/ |TapL1/ |------| |Space |Tab | End | `---------------------'
- 右側
,----------------------------------------------------. | | 7 | 8 | 9 | 0 | - | = | |------+------+-------+------+------+------+---------| | _ | Y | U | I | O | P | \ | | |------+-------+------+------+------+---------| |------| H | J | K | L | ; | '" | | = |------+-------+------+------+------+---------| | | N | M | , | . | / | ` | `-------------+-------+------+------+------+---------' |RG/Kana| RAlt | [ | ] |C-Right| `------------------------------------' ,---------------. |AltTab|LGuiSpc | |------+--------+--------. | PgUp | | | |------|BackSpc |RShift/ | | PgDn | |Enter | `------------------------'
基本的には英字配列からあまり外れないように
慣れるのが大変そうなので,基本的な配置はなるべく US からあまり外れないようにしました.例えば左端の Ctrl や Shift などのキーは残す,以前のキーボードで左手で押していた 6 キーは引き続き左手で押せるように移動する(デフォルトでは右手で押すようになってた)など.
ただし,ErgoDox のキーボードの列数は HHK のそれよりも少ないため,どうしても足りなくなります(特に右端の記号列).これはどうしようもないので,あぶれた [ と ] は最下段へ… これはちょっと押しにくいのでもう少し考えたいところです.今までのキーボードは小指の守備範囲が広くて,記号を多用するプログラミングでは結構つらかったので,それが解消されるならお釣りがくるかなという感じです.
単押し,複数押し
ErgoDox ではモディファイアキー(他のキーと一緒に押す Ctrl などのキー)の挙動をかなり細かく指定することができます.例えばキー単体を押した時は半角スペースを入力し,他のキーと一緒に押した時は Ctrl として働くといったことができます.また,Ctrl を押した次のキー入力が Ctrl と一緒に押した扱いになるワンショットなどの挙動も指定できます.
親指にたくさんキーを割り当てられるので,ここはしっかり活用したくて特に左右に2つずつある大きい親指キーには単押しと複数押しにそれぞれ割り当てています.
,---------------. ,---------------. |LGuiEnt|LGuiSpc| |AltTab|LGuiSpc | ,------|-------|-------| |------+--------+--------. | | | Home | | PgUp | | | |Ctrl/ |TapL1/ |-------| |------|BackSpc |RShift/ | |Space |Tab | End | | PgDn | |Enter | `----------------------' `------------------------'
- 左手親指
- 単押しはスペースキー,他のキーと同時押しで Ctrl キー
- 単押しはタブキー,他のキーと同時押しでレイヤー2(後述)のキー配置
- 右手親指
- 単押しは Enter キー,他のキーと同時押しで Shift キー
- バックスペースキー
これだとキー長押しのキーリピートができなくなるのではと思われるかもしれませんが,同じキー2連打以降の長押しはキーリピートとして扱われる仕様のため問題ありませんでした.
ちなみに親指向けにはさらにキーが配置できるようになっていますが,一番外側の縦3つのキーはホームポジションから指が届かないのでほぼ使ってません.この辺は外国人サイズなのかも.さらに Vim 的には Esc キーが親指のほうが良いかなとも思ったのですが,普段 jj
で挿入モードから抜けるようにしているのと,Vim 以外ではほとんど使わないので Esc キーは普段の位置に収まりました.
英数キー,かなキー
僕は IME の状態を覚えておかないといけない 半角/全角 的なトグルキーが嫌で Mac の JP 配列のような英数キーやかなキーを使っています.HHK ではその挙動にするために Karabinar のお世話になっていたのですが,今回はファームウェアのキーマップ書き換えで出来そうなのでやってみました.
最初調べて出てきた情報によるとパッチを当てないとだめとのことでしたが,該当箇所を確認したところ既に修正された跡がありました.issue を漁ってみると下記を見つけました🙏.
Can't use KC_LANG1 & KC_LANG2 key
どうやら既に LANG1
がかなキー, LANG2
が英数キーとして使えるようなのでそのまま使ってみるとちゃんと動きました.Karabinar で設定していたのと同じように,単押しで IM 切り替え,他のキーと同時押しで Cmd キーになるようにしました.
Alfred や iTerm2 に1キーでアクセス
僕は普段ターミナルで作業するので,Cmd+Enter で iTerm2 を全画面トグルで使えるようにしています.また,Alfred もよく使うので,Cmd+Space にホットキーを設定しています.
ErgoDox ではこれらのホットキーを1ボタンに割り当てています.左親指キーの LGuiEnt
というのがターミナルのトグルで,右親指キーの LGuiSpc
というのが Alfred のホットキーです.頻繁に使うアプリのホットキーが1キーになることで思ったより楽になりました.
また,左右のワークスペースへの切り替えも最下段の一番端のキーのみで行えるようにしました(C-Left
と C-Right
がそれです).元々 Karabinar に頼って Ctrl + 左Cmd/右Cmd で切り替えというかなり変わったキー配置をしていたのですが,それが1キーで出来るようになりました.
キー配置レイヤー
ErgoDox ではキー配置にレイヤーを持たせることができ,Vim のモードのように複数のキー配置を切り替えることができます.レイヤーは3つ設定できます(デフォルトのレイヤーが L0 なので残りの L1 と L2).各レイヤーには Vim のようにキー入力で遷移したり,キーを押している間だけレイヤーを変えたり,キーを押した次の入力だけレイヤーを切り替える(ワンショット)といった好きな方法でアクセスできます.
僕はレイヤー3つは使いこなせる感じがしなかったので L1 だけ使い,F1〜F12 や方向キー&Home・Endキー,列が足りなくて再現できなかった右端の記号列のキー配置を設定したりしてますが,F1〜F12 と方向キーぐらいしかちゃんと使えていません.もっとレイヤーを使いこなしたい…
ErgoDox のキー配置(物理)について
ErgoDox は今まで僕が使ってきたキーボードとは違い,縦にまっすぐにキーが配置されています.そのため,以前のキーボードに慣れている指では最初誤入力が多発しました(特に C と V とか).これについてはキーボードに対する腕の向きが大事でした.一般的なキーボードは,キーボードに対して腕がハの字になるように設計されていると思います.それに対して ErgoDox では腕がキーボードに対して垂直になるように意識的に直してやる必要がありました.腕の向きを直すと大分誤爆が減りました.
また,ErgoDox に慣れると今までのキーボードが打てなくなるのではという懸念がありました.しかし今までは HappyHacking (US配列) を使っていて,職場では静音の Realforce (JP配列) を使っているので,新しい配列が加わったという感覚で,今までのキーボードが打てなくなるといったことは無さそうです.
打鍵感と音と振動
これらについては残念ながら以前の HHK のほうが遥かに良かったです.
打鍵感は HHK のほうがキーの押し込みがスムーズで押し心地が良いです.さすがに静電容量無接点方式にはメカニカルでは敵わないのかなという印象でした.
また,僕はキーの押下圧が強くて,HHK の時は特に気にならなかったのですが,ErgoDox では入力の振動が机に伝わってしまってモニターが少し揺れたりすることがあります.この辺りは良い机を買ったりすれば少しマシになるのかもしれませんが…
あと,音もちょっと気になりました.静音でない HHK Pro2 よりも大きいです.自宅では特に気になりませんが,職場でこの音は僕的にはちょっと…という感じです.
肩凝り
僕は昔から結構肩凝りがひどいのですが,それはかなりマシになりました.肩が開いて姿勢も良くなるので,そのおかげだと思います.日中ずっとキー入力していても肩がつらくなってきて中断といったことはほぼなくなりました.
まとめ
今の時点でもう ErgoDox のみでコードを書いたりツイートを書いたりしていて,特に困っていないです.前述のとおり肩凝りが解消されたのと,かなり小指の負担が減ったように思います.あと,キー配置やキーの挙動の自由度がかなり高いので,新しいキー設定を思いついたら即試せて今後も楽しめそうです.
僕自身はキーボードを組み立てる技術が無いので壊れた場合のサポートとかが少し不安ですが,その時は HHK にフォールバックして考えます.新しいおもちゃが手に入ったというのと,肩凝り解消などの実益で,僕にとってはなかなか良い買い物でした.
15K 行のアプリを TypeScript 1.8 から 2.0 に移行してみた
先日 TypeScript の新しいメジャーバージョン 2.0 のコンパイラの beta 版がリリースされました.
コンパイラのチェックの強化や非 null 型,tagged union など,いくつかの機能が追加・強化され,自分の趣味プロジェクトでも恩恵に与れそうだったので試しに移行してみました.
移行してみたのは下記の Electron でつくり中の Twitter Client アプリ(React+Redux)で,全体で大体 15000 行ぐらいです.
下記の手順で修正してみました.
- コンパイラをアップデートしてビルドしてみる
--noImplicitThis
,--noUnusedLocals
,--noUnusedParameters
を有効にしてみる--strictNullChecks
を有効にして nullability をチェックするようにするinclude
で glob を使う- Tagged union types で Redux の Action types をリファクタリングする
- 引数リストに trailling comma を入れていく
- インターフェースやクラスメンバを
readonly
指定する
各段階でビルド&単体テスト確認をするのが大事だと思うので,なるべく細かく段階を分けました.コミットも大体各作業ごとになっているので,随時 diff のリンクを貼ります.
「説明しなくて良いからコードを見せろ」という猛者向けに,下記が今回行った作業の全 diff です.+-1000行弱ぐらいですね.
コンパイラをアップデートしてビルドしてみる
TypeScript 2.0 beta は下記のコマンドで入るので,サッと入れてとりあえず npm run build
してみます.
$ npm install --save-dev typescript@beta
TypeScript 2.0 では処理フローを見て型を付けるようになったので,この時点でビルドが失敗することがあります. 例えば下記みたいな場合です.
type T = 'aaa' | 'bbb'; const v: T = 'aaa'; switch (v) { case 'aaa': /* ここでは v の型は 'aaa' */ console.log('OK'); break; case 'bbb': /* ここでは v の型は 'bbb' */ console.log('OK'); break; default: /* ここでは v の型は never */ console.log('NOT OK', v); break; }
このように,制御フローを見て適宜型を切り替えてくれるようになりました.
上記のように v
の型として取りうる可能性のある型がなくなると never
という型になり,v
を参照しようとするとエラーになります.
never type も 2.0 で導入された機能です.
基本的に煩雑さが減る方向のはずなので,修正は容易なはずです.
--noImplicitThis
,--noUnusedLocals
, --noUnusedParameters
を有効にしてみる
2.0 ではいくつかのチェック機能がコンパイラに追加されました.互換性が理由(?)でデフォルトはオフのようですが,特に理由が無ければ有効にしておいたほうが良さそうです.
tsconfig.json で "noImplicitThis": true, "noUnusedLocals": true, "noUnusedParameters": true
のように指定できます.
機能名の通り各チェックを行って,検知した時はコンパイルエラーに落としてくれます.特に noUnusedLocals
は tslint で検知してくれなかった未使用の import
を検出してくれて助かりました.
ここまではたとえ 2.0 にすぐに上げられないプロジェクトでも一時的にコンパイラのバージョンを上げてチェックさせることで恩恵に与れそうです.
--strictNullChecks
を有効にして nullability をチェックするようにする
2.0 では null
の型がそのまま null
となり,T | null
のように書くことで nullable な型を表現できます.また,undefined
についても同様に T | undefined
のように書けます.
さらに tsconfig.json に "strictNullChecks": true
を追加することで,デフォルトで全ての型を non nullable type として扱うようにできます.
基本的には
null
を代入しているのに nullable でない変数の型に| null
を追加するnull
が来る可能性があるのにチェックしていない箇所は素直にチェックする処理を入れる- 型は nullable だけど実質
null
な値が来ないところには null assertion 演算子(後置!
)を使う
という処理を入れていけば修正は OK です.3. は例えば下記のような感じです.
// 対象の要素が無い時 getElementById は null を返すので戻り値型は本来 // Element | null だが,静的に HTML に id が振られているので実質失敗しない // expr! で expr が null にならないとコンパイラに伝える const elem = document.getElementById('root')!;
また,null assertion 演算子は undefined
にも使えます.
変更箇所もなかなか多かったのですが,他にも細々とうまくいかないところがあり,この変更は思ったより大変でした.
例えば,strictNullChecks
によってオプショナル引数の型が以前と変わります.
function foo(optional?: number) { // 1.8 まで -> number // 2.0 から -> number | undefined optional; }
これだけ見ると問題ないように見えますが,型定義ファイルには,実質オプショナルでないのにオプショナル引数になっている定義が割といっぱいあります. 特にコールバックの引数の指定がまずいものが多く,1.8 までは型的には変わらなかったので問題にならなかったのですが 2.0 では問題になります.
今回例えば困ったのは react.d.ts
の StatelessComponent
です.
interface StatelessComponent<Props> { (props?: Props, context?: any): ReactElement<any>; // ... その他雑多なプロパティ }
上記の props?
が問題です.
const MyComponent: React.StatelessComponent<Props> = props => ...;
今までは上記のようにコンポーネントの型を指定し,引数を推論させていてこれでうまくいっていました.ですが,引数は props?
となぜかオプショナルに定義されているため,
2.0 からは props
の型は Props | undefined
に推論され,props
が undefined
でないかどうかのチェックを入れる必要が出てきてしまいます.
(僕の知識が足りないだけで実は props?
や context?
が実際に undefined
になるようなケースがひょっとしたらあるのかもしれないですが…もしそうなら教えていただけるとうれしいです)
仕方がないので下記のようにしてワークアラウンドを入れています.
const MyComponent = (props: Props) => ...;
これだと引数の型はプログラマが指定したものになるので undefined
チェックを回避できます.現状ではこれで問題になっていませんが,上記型定義の「その他雑多なプロパティ」がほしくなった場合は困ることになります.
また,react-redux.d.ts
の connect()
も困りました.connect()
は mapDispatchToProps
(第2引数)だけを指定したいときは第1引数を null
にできるのですが,第1引数の型定義に | null
が入っていないため
null
を渡せません.仕方ないので手元で react-redux.d.ts
に手を入れ,リポジトリに含めて typeings でインストールしたものの代わりにそちらを見るようにして凌いでいます.
型定義ファイルの更新状況などを見ながら,strictNullChecks
を付けるのは少し待ったほうが良いかもしれません.DefinitelyTyped では今のところ TypeScript 2.0 向けの型定義ファイルの開発を types-2.0 ブランチで進めているようです.
include
で glob を使う
TypeScript のプロジェクトファイル tsconfig.json で指定するソースコード一覧には今まで glob が使えなかったためファイルを1つずつ追加していました.
2.0 からは晴れて *
や **
が使えるようになったのでそれを使うようにします.
**/*.ts
や **/*.tsx
,typings/*.d.ts
のように指定すれば良くなりました.
Tagged union types で Redux の Action types をリファクタリングする
2.0 では tagged union types という機能が入り,union types のどの型の値が入っているのかを,各型に共通のプロパティで判断してくれます. プロパティには string literal type を指定すれば良いようです.公式の What's New に載っている例が分かりやすいです.
flux や redux では type
プロパティを見てアクションの種類を判断するため,アクションの型を tagged union type にすることでうまく型がつくようになります.
/* * action_type.ts */ // 'type' プロパティがタグになる type Action = { type: 'AddSomething', item: Something, } | { type: 'Sort', kind: Kind, } | { type: 'DeleteLast', }; export default Action; /* * actions.ts */ import Action from './action_type'; export function addSomething(item: SomeThing): Action { return { type: 'AddSomething', item, }; } export function sort(kind: Kind): Action { return { type: 'Sort', kind, }; } export function deleteLast(): Action { return { type: 'DeleteLast', }; } /* * reducer.ts */ import Action from './action_type'; function reduce(state: State = DefaultState, action: Action) { switch (action.type) { case 'AddSomething': // ここでは action の型は {type: 'AddSomething', item: Something} になる const next = ...; return next; case 'Sort': // ここでは action の型は {type: 'Sort', kind: Kind} になる const next = ...; return next; case 'DeleteLast': // ここでは action の型は {type: 'DeleteLast'} になる const next = ...; return next; default: return state; } }
大体こんな感じです.これで各アクションの処理内で間違ったプロパティにアクセスしていた時などは全てコンパイルエラーになります. 文字列リテラルが複数箇所にあるのが気になるかもしれませんが,全て string literal 型としてコンパイラがチェックするのでタイポしていてもコンパイルエラーになり安心です. 良い感じです.
ちなみに以前は type
プロパティが取る値を全部 Kind
というオブジェクトに入れて Kind.AddSomething
のように参照していたので,:%s/Kind\.\(\w\+\)/'\1'/g
のように置換して少しマクロを使ってやるだけで
かなり簡単に置き換えられました.Vim 便利.
引数リストに trailling comma を入れていく
個人的にかなり嬉しい機能なのですが,2.0 からは関数の引数に trailing comma が許されるようになりました(公式の例). (配列やオブジェクトの要素は前から trailing comma を許してます).
tslint がチェックしてくれるようになるのを待っても良いのですが,せっかくなので手で置き換えました.\h\w*\s*\(\n
あたりで適当に grep で引っ掛けて修正します.
Vim なら一度行末にコンマを追加する修正を入れれば,他の箇所は .
で繰り返すだけで OK ですね.Vim 便利.
インターフェースやクラスメンバを readonly
指定する
変更するつもりのないインターフェースのプロパティやクラスメンバに 2.0 から導入された readonly
指定をつけてまわります.基本的に大抵のプロパティは変更されないと思うので,デフォルトで readonly
付けるぐらいの勢いで良さそうです.:%s/^\s*\zs\ze\w\+?\=:/readonly /g
とかやると雑にプロパティに readonly
を付けられるので,付けてみてコンパイラに怒られたらそのフィールドを外す感じで機械的に作業できます.Vim 便利.
まとめ
最近ブログ書いてなかった(ネタはあったのに)ので,久々に人柱になった内容をまとめてみました.まだ beta ではありますが,今のところ変なバグは踏んでません.--strictNullChecks
以外はとりあえずやっておいて損は無さそうです.せっかくなので,いずれ 2.0 が正式リリースされた時に役立つと良いなぁと思っています.
『SD別冊 Vim&Emacs』と『SoftwareDesign 5月号』に寄稿しました
SD別冊 Vim&Emacs と SoftwareDesign 5月号の Vim 特集にそれぞれ寄稿させていただきました.
SD別冊 Vim&Emacsエキスパート活用術
http://gihyo.jp/book/2016/978-4-7741-8007-6
Software Design の Vim 特集と Emacs 特集を集めて1冊の本にしたものです.Vim と Emacs について,入門から拡張の紹介,キーボードの話や昔話まであります.1冊読み終える頃にはエディタ成分を過剰多量に摂取できていることでしょう.
僕は 2015年 1月号に寄稿させていただいた「犬でも分かる!?Vim 導入&カスマイズ超基本」という記事を古くなっている箇所を改定して寄稿させていただきました.特にこれから Vim を使い始めたいと考えている方を対象に,インストール方法から Vim の入門の仕方(チュートリアル,プラグイン導入,ヘルプの読み方など)を解説しています.
Software Design で「犬でも分かる!? Vim 導入&カスタマイズの超基本」という記事を書きました
全体を通して個人的に印象深かったのは,まつもとゆきひろさんの記事で Emacs の GC 実装などを見て言語実装を学んだというところでした. 確かに Emacs は Lisp マシンとその上に Lisp で実装されたエディタという構成で,Atom にちょっと似ています(と言っても Atom は下地が Chromium なので全然厚さが違いますが).Emacs に次の GC 発動までに割り当てるメモリサイズとかの指定ができることを考えると普通のマーク・アンド・スイープなのかな.
Emacs の ruby-mode も実装したとのこと.Ruby の end
で終わる構文は地味に厄介で,ある end
が class
ブロックのものなのか if
ブロックのものなのか…というのはぱっとみただけでは分かりません.雑にハイライトするだけなら大して問題にはならないのですが,class ... end
と if ... end
では別のハイライト色を割り当てたいとかなるとちょっと考える必要があります.というのを vim-crystal を実装した時に考えたのを思い出しました.
Sofware Design 5月号
http://gihyo.jp/magazine/SD/archive/2016/201605
Vim と GitHub の連携についての記事を『第1特集 コード編集の高速化からGitHub連携まで Vim[実戦]投入』に寄稿させていただきました.こちらは新規に書いた記事です.
仕事でも趣味でも GitHub を使った開発が非常に一般的になってきましたが,Vim はエディタ,Github はウェブサービス,Git は(主にコマンドラインベースの)VCS という都合上,どうしてもエディタとターミナル,ブラウザ間の移動が多くなってしまいがちです.そこで,Vim プラグインを使って Vim と GitHub の連携をスムーズにすることを目的とした記事を書きました.下記のような tips 形式で紹介しています.
- Vim から Git を使うための Vim 本体の設定
- Vim からコミットを見る(コミットブラウザ)
- Vim から GitHub をブラウザでシュッと開く
- Vim 内でイシュー確認
- GitHub ではほぼ必須な Markdown ドキュメントの効率的な編集(表記法とか)
- リポジトリ URL や issue 番号,絵文字の補完
- Vim + Gist 連携
Git や GitHub 使ったこと無いよ!という方もいると思いますので,どうやって学べば良いかも introduction として書いてみました.
また,他の記事に目をやってみると,
- ujihisa さんの入門記事.インストールからプラグインの概要まで幅広い内容です.
- thinca さんの中級者向け機能紹介.矩形選択やオペレータ・テキストオブジェクト,ドットによるリピート,
gn
など「とりあえず Vim の基本操作は分かった」な人が読むとかなり勉強になる内容です. - tyru さんの正規表現解説.Vim の若干とっつきにくく強力な正規表現の解説です.ここまでしっかり Vim 正規表現とその使いみちについてまとまっている内容はなかなか無いですね.
- mattn さんの Vim の歴史と最新の開発事情について.今年に入ってから version 8 に向けて非常に活発に開発が進んでいる Vim の開発事情と新機能がとても興味深いです.
といった感じで,Vim を使い始めたい初心者,もっと使いこなしたい中級者,Vim ジャンキー各位どの層にもうれしいラインナップとなっています.発売は明日(4/18)らしいので,是非手にとってほしいです.
なお,他の特集については Ubuntu 16.04 LTS の記事とかがとても参考になりました.Python3 や systemd,日本語入力周りの更新,LXD など色々あるもよう.
まとめ
この時期に Vim 関連の特集および別冊を立て続けに出してくるのは技術評論社なかなか攻めてきてるなという印象でした.エディタはプログラミングする上で欠かせないので,春から新しくプログラミングを始めた人とかにリーチすると良いなぁと思っています. 最近は組み込みな現場を離れてウェブサービス開発する部署にいるんですが,周りを見ると Atom 使ってる人が多いですね.Atom とか VS Code の特集も読みたい.
校正などでアドバイスをいただいた編集の方々および vim-jp の方々ありがとうございました.