カリタ ナイスカットミルの0点調整

最近コーヒー趣味が何度目かの再加熱。 いろいろ試してみたりしている中でなんだかよくわからなくなっていたのがコーヒー豆の挽き方。粒度とも呼ばれているやつ。

家ではカリタのナイスカットミル(Gじゃない初期の方)を使っているのですが、本体で中挽きと書かれている目盛り3とか4にしてもなんだか粗い気がしていました。
好みの味になるまで細挽きにしていくと良いという話も聞いたので、最近は目盛りを2にして使っていました。

このミルはそういうものなのかなぁと不思議に思いつつなんとなくレビュー動画や紹介動画をながめていると、他所のナイスカットミルは同じ設定でもなんだか挽き目が自分のナイスカットミルと違うことに気がつきました。

そして0点調整の紹介を発見……!!

ナイスカットミルを長く使っていると本体ダイアルの目盛りと実際の挽き目がズレてしまうんですね。9年使っていて知りませんでした。説明書は読んだはずなのですっかり忘れてしまっていたのかもしれません。

0点調整自体は

www.youtube.com

tokolog.net

あたりを参考にさせていただきながら調整してみると、なんと3目盛り分もズレていました……。
そりゃあなんだか粗いわけです。1目盛り0.5なので3目盛りズレていると1.5も違います。自分の3は4.5、4は5.5で中粗挽きどころか粗挽きです。使っていた2なら3.5で、そりゃちょうど良さそうな目盛りに。。

ナイスカットミル使っていてなんだか挽き目がおかしいなーと思ったら自分でまた思い出せるように書いて残しておきます。

パームレスト自作した

完成した自作パームレスト

自作といってもやすりかけただけ。


キーボード組み立てたあと、イスの高さやひじ置きの高さをあれこれ試しながら日々暮らしていると、妙な手首の痛さを覚えました……。
へんだな〜おかしいな〜と思いながらもそのままにしておいたところ、手首が曲げられないほどに痛くなり病院へ。腱鞘炎かと思ったら腱鞘ではなく腱そのものが炎症になっているらしく腱炎と診断されました。。

腱鞘炎と同じく、治すには安静しかないそう。とはいえ仕事がらキーボードを使わないというわけにはいきません。手首が曲がった状態だと負荷がかかるそうで、お医者さんにもパームレストリストレスト)をおすすめされました。
しゃーなしでライブで買ったマフラータオルをキーボードと同じような高さになるように畳んで手首の下に敷いてだましだまし仕事をすることにしました。2週間くらいでよほど無理しない限りは痛みを感じないほどに回復。ありがとうサカナクション

タオルでも洗濯できるし柔らないし良いといえば良いんですが、机の上に2組の畳まれたタオルが置いてあるのはなんともテンションが上がりません。そんなとき会社の人から「木製のパームレストはどう?」とおすすめしてもらいました。
ちょうど木製の机を使っていることもあり、木製のパームレストならよく合いそうです。早速その木製パームレストを買おう……と思ったもののなんとも微妙なお値段。いや買っても良いんですが「板やんこんなん」という思いが頭をよぎりました。

ということで、品質とか形にこだわらなければ作れそうなので自作してみました。

まずは採寸。
キーボード、自分のは分割型の Choco60 rev.2 なので左右用で2つと、トラックパッドトラックボールの高さもキーボードと合わせるために載せる台用1つで合計3つ分の採寸をしました。
木材カットで誤差が出るのでそんなに厳密には測りませんが、

  • 左手用
    • 幅 125mm
    • 奥行 100mm
    • 高さ 18mm
  • 右手
    • 幅 155mm
    • 奥行 100mm
    • 高さ 18mm
  • トラックパッド
    • 幅 160mm
    • 奥行 110mm
    • 高さ 18mm

なんとなくの大きさがわかったので、次はコーナンさんに行って木材を物色。
せっかくなのでヒノキとか良い材を使ってみたくもありましたが、あまり大きな店舗ではなかったので取り扱いなし。まあこういうのはいきなり良い材料を使うんじゃなくて、まずは失敗しても諦めのつくお値段の材料にしましょうとワンバーフォーの白木の材にしてみました。ワンバイフォーは規格で約19mm×89mm×2440mmなので、どこでも手に入りやすいです。 しかも398円……安い! 高さ(木材の厚み)がパームレストとしてはけっこう重要かと思うのですが、Choco60 rev.2 はざっくり測って 18mm くらいなのでワンバイフォーの19mmはなんともちょうど良い厚みです。

ワンバイフォー

ワンバイフォー材はそのままだと表面がざらざらで、そのままではちくちくとトゲが刺さりそうです。紙やすりで角をとって表面を仕上げる予定なのでOKとしました。(家にダイソーさんの紙やすりがあったので買いませんでした。)
表面に何か塗るか悩んだのですが、白木のさらさらとした手触りが良さそうだったのでいったん無しにしました。夏が来て暑いと汗で木材が傷む可能性もあるのですが、まあそのときはまた作って何か塗ろうと思います。
コーナンさんでは買った木材を機械でカットしてくれるサービスがあるのでそちらも利用しました。ワンバイフォー材の奥行89mm・高さ19mmはそのままに、必要な長さにカットしてもらえます。その場でコーナンさんをLINEの友達登録したので無料でした……!

帰宅したらカットしてもらった材の角と表面を紙やすりですべすべにしていきます。特に手前側は手首と手のひらの当たるところなので少し傾斜がわかるくらいに紙やすりをかけて角をとりました。
紙やすりは大昔にダイソーで買った100円で番手(粗さ・細かさ)の違うペーパーが1枚ずつ入ったセットを使いました。まず60番でガリガリ削って角やささくれをおとして、400番で表面も一緒にきれいにならして、600番で仕上げとしました。1000番のペーパーもあったのですが600番をかけ終わった時点で満足のいくすべすべ感だったので1000番は使わず。
余談ですが、600番で紙やすりをかけていると花粉症がめちゃくちゃ悪化した気がします。。これは外で作業していたからなのかそれとも削った粉によるものなのか……。

このままだと机の上に置いたときパームレストが滑って動いてしまうので、裏側に滑り止めを貼りました。

滑り止め

3Mのいつでもはがせるクッションゴムを使ってます。キーボード裏に貼ることもあるかなと買って置いたのを流用しました。
少し傾斜があってもいいかなと、手前側には貼らず奥側の隅に2箇所貼りました。2箇所でも特に滑らず傾斜も気にならないのでそのまま貼り付けは2箇所で使っています。

ここまででひとまず完成です!

完成を横から

なかなかちょうど良い高さと安定感、トラックパッドの台もある、表面がすべすべで気持ちよいと良い感じです。木製の机の上に置いていても違和感なくなじんでいるように思います。
贅沢を言うなら、手前側に向かって削って傾斜を付けるとより良いかもしれません。ただあまり傾斜を付けると手首に角度が付いて本末転倒になりそうですし、いったんこのまま使ってみます。
また、机の方が少し茶色が強いのでなにか塗って色味を調整しても楽しそうです。塗装は塗装でなかなかに奥深い(沼)な気がするので、こちらもいまは対応せずとしました。 木材は半分ほど残っているので、またカットするなりして別に使おうと思います。

と、こんな感じで自作(やすりかけただけ)してみました。
木材が398円、紙やすりは100均のを数センチ角ずつ使っただけ、滑り止め4つ。合計500円くらいの材料費がかかりました。
時間の方は、木材買いに行って帰ってきて紙やすりかけてで合計2時間ほど。

買った方が確実に良いものが手に入りそうですが、自分で用意するのも良いですね〜。気が向いたら塗ったりしてみようと思います。
(と、ここまで仕様感を確かめるために長文書いたのでした。良い感じ。)

キーボード沼に足を踏み入れました(Choco60 rev.2を組み立てました)

分割キーボードはずっと前からかっこいーと思っていたものの、はんだとか必要なものを揃えるのがちょっと面倒で手を出していませんでした。
とはいえこういうのは考えていてもいっこうに前に進まないもの。

まあ多少なにかあってもいいか〜と気楽に挑戦してみました。

準備

とはいえ、やはりやるからには失敗したくないので、ネットで検索して必要な道具やコツみたいなもの、初心者でも比較的簡単なキーボードのキットについて調べました。
はんだづけは子どもの頃にちょっとやったことがあるくらいなので、できる限り簡単につけられて数が少ないキットを候補に探しました。 そこで、情報も多くて組み立ても簡単そうだった Choco60 rev.2 を選択。

Choco60 rev.2shop.yushakobo.jp

キーキャップは足りないキーや長さが足りないとかあると面倒なので、入っている数と種類の多い Cream Keycap Set(282-Key) を選択しました。

Cream Keycap Set(282-Key)shop.yushakobo.jp

スイッチは手に入りやすかった Aliaz Silent に。

Aliaz Silent スイッチshop.yushakobo.jp

あと TRRS ケーブル。

その他、必要な道具は何も持っていなかったのでえいやっと揃えました。

  • はんだごて
    • スタンダード?らしい白光の FX600-02
    • 手に入りやすいことと温度調節ができることから選びました
  • はんだ
    • スズ60%・鉛 40%の物が扱いやすいそうなのでそうしました
    • キーボードなど基盤のはんだづけは線径0.8mmくらいだそうなので0.8mmを選びました
  • はんだ吸い取り線
    • 失敗したときのリカバリー用に用意しましたが使わずでした
  • こて台
    • まあ無くても良いけどせっかくなので安いのを買っておきました
  • 精密ドライバー
    • Choco60 は M2 サイズのネジが部品に含まれるの
    • メガネ用のドライバーで回せそうでしたがせっかくなのでプラスドラバーセットを用意しました
  • エポキシ接着剤
    • Choco60 rev.2 では不要そうですが USB 周りの固定のためにいちおう用意しておきました

それとラジオペンチは家にあったのでそれを使いました。

組み立て

公式の動画を見ながら作業して完成。
キースイッチだけはんだづけすれば良いので全部で2時間ちょっとで終われました。ちょっと拍子抜けです。

と書きつつも、1カ所だけ失敗してしまったところが……。 右側手前のスタビライザーが取り付け時に固くてなかなかはまらなかったんですが、力が入ってしまったからか、はまりにくかったのはそもそも異常があったからなのか、スタビライザーが押し込まれた状態で固定されてしまっていました。。 ほとんどのキースイッチをはんだづけした後だったので諦めました。
ただ、スペースキーは左手でいつも使っていたので、右手のこの位置はスタビライザーを使うほど大きなキーを付けなくてもいいなと、右Cmdにしてスタビライザーに当たらない大きさのキーキャップをはめてみています。
そのまま特に困ることがないようであれば、スタビライザーは削ってキーキャップに干渉しないようにしてしまおうと思います。

完成

ということで実用には困らない問題もありましたが無事に完成させることができました!

ここまでも組み立てたキーボードで書き進めていますが、分割キーボードは初めてですが案外スッと使えています。 Bキーを右手で押そうとして空振るくらいでしょうか。 また、レイヤー2に HJKL で左下上右を割り当てて、右手だけでとても自然にカーソルキー移動できているのも良い感じです。(C-n/p/f/b は両手を使いますので……)
右の下側 Fn や右 Cmd を割り当てているあたりはまだまだ探求のしがいがありそうですし、他にもマクロなどなど試したいことがたくさんで楽しめそうです!

赤ちゃんを「みる」(育休を取得した)

(めちゃくちゃ個人的なことなので書いて公開する必要あるのかな、とも思ったけどせっかくなので。)

赤ちゃんを「みる」

もうほんと「赤ちゃん」はあまりにも脆弱な上、なんで泣いてるのかなにを要求しているのかさっぱりわからず。
赤ちゃんをモニタリングできる項目も限られていて、あれこれ推測しながら対応することになります。
このよくわからないながらあれこれ対応するのが「なんだか昔のサーバー監視みたいだな」と考えていたりしました。

赤ちゃんのメトリクス

主にわかるメトリクスは

  1. おむつのおしっこしたら色が変わるところ
  2. 設置した温度・湿度センサーと見守りカメラ
  3. 睡眠やミルクの時間を記録したログ(アプリ利用)

の 3 つ。
メトリクスっていっても一次情報しかないので、ただの数値・指標ですね。。
でもこれらを使って「今なぜこいつは泣いてるのか?」を推測して対処していくことになるという……。
(監視・対応といってもこれじゃほとんど勘!)

おむつ

1 のおむつは各種メーカーさんでそれぞれ液体に反応して色が変わったり柄が浮き出る仕組みを取り入れているので、一定時間たったり授乳のタイミングで確認して、必要あればおむつ交換タイム。

センサー・見守りカメラ

2 のセンサーは以前から Switch Bot 社製の温度・湿度センサーを購入して設置していたので、本やらネットやらに書いてあった 26〜28度くらい & 湿度 50〜60% になるようにエアコンと加湿器を動かしてました。

見守りカメラはせっかくなのでと同じく Switch Bot 社製のカメラを購入して設置してみています。いま時点では基本的に赤ちゃんのすぐそばにいることがほとんどなので特に活躍していませんが、育休が終わって別の部屋で仕事しはじめたら(かわいくて)しばしば見ることになるのかもしれません。

ログ

そして 3 のログがとても良かったです。
というのも、家庭内での情報共有・申し送りがこれでほぼ完璧になります。

昼夜関係無く 3 時間間隔で授乳が必要なため、夫婦で分担して育児(と家事!)を寝たり起きたりしながらこなしていきますけど、このとき「あれ?最後にいつおむつ交換したの?」「ミルトン(哺乳びん等の消毒)の液いつ変えた?」などなど情報交換が不可欠です。対応時間だけではなくミルクの量なども記録できるので、ぐずって泣いているとき自分が対応していなかっても前回いつどのくらい飲んだのかすぐ確認できてとても楽です。 1 のおむつの情報と組み合わせると、「お、少ししか出てないけどしばらくおむつ替えてないから交換しよう」みたいな判断ができます、便利。

「家にいるんだからそのくらい相手に聞いたら?」と考えるかもしれないのですが、対応者が家の中にいても3時間スパン生活で疲れて寝てしまっていて聞けないことが多々あります……!
ぐずっているのをあやして寝かしつけてようやく自分もひと眠りしよう……このタイミングで起こされるのは厳しい……こういう小さなストレスをできるだけ消し去っておくことが平和に日々をこなしていくことにつながるな〜と思います。

また、グズっているときも前回いつ頃なにをしたかログを見ればわかるので、「そろそろ〜の時間かな?」と推測しやすくなるのも楽でした。周期のようなものもわかってくるので、計測・記録は偉大です。

こまめに登録するのも面倒・ストレスですが、情報共有の快適さとぐずっている理由をログから推測できるのはそれを上回る快適さです。

いろいろアプリ・サービスが公開されているようですが、我が家では「ぴよログ」を使わせてもらっていました。
iOS のショートカットを使って Siri 経由でロギングできるので、手を使えないときにも簡単にログが取れて便利……!UI もよく考えられているなーと使っていて感動することもありました!!ここに書いてもしょうがないけれど、ありがとうございます……!

www.piyolog.com

まとめ

なにが書きたかったのかわからなくなってきてますが、ひとまずまだまだ 2 ヶ月間の様子でした。
サーバー監視みたいだなということが書きたかったような気がするけれど、ロギングと情報共有・申し送りが大切だぞ……という話になっていました(?)

最後に書くのもアレですが、入社してしばらくで約 1 ヶ月半も育休をいただき、関係する方々や会社にはとても感謝しております。忘れようのない、自分にとってすばらしく貴重な時間となりました。
復帰後もあれこれ発生しそうですが、できる限りのことはやろうと思います〜。

Mac標準の日本語変換とPWAを使っているとレインボーカーソルする

最近たまにiPadで外部キーボードとライブ変換を使っています。
それならMacでも同じようにライブ変換を使ってみようと思ったところ、やたらとレインボーカーソルが発生して作業が進まなくなりました。。

何が条件なのかと色々変えて試してみましたが、どうやら

  • ChromeやEdgeでサイトをアプリとしてインストールして使っている(PWAを使っている)
  • Mac標準の日本語入力を使っている

の2つが組み合わさると発生している様子。
例えばTwitterをPWAで使っていてメインのブラウザのウィンドウにフォーカスを移すと100%発生するのでその度に数秒止まります。なかなかにしんどい。。。
自分の環境はmacOS Big Sur でしたが、別の人のマシンではそれより前のCatalinaでも再現しました。となるとmacOSの問題というよりは日本語入力の問題かブラウザの問題なのかもしれないなぁと疑っています。(冤罪だったらごめんなさい。)

しかしまあTwitterGoogleで検索してみてもほとんど同じような現象がヒットしません。それ故に自分の環境固有の問題かとも思いましたが、あまり設定をいじらない人のマシンでも再現できたのである程度は広く起きてる現象のよう。PWAが使われていないのか、Mac標準の日本語入力が使われていないのか......。どちらにしても悲しい。

そんなにライブ変換したいわけでもないけれど、気になってしまったのでいろいろ試してみましたが解消策は見つけられず残念。言及してる人すらほとんど見つからないので、誰かがたどり着けるようにこうやって残しておきます......。近い将来この記事が同じ現象に当たった人の目に留まることを祈ります。願わくはその人が解消策まで到達できますように......。

ちなみに回避策は1つ発見しました。
それは

  • 日本語はMac標準の日本語入力を使う
  • 英数はGoogle日本語入力ATOKなどMac標準の日本語入力以外の英数入力モードで入力する
  • Mac標準の日本語入力の英数モードはキーボードの設定で削除しておく
    • 英数モードにしていてもレインボーカーソルが発生するため
  • PWAからブラウザにフォーカスするときは必ず日本語入力をオフにする

です。
自分はaquaskkを使うことが多いので、

  • キーボードの設定でaquaskkの各モードとMac標準の日本語入力の日本語モードだけを使えるようにしておく
  • 英数はaquaskkのASCII入力モードを使う
  • 日本語はMac標準の日本語入力を使う
  • フォーカスを変える前や日本語を入力し終わったらすぐに「英数」キーでaquaskkのASCIIモードに変える

ことで限りなく回避しています。
とはいえ切り替え忘れていてレインボーカーソルが発生して「イラッ」とすることは多々ありますが......。

以上、すぐにそもそもMac標準の日本語入力をつかわなくなって忘れちゃいそうな内容でした。

2014年のYosemiteから「ことえり」じゃなくなって「日本語入力プログラム」になったらしく、何度も持って回った言い回し(Mac標準の日本語入力)をタイプしているのでぜひ名前をつけてほしいものです................

iTerm2とVisual Studio CodeをMacがダークモードになったら暗いテーマにする

新しいMacで環境構築進めている最中の完全に自分用メモ📝

ブラウザやチャットなど、さいきんはMacの外観モードがダークモードになると追随して暗めのテーマに変わるものが多い。
逆に変わらないiTerm2やVisual Studio Codeが煌々と明るくて気になるようになったので、ダークモードに切り替わるように設定した。

iTerm2

iTerm 2 - script to change theme depending on Mac OS dark mode

を参考にしてPythonスクリプトを設定する。
基本的に書いてあるとおり。

  1. 上記リンク先のPythonスクリプトを保存する
  2. スクリプト中にiTerm2のカラーテーマ名を指定している箇所があるので好きなカラーテーマに書き換える
    デフォルトで Solarized DarkLight Background が指定されている
  3. 保存したスクリプト$HOME/Library/ApplicationSupport/iTerm2/Scripts/AutoLaunch にコピーする
    もし AutoLaunch ディレクトリが無ければ作成する
  4. iTerm2のメニューから Scripts > AutoLaunch を選択する
  5. Pythonランタイムをダウンロードしていない場合はするようにプロンプトが出るのでOKしてダウンロードする
  6. MacがダークモードON/OFFされるとiTerm2のカラーテーマが切り替わる
    テストする場合はMacのシステム環境設定 > 一般から外観モードを変えてみる

ライト・ダークモードが切り替わるのは時間とかじゃなくて、Macの外観モードが切り替わることなので、
テストする場合は↑に書いたように設定を変えること。

スクリプトが動くことでパフォーマンスに影響しないか気になるけどいまのところ体感レベルではわからずです。

Visual Studio Code

こちらは拡張をインストールする。
いくつかありそうだけど以下を利用させてもらった。

Auto Dark Mode - Visual Studio Marketplace

インストール後、設定に以下を追加すればMacの外観モードが切り替わるのに追随して動作する。

  • autoDarkMode.lightTheme
    • ライトモードのテーマ名を文字列で指定する
  • autoDarkMode.darkTheme
    • ダークモードのテーマ名を文字列で指定する

設定例

"autoDarkMode.lightTheme": "Chinolor Light",
"autoDarkMode.darkTheme": "Nord Wave",

2021年初頭に SKK を Windows/Mac で Google 日本語入力からの候補取得といっしょに絵文字まで変換して使うための方法

前提・したいこと

いろいろしたいこと盛り沢山。

動作させる環境としては

  • Windows10 の WSL2 で動作させたい
  • WSL2 と VcXsrv で動かしている Emacs の ddskk からも (できるだけ) 利用したい
  • でも Mac でもできるだけ同じように環境を用意したい

そして動作自体には

  • 辞書に無い未知語は候補を Google 日本語入力 (Google Japanese Input) の API から取得したい
  • 辞書に有る語の場合は辞書から候補を取得して可能な限り高速に変換したい
  • 絵文字も入力したい

とぜいたくな感じ。2021 年、令和三年ですからね。

作業内容・手順

SKK のインストール

Windows10 では動作も軽快で安定感抜群な CorvusSKK を利用させていただいてます。

github.com

リリースから最新のインストーラーをダウンロードしてきてインストールすればふつうに完了。

Mac では AquaSKK (aquaskk?) を利用させていただいてます。

github.com

こちらもリリースから最新のインストーラーをダウンロードしてきてインストールすればふつうに完了。

yaskkserv2 のインストール

ここでは yaskkserv ではなく yaskkserv2 を使います。Rust で作られている yaskkserv2 なら比較的簡単に環境差異を気にせずに SKK 辞書サーバ (skkserv) が用意できるためです。(あと個人的に Rust に興味があったからというのも大きい)

github.com

README.md のとおり (2021/01/06時点) に作業をします。

ソースの取得

今後の更新で再ビルドしたいので git で clone します。WSL2 の環境に git が無いときは ZIP でダウンロードしても良いでしょう。(git はインストールしておくことをオススメしますが……)

cd ~/git/
git clone https://github.com/wachikun/yaskkserv2.git

私はホームディレクトリに git ディレクトリを用意してそこにソース類を置いているので、cd してから clone しています。

Rust 用意

(すでに Rust が使える環境の方は飛ばしてください)

まったく Rust の環境用意が無い場合は、 Homebrew on Linux を使ってインストールするのが手っ取り早いかもしれません。

docs.brew.sh

brew のインストールは上記のリンク先のとおりです。
脱線な上に長くなるので省略してしまいますが、私は fish を使っているので PATH を通すための環境変数設定あたりに違いがありました。対処方法は「homebrew fish」等ですぐ出てきます。

ビルド

ここは yaskkserv2 の README.md のとおりです。

cd (yaskkserv2 を clone したディレクトリ)
 cargo build --release

成功するとtarget/release の下に yaskkserv2 本体と辞書変換用の yaskkserv2_make_dictionary が作られます。

実行できるところに配置する

ビルドしてできた yaskkserv2 本体と辞書変換用の yaskkserv2_make_dictionary を実行しやすいように PATH のとおったところに配置します。

私は自分でソースからビルドしたものを ~/bin に置くことにしているので以下のコマンドでコピーして配置しました。

cp -av target/release/yaskkserv2 ~/bin/
$ cp -av target/release/yaskkserv2_make_dictionary ~/bin/

/usr/local/bin とかでも良いんじゃないかなと思います。

辞書用意・変換と yaskkserv2 の起動

yaskkserv2 は SKK 辞書の変換を必要とするので、変換元辞書の用意と変換をしてから yaskkserv2 を起動してみます。

SKK 辞書の用意

公開されている SKK 辞書をダウンロードしてきて集めても良いでしょうし、WSL2 で Ubuntu を使っているなら apt で yaskkserv (yaskkserv2 ではなく yaskkserv) をインストールすると /usr/share/skk の下にだいたいの種類の辞書ファイルが置かれるので、それを利用すると手っ取り早く進められます。以下を clone するのも便利です。

github.com

cd ~/git/
git clone https://github.com/skk-dev/dict.git

また、速く変換したいので Google 日本語入力の API に頼らず辞書ファイルから候補の語が取得できるように以下も利用させてもらいます。

github.com

cd ~/git/
git clone https://github.com/tokuhirom/skk-jisyo-neologd.git

辞書の用意ができたら yaskkserv2_make_dictionary を使って辞書を変換します。以下は上記の skk-dev の dict と SKK-JISYO.neologd を利用する想定です。
なお、絵文字の対応は skkserv ではなくCorvusSKK または AquaSKK でおこなうため、自分は utf8 ではなく eucjp のまま変換しています。

cd ~/git/dict
yaskkserv2_make_dictionary --dictionary-filename=/tmp/dictionary.yaskkserv2 SKK-JISYO.* ../skk-jisyo-neologd/SKK-JISYO.neologd

辞書表記の影響で SKK-JISYO.neologd のいくつかの語で警告が出ますが、わずかであったので無視して進めました。(気になる方は変更して変換成功するようにしてみてください。そしてその内容を書いていただけますと……)

yaskkserv2 の起動

辞書の変換までできたので、yaskkserv2 を起動します。
変換した辞書は、変換時のコマンドに渡した --dictionary-filename オプションのパスにある /tmp/dictionary.yaskkserv2 にできています。よって起動時にもこれを使います。

yaskkserv2 --no-daemonize --google-japanese-input=notfound --google-suggest --google-cache-filename=/tmp/yaskkserv2.cache /tmp/dictionary.yaskkserv2

オプションについての詳細は yaskkserv2 の README.md を見ていただくのがいちばんですが、使ったものは以下のとおりです。

  • 使いはじめは Google 日本語入力から候補をもらう処理をいろいろ試してみたかったので、--no-daemonize をつけてバックグラウンドで動作しないようにしています。
  • --google-japanese-input=notfound とすることで、Google 日本語入力からは辞書に候補が無かった場合にだけ候補を取得します。
  • --google-suggest をつけて有効化しています。
  • Google 日本語入力から取得した候補はキャッシュして何度も問い合わせしないように --google-cache-filename=/tmp/yaskkserv2.cache をつけています
  • さいごに変換した辞書の場所 /tmp/dictionary.yaskkserv2 を指定しています。

特に README.md にもあるとおりで、Google 日本語入力からの候補取得はどうしても変換ラグが発生してしまいます。 notfound オプションでできるだけ軽減させています。
また、起動ポートは指定していないので 1178 で起動していますが、AquaSKK の内蔵 skkserv を使っていたり他に skkserv が動いているのであれば

yaskkserv2 --no-daemonize  --port 1179 --google-japanese-input=notfound --google-suggest --google-cache-filename=/tmp/yaskkserv2.cache /tmp/dictionary.yaskkserv2

--port 1179 のようにポート番号を指定するオプションでポート番号を変更すれば OK です。
あとは CorvusSKK または AquaSKK で yaskkserv2 を skkserv として追加してやると利用できます。最近の WSL2 であれば、Windows 側から WSL2 への通信に localhost が利用できるので、skkserv は localhost:1178 で接続可能になっています。便利になったものです。。

また、ここまでで ddskk から yaskkserv2 に接続して変換することができるようになっています。

絵文字変換の用意と設定

絵文字も変換できるように辞書を用意します。絵文字辞書を用意してくださっている方がいらっしゃるので、以下を clone するか必要な辞書ファイルをダウンロードします。

github.com

github.com

uasi/skk-emoji-jisyo の README にもあるように、CorvusSKK または AquaSKK に直接辞書として登録します。

絵文字辞書は utf8 であり eucjp な SKK と異なるのですが、このあたりあまりいろいろすると後から混乱しそうなため

  • yaskkserv2 は ecujp の辞書と eucjp で動作させる
  • 絵文字用の utf8 の辞書は CorvusSKK または AquaSKK に直接辞書として登録する

と分けてみています。
skk-dev/dict にも絵文字辞書があるのですが、以前からこの手順と分け方で設定していたのでそのままにしています。Emacs の ddskk でも絵文字変換を使わないので、yaskkserv2 に絵文字辞書を入れたくないという背景もあります。
もしこの手順無しでもうまく絵文字変換できたよ!という方いらっしゃいましたら教えていただけますと……

お試し

以上で CorvusSKK または AquaSKK では以下の挙動が確認できるはずです。

  • 「▽へんかん」(変換)など辞書にありそうな語を変換する → 高速に変換される = yaskkserv2 経由で辞書ファイルから変換されている
  • 「▽へんかんてすと」(変換test) など辞書にない語を変換する → 数ms〜1s 程度の時間をかけて変換される = yaskkserv2 経由で Google 日本語入力から候補取得して変換されている
  • 「▽だんぼーる」(📦) など絵文字を変換する → 絵文字が変換候補に存在する = utf8 の絵文字辞書が読み込まれて変換に使えている

Emacs の ddskk では絵文字辞書を使っていないので、最後の絵文字変換以外が動作するはずです。

おわりに

Google 日本語入力を使った候補取得をおこなう場合、SKK の設定によっては辞書ファイルに存在する語に変換する場合でも Google 日本語入力に問合せしてしまい若干のラグが発生してしまうことがあるのですが、以上の設定では可能な限りローカルの辞書から候補を取得して高速に変換ができるようになっているはずです。また、WIn10 でも Mac でも、また Emacs の ddskk でも同じように変換ができるようになっているはずです。

過去にも SKK をさまざまな環境で同じように利用する方法を試行錯誤してきましたが、多くの方の作成物を繋いで利用させていただくことで 2021 年には素晴しい SKK 環境が OS やアプリケーションにとらわれることなく実現できるようになっていることに感謝です!

……と、せっかく SKK の良い感じな環境を手に入れたので長文を書いてみたくて書いた記事です!

2020 年と 2021 年

びっくりするほど 2019 年の終わりについて覚えていない……。でも記事はあるから不思議。

nishikawasasaki.hatenablog.com

酔っぱらい過ぎていた?

2020 年

世の中としてはコロナなんだろうけど、個人的にはますますの山登りとカメラ (フルサイズ) につきる年。

ずっとマイクロフォーサーズを使っていたのに、2 月に突如 SIGMA の fp を買ってフルサイズデビューした。写真データの連番を見ると、10 ヶ月 7500 枚くらい撮影したらしい。山の写真が 9 割かな?写真が撮りたいから山へ行くし、山へ行くから写真が撮りたい。そんな 1 年だった気もする。オールドレンズ、特に六甲にちなんだ ROKKOR を 2 つ入手してよく使った。

また、春くらいの緊急事態宣言で 2 ヶ月くらい山に行かなかったことを考えると、2019 年よりよほど山に行ったなーという感じがする。

f:id:nishikawasasaki:20201231202851p:plain

去年の記事をあらためて読んでみると 1000 メートル超えの金剛山に言及しているけど、今年は 2000 メートル近い西日本最高峰の石鎚山に登頂することができた。同じく去年は雪山を「歩きたい」と書いているけど、石鎚山は雪山を登って登頂できてる。百名山にも 4 座、剣山、大台ケ原、大山、石鎚山に登ることができた。テント泊もしたし、ステップアップしてるな〜。来年も楽しみ!

2 月のコロナ前最後というタイミングで研修に行って試験を受けて認定スクラムマスター (CSM) になったのもいつもと違うことかな。数年来、自分で考えたり見聞きしたことから判断してやってきたことの答え合わせになった。これだけで食べていけるような甘い世の中じゃないと思っているのでだからなにってことも無いのだけれど、「次は今よりうまくやる」をモットーにしている自分にとって大きなきっかけだったなとは思えるものだったと思う。あと 2019 年にしなかった登壇を誘ってもらってしたのも良かった。

nishikawasasaki.hatenablog.com

なんか追い込まれるかぎりぎりにならないと動かない性質なので、こういう機会はありがたや。

2020 年は世界的に世の中とんでもない年だったのだろう。個人としても、こんなにもそれまでしたことがないことをやった年もなかったし、もっとたくさんしたいことがあるなとさらに思えた年もなかった気がする。ひとつ大きな変わり目なんだなと振り返る年になったかな。

2021 年

2021 年って書くたびに超未来感すごい。去年の記事にも仕事では新しいことしたいと書いていたけど、これはなにも進められなかった。ただまあ、もうそろそろ良いかなーという感じが隠さないほど出ているし変化の年になりそうな気がしてる。
山は今年行けなかった北アルプスのような 3000 メートル峰にも行ってみたいなー。雪中テント泊はまだ遠いかもしれないけど、冬の山でももっと遊びたい。やりたいことはたくさんあるなー。

J Lang Fest Kansai Online #1 で登壇してきた

久しぶりに外の勉強会ではなしてきた。

kansai-jvm-langs-fest.connpass.com

毎年 1 回は機会を作ろうと思っていたのに、2019 年は社外で登壇しなかったので久しぶりになってしまった。。

Scala の好きなところ」をテーマにもらっていたので、大好き(?)な Akka をメインにしてみた。
コーディングとかたくさんある機能、簡単に実現できる並列・分散処理、リアクティブなどなど、Akka の良いところはたくさんある。その中でも特に推しておきたい処理を部品として分解することによる事業へのメリットを扱ってみてる。実は「それは Akka じゃなくても良いんじゃない?」という声があるだろうなーとは思ってる。ほんとそのとおり。でも同じように実現できる言語やフレームワークの中でも、その自由さであったり容易さがピカイチなのは Akka だと思ってる……。定量的に比較してなくて超定性しかも個人の。
そんなだから、もし「おいおいおいおいーこれも超いいんだけど!?忘れてない!?!?!?」みたいなのがあればぜひ教えてもらって知りたい!というモチベーションでも登壇したのでした……。

資料はこちら

speakerdeck.com

質問でもらっていた背圧制御については Actor ではなく Streams の方で実装されているのは訂正しておきます。
あとあんまりデメリット側のはなしができてなかったのだけれど、アクターやメッセージボックスの数の最適化や、割り当てるスレッドプールの数などアクターモデルにはアクターモデルのチューニングポイントというか難しさがある。これはどんな道具でもそういうところがあるので、道具にあわせて学んでうまく付き合っていきたいところ。

そういえば「良い道具は使い手を良く育てる」みたいなことを途中言いたかったんだけれど、なにかの格言なのかネットの言葉なのかネタ元が見つからなかったので見送った……。良い道具はそれ自体に作り手の思想やプラクティスが染み込んでいるので、ある程度はその道具の導くとおりに振る舞うことで良いおこないとなるみたいな云々カンヌン……。

ぜんぜん内容には関係ないけれど、タイトルや途中のスライドに出てくる山は
剣山(から見た次郎笈)→(次郎笈から見た)剣山 → 大膳原キャンプ場 → 大山から見た日本海 → 大山
の順番。この夏の山々。もっと山登りいきたいなー。

他の方の登壇内容もすごく興味深いのに、登壇が後の方だったので自分のことにいっぱいでちゃんと見聞きできていない。。また見ときます。

運営の方、素敵な機会をありがとうございました〜。良い経験になりましたー。

Windows Terminal 1.3 で変わったタブ切り替えの挙動をもどす

Windows Terminal が 1.3 になったころから Ctrl + Tab と Ctrl + Shift + Tab での次のタブ・前のタブのタブ切り替え挙動が変更となった。

Release Windows Terminal Preview v1.3.2382.0 · microsoft/terminal

We're trying out a new tab switching experience! (#6732), followups: (#7263) (#7280) (#7321) The nextTab and prevTab bindings will now display an ephemeral UI that can be navigated with the mouse or keyboard

↓ こんなかんじ

1.3からのタブ切り替え
1.3からのタブ切り替え

いろいろ変わっていくこと試してみることはとても良いことなんだけれど、自分にはあんまり合わなかった。。
というのもシェルの名前といまいるディレクトリを表示されても、そこでなにしてたか覚えてない。なんなら複数同じディレクトリを別タブで開いておいて Scala の sbt の対話型コンソールで作業しつつ別タブではコマンド実行してたりするので、同じ名前の同じディレクトリがいくつも並んでしまう。こういう使い方してると合わないのかも。

たくさん開いたタブを検索する機能も入ってるので、それとの挙動の共通感を出したかったのかも?

ということで元に戻した。
方法は同じリリースノートに書いてあった。

If you would like to fall back to the original tab-switching UI (or lack thereof), set new useTabSwitcher (global, boolean, default true) to false.

  "useTabSwitcher": false,

これを keybindings とか copyOnSelect とかと同じ階層に追加する。

戻った。しっくりきた。

We'd love feedback on why the new tab switcher didn't work for you!

ということなので、またフィードバックしだいでは変更あるかもしれないけどひとまずはこれで……。