マンションの換気ダクトと塗装ブースのホースを直結できる部品を3Dプリンタで作った
省エネ記事。
最初のアイデアはAmazon | 排気ホース・集合ダクト【補強 タミヤ塗装ブース・ツインファンの2本のホースを連結して1本に (タミヤホース) | ペインティングスタンド・ブース 通販から。
しかし、そのためにはCADでモデルを作らないといけない。 Fusion 360を使うかFreeCADを使うか、つまりwindowsをやむなく使うかlinuxでも使えるソフトウェアを使うか3日悩んで、ユーザビリティに劣るとしても長期的には価値が高いと判断したFreeCADを使うことにした。 ちなみにこの判断はあとで大正解だったと感じた。確かにわかりやすくはなかったがyoutubeなどに解説動画も多くあり、やりたいことができないことはなかった。これでwindowsの呪縛から逃れられるなら多少の不便は許容できる。
というわけで早速試しに設置してみたのだがとてもよかった。 かかった費用はフィラメント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、僕は会社で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 第3世代
それぞれ3千円と200円で購入。 最初は音声制御がそんなに便利か懐疑的だったが、認識の精度が高いこと(体感成功率は9割以上)、ほぼすべての家電の制御をalexaに一元化したことによる便利さから今ではなくてはならないものに。地味にキッチンタイマーとしても便利。あといつもと違う時間に起きる必要があるときに一回限りの目覚ましをセットするのも良い。
コスパ★☆☆ Nature Remo mini
2018/10に1万円で購入。 これ一つでエアコン、テレビ、リビング照明、PCモニタを制御。 Alexaと一緒でないとあんまり便利でない点、今ならswitchbotなどが半額以下で同様の製品を出していることからコスパは悪目。
コスパ★★☆ SwitchBot Hub Mini
2021/06に約3千円で購入。 SwitchBotカーテンは単体ではAlexaに繋げないため、音声制御するのはこれが必要になる。 Nature Remoと役割がかぶっているためうちでは残念感があるが、それがないなら十分コスパは良い。
照明
コスパ★★★ LED電球 広配光タイプ 人感センサー付き 明暗センサー
コスパ★★★ アイリスオーヤマ LED電球 人感センサー付
それぞれ1個1,200円程度で購入。 まずいちいちスイッチを入れなくていいので便利。トイレにつけると衛生的にも良い。また消し忘れを消しに行くだるさもなくなる。 コスパはとても良い。
コスパ★★☆ リモコン制御照明(リビング組み込み、ブランド不明)
マンション組み込みのリモコン制御照明。 Nature Remoで制御している。特に寝るときベッドにいながら「Alexa、照明を消して」といえば消せるのが最高。安くない家賃の幾分かはこういったところの評価なのだろうけど、結構満足している。
コスパ★★☆ SwitchBot カーテン
2021/06に9,000円で購入。 朝日で起きると快適に起床できることに気づいたため導入。まだ数日しか使っていないがスムーズに動いている。 値段は高いが睡眠と起床はQoLに直結するので評価は高い。
白物家電
コスパ★★★ 日立 ドラム式洗濯機 BD-SG100FL-W
2021/04に約16万円で購入。 洗濯が苦でなくなった。干す手間が要らなくなっただけではなく、物干し竿やハンガー、ピンチなど干すための道具やそれを置く空間、干しておく場所などがすべて不要になり部屋が広くなった。 洗濯頻度が4,5日に一度から3日に一度になり衛生的にも良くなった気がする。
コスパ★★★★ Panasonic 食器洗い乾燥機 NP-TCM2-W
2020/01に中古で23,000円にて購入(分配器込み)。 一人暮らしを始めた瞬間に買っておけば良かったと思う家電筆頭。 これによりシンクに使用済み食器を貯めることがなくなり、料理が楽しくなった。 自分は料理が嫌いなのではなく料理の後片付けが嫌いなだけなことに気づいた。
グリルの網や受け皿、フライパン、ボールまでまるごと入れて実行している。 日によっては2回実行するほど多用している。
その他家電
コスパ★★★★ DEEBOT ロボット掃除機 N79T
2018/11に26,000円で購入。 いわゆるルンバコピー。値段は1/4だが十分に機能してくれてほぼ毎日稼働しつつそろそろ2.5年が経とうとしている。頑丈でまだまだ壊れる気配はない。 特に自分が不在の平日昼間に掃除してくれるのが最高で、掃除機のあの騒音なしに床がきれいになる。
コスパ★☆☆ TP-Link WiFiスマートプラグ
2019年8月に4,000円で購入。 扇風機や電気ストーブに接続して使用。 アイデアとしては至極全うで便利なのだけどこの製品に関しては残念なことに製品の品質が低かった。 まず、alexaとの接続がしょっちゅう切れる。wifiでalexaと接続されており中継器などいらない点は良いのだけど3割ぐらいの確率でalexaからアクセスしても応答がない。ファームウェアをアップデートなどしても改善しない。また、電源プラグの形が左右で違い、片方が縦に長い形になっている。これにより延長コードなどによっては刺さらないケースがある。実際うちの延長コードなどにはほとんど刺さらなかったため対応したケーブルを見つけるのに苦労した。
コスパ★★☆ FLEXISPOT EF1
2021年10月に購入。 組み立てめっちゃ大変だった。 単純に机が追加されたことがQoLを上げた。
立って作業する時間はだんだん減って、最近だと10%ぐらい。ただ、立ち上がる習慣がついた気はする。
購入検討中の家電
スマートロック
便利だが、そもそもマンションの入口で物理鍵を使う必要があるためどちらにしろ物理鍵を持ち歩く必要がある。そのためこれだけ導入してもメリットが薄い。
Echo Show
Echoは使い倒していてタダならほしいが、現状モニタによるメリットが不明瞭で購入に踏み切っていない。
自作キーボードの追加パーツのデメリットの話
tl;dr
- より多くの機能があったほうが良いと思って追加パーツをたくさん使っていたよ
- 結果、キーボードがハードウェア的/ソフトウェア的にとても不安定になってしまったよ
- 機能を盛ったほうが良いというものではないという学びがあったよ
- 今は安定したキーボードを求めて使うパーツを限定し始めたよ
追加パーツの代償
自作キーボードを初めて半年、基本的にメンタリティが男の子なのもあって使用可能なオプションはすべて使用してきました。主に以下などです。
最初パーツを追加する限りは特にデメリットはないと思っていたんですが、数ヶ月続けていくうちにどれもデメリットが見えてきました。
機能 | デメリット |
---|---|
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などを使っていないことに気づきます。こういった方たちは同様の経験をしたことがあるか、直感的に安定性へ悪影響があることを気づいていて使用していないのかもしれません。
今、一旦原点に立ち返って多少の不便を受け入れつつ最小パーツで自作キーボードを作っています。
自作キーボード沼マップ作りました
先日、珍しく同僚とお酒を飲んでいるときに自作キーボードの世界にもいろいろな沼があるんだよという話になりました。 実際一言で自作キーボード沼と言っても様々な分野があり、沼にハマっていると言ってもお隣さんとは全く別のことをしているということが結構あります。そこで全体を見渡してどのような沼があるのか一度書き出してみました。
キーボード沼マップ v1.0できました! #自作キーボードhttps://t.co/4Re70dbWFH
— 🤓k.bigwheel🤓 SREエンジニア@Speee株式会社 (@k_bigwheel) December 6, 2020
貴重な日曜日の午後を何に使っているんだ... pic.twitter.com/xuAS7oGVbt
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キー, 本来入れたかったキーを押すの流れが完全になくなりました。 このまましばらく様子を見て、問題なさそうであれば持っているキーボード全てへ展開する予定です。