YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

自作キーボードパーツショップを始めた話

はじめに

本記事はキーボード #2 Advent Calendar20日目の記事です。昨日は@e3w2qさんの「狭ピッチキーボードの世界にようこそ」でした。圧倒的な参照文献数の記事で読み応えがありました。

先日は別のアドベントカレンダーで自作キーボードにはまっている話を書きました。

ymotongpoo.hatenablog.com

本記事ではそれをこじらせて自作キーボードパーツショップを始めた話を書きます。

TL;DR

組み立やすいキーボード、コンパクトなキーボード、自分でキーボードを自作するときに必要な部品が手に入りやすい状況にしたいと思い、パーツショップを開くことにしました。

kochikeyboard.stores.jp

まだまだ不慣れなことも多いですが、よろしくお願いします。

2020年3月以前

コロナ禍以前は勤務先の会社の職務内容的に海外の技術系カンファレンスへの登壇やそこで行われる会議やイベントなどへの参加が月に一度か二度あり、それぞれが1週間前後あったため下手すると月の半分以上が海外ということもあるくらい移動を行っていました。かねてよりエルゴノミクスキーボードへの感心は高く、2013年ころからMicrosoftのエルゴノミクスキーボードを、2015年ころからKinesis Advantage 2を、2016年からErgoDox EZを使用していたのですが、月に半分ほどしかその恩恵にあずかれず、あとの半分は出張先でノートPCに備え付けのキーボードを使って仕事をするという状況でした。

そんな状態でしたので「職場と同様の分離型のキーボード」で「持ち運びがでしやすいコンパクトさ」のキーボードがほしいと長らく思っていたのでした。ErgoDox EZ購入後からときおり思い出しては実現に向けてインターネットを調べていると、2017年後半に自作キーボードというムーブメントを知り、Let's Splitを作っている方々を多く見かけ自分もPCBを購入に至り、さらにはHelixのGBにも参加したのでした。

「これでようやく一つ全身できる」と思っていたのですが、当時は無鉛ハンダを使用して組み立てていたり、適当にやりすぎていたこともあって、ハンダ付けに失敗。さらにLet's Splitの設計の都合もありProMicroを取らないと復旧が不可能という状況になったこともあって組み立てに挫折し、HelixのGBの材料もろともお蔵入りさせてしまいました。

2020年7月〜9月前半

本格的にコロナ禍へと突入し、予定されていた出張もすべてキャンセル、強制的な在宅勤務へと自分の働き方が大きく変化しました。また3-5月は諸々となんとか生活をしていくのに精一杯でなにも他のことを考える余裕がありませんでした。6月になりようやくとりあえずで延期されていたものもすべて白紙となり、生活の方も落ち着き、それと同時にいままで合間の時間にしか使っていなかった自宅のデスク環境も見直すこととなりました。いまこそようやく自作キーボードに取り組む時間ができたと感じ、一念発起して自作キーボードをはじめました。今思えばその初手がCaravelle BLEだったのはなかなかにチャレンジングだったと思います。しかしPCBA済みの基盤だったこと、キースイッチのハンダ付けがPCB直だったことはかなり実装の負担が少なく、また完全無線分離型40%キーボードという、絶対に既成品では得られないものが得られた楽しい体験によって、その後自作キーボードにはまることになったのだと思います。SatTさんには本当に感謝しています。(ケースがあったりフォームがあったりするキーボードを組み立たのもこのときが初めてで、打鍵感など非常に参考になりました。)

その後、多くの方々が設計したキーボードを組み立ていきました。念頭にあったのは前々から考えていた「分離型でコンパクトなキーボード」で、30%-40%を中心にいろいろと調査をしていました。また出張などで荷物の紛失の危険性などもあるので「すぐに組み立られるか」というのも大きなポイントでした。国内で販売しているものや、海外で発表されているものも含めて検討した結果、やはり自分で作るしか無いと思い要点を整理し始めたのが9月の後半でした。

それと同時に自作の薄型キーボードで使われているKailh Choc v1/v2シリーズへ対応しているキーボードの少なさや、Outemu LPの入手のしづらさ(いまは遊舎工房さんで取り扱いがあります)を感じることとなりました。また自分でキットがないものを組み立てようとすると多くの部品を自分で見つける必要があることを感じました。自分がそう思っているのであれば、他にもそう思っている人もいるだろうと思い、在宅勤務で自宅にいる時間も増えたことから「どうせ自分でキーボードを設計して作るなら、そういう材料を自分で揃える羽目になるわけだし、じゃあそういうものを取り扱う場所を増やそう」と毒を食らわば皿まで精神でお店を開くことに決めました。

2020年9月中旬〜10月末

お店を開くということは在庫を用意する必要があるので、この1ヶ月半はひたすらいろいろと仕入れを行っていました。このときに初めて他人に海外送金をし、さらに初めて自分に対して「口座を開いてもらう」という行為をしてもらいました。しかも海外の会社に。海外送金には本当に手間取って、ソニー銀行には多くの書類を送ったにもかかわらず審査を落とされたので、それなりに口座にお金を入れているのにその仕打ちはなんだという気持ちだけが湧きました。

その後、なんとかすべて配送待ちという状況になってから、今度は海外から送られてくるのに2週間弱。海外からの仕入れはこの時差が本当に厳しいです。もちろん高い送料を払えば数日で届くわけですが、そうすると送料がものすごく高くなってしまうので、とても個人で仕入れる数量程度はペイしません。卸とか商社の大変さを勉強できる良い機会でした。

ECを行うための発送関係の備品も同時に揃えました。梱包用ダンボール、緩衝材、納品書や宛名ラベル印刷用のプリンターなど、多くのものを準備して、本当に開店できるのか心配になったのもこの頃です。

また是非取り扱わせてもらいたいと思っていたCorneキーボードシリーズの作者の@foostanさんに連絡をしたのもこの時期です。無理な申し出にもかかわらず、快諾をいただけたことは本当に感謝しております。お店に対しても自作キーボード関連の部品を扱う店が増えることを応援している、と温かい言葉を頂いたことはなにより励みになりました。

10月半ばにとりあえず最低限お店を開ける状況になったので、友人のみに限定公開し、お店のフィードバックをいただきました。フィードバックいただいた方々には本当に感謝しています。一通りECサイトの機能と発送処理も理解でき、なんとかこなせたので安心したのを覚えています。

2020年11月1日〜

前々から月初に開店しようと思っていたので、準備が整ったあとの最初の月初である11月1日に開店しました。

ありがたいことに開店日がたまたまほぼ週間キーボードニュースの放送日だったこともあり、びあっこさんからご連絡をいただいて、放送で取り上げていただきました。(19:21ごろ


ほぼ週刊キーボードニュース #84 カスタムキーボード「Vega」の発売日が発表! ほか (11/1) #自作キーボード

おかげさまで開店から1ヶ月半が過ぎまして、一応特定の部品は2回目の仕入れをするなど、お店がぎこちないながらも動き始めた感じがします。しかしまだまだコミュニティに貢献できているという感じではないので、これからできることを増やしていきつつ、引き続きみなさんに応援いただければありがたいなと思います。

おわりに

とくにとりとめもない記事でしたが、こういう経緯でお店をはじめましたという自分の記録になりました。いろいろと至らない点があると思いますが、なにか感じたことなどがあればどうかお気軽に店舗のTwitterアカウントまでDMやメンションをいただけたら幸いです。

twitter.com

これからもよろしくお願いします。

この記事はCorne Chocolate v2.1で書かれました。

明日は@yoichiroさんです。

gopterでステートフルなPBT

はじめに

こんにちは、Cloud Ops担当者です。最近はGoogle Cloud Profilerがイチオシです。ワークショップやってるんで興味がある方はご連絡ください。

この記事はGo Advent Calendar 2020の19日目の記事です。昨日は@DoarakkoさんのGo の Web フレームワーク Gin にちょっとコミットしましたでした。

Property Based Testingとは

先日開催されたGoCon SendaiでFuzzingとProperty Based Testingについてお話しました。Property Based Testingを簡単に説明すると、テスト対象の関数に対して、入力値の条件とその関数が満たすべき性質(Property)を定義してあげて、入力時をマシンパワーに任せて自動生成しながら、テスト対象の関数の戻り値と性質を表す関数の戻り値を比較して、一致しない条件を探すという、高級なファジングです。詳しくはGoCon Sendaiの発表を見てください。


S3-1 Goにおけるfuzzingとproperty based testing

資料はここです。

ステートフルProperty Based Testing

GoCon Sendaiでの発表ではProperty Based Testingの紹介だったので、一番始めやすいステートレスPBTについての話をしました。それだけでも十分有用なのですが、PBTが真に力を発揮するのはステートフルなテストを行うときです。発表でも紹介しましたが、LebelDBのバグを発見するのにステートフルPBTが使われました。

groups.google.com

このバグは17ステップを特定の条件で踏まないと再現しないという、非常にややこしいものだったのですが、PBTはきちんとその手順を見つけてきました。人間がこれを発見するのはほぼ無理なのではないでしょうか。他にもステートフルPBTが見つけたバグは多くあります。

他にもDropboxが分散同期システムでのバグを発見したり、Volvoが車載システムの検証に使ったと多くの事例があります。たとえば

  • ショッピングカートの実装
  • オンラインゲームなどでのターン制戦闘の管理やポイント処理周り
  • 決済システム
  • ステートフルプロトコル

など、多くの場面で有用でしょう。

GoでステートフルPBT

GoでPBTをする場合にはいくつか選択肢があります。

github.com

github.com

gopterのほうが多くの事例があるので、いま使うのであればgopterのほうがいろいろ都合がいいと思います。発表やスライドにもありますが、ステートレスなPBTの場合に、PBTの実行は properties.Property() にテスト自体の説明と、テスト対象の関数を渡していました。(次はステートレスPBTの例)

func TestSqrt(t *testing.T) {
    properties := gopter.NewProperties(nil)

    properties.Property("greater one of all greater one", prop.ForAll(
        func(v float64) bool {
            return math.Sqrt(v) >= 1
        },
        gen.Float64Range(1, math.MaxFloat64),
    ))

    properties.Property("squared is equal to value", prop.ForAll(
        func(v float64) bool {
            r := math.Sqrt(v)
            return math.Abs(r*r-v) < 1e-10*v
        },
        gen.Float64Range(0, math.MaxFloat64),
    ))

    properties.TestingRun(t)
}

gopterでステートフルなPBTを行う場合は commands というサブパッケージを使うことになりますが、ステートフルPBTを行う場合も、実行はステートレスなPBTと同様に properties.Property() 関数でおこないます。ただし、渡すのが commands.ProtoCommands になります。

func TestAll(t *testing.T) {
    if testing.Short() {
        t.Skip("skip PBT in short mode.")
    }
    parameters := gopter.DefaultTestParameters()
    parameters.Rng.Seed(1234) // デモなので常に同じ結果になるようにシードを固定

    properties := gopter.NewProperties(parameters)
    properties.Property("buggy counter", commands.Prop(buggyCounterCommands))

    properties.TestingRun(t)
}

これが何者なのかを説明することでステートフルPBTの書き方がわかりやすくなるので、以下で説明します。

ステートフルPBTに必要なもの

上の発表はスライドを読む時間がない忙しい人に、そもそもPBTは何をするものなのかという点をもう一度簡単に書くと「テスト対象の属性(Property)を表すものを定義し、入力値をランダムに生成して、テスト対象が返すものと属性の実装が返すものが不一致ならテスト対象に問題があると判断する」というものです。(下図参照)

f:id:ymotongpoo:20201219214846p:plain

ステートレスPBTの場合は上の図のPropertyが関数にしかならないのですが、ステートフルPBTの場合はそれが変数と関数の組み合わせだったり、メソッドをもった構造体です。比較対象も直接出力値を比較するというよりも「状態」を比較することになります。そして入力値は値を入れるというよりも「呼び出す関数(およびその引数)の組み合わせ」になります。整理して

  • ステートを持つテスト対象
  • 状態
  • 呼び出す関数の組み合わせ

が必要になります。

百聞は一見にしかずで、ドキュメントの例にある次の関数を見てみましょう。

テスト対象

まずテスト対象を定義します。これは普通に機能を実装するだけなので、PBT関係なく行います。ここではカウンターを実装します。例ではわざとバグを作るためにカウンターの値が3より大きい場合は、デクリメントの際に2を引くことにしています。

type BuggyCounter struct {
    n int
}

func (c *BuggyCounter) Inc() {
    c.n++
}

func (c *BuggyCounter) Dec() {
    if c.n > 3 {
        // Intentional error
        c.n -= 2
    } else {
        c.n--
    }
}

func (c *BuggyCounter) Get() int {
    return c.n
}

func (c *BuggyCounter) Reset() {
    c.n = 0
}

状態の定義

次にテストファイルで書く内容です。ステートフルPBTでは状態を比較することになるので、比較対象として状態を管理するためのオブジェクトを定義します。カウンターは状態としてカウンターの数値しか持っていないので、ここでは特段構造体などを用意せず、intとします。とりあえずこのことだけ理解した上で次の話に進みます。

コマンドの定義

gopterで「コマンド」と呼んでいるのは、状態を持ったオブジェクトに対する操作を指します。なぜ「コマンド=関数/メソッド」と呼ばないかといえば、コマンドは「一意な操作」の単位なので、たとえば引数を取る関数であれば、引数の値ごとにコマンドが異なります。(カウンターの例では引数なしのメソッドしかないので、たまたまコマンドとメソッドが1対1対応しています。)

カウンターの例でいうと IncDecGetReset の4つのコマンドを定義します。まず Get メソッドと Inc コマンドに対応するコマンドを定義してみます。

var GetCommand = &commands.ProtoCommand{
    Name: "GET",
    RunFunc: func(systemUnderTest commands.SystemUnderTest) commands.Result {
        return systemUnderTest.(*BuggyCounter).Get()
    },
    PostConditionFunc: func(state commands.State, result commands.Result) *gopter.PropResult {
        if state.(int) != result.(int) {
            return &gopter.PropResult{Status: gopter.PropFalse}
        }
        return &gopter.PropResult{Status: gopter.PropTrue}
    },
}

var IncCommand = &commands.ProtoCommand{
    Name: "INC",
    RunFunc: func(systemUnderTest commands.SystemUnderTest) commands.Result {
        systemUnderTest.(*BuggyCounter).Inc()
        return nil
    },
    NextStateFunc: func(state commands.State) commands.State {
        return state.(int) + 1
    },
}

Name フィールドはこの操作の愛称です。これはテスト結果に出力されるので、1単語でわかるくらいの短いラベルが良いです。それぞれ "GET"、"INC"としています。

RunFunc フィールドはテスト対象側で実行する操作です。commands.SystemUnderTest をテスト対象のオブジェクトにキャストしてから、対象の操作を実行します。

PostConditionFunc はコマンドを実行し終えたあとに行う処理です。通常はここで状態の比較を行います。また、ここでフィールドに与えている無名関数の引数に commands.Statecommands.Result がありますが、stateは自分がテスト用に用意した状態管理用のオブジェクト、resultはRunFuncの結果です。それぞれ int なので int にキャストして比較しています。不一致だったら gopter.PropResult{Status: gopter.PropFalse} として失敗した旨を返します。

NextStateFuncRunFunc を行った場合に状態がどのように変化しているべきかをテスト用に用意したオブジェクトに対して操作を記述し、その値を返します。ここでは無名関数の引数に渡される commands.State を直接操作して、そうあるべき状態に変化させます。"INC"ではカウンターとして用意した int の値に対して1を足すだけです。状態を管理しているものが構造体の場合も、その構造体にキャストしてから適切な操作をします。

同様にして DecReset についてもコマンドを定義します。

ステートフルPBTの初期設定

最後に、初期値に関する設定と、存在するすべてのコマンドを定義します。commands.ProtoCommands がそれです。(commands.ProtoCommand ではなく複数形になっていることに注意。)次のような形です。

var buggyCounterCommands = &commands.ProtoCommands{
    NewSystemUnderTestFunc: func(initialState commands.State) commands.SystemUnderTest {
        return &BuggyCounter{}
    },
    InitialStateGen: gen.Const(0),
    InitialPreConditionFunc: func(state commands.State) bool {
        return state.(int) == 0
    },
    GenCommandFunc: func(state commands.State) gopter.Gen {
        return gen.OneConstOf(GetCommand, IncCommand, DecCommand, ResetCommand)
    },
}

NewSystemUnderTestFunc はテスト対象のオブジェクトを初期化するための関数を定義するフィールドです。 InitialStateGen はテスト用に定義したオブジェクトの初期化。この例では int のまま、かつカウンターは常に初期値0となっているので gen.Const(0) となっています。 InitialPreConditionFunc はPBTを始める前にテスト対象とテスト用状態管理オブジェクトの各初期値が持っているべき状態です。

そして最後に GenCommandFunc で実行すべきコマンドを返す関数を渡します。カウンターでは状態によらずすべてのメソッドが呼べるので、特に引数の commands.State は触っていませんが、複雑な状態を管理している場合には状態に応じて呼ばれるコマンドがかわるわけです。ここでステートマシンのグラフをすべて書くことになります。

ステートフルPBTの実行

最後にステートフルPBTを実行します。自分は testing.T を使って go test コマンドで呼び出せるほうが好きなので、普通のテストと同様に xxx_test.go ファイルに書きます。ただし、PBTはファジングと同様に実行にどうしても時間がかかるので、常に起動することがないように --short フラグで起動しないようにするなど、条件付きで起動するようにしたほうが良いと思います。

func TestStatefulPBT(t *testing.T) {
    if testing.Short() {
        t.Skip("skip PBT in short mode.")
    }
    parameters := gopter.DefaultTestParameters()
    parameters.Rng.Seed(1234) // デモなので常に同じ結果になるようにシードを固定

    properties := gopter.NewProperties(parameters)
    properties.Property("buggy counter", commands.Prop(buggyCounterCommands))

    properties.TestingRun(t)
}

実行は先にも書いたように properties.Property() 関数に上で定義した commands.PropCommands を渡してあげれば終わりです。( commansd.Prop でラップしてるのは型を揃えるため)

実行

これを go test で実行してみます。

$ go test
! buggy counter: Falsified after 43 passed tests.
ARG_0: initialState=0 sequential=[INC INC INC INC DEC GET]
ARG_0_ORIGINAL (8 shrinks): initialState=0 sequential=[RESET GET GET GET
   RESET DEC DEC INC INC RESET RESET DEC INC RESET INC INC GET INC INC DEC
   DEC GET RESET INC INC DEC INC INC INC RESET RESET INC INC GET INC DEC GET
   DEC GET INC RESET INC INC]
Elapsed time: 19.201782ms
--- FAIL: TestAll (0.02s)
    properties.go:57: failed with initial seed: 1608381699594525693
FAIL
exit status 1

ここで特筆すべきは、ステートフルPBTの場合、テストを失敗させた入力値の表示として、失敗する状態まで持っていったコマンド列が表示されることです。さらに上の例を見ると、ちゃんとその結果まで shrink していることがわかります。今回の例だと3より大きい数字でデクリメントを呼んだときに2を引いてしまっているので、そこでおかしくなることが最小限のステップで再現できるコマンド列が得られています。こんな簡単な例ですら6手順必要なので、リアルワールドではとても有用であることが容易に想像できます。

ステートフルPBTのデメリット

ステートフルPBTは非常に強力なのですが、上で書いているように状態を本来の実装とは別に管理するロジックを書いたり、またコマンドの準備などが非常に複雑になりがちなので、なかなか手が出しづらい側面があります。手動で境界条件になりうるテストシナリオをすべて列挙するのは非現実的ですが、露見するバグによる障害が手動による例外的な対応で許容できる場合もあります。そのようなテスト実装コストと得られるメリットのバランスはなかなか読めないので、すべての人におすすめできるわけでもありません。個人的にはステートフルPBTはもっと事例が出てほしいなと思ってはいますが。

おわりに

急いで書いたのでサンプルの解説になってしまいましたが、少しでもこれでステートフルPBTを使う人が増えると嬉しいです。明日は@soichisumiさんです。

自作キーボードにはまっている話を2万字で説明します #自作キーボード

はじめに

こんにちは、Google Cloud Operations担当者です。Stackdriverという表記はいまは便宜上のものなので、これからは "Cloud Operations" あるいは "Cloud Ops" といった形でまとめて呼んでください。この記事は pyspa Advent Calendar の8日目の記事です。昨日は@shiumachiFreeleticsで身長が40cm伸びた話でした。

f:id:ymotongpoo:20201101201739j:plain

この写真は本文を書くときに使ったCorne Cherry v3です。今年の6月くらいからキーボードを組み立てまくっていて、知人友人にもキーボードの自作の良さを広めています。実際すでにpyspaアドベントカレンダーも2エントリが自作キーボードの話です。

自分は好きなものは話し始めると喋りすぎてしまうタイプのオタクなので、ちょっとした会話で自作キーボードについて話しはじめるとそれだけで2時間とか話してしまいかねません。したがっていつもは喋りすぎないように頑張って控えているんですが、今回は自分の思考の整理のために普段話し控えていることを書き下してみました。

いくつかの観点があるのでそれに沿って整理していこうと思います。

  1. 健康のため
  2. 楽しい

TL;DR

とりあえず自作キーボードは健康にもよくて楽しいので、自分が新しく開いたお店でキーボードキットとか買ってください。

kochikeyboard.stores.jp

長いので目次を入れました。

1. 健康のため

多くの人がオフィスで働いていたころは、IT系の職種の人はノートパソコンを持ち歩いて会議室から会議室へ、あるいは客先へ移動し、その場でノートパソコンを開いて作業をするという事が多かったのではないでしょうか。職種により自席以外での作業をする時間の長さというのはまちまちだと思いますが、自席での作業が少なくなればなるほど、キーボードを外付けして作業する人というのは減ることでしょう。したがって外付けキーボードの需要というのは日常的な行動の制限によって発生してなかったのだと思います。

しかしコロナ禍においてデスクワーク中心だった人々が突然在宅勤務を始めるようになりました。いつまで続くかわからないため、はじめはノートパソコンを1日中使って作業をしていた人も、在宅勤務の期間が延長されその勤務形態が一般化してくると、徐々に自宅のオフィス化を図る人が増えたように感じます。長時間の作業を快適にするために机、椅子、ディスプレイなどを揃え、自分のTLでも一時期毎日「my new gear....」と書かれた写真付きツイートが見られました。

机、椅子、ディスプレイに続いて私が強くおすすめしたい改善がキーボードです。すでにHHKB、Realforceといった静電容量無接点方式のキースイッチを採用した日本が誇るキーボードを購入されて使っていらっしゃる方も多いでしょう。そんな方にも私がおすすめしたいのが分離型キーボードです。市販されているキーボードは通常一体型(一枚板の形状、Conventional)でキーが数行に渡り縦方向にずれた状態で配列されています*1。これは古くはタイプライター、その後のコンピューター端末の都合に合わせた形状で、人間の動作に沿って作られたものではありません。こうしたキーボードの長時間に及ぶ使用が人体にどのような影響を与えるかに関しては、人間工学の分野で長年研究されていて、Human Factors and Ergonomics SocietyChartered Institute of Ergonomics & Human Factorsといった専門学会があり、それらの査読付き学会誌に多くの論文が掲載されています。

我々エンジニアとしては、データに基づいた先行研究はまず参照したいところです。探してみると分離型キーボードの利点を長年の多くの研究を踏まえてDevid Rampel [Rampel, 2008]が整理していました*2。詳細は論文に譲るとして、多くの実験から著者は分離型キーボードは生産性には大きく寄与しないが、その主な価値は健康状態(上肢の各筋の痛みや疲労)を改善することにあると結論付けています。またその効果は4ヶ月以上の使用でようやく観測されるともしています。最大の効果を得るためには、キーボードの傾斜や開き具合などの細かな設定はありますが、一体化キーボードよりもいわゆるエルゴノミクスキーボード、特に両手の打鍵領域が分離したものが筋骨格的に有利に働くとあります。

実際に自分が2015年からそういったキーボード(Kinesis Advantage 2→ErgoDox EZ→各種自作キーボード)を常用する生活を続けてきて感じているのが肩こりのなさです。自分が日本人の成人男性の中でも大柄な部類であることも関係するとは思いますが、やはり肩幅より狭い領域に両手を置き続けるのは無理があったのでしょう。また上記論文では触れていませんが、やはり胸が開いたため呼吸が楽になりました。そのあたりの話はかつて記事にしたので時間があればご一読ください。

ymotongpoo.hatenablog.com

一体型で左右分離になっているタイプのキーボードは市販品でもいくつかあるのですが、残念ながら打鍵領域の開きは変更できません。

そうなってくると限られた選択肢としてErgoDox EZMoonlanderのような既成品キーボードが出てくるわけですが、ここまでくると今度はキーのレイアウトが...といろいろ気になってくる点が出てきて、結果選択肢として分離型で満足の行くキーボードを手に入れようと思うと自作キーボードしかなくなってくるわけです。

というわけで、第1の理由は健康にデスクワークを続けるための道具としての条件としての自作キーボードでした。

2. 楽しい

人間は多少健康には良くなかったとしても、魅力があればそちらを選択することも多々あります。私は健康に悪いとはわかっていながらお酒を飲んでしまうタイプです。その点、自作キーボードは分離型のようなものも含めてエルゴノミックに作れるというだけではなく、その作るプロセスや使っていくプロセスにも十分楽しさがあります。「キーボード」というハードウェアの機能としての制約があるがゆえに、最適なキーボード("Endgame")を求めて多くの人が創意工夫をしています。本エントリーではそれらを思いつく限り紹介していこうかと思います。

なお記事を書いている間に次に挙げているような「キーボード温泉」を図にしてくれた方がいたので引用します。

キーボードの組み立て

キーボードキット

巷で聞く「自作キーボード」の多くは、すでに誰かが設計したキーボードの基板とそこに必要な電子部品が一通り揃えてあるキーボード組み立てキットを購入し、自分でハンダ付け作業を行って組み立てるものだと思います。ハンダ付けという作業は見聞きはしたことがあるけれど実際にやったことがないという方には少しハードルが高い行為かもしれません。また一通りハンダゴテなどの工具などを揃えないと始められないというのもハードルの一つかもしれません。

しかし実際は始めるのに最低必要な道具というのはサリチル酸さんが以前書いた記事で「必須な道具」と書いてあるものくらいでしょう。

  • はんだごて
  • はんだ
  • はんだごて台
  • ハンダ吸い取り線
  • ニッパー
  • ピンセット

salicylic-acid3.hatenablog.com

実はこれらはとりあえず揃えるだけであればたいていが100円ショップで揃えられてしまうのです!便利な時代ですね。*3

これらの道具があればキーボードキットの組み立ては基本的にはプラモデルと同じような作業だと思って差し支えないと思います。キーボード作者の方々が組み立てに必要な工程を写真付きで公開してくださっているので、それを見ながら一つ一つ手順を追って作成すればちゃんと完成します。この中で大半を占めるハンダ付け作業それ自体がまず結構面白いものなのです。*4

ハンダ付けも最初はリードやピンが部品から出ていて、基板の穴(スルーホール)にそれを挿して、仮固定が楽なものでようやくできる、という状態からはじまります。徐々に慣れてくると表面実装と呼ばれる部品を基板の表面に直接載せてハンダの接着力のみで固定するやり方に慣れ、そのうちQFPやUSB-Cのピンなども手ハンダできるようになってくるから面白いものです。

完成したものがPCにつないでデバイスとして認識され、それが普段遣いの道具になるというのは得も言われぬ喜びがあります。

手配線

はじめは基板にあるスルーホールやランドに対して設計時に決められた部品を取り付けて、それが動くだけで楽しいんですが、3年前に設計された基板とかだとLEDは当初設計にはなく、アンダーグローLEDは自分でMCU*5からビニル線などで引っ張ってきて取り付けるというようなことをする必要があります。はじめは過去にそういう実装した人の写真などを参考にしながら配線していたのですが、その作業の中でProMicroのどのピンがキースイッチに使われていて、どのピンが余っているかなどを調べることになります。そうすると今度は余ったピンでなにか別のことをしたくなってきます。はじめはLEDだけだったのが、ロータリーエンコーダーなどもつけて遊んだりと、少しずつ自由度が上がってきます。このあたりが自作キーボードならではのカスタマイズ性です。

以前はこうした作業は不格好にキーボードからビニル線などを引っ張り出して、自分で拡張部分の基板などを作ったりするしかなかったようですが、いまはロータリーエンコーダーや追加のキーであれば @e3w2qさんの作った「SU120」という基板があるので、これを利用することで拡張が容易になります。

e3w2q.github.io

そもそも基板がなくても手配線のみでキーボードを作るということも可能で@ikejiさんがそのやり方を記事にしてくれています。自分も変な形状の立体的なキーボードなどを作りたくなったらこの手法でやってみる思うけれど、まだここまでには至っていません。しかし自由度無限大なのでとても楽しそうだなと思います。

blog.ikejima.org

キーキャップ

さて、いきなり手配線でキーボードを作成するなどというハードコアな楽しみを紹介しましたが、一切キーボードを作らずに手軽にできる楽しみがキーキャップです。キーキャップはまたそれだけで奥が広く楽しみがある領域です。こちらもサリチル酸(@Salicylic_acid3)さんがキーキャップだけのエントリを書いてらっしゃるのでご参考までに。

salicylic-acid3.hatenablog.com

デザイン

まずなんといっても様々なデザインのキーキャップがあることです。にるぽ酸(@nillpo)さんが主催している「KEEB_PD」というオンラインイベントを見てみると、多くの自作キーボードユーザーが投稿した自慢のキーボード写真を見ることができます。

twitter.com

ここに掲載されているキーボードはどれも普段使っているキーボードでは見られないようなデザイン性の高いキーキャップを使っていることがわかります。これらはたいていCherry MX軸互換のキーキャップなので、いわゆるメカニカルスイッチを使っているキーボードであれば取り付けられます。

たとえばゆかりキーボードファクトリーさん、TALP KEYBOARDさん、遊舎工房さんなどでは多くの意匠性の高いキーキャップセットを販売しています。*6サイトを見ているだけで欲しくなってしまいます。また、数が出るものではないので、共同購入(=Group Buy、以下GB)で先にお金を集めてから受注生産するキーキャップも少なくありません。GBでデザイン的に優れていて人気だったけれど通常生産されない限定品のようなものは、その希少性も相まってよりキーボードを彩ってくれます。

色やデザインだけでなく、刻印の方法もダブルショット、シルクプリント、昇華印刷(dye sublimation; dye sub)、レーザー刻印などさまざまにあり、やはりこれも好き好きです。自分のお気に入りのデザインのキーキャップをつけると特別感がまたひとしおです。

形状(プロファイル)

自作キーボードを始めるまで深く意識したことがありませんでしたが、市販されているキーキャップにはいくつかの形状があります。その形状は「プロファイル」と呼ばれています。メカニカルキーボードで最もよく使われているCherry MX互換のキースイッチでは、SA、OEM、Cherry、XDA、DSAといったプロファイルがメジャーです。次の記事などで詳しく解説されています。

buildersbox.corp-sansan.com

  • SA: 背が高く上の行から下の行にかけてのくぼみ(シリンドリカル)が大きいもの。FILCOのMajetouchのキーキャップはこのプロファイルです。
  • OEM: 一般的な形状。SAより少し背が低い。SAよりもくぼみの傾斜もゆるい。
  • Cherry: 一般的な形状。OEMよりも少し背が低く、くぼみの傾斜もゆるい。
  • XDA: 背は中くらいですべてのキーの高さが同じで、各キーの真ん中が少しくぼんでいる(スフェリカル)なもの。
  • DSA: XDAよりも背が低く、それ以外はXDAと同様。

キーキャップは人間がキーボードに直接触れる場所、特に指に物理的に影響するので形状の好みは思った以上に影響します。ほんの数ミリの高さの違いでも指の大きさに対しては数パーセントに及ぶので、自分のお気に入りの形状を探すのも楽しいものです。

材質

また指が触れる、の話をするとキーキャップの材質によっても打ち心地はだいぶ異なります。ディスプレイの文字を読んでいる間なんかは、キーに指を乗せたままなので、その触り心地は思った以上に影響します。よく使われている素材はABSとPBTです。

ABSは薄く表面はなめらかなで高い打鍵音がする傾向があります。PBTは表面は少しさらっとした印象で少し低めの打鍵音がします。PBTのほうが値段が高めになる傾向があります。

私個人は圧倒的にPBTのものが好きで、キーキャップを探すときはまずPBTに絞って探しています。

3Dプリント

ここまではいわゆる通常の大量生産のキーキャップ製造方法、すなわち金型を作成し、射出形成で製造する方法によるものについて書いていましたが、そもそもキーキャップはキースイッチにある軸にはまって打ちやすくなれば何でもいいわけです。指の形状や動きに合わせてベストなものを探していくと、3Dプリンターで1つずつ作っていくという方向に行くのはごく自然な探求です。

私はそこまでまだいっていないのですが、やってみたいという気持ちは多分にあり、実際こういう先達の仕事を見ると欲しくなったりします。

make.dmm.com

Makerムーブメントにより、3Dプリンターやレーザーカッターなどの貸出やデータ入稿による作業の外注が個人でもできるようになり、こういった方向での探求がしやすくなりました。

アルチザンキーキャップ

自分が使っている40%キーボードだとめったに使わないキーというのは存在しないわけですが、テンキーレスキーボードくらいだと、例えばファンクションキーやエスケープキーなど、普段あまり使わないキーというのが存在します。そういったキーがただ存在してるだけでは面白みがないので、意匠性に凝ったキーキャップをアクセントとしてつけたくなります。

アルチザンキーキャップというカテゴリは多くのキーキャップ作家さんが手作業で様々に凝った一点物のキーキャップを作っています。たとえば遊舎工房さんや当店Kochi Keyboardでも販売されています。

yushakobo.jp

kochikeyboard.stores.jp

他にもBOOTHで出店されている方も多く、入荷数も手作業故に限られているため人気なアルチザンキーキャップはすぐに売り切れてしまいます。

たとえばこのBOXXX KEYCAPさん作のツナは「マツコの知らない世界」でも紹介されていました。こういうキーキャップをつけると、より一層キーボードに愛着が湧くというものです。

Gopherキーキャップは本当にかわいいですよね!(人気すぎて毎回入荷後5分で売り切れてしまう)

キースイッチ

「キーボードにこだわる」というと、一歩進んでよく論じられるのはキースイッチです。すこしキーボードにこだわりがある人であれば「すっと押せる赤軸が好き」「自分は青軸の音が好み」などCherry社製スイッチの軸色で好みを表すこともあると思いますが、自作キーボードを始めて実に奥深い領域であることを知りました。

特性

カニカルキースイッチは簡単に言えば軸がバネ(スプリング)によって押し上げられた状態になっていて、その軸を指で押し下げることで金属のスイッチが接触し、電流が流れることでスイッチがオンになったと反応する仕組みです。このバネとその周りの機構によって、大きく分けて「タクタイル」「リニア」「クリッキー」と呼ばれる特性が得られます。これはどのような押し心地がするか、という区分ですが、私が説明すると次のような感じになります。

  • タクタイル: 押下時にはじめ少し強めの負荷(クリック感)があり、ある程度押すとスッと押し込める。スイッチ自体の音は軸(ステム)、ハウジング、スプリングの接触によって起こる音のみ。
  • リニア: 負荷が直線的に掛かりクリック感はない。音に関してはタクタイルと同様。
  • クリッキー: 名前の通りクリック感が強く、音も「カチッ」とした押下音を作るためにわざわざ機構を追加している。(クリックジャケット、クリックバーなど)

こうした特性は各キースイッチメーカーがこれらの種類とともに次のような負荷の特性グラフとともに公開しています。(次の図はロジクールのサイトより引用)

f:id:ymotongpoo:20201206210200p:plain

これ以外にも静音性や押下圧(スプリングの強度)、作用点までの距離(反応までに必要な押し込みの量)など様々な属性があるので、それらを見ながら自分の好みのスイッチを探していくのは非常に楽しいものです。また自作キーボードならではなのが、キーそれぞれでスイッチを変えられる点です。小指は力が弱いので他のキーよりも軽めのスイッチにしたり、モディファイアキーは押し間違えたときにわかるようにクリッキーなスイッチにしたり、などといったカスタマイズができます。

データシートには載っていないような個々の種類における差異など踏まえるととてもこの記事の1セクションだけで収まるものではないので、気になった方は他の方の記事を是非見てみてください!(サリチル酸さんの記事は実体験の感想が書いてあって面白いです)

プロファイル

カニカルスイッチというといわゆる「Cherry MX互換」のキースイッチが想像されますが、実は他のキースイッチもあります。例えば私が個人的に好きで推しているキースイッチであるKailh社のChoc v1と呼ばれるキースイッチはCherry MXの半分程度の高さのスイッチです。

これを使ったキーボードは非常に薄くできるので、たとえばAppleの昔のMagic Keyboardが好きだったような人はこのスイッチが合うかもしれません。他にも同様に背が低いけれどCherry MX互換スイッチ用のキーキャップが使えるKailh Choc v2や、完全にCherry MX互換スイッチとピンの位置やキーキャップをはめる軸の形が同じだけど背だけ低いOutemu社のLow Profileスイッチなどがあります。また昔懐かしいALPS社のスイッチの互換スイッチなどもあります。

Kailh Choc v1は自作キーボード以外だとなかなか使えないので、こうしたプロファイルを使えるのも楽しみの一つです。

ルブ

いくつかの種類のキースイッチを使っていろいと試していると、キーの音が気に食わなくなってくるかもしれません。キースイッチは、軸(ステム)、ハウジング(上下の入れ物)、スプリング、板バネ(接点用の金属)などの部品によって構成されます。普通のスイッチは購入時はこれらがハウジングによって所定の位置に納められているだけで、動作点に特別な処置がされていません。しかし例えば自転車の部品などを想像すると分かりやすいのですが、通常こういった連続稼働をする機械には、接点や動作箇所にはグリスやオイルと言った潤滑剤が塗られていて、接触が滑らかになるようにしています。同様のことを自分で行うのがルブです。

中の部品に潤滑剤を塗る、と言っても塗るものや場所を間違えるとキースイッチ本来の特性が失われたり、下手をすると処置を施す前のほうが快適だったりします。適切な潤滑剤を適切な量、適切な箇所に塗る必要がありますが、すでに先達が多くの知見を残してくださっています。

keys.recompile.net

たとえば上のrecompile keysさんで公開されている記事などは非常に参考になりました。こうした記事を見ながら自分でルブをしてみると、確かに実感できる差異で音や感触が改善がありました。こうした手間は時間もかかりますし面倒に感じることもありますが、確実に使用感として返ってくるだけでなく、手間をかけた愛着もあり余計に作ったキーボードを好きになれる作業かなと思います。

また高級キースイッチはこうしたルブ作業を行った状態で販売をしていたりします。高級キースイッチを一度使うと、市販のメカニカルキーボードの打鍵感には満足できなくなってしまうかもしれません...

カスタマイズ

ルブをするという作業を通じてはじめてキースイッチを分解する人も多いと思います。私がそうでした。そして思った以上に簡単に分解できることがわかります。分解できて作りも単純であるとわかれば、カスタマイズしたくなります。先ほども書いたように、キースイッチはステム、ハウジング、スプリングが大きな部品です。これらを複数の種類のキースイッチで入れ替えてオリジナルのスイッチ(キメラスイッチ)を作るという人もいます。またスプリング、ステム、ハウジングをそれぞれバラで買ってきて作るということもできます。

ステムの太さやハウジングの形状が微妙に違うので、それをうまく組み合わせることでステムとハウジングの穴の隙間が少なくなり押下時のブレがなくなると言った作用がある、といった利点からこういったことをするようです。(自分はやっていない)もはやここまで来るとスプリングを手で巻くといったこともしている人がいそうです。

静電容量スイッチ

HHKBやRealforceといった東プレ製の静電容量無接点方式のキースイッチを使用している人は、その感触の良さを利点の一つとして挙げています。これは静電容量無接点方式だから感触がいいわけではなく、スイッチとそこに使用しているドーム型のラバーと台形のスプリングの組み合わせが良いものだから感触が良いわけです。

静電容量無接点スイッチを自作キーボードで使おうという試みはすでにされている方もいて、いま研究のまっただ中です。(銀鮭さんせきごんさんの本などで解説があります)

ginjake.booth.pm

nogikes.booth.pm

さらにそれをサポートするかのようにビットトレードワンさんからも静電容量無接点方式のキースイッチを自作するキットが販売されはじめました。

bit-trade-one.co.jp

静電容量方式や光学など、自作キーボードで使われていた通常のメカニカルキースイッチとは異なるスイッチは基板の設計からすべて変更する必要があるので難点もありますが、新たなステージでもあるので自分もぜひ試してみたいと思っています!

キーマップ

自分は複数のOSを使っていて、開発用のメインマシンはLinux、サブマシンにWindowsmacOSのマシンがそれぞれあります。普段遣いのLinuxマシンを使うときはショートカットを使うのだけれども、このショートカットというのはときに人間の手の構造をまったく無視していて「こんな同時押しできないでしょ!」とつっこみたくなるようなものもあります。

自作キーボードでデファクトとして使われているQMK Firmwareというファームウェアでは自由にキーマップを変更できるため、macOSでKarabiner-Elementsなどで行っていたような処理をファームウェアとして焼いてしまって、どのOSでも自分の好みのキーマップやショートカットを設定できます。これまで書いてきたような複雑な機械的なカスタマイズではなくても、自分好みのキーマップを探すだけでも十分奥深い領域になっていて、これもまた楽しみの一つになっています。

独自配列

はじめて自作キーボードを作るときは既存のキーボードと同じぐらいの数のキーがあるキーボードを作るので、はじめはモディファイアの位置の変更などから始めると思います。(自分の場合は自作ではないですがErgoDox EZでそうした変更をしていました)その後慣れてきて40%キーボードなどを使い始めたときに、数字の行が無いため必要に駆られて記号キーを複数のレイヤー*7に入れるようになり、複数のレイヤーを扱うことに慣れます。そして次第にQWERTY配列とは異なるキーマップを使いたくなってくるわけです。

QWERTY配列と異なるキーマップというと有名なところではDvorak配列がありますが、他にもColemak配列、Workman配列といった配列があります。いま私が練習しているのはゆかりキーボードファクトリーゆかりさんが開発したEucalyn配列です。

eucalyn.hatenadiary.jp

この配列は3年前に遊舎工房のファクトリーヘッドであるないんさんが他の配列と比較し、データ上でも効率がいい配列と評価されています。

yushakobo.jp

こうした配列を気軽に試せるのが自作キーボードの良さでしょう。よく「こういうカスタマイズされたキーボードに慣れてしまうと他のキーボードで打てなくなりそう」と言われるのですが、不思議なことにノートPC付属の通常のQWERTY配列のキーボードで打つとちゃんと打てるのです。物理的にキーの数も配列も異なるキーボード間での移動のほうが脳の切り替えが楽な印象があります。

ファームウェアによる高度な設定

ファームウェアはキーレイアウトを変えるだけではありません。たとえばマクロ的なこともできるので、Vimであるような複数のキー入力を記録して再生するといったこともできますし、家でしか使わないキーボードであればおすすめはしませんがパスワードの入力を1キーで行うといったこともできます。またキーをマウスカーソルの移動やクリックに割り当てたりもできます。

さらにキーボードにつけたLEDのライティングのパターンの変更なんかもファームウェアで行います。たとえばこういう光らせ方もできるわけです。

自作キーボードを始める前は「キーボードとか光らなくていいでしょ....」って思ってたんですが、いまは面白いから光らせてます!ただ光らせるだけでなく、QMK FirmwareはHIDインターフェースを使ってホストとやり取りする機構もあるので、これを使ってCIやテストがコケたらキーボードのLEDを赤く光らせるといったこともできるわけです。

docs.qmk.fm

たとえば@yoichiroさんGoogleアシスタントと連携させてキーボードを光らせるといった遊びもしていました。

www.youtube.com

他にもブザーをつけたりして音声フィードバックもできますし、単純にキーボードとしてだけでなく、視覚的なインターフェースとして利用できるところも自作キーボードの面白いところです。

ケーブル

アルチザンケーブル

自作キーボードではPCをつなぐケーブルはUSBケーブルが使われ、分割キーボードの左右をつなぐケーブルには3極/4極のオーディオケーブルが利用されます。通常こうしたケーブルは家電量販店等で入手できる普通のケーブルを利用することが多いでしょう。しかしケーブルはキーキャップに次いで外からよく見える部分です。意匠にこだわり始めるとケーブルを少しでも見栄えよくしたいという気持ちが出てくるのでしょう。

そこでアルチザンケーブルです。EXME CABLESさんやnokke/cablesさんといった専門店もありますし、遊舎工房でもキットが販売されています。

exmecables.com www.nokke-labora.com

ケーブルの自作は何気にハンダ付けが結構シビアだったりするので自分はまだ手が出せてませんが、オリジナルのUSBケーブルとか作れたらちょっとおもしろそうだなとは思っています。

無線化

ケーブルではないですが、PCとの接続という観点で言うとキーボードの無線化も重要なトピックです。自分はSatTさん作のCaravelle BLEというキーボードキットを購入して分離型無線キーボードを使い始めました。

booth.pm

やはりケーブルがないと机上がすっきりします。通常使うPCが1台であれば無線型のキーボードをおすすめしますし、Caravelle BLEは40%キーボードとしてもケース込みで非常によく設計されているので自分個人としてもおすすめです。そして、ProMicroが使われているキーボードをあとから無線化するキットとしてせきごんさんの作られたBLE Mirco Pro(BMP)は定番になっています。

sekigon-gonnoc.github.io

他にもESP32を使ったキーボードを作る試みなどがあり、これから無線キーボードの領域は非常に楽しみです。またBMPを使う上でボタン電池がよく使われるのですが、購入が面倒であったり再利用できない点が難点でした。しかしいませきごんさんが単4電池を昇圧して使うための基板も用意してくれたりと、このあたりも今後やりやすくなるのかなと期待しています。

こうしたおもしろ電子工作への足がかりになりそうな要素があるのも自作キーボードの楽しみです。

基板設計

電子工作への足がかりといえば基板設計です。「自作キーボード」はまずキーボードキットの組み立てから入ると思いますが、やはりゆくゆくは自分で設計したキーボードを使いたいものです。基板設計はまさにその醍醐味と言えると思います。*8

キーボードのレイアウトを自分好みにするためには自分でキーボードを設計するしかありません。もちろん先に書いたように手配線で作るという方法もありますが、壊れてしまったらそれっきり。同じキーボードは作れません。一度基板に起こしてしまえばデータが有効な限り何度でも作れます。また他の人に頒布することも可能になります!

ケース

自作キーボードでよくある設計は部品を実装する基板を上下のプレートで挟んで固定するサンドイッチマウントといった方法です。この方法が採られている理由は

  • ケースの3Dモデリングをしなくてよい
  • プレートだけなのでコストが安くなる

などがあると思います。しかし残念ながらメリットの裏にはデメリットもあります。よくあるアクリル板やFR4のプレートで組まれたキーボードはまずそもそも重量がないため安定感に欠けます。またプレートの材質やプレートを固定する位置の都合上、打鍵時の音もよくありません。トップマウントやガスケットマウントと呼ばれるプレートマウント方式では打鍵時の音がよくなり、またケースを作った場合にはそこにウェイトを仕込めるので安定化が図れます。(次の動画の打鍵音はキースイッチによるものだけではありません)

www.youtube.com

www.youtube.com

しかしそうしたケースの設計は3Dモデリングのスキルが必要となります。また製造も3Dプリンタで作る場合には精度や剛性に難があり、切削や射出形成のいずれも少数ではコストが高く、大量生産をしても単価を抑えるには限度があります。趣味で小ロットで生産しか行わないのではやはり限界があるでしょう。そんな中でもやはり突き抜けている設計はコストが高くても受け入れられています。

ai03さんのVegaはアルミ切削ケース、アルミ/ポリカーボネイトプレート、二重のフォーム、PVDコーティングされたウェイトスチールと、おおよそ自作キーボードで最先端かつ最高級と思われる構成を素晴らしい3Dモデリングと基板設計をもって作られたキーボードです。*9

自分のお店でも販売させてもらっているCorneシリーズの作者の@foostanさんがちょうど数日前にケース込みで新しいキーボードを設計した話を書いています。

fstn.hateblo.jp

そこまでとはいかずとも、やはりこうした自作ケースの可能性を見せられると、自分もいつかはケースを作ってみたいなという気持ちになります。

ポインティングデバイス

もう何を書いてきたか覚えていないんですが、最後にポインティングデバイスについて。自作「キーボード」なんですが、やはりキーボード好きの中には一定層ThinkPadのようにポインティングデバイスを内蔵したキーボードを作りたいという人がいます。実際自分もその一人です。そういう人の中にはポインティングデバイスを内蔵したキーボードを作っている人もいて、そのためのモジュールも販売されています。

akiba-pc.watch.impress.co.jp

yfuku.com

ポインティングデバイスを扱うための設定もQMK Firmwareにはあり、実際に自分も適当なジョイスティックを使って実験的にポインティングデバイスを使ってみたこともあるので、これをどうやってうまくキーボードに組み込むかが課題だなとおもっています。これがうまく行けば普段使っているトラックボールを使わずに済むので、手の移動が減り、より快適なタイピング環境が実現されるはずで、いまからワクワクが止まりません。

おすすめのサイトなど

コミュニティ

自作キーボードコミュニティは普段のやり取りをDiscordでしていることが多いのですが、日本だとSelf-Made Keyboards in Japan (SMKIJ)というDiscordサーバーが有名です。

biacco42.hatenablog.com

自分もここの話題を見ながら多くのことを学ばせてもらいました。これから少しでも還元できたらいいなと思っています。

とにかくキーボードの写真を見たい

上のSMKIJのDiscordサーバーにある #photo-share チャンネル、および #exhibition-room チャンネルなんかに多くの写真が流れてきます。また上でも書きましたがにるぽ酸さんが主催されてる#KEEB_PDというオンラインキーボードフォトコンテストはきれいな写真ばかりでどれも欲しくなるものばかりが流れてきます。

海外のサイトなどで多くの写真が公開されているので、自分はそういったサイトも見に行くことが多いです。まずは総本山といってもいいGeekHackです。

geekhack.org

ここは世界中の自作キーボードファンが集まっていて、グローバルなGBやそのためのInterest Checkなどもこのサイトで行われています。またRedditのr/MechanicalKeyboardにも多くの写真が上がってきます。

www.reddit.com

YouTubeチャンネル

こうした自作キーボードの楽しみはやはり動画で見たほうが分かりやすいのでおすすめのYouTubeチャンネルを紹介します。はじめは週間キーボードニュースです。

www.youtube.com

ホストのぺかそさんとびあっこさんが毎週自作キーボード関係の最新ニュースをお届けしてくれるチャンネルです。毎週日曜日の夜10時からライブ配信をされていてアーカイブも残っています。最新動向を知りたい方におすすめです。

次におすすめはDaihuku Keyboardです。

www.youtube.com

Daihukuさんが様々な自作キーボードを紹介してくださっていて、写真ではわかりにくい部分も含めてキーボードの雰囲気がわかります。また自作してみた動画は組み立ての様子がわかるので、自分で作ってみる予定があるキーボードの作成動画はおすすめです。

おわりに

長々と書いてきましたが、なによりも「自分が作ったものがきちんと動作して使えている」という体験はなによりも楽しいものです。いきなりここに書かれているようなものすべてに取り組むと圧倒されてしまいますが、どれか一つの領域だけでも十分に楽しい趣味であることが少しでもわかっていただけたら嬉しいです。キーボードキットを使って作るだけでも十分に実用的で面白く、かつ上を見ればいくらでもできる、そんな世界です。この記事がきっかけで自作キーボードの世界に触れる人が少しでも増えたら嬉しいです。その際にはぜひ自分のお店で買ってもらえたらもっと嬉しいです。

kochikeyboard.stores.jp

本エントリーはCorne Chocolate v2Corne Cherry v3で書かれました。明日はインターネットコンテンツの @tokoroten です。

その他本文に入れなかったリンク

*1:キーが横方向に揃って配列され、縦方向に少し斜めにずれているこの配列はRow Staggeredと呼びます。

*2:Rempel, David. (2008). The Split Keyboard: An Ergonomics Success Story. Human factors. 50. 385-92. 10.1518/001872008X312215.

*3:実際はハンダゴテは少し高くても白光などが出している温度調整機能があるものを購入することをおすすめします。

*4:Corne ChocolateのハンダのジャンプによるSK6812MINIの取り付けははじめは本当に地獄かと思いましたが

*5:実際にはそのブレイクアウト基板のピンなのですが、ここではまとめてMCUと呼んでしまいます

*6:ところで普段キーキャップを買うことがなければ意外に思うかもしれませんが、意外と値段は高いです。キーキャップは種類によっては行ごとに形状が違い、そのうえ刻印があるものはキーごとにデザインがことなる(=刻印する文字が違う)ことや、材料によっては複数回の射出形成が必要だったりと、作業的にも手間が多く、おまけに数量が出ないこともあって、1セットあたりの単価は思っているよりは上になります。

*7:通常のキーボードで言うと異なるキーマップにするシフトが複数あるような状態。

*8:自分もいままさに設計を行いはじめました

*9:1000台のIn Stock販売を行うということで、世界中にファンがいるとは言え、リスクを背負っての販売という部分も驚嘆ですし、それが完売した上で追加のGBを行っている最中ということですから畏敬の念しかありません。

「サクッとわかるビジネス教養 地政学」読了

はじめに

こんにちは、Google Cloud Operations担当者です。最近はGoogle Cloud Profilerのワークショップを行っているので、アプリケーションのパフォーマンス改善に課題を感じている企業の方、Goのpprofをより積極的に使っていきたいという方はぜひお気軽にTwitterなどでご連絡ください。

さて、図書館に行ったらたまたま新刊で次の本が置いてあったので、軽く読めそうということで読んでみました。

政治・経済の「物理装置」としての地政学

実は地政学地政学としてきちんと情報を得たことはなく、高校までに習った地理の知識やその後の国際ニュースの情報などから、だいたいの雰囲気で断片的に知っていたという状態でした。いままで現代史を捉えるときに、その歴史的背景や周辺地域の資源ぐらいしか気にしていなかったのですが、それだけでは理解しづらい部分というのがありました。しかし、あらためて本書で触りだけでも地政学の概要を知ると、各国の地政学における特徴を理解するとともにその戦略的な観点が見えやすくなり、実際にいま現在起きているナゴルノ・カラバフ紛争やシリア内戦などへの理解がより深まりました。

本書の冒頭にも記載がありますが、現代起きている様々な事象をドラマの最新話と捉えるのであれば、地政学や地理はその舞台、そして歴史が過去回ということになります。自分は中高のときに地理が好きだったのですが、それは特定の視点からの地理でしかなく、たとえばこの国は農産が盛んであの国は鉄鋼業が盛んだとかいったものや、この国は輸出国だとか、あくまで産業や気候の状態を「覚える」だけのもので、政治的な戦略と結びつかない形での理解でした。しかしながら長年経ってから地政学と結びつくとさまざまな理解が深まり、なんでこれをいままで知らなかったのだろうと思うくらいです。

本書の構成

本書は構成として「日本」「大国」「大国に影響受ける小国の集まり」という3つの観点から構成されています。

  • ​Chapter1 基本的な6つの概念
  • Chapter2 日本の地政学
  • Chapter3 アメリカ・ロシア・中国の地政学
  • Chapter4 アジア・中東・ヨーロッパの地政学

第1章で地政学の基本となる概念を先に説明してくれるので、その後の章で各国がどういう特徴があるかを説明されてもわかりやすく、まずこの章を読むだけでも地理的な知識を多く持っている人はすでに大枠は捉えられたと言っても過言ではないと思います。

第2章はまさに自分の身の回りで起きている様々な出来事、たとえば北方領土尖閣諸島対馬列島などの問題における地政学の観点からの解説や嘉手納と横須賀にある米軍基地の地政学上の意味など、その文脈が深く理解できるものでした。

第3章は国際政治を大きく動かす大国であるアメリカ、ロシア、中国に関する地政学的観点からの特徴や、そこから見えてくる各種戦略の解説は多くの現代史の理解を深めてくれるものでした。

第4章はアメリカ、中国、ロシアと友好関係を築いたり、敵対関係にあるアジア、中東、ヨーロッパ諸国の地政学の観点からの立ち振舞を解説。さすがにここは単純に地政学だけでの理解は難しく、補助的に解説を補強するための歴史や文化の解説が入りますが、地政学を軸に他の観点の知識を補強することで、以前よりも整理した形で現状を把握できるようになった感触があります。

感想

本書は2020年6月に発刊されたとあって、最新時事も時折入っており、今軽く地政学について学ぶには非常に良い本だと思いました。実際、発売3ヶ月で10万部発行するなど売れ行きも好調のようです。

本書をきっかけにしてより詳細に地政学を学んでいきたいと思えたので、自分と同じく過去にまったく学んだことがない人にはおすすめできる本だと思いました。あえて本書で残念だったところを挙げるとすれば、本書はどうしても北半球だけの内容になっていたところです。今後多くの天然資源があるアフリカ、オーストラリア、南アメリカに関する地政学的な解説も読みたいなと思いました。

参照

本書の監修の奥山さんのブログ。こちらも面白いです。

geopoli.exblog.jp

外務省のサイトに多くの解説記事があるので、気になった国際政治関連ニュースはたまにここで見てます。

www.mofa.go.jp

qmkコマンドでkeymap.cからキーマップの図を生成する

はじめに

こんにちは、Google Cloud Operations担当者です。最近のCloud Ops関連のリリースではCloud ProfilerのHistory Viewがお気に入りです。

最近は自作キーボードのパーツショップの開店に向けて仕入れなどをほそぼそと行っています。海外からの仕入れはいろいろと難しいことがたくさんある!今月末には開店したいなと思います。

それとは別に自作キーボードエンジョイ勢として、新しいキーボードを組み立てたり、キーマップの変更を楽しんだりしています。

キーマップの作成は普段は直接エディターで keymap.c を編集しているんですが、大胆に変更を加えたあとはキーマップを覚えきれておらず、いちいち keymap.c を確認しにいっていました。しかしそれが非常に面倒だと思っていたところ、こちらのPull Requestがあったので、早くmasterに入らないかなと思っていたところ、ついに取り込まれたので早速試してみました。

qmk c2json コマンド

github.com

このPull Reqeustによって qmk_firmware に取り込まれているキーボードの標準的なキーマップ(コンボやマクロを多用していないようなもの)の keymap.cQMK Configuratorで使用できる keymap.json に変換できるようになりました。まだPyPIでダウンロードできる qmk コマンドには取り込まれていないので、本記事執筆時のmasterのHEAD(bc79e51)で試してみます。

$ cd ${QMK_FIRMWARE_ROOT}
$ python -m venv .venv
$ .venv/bin/pip install -r requirements.txt
$ .venv/bin/python ./bin/qmk c2json -o keymap.json -km ymotongpoo -kb crkbd/rev1 keyboards/crkbd/keymaps/ymotongpoo/keymap.c
Ψ Wrote keymap to /home/ymotongpoo/personal/qmk_firmware/keymap.json

venvのくだりは個人の趣味でOS直に入っているPythonの環境を汚したくないだけなので、気にしない人はこのあたり無視していきなり pip install して大丈夫です。ここで生成した keymap.json を QMK Configurator に読み込ませてみると表示されました!これは助かる!

f:id:ymotongpoo:20201007122030p:plain

これをPDFにするなり印刷するなりして見えるところに置いておけばいつでもキーマップを確認できますね。

f:id:ymotongpoo:20201007121613p:plain

参照

config.qmk.fm