なんか書いていこうぜー .com

Let's write something good

キーボードのキー数を減らした

2021-07-15
  • Share on Facebook
  • Tweet
  • Add to Pocket

以前は Zinc を使っていたが、もう少しキー数を減らせるかも? と思って探していたところ、私が使えそうなキーボードである REVIUNG41 をみつけたので、今はこれを使っている。

なぜキー数を減らしたいのか?

手の移動距離を減らせそうであることと、小さいほうがキーボードを移動させるときに便利であることが理由である。小さいと必然的にキー数が減るのだ。

ただ条件があり、Linux の i3wm のメタキー、ショートカットキーを使いこなせる程度のキー数、キー配置が必要なのだ。この条件をクリアしつつ、キー数が少ないものを選ぶ必要があった。

REVIUNG41 にした決め手は?

分割キーボードっぽい配置であること、アルファベットキーの外側に一列キーがあること、キー間が狭いことがある。

分割キーボードっぽい配置であること

今はすっかり分割キーボード派である。完全な一体型には戻れる気がしないが、REVIUNG シリーズはエルゴノミックキーボードみたいになっており、末広がりな配置になっていて分割キーボードに近い配置になっているため、違和感が少ない。

また、これまでは raw staggered 派だったのであるが、この末広がり状に配置されていることにより苦手な column staggered タイプでも違和感少なくタイピングができている。

そのままではキーボード上部に配置されているキーとの距離が遠いため、上部の底に足をつけて高くしてキーとの距離を短くしている。これがあるとないとでは、E や R、I への指の届き方が違うので、角度はキーが見えるかどうかだけの差しかない、とか言う説は私の中では却下されている。

アルファベットキーの外側に一列キーがあること

Tab キーや Del キーがある列がないと、個人的に違和感がありすぎて慣れない。これは以前チャレンジしたが克服できなかった。

REVIUNG41 はその外側の列のキーが 3 行しかないが、Zinc で使っていたキーマッピングを少し変える程度でなんとかなりそうだったので、採用している。

キー間が狭いこと

Zinc の配置に慣れた身体だと、Ergotonic49 を使ってみるとキー間がちょっと空きすぎて違和感があったため、よりキー間が詰まっているものを探した。

元々がノート PC を使っていたこともあり、変にキー間が空いているよりは詰まっていたほうが違和感が少なく、このほうが馴染む。

どんなキーマップで使っているのか

今は以下の配置にしている。ほとんど Zinc を使っていたときと変わっていない。

BASE の Tab キーが Shift、MO(LO) + Tab でタブにしているのを、Zinc を使っていたときと同じように逆にしようかどうかで悩んでいる。

BASE
 ,-----------------------------------------.             ,-----------------------------------------.
 | Shift|   Q  |   W  |   E  |   R  |   T  |             |   Y  |   U  |   I  |   O  |   P  | Bksp |
 |------+------+------+------+------+------|             |------+------+------+------+------+------|
 |CTL_ESC|  A  |   S  |   D  |   F  |   G  |             |   H  |   J  |   K  |   L  |   ;  |  '   |
 |------+------+------+------+------+------|             |------+------+------+------+------+------|
 | ALT  |   Z  |   X  |   C  |   V  |   B  |             |   N  |   M  |   ,  |   .  |   /  |Enter |
 |------+------+------+------+------+------|-------------|------+------+------+------+------+------|
                             | WIN  |MO(RA)|   Space     |MO(LO)|Shift |
                             '-------------'-------------'-------------'
 ※ CTL_ESC は QMK でいう、LCTL_T(KC_ESC)


LOWER
 ,-----------------------------------------.             ,-----------------------------------------.
 | Tab  |   !  |   @  |   #  |   $  |   %  |             |PageUP| Home |  UP  | End  | ESC  | Del  |
 ,-----------------------------------------.             |------+------+------+------+------+------|
 |CTL_ESC|  &  |   ^  |   (  |   )  |  _   |             |PageDN| LEFT | DOWN | RIGHT|      | PSCR |
 |------+------+------+------+------+------|             |------+------+------+------+------+------|
 | ALT  |   \  |   +  |   *  |   /  |  =   |             |  [   |  ]   |  (   |   )  |   -  |Enter |
 |------+------+------+------+------+------|-------------|------+------+------+------+------+------|
                             | WIN  |MO(RA)|   Space     |MO(LO)|Shift |
                             '-------------'-------------'-------------'
RAISE
 ,-----------------------------------------.             ,-----------------------------------------.
 | Tab  |   1  |   2  |   3  |   4  |   5  |             |  F1  |  F2  |  F3  |  F4  |  F5  | Del  |
 |------+------+------+------+------+------|             |------+------+------+------+------+------|
 |CTL_ESC|  6  |   7  |   8  |   9  |   0  |             |  F6  |  F7  |  F8  |  F9  |  F10 | F11  |
 |------+------+------+------+------+------|             |------+------+------+------+------+------|
 | ALT  | RESET|      |      |  `   |   -  |             |  F12 |CTRL-Q|      |      | RESET|Enter |
 |------+------+------+------+------+------|-------------|------+------+------+------+------+------|
                             | WIN  |MO(RA)|   Space     |MO(LO)|Shift |
                             '-------------'-------------'-------------'
 ※ CTRL-Q は私の環境では tmux の prefix で、MO(RA) + CTRL-Q と MO(RA) + q(つまり 1) で
    指定の数字のウインドウに移動しやすくしている

さいごに

REVIUNG41、なかなかよく、前に使っていた Zinc との違和感も少なく移行できた。指の移動も少なくいい感じである。

キーのマッピングは変えるかもしれないが、しばらくはこの形でいきそう。

Blue Yeti Nanoを使う際に気をつけたい点

2021-02-17
  • Share on Facebook
  • Tweet
  • Add to Pocket

説明書にも書かれていなかった気がしたので、ここに記しておく。

Blue Yeti Nano とは

https://www.bluemic.com/ja-jp/products/yeti-nano/ これです。

私はこれを主に Linux 機に接続して使用しています。

背面にある パターンセレクタ について

パターンセレクタは、指向性の変更のために使うボタンである。正面からの音を中心に拾うのか、全体から音を拾うのか切り替えることができる。

このボタンが指向性の切り替えのためだけにあると思っていたのであるが、ヘッドフォン出力からの音の ON/OFF を切り替える機能もある みたいだ。 長押しすると、正面のボタンが LED がちらちら光ってヘッドフォン出力からの音を拾ったり、ミュートさせたりというのができる。

ヘッドフォン出力からの音が聞こえない場合、「Yeti Nano Linux」などのワードでググると、alsamixer コマンドで「再生」の音量を調整することで聞こえるようになるよ、とのコメントを見るが、パターンセレクタボタンの長押しはハードウェアミュートになるっぽく、alsamixer で見た数値は十分に聞こえるものであっても全く何も聞こえてこないので注意が必要だ。

そういうときは、パターンセレクタを長押ししてみよう。

まとめ

Blue Yeti Nano を使っていて、ヘッドフォン出力から音が聞こえなくなった!と思ったら、パターンセレクトボタンを長押ししてみよう。

それでも聞こえないなら、alsamixer の Yeti Nano の設定を確認し、再生の音量を調整してみよう。

S3 のリダイレクト設定を見直した

2021-02-16
  • Share on Facebook
  • Tweet
  • Add to Pocket

きっかけ

このサイトに Google カスタムサーチを設定して数ヶ月、うまく動作していなかったので、原因を探ることにした。 たまたま AWS から S3 関連の通知がきていて、そういえば……と思い出したので重い腰を上げてみた。

調べた経路

Google カスタムサーチの設定がうまくいっていないのか?と思い、色々見直していると、Google SearchConsole を見ろと表示されたので観に行った。

Google SearchConsole のカバレッジをみると、どうやら大半が除外されているみたい。 詳細を見に行くと、Googlebot さんがクロールできていないことがわかった。つまり、検索インデックスが作成できていないようだった。

そのクロールできていない原因なのであるが、個別のページにアクセスするとルートにリダイレクトされてしまっているようで、そのため個別ページのインデックスが作成できていないらしい。

ローカルで動かしている分にはリダイレクトされない。そうなると、S3 か CloudFront のどちらかになる。CloudFront は個別のリダイレクト設定はないはずと思い、S3 の設定をみるとリダイレクト設定があったので、設定をまるごと消した。なくてもよさそうな設定であった。

どうやらクロールされ始めたっぽいので、これが根本の原因だったらしい。

本当の原因

gatsby-node.js にある createRedirect の設定がどうやら gatsby-plugin-s3 によって S3 の設定に作用するみたいで、コードを削除して deploy したら、設定が S3 に反映されなくなった。個別ページの URL を直に叩いてもルートにリダイレクトされないようになった。

クロールが終わって完全にサイト内検索ができるようになるのはいつになるのかわからないけれども、これでまともに動くようになればいいな。

2020年のふりかえり

2020-12-31
  • Share on Facebook
  • Tweet
  • Add to Pocket

2020 年やったこと(順番はテキトー)

  • BuriKaigi2020 で発表した
  • i3wm と polybar に乗り換えた
  • 自作 PC を組み立てた
  • 自作キーボードを組み立てた
  • 肉を買って焼くようになった
  • 通信制大学に入学、課題をするようになった
  • Kanazawa.rb にはだいたい出没した
  • 作業場所の設備を整えた
  • 齢が次の代に移った
  • 健康診断で初胃カメラを飲んだ
  • 家族 PC の入れ替え

2020年感想

BuriKaigi2020 で代打発表してからこんなことになるとは思わなかったコロナ禍2020年。引きこもってできる実用的な趣味を試した年であった。

自作 PC は知識ゼロからやったので楽しかったが構成を頻繁にはかえないので今は落ち着いていて、自作キーボードはまだいろいろといじりがいはありそうな感じ。お肉は美味しく焼けると嬉しいのでまだまだ続きそう。

真面目に勉強しようと通信制大学に入学したもののなかなかキツイので、これをどう乗り越えていくかが生活の鍵になりそう。

実際のところ、今年は前半で結構な燃え尽きがあったので、散財してストレス発散で復活とおもったが、あまりうまくいっていない気がするので、なんとかならんかなというところ。

2021年

  • エディタについて学ぶ
  • 面倒くさいことを 1 つは実行する
  • 過去やったことをもう一回やってみる

Ruby の Curses::Window#refresh と Curses::Window#noutrefresh の違い

2020-10-12
  • Share on Facebook
  • Tweet
  • Add to Pocket

最近 Ruby の curses を使って遊ぶことがあり、その中で Curses::Window#refreshCurses::Window#noutrefresh の違いがよくわからなかったので、ドキュメントを探していた。

日本語で探すと るりま が検索にかかるが、最新とは内容が離れているのでメモemoji-memoとして残しておく。

Ruby の curses のドキュメント

curses は Ruby 2.1.0 から標準ライブラリから切り出されて独立した gem になっている。see: https://github.com/ruby/curses#description

切り出されたことにより、curses のるりまは 1.8.7 の library curses でなくなって?おり、ruby/curses の README の Documentation にあるように www.rubydoc.info にあるものが最新を追随している公式ドキュメントになっている。

1.8.7 標準添付の curses から 現在の v1.3.2 までの間に API も増えているため、残念ながら 1.8.7 の情報では現在の curses を扱うのは難しい。

physical screen と virtual screen

Python の curses のドキュメント https://docs.python.org/3.5/library/curses.html はより詳細に説明が記載されており、physical screen と virtual screen という語を使って説明されていた。日本語版もあるが、単語が明確に分けて使われている英語のほうのドキュメントがおすすめである。

実際に私たちに見えるのは physical screen で、見えていないが変更内容を保持しているのが virtual screen である。virtual screen に対して変更したものを physical screen に同期するようなかたちで更新し、physical screen に反映して表示する仕組みとなっている模様だ。

尚、Curses.doupdate というメソッドが用意されており、これにより強制的に physical screen を更新することができる。

Curses::Window#refresh と Curses::Window#noutrefresh の違い

さて、本題である。

https://www.rubydoc.info/gems/curses/Curses/Window をみると、どちらも Curses::Window に設定した内容を更新するメソッドで、両メソッドの説明には Refresh the windows and lines. とある。

Curses::Window#noutrefresh は加えて、Curses::Window.noutrefresh allows multiple updates with more efficiency than Curses::Window.refresh alone. と書いてあるので、複数 Window がある場合に効率的に処理できるらしい。

Curses::Window#refresh

Curses::Window#refresh は、指定された Curses::Window の設定内容を virtual screen、physical screen の両方に反映するようだ。つまり、実行されると更新されたものが私たちに見えるようになる。

Curses::Window#noutrefresh

一方で、Curses::Window#noutrefresh は指定された Curses::Window に設定した内容を virtual screen にのみ反映するようだ。この段階では私たちに変更は見えない。 これを physical screen に反映するには Curses.doupdate を呼び出す必要がある。こうすることで、virtual screen の内容が physical screen に反映される。

先に書かれている “効率的” というのは、Curses.doupdate が存在する Curses::Window すべての virtual screen の内容を physical screen に反映するためだ。Curses::Window#refresh は 1 つの Curses::Window に対して Curses::Window#noutrefreshCurses.doupdate を実行しているようなものなので、こちらを使ったほうが確かに効率的だ。

まとめ

Python のドキュメントのちからを借りつつ、Curses::Window#refreshCurses::Window#noutrefresh の違いを確認した。

  • Curses::Window#refresh
    • 1 つの Curses::Window に対して、virtual screen, physical screen 両方を更新する
  • Curses::Window#noutrefresh
    • 1 つの Curses::Window に対して、virtual screen のみを更新する
    • physical screen を更新するには Curses.doupdate を呼ぶ必要がある
    • Curses.doupdate はすべての virtual screen を physical screen に反映するので複数 window がある場合はこちらを使うのが効率的である

ruby/curses のメンテをしている shugo さんの作っている Textbringer の window クラス が同様の使い方をしているので合っているはず。