マンションの換気ダクトと塗装ブースのホースを直結できる部品を3Dプリンタで作った

省エネ記事。

最初のアイデアはAmazon | 排気ホース・集合ダクト【補強 タミヤ塗装ブース・ツインファンの２本のホースを連結して１本に (タミヤホース) | ペインティングスタンド・ブース 通販から。

しかし、そのためにはCADでモデルを作らないといけない。 Fusion 360を使うかFreeCADを使うか、つまりwindowsをやむなく使うかlinuxでも使えるソフトウェアを使うか3日悩んで、ユーザビリティに劣るとしても長期的には価値が高いと判断したFreeCADを使うことにした。 ちなみにこの判断はあとで大正解だったと感じた。確かにわかりやすくはなかったがyoutubeなどに解説動画も多くあり、やりたいことができないことはなかった。これでwindowsの呪縛から逃れられるなら多少の不便は許容できる。

FreeCADで最初に作ったモデルの印刷。これが一発でとてもきれいに出たのでFreeCADいけるやんと自信になった

次に換気ダクトのフック部分に引っ掛ける構造のテスト印刷。これのFreeCADでのモデル制作は大変だった。が、ここを頑張って超えたのでその後もFreeCADを続けられた。やはり3Dプリントでの成功体験が強烈なのでモチベーションが保ちやすいのは3Dプリンタの良い点

先に印刷したやつをフックへ引っかけようとすると肩甲骨の間のところが邪魔でちゃんと引っかからなかったのでその部分を除去したモデル。これならピッタリ引っかかった。ちなみにフックのサイズはちゃんと採寸して、多少の余裕を加えてサイズを設計してある。

1つ目と2つ目の試作の比較。左右の出っ張りの間の部分があるかないかが違う。この辺、細かく試作しながら試せるのも3Dプリンタの良い点。しかもPDCAが早い、これぐらいのパーツなら1時間以内にできる。

ダクト径を量って一度試しに作ってみたモデルがこれ。十字の支えの一箇所がちゃんと外径へ接していない問題など発覚。また、このような単なる円柱状だとダクトホースへうまく接続できないことがわかった。さらに、設置場所の机の高さからダクトホースは斜め上方向から接続する必要があるため、この部品の間で角度を変える必要があることもわかった。こういったことも実際に試してみないとわからないのでやはりPDCAは大事。

3Dプリンタの新しいファームウェアが公開されておりoctoprintとの相性問題が解決したらしいのでSDカードからとoctopiからで印刷結果を比較。結論、問題は解決したっぽい。また印刷時間も従来octopi経由だと長くかかっていたのが差がなくなった、気がする。今後はoctopiを常用することに。

ダクトホースとうまく接続するため、ライフリングのようなものを刻むことに。これもまた3Dプリンタで作るの大変だった。最終的に円柱からねじを減算してモデルを作った。これはその初作だが、回転の方向が逆なのとサポートが邪魔すぎる問題点が見つかった。

1回目の反省を生かしてネジの回転方向を逆にし、同時にサポートをなくした。サポート無しでちゃんと印刷できるか少し不安だったが問題なかった。この辺りはサポートがないとほとんどまともに印刷できないSLAタイプとは大きく異るところ。

このあと、とても苦労してモデルができた(2つの向きの違う円柱をスムーズにつなぐのに数日かけた)。モデルができたので本印刷前に実物の数分の1のサイズで印刷したのがこれ。しつこいが、こういった試作がスケールの係数一つ変えるだけで印刷できるのは本当にすごい。この印刷結果を手に取りながらいろいろ見た結果、問題なさそうだったので本印刷へ入ることにした。

本印刷1回目。残念ながら全体の40%ぐらいのところで印刷が途切れていた。状況を観察するとフィラメントがヘッドからすっぽ抜けていた。そうなった原因は不明。

本印刷2回目。モデルが原因かはまだわからなかったのでモデルを変えずフィラメントをちょっと高いやつに。結果、こちらも印刷途中で途切れてしまっていた。こちらもフィラメントがすっぽ抜けていた。ここでモデルのGコードに異常がある可能性(unloadのコードがバグで混入してしまった？)を疑ったが、1回目と2回目の印刷結果を比較するとその高さ = 印刷失敗タイミングが違うことに気がついた。ということはGコードではない。モデルデータ内のGコードが原因なら必ず同じ場所で問題が発生するはずだからだ。よってモデルが原因ではないと判断した。次に疑ったのはZ軸の移動で、このモデルのような背の高いものを印刷するのが久しぶりでかつZ軸移動で激しく泣きが発生していたため、自転車のグリスを塗ってZ軸の移動をスムーズにした。もう一つ原因として考えられたのが3Dプリンタの振動で、今プリンタを廊下の棚へ設置しているため部屋への出入りのタイミングで結構振動が伝わってしまっていた可能性があった。そのため、印刷中は気を使ってなるべく振動を伝えないように廊下を移動するようにした。

本印刷3回目。今度こそ成功。2回目までの失敗要因がZ軸だったのか振動だったのかは不明だが、たぶんZ軸のような気はした。

というわけで早速試しに設置してみたのだがとてもよかった。 かかった費用はフィラメント1KG未満で前半は安物を使っていたのでおそらく2,000円もかかっていない。 今回はできたものにも大満足だが、なによりFreeCADで工業デザインのためのCADを学べたのが本当に良かった。僕はもともとロボットコンテストで興味を持って高専に入ったのだけど結局学科は当時急速に伸びていた情報工学科を選んだ。そんなわけで昔から機械科の友達がCADを使っているのを少し羨ましいと思っていた。だから昔からの念願が一つかなった感じ。

一年ぐらい前からゲームをしている

子供の頃からゲームが好きだった。

親が買ってくれたファミコンやスーファミには可処分時間の限りかじりついたし、社会人になってもLoLへ5,000時間以上費やしたりしていた。 一方で人以上にうまいとは言えず、初めてハマった格闘ゲームGGXXBRでもせいぜい校内上位20%、LoLに至ってもプラチナ2が最高ランク(全プレイ人口の上位10%ぐらい)だった。 そもそも子供の頃から運動神経が良いとは言えず、妹が上手にできるドリブルがいつまで経ってもうまくできなかった。格闘ゲームにしても親指の筋肉を痛めてしまい、とてもがっかりしたこともある。

直近はどうにもゲームが面白いとは思えなくなってきた。 いろんなゲームをやっているうちに単調に感じてきたのもあるし、梅原の言葉を借りるなら自分の成長を感じられることがなくなってきた。

RPG, MMORPG, FPS, アクション, シミュレーション, アドベンチャー, ストラテジー, ローグライク, TRPG, ボードゲーム, etc あらゆるゲームに手を出してきたが何をやっても1時間も続けられなくなった。

そんなわけで暇を持て余した僕は、ついに仕事をゲームにして遊んでみることにした。

そうすると、これがなかなか面白い。 まず成長実感が非常に得やすい。問題は常に目の前にあり、それへの打ち手は基本的に何でも効く。 次に、やったことがより大きな影響を及ぼす。ほとんどのゲームの影響範囲は自分の箱庭の中で完結しており、その外へ影響を及ぼすものもせいぜい直接やり取りをする人ぐらい。ただ、このゲームや自分のやったことが社会へ直接影響を及ぼす。これはなかなか面白い。 また、問題が無限にある。ゲームでは設計された課題やレベルデザインを相手にするが、仕事では用意された正解のない無限の問題と戦う必要がある。これが飽きない。

行動も随分変わった。問題解決や組織論のようないわゆるビジネス書を読んでいる。 最初の上司(数ヶ月で転職した)が退職時の挨拶で「エンジニアはビジネス書を胡散臭いと思って読まないけど、あれはあれで役に立つよ」と言い残していったのだけど、7年経ってそれを実感したことになる。

周りを見渡すと、タフで信頼できて頼りにしている同僚はみんな実に楽しそうに仕事をしている。 今の自分も、周りからそう思われていたらいいなあと思う。

なぜ今10年使ったzshをやめてfish shell / nushell / xonsh / elvishへ移行しようとしているか

zshをかれこれ10年ぐらい使っている。

最初のきっかけは忘れたけども、本格的に使うようになったのは2007年ぐらいに書かれた「漢のzsh」という伝説的な紹介記事によるもので僕の .zshrc には未だに 漢のzsh 4thから引用 みたいな設定がたくさんある。

【連載】漢のzsh | TECH+

そんなzsh、僕は会社でmac自宅でlinuxを使うようになってもhomeshickというツールを使って設定を同期していたのだけど近頃調子が悪い。自宅のlinuxの方は問題ないのだけど会社のmacでshellの立ち上げに5秒ぐらいかかるようになってしまった。 tmuxを使っているのでshellを立ち上げ中に元のペインへ戻って作業をしているのだけど考えてみると結構作業効率を落としている。なにか目的があって別のシェルを立ち上げているので、一時的にでも別のことをせざるを得ないということは思考が中断されている。人間の脳のコンテキストスイッチはかなり効率が悪いのでこれは良くない。

調べてみたらzsh+anyenvが不味そうなことがわかったのでそこを直そうかとも思ったんだけど、そもそもその問題を解決しても起動に1.5秒ぐらいかかる。 なんでこんな時間がかかるんだとzshのプラグインマネージャーを比較し始めたあたりでもう嫌になってきた。

そうだ、fishをためそう。

fish shell

fish shellは新時代のshellとして数年前から話題になっていた。 ただ、移行に踏み切らなかった理由はいくつかあって、一つにposix標準じゃないこと、もう一つはportabilityの観点だった。

fish shellの懸念

posix標準のshellというのはだいたいsh互換のシェルという意味で、ifやwhileなどの構文がshと同じようにかけるshellだ。 fish shellはこのif for whileのような構文がshと違うことがネックだった。というのは僕のようなインフラ寄りのエンジニアにとってシェルスクリプトは日常書くので2種類の構文を使うと混同して混乱してしまう恐れがある。

もう一つのportabilityというのはログイン先のサーバなどでfishが使えないことで、数年前はまだfish shellは新しめのshellという印象だったのでログインした先のredhatやcentosで使えるかが不安だった。当時は日常的に数十台のサーバへログインして作業しており、サーバによってはその中でツールをインストールして実行していたので手元のPCと出先のサーバでshellが違うことはこれまた認知負荷を余計に高める要因だった。

しかし、状況が変化した。

サーバレスの時代

オンプレからAWS初期の時代はインスタンスに直接sshしての作業は日常茶飯事だったが、Lambda, ECS, EKSへ移行していくに連れcompute nodeへログインすることはおろか踏み台サーバを使用することすらまれになってきた。 そして今の会社ではついに全面EKS / lambda移行を行い、踏み台サーバすらない状態になっている。 こうなると懸念だったポータビリティの観点はほとんどどうでもよくなる。 また、posix標準についても5年前は不慣れだったposix標準構文に十分慣れたことで混同する恐れがほとんどなくなったために問題はクリアされた。

zshからの移行先

こうして、fish shellを避ける理由がなくなったのでzshrcからfishへの設定移行をしているのだが、bigwheel/fish-castleかなり移行を進めた段階でこれはこれで気になる点がいくつか出てきた。一つは設定のポータビリティで、サーバーへはログインしなくなったものの会社と自宅PCで同じ設定は使いたいのだがfish shellはuniversal variablesという変数周りのポータビリティがそもそも設計思想になく各PCでuniversal variablesは固有の思想になっているため同期に難がある。

またC++で書いているのも気になって、令和ならgolangかrust使っているほうが将来性があるのではという気になってきた。 そこで上がった選択肢が以下

• xonsh
• nushell
• elvish

特にnushellはすでに一定の信頼を得ている気がするので、これが良さそうであればfish shellを飛び越してこれにするのもありだと思っている。

追記

fish, nushell, elvishと試した結果、結局fishを使うことにした。 nushellはHistory (ctrl + r) with fzf · Issue #1616 · nushell/nushellにある通りhistoryに対して高度な検索を行えないのが痛い。 elvishは最初ctrl-aのようなショートカットキーが使えなくて、しばらく調べてreadline-binding: Readline-like Key Bindings - Elvish Shellで有効化できることはわかったのだけど、fishの哲学のout of the boxで使用できるというものが以下に価値があるかわかった & elvishは全編こんな感じで対処しないといけない匂いを感じたので結局fishに戻ってきた。

我が家のIoT家電とそのコスパ

うちのIoT家電設備がいよいよほぼ完璧になったのでメモがてらそれぞれの使用感とコスパを列挙していく。 一部普通の白物家電もあるがご愛嬌。

制御

コスパ★☆☆ Echo Dot 第2世代

Echo Dot (エコードット) 第2世代 - スマートスピーカー with Alexa、ホワイト

コスパ★★★ Echo Dot 第3世代

Echo Dot (エコードット)第3世代 - スマートスピーカー with Alexa、チャコール

それぞれ3千円と200円で購入。 最初は音声制御がそんなに便利か懐疑的だったが、認識の精度が高いこと(体感成功率は9割以上)、ほぼすべての家電の制御をalexaに一元化したことによる便利さから今ではなくてはならないものに。地味にキッチンタイマーとしても便利。あといつもと違う時間に起きる必要があるときに一回限りの目覚ましをセットするのも良い。

コスパ★☆☆ Nature Remo mini

Nature スマートリモコン Nature Remo mini ネイチャーリモミニ Remo-2W1 Alexa/Google Home/Siri対応

2018/10に1万円で購入。 これ一つでエアコン、テレビ、リビング照明、PCモニタを制御。 Alexaと一緒でないとあんまり便利でない点、今ならswitchbotなどが半額以下で同様の製品を出していることからコスパは悪目。

コスパ★★☆ SwitchBot Hub Mini

SwitchBot スイッチボット スマートホーム 学習リモコン Alexa - Google Home IFTTT イフト Siriに対応 SwitchBot Hub Mini

2021/06に約3千円で購入。 SwitchBotカーテンは単体ではAlexaに繋げないため、音声制御するのはこれが必要になる。 Nature Remoと役割がかぶっているためうちでは残念感があるが、それがないなら十分コスパは良い。

照明

コスパ★★★ LED電球 広配光タイプ 人感センサー付き 明暗センサー

コスパ★★★ アイリスオーヤマ LED電球 人感センサー付

LED電球 広配光タイプ 人感センサー付き 明暗センサー 室内センサーライトト 自動点灯/消灯 センサーライト E26口金 led センサー 60W形相当(昼白色7W-E26)

アイリスオーヤマ LED電球 人感センサー付 口金直径26mm 40形相当 昼白色 LDR6N-H-SE25

それぞれ1個1,200円程度で購入。 まずいちいちスイッチを入れなくていいので便利。トイレにつけると衛生的にも良い。また消し忘れを消しに行くだるさもなくなる。 コスパはとても良い。

コスパ★★☆ リモコン制御照明(リビング組み込み、ブランド不明)

マンション組み込みのリモコン制御照明。 Nature Remoで制御している。特に寝るときベッドにいながら「Alexa、照明を消して」といえば消せるのが最高。安くない家賃の幾分かはこういったところの評価なのだろうけど、結構満足している。

コスパ★★☆ SwitchBot カーテン

SwitchBot カーテン 自動 開閉 スイッチボット スマートホーム アレクサ - Google Home IFTTT イフト Siri LINE Clovaに対応 遠隔操作 取付簡単 ソーラーパネルで充電可能 U型/角型レールに対応 8Kgまで対応

2021/06に9,000円で購入。 朝日で起きると快適に起床できることに気づいたため導入。まだ数日しか使っていないがスムーズに動いている。 値段は高いが睡眠と起床はQoLに直結するので評価は高い。

白物家電

コスパ★★★ 日立 ドラム式洗濯機 BD-SG100FL-W

日立 ドラム式洗濯乾燥機 ビッグドラム 洗濯10kg/洗濯～乾燥6kg ホワイト BD-SG100FL W 本体幅60cm 左開き 本体日本製 風アイロン

2021/04に約16万円で購入。 洗濯が苦でなくなった。干す手間が要らなくなっただけではなく、物干し竿やハンガー、ピンチなど干すための道具やそれを置く空間、干しておく場所などがすべて不要になり部屋が広くなった。 洗濯頻度が4,5日に一度から3日に一度になり衛生的にも良くなった気がする。

コスパ★★★★ Panasonic 食器洗い乾燥機 NP-TCM2-W

Panasonic 食器洗い乾燥機 プチ食洗 ホワイト NP-TCM2-W

2020/01に中古で23,000円にて購入(分配器込み)。 一人暮らしを始めた瞬間に買っておけば良かったと思う家電筆頭。 これによりシンクに使用済み食器を貯めることがなくなり、料理が楽しくなった。 自分は料理が嫌いなのではなく料理の後片付けが嫌いなだけなことに気づいた。

グリルの網や受け皿、フライパン、ボールまでまるごと入れて実行している。 日によっては2回実行するほど多用している。

その他家電

コスパ★★★★ DEEBOT ロボット掃除機 N79T

2018/11に26,000円で購入。 いわゆるルンバコピー。値段は1/4だが十分に機能してくれてほぼ毎日稼働しつつそろそろ2.5年が経とうとしている。頑丈でまだまだ壊れる気配はない。 特に自分が不在の平日昼間に掃除してくれるのが最高で、掃除機のあの騒音なしに床がきれいになる。

コスパ★☆☆ TP-Link WiFiスマートプラグ

TP-Link WiFiスマートプラグ 2個セット 遠隔操作 Echo シリーズ / Googleホーム / LINE Clova 対応 音声コントロール ハブ不要 3年保証 HS105P2

2019年8月に4,000円で購入。 扇風機や電気ストーブに接続して使用。 アイデアとしては至極全うで便利なのだけどこの製品に関しては残念なことに製品の品質が低かった。 まず、alexaとの接続がしょっちゅう切れる。wifiでalexaと接続されており中継器などいらない点は良いのだけど3割ぐらいの確率でalexaからアクセスしても応答がない。ファームウェアをアップデートなどしても改善しない。また、電源プラグの形が左右で違い、片方が縦に長い形になっている。これにより延長コードなどによっては刺さらないケースがある。実際うちの延長コードなどにはほとんど刺さらなかったため対応したケーブルを見つけるのに苦労した。

コスパ★★☆ FLEXISPOT EF1

FLEXISPOT 電動式スタンディングデスク(幅120×奥行60,メモリー機能付き) 昇降デスク 高さ調節デスク パソコンデスク 人間工学 ゲーミングデスク EF1 セット (マホガニー, 120*60)

2021年10月に購入。 組み立てめっちゃ大変だった。 単純に机が追加されたことがQoLを上げた。

立って作業する時間はだんだん減って、最近だと10%ぐらい。ただ、立ち上がる習慣がついた気はする。

購入検討中の家電

スマートロック

便利だが、そもそもマンションの入口で物理鍵を使う必要があるためどちらにしろ物理鍵を持ち歩く必要がある。そのためこれだけ導入してもメリットが薄い。

Echo Show

Echoは使い倒していてタダならほしいが、現状モニタによるメリットが不明瞭で購入に踏み切っていない。

自作キーボードの追加パーツのデメリットの話

tl;dr

• より多くの機能があったほうが良いと思って追加パーツをたくさん使っていたよ
• 結果、キーボードがハードウェア的/ソフトウェア的にとても不安定になってしまったよ
• 機能を盛ったほうが良いというものではないという学びがあったよ
• 今は安定したキーボードを求めて使うパーツを限定し始めたよ

追加パーツの代償

自作キーボードを初めて半年、基本的にメンタリティが男の子なのもあって使用可能なオプションはすべて使用してきました。主に以下などです。

• Bluetooth化 (BLE Micro Pro)
• Pro Micro用コンスルー
• キースイッチのソケット化
  • PCBソケット
  • Mill-Max ソケット
• LED

最初パーツを追加する限りは特にデメリットはないと思っていたんですが、数ヶ月続けていくうちにどれもデメリットが見えてきました。

機能	デメリット
Bluetooth化	接続が不安定 BIOSやブートローダで使用できない linuxでbluetoothdが死ぬ
Pro Micro用コンスルー	USBケーブル抜き差しのタイミングで浮く 浮きすぎて特定ピンの接続が切れると挙動がバグる (原因特定がとても大変だった)
キースイッチのソケット化	キーがぐらつく 斜めの力がかかるとキーキャップごと抜ける キーキャップの交換が大変
LED	光らせたくないときの切り替えが必要 LED制御のための追加のキー配置が必要

どれもメリットとのトレードオフであったというだけの話なのですが、使い始めた時点ではデメリットに気づいていませんでした。またこのあたりのデメリットに対する言及もウェブ上ではあまりされていないと思います。

特に問題だったのが安定性が損なわれてしまったことです。

キーボードと安定性

四六時中PCを利用しているエンジニアにとってキーボードの安定性はとても重要です。 HHKBやRealForceのようなキーボードをエンジニアが評価する一因はその高い安定性にあります。

先述の追加パーツのデメリットで最も痛かったのはその重要な安定性が損なわれたことでした。

Bluetoothの問題

最初に問題が発生し始めたのはBluetooth接続です。職場では多くのPCが使われておりBluetooth接続も沢山の人が使っているためか接続がまったく安定しませんでした。一方自宅では電波の問題はないものの今度はlinux OSとの相性が悪く定期的にbluetoothdが死ぬという現象に遭遇します。一般に市販されているlogicoolのキーボードならlinuxとつないでも一切問題が出なかったのでおそらくBMPのソフトウェア側の問題だと思われます*1。

コンスルーの問題

そこでやむなくUSBケーブルに接続方法を切り替えたのですが次に出てきたのがコンスルーの浮き問題でした。USBのソケットがテーブルから5 ~ 10mm程度浮いていることもありケーブルの自重で斜めの力が働いた結果、Pro Microの奥の方が持ち上がる力が働いてしまいます。キーボードの移動などを繰り返すとこの力が繰り返し働き、ついにはソケットからコンスルーが浮いてしまいキー入力が正常に処理されなくなってしまいました*2。

キースイッチのソケット化の問題

それらと平行して問題となったのがキースイッチの抜け問題です。左上のEscapeキーなど斜めに力が入りやすく隣が埋まっていないキーへ過度に斜めの力が入ると簡単に抜けてしまいました。また打鍵感自体も悪く少しぐらつくような感触があります。 これはスイッチをはめているアクリルなどの精度にもよるところではあるかもしれませんが、剛性の意味ではソケットではなく直接はんだ付けされている方がよいように感じました。

まとめ

実は僕にとってはどの追加パーツもある意味安定性を求めての導入でした。

• Bluetooth化: ケーブルという物理デバイスを使わないことによる故障箇所の削減
• ソケット化: 故障時速やかに交換可能とすることで可用性を高める
• LED: 活用したいと思ったときにあとから追加するのは大変なので先にやっておく

それが逆に安定性を損なう側面があったというのが今回の学びでした。 その学びを持って自作キーボード界隈を見ると高度な技術を持った人が以外とソケット・Bluetoothなどを使っていないことに気づきます。こういった方たちは同様の経験をしたことがあるか、直感的に安定性へ悪影響があることを気づいていて使用していないのかもしれません。

今、一旦原点に立ち返って多少の不便を受け入れつつ最小パーツで自作キーボードを作っています。

*1:もっとも世界へ広く市販されている枯れた製品とDIYで実験的に使用されるBMPでは期待される品質は大きく違うためBMPを攻めるのは間違っている気はします

*2:ちなみにコンスルー周りが原因だと特定するまではとても苦労しました。ピンによって接続されていたりされていなかったりするのでとても変な挙動をしており、最初はソフトウェアの問題かと疑いました。最終的に原因を特定するまで2週間ぐらいかかったと思います

自作キーボード沼マップ作りました

先日、珍しく同僚とお酒を飲んでいるときに自作キーボードの世界にもいろいろな沼があるんだよという話になりました。 実際一言で自作キーボード沼と言っても様々な分野があり、沼にハマっていると言ってもお隣さんとは全く別のことをしているということが結構あります。そこで全体を見渡してどのような沼があるのか一度書き出してみました。

キーボード沼マップ v1.0できました！ #自作キーボードhttps://t.co/4Re70dbWFH

貴重な日曜日の午後を何に使っているんだ... pic.twitter.com/xuAS7oGVbt

— 🤓k.bigwheel🤓 SREエンジニア@Speee株式会社 (@k_bigwheel) December 6, 2020

twitter上でも結構反応をもらえて嬉しかったです。 一方ですぐにいろいろ書き足りないところが見えてきてたくさん追記しています。 たぶんこれからもたくさん出てくると思うので随時書き足していきたいと思います。

日本語入力切り替えストレスの少ないキーマップを定義した

週末このハイカロリーなブログを書いていたので今回は軽めで。

オフィスで活きる自作キーボードのメリットと自作せずにそれを実現する方法 - Speee DEVELOPER BLOG

日本語入力時のストレス

日本語入力時のストレスってなんでしょう?賢くない変換?文節の切れる点が間違っている?それもストレスだと思いますが僕は日本語入力有効な状態で記号キーや数字キーを押して全角で入ってしまった瞬間だと思っています。 特に僕は普段vimを使っているのですが、コマンドラインモードに入ろうとして全角の ： が入る瞬間は最も憂鬱な瞬間です。日本語大好きな僕でも流石にこんなことが数年も続くと日本語嫌いになりそうです。

僕らエンジニアは英語入力と日本語入力をよく切り替えます。というのは主として入力するプログラミング言語が英語だからです。一方コメントやドキュメントは会社にもよりますが日本語で書くことが多いです。

しかし、よく考えると全角つまり日本語入力モードONの状態で数字や記号を入力することはめったにありません。例外は ー 、 。 ぐらいのものです。ならそもそも日本語入力がONであろうが数字キーや記号キーを押したときは無条件で日本語入力をOFFにして入力したらいいのでは?そう思って作ってみたのが今回のキーマップです。

数字・記号絶対半角で入力するマンキーマップ

完成品はこちらです(BLE Micro Pro用のコードなので汎用のqmk firmwareにはちょっとそのままでは動かないかもしれません)。 qmk_firmware/keymap.c at d3408a2cf1d6d39d6891d555b1a999e6191ae198 · bigwheel/qmk_firmware

正確に書くとprocess_record_userでキーコードの処理を改変しているだけなのでキーマップ、いわゆる論理配列はどんなものでも対応できます。

const uint16_t leave_ime_on_keys[] = {
  // https://beta.docs.qmk.fm/using-qmk/simple-keycodes/keycodes_basic#letters-and-numbers
  KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0,
  KC_ESCAPE,
  // KC_MINUS,
  KC_EQUAL,
  ...
  KC_QUESTION
};

const uint16_t leave_ime_on_keys_with_shift[] = {
  // https://beta.docs.qmk.fm/using-qmk/simple-keycodes/keycodes_basic#letters-and-numbers
  KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0,
  KC_ESCAPE,
  ...
  KC_QUESTION
};

bool process_record_user(uint16_t keycode, keyrecord_t *record) {

  ...

    bool leave_ime_on = false;
    for (int i = 0; i < length_of_leave_ime_on_keys; i++)
      if (leave_ime_on_keys[i] == keycode) {
        leave_ime_on = true;
        break;
      }

    if (get_mods() & MOD_MASK_SHIFT)
      for (int i = 0; i < length_of_leave_ime_on_keys_with_shift; i++)
        if (leave_ime_on_keys_with_shift[i] == keycode) {
          leave_ime_on = true;
          break;
        }

    if (leave_ime_on && record->event.pressed) {
      uint8_t real_mods_memory = get_mods();
      clear_mods();
      off_ime();
      set_mods(real_mods_memory);
    }

  return PROCESS_USUAL_BEHAVIOR;
}

アイデアは死ぬほどシンプルで、記号キーが押された場合はその前に必ず無変換キー(PCモードの場合)または英数キー(Macモードの場合)を先行して入力するだけです。いわば、数字・記号キーすべてを2ストロークのマクロ化して、本来のキー入力の前に日本語入力OFFキーを入力するようにした感じです。

追加でしている工夫としては、これだけだと全角の記号などが一切入力できなくなりこれだと困るケースもあるためカスタムキーコードとして KC_DISPEL というものを定義しています。これを押している間は上記の日本語入力無条件OFF挙動がキャンセルされます。

まとめ

このキーマップで一週間程度使い続けているのですがかなりいい感じです。 特にコーディング中、日本語入力ONのまま記号やアルファベットを入力しようとしてしまいBackSpace, 日本語入力ONキー, 本来入れたかったキーを押すの流れが完全になくなりました。 このまましばらく様子を見て、問題なさそうであれば持っているキーボード全てへ展開する予定です。