たのしい人生

ヴァイオレット・エヴァーガーデン雑感

ヴァイオレット・エヴァーガーデン、1 話を観ました。

いろいろ喋りたくなるオタク好みな作品だなーと思った。喋りたいことが多いので列挙します。

テーマがテーマだけにキーボード界隈で話題になっていた。

けれど 1 話の段階ではほとんどタイプライター出てこなくて残念。ただ、最後の方に出てきたタイプライターの描写、動きは最小限だったけど(まじめにやると作画コストが高すぎるよね)丁寧に描かれそうで期待は持てる。音はなんかそれこそキーボードっぽくない?実家にタイプライターあったけどもっとガシャガシャした重い音がする気がする。

試しに Ergo42 黒軸 PBT キーキャップで録音録画したらおもったよりそれっぽくなった。

作画

神作画みたいなツイートとかあったけど、結構省力作画というかバランス取ってる感はある。気合入っているところは入ってるけど、正直動きとしては息を呑むようなシーンはあまりなかったかなぁ。

全体的に動画の割り方もかなり離散的というかタイミングがフラットなのか、あまりドラスティックに動く感じではない。

ただ手の作画だけは異常なこだわりを感じる。もうこの画とタイプライターというテーマだけでいける。

あと、一部シーンでは髪の毛の動画が妙に細かったり、ある印象的なシーンにたいする細部へのこだわりみたいなものは随所に感じる。

美術

どちらかというと背景美術にはかなりこだわりを感じる。

影の出方、色の付け方がかなり特徴的で、リムライト的というか影色も特徴的で GI ぽさともまた違う画としてのおもしろさがある。

タイムラプス

日常とも共通するけど、サチュレーションかけたような写実的な固定カメラでのタイムラプス京アニ好きなのかな。朝ガス灯を消しに来る描写が入ってるのがよかった。

加持リョウジ

みたまんま

ヴァイオレットの人格

ヴァイオレットの人格が不安定すぎて、そういう状況・設定だしなぁうーん、と思っていたけれど、結構最後の方でいい感じにストーリーに回収されていって、やりすぎなぐらいがいいバランスだったのかもしれない。ヴァイオレットの今後が気になる。

音楽

音楽は派手さはないけどしっかりシーンに合わせて作ってあって贅沢さがある。オケの収録はスタジオ感強くてちょっとフラットな印象なのが惜しい。けどファゴットとか目立ってたりしてちょっとたのしい。

とりあえず、先が気になるので今期楽しみ。

Meishi keyboard 組み立て方ガイド

※現在 GCC 8 系でメモリマップの構築に不具合があるようで、Pro Micro への書き込みに失敗するようです。その場合は GCC 8 系をアンインストールして GCC 7 系をインストールしてください。 (qmk_install.sh 等では対応済みの様子ですが念の為掲載)

Meishi - The micro macro keyboard をご購入、もしくはリポジトリから製造いただきありがとうございます。この記事では、Meishi keyboard の組み立て方を簡単に紹介します。

meishi2 ができました。meishi2 のビルドガイドはこちら

必要なパーツ

f:id:biacco42:20180121224357j:plain

項目 数量
Meishi PCB 1
Pro Micro 1
キースイッチ (Cherry MX 互換 / Kailh Low Profile) 4
キーキャップ 4
ダイオード(1N4148) 4
リセット用タクトスイッチ(5 mm ピッチ 2 本足) 1
クッションラバーシール 4

※クッションラバーシールは必須ではありませんがあると実用的です。遊舎工房のキットには付属していませんが、Amazon 等で簡単に購入できますのでお試しください。

(オプション) 組み立てに必要・あると便利な道具

白光 ダイヤル式温度制御はんだこて FX600

白光 ダイヤル式温度制御はんだこて FX600

温度調節機能が便利(ない安物は温度が高すぎてはんだ付けが難しいし基板焼いちゃいやすい)。加温も早くてよいです。

白光(HAKKO) こて台 633-01

白光(HAKKO) こて台 633-01

コテ台も安いのもあるんだけど、熱いものを扱うのでちゃんと固定できる・保護できるものがおすすめ。これはコテ先クリーナーもついていて、スポンジに水をつけるタイプと比べてもめちゃめちゃ扱いやすいので総合的にお得だと思います。

goot はんだ吸取り線 CP-3015

goot はんだ吸取り線 CP-3015

はんだ吸取り器があったほうがよい場合も多いんだけれど、自作キーボード、多分そんなにはんだをミスったりするような複雑な部分もないし、とりあえずはこれだけあれば十分。

バイスの余った脚を切るのに必要。

これぐらいあればこのキーボードを作る分には十分だと思います。

組み立て

単純で、基本すべてはんだ付けしてキーキャップ・脚シールをつけるだけです。ただし、次の 2 点に注意する点があります。

  • ダイオードの向き
  • Pro Micro の固定面・固定方向
  • キースイッチの固定

ダイオードの向き

ダイオードという部品は基本的には一方向にだけ電流を流す整流用に使われます。なので、どちらに電流を流すかという 向き の概念があります。この向きを間違えると正しく動作しません。

f:id:biacco42:20180121235555j:plain

写真のダイオードの左側、黒い線が入っている側が カソード、逆に入っていない側が アノード といい、アノード側からカソード側に向けて電流が流れます。

f:id:biacco42:20180121235845j:plain

キーボードに固定する際には、この黒線の入ったカソード側を矢印の先の線のある側、四角いパッド側にしてはんだ付けしてください。

Pro Micro の固定方向

Pro Micro には裏表があり、また Meishi は決まった面に Pro Micro を固定するように設計されているため、Pro Micro の固定方向に気をつける必要があります

f:id:biacco42:20180122000446j:plain

写真の ロゴマークがある面 を上にし、Pro Micro を写真の通り 部品実装された面を上 にしてはんだ付けします。

Pro Micro のはんだ付けができたら、不要な余った脚の部分はニッパーで切ってしまってください。

キースイッチの固定

この基板は Cherry MX / Kailh Low Profile 両対応仕様です。3 pin 仕様のキースイッチ (固定用の脚が出ていないもの) だと多少の遊びがあり斜めにキーを固定できてしまいます。そのため、はんだ付けする際には、セロハンテープ等で向きを固定してはんだ付けすることをおすすめします。

完成状態

f:id:biacco42:20180122002337j:plain 表面

f:id:biacco42:20180122002355j:plain 裏面

ファームウェア書き込み

組み立てが完了したらファームウェアをビルドして書き込みます。Meishi keyboard では QMK Firmware が利用できます。 現在私の QMK Firmware fork リポジトリの meishi ブランチ に実装があります。 本家 QMK にマージされました🎉

ここでは詳細は省きつつ、ファームウェアをビルドしてインストールする手順と、キーマップの変更方法を「黒い画面」を使わない方法と、CUI で行う方法の 2 つで簡単に紹介します。

「黒い画面」を使わずにビルド・書き込み

なんと 2019 年にもなると、黒い画面を使わなくてもファームウェアをビルド・書き込みできるようになりました🎉

手順が、以下の動画で紹介されているので参考にしてみてください。動画中で Ergo42 としているところを meishi に読み替えるだけでオッケー (なはず) です。

また、サリチル酸さんの入門記事もまとまっていておすすめ です。


基礎からわかる!自キ入門講座 第12回「ファームウェアのカスタマイズ」

CUI でビルド・書き込み

QMK firmware documentation でデフォルトで紹介されている方法はこちらになります。CUI に慣れている人は、マクロ機能等自由な拡張ができる他、内部で何が起こっているかわかりやすくなるので、やってみるのも一興です。

ファームウェアの実装とビルドの詳細については QMK firmware documentation のドキュメントを参照してください。また、Windows はいろいろと差分が多いので、可能なら VirtualBox 等を用いて Linux 環境を用意できるとよいです。 最近は Windows 環境でのビルド・書き込み知見も溜まってきたため、公式推奨の msys2 による環境構築がよさそうです。

環境構築

Git

まず Git が必要です。Windows / Mac / Linux 環境でそれぞれにインストール方法が異なるため、それぞれのプラットフォームの Git をインストールしてください。

Mac でかつ brew がインストールされていれば (brew についてはここでは説明しません)

$ brew install git

DebianLinux であれば

$ sudo apt install git

等でインストールできます。とりあえずファームウェアのビルドの目的だけであればこれで大丈夫です。

Git が準備できたら、ソースをダウンロードします。

ソースコードをダウンロードしたいディレクトリに移動して

$ git clone https://github.com/qmk/qmk_firmware.git

ソースコードを取得できます。

Build 環境

Mac / Linux の場合

QMK のプロジェクトルート配下の util/qmk_install.sh を実行することで、ビルドに必要な依存が解決されます。

$ ./util/qmk_install.sh

Linux の場合だと特権を要求されるので、

$ sudo ./util/qmk_install.sh

としてください。

Windows の場合

すいません。未検証のため、こちらの Let's split の Windows 向けビルド・書き込みドキュメント を参照してください。 こちらの MarchRaBBiT さんの Windows 向け環境構築ガイド を参照して msys2 での環境構築をしてください。

ファームウェアのビルドと書き込み

組み立てた Meishi キーボードを USB ケーブルで PC に接続しておいてください。

ビルド環境が構築できたら、ファームウェアをビルドします。

$ make meishi:default:avrdude

でビルドとインストールをいっぺんにできます。途中リセットしろよという旨のメッセージが出るので、そこでリセットボタンを 1 回または 2 回連続で押します(ブートローダーによって挙動が異なるようです)。リセットを検出すると自動的に書き込みが始まります。

Linux 環境の場合は書き込みに特権が必要かもしれないので、権限不足で書き込めなかった場合は

$ sudo make meishi:default:avrdude

としてください。

動作の確認

正常にファームウェアが書き込めたら、キーボードとして認識されて動作するはずです。default キーマップでは左から順に Ctrl-z Ctrl-x Ctrl-c Ctrl-v の配置になっています。動作が確認できたら Meishi キーボードの完成です!お疲れ様でした。コピペがはかどりますね。

ファームウェアの改造

以上の工程でキーボードは完成しましたが、せっかくの自作キーボードですからコピペ以外にも使えるようにしたくなります。そのためにはファームウェアの改造が必要になります。その方法を簡単に紹介します。

Meishi キーボードのキーマップを変更するには、キーマップが記述されている <QMK firmware root>/keyboards/meishi/keymaps/default/keymap.c を編集します。また、新たに名前をつけてキーマップを作成したい場合は default ディレクトリをコピーして適当に名前を変えて keymap.c を編集してください。その際ビルドコマンドは

$ make meishi:<your keymap directory name>

になります。

keymap.c で実際にキーマップが定義されているのは

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
[0] = KEYMAP( /* Base */
  LCTL(KC_Z),  LCTL(KC_X),  LCTL(KC_C), LCTL(KC_V) \
),
};

の部分、特に LCTL(KC_Z), LCTL(KC_X), LCTL(KC_C), LCTL(KC_V) の部分になります。これが左から順番にキーの割当を表しています。簡単ですね。

このキーマップに指定するキーの一覧については QMK firmware documentation の Keycodes に一覧があります。初期状態だと、LCTL(KC_Z) のような形で、Ctrl と Z の同時押しを表現しています。 LCTL を外せば単なる Z キーになりますし、MEH(kc) とすれば Ctrl+Alt+Shift+kc が一発で入力できます。その他にもメディアキー(音量操作等)や電源キー(KC_SYSTEM_POWER)等の便利キー系もあるので、いろいろ試してみてください。

また、ここでは説明しませんが、マクロ機能もあり、あるキーが押されたら一定の複雑なキーコードや文字列を送信することもできます。5000 兆円欲しい!キーボードとか。

お疲れ様でした

ここまで来たらあなたも立派な自作キーボーダーです。おそらくここまでたどり着けたなら、他のより高度な自作キーボードについてももう自分で作ることができるようになっていると思います。

しかしここで触れた内容は自作キーボードのほんの一部に過ぎません。キーキャップやキースイッチにこだわるのも楽しいですし、QMK firmware にはここでは紹介しきれなかったたくさんの機能があります。ぜひ、このキーボードをそういった次のキーボード道の道標として利用していただければ幸いです。

ようこそ自作キーボード沼へ!

Help

組み立ての際に困ることやトラブル等あるかと思います。その際には Twitter@Biacco42 にリプライを飛ばしていただくか、Self Made Keyboard in Japan Discord server で相談していただければ対応します。特に Self Made Keyboard in Japan Discord server には私以外にも自作キーボードを製作している方がたくさんいるので、より多くのアドバイスを得られるかと思います。大変気楽なコミュニティですので、ぜひこちらの利用も検討してください。

おわり

自作キーボード入門本 KbD C93 の通販絶賛販売中 日経 Linux 2018 3月号 にて本誌 KbD C93 と Ergo42 が紹介されました! & 2018/3/6 Meishi 再販開始!

自作キーボード入門本 KbD C93 の通販告知になります。

[NEW] 2018 3/6 日経 Linux 2018 3月号掲載の「まつもとゆきひろ プログラマのこだわり」で KbD C93 と Ergo42 が紹介されました! & Meishi 再販開始!

おしながき

  • 自作キーボード入門本 KbD C93 の 印刷製本版 の販売中
  • 自作キーボード入門本 KbD C93 の 電子書籍 の販売中
  • 自作キーボード入門におすすめな Meishi - The micro macro keyboard 再販開始!

自作キーボード入門本 KbD C93 の 印刷製本版 の通販絶賛販売中

booth たのしい人生 ストアページ にて、 KbD C93 の印刷製本版の通販絶賛販売中です!

先日 C93 で好評を博し、あっという間に完売してしまった KbD C93 の製本版です!ブースに来ていただいたにもかかわらずご購入いただけなかったみなさま、大変ご迷惑をおかけしましたが、おまたせしました!通販でご購入いただけます!

しかも、今回は大幅な増刷ということで、がんばって フルカラーオフセット印刷 仕様にさせていただきました!意図的に雑誌的なデザインを心がけた本誌ですが、より雑誌感を増してお届けできるかと思います。

C93 頒布分のオンデマンド印刷も非常にきれいだったのですが、ぜひこちらの質感の変化も楽しんでいただければと思います。

booth KbD C93 印刷製本版 販売ページ

自作キーボード入門本 KbD C93 の 電子書籍 の通販販売開始

電子書籍版絶賛販売中です!

上記 KbD C93 に、ご要望の多かった 電子書籍版が登場します!

一刻も速く手に入れたい!紙の本は保管場所が…という方はぜひご検討ください。

booth KbD C93 電子書籍版 販売ページ

自作キーボード入門におすすめな Meishi - The micro macro keyboard 再販開始!

Ergo42 のキット販売に先立ち、本当は C93 で頒布したかった名刺型キーボードのキットを 再販します!

今回再販にあたり、4 つの付属スイッチの種類をいろいろ混ぜました! Gateron 黄色軸 (Linear)・白軸 (Linear 最軽量)・赤軸 (Linear)・青軸 (Clicky)、Cherry 茶軸 (Tactile) とかがランダムに混ぜてあります!スイッチの差もたのしんでみてください。

ケースもなく基板だけ、4 キーの非常にシンプルなキーボードです。キーボードに入門するのに必要最低限の要素を手軽に体験することができるキットになっています。

制作方法はこのブログの Meishi keyboard 組み立て方ガイド で紹介しています。(製作中)

以上、C93 当日売り切れで購入することができなかった皆様には大変ご迷惑をおかけしましたが、通販の方、なにとぞよろしくお願いいたします🙏

booth たのしい人生 ストアページ

2017 まとめの話

TL;DR

  • 全体としてはアウトプットしたものはしっかり刺さったので良かった
  • 復活の年
  • 他人に頼ろう

やったこと

1 月

今年最大クラスのイベントでかつ初っ端。前職を 12/31 付で退職して、現職に 1/1 付で就職しました。正直今年やってこれたのは、現職に移ることができ、暖かく迎えてもらったことだと思っており感謝しかない🙏

1/28 の yatteiki.fm #16 に出演させてもらった。2017 のやっていきはじまり。ここでもオタク活動のデータベース型みたいな話になっており、私の傾向が見て取れる。ただ、Podcast については自分がごっこ遊びが好きで編集とかにコストをかけすぎて潰れたので他山の石にしてほしい(反省)。

2 月

Scala Matsuri で Poor man's type classes revisited というタイトルで型クラスについての発表をした。このときは Haskell とかで理論的骨格になっている圏論等の話も交えて説明をしたんだけれど「Scala Matsuri なのになんで Haskell の話してるんやこいつ」という尤もすぎる指摘を受けたので、その指摘を踏まえて 6 月の記事では Haskell圏論が出てこないというテーマを打ち出すことができた。ありがとうございます。

3 月

引っ越し。転職したことで家が職場から遠くなってしまった + 現職の家賃補助制度もあり引っ越した。鬱が改善してきて人間性を回復してきたらこの家めっちゃ狭くね?と感じたので、今度は躁状態でめっちゃ広いとこを借りてしまった。精神を安定させたい。

あとクイーンサイズのベッドを買ったら QoL 爆アゲしたのでおすすめです。

4 月

前々から書こうと思っていた記事をシュッと書いたら某所で年間トップランキングに乗るぐらいバズったのでよかった。

5 月

あんまり記憶がない。たぶん引越し後で生活が荒んでいた時期。Kotlin を本格的に書き始めたのがこの時期のはず。Scala と似てるけど微妙に違うところがあってちょっと歯がゆい。検査例外がないのに標準ライブラリに Result がないのはどうかと思う。

6 月

2 月に Scala Matsuri で発表した型クラスの話が再燃していたので、【Haskell や圏論が出てこない】Scala で型クラスを完全に理解した話型クラスの原点 How to make ad-hoc polymorphism less ad hoc を読んだ話 を書いた。個人的には Haskell の型クラスの原論文に当たれたのが良かったし、Scala で型クラスを完全に理解した話の方はかなりバズったのでよかった。この辺の記事の理解に関しては @lyrical_logical さんや同僚の @omochimetaru によるところが大きい。ありがとうございます。

7 月

今年の冬コミに出す原因になったイベントがあった。絵を描いている友人と、アウトプット出していかないとなぁという話をしていたら「コミケ申し込んで、当選したらブースを即スクリーンネームに書いて背水の陣に追い込みましょう!」と言われて約束して実現した。他力本願寺

にしてもこのときは気軽に受け止めていたけれど、結果としてものすごく影響があったのでこれは感謝ですね。来年も鋭い感じでよろしくお願いします。

お遊びで描いた絵がバズってた。

8 月

コミケ行ったりコミティア行ったりでオタク活動が忙しかった。冬コミの申込みをするときに自作キーボード本にするか 3D CG イラスト本にするか悩んで自作キーボードを選んだ。この判断が今年の後半を決したので、なにがあるかわからないですね。

特にコミティアについては創作百合ジャンルの圧倒的尊さをこれでもかというほどぶつけられて最高だった。

9 月

突発的にめちゃくちゃ仕事が忙しかった。

Nippo で日報を毎日書き始めると同時に アイカツ! マラソンを始める。毎日必ず最低 1 話は観るようにした。人生を変えるきっかけはどこに落ちているかわからない。アイカツ!に出会えて本当によかった。

アイカツ! は基本的に幼女先輩向け作品ではあり、そしてだからこそ、根本的に悪い人間がおらず、また各キャラクターが賢く、根性論だけでなく結構合理的判断によって行動しているので観ていて非常にストレスが少ないし、ポジティブなメッセージが強く、オタクのユートピアに近い。アイカツ! については本当に良くてここでは書ききれない。 風沢そらを信じろ。

10 月

自作キーボード Ergo42 の本格的な commit が始まったのが 10/20 ぐらいから。冷静に考えて 1 ヶ月ぐらいでキーボード作ってたのか...

ただ、ErgoDox の KiCad ファイルが開けなくてまごまごしたり、KiCad チュートリアルを 0 からやったりたぶんしていたはず。逆に言えば下準備できていれば結構サクサク行けるとも言えるかもしれない。

たしか、やっていくために大学の後輩や友人等を誘った「頭が悪い人」Slack チャンネルを開設したのもこの時期。やっていきやアウトプットそのものも重要だけど、やっていくためには?という課題意識はずっとあって、それに関してこの取り組みはわりとうまくいったと思う。社会性があれな人間を集めたので(失礼)「今日はちゃんとご飯食べたえらい」「選択と掃除したえらい」「ちゃんと起きたえらい」みたいな会話もしていてこれは非常に良かった。メンバーもメカ系から機械学習やイラスト、言語オタク、漫画家等多岐にわたっていて、お互いの素朴なアウトプットを肯定できたのはかなり力になったと思う。

11 月

主に Ergo42 をつくっていた。毎週末レーザーカットに出かけていた形跡がある。

Ergo42 Rev.1 が完成。

Self Made Keyboard in Japan Discord server を開設する。あと、QMK firmware に Ergo42 が merge された🎉

アイカツ! についても 1 期 50 話を走り終えた。

そして宝石の国が神になっていた。

12 月

冬コミ準備 + Ergo42 製作で発狂する。さらにアドベントカレンダーも書いて発狂が極まってた。

冬コミでは無事 KbD C93 を頒布することができてありがたいことに速攻完売して主に謝り通す人になった。来てくださったみなさん本当にありがとうございます。

通販 booth でやることに決めました!続報はまたこの blog や twitter で書きます。Ergo42 のキット販売も来年予定していますのでなにとぞ!

あと、名刺型の 4 キーマクロキーボード基盤 + キットも販売しようかと思うので、KbD C93 と合わせて購入できるようにはしようかと思います。入門向けに。

まとめ

2015 ~ 2016 にかけては個人的には暗黒時代で、残業させまくられたり鬱で休んで天井を眺める日々を過ごしたりとわりと散々だったのですが、今年は本当にいい会社に転職できていろいろ少しずつ人間性を取り戻せたかなと思います。おかげさまでそれなりにアウトプットを出すリハビリもできたかな?

また、アウトプットについても量はそれほど出なかったけど、出したものはしっかり刺さったので、よかったかなと思います。あとは、鬱による不安が弱まったのか新しいことに挑戦するコストが少し下がったかなと。失敗を許容できるようになってガンガン新しいところに突っ込みたいし効率を上げたい。

石橋を叩いて壊すなんてジョークもありますが、実際のところ石橋を叩いているうちに時間も体力も使ってしまって渡ることを諦めてしまう人は多いんじゃないかと思っていて、私なんかも自己肯定感が低くて失敗したら見捨てられてしまうんじゃないかという気持ちがあったりして、なかなかシュッと手がつけられないタイプなんですが、今年は色々他の人に頼るという手段で精神を保つことができたので、自分も他の人にそういうサポートが提供できたらなぁという気持ちで本を作ったり Discord サーバー立ち上げしたりしました。

yatteiki.fm や コミケ出しましょう!に始まり、Slack や Discord コミュニティ等、人に救われた一年でした。

こう勉強会であるとか Discord サーバー立ち上げる人はすごいなぁと思っていたのですが、そういうことができたら楽しそうだなー、で動いたらうまくいったので、結構そういうものなのかもしれない。あったらいいな、やれたらいいな、はやってみるに限る、そういう気持ちになれたのもよかったかなぁ。

あとは、アイカツ!宝石の国少女終末旅行魔法使いの嫁、まほプリ等、上げきれないけどとてもいいコンテンツに巡り会えた年でもありました。次はこういうコンテンツの出力がしたい。私が信じる百合を信じたい。

全体を通して 2017 はよかったと思います。2018 はこれをブラッシュアップして伸ばしていきたい。

もうちょっと書きたかったけど、年越しコンサートなのでこれで。みなさま良いお年を。

この記事は 18:50 から 40 分で書かれました。その後 GPD pocket で 40 分ほど更新されていました。

4x7 split keyboard Ergo42 をつくったときの失敗話

この記事は、自作キーボード Advent Calender の25日目クリスマスの記事です。

昨日の記事は、ないんさんの キー配列頂上決戦!さいつよなレイアウトはどれだ! でした。

はい

[PR] KbD C93

KbD C93 という自作キーボード同人誌が 12/29(金) 東3 カ54b で頒布されます。

昨年あたりの ErgoDox での話題から、今年は Let's Split の大ブレークなど、2017 は自作キーボード元年ともいえる盛り上がりだったのではないでしょうか?そういった状況で、自作キーボードを職場で見かけたり、ブログや podcast などで見聞きした人、そして興味を持たれた人もだいぶ多くなってきたのではないかと思います。

その一方で、キーボードを自作するというのはおそらくまだまだ "得体の知れない" 行為である部分も多々あると思います。半年前の私もそうでした。

そこでそういった、自作キーボードに興味はあるけど、どこから手を付けていいかわからない、という人たちにとってわかりやすい入門のきっかけとなるように本を作りました。

この記事で紹介する Ergo42 の制作過程についても載っているので、ぜひ。

なにがしかの方法で通販もしようかと思いますので、当日来れない方もぜひよろしくお願いします。ご一報いただけると販売数を調整できるかもしれないので気軽に Twitter 等でご連絡ください。

宣伝終わり。

What ― 4x7 split keyboard Ergo42

Ergo42 という split / ortholinear / 4 行 7 列 のキーボードを作りました。

42 の理由は The Answer to the Ultimate Question of Life, the Universe, and at least Keyboards. です(ググってみてください)。

github.com

https://raw.githubusercontent.com/Biacco42/Ergo42/readme/readme_image/ergo42_image.jpg

Why ― バランスのいい分割キーボードが欲しかった

もともと去年の夏頃から ErgoDox EZ / ErgoDox を使っていて概ね満足していたのですが、使っていく中でいくつか気になることが出てきました。

  1. レイアウト切り替え機能が標準的な QMK を利用できるキーボードでは、指を伸ばして 5 行を使うのはちょっと余りある
  2. 特に親指の扱えるキーは 6 キーも振られているが親指でそこまで扱えない
  3. にも関わらずキー数の多さゆえにサイズが大きく持ち運びが大変
  4. エルゴノミックデザインということで、列ごとにキーがずらされているがこれが有効か確信が持てなくなってきた

そんな折、今年になって大ブレークしたのが Let's Split です。Let's Split は

  1. 4 行
  2. 親指で扱えるのは 2 キー程度
  3. 4x6 の最小限な構成と小型設計
  4. 完全直行配置

ということで、完全に自分のニーズにマッチするようで飛びつこうかと思ったのですが、ErgoDox で一番内側のキー(7 列目)を多用していた私としては 4x6 配列だとどうしてもキーが入り切らず、煮え切らないまま購入に踏み切れずにいました。

そこで、自分の考えるようなことは誰でも思いつくだろうと思って 4x7 split ortholinear なキーボードがないかなと思って探してみたのですが、なんと驚いたことに存在していませんでした。

ないなら作るしかないかということで作りました。

How ― どこから手を付けていいかわからないので先人の知恵に頼る

上記で Why を突き詰めていった結果、やりたいことはこの時点でかなり明確になっていました。その一方で、何をやったらいいかは全く不明でした。

ErgoDox でキーボード自体の組み立ては経験済みだったため、キーボードの構成要素やおおよそどう作られているかはわかっていましたが、自作するとなるとどうしたものかわからなかったのでマネすることにしました。オープンソース万歳。

詳しいことは薄い本 KbD の方にまとめてあるのでぜひ手にとっていただくとして 、大抵こういう場合はなんかいい感じにうまくいってしまった話がまとめられてしまうものなので、ここでは本に載せられなかった失敗談をメインに書いていきます。失敗が怖くてなかなか踏み出せない私みたいな人が一歩を踏み出すきっかけになれば幸いです。

失敗 1 ― プロジェクトが開けない

とりあえず最初は慣れ親しんだ ErgoDox の KiCad プロジェクトを見てみようとしたのですが、なぜか KiCad の PCB デザインファイルが開けずいきなり詰まる。KiCad のファイルには編集した KiCad のバージョンが記録されておりかつ、基本的に下位互換性を保証しない = 編集された KiCad バージョンより古い KiCad ではファイルを開けないという仕組みになっているのですが、コミットされていたバージョンのファイルの KiCad のバージョンが通常のバージョン命名規則から逸脱しており(ベータ版?)、最新の安定版どころかリリースされているいずれのバージョンでも開けなくなっていました。しょーもなくて疲れた。

ある程度コミットを遡って PCB 設計ファイルを開けるようになったのですが、最新版との差分も気になるし精神衛生上よろしくなかったので、この時点で ErgoDox をベースに作成する案はなしになり、代わりに Let's Split をベースに方針転換しました。今思うと KiCad のファイルはテキストファイルなので、バージョン番号だけ適当に書き換えてチャレンジしてみても良かったかもしれない。

失敗 2 ― 回路の流用はかえって大変

というわけで Let's Split をベースにするようにしたのですが、プログラマーの方ならわかるでしょうが、他人のソースコードを読むのは、それがよほど配慮して書かれていない限り、それなりに苦労があります。それを拡張するとなればいわんやをや。

最初は Let's Split のプロジェクトを改造して適当に 1 列足せばいけるやろ~w とか思っていたのですが、回路の設計意図を読み解いて、それを壊さずに拡張するのがめっちゃしんどいことが発覚し、またライブラリ等についても KiCad が結構フリーダムな仕様になっていて、もとの設計を流用するほうが困難だとわかりライブラリも含めて全部自分でやることにしました。この決断をするまでにも結構うだうだして時間を食った。

失敗 3 ― 買い物は慌てずに

これは失敗というかは微妙なのですが、ErgoDox では赤軸(45 g)を使っており、新しいキーボードにはリニアでもっと軽いキーならもっと楽になるのではという単純な発想で、Gateron 白軸(35 g)を買ってみました。で、組み立て終わって使ってみたのですが、ハチャメチャに軽い。軽くて打鍵感が軽いのはもちろんでそれは良かったのですが、簡単に沈み込んでしまうため底打ちしてしまいやすく、指を跳ね返す力が弱いので自分で指を持ち上げなければいけないという不思議体験をすることになり、個人的にはいまいちあいませんでした。後輩は荷重 30 g のキーボードを気に入っているそうなので個人差が大きそうですが。

キースイッチはキーボードの打鍵感の大半を決める重要なファクターなので、時間とお金を惜しまずキースイッチサンプルセット等をまず買って好みのものをしっかり見極めるほうが結果的に節約になると学びました。急がば回れ

失敗 4 ― 世の中にはレーザー加工機を使う人間が思ったよりいるし、ファッションコワーキングスペースはそんなに怖くない

ケースを製作するにあたって、3D プリンタは経験がなくなんとなく難しそうだったため(アホ)、アクリルをレーザー加工機で加工するよくある方式でやることにしたのですが、レーザー加工してくれる業者も、レーザー加工機を貸してくれる場所も意外と少ない。はじめてのケース製作では東急ハンズでアクリル板を買って、レーザー加工機のレンタルだと有名所な FabCafe 渋谷に雨の中いったのですが、まさかの予約で完全に埋まっており利用できず。FabCafe は予約できるのですが、予約の最小枠が 40 分でキーボードを加工するにはちょっと過剰なのでドロップイン利用を狙っていたのですが、世の中にはレーザー加工機を使う人間が思ったよりいる。

その後、雨の中悲しい気持ちだったのですが、とっさに調べて原宿にある coromoza さんに電話して、幸い空いていることを確認できてアクリル板を加工することができました。coromoza さんは 表参道にあるファッションのコワーキングスペース ということでくっそビビっていたのですが、スタッフさんが丁寧に対応してくれてとてもよかったです。5 分単位で予約もできるので、足が伸ばせる人はおすすめ。

失敗 5 ― 心配するよりやってみたほうが吉

最大の失敗は、自作キーボードなんて自分に作れるのか?といってビビっていることでした。やってみた結果わかったのですが、正直キーボードの自作は電子工作としてはかなり簡単な方です。高周波回路とかでもないし、レイアウトには余裕があるので分布定数とか厳密なことは考えなくてもぶっちゃけ動きます。そしてなにより自分で手を動かしてみるとやはり理解が進みます。当方ボーカルプロ志向バンドメンバー求むに陥らず、ぜひ手を動かしていきましょう💪

そしてそんな人を応援する C93 東3 カ54b のサークルたのしい人生(Biacco42)の KbD と Discord サーバーをどうぞよろしく。お後がよろしいようで。

この記事は、Ergo42 rev.1 で書かれました。

Self-Made Keyboards in Japan Discord Server を開設した話

Self-Made Keyboards in Japan という Discord サーバーを立ち上げました。

Self-Made Keyboards とは?

キーボードは買うものだと思っていませんか?作れるんです。

解説本としては @pekaso 氏が有名?

でも、難しいんでしょう?

多分電子工作の中では かなり簡単な方 です。完全自作だと多少は知識が必要になりますが、ハンダ付けするだけで作れるキット的な製品も存在しますし、ファームウェアもオープンソースのものがあります。しかも実用品なので、作った後は実際に使えるので満足度が高いです。

そして、そんな自作キーボードについて会話して、作り方まで聞けちゃう Discord サーバーができました。

Self-Made Keyboards in Japan

最近だと、ErgoDox や Let's split がかなりメジャーになったおかげで、自作キーボードを見かけることも増えたんじゃないかと思います[要出典]

ちょっとでも興味が出たら、覗いてみてください。

おしまい

Scala で for 式の中括弧{} 内で <- expression が受け取れる型について

どういう経緯だったか忘れてしまったのだけれど

Haskell の do 記法は Monad 型クラスの >>= (bind?) 等に変換される糖衣構文で、do 記法で使えるのは Monad 型クラスのインスタンスを持つ型だけだけど、Scala の for 式はどういう形で受け取る型を決めているんだろう?

という話になり、「TraversableflatMap とか定義されているから Traversable が受け入れられるのでは?」と素朴に思ったのですが、Option とか Future とか明らかに違うやつがいくらでもいるので調べました。

※さらにいうと、Scala 仕様書の for のところ見ても糖衣構文だよーとかどう分解するかということまでは書いてあるものの受け入れられる型みたいな話はなかったり、"Scala for 受け入れられる型" みたいなググり方をしてもなかなかたどり着けなかったので、私みたいな検索弱者用に書く

公式ドキュメントにめっちゃ書いてあった

Scala’s “for comprehensions” are syntactic sugar for composition of multiple operations with foreach, map, flatMap, filter or withFilter. Scala actually translates a for-expression into calls to those methods, so any class providing them, or a subset of them, can be used with for comprehensions.

ただし、How does yield work? という yield に特化したタイトルで、 Scala FAQs って謎階層にいたので、みつからないよ...って思った。(Scala の Gitter チャンネルで Tsuyoshi Yoshizawa さんに教えていただいた)

ためした

object Main extends App {
  val forPo = new Forable("Po")
  
  val po = for {
    u <- forPo
  } yield u
  
  println(po)
  
  // Kaboom! Cannot compile - lack of flatMap
  // val popo = for {
  //   u <- forPo
  //   v <- forPo
  // } yield u + v
  
  val multiForPo = new MultiForable("Po")
  val multiForPoPo = new MultiForable("PoPo")
  
  val popopo = for {
    po <- multiForPo
    popo <- multiForPoPo
  } yield po + popo
  
  println(popopo)
  
  // Kaboom! Cannot compile - lack of foreach
  // for {
  //   po <- multiForPo
  //   popo <- multiForPoPo
  // } println(po + popo)
  
  val sideEffectPo = new SideEffectForable("Po")
  val sideEffectPoPo = new SideEffectForable("PoPo")
  
  for {
    po <- sideEffectPo
    popo <- sideEffectPoPo
  } println(po + popo)
  
  // Kaboom! Cannot compile - lack of filter
  // val popo = for {
  //   popo <- multiForPoPo if multiForPoPo.x == "Po"
  // } yield popo
  
  val filterPoPo = new FilterForable("PoPo")
  
  val popo = for {
    popo <- filterPoPo if filterPoPo.x == "PoPo"
  } yield popo
  
  println(popo)
}

class Forable[A](val x: A) {
  def map[B](f: A => B): Forable[B] = new Forable(f(x))
  override def toString(): String = x.toString
}

class MultiForable[A](x: A) extends Forable(x) {
  def flatMap[B](f: A => Forable[B]): Forable[B] = f(x)
}

class SideEffectForable[A](val x: A) {
  def foreach(f: A => Unit): Unit = f(x)
}

class FilterForable[A](x: A) extends MultiForable(x) {
  def withFilter(expr: A => Boolean): FilterForable[A] = this // easy implementation
}

ダラダラと書いたけど、つまるところ map とかのシグネチャを満たしてれば普通に for comprehension<- の右側に使えることがわかった。

Scala の for 式は実は単に flatMap 等のへの糖衣構文だったり明らかに Haskelldo 記法 をパクった に近いにも関わらず、Haskelldo 記法が Monad 型クラスを要求するのとは結構毛色が違う感じがする。

受け入れられるシグネチャについても結構ゆるくて

class Forable[A](val x: A) {
  def map(f: A => A): MultiForable[A] = new MultiForable(f(x))
}

とか、かなり原型をとどめていなくても行けたので、シグネチャというより、本当にメソッド名さえあっていれば良くて、脱糖されてから型検査が通ればオッケー(実際脱糖は型検査以前に行われるらしい)、という感じのようだ。

結構ふわっとした仕様でちょっと意外だった。

おしまい。

エスペラント入門 #2 ~ または、ことのはアムリラート

本日の学習

ことのは 意味 備考
ボーナン マテーノン あいさつ? ボーネ や ボネーゲ がポジティブなようなので good morning 的な?
ファルタス キーエル ヴィ ファルタス? という形が何回か見かける
プレータ プレート = Dish? マテンマンヂョ エスタス プレータ = 朝ごはんです?
ヴィズィタント visitor
グーテン good? グーテン アペティート で食事の挨拶?おなかへった?
アペティート appetite? 同上
ヴェーレ チュ ヴェーレ = ホント?
ボーネ いいね? ボネーゲ が前回も褒められていたのでポジティブな単語らしい
チェース 待って? ヴィ ネ ベゾーナス スクリービ ミーアン ノーモン! と続いたが…
ゾル 悪い? ゾルグ!という形で「悪くないよ!」的文脈で
エラーラス 間違い? error だろうなぁ
カゥズィス Cause? オカーズィス(前回)同様 cause 系の文脈で出現してる気がする
コムプレーナス 前回のものと同じ? ミ コムプレーナス = 大丈夫?安心して?
ヴェンデーヨ
レゴーマ 野菜
フィシュ
ヴィアンド
パノ パン
クク ケーキ
リズブル おにぎり?
リブロ
the? 仏語?
カーフォ コーヒー
ペフェクテ perfect?
プルス plus
ミーアン my?
ノーモン 名前? name やろなぁ

単語レベルではわからんやつ

徐々に単語レベルではなくガンガン文章としてエスペラントが出てきたので、もはや単語での推測は困難になってきた。ので、文章単位で意味を予測していくことにした。

  • キーウン ヴィ プレフェーラス、チュ ポムスーコン アゥ オランデジュスーコン.....

    • キー* は疑問詞
    • プレフェーラス は謎だけど prefer か?
      • だとすると キーウン は Which かも。Which do you prefer?
    • ポムスーコン と オランデジュスーコン が語形から並置されているとすると アゥ が or か
    • 飲み物を運ぶシーンだけど、オレンジジュースってのは安直すぎるか…?
  • ニ マルシュ マーノン エン マーノ

    • 上のと同じで エン が and?
    • マルシュ が verb?
      • 近い発音だと仏語の marché = 市場だし後に商店街に行くので正しそうだが、品詞的には marche = 散歩 (march と同語源?)のほうが正しいかもしれない
  • レゴーモ、フィーショ、ヴィアンド

    • レゴム-ヴェンデーヨ、フィシュ-ヴェンデーヨ、ヴィアンド-ヴェンデーヨ
      • 舞台は商店街
      • ヴェンデーヨ = 店?
      • レゴーマ サンドヴィーチョ が野菜サンドだったっぽいので、八百屋、魚屋、肉屋、と来そう
    • どうも活用?して語尾が 〇〇eーyo みたいな感じになると〇〇屋になる?
  • チュ ヴィ ヴォーラス マンヂ パーノン?

    • Do you おなかへり? Want パン?
      • 形容詞に対しても チュ (Do っぽいと予測しているやつ) つかう?
  • ラ "ヴォルト-ラディーコ" エスタス "リブル"、ド "リブル プルス 『エーヨ』" ファリーヂャス "リブレーヨ"

    • ヴォルト-ラディーコ = 無活用形?
      • 無活用形がリブル、で、リブルとエーヨを足して finally リブレーヨ
  • ヴェーヌ アル ミ

    • 私についてきて?
  • ヴィ ネ ベゾーナス スクリービ ミーアン ノーモン!

    • ヴィーアン が あなたの と予測される文脈があったので、ミーアン は 私の かも
    • だとすると ノーモン は話の流れ的に 名前
    • ベゾーナス か スクリービ が書くという動詞のはずだけど不明

感想

f:id:biacco42:20171011011333p:plain

ルカちゃんが非常にかわいくなってきたけれど、彼女は日本語がほぼできないので、感情的な表現・流暢な表現となるとエスペラントなので、はやくルカちゃんと自由にコミュニケーション取れるようになってルカちゃんと仲良くなりたい...

だいぶ一筋縄には行かなくなってきた。単語や文章の意味を真面目に考えてメモしながらすすめるとなかなか進まない。けど、Ruka ちゃんがめっちゃ優しくがんばって教えてくれるのでがんばる。

エスペラント入門 #1 ~ または、ことのはアムリラート

ことのはアムリラートをはじめた

ことのはアムリラートという純百合 ADV を標榜するゲームがあります。当然『純百合』の時点で耳目を集めることは必定であるのですけれども、このゲーム、なんといっても異世界転生 ※ただし異世界の言葉は理解できない という、「なんで異世界転生したのにいきなり言葉が通じるんだよ」という消費者の声に真摯に応えた作品で、以下のような画面が展開される大変エモーショナルな作品として注目を浴びていました。

f:id:biacco42:20171007225329p:plain

典型的な (異世界での) 少女同士の出会いの一幕

この異世界言語は全くのオリジナルではなく、基本的にはエスペラントだそうです(厳密にはエスペラントと異なる部分もあるらしい)。

言語監修

藤巻謙一 『著書「はじめてのエスペラント」他』

協力(言語監修)

一般財団法人日本エスペラント協会

というわけで、ことのはアムリラートでエスペラント入門、です。

本日の学習

【注意】 ここから先はネタバレを含みます!

といってもエスペラントの話なのでネタバレもへったくれもないとは思いますが、ストーリーの進行と一致しているので念のため。

意味に?がついているものは完全な予測なので全く外れている可能性もあります。

ことのは 意味 備考
エス Yes
No
ヴィ あなた
私達
パルドーヌ ごめんなさい 英語の Pardon と同語源?
ダンコン ありがとう 独語の Danke と同語源?
キーオ 疑問詞? 文法的には文頭について疑問文をつくっている?
キーエ Where?
ヴァルマ あたたかい
ヴァルメーガ あつい
アクヴォ "ユ" => 湯 が ヴァルマ アクヴォ
オムレート オムレツ そのまま。朝ごはんだった
タグメーゾ 独語の Tag と同語源?
ィエ ラ ウヌーア 1 時
レゴーマ サンドヴィーチョ 野菜? サンドウィッチ
エクイーリ 出かける
アクツィデント 事故・Accident
ウーヌ 1
ドゥ 2
トリ 3
クヴァル 4
クヴィン 5
ヂス ラ じゃあね?
何らかの冠詞 or 前置詞?
レルネーヨ 学校?
ヴィーアン Your? You の所有格か?
セド But?
ホーロ When?時刻?
レヴェーニス 探す?
ボネーゲ すごい?
コンプレーナス 完璧? Complete?
ティーミス 心配する?
オカーズィス 起こる? Occur から根拠レス予測
イーア Some?
アル 前置詞?
エスタス やたら出て来るけれど不明。疑問文に出現しやすい気がする...
エスティス 活用形?ネ と同時に出現。Be っぽい運用な気がする...
チュ 単純疑問で使われている気がする。Do?

セリフはエスペラントではなくカタカナ表記なので、エスペラントについては完全な文盲になりそう。綴りがわからないの結構つらい....

f:id:biacco42:20171007232130p:plain

これは...わからないなぁ....

iOSDC 2017 でさらっと出てきた Phantom Type さらっとやった話

これはなに

先日開催された iOSDC 2017 に参加しました記事です。

Ray Fix 氏の 視覚化とSwiftのタイプについて という発表で

protocol CoordinateSpace {}

enum ModelSpace:   CoordinateSpace {}
enum UserSpace:    CoordinateSpace {}
enum DeviceSpace:  CoordinateSpace {}

struct CGPointT<Space: CoordinateSpace>: Point2DProtocol {
  var xy: CGPoint
  // 実装
}

struct CGAffineTransformT<From: CoordinateSpace, To: CoordinateSpace> {
  var matrix: CGAffineTransform
  public func inverted() -> CGAffineTransforT<To, From> {
    return CGAffineTransformT<To, From>(matrix.inverted())
  }
}

public func * <From, To, I>(from: CGAffineTransformT<From, I>,
                            to: CGAffineTransformT<I, To>) -> CGAffineTransformT<From, To> {
  return CGAffineTransformT<From, To>(from.matrix.concatenating(to.matrix))
}

みたいなサンプルコードが出てきて

let modelToUser: CGAffineTransformT<ModleSpace, UserSpace> = ...
let userToDevice: CGAffineTransformT<UserSpace, DeviceSpace> = ...
let modelToDevice = modelToUser * userToDevice // CGAffineTransformT<ModelSpace, DeviceSpace>

これ型パラメータ実装ないし、実質処理はなにもしてなくない?

というのが、幽霊型 (Phantom Type) です。

Phantom Type

上のコードがほぼ全てですが、型の状態 (モデル空間にある頂点なのかユーザー空間にある頂点なのか) を型パラメータとして表現することで、実行時ではなくコンパイル時に状態を検査することができます。が、この型パラメータは実装では利用されておらずコンパイルしたら消えてしまうので、幽霊型 (Phantom Type) というわけです。洒落てますね。

状態に依存したコード

struct StateDependent {
    var ready: Bool = false

    func doPo() {
        precondition(ready, "Not ready!")
        print("Po")
    }
}

let stateDependent = StateDependent()
hoge.doPo() // Boom! Exception in runtime!

Phantom Type で状態を型で表現したコード

protocol State {}
enum Ready: State {}
enum NotReady: State {}

struct PhantomTypeSafe<S: State> {
    static func create() -> PhantomTypeSafe<NotReady> {
        return PhantomTypeSafe<NotReady>()
    }

    func toReady() -> PhantomTypeSafe<Ready> {
        return PhantomTypeSafe<Ready>()
    }
}

extension PhantomTypeSafe where S == Ready {
    func doPo() {
        print("Po")
    }
}

let phantomTypeSafe = PhantomTypeSafe<NotReady>.create()
//phantomTypeSafe.doPo() // Cannot compile
phantomTypeSafe.toReady().doPo()

Phantom Type = コンパイル時に型検査するためのタグのようなもの

上記サンプルだと、状態を表す変数 var ready をフィールドに持った型では、実行時までエラーが検出できませんが、Phantom Type を用いた型では extensionwhere 句による制約を設けることで、ある 型の状態 でないと呼べない関数を表現することができており、コンパイル時に静的にエラーにできます。

Ray Fix 氏のサンプルだと、CGAffineTransformTModelSpace でも UserSpace でも型としての性質や実装は変わらないので、下手に型を増やさずに Phantom Type で状態を表現して、変換同士の接続に破綻がないかを型で検証できています。

繰り返しになりますが、型パラメータ自体は利用されておらず、あくまで状態を表現する変数のようなものとして扱われているところがおもしろいところです。

Phantom Type で型の条件付け

これだけだとアレなのでもうひとネタ。

ジェネリクスのある言語ならこの Phantom Type のテクニックは使えると思うのですが、関数の引数に受け取る型に制約をつけるといえば他にもあった気がしてきました。型クラスですね

というわけで Scala で Phantom Type と impicit を組み合わせて、受け入れる型に制約をつけてみます。

sealed abstract class =:=[From, To] extends (From => To) with Serializable
private[this] final val singleton_=:= = new =:=[Any,Any] { def apply(x: Any): Any = x }

object =:= {
  implicit def tpEquals[A]: A =:= A = singleton_=:=.asInstanceOf[A =:= A]
}

def doPoWhenEqualType[A, B](implicit et: A =:= B) = "Po"

val po = hoge[Int, Int] // Po
// val po = hoge[Int, String] // compile error

上記の =:= の定義は実際に Predef という、Scala が標準で読み込む定義に含まれています。

Swift でもやってみました。

class TypeTag<T, U> {}

func doPoWhenEqualType<T>(_ tag: TypeTag<T, T>) -> String {
    return "Po"
}

//let po = doPoWhenEqualType(tag: TypeTag<Int, String>()) // Cannot compile
let po = doPoWhenEqualType(TypeTag<Int, Int>())

なんかもっとうまく書けそうな気がします…

というわけで、Phantom Type をさらっとだけ見てみました。

おしまい。

Amazon.co.jpアソシエイト