Loox Uと初音ミクで行こう！

electronのリリース用ファイルサイズを半分以下にした 本日、 きつねゆっくりリネーマーVer 0.0.2 をリリースした。 基本機能は変わっていないが、リリース用のファイルサイズを半分にした。 変更箇所 変更箇所は、package.jsonのbuild。 変更前 "files": [ "dist/**/*" ] 変更後 "files": [ "!.git", "!.dist", "dist/background.js", "dist/index.html", "dist/preload.js", "dist/assets/**/*", "node_modules", "package.json" ], 変更したのはここだけ。 以前のバージョンは、dist以下全部をビルドするようになっていたが、今回は、ビルド用のファイルを個別に指定するようにした。 node_modulesやpackage.jsonやら、色々書いているが、多分要らない。 今後、実験してこの辺はアップデートしていく予定。 推測 以前のビルド設定だと、dist以下を全部包含して作っていたため、同じファイルを2回パッキングしていた可能性がある。 ひどい。 まあ、何も知らないで作るとこうなるという話なので、もし似たような件で悩んでいる人がいたら参考にしていただければと思う。

ワクチン接種三回目 三回目のワクチン接種を木曜日に行ってきた。 そして、昨日は完全に死に体で過ごしていた。 こんな時間になってようやく復活という形。 一回目と二回目はファイザーだったが、三回目はモデルナを接種。 当日は、寝る時に謎の悪寒に襲われて、これやべーわとなったが、案の定翌日は完全死亡。 高熱（測れなかったが、恐らく３８度近く）と全身の倦怠感で色々ときつかった。 お医者さんには、少しでも痛みがあったら痛み止めガンガン飲めと言われてたので、痛み止め（自分はイブＡ錠が相性良いので、イブＡ錠を飲んだ）をガンガン飲んで、横になっていた。食事もろくに作れない状態だったので、事前に簡単に食べられる物やウィダインゼリー的な物を用意して、耐え忍んだ。 誤算だったのは、ポカリスエットを３L用意していたのだが、それが全く足りなかったという点だ。結局、合計で４．５L消費した。 もし、四回目があるなら、ポカリは３本用意しないと駄目だな……。 痛み止めの効果は抜群で、飲んだ後は大分楽になり、ちょっと買い物に行くくらいの元気は出た。 １回目と２回目は特に副反応が出なかったが、３回目はワクチンの本気を感じた。 しかしながら、諸説あるように副反応出たほうが強い抗体が出来るとかなんとかという話なので、これで大分強化されたと思い込むことにしている。 思ったよりも、キツい副反応が出たが、鎮痛解熱剤があれば人類は戦えるので、みんな鎮痛解熱剤をしっかり用意して戦おう。 バファリン、ロキソニン、イブのどれかで戦える。 ちなみに、ロキソニンのパチもん（？）も用意して飲んだが、それよりもイブの方が効いたのは多分体質的な物と思われる。僕はイブの方が相性良かった。

きつねゆっくりリネーマーを作った きつねゆっくりリネーマーという名前のツールを作りました。 こちらからアクセスしてください 技術関連に関するあれやこれ 今回は、自分の主戦場でもあるJavaScriptをベースにツールを作ろうという事で、色々模索した結果 vite+TypeScript+electron という技術選定になった……が、実際にはTypeScriptはほぼ使っておらず、JavaScriptメインでの実装になってしまった。 これに関しては、今後のアップデートなどで更新出来たら良いなぁぐらいに思っている。 electronでfsなどを使うためには、色々工夫が必要で、preload.jsにcontextBridgeやらipcRendererを経由して、background.jsでデータをやりとりするみたいな感じになった。 レンダラーの所では、window.API名みたいな感じでアクセスするのだが、これの部分にはちょっと工夫が必要で、 App.tsx を見てもらえば分かるのだが、 declare global { interface Window { api?: any } } の設定と、関数内で、 if( window.api ) というチェック処理が必要になる。これをやらないとコンパイルが上手く通らない上、画面が真っ白になって動かないというバグがあった。 これは、デバッグモードでは見つけることが出来ないバグだったので、色々と辛かった。 まあ、いずれにせよ、このツールを作る事で、electronアプリの作り方を一通り体験出来たのは良かった。 nodejs周辺のライブラリを使うのにはかなり工夫が必要なのだが、一旦覚えてしまえばそこまで複雑な処理ではないので、勉強できて良かった（小並感）。 その他今後やっていきたい事 今回、ビルドしてみて改めて思ったのは、electronアプリのサイズがでかすぎるという事。 Hello,worldレベルのアプリに125Mは流石にでかすぎる。 サイズ的には30Mとか40Mくらいに抑えられるものだと思っているので、今後何かしら良い方法を知ることが出来たら、それで実装してみたいと思う。

ddu.vim へ移行する 昨日、重い腰を上げて、 denite.vim から、 ddu.vim への移行を行った。 基本的なセッティッグは、ddu.vim の README.md を読めばある程度出来る。 とは言え、ddu.vim の理念を理解していないとそもそも使えないプラグインなので、理念を含めて説明していきたいと思う。 ddu.vim とは ddu.vim は、 Shougo さんによって開発されている、Vim プラグインである。 Unite.vim や denite.vim の流れを組むプラグインであり、物凄く雑に説明すると、Vim で操作できる全てをコントロールしようというプラグインである。 雑すぎねーか。 Unite.vim からこのコンセプトは変わっていないが、Unite.vim は速度が遅いという欠点を抱えていた。 そこで、速度改善のために、pure Vim Script から脱却し、Python3 を採用したのが、denite.vim。 しかし、denite.vim は Python 回りのでトラブルが多かった。 そういう地獄のような状況で、 denops.vim というプラグインが登場する事で環境が一気に変わった。 denops.vim は、 Deno を Vim で使えるようにするプラグインで、これがべらぼうに Vim と相性が良かった。 早いし、色々なことが出来るなど、非常に柔軟な対応を出来るようになった。 Python ちゃんは要らなかったんや……。 簡単にまとめると、 ddu.vim は全てを繋ぐ 環境依存性を著しく下げる denpos.vim の登場により、環境構築が容易に Deno を採用することで高速性と柔軟性を担保 と言った、まさしく次世代のプラグインと呼ぶことが出来る。 ddu.vim の概念 ddu.vim には、 UI sources filters kinds という概念があり、これらも合わせてインストールが必要である。 それぞれ好きな物をインストールすれば良いと書いてしまえばそれで終わりなのだが、初めて導入する人にとっては何を言っているのか意味が分からないと思う。 UI は、文字通り、ユーザーインターフェースである。 とりあえず、ファジーファイン

netlify で node-gyp のビルドが失敗した時 node-gyp という、nodejs回りを触っていたらなんか勝手にインストールされる奴がいるんだけれど、毎度毎度ビルド回りで、困らせてくる。 今回は、netlifyでビルドしようとした時にこいつのビルドが出来なくて、困ったので、その備忘録。 自分がビルドしようとしたnode-gypのバージョンは、8.4.1（2022年3月現在）。 こいつのビルドには、どうやらPython3.6以上が必要。 しかし、netlifyのデフォルトでは Python3.5.2が使われていたのでコケてしまった。 なんだこいつ。 https://docs.netlify.com/configure-builds/environment-variables/ と、 https://github.com/netlify/build-image/blob/xenial/included_software.md を見て、どうやらPYTHON_VERSIONに3.7を指定出来るようなので、Deploys > Deploy settings > Environmentを選び、PYTHON_VERSIONを追加した。 ついでに、NODE_VERSIONも今使っている16.14にアップデートしておいた。 これでビルドが上手く通った。 node-gypって何に使ってるん？ node-gypって何に使ってるんでしょうね。 なんか色々入れていると気がついたら毎回入ってくる感じで、マジで捨てたい。 こいつのビルドエラーは頻繁に起こっている印象があり、開発体験を著しく悪くしているのでなるべくサクサクと倒せるようになりたい。

たかが殺人じゃないかの構成は最高だった たかが殺人じゃないかを読了した。 実は、辻真先氏の作品を読むのがこれが初。 ミステリーランキング3冠を達成した作品であり、面白いというのは前評判から知っていたが、想像を超える良さだった。 構成が素晴らしい まずは、なんと言っても、この作品は構成が素晴らしすぎる。 ミステリファンであればあるほど、この構成に感動しない人はいないと思う。 一番最後まで読み進めて、改めて最初に戻りたくなる作品は、中々お目に掛かることが出来ないのだが、「たかが殺人じゃないか」はその稀有な作品の一つ。 多くの人が最後まで読んで、また最初に戻ったに違いない。 作品構成が往年の作家らしく非常に凝っていて、素晴らしかった。 セリフが素晴らしい タイトルにもなっている、「たかが殺人じゃないか」は劇中のとある人物が放つ言葉なのだが、これが今の情勢と合わせて、自分には響いた。 戦争が与える影響によって、どれだけ人間が醜く歪むのかというのを端的に表したセリフであり、且つその人物のようにはなって欲しくないという作家のメッセージ性が強く表れた言葉であり、今だからこそ、改めてこのセリフの重みを感じる。 ロシアのウクライナ侵攻が無かったとしても、このセリフは非常に重みがある言葉であり、歴史の生き証人からの大切なメッセージである。 この言葉を吐く人間を今後も生み出しては行けないし、当然ながら自分もそうなってはならないと考えさせられるものだった。 とは言え、いわゆる説教臭さは皆無であり、むしろライトな印象でこのセリフが使われている所に、プロの技術の高さがにじみ出ていると感じた。 雰囲気が素晴らしい 昭和24年という、時代としては完全に失われた世界の描写が数々描かれており、それが良かった。 これは京極堂シリーズ読者からすると、ある意味「既視感」のある世界であり、別の作家を通して描かれた昭和24年というのも斬新であった。 京極夏彦以外のフィルターを通しての昭和24年は別の生々しさがあり、読んでいてとても良かった。 ミステリとして ミステリとして読んだ場合、実は非常に明快且つシンプルすぎるため、「誰が犯人なのか」というのはかなり簡単に分かってしまう。 可能性を1個1個潰せば誰でも簡単に結論にたどり着けるからだ。 「なぜ殺したのか」の部分は、かなりの部分隠されてい