Ergodoxを最上段を使わないキー配置にしてみる
いまはErgodox EZを会社で使ってるのだけど、レツプリ組み立てを視野に入れて、最上段がなくてもやっていけるかどうかを試してみている。いま現在のキー配置はこれ。
ポイントをいくつか解説する。
レイヤー
BASE, SYMB, MDIAの3レイヤー構成だったのを、LOWERとRAISEを足して5レイヤー構成にしている。ただSYMBはもう使わない予定で、MDIAも音量操作くらいでしか使わないので、実質的には3レイヤーに近い。
いまはErgodox EZを会社で使ってるのだけど、レツプリ組み立てを視野に入れて、最上段がなくてもやっていけるかどうかを試してみている。いま現在のキー配置はこれ。
ポイントをいくつか解説する。
BASE, SYMB, MDIAの3レイヤー構成だったのを、LOWERとRAISEを足して5レイヤー構成にしている。ただSYMBはもう使わない予定で、MDIAも音量操作くらいでしか使わないので、実質的には3レイヤーに近い。
メモです。
MacのCmd-Shift-4
でキャプチャしたpngをブログに貼ろうとすると、想定の2倍のサイズになってしまうことがあります。
ImageMagickのidentify -verbose foo.png
で見てみるとUnitsがPixelsPerCentimeter、Resolutionが56.69四方なので、2.54倍してDPI(=Dots per Inch)に直すと143.9926DPIですね。
ということでImageMagickのconvertで以下のようにして修正すれば良いのかな?
for a in *.png; convert $a -resample 72x72 -units PixelsPerInch tmp/$a
メモです。
Opalでプログラムを書いているとき、例外のバックトレースが開発者コンソール上で綺麗に表示されるときとそうでないときがあるので困っている。
綺麗ってなんやねんという話ですけど、こういうのが綺麗な状態です。
それで望ましくない状態がこれ。
Twitterの#レツプリというタグから、キーボード自作に興味を持った。ものによってはキットがあって、はんだ付け等で組み立てできるらしい。
形状にもいろいろあるようなので調べたものをまとめておく。
いま会社で使ってるやつ。これはErgodox EZで組み立て済みのものを購入したのだが、もともとのErgodox自体はオープンソースのハードウェアである。
形状は左右分離タイプ。キー数は普通のキーボードより少ない(例えばPの右に1列しかないとか)。
仕事で、GitHub Wikiに書いた表をExcelにしたいというシチュエーションがあったので、簡単なRubyスクリプトを書いた。
実行にはNokogiriが必要 (gem install nokogiri
)。ブラウザでWikiページをa.htmlという名前で保存したものとする。
require 'nokogiri'
require 'csv'
# a.htmlというファイルを読み込んでNokogiriのオブジェクトに変換する
doc = Nokogiri::HTML.parse(File.read("a.html"))
バグ修正がたまっていたのでリリースした。
https://github.com/biwascheme/biwascheme/releases/tag/0.6.8
このあと7月、8月はRubyKaigiの準備をします。
とある映画の日本語字幕で、
コンピュータの天才
9つのC言語を操る
というものがあるらしい(画像はググってください)。原文はnine conputer languagesらしいので、翻訳者がC言語のことをコンピュータ言語の略だと勘違いしたのだと思われるけど、C言語を知っている人から見ればなかなかに味わい深いフレーズである。
yhara [4:39 PM]
ergodoxの調子が悪くてやばい
Oが1/3くらいの確率でしか入らない
tも怪しい
ということは物理レイヤの問題ではない??
Lもだめだな
という感じだったのだけど、久しぶりにファームウェアをgit pullして更新したら現象が直った。
ブログのトップページが重いなと思っていたので、長いエントリは冒頭だけ表示するようにした。いわゆる「続きを読む」機能である。
「続きを読む」を実装する場合、エントリのどこまでを冒頭と判定するかが問題になる。ブログエンジンによってはエントリ内に特殊な記号を記入することで「続きを読む」の位置を明示するものもあるけれど、いちいち書くのも面倒なので避けたかった。適当によしなにやってほしい。
ということで今回実装したアルゴリズムが以下。
充分短い、の定義は最初は10行以内としていたけど、これだと11行のエントリがあったときも「続きを読む」が表示されて、クリックすると1行増えるだけなので微妙だった。そこで、「何行に丸めるか」と「何行までなら全文表示するか」の行数を別にすることでいい感じになった。
ちなみにこの方法だとcode blockをまたいでしまう可能性があるけど、redcarpet gemだとcode blockが閉じられていない場合は最後までがcode blockだと判断してくれるようで、特に対処は必要なかった。
趣味で書いてるコードのうち、規模が小さいものはCHANGELOGを書いてなかったのだけど、最近は書くようになった。
前までやっていなかったのは面倒だというのが理由だけど、実際やってみるとそれほど面倒でもない。むしろ、自分が最近何の作業をしていて、そのうちどれが完成しているとかが分かって便利だ。
変更内容を記録して、溜まったらgitのtagを打って、masterにpushして、みたいなことをしてるとまるで仕事みたいだけど、効率を良くしようとすると、仕事のやり方に近づくのは自然なのかもしれない。趣味とはいえ、効率が良くなればもっと多くのものを作れるようになる(または遊ぶ時間が増える)ので、効率は大事だ。
これは趣味のコードだから雑に作業する、みたいなことをする場合、仕事と趣味で意識を切り替える必要があるけど、ぜんぶ仕事みたいにやることにすれば、切り替えが無くなって、ずっと同じペースで作業できるので良いかもしれない。