Posts

今回は超小ネタです。 <!–more–> 最近はEmacs上でのcompletionとして、orderlessなどの標準のcompletion-readなどに則ったものを利用してます。Emacsの標準補完は、実はかなり柔軟性に富んでいて、様々なカスタマイズが可能になっています。 completion-readのカスタマイズでは、 completion-category-overrides という変数で、completion-readによるマッチング方法を categoryごとに 変更することができます。 このcategory、 completion-metadata という関数で取得できるmetadataから取得することができます。 (completion-metadata-get (completion-metadata "" table nil) 'category) このtableとは、(私の理解だと)completion-readの第二引数として渡す関数です。この関数は、第３引数としてactionを取り、このactionに 'metadata というシンボルが渡された場合は、metadataを返す必要があります。 completion-metadata-getはこれらのmetadataから、特定の情報を取得するものです。なので、あるパッケージの補完をカスタマイズしたいときは、これを調べればカスタマイズできます。 ・・・が、場合によってはcompletion-readの呼び出しでlambdaを利用していて、 completion-metadata が使えないケースがあります。 実際、org-roam-node-findではlambdaで渡されており、categoryを知るためには結局その中身まで見る必要がありました そういう場合は、しかたがないのでパッケージの中を completion-read で検索してみると大体見付かります。 そんな場合もあるんだよ、というメモでした。

涼しかったのも終わり、相変わらずの厳しい残暑が戻ってきてしまいました。日が出ていないのに36℃とか勘弁して欲しいですほんと。 今回は、ひょんなことからガッと作ったアプリケーションで、Recoil.jsを使ってみたのでその話をしようかと思います。 <!–more–> 作ったもの これです。といってもまだ若干イケていないところがあるので、画面とかはないですが。 https://github.com/derui/simple-planning-poker 複数人で一つのゲームを開催できる 全員がカードを選択したらその平均値を表示できる 表示し終わったら次のゲームを直ぐに開始できる カードの選択、show downなどはリアルタイムで同期されます。 今日時点で9daysなので、大体1週間ちょっと(平日の夜 + 土日の日中)ですね。 なんで作ったん？ チームではスクラムっぽいことをやっていて、そのなかで見積もり手法としてプランニングポーカーを利用しています。 で、最初はアナログな手法でやっていたのですが、リモートが長く続くこともあり、 https://planningpokeronline.com/ というサイトを利用するようになっていました。 で、↑のサイトを使っていたときに、チームの中から(自分が言い出したかもしれん)、 これってFirebaseを使えば割と簡単に出来るんじゃない？ という話が出ました。 そういえば、Firebaseって使ったことねーなー。 と思ったので、じゃあやってみんべ、と作ってみました。 state管理ライブラリの選定 さて、今回はガッと作ろうと決めていたので、フロントは慣れている React.js + TypeScriptを使うことにしました。react-routerとかも使ってます。が、あんまりまともに使ったことがないのでreact-routerはいつも迷いどころ・・・。 ただ、state管理として Redux を使うかどうか・・・というのはちょっと迷っていました。いくらガッと作ると言っても、趣味プログラミングならばちょっとは冒険してみたいところ。 と調べていたら、 Recoil.js という新しめのstate管理ライブラリを見つけました。 A state management library for React と謳っていることもあり、完全にReact専用です。なんといってもHookを前提にしているので、Reactじゃないとそもそも動作しません。Reduxは別にReactに閉じるものでもないことを考えると、汎用性があるわけではないなーとは思ったんですが、まぁ使ってみるか、とやってみました。 Recoilの基本 基本的なものは、公式サイトを見るのが一番わかりやすいと思うんですが、簡単に紹介します。 Recoilの基本は、 atom と selector の二つの概念です。といっても、 atom = state で、 selector = atomから情報を取得したり加工して情報を返す という区別があります。 const textState = atom({ key: 'textState', // ユニークなID。atom/selector全部を通じてユニークでなければならない default: '', // デフォルトの値 }); const quotedText = selector({ key: 'quotedText', // ユニークなID。atom/selector全部を通じてユニークでなければならない get: ({get}) => { const text = get(textState); return '"' + text '"'; } }); みたいな感じです(例が思いつかなかった)。recoilは、selector/atomの間にデータフローを作成し、atomが更新された場合はそのatomを利用しているselectorを更新する、という形になっているようです。 ...

気付いたら8月です。猛暑というか酷暑というかですが、台風が来てくれると多少熱が持っていかれるので、多少は過ごしやすくなってくれるといいんですが。 少しは別のこともやらんとなぁ、ということで、久し振りにRustを使ってちゃんとしたツールというのを作ってみました。 <!–more–> 何を作ったのか https://github.com/derui/org-roam-protocol-installer こんなのを作りました。今、個人なナレッジの蓄積としてorg-roamを利用しています。org-modeには、org-protocolという、外部からorg-modeに対してcaptureを行わせることができる仕組みが存在しています。 org-roamにはこれを独自に拡張した、org-roam-protocolというものがあります。これを利用すると、webページとかをお手軽にorg-roamにcaptureする・・・ということができます。 が、リンク先のドキュメントを見てもらえばわかるのですが、ファイルを作ったりなんだりと、別段複雑ではないものの、多少手順が必要だったりして、これはこれでなぁ・・・みたいなことを考えました。特にmacOSがめんどくさい。 ということで、じゃあこれをインストールするだけのツールを作ればいいんでない？ということを思いつき、ついでにRustの勉強(実際には以前使っていたので復習)がてら、Rustで作ってみることにした、という次第です。 使ったcrate Cargo.tomlを見たらわかりますが、今回はきちんと？crateを利用しました。 clap CLIのフレームワーク。サブコマンドの定義とか色々可能 dirs HOMEとか特殊なディレクトリとかにアクセスするため tempfile 一時ファイルを適切に作成するため ソースは見てないけど、挙動的にdropすると削除されるようになってる quick-xml 高速な低レベルXMLライブラリ。Info.plistの編集で使ってます 常日頃OCamlをよく利用している側としては、一つの処理に対して色々なcrateがあってすげーなぁ、と思うと同時に、どれを選んだらいいのかわからない問題も起きがちだなぁ、というのはやっぱりありますね。 苦労した点 私はmacOSを個人では保有していないので、macOSでのインストール作業をどう自動化するか？を結構悩みました。 Script EditorをApplescriptで起動して保存させる・・・？ ApplescriptをApplicationとして保存しなければならないのですが、そのためにはScript Editorしか使えなさそうに見えた そもそもApplescriptで↑ができる・・・？ とか考えましたが、最終的には osacompile というコマンドの存在を知り、これでええやんってことになりました。このあたり、独自形式を突っ走るmacOSがめんどくさいですね・・・。 所有権とかは苦労していないの？ Rustでよく言われる所有権とかborrow checkerですが、そこまで苦労はしませんでした。というか、普通にプログラムを作っていったら、一つの中で書きこみと読みこみを同時にやる、とか基本的にそこまでしないはずなので。 ライフタイムとかを考え始める = structにオブジェクトを含めるようになると、めんどくさくなるのが目に見えてますが、今回はそこまで必要なかったというのもあります どちらかというと、 File::open と File::create の違い(Cとか他の言語だと、大抵はopenに引数を付けてwriteとかappendとかにする)とか、traitを渡すためにはどうすればいいか、とかの方がよほど苦労しました・・・。 エラーメッセージが大分親切になっているので、そこまで困らなくなったように思います。 あらためてRustでよいなと思った点 Testが統合されている Rustはtest用のモジュールを、それぞれのモジュールに含めることができるので、かなり細かいテストまで作成できる、という点はやはりよい点ではあります。 ただ、これには負の点もあって、内部実装を細かくテストしすぎると、リファクタリングとかがめんどくさくなります(private methodをテストするのと同様のことができてしまうので)。 ポインタの心配がない Null dereferenceとかの心配が無いのはよいです。まぁ、その代わりにmutとかborrow checkerとかを確認しなければならない、ということでもあるんですが。 CとかC++とかで生ポインタを触る場合は、super powerを手にしているのと同じようなものなので、注意しなければならない、というのを思い返させてくれますね。 crateが豊富 上でも書きましたが、直近のえらい盛り上がりに比例して、crate数がものすごいことになっています。当然ながらそうなると玉石混交にもなるんですが、やりたいことに対してcrateが見つかるというのは気楽です。 OCamlとかだと、下手したら存在しないから自分で書く羽目になる、とか、メンテナンスが進んでいないやつしかない・・・とかにもなりえます。最近は少なくなってきましたが。 targetを変更してビルドしやすい OCamlでは結構めんどくさいので、これはうらやましい点ですね。まぁ、前提や設計された時代背景がそもそも違うので、単純に比較するとそれはそれで無知をさらけ出すことになりますが・・・。 解決できていない点 Linuxでは動作を確認できているんですが、macOSにおいては、Gatekeeperを突破する方法がいまいちわからず、ダウンロードしたものをそのまま利用することができない状態です。 正当な手段は、Apple Developer IDを取得してきちんと署名する、ということだと思うんですが・・・。 高い Macを保有していないし、macOS向けになにをするわけでもないのに年間$99も払えません プロセスが複雑になる とかなので、基本的には色んなところで配布されているCLIを参考にしてバイパスできるようにしようと思います。 ツールを作ることでの学習 久し振りに簡単なツールを作りきりましたが、やはり簡単でもいいので作りきるということは、個人的に進歩するなぁ、という実感があります。 ...

今週はワクチン接種とwelcomeランチで、とてつもなく久し振りに何日か連続で部屋のある地域から出ました。すっかりリモートに順応してはいますが、やっぱりリアルで会話すると、人間は五感で会話しているんだなぁ、ってのがよくわかります。 以前AZIK + SKKを利用している、という記事を書きましたが、今回はちょっとそれから色々アップデートをかましたので、それについて書きます。 <!–more–> AZIK + SKKの問題 大分AZIK自体には慣れたのですが、あんまり一貫性のない拡張は利用せず、必要最低限の拡張だけを利用するようにしています(覚えられないとも言う)。 しかし、やはりSKKと利用していると色々な問題があり・・・。 SKKの標準で利用するキーとバッティングする sticky keyとの相性がよろしくない これは後述します SKKを利用していない環境のAZIKと少しずつ異なっているので、体を合わせるのが結構大変 この中でも、sticky keyが色々問題がありました。なのでちょっとそれに対して深掘ります。 SKKのsticky keyで利用されるキー さて、SKKの実装には大抵sticky shiftを実現するためにsticky keyを定義できるようになっています。 少なくとも、私が利用しているddskkとAquaSKKには存在しています これをどのように設定しているのか？を調べてみると、以下のような感じが多そうでした。 セミコロン 変換・無変換キー F + Jなどの同時押し このうち、私が試したことがあるのはセミコロンと変換・無変換キーです。同時押しは、かな入力であればよいと思いますが、SKKで要求される頻度でそれを行うと、まず間違いなく打鍵数がとても増えてしまいます。 変換・無変換キーと親指Enter/SandS 私の利用しているキーボードは、今も変わらず crkbd ですが、このような系統ではEnter/Spaceを親指に割り当てたうえで、レイヤーの切り替えも親指で行うのが大勢となっています。それに加えて、SandSを長いこと利用しているので、それも設定しています。また、日本語・英数の切り替えも親指です。そうすると、親指が担当する機能というのは・・・ レイヤー切り替え Enter Space SandS(実際にはSandEnterも設定してます) Alt/Command 日本語・英数切り替え ・・・というくらいまで拡張されています。普通のUSやJISキーボードであればSpaceとかAltしかないと思いますが、このキーボードでは親指がかなり酷使されます。よく、親指はタフな指なので〜みたいな言説がありますが、実際には親指は支持するための指であり、タフでありますが運動性は高くありません。また、支持が目的であるため、キーボードにおいては他の指と力の入れかたが異なります。そのため、親指に機能を割り当てすぎると、今度は親指の負担が大きくなりすぎる、という問題になります。 ちょうど、無変換にsticky keyを設定してしばらく運用してみたのですが、親指があまりに動きすぎるため、手もブレるし痛みもでやすい、ということがわかったため、これは却下しています。 SandSでやればいいんじゃないの？ SandSを設定しているからsticky keyは使っていない、というのも見ましたが、これはあくまで一般的なキーボードを利用しているケースです。↑にあるように、親指に多数の機能が割り当てられているときに、SKKの頻度でSandSをやってしまうと、これまた親指の酷使になります。 じゃあどうするのか ここでの問題は、AZIKにおいては促音「っ」を入力するためにセミコロンが潰されている、という点にあります。 ＡＺＩＫでは「っ」の入力は常に「；」キーを使います。「あっ、ピカッ」などという入力がとても楽になります。 http://hp.vector.co.jp/authors/VA002116/azik/azikinfo.htm さて、実際に色々文章を入力していると、このような文章を入力する機会はかなり少ないです。正直、このくらいなら xtu で入力しても問題ない・・・。AZIKでは、これで潰した元々の促音入力である tt kk pp ss などに拡張が割り振られています。しかし、これらの拡張は利用頻度を考えると相当少なく、かつ促音を単独キーで入力するときと、結果として打鍵数は同一です。 そこで、以下のようにしてみました。 セミコロンはsticky keyにするので、AZIKの定義から削除 tt ss kk pp などの拡張を削除 結果としては大分シンプルですが、AZIKそのものよりもローマ字入力との互換性が向上したのと、セミコロンというsticky keyに最適な場所を利用できるため、体感的な効率としてはかなり改善しています。そもそもddskk上のAZIKはオリジナルと変わっているので、むしろ拡張しない側にもっていくのは簡単でした。 ddskkだとこんな感じで設定できます。 ...

7月も半ばに差し掛かりつつありますね。今年はオリンピックのために4連休なので、このタイミングで小旅行に行く予定です。 今回も大分ライトな話題で、swayに今利用しているアプリケーションのタイトルを出したいという話です。 <!–more–> swayとswaybar swayには、swaybarという最上部にあるbarを表示するためのアプリケーションが付属しています。これはi3にあるi3barとほぼ同様の機能を提供しています。 ・・・が、このswaybarには一つ不足している機能があり、 アプリケーションのタイトルを表示する という機能が無いのです。 https://manpages.debian.org/experimental/sway/sway-bar.5.en.html 個人的に、 https://github.com/takaxp/org-onit を利用して時間を計測するようなワークフローになっているため、タイトルが出ていると非常に助かります。 モードラインに出せば？という意見もあると思いますが、モードラインはすでに色々な情報で一杯なので、これ以上増やしてもなー、というのがあります swaybarの代替探し swaybarの代替としては、自前でスクリプトを書くというのもありますが、代替もあります。 その中で一番使われている(と思う)のが、waybarです。 https://github.com/Alexays/Waybar swayのみならず、wlrootをベースとしたcompositerで利用できるようになってます。 こいつだと、タイトル以外にも、色々と表示させることができますし、カスタマイズ性もかなり高いです。というわけで、これを使ってみることにしました。 waybarのカスタマイズ さて、waybarには二つの設定ファイルがあります。一つはwaybar自体の挙動 = 表示する位置やモジュールの種類、位置や設定を設定するためのJSON、そしてスタイリングをするためのCSS、という設定ファイルがあります。 { "layer": "top", "modules-left": ["sway/workspaces", "sway/mode"], "modules-center": ["sway/window"], "modules-right": ["temperature", "memory", "clock"], "sway/window": { "max-length": 50 }, "memory": { "interval": 10, "format": "{used:0.1f}GiB/{total:0.1f}GiB" }, "clock": { "interval": 5, "format-alt": "{:%4Y/%2m/%2d %H:%M:%2S}" }, "temperature": { "hwmon-path": "/sys/class/hwmon/hwmon1/temp1_input", "critical-threshold": 80, "format": "{temperatureC}°C" } } 設定ファイルはこんな感じにしています。temperatureのところは個々人で違いますが、私の場合はCPUの全体的な温度となっています。これ以外にもGPUの温度を出したりもできるはずです。 CSSですが、これはかなり巨大なので、 https://github.com/derui/dotfiles/blob/master/waybar.style.css を参照してもらった方がよいかと・・・。ちなみに、変更点としてはbar全体の高さやフォントの設定くらいです。 カスタマイズしていきましょう せっかくlinuxやswayを利用しているのであれば、かなり自分の好みに合わせて変更していくことができます。これはMac/Windowsにはない利点です。当然ながらそのためには色々調べたりしないといけないですが、その結果として自分のやりやすいようにできていけば、それはそれでよいんではないでしょうか。 ちなみに私は結構デフォルトで満足してしまう(最近はデフォルトでも十分なケースが多い)方ですが、やりづらい場所はできるだけ改善していきたいなぁ、と思ってます。

久々(約４年振り)に眼鏡を新調しました。といっても注文して決済しただけで、まだ受け取っていないのですが。 さて、今回はEmacsの補完をivyから完全に切り替えたのでその話を書こうと思います。とはいえかなりライトなお話ですが。 <!–more–> 補完インターフェースの遍歴 なんだかんだ、Emacs(Meadow含め)を使いつづけて早1x年が経過してますが、その間に補完インターフェースはその時々のトレンドに乗ってきました。 Anything Helm Ivy Ivy + posframeもやったりしました selectrum どちらかというと個人的にはこだわりはないので、そのときどきで一番勢いがあるものに乗っかることで楽をしている感じですね。 今回の変更先 ついこの間まではivyからselectrum + consultとなっていましたが、以下の記事を見て、ご他聞に漏れずverticoに変更することにしました。仕事でもそうですが、標準に乗っかるって大事ですね。 https://blog.tomoya.dev/posts/a-new-wave-has-arrived-at-emacs/ selectrumからverticoへの変更 さて、実際に乗り換えたのはインターフェースだけなので、selectrumからverticoへの移行のみが焦点となりました。 ・・・が、そもそもほとんどカスタマイズが不要な状態で(唯一やっていたのはmini-frameくらい)利用していたので、正直ほとんど変更することもなかったです 実際に設定中でもたったこんだけです。 (leaf vertico :straight t :custom ;; 最大20件まで表示するように (vertico-count . 20) :config (vertico-mode)) 個人的には、Interfaceとかはあんまりいじりすぎないようにしています。よほど色がどぎついとかそういうのは弄りますけど。 mini-frameを利用しないようにした理由 さて、selectrumを利用していたとき、ivy-posframeを利用していたのと同じ感じで利用できれば、ということでemacs-mini-frameを利用していました。 しかし、これはこれで結構難点がありました。 現在の視点に関わらず、常に一定の場所に表示される ivy-posframeとかだと、カーソルのそばとかに表示できたりします 配色の問題だが、borderlessなので一瞬境目を見失う といったものが日々利用する上でだんだんストレスになっていました。固定位置なのであれば、正直minibufferを見るのと変わらんやん・・・ということもあり、verticoへの移行を期に削除しています。 migemoるようにした 今回、orderlessとverticoを導入したことで、emacsの補完システム(実はかなり充実している)を利用する形で、結構お手軽に変更できるようになっています。 https://nyoho.jp/diary/?date=20210615 こちらの記事を参考、というかほぼ丸パクリさせていただいて(多少アレンジはしてます)、無事consultでもmigemoることに成功しました。最近はorg-roamでメモを取るようにしているので、ファイル名とかを日本語検索するのが億劫になっていたところだったので・・・。ちなみにmigemoは自作のmigemocamlを利用しています。 そういえば、単独でdictを生成できるようにしたのに、まったく記事を書いていないので、これについては後程記事にしようと思います。 軽快・快適な補完生活を 現在、Emacsのpgtkブランチを利用することで、 Wayland native + native compileな環境を利用できるようになり、かなりEmacs上が快適になっています。これだけ快適になると、さらにVSCodeとかに移行するモチベーションが無くなるのが困ったところですね。 とはいえ、快適な補完は現代的な生活における必需品だと思います。Spacemacsとかではなく、vanillaのEmacsを利用している方は、是非これらのパッケージを利用してみることをお勧めします。快適ですよ。

大分前に購入していたけど、ほとんどやっていなかったshapez.ioというゲームを久し振りにやったら、ずっと黙々とやってしまいました。これは時間が溶ける系統や・・・。 さて、今回もライトな話題で、Linuxでの音楽鑑賞をどうやっているか、について書いてみようと思います。 <!–more–> GUI or CUI まず、Linuxでのプレイヤーとしては、CUIベースかGUIベースか、に大別されます。 CUIベース mplayer mpv GUIベース smplayer celluloid VLC …など CUIベースであるmplayer/mpvは、他のplayerのバックエンドとして利用されている(smplayerやcelluloidといったものは、mplayer/mpvのフロントエンドです)ので、実際には本当にインターフェースがCUIなのかGUIベースなのか、という違い程度だと思います。 Spotifyとかは？ 私は基本的にオールドタイプなので、ストリーミング(有料会員ならオフラインにダウンロードとかできるらしいですが)で聞く、というのは基本的にやってません。購入した楽曲は手元に置いておきたい、という感じですね・・・。 Youtubeとかで見つけても、その後には楽曲をあらためて別サイトで購入したりするのが私にとっては一般的です。 楽曲の保存 基本的に全ての楽曲はNASに保存しています。ちなみに使っているNASは二代目で、以下を使っています。 https://www.synology.com/ja-jp/products/DS218 これに、WesternDegitalのNASむけHDDを組み合わせて利用しています。 LinuxとはNFSで接続できるので、まー特に問題ありません。Windowsとの相互運用も問題ないので、普通にWindows機とのファイルのやりとりにも利用しています。 何を利用しているのか 私は上記に書いたプレイヤー全部を利用したことがありますが、現状は以下のような形に落ち着いています。 音楽をディレクトリごととかで再生する mpv 動画や、頻繁にシークする音楽ファイルを再生する celluloid プレイリストを見たい celluloid mpvでもシークはできるんですが、どうしても視覚的に直感的ではないため、シークが頻繁におこなわれるものとしてはcelluloidを利用しています。あと、動画とかを一気に見たりする場合は、プレイリストとして常に表示できるGUIの方が便利です。 まぁ、最近は動画についてはストリーミングでしか見ていないので、ほとんどcelluloidは使っていないのですが・・・。 なぜCUIを利用するのか 私が思うCUIの楽さ加減としては、 tmuxとかのターミナルマルチプレクサと併用すれば、裏で流しっ放しにできる ディレクトリ内を一括で入れたりするのが簡単 ファイル数が多すぎると、コマンドラインの最大長を超える可能性もありますが GUIが無いのでとても軽い という点です。私の環境ではWMとしてswayを利用しているので、GUIを起動するとどうしても邪魔になりやすい、というのがあります。 floating windowは、場所をずらしたり調整したり、後邪魔になったときに避けないといけないので、あんまり利用してません。 他の人はどうやってるんだろう 最近はもう基本的にストリーミングサービスを利用している、という方が大半だとは思います。私は今でも専用のメディアプレイヤーにmp3なりを突っ込んで聞いている、という人なので、基本的にはオフラインで聞けることを優先しています。 ストリーミングを利用している人の場合、基本的にはそのサービスのクライアントを利用するんだと思いますが、それって無駄に重いし邪魔じゃない？という思いもあります。機会があれば聞いてみようかなー、と思います。(私の周辺はみんなオールドタイプなので)

気付けば今年ももうそろそろ半分が終わろうとしている、という恐怖の事態。なんか毎年言っている気がしますが。年々早くなっている気がしますな。 今回はライトな話題で、org-roamでjournalを書くようにしてみている話です。 <!–more–> org-roamとは まずパッケージの紹介ですが、 org-roam というパッケージがあります。これは、Roam Researchというサービスをorgに移植したものです。 Roam Researchというサービスは、 Zettelkasten Method というメモの方法論を基に実装されたようで、色々なメモを有機的に結合することで、知識の整理や発想を促す・・・という感じのもののようです。 org-roamはローカルでだけ動作するので、特にサーバーとか不要で、orgファイルさえ共有できれば、どこでも利用できるというのが強みですね。 ただし、検索速度とかを向上させるために、sqlite3を利用しているのと、グラフを作成するのにgraphizを利用しているので、それらが利用できるプラットフォームである必要があります。 最近のメモとかは基本的にすべてorg-roamに書き溜めるようにしています、が、リンクをするのがめんどくさいなど、いくつか課題がありますが・・・ org-roamのjournaling機能 org-roamは、org-modeよろしく非常に多彩な機能が含まれていますが、その中に dailies という機能があります。 https://www.orgroam.com/manual.html#Daily_002dnotes org-journalほどは機能があるわけではないけど、必要最低限の機能はあって、かつroamと統合されている・・・というようなのが特徴です。 今の私の設定はこんな感じになってます。 (leaf org-roam :after org :straight t :if (and (file-exists-p my:org-roam-directory)) :custom ((org-roam-db-update-method . 'immediate) (org-roam-db-location . my:org-roam-db-location) (org-roam-directory . my:org-roam-directory) (org-roam-index-file . my:org-roam-index-file) ;; dailiesを保存するdirectory (org-roam-dailies-directory . my:org-roam-dailies-directory) (org-roam-capture-templates . '(("d" "default" plain (function org-roam--capture-get-point) "%?" :file-name "%(format-time-string \"%Y-%m-%d--%H-%M-%SZ--${slug}\" (current-time) t)" :head "#+title: ${title}\n- tags :: " :unnarrowed t))) ;; dailiesのcapture (org-roam-dailies-capture-templates . '(("d" "default" entry #'org-roam--capture-get-point "* %<%H:%M>\n%?" :file-name "daily/%<%Y-%m-%d>" :head "#+title: %<%Y-%m-%d>\n" :olp ("Journal"))))) :bind ((:org-mode-map :package org ("C-c r" . org-roam-insert))) :hook (after-init-hook . org-roam-mode)) この設定だと、captureを起動すると、 ...

在宅が始まってから、大分コーヒーの量(ただしかなり薄い)が増えてたので、ちょっとカフェインの摂取量を減らしてみました。まだやりはじめなので、効果が出るまではまだまだかなー。 ちょっと仕事が忙しい & 実装がいまいち進んでなくて書くことが無いので、埋め草的に、ちょうど半年が経過した引越しについて振り返ってみようかと思います。 <!–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 当たりました。 特に空気清浄機は、冬の超乾燥に対抗する手段としてきっちり役に立ってくれました。現状花粉症とかでは無いので、それ以外だとまぁつけておくか・・・くらいですが。 ...

去年のGWに何をやっていたか全く記憶が無いんですが、今年も特に何もないGWになりそうですね。なんだかなぁ、という気分しかありませんが。 そんな状態ですが、最近チマチマと作っているOCamlでのScheme処理系で、Monadic Parserを作ってみたので、その紹介をちょっとできれば。 <!–more–> Monadic parserとは まずMonadic parserとは何か、ですが、あんまり明確な定義は無いというか、名は体を表すというか、そのまんまというか。モナドを利用したparserです。HaskellのParsecが有名ですね。 基本的には、 関数で構成されている モナド則により合成可能である という感じかなー、と。理論的な背景はあんまり理解しきれていないので、あくまで私の理解ではありますが。 OCamlのapplicable let Haskellだと、Monadの記述にとても役立つ、 do記法 というのがあります。OCamlには長らくそういうのがなく、PPXとかで各ライブラリごとに拡張を書いていたり、ppx_letのように汎用的な拡張を利用したり・・・というのが必要でした。 が、OCamlの4.08？くらいで導入された Applicable let というのを利用すると、do記法と同じような記述を、OCamlらしく記述することができます。 module Nanika_monad = ... let ( let* ) v f = Nanika_monad.bind f v let () = let* v = Nanika_monad.return v in ... applicable letと言っても、なんてことのない関数定義です。 let* とかだけではなく、 let+ みたいなものも定義できます(定義の中身は、定義の実装者次第です)。letが定義できるということで、同時に and* のような関数も定義することができます。 これですが、 >>= での結合をほぼそのまま変換することができ、逐次処理のように見せることができます。記号で繋げまくっていくのも楽しいですが、後から見たときに処理が明瞭になるので、最近はMonadとかを利用するときはこれを使ってます。 Applicative ParserではなくMonadic Parserになる理由 Monadic Parserとはよく呼ばれるけど、 Applicative Parser というのが無い理由ですが、これはシンプルで、 Applicableだとパースできないものが沢山ある から、という理由のようです。 具体的な例は、もっとよく説明しているサイトを参考にするのがよいと思います。私の浅い理解だと、 Applicableだと、繰り返しやバックトラックといった挙動を定義することができない 前の値を利用する、というようなことができない ため、そもそもパーサーという目的には機能が足りないのでApplicative Parserというものは事実上作成されない、ということのようです。よりシンプルなパースができればいいのであれば、Applicative Parserとかも作れると思います。 ...