Hika Hibariya

TOEIC 第211回 の受験記録

今回がはじめて。一生受けないだろうと思っていたけど考え直して 6/26 に受けてきた。 2.5時間も拘束されるのとマークシートがけっこう辛くて、受けるたびにそれなりの覚悟が必要な印象。 事前に 公式の練習テスト をやっておいたので試験の内容自体は落ち着いてこなせた。 試験はモノサシとして便利だし、ある程度のスコアを取れば単位認定もされて便利なのでこれからもたまに受けようかな。

(追記) そのあと結果が来て、リスニング410のリーディング395で合計805点だった。単位認定に必要なのは750点だったので嬉しい。

KinesisをDvorak配列にした

今年の始めごろに、坂村健さんの 痛快!コンピュータ学 を読んでいて、Dvorak 配列に移行したくなった。 効率とか健康とかもあるんだけど、一番のモチベーションは「慣れ親しんだものから離れてみたい」というぼんやりしたもの。 休日に少しずつ始めてから半年ほど経ち、今では日常生活に困らないくらいには慣れてきている。

移行していちばん実感しているのは、落ち着いて文字を打てているという感覚。 以前よりも手首や掌全体の動きがやや少なくなった気がする。 もしかすると、自分の場合はタイピングにもともと我流な部分があったのでこの機会に矯正されたという面もあるかもしれない。

Dvorak配列へ移行するためにやった練習方法は単純で、Dvorak keyboard training を英語モードにしてひたすら単語を入力するというもの。 5分で100単語くらい入力できるようになるまで機械的に続けた。 そうして単語を打てるようになってもショートカットキーの組み合せは指がおぼえてしまっているので始めのうちはシェルの操作も思うようにできない。 vim 使いはvimtutorを一回やると少しは楽になれるかもしれない。 やった練習としてはこれくらいで、あとはぎぎぎ歯をくいしばって使い続けた。

配列を変えたのはメインのキーボードとして使っている Kinesis (Advantage USB Contoured Keyboard) だけで、ラップトップは QWERTY のままにして使っている。 単に設定が面倒だからというのが本音だけど、もしかしたら良い面もあるかもしれない。 というのは、席を離れたときには QWERTY を使う必要があるので、そのおかげか両方の配列を行き来できる状態を維持できているのだった。

pty-shell でシェルを操作する

以前、PTY を使ってシェルの入出力を好きなようにする 方法を調べて、それを Rust でやるために pty という crate を作っ た。この pty を使ってこれまでに hokaido のようなターミナル共有ツールとか シェルへの入力をどこかへ通知するツール を作った。

これらには「ターミナルを立ち上げてその入出力をフックする」という共通の処理がある。けれど pty が用意している pty::fork() は、新しい疑似端末 (PTY) を割り付けた子プロセスを生成するだけだ。実際には他にも必要な処理がある。

  • 子プロセスの制御端末に適切な画面サイズを設定する。
  • 標準入力を子プロセスへ即座に伝えるため、親プロセスの制御端末を raw モードにする。
  • 親プロセスへの入力を子プロセスの標準入力に送り、子プロセスの出力を親プロセスの標準出力に送る。
  • 子プロセスでシェルを起動する。

意味もなく同じコードを何度も書くのはつらい。とはいえこれら一連の処理は、pty crate として用意するには少し具体的すぎる気がする。そういうわけで、シェルに特化した拡張という意味で pty-shell という crate をもうひとつ用意した。

hibariya/pty-shell

pty-shell は「ターミナルを立ち上げてその入出力をフックする」ための簡単な方法を提供する。 具体的には子プロセスとしてシェルを起動し、親プロセスの入出力を子プロセスのシェルにプロキシする。

反応しない練習 を読んだ

それほど長くないのと文章も読みやすかったので、空いた時間でぱらぱらめくっているうちに読み終わってしまった。 何かを見聞きするたびに動揺していては、なかなか目の前のことに集中できなくて困ってしまう。 ムダな反応をしないとはどういうことか、上手にそれをするためにはどうすればいいのか、この本は原始仏教の教えを噛み砕いて説明している。 自分は仏教そのものをよく知らないのでそういう意味でも興味深かった。

エリック・エヴァンスのドメイン駆動設計 を読んだ

良い設計がしたい。@tkywtnb からお借りした PofEAA の中にこの本への言及があって、本から本へ移動する感じで読みはじめた。

全体的には4部構成で、ドメイン駆動設計を構成するパターンやなぜドメインモデルが重要なのかについて詳しく説明されている。 個人的な収穫は、説明のため簡単にされているとはいえ現実に使われているモデルがチームによって次第に改善されていく様子をいくつか見学できたことだ。それに、これまで知らなかった「仕様」というパターンにも出会えた (気に入ってる)。

まえがきにある通り、この本は好きな場所から読んでも良い構造になっていた。けれどこの本にはドメイン駆動設計のパターンが体系的にまとめられているだけでなく、著者のかかわったいくつかのプロジェクトがどのように始まり、その後どのような道を辿ったかという長い物語としての側面もある。だから、もし時間があるのならば始めから順番に読んでいって、最後にエピローグを読むのが良いと思う。