HIKAKINさんのストイックだったサラーリーマン時代を支えたのは、「僕は、ただのサラリーマンじゃない。動画を作って、海外からもたくさん見られてるんだ」という意地でした。

前回はキーボードの自作キットを使って、自分好みのキーボードを作る道を模索した。だが、まだキーボード沼にはさらなる深みがある。 国内外の有志によって、さまざまなオリジナルキーボードが開発されているのだ。市販品やキットでは攻めきれない、エッジの効いたデザインや配列のキーボードを得るためには、この深みへ挑むしかない。 そこでKTUのキーボー道第3回は、基板やケースデータがオープンソースになっているキーボードの自作に挑戦する。キーボード沼のより深い領域に挑んでみようではないか。 今明かされる、KTUのキーボー道の変遷 前回自作したGH60のようなRow-Staggeredなキーボードは、筆者にとってのEndgame（究極の）キーボードたり得ない。PCゲームならいざ知らず、物書きをするには窮屈、かつ運指も不自然なのだ。 両手を自然な形で置くことができ、指を上下に移動すればよいエルゴノミクス配列のキー

某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない