雑記

在宅が始まってから、大分コーヒーの量(ただしかなり薄い)が増えてたので、ちょっとカフェインの摂取量を減らしてみました。まだやりはじめなので、効果が出るまではまだまだかなー。 ちょっと仕事が忙しい & 実装がいまいち進んでなくて書くことが無いので、埋め草的に、ちょうど半年が経過した引越しについて振り返ってみようかと思います。 <!–more–> 引越し遍歴 そういえばあんまり気にしてなかったんですが、社会人になってからの引越しを思いだしてみます。私はめんどくさいのが嫌いなので、基本的に引越しにはかなり腰が重い方です。なので件数は少ないですね。 築xx年、は入居時点です 一部屋目 築12年ワンルームでした。約5.5畳で、風呂・トイレがセットになっていましたね。ここはとにかく日当たりが悪く、朝の30分以外は日光が当たらないような場所でした。 学生の時に住んでいたアパートも似たようなもんでしたが。 約4年半ほど住んでいました。 二部屋目 築25年の1Kでした。約6.5畳(ただし0.5畳が中途半端な状態だったので、事実上6畳。ここは風呂・トイレ別になっていて、初のオール電化物件でした。 実家もオール電化ですが、自分の部屋がオール電化になると、やっぱりよい点が色々ありました。ちなみに、私はこの部屋に引っ越すまで自分の冷蔵庫というものがなかったので、引越し直後に慌ててヨドバシに走った記憶があります。 お湯がすぐ出る IHなので火力とかも大体問題なし ただ、その分電気料金が結構いくので、まー最終的にはトントンくらいでした。また、この部屋は大通りに面している場所だったので、一日中車の音がしている、というのは、慣れててもやっぱりうーんと思うときはありました。 この部屋は今迄で一番日当たりがよく(南西向き)、初めて5階という階層を経験しました。周囲に5階建以上の建物がほとんどなく、窓から日光がサンサンと降り注いでくれたので、 もう夏はサウナ でした。後冬でも暖房がいらんときが多々ありましたね。 約8年半住んでいました。途中で管理会社が変わったりと色々ありました。 今の部屋さがし 部屋探しは、約3週間程度かけておこないました。ちょっと特殊な要件があったので、まず前提となる物件が少なく、ネットだと限界があるなー・・・と思ったので、 https://www.heyagime.com/ ここに予約して行ってみることにしました。都合3回行きましたが、3回目は書類の記載をしに行ったので、事実上2回です。色々提案してくれたり、隠れ物件を紹介してくれたりと、かなり満足度が高かったのでオススメです。 ちなみに私はあんまり迷うことが無い質で、大体一回内見に行ったら決めてしまいます。要件が特殊でそもそも選べないんじゃーというのもあるんですが。 なお、実際に部屋を決めてから引越しまでは3週間ほど空いています。これは、その当時マンションのエレベーターが工事中だったためで、さすがに5階から荷物を運び出してもらうのは・・・ということで、伸ばしました。今の部屋が一ヶ月のフリーレントがあったので、お金的にはそれほど痛くなかったのが幸いでした。 2020/10〜11 くらいで話を聞いた感じでは、結構フリーレントは多い、という話でした。まず入居してもらわないと始まらない、ということのようです 荷造り & 手続 ここが一番大変というかめんどくさく、元々居住空間が1畳ちょっとしか無いような状況(ゴミが多いとかではなく、テーブルとベッド + レンジ台 + スチールラックでこうなってました)だったので、まずは不用品を捨てていくところからでした。多分人生で一番物を捨てましたね。十年以上共にしたベットもここで廃棄しています。 3週間もあけておいてよかった・・・と本気で思ったのは言うまでもありません。ただ、実際には引越し日になってもまだ終わりきっておらず、業者がうまく予定をしきれておらず、午前中予定が昼から、となったので、最後に終わらせることができた、というのが実態でした・・・。 この荷造りがあるので、引越しが面倒すぎるというのが本音ですね。手続系統もめんどくさいですが、なんというかコロナのおかげで窓口がえらいガラガラだったので、移動時間の方が長いくらいで終わりました。一番面倒なのはクレカとか銀行とかの住所変更ですね。多分まだ変更しきれてないのがいくつかある。 引越し〜 引越し自体は、業者がテキパキとやってくれたので、搬出と搬入で合計1時間くらいしかかかってなかったんじゃないでしょうか。むしろそこから自分で出したりする方が時間かかった気がする・・・。 引っ越した部屋は今迄で一番築浅なので、色々と見たことがないものがついていました。 24時間換気(初めてみた) 画面つきインターフォン 前の部屋のインターフォンは多分4年くらいずっと壊れていたので、鳴ること自体が新鮮でした 自動湯沸器 風呂を自動で入れてくれるやつとか ただ、24時間換気は考えものだなーとも思いました。今の建物は高断熱高気密になっているので、これがないと循環しない(そしてまた大通り沿いなので窓が開けづらい)のはわかるんですが、冬の超乾燥している空気が遠慮なく入ってくるので、 部屋が乾燥しすぎて寝られない というのを経験しました。 引越してから買ったものリスト 部屋を引っ越してから、なんか色々と古くなっているものを買いかえたり買ったりとしました。リストにしてみましょう。 自作PC 前書きました。完全に新しくしました ダイキンの空気清浄機 加湿機能付を買いました。買った直後に除湿・加湿機能付きが出たので、そっちにしとけばよかったと思う6月直前です スピーカー 元々のスピーカーが8年くらい使っていたので、リファインしました Boseとどっちにしようか悩みましたが、あんまり低音が効きすぎるのもどうかと思ったので、バランスのとれたこっちにしてます 4Kモニター x 2 モニターアーム x 2もセットです 24inch x 2から 27inch x 2にレベルアップしました。机のサイズと部屋のサイズ的にはこれが上限ですね フライパンとか せっかくガスコンロになったので、鉄フライパンを購入してみました。扱いは難しいですが、ちゃんと使えると楽しいです。 PS5 当たりました。 特に空気清浄機は、冬の超乾燥に対抗する手段としてきっちり役に立ってくれました。現状花粉症とかでは無いので、それ以外だとまぁつけておくか・・・くらいですが。 ...

今年は桜を見に行きました。以外と近くの公園が綺麗に咲いていたので、特に留まるとかはせずに歩きながら、ですが。酒を飲んだりする花見、なんてやったことないなぁ・・・。 相変わらず在宅ワークの日々ですが、ディスプレイの配置を6、7年振りに変更しました。その話をさらーっと書いてみます。 <!–more–> まずは現状を 今のディスプレイ配置ですが、こんな感じになりました。手前にあるAlienwareは気にしない方向で。ディスプレイのサイズですが、24.5inchです。いずれ27inchにしたい。 モニターアームとしては、以下を利用しています。エルゴトロンのOEMであるAmazon Basicのやつです。 ただ、デュアルディスプレイ用のものではなく、シングル用のを二つ購入しています。これは後述します。 なぜこの配置か？ 以前は、通常あるデュアルディスプレイの配置にしていました。外部サイトの画像ですがこんな感じ。 デュアルディスプレイ用のアームとかであるような、視線が二つのディスプレイの間にあるような感じでした。実際、初めてデュアルディスプレイにしてからずっとこの形でした。しかし、在宅が始まってから、この配置だとちょっと都合が悪いケースが増えてきました。 MacBook(社から支給されている)と繋げているのは左側だけ メインの作業領域が(広いので)繋げたディスプレイになっている 仕事中、首がずっと左側を向いている状態になっている また、仕事中でなくとも、エディタがあるのは大抵どちらか一方なので、結構な時間そちらの方に首が向いている形になっていました。同じ方向に首を曲げ続ける、というのは結構な負荷になっていたとは思いますが、今までは在宅とかなかったので、そこまで長時間その体勢になっているということはありませんでした。 しかし、在宅で長時間その体勢になるようになったことで、結構体に対する負荷がかかってきていることに気付いたので、ちょっと試行錯誤した結果が前掲した画像のスタイルになったわけです。 配置の制約と検討 メインの作業領域はどうせ一つの画面に集約されるので、そのディスプレイは自分の正面に配置することがほぼ確定します。そうなると、24inchだと約60cmくらいの領域が正面を占めます。そうなると、もう一つのディスプレイをどう配置するのか？という問題になってきます。 配置にあたって、私の机やスタイル上、以下のような制約を設けています。 机の右端にPS5が置いてある 正面のディスプレイは仕事/Alienwareからの出力で使う なのでHDMI端子が埋まってる DisplayPortはデスクトップが全部使ってる 上の制約を満たしつつ、私の机のサイズを勘案すると、配置は概ね以下のいずれかにすることに決めました。 縦に２画面並べる 横に角度を付けて置く ただ、縦に並べる、ということも考察してみたんですが、それを成立させるためのアームがわりと特殊なものになる(=汎用性が無い)ため、早々と検討リストから脱落しました。そうなると横に角度を付けて配置する、という話になります。が、24inchとはいえ、横にしたまま配置するとかなりの威圧感があります。かつ、全体を視線に入れるためには、結局かなり首を曲げなければなりませんでした。もう自分の椅子ごと向いた方が早いくらい。 さてではどうしようか・・・ 縦にするというパターン 情報収集とかで見るwebサイトなどは、縦にした方がサイトとかの情報量は多くなる傾向があります。デザイン上横幅が決まっているサイトだとスペースが空いてしまうし、文字が折り返されたとしても、長すぎると始点を見失うので、横に長すぎても情報の閲覧という意味ではそこまで強みがあるわけでもありません。 そうなると、縦にする、ということが選択肢に上がってきます。特にモニターアームを使うことが前提(机のスペース問題上、スタンドを置くというのはちょっと無理なので)であったので、縦にする分には問題はありません。 また、PS5をやるときは、ディスプレイを横に回してしまえば無問題です。どうせゲームをやるときはそっちに体を向けるので、角度が付いていることも問題ではなくなります。 シングルのモニターアームを二つ使う さて、そうなると今度は、それができるモニターアーム探しですが・・・。これがわりと難しいです。 24inchのディスプレイの幅は約56cmあります、それが正面にあるということは、少なくともアームの長さが60cmはないと、正面にあるディスプレイの横に置けなくなります。が、一般的なデュアルディスプレイ用のアームだと、これを満たしそうなものがありませんでした。あっても、今度はディスプレイがかなり前に来たりして、非常にやりづらい感じになってしまいました。 実際、以前使っていたアームだとその配置にするのが不可能でした。 そこで、配置に関する記事を漁っていたところ、 シングルのアームを二つ使えばいい という、目からウロコのアイデアを頂きました。そりゃそうか、という感じですね。Amazon basicのアームは、ちょうど二個一で注文できたので、それを注文して設置をしました。結果が最初の画像です。 この配置にすることで、 メインは、首を曲げずに正面に設置できる サブは縦にして、情報を表示できる 縦に長いのを利用して、ターミナルとブラウザを縦にしたりして、とかもやりやすいです PS5をやるときはクルッと横向きにできる 油断するとディスプレイ同士がぶつかりそうなサイズ感なので、ちょっと注意は必要ですが という、前述の制約を満たしつつ、配置を改善することができました。やったぜ。 シングルを使う利点 Amazon Basicのアームは、耐荷重が11kgとかあります。また、27inchとかでも普通に利用できます。デュアルディスプレイ用だと、ディスプレイが大きくなると配置上の自由度はかなり小さくなりますが、シングルなら設置場所を調整することも容易です。 下手にデュアルディスプレイ用を使うよりも、シングルを二つ利用するほうがいいな・・・という認識になりました。いいよこれ。 おまけ: Swayで縦ディスプレイを使う 私のメイン環境はSway、つまりWayland nativeに完全移行していますが、Swayだと縦ディスプレイにしても何の問題もなく表示してくれます。表示する場合、swayのconfigで、outputにtransformを指定するだけでできます。 output DP-1 { pos 1920 0 mode 1920x1080@119.982002Hz transform 270 } transformがミソで、デフォルトの状態を0としたときに、右回りに回転する角度を指定する形です。ここを指定したり、 swaymsg を使ったりすれば、ディスプレイのローテートに合わせて自動的に向きを変える・・・なんてこともできそうです。 ...

今年の桜前線は大分早く、今の時点でほぼ満開、となっていますね。この調子だと土日でがっつり散ってしまいそうな感じです。 さて、タイトルにもありますが、ゲーミングノートを更新したので、たまには箸にも棒にもかからない話ではなく、開封の儀とかを載せてみようと思います。 <!–more–> まずは画像を どのブランドのものを購入したか、はこの画像をみたら一発でわかります。 でーん。はい、Alienwareでした。AlienwareのM15 R4フルカスタマイズ、を今回購入しました。 上の箱を開くと、こんな感じです。15inchを表す意匠がありますね。15というか13に見えたりしなくもない・・・。 前まで使っていたノート MSIのGS75になります。実家に持って帰れるサイズと重量、ということで、3kgとかするような重量級は最初からアウトオブ眼中なのはあしからず・・・。 ちなみにこれも別段悪いわけではないです。ただ、後述するようにちょっと問題があり、CPUはBoostをかけられない、という制約がありました。でも17インチ相当の画面ながら、15インチとほぼ変わらないサイズ感は、かなり魅力的でした。 購入した直後にSUPERが発売されて、悲しい思いをしたのは秘密です。 購入したノートのスペック Corei7-10870H 32GB DDR4 1TB PCIe M.2 SSD NVIDIA GeForce RTX 3070 8GB 4K有機EL これ以外のオプションは全部オフってます しめて税込約x0万・・・なんですが、これはクーポンが有効になって16%Offになっているときの値段なので、実際にはもっと高いです。 今回、初めて4K有機ELのディスプレイを購入してみました。個人的に光沢ディスプレイは嫌いなんですが、まぁ最悪半光沢にするフィルムを貼ればいいや・・・、ということで、4Kに挑戦してみました。 まだ届いたばっかで、ブラウザとかしか見ていないんですが、確かにフォントのくっきりさ具合とかが、あんまり気にしない私でもはっきりと違いが感じられる程度には違いました。 何で3080じゃないの？ Alienware M15 R4には、3080のオプションがあります。今回これを選択しなかった理由は、 たけぇ +10万です しかし、ノート用のspecなので、VRAM 8GB 価格帯性能比を考えると、同じVRAMで3070の方が7万くらい安い そもそも3080が必要なほどのゲームをしない 4Kのリフレッシュレートは60Hzです。それでもそもそも厳しい という感じです。特に、価格帯性能比の割合が強いですね。3080にしたところで排熱が追いつかなければ宝の持ち腐れでしかないです。 なぜAlienware？ この4年くらい、ゲーミングノートは大抵MSIにしていました。理由としては、2kg前後の重量で、十分な性能と実績があるのが、MSIだったから、という感じです。Asusとかでもよかったんですが、どうもキワモノの印象が強かったです。 しかし、今回買い替えるにあたって、色々なレビューサイトを巡り巡ったところ、MSI/Asusは、排熱に問題を抱えている・・・という話題が多くありました。確かに、MSIを使っていたときも、特にCPUの熱があまりに大きいので、電源設定を変更してCPUにboostさせないようにしていた、ということがあります。というかそうしないと、CPUファンの音が危険なレベルに達してしまうので・・・。 今回はAsusにしようかなー、とも思っていたのですが、狙っていたモデルのレビューが芳しくない・・・。と思っていたところで、Alienwareのレビューを見たところ、排熱がかなり改善されてきており、R4ではさらに改善されている・・・、という記事を見付けました。 これが決め手になり、初のAlienware、個人では10年振りにDellからPCを購入することと相成りました。 これから とりあえずSteamとDiscordは入れたので、ぼちぼちゲームをやっていこうかな、と思います。後はWSL2を入れたりー、とかもしますが、それはまた後で・・・。 いまどきのゲーミングノートは、Macbookと然程変わらない重量で、30X0系統が載るようになっていますんで、お財布に余裕があれば検討してみちゃーいかがでしょうか。

久々に４連休となったので、たまには頻度高めにブログを書いてみることにします。 今回は、前回SKKにしたということを書きましたが、それの辞書サーバーについて書いてみようと思います。 <!–more–> SKKと辞書サーバー SKKを使ったことがない方は、辞書サーバーといってもなんじゃそりゃ？となるでしょう。辞書サーバーとはそのままの意味で、SKKの辞書を提供するためのサーバープログラムを指します。 SKKの実装では、大抵はSKK辞書をインプットメソッド内にメモリとして展開し、それを利用しています。当然ながら、この形式では複数のインプットメソッドがあったら、各々でメモリを消費してしまいますし、管理が煩雑になりがちです。 そのため、SKKのほとんどの実装では、SKKプロトコルというプロトコルにもとづいたサーバーも辞書の一つとして利用できるようになっています。サーバーとして一つにまとめることで、複数のインプットメソッドから同時に利用することもできる、ということです。 ddskkでの辞書サーバーの設定 辞書サーバー、使う？ さて、辞書サーバーを使うといいことあるじゃん・・・と思いたいところですが、実際は中々そうはいきません。なぜかというと、使ってみたり運用してみた限りでは、以下のような問題があります。 SKKプロトコルがEUC-JPを前提としていて、UTF-8全盛の今にそぐわないケースが多い 実際に複数のインプットメソッドから利用すると、以外と面倒くさいケースが多い そもそもメモリが多くなったので、各々で利用しても問題にならないケースが多い 一個ずつ見ていきます。 SKKプロトコルの問題 SKKが開発されたのは1987年、佐藤雅彦氏によって開発されたのが初版とされています。 参考 当然ですが、1987年当時にはUnicode consortiumすらありません。(Wikipedia)なので、日本語を扱える文字コードは、事実上 EUC-JPとShift-JISの2強 でした。Linuxにおいては、EUC-JPがデファクトスタンダードの地位を確立していた(らしい)ので、日本語のかな漢字変換プログラムであるSKKがEUC-JPを前提としていても、何の不思議もありません。 さて、しかし時は経ち、現代ではUTF-8がデファクトスタンダードとなりました。そうなると困るのは、EUC-JPでしか扱えない、というプロトコルの問題です。これはSKKプロトコルの定義を修正しない限りはなんともならないです。事実、macOSで一番使われていると思われるAquaSKKでも、serverとのやりとりはEUC-JPに固定されています(辞書はUTF-8も扱えます)。 なので、辞書がUTF-8だったり、エンコーディングがUTF-8だったりすると、上手く変換できなかったりと、問題が発生しがちです。 複数のインプットメソッドからだとめんどくさい問題 プロトコルの問題でも上げましたが、辞書と辞書サーバーの文字コード、インプットメソッド内での扱いなどが異なる場合がある、などの事情があります。なので、以外とサーバーをそのまま利用できるケース、というのは少なかったりします。 仕事用のmacOSで、AquaSKKとEmacsで共通の辞書サーバーを使おう、と思ったりしましたが、このへんが上手くいかずに挫折したりしています。 そもそもメモリが多くなった 1990年くらいのPCは、メモリがMB単位とかあるとそれだけですげー、ってなった時代でした。今は2桁GBがあたりまえです(個人の感想です)。個人所有しているPCも、32GBとか積んでいます。 片や、SKKの辞書は、他のIMEと比較してもかなり小さいほうだと思います。実際に計測してみたら、SKKが配布している辞書を全部統合した辞書(コンパイル後)で、22MBしかありませんでした。 32 * 1024MB のメモリ空間があるところに、高々数十MBの辞書をメモリに展開したところで、ほとんど影響がないのは明白でしょう・・・。 それでも辞書サーバーを使ってみる 色々問題があるにはある辞書サーバーですが、それでも使ったことがないから使ってみたい、というのは人の性でしょう。ですので使ってみます。 さて、SKKには歴史があるので、当然ながら辞書サーバーも色々な実装があります。ここで挙げるのは蛇足なので、 Wikiへのリンクを貼っておきますので、気になる方はこちらから。 Google IME≒mozcを利用して、候補を取得したりする・・・という変わり種もあったりしますが、そこまで変わり種を使いたいわけでもないので、シンプルな辞書サーバーを選択してみます。 実際、速度の面などを考えると、C/C++で作られたサーバーがいいかな・・・と最初は考えました。 yaskkservは、かなりこなれた実装でもあり、かつGentooでも使えるものです。 が、これもまた歴史のあるツールなので、色々内部構造的な問題がある、ということで、作者の方がRustでリライトした yaskkserv2というのを開発されています。 ちょうどFirefoxとかをビルドしている関係上、Rustがマシンに入っているということもあり、これを使うことにしました。(見切り発車すぎる) yaskkserv2のビルドとか これらは、Emacsの起動時に、対象のプログラムが存在していなければビルドしてインストールするようにしました。ただ、ビルド環境が無い場合は、バイナリを落として展開するようにしています。 (leaf *skk-server :after f :if my:use-skkserver :init (let ((server-program (expand-file-name "yaskkserv2" my:user-local-exec-path)) (dictionary-program (expand-file-name "yaskkserv2_make_dictionary" my:user-local-exec-path))) (cond ((and my:build-skkserver (executable-find "cargo") (not (executable-find server-program)) (not (executable-find dictionary-program))) (let ((base-path "/tmp/yaskkserv2")) (unless (f-exists? base-path) (call-process "git" nil nil t "clone" "https://github.com/wachikun/yaskkserv2" "/tmp/yaskkserv2")) (call-process "cargo" nil nil t "build" "--release" "--manifest-path" (expand-file-name "Cargo.toml" base-path)) (unless (f-exists? server-program) (f-copy (expand-file-name "target/release/yaskkserv2" base-path) server-program)) (unless (f-exists? dictionary-program) (f-copy (expand-file-name "target/release/yaskkserv2_make_dictionary" base-path) dictionary-program)) )) (t (let* ((target (cond ((eq window-system 'ns) "apple-darwin") (t "uknown-linux-gnu"))) (path (format "https://github.com/wachikun/yaskkserv2/releases/download/%s/yaskkserv2-%s-x86_64-%s.tar.gz" my:yaskkserv2-version my:yaskkserv2-version target))) (call-process "curl" nil nil t "-L" path "-o" "/tmp/yaskkserv2.tar.gz") (call-process "tar" nil nil t "-zxvf" "/tmp/yaskkserv2.tar.gz" "-C" my:user-local-exec-path "--strip-components" "1")))))) 辞書のコンパイル時の注意 yaskkserv2は、独自の辞書形式を利用しているため、SKKの辞書はそのまま利用せず、 yaskkserv2_make_dictionary というツールから変換する必要があります。 ...

気がついたら2月でした。書き出しがほとんど前回と一緒なので、そのへんなんとかしたいところです。 さて、実は今回結構大きめの決断をしたので、なんでそれに至ったのかを書いていきます。まぁそこまで強い理由がある、というわけでもないのですが。 <!–more–> かな入力、やめました 今まで、 https://github.com/derui/oif こういうものまで作って色々かな入力を試してきました。実際に使っていたと思しきコミット履歴を見てみると、2013年とかになっているので、都合7年くらい前からですね・・・。 実際、ほとんどはマイナー配列に属するようなものばかりでしたが、それなりの数を使ってきました。 月配列 新下駄配列 蜂蜜小梅配列 薙刀式 この中で一番長続きして、かつ速度が実用に至ったのは、月配列と蜂蜜小梅配列です。どっちも秒間3〜4カナとかは普通にいけてました。ちなみに、上二つが中指シフト、下二つが親指でのシフトです。 しかし、これを書いている現在は、AZIK + SKKという組み合わせになっています。SKKは多分8年振りくらいに戻ってきました。AZIKはなにげに初めてですね。 なんでかな入力をやめたのか これはいくつかの理由が複合しています。決してその配列に問題があるわけではない、ということは強調しておく必要があります。 親指の負荷が馬鹿にならないレベルになってしまった SKKとの相性が悪すぎた どうしても運指がローマ字入力の速度になってしまう 一つずつ少し深掘りしてみます。 親指の負荷 まず、私が使っているキーボードは、 Crkbd である、ということが前提にあります。このキーボードでは、一般的なキーボードよりも親指に色々機能を割り振ることを前提としたキー配置になっています。 詳しくは、私のキー配列を見てもらうとわかりやすいのですが、かなりの量の機能を割り振っています。 https://github.com/derui/qmk_firmware/blob/master/keyboards/crkbd/keymaps/derui/keymap.c 簡単に挙げると、 LOWER/RAISEでの数字・記号の入力 SandS/SandEnterによる、小指でのシフト全廃 かな・英数のトグル ADJUSTに矢印やsway/i3用の定義が満載 という感じで、普通のUS/JISキーボードとは比較にならないレベルで機能を割り振っています。親指でのシフトを行うかな入力は、これに加えてシフトをしないといけないため、親指の負荷が半端じゃありません。 親指は強い指ではありますが、それは筋力が強い(元々は支持するための指なので)ということであり、ほかの4指に比べたら遥かに鈍いということもあります。実際、親指に機能を割り振りすぎたゆえに、親指に変な痛みが生じたのは一度や二度ではありません。 SKKとの相性 これは一言です。 親指シフト系統とSKKの相性は最悪 です。少なくとも私にとっては。SKK自体では、一応NICOLA/旧JISかなをサポートしてはいますが、それを参考にしてみた限りでは、とてもではないですがQWERTYでの書き味とは全く異なる、と言わざるを得ません。 SKKとの相性自体は、そもそもSKKを使わなければいいじゃん、という話もありますが。SKKは一回使うとクセになってしまうところがあるので、相性が悪いということが許せなくなってしまった、というのもあります。 大分四苦八苦してみましたが、最終的な結論としてはこうなりました。多分、親指の負荷が低い月配列や新下駄配列であれば、そこまでの問題にはならないんじゃないかとは思いますが。 運指速度の問題 これは、特に親指でのシフトをする配列で顕著でした。今迄20年以上使いつづけており、かつプログラムを書く際にもずーっと使いつづけているのがQWERTY、そしてローマ字入力です。このときの運指速度がデフォルトになってしまっており、これとかな入力時の運指速度がバッティングしてしまう、ということが度々発生していました。 同時打鍵を要求する配列は、仕組み上どうあがいてもローマ字入力に匹敵する運指速度になることはありません。名目の打鍵数が低いから問題ない、とする向きが強いですが、同時打鍵という仕組み上、実際には少なくない数の打鍵は2打鍵必要です。 このあたりで折り合いを付けられなくなった、という形です。 かな入力はダメだったのか ある程度の速度にまでは到達できていましたし、実際には打っていて楽であった、ということもあります。なので、ダメだった、という二元的な評価ではありません。 単純に、合うか合わないかを実験してみた結果として、合わなかった、ということです。ブログでもなければ、プログラムを書く量の方が多い日もある、という事実もあるので、どちらにせよQWERTYの配列を変える方が余程効果がありそうですし。 AZIK + SKK さて、AZIKですが、これはこれでSKKで使われる上で、いくつか問題がありました。 q が潰される ; が「っ」になるので、switcky keyが使えない X が「sy*」の接頭になるので、辞書の削除が使えない これらをとりあえず解決してみました。こんな感じになります。 ;; azikを利用するように (setq skk-use-azik t) (setq skk-azik-keyboard-type 'us101) (require 'skk-azik) ;;; azikから追加された各種拡張を、SKK寄りに戻すための追加設定 ;; 「ん」をqに割り当てるのは、ただでさえ負荷の高い左小指を酷使することになるので、元に戻す (skk-delete-rule skk-rule-tree "q") ;; qの役割を元に戻したので、「も元に戻す (skk-delete-rule skk-rule-tree "[") ;; Xで辞書登録する場合があるので、この場合でもちゃんと破棄できるようにする (skk-add-rule skk-rule-tree '("!" nil skk-purge-from-jisyo)) (skk-add-rule skk-rule-tree '("q" nil skk-toggle-characters)) (skk-add-rule skk-rule-tree '("[" nil "「")) SKKは、 skk-add-rule とか skk-delete-rule といった便利関数を提供しているので、こういうのが簡単にできます。注意としては、 skk-azik は、何か関数を呼びだして変換ルールを設定しているわけではなく、requireされた瞬間に変換ルールを設定しているので、事後に追加したり削除したりしないといけない・・・ということです。 ...

ふと気づいたら年が終わりそうですね。今年はどこもかしこも大体コロナのせい、という感じになりましたが。 前回PCを新調した話をしましたが、中身も1x年ぶりに新調しました。いろいろ変えたので、その話を書いてみます。 ...

私用でいろいろ忙しかった原因である引っ越しが終わりました。数えたら8年半くらい同じ場所に住んでました。 で、引っ越しを期に自作PCを新調したので、それについて書いてみようと思います。 <!–more–> なんで新調したのか？ 心機一転、という話もありますが、一番は 使っていたPCがめっちゃでかい ってことでした。 ちなみに前のPCで使っていたケースはこれです。 Themaltake Urban T81 https://kakaku.com/item/K0000626152/?cid=shop_yahoo_dsa_00010032&yclid=YSS.1000163161.EAIaIQobChMI5MqMh6LH7QIVV3RgCh3HQAkMEAAYAyAAEgLUW_D_BwE フルタワーケースで、全高が 61cm あります。このサイズの何が問題というと、実際に問題として感じていたのは以下のような点です。 入るPCラックがほとんどない 入手できそうなもので唯一入りそうだったのがこれです。これも割とギリギリまで伸ばさないとならなかった・・・。 重い スチールラックなので当然ですが、重いです。全部部品が組み込んであると、だいたい20kgくらいになるので、ダンボールに入れるのも一苦労です（でした よく考えたらそこまででかくなくていい ディスクの拡張とかそんなにしないし、でかいGPUを積むわけでもないし・・・ また、途中で一回M/Bのメモリ部分が故障してM/BごとCPU/Memory/CPUクーラーを全部新調したことはありますが、都合6年ほどこのケースを使っていたというのもあり、全面新調に至りました。 とりあえず新しいPCの構成 構成はこんな感じです。大体アッパーミドルくらいかな・・・。 ケース：Fractal Design Define R6 評判のいい、ミドルタワーケースです CPU：Ryzen9 3900XT CPUクーラー：Nocture NH-U12A かなり高価なクーラー。しかし、Ryzen9シリーズを空冷で冷やそうとすると、これくらいは欲しかったので SSD システム：Crucial M.2 P5(500GB) ストレージ：Crucial MX500 1TB HDDを卒業して、full SSD構成にしました。NVMeも使ってみたかったので。 Memory：Corsair 16GBx2 電源：Corsair RM750 GPU：Radeon RX 5700XT マザーボード：ASRock Steel Legend B550 初めて全面的にAMD構成にしてみました。Ryzenの5xxxシリーズは全滅していたので、潔く3900を使っています。 ちなみにお値段は、しめて21万程度でした。ドスパラでまとめて購入しましたが、BTOでも大体同じくらいの値段になっていたので、まぁ相場通りかな、と。 組んだ 大体2時間くらい・・・。毎回組むたび思うのは、システムパネルのケーブルはもうちょっと楽にならんのか・・・。というところですね。 ASUSのM/Bを使ったときにあった、 Q-Connector はほんとに楽だったので、これが標準添付されてほしいです。 https://www.pc-master.jp/jisaku/fp-connector.html ここで紹介されてるみたいなやつです。システムパネルはたいてい最後の方に組み込むことが多いと思うので、割と無理のある姿勢で細かい作業をしないとならないことが・・・。 とりあえずは、ちゃんと動きました。相変わらず最初の起動は緊張しますね。幸い今まで初期不良にはあたったことが無いのですが、ここで動かないときの絶望たるや凄まじいことと思います。 OSをインストール・・・できない？ さて、このPCにインストールするのは、かれこれ10年くらい使い続けているGentoo Linuxです。ただし、今回はCPUが切り替わるということもあったので、10年ぶりにclean installすることにしました。 いつもの通り、USBにminimal imageを書き込んで起動、さてstage3を持ってくるかー、というタイミングで気づきました。 ...

すっかり在宅に慣れてきましたが、ちょっと出かけることも出来ないというのが割とストレスですね・・・。 最近は出勤時間分の時間が空いたので、環境の改善をよく行っています。そんな中で、日本語入力も改善したので、それについて書こうかと思います。 <!–more–> qmk_firmwareと日本語入力 いくつかqmk_firmwareでカナ入力の方式を実装してきましたが、今までの実装だと、以下のような問題がありました。 どうしてもローマ字で入力させる必要があったため、マッピングが肥大する 肥大すると、当然ながら他の機能を追加できないため、使い勝手が悪い 濁音を後置する場合、どうしても不自然になる 本来であればIME側でやってくれることを、ファームウェア側でやる必要がある 遅延で入力させることもできるが、いかんせん表示がかなり不自然になる 特にnew stickney配列を使うようになって顕著なのが、濁音後置になったため、濁音の入力時に考えなければならないことが増えました。 timerを使った遅延入力にすると、出力自体が遅延するため、今入力している内容を把握するのが大変です。濁音キーを入れた時に、一回入れた文字を消して新しい文字を入れる、ということもしてみたりしましたが、これはこれで誤動作が多く、今ではお蔵入りになっています。 なぜIMEのかな入力を使わないのかと IMEでローマ字ではないかな入力を使えば、こういう問題はある程度解決されます。今までやってなかったのは、ひとえに マッピングがめんどくさい という点が大きかったです。 また、ローマ字では、キーボードのレイアウトがUSでもJPでも全く問題なく扱うことが出来ますが、かな入力では、USではそもそも入力できないキーコードが必要になります。こういった点を解決できるのかが把握できなかったため、放置していましたが、一念発起して対応してみました。 対応した結果 こんな感じになりました。key sequenceが1文字になったことと、濁音と半濁音のハンドリングを自分で行う必要が無くなったため、全体の容量は減っています。 https://github.com/derui/qmk_firmware/tree/master/keyboards/crkbd/keymaps/derui ただ、小書き文字に対する対応が必要であるため、母音を入力するときだけは遅延が発生する状態です。慣れればdelayを低くしてもいいとは思いますが、今のところは置いておいてます。この小書き文字の部分をスマートに実装できれば、かなりの使い勝手になりそうだと勝手に思ってます。 また、Emacsでの設定も追加しました。 (setq mozc-keymap-kana mozc-keymap-kana-101us) この対応をした結果、以下のようになりました。 Fcitx + mozcでは特に問題なく使える Emacs + mozcでは、 ろ と ー に対応するkey codeをハンドリング出来ていないため、本来の入力と異なるmappingが行われてしまっている この２つ以外は、問題なくnew stickney配列を再現できている Emacsでもfcitxを使って、mozc.elを使わない、とかすればいいかもしれないが・・・ mozc-keymap-kana-106jp というkeymapに変更すると、異なる文字が入れられるようになってしまう 多分USレイアウトとJPレイアウトで記号が異なる部分で違っている USレイアウトにないkey codeをハンドリングすることが出来ればなんとかなるので、mozc.elの中を覗いているところ 仕事で使うMacでは試していない ローマ字でいいじゃん、という誘惑との戦い 正直、これだけやっていても、仕事で急いでいるときにはローマ字で入力してしまっているという体たらくなので、ローマ字でいいんじゃないか？と思うときがないわけではありません。 特に、価値のあること（大抵金銭的なもの）以外に時間を使うことに対して否定的な環境にいると、非効率自体が無駄とみなされがちです。 しかし、異なる入力方法に親しむということは、異なる能力開発をしている、ということでもあります。この入力を自然に行うためにはどうするべきか？という問いに答えるのは自分しかいません。問題解決能力を鍛えるということは、みんな大好き人生１００年時代にもマッチするのではないでしょうか。 なんだかんだ書いてみましたが、つまるところ自分の趣味なので、まー好きにさせてくれよ、というところでしょうか。 かな入力はIMEに任せよう 濁音後置型のかな入力は、IMEのJISかなに任せると楽が出来ます。新下駄配列とかの濁音も一モーションで入力するような配列では工夫する必要がありそうですが、送信するキーシーケンスの数は減るはずです。 qmk_firmwareでカナ入力を実装している方の参考になれば幸いです。

個人的に作っているツールで、OCamlでどうやってDDDをやっていくか？ということを考える中で、 Domain Modeling Made Functionalというそのものズバリな本の存在を知りました。そこまで高くなかったので購入して読んでみたので、感想を書いてみます。 <iframe style=“width:120px;height:240px;” marginwidth=“0” marginheight=“0” scrolling=“no” frameborder=“0” src="//rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=derui09-22&language=ja_JP&o=9&p=8&l=as4&m=amazon&f=ifr&ref=as_ss_li_til&asins=1680502549&linkId=05192cc54dff2d67c58d290cad5cdd28"></iframe> <!–more–> どんな内容？ すごい簡単に書くと、 F#でDDDをやっていく時のノウハウが詰まっている 本です。たいていこういう本はScalaとかHaskellで書かれている印象（偏見）なので、F#というのが中々ニッチな印象でした。 ちなみにF#を知らない方のために紹介だけしておくと、F#は以下のような特徴を持つ言語です。 OCamlをベースにした関数型言語 ベースにしているので、命名規則とか文法とかは違いますが、ML族です なので、型クラスとかはありません .NET Platform上で動く 多分.NET Coreでも動くんではないでしょうか OCamlを使っている人間としては、F#の文法は若干の違和感を感じるくらいで、特に読みづらさとかは感じませんでした。 もうちょっと細かい内容 概ね、以下順で進んでいきます。 DDD自体の解説 仮想プロジェクトを使ったDomain導出の流れ この部分が、対話形式になっていてなかなか面白いです。また、ダイアグラムなどをあえて使わず、擬似言語を用いてユビキタス言語やビジネスの制約とかを書き下しているのが印象的でした。やってみたい ドメインをどうやって型に翻訳していくか ここからが関数型言語（特に代数的データ型を持つ言語）でどうやってドメインを型にしていくか、という話題です。この時点では実装を一切考えず、ビジネス要件を型の表現力でどう表現するか？に注力しています。 ワークフローをどう表現するか ビジネス上のワークフローを、小さいstepという関数で表現していくか、という内容です。ここでも実装そのものは行わず、step/work flowをひたすら型で表現していきます。 型に対する実装 ドメイン自体、そしてワークフローに対して行った大量の型をどのようにつなぎ合わせていくか、という内容です。ここから実装が登場します。バリデーションやエラーを扱う話題もあります。 関数でワークフローを表現した時、stepの依存などをどのように扱うか、という内容もあります。関数適用をDependency Injectionとして利用するなど、関数型言語で一般的なテクニックなども紹介しています。 エラー実装、永続化、シリアライズなど現実的な内容それぞれ独立した章に分かれていますが、全て実装に関する内容です。 エラーでは、主にResultをどう扱うか、Resultをどう繋げていくか、といった実践的な内容となっています。永続化、シリアライズでは、DBやJSONへのシリアライズなど、主にWebアプリケーションで扱いそうな内容を多く扱っています。 特に印象に残った点 DDDに当たる部分は、Evans本やIDDD本を読んでいれば、ある程度は読み飛ばしてしまっていいと思います。そこ以外で印象に残っていたり、参考になったものがいくつかあります。 とにかく型で表現する 文中には、必要に応じて減らしてもいい、という書き方をしています しかし、step/work flowすら型で表現する、というのか魅力的です IDとかは、実際にはfunctorで作ったり、ある程度自動的に導出することも出来るので、方はある程度多めになってもなんとかなる気はします Monadは必ずしも必要ではない 実際、文中ではMonadという言葉をほとんど使っていません 言及している部分では、 それほど恐れる必要はない という記述になっています Free Monadなどにも触れているので、実際のアプリケーションなどでは使うかもね・・・というニュアンスなのかもしれません 関数適用はDI 最近オブジェクト指向言語ばかりやっているのと、部分適用して使う、というのが普通すぎて、逆に目からウロコでした IOはEdgeに追いやる DomainはIOを知るべきではない、というのを何度も書いています Clean Architecture/Onion Architecture/Hexagonal Architectureといったアーキテクチャをより簡潔に言い表したものだなーって思います Edgeにどうやって追いやる？関数を使えよ、という当たり前の内容もちゃんと書いてくれています 最近OCamlで書いていると、なんとなくFunctorを使ってしまう部分でも、より基本的な関数をまず使おう、と思い直しました DTOをきっちり使う重要さ Domainを直接JSONなどに変換してはならない理由をちゃんと説明している点が非常に良かったです 個人的にもDomainをそのままAPIなどに露出しないようにしていますが、次からは何故そうするのか？と説得できそうな気がします 現実だと工数がかかりすぎる、とか言われそうですが・・・ 型パズルの解き方 大量の型が出てきた時に、どのように関数を繋げていくか、という方法論が書かれています 関数型言語でもDDDをやりたい人にはオススメです DDDをJavaとかC#、他の言語ではやっているけど、関数型言語ではどうやるんだろう、Monadとかよくわからない概念のオンパレードになるんじゃないか、とか思っている人にオススメです。 ...

せっかくの個人ブログなのでこんなものも書いてみます。レビューというか感想ですね。 <!–more–> SEKIRO -SHADOWS DIE TWICE- （PS4版。以下SEKIRO）のプラチナトロフィー取得が終わったので、感想を書いてみます。完全に個人的な感想ですので、仮にこれを読んで買って満足できなかったとしても保証はできかねます。ご了承を。 なお、完全にプラチナ狙いで行ったので、3週目で終了しています。 書いている人間のスペック 前提として、この記事を書いている人間のゲーム的スペックを書いておきます。ライトではないがガチでもない、という普通の領域だと思います。 Demon’s Soul/Dark Soul(1のみ)/Bloodborneクリア経験あり 基本PS4/PCのゲームが主 やり込むというよりはトロフィー狙いが多い 最初の一周は一切攻略サイトとかを見ない、がポリシー どんなゲーム？ 死ぬことを楽しむゲームです なんの説明にもなっていないですね。ちゃんとした紹介は↑の更新サイトを見たほうが早いと思います。Demon’s Soul/Dark SoulやBloodborneをプレイしたことがある方であれば、ああいう感じ、と言えば伝わるでしょうか。SIEとFROM Softwareが手を組んだ作品です。ちなみに SEKIRO は せきろ と読むのが公式だそうです・・・ほんとか？ すっかりSoulライクゲームがFROM Softwareの代名詞になりましたが、30代くらいの人にとっては FROM Software＝アーマードコア とかなんじゃないでしょうか。もうアーマードコアが出ることはなさそうですが、もう一回プレイしてみたいものです。 閑話休題。 さて、Soulライクゲームと同じような感じ、と書きましたが、その内容は大きく異なります。同じなのは死んで覚える、というくらいです。私は最初の一周は公式サイト以外を見ないことにしているので、死にっぷりに拍車がかかります・・・。が、できればSEKIROやSoulライクゲームは最初だけは攻略サイトとかを見ないようにするのをおすすめしたいです。そのあたりは個人の裁量なので、最初からガッツリ見るも詰まったら見るも自由ですが。 SEKIROとSoulライクゲームの違い 簡単に箇条書していきます。 レベル概念の撤廃 Dark Soulとかでは、キャラクターの成長自体が個性になりますが、SEKIROでは成長要素は2つしかありません また、大抵のスキルは プレイを楽にする のではなく、 多様な攻略 を可能にするものなので、これを取ると楽になる！というのはあんまりないです 武器・防具の概念がない 最初っから最後まで装備は一緒です。アイテムで一時的に変更する以外、防御力を上げる手段は（把握している限り）ありません スタミナの概念がない 忍者なので 回避し放題、ダッシュし放題、攻撃し放題です 移動の自由度が圧倒的に高い 鉤縄のおかげで、探索が非常に楽しいです。 致命の一撃を狙うのが基本 HPを削り切る、というパターンは多くないので、特に雑魚戦における戦闘のテンポが非常に早いです ソウルの回収的な要素がない 死んだらそのタイミングできっちり経験値とかが半分になります 救済措置はありますが、あんまり期待しないほうがいいです 要素としては色々ありますが、とにかくゲーム内の要素が 剣を交えること に特化されている感じです。 キャラクターの成長＝自分の成長 Soulライクゲームでは、ある程度はレベルを上げてゴリ押し、ということができました。しかし、前述したとおり、SEKIROではレベルという概念がありません。アイテムを利用しないと、キャラクター自体の成長はありません。そして、そのアイテムは一部を除いて ボスを倒さないと取得できません 。 つまり、ボスで詰まった場合、 自分自身の腕を上げないと攻略できません 。ここでの腕は、相手のパターンを見切る、ということも含みます。この点がSoulライクゲームとの一番の相違でしょう。 逆に言うと、ボスに勝てた＝自分が成長した、ということにほかなりません。特に大ボスは、トドメにイベント的な最後の一撃が必要なんですが、それを行う＝勝利なので、イベント的な演出も含めて 勝利した瞬間の快感は凄まじいです （個人差あり）。 その快感を得るために、次のボスに向かってまた何度も死ぬ・・・と繰り返すことになります。その過程で、ベースになる腕も上がっていきます。 剣戟 を体感する 弾きと体幹システム上、基本的には攻め続けて、相手の攻撃は弾き（＝ジャストガード）し続ける、というのが理想です。そこに至るまでには何度も死ぬことになりますが・・・。逆に、そこに至ると、まさに映画のような剣戟を繰り広げることができます。これがまた気持ちいいんです。 ...