Yutaka Hara

ObsidianとLogseqはどちらもローカルMarkdownファイルを扱うツールなので、実は一つのリポジトリをObsidianとLogseqで同時管理することができる。同時管理？なぜそんなことをしたいかというと、僕の場合はこういう事情だ。家ではメモの管理にObsidianを使っている。仕事でも仕事メモの管理にObsidianを使っている。仕事用PCでも、家庭メモを編集したい場合がある。Obsidianを2個起動すると操作がわずらわしい（というかそもそもできるのかも知らん）ということで、仕事用PCで家庭メモを編集するときだけLogseqを使っている。やり方は簡単で、単にLogseqを起動してObsidianの保存フォルダを開くだけ。日誌これでだいたいいいのだが、デイリーのメモの管理だけ少し工夫が必要だった。ObsidianもLogseqも、日次のメモファイルを自動で作るような機能がある。が、普通にやるとそれぞれ別の場所にファイルを作ってしまうので、できれば統一したい。これに関してはLogseqの方が設定が貧弱なので、必然的にLogseq側に合わせることになる。まず、Logseq→設定→カスタム設定(config.ednを編集)で、一番最後の}の前に :journal/page-title-format "yyyy-MM-dd"  :journal/file-name-format "yyyy-MM-dd" を入れる。次にObsidian側で、設定→Daily notes→New file locationをjournalsにする。これでどちらのツールで日誌を作ってもjournals/2025-01-01.mdのようなファイル名になるはず。

ObsidianとLogseqのオーバーレイで、日誌をうまく扱う

久しぶりにvimプラグインをいろいろ見直してみた。パッケージマネージャVundleからJetPackに移行。Vundleに特に不満があったわけではなく、たまには新しいのも試してみるかの精神。JetPackは、プラグインのインストール時のUIの見栄えがよい。とりあえず当面使ってみる。起動画面Startifyを入れた。起動時に、最近開いていたファイルの一覧から選べるのが便利。実は起動画面だけでなく、セッションを./Session.vimに自動で保存するという機能がある。前はそのために別のプラグインを入れていたがこれに移行。Jetpack 'mhinz/vim-startify'  let g:startify_change_to_dir = 0      " カレントディレクトリを変えてほしくないのでオフ  let g:startify_session_autoload = 1  let g:startify_session_persistence = 1ファイルオープンCtrlPからfzf.vimに移行。外部コマンドを必要とするかわりに速い。コマンドも実はjunegunn/fzfを入れれば入るのでそんなに面倒はない。コマンド名が:Buffersみたいに名前空間が付いてないのが気に入らない、と思ったが設定で付けることもできるようになってて、さすが。現在は:FzfBuffersみたいな名前で使っている。ファイル一覧は.gitignoreを適用したかったので、rgコマンド(ripgrep)を起動するようカスタマイズした。Jetpack 'junegunn/fzf', { 'do': { -> fzf#install() } }Jetpack 'junegunn/fzf.vim'  let g:fzf_vim = {}  let g:fzf_vim.command_prefix = 'Fzf'  nnoremap <Space>u :FzfFilesWithIgnore<CR>  command! -bang FzfFilesWithIgnore    \ call fzf#run({'source': "rg --files",    \   'sink': 'edit',    \   'window': { 'width': 0.92, 'height': 0.7 }    \   })コンパイラの起動前はquickrunを使っていたのだが、quickrunは「現在のバッファを手軽に実行するプラグイン」で、やりたいのはバッファに関係なくただcargo runを実行することなので、それに適したプラグインを探してみた。下記の設定で、Space w で RUST_BACKTRACE=1 rake aをvimのターミナル機能で起動するようになっている。Jetpack 'skywind3000/asyncrun.vim'  nnoremap <Space>w   :<C-u>AsyncRun -mode=term -pos=left RUST_BACKTRACE=1 rake a<CR>ファイラーずっと組み込みのnetrwを使っていたのだがfernを試してみている。まだ設定を詰めきれてないのだがとりあえず現状のはこれ。Jetpack 'lambdalisue/vim-fern'  Jetpack 'lambdalisue/vim-fern-git-status'  Jetpack 'lambdalisue/vim-fern-mapping-git'  nnoremap <Space>e  :Fern %:h<CR>

vimの環境を見直した

今年も会社の支援のもとRubyKaigi 2025に参加してきました。今年はTRICK 2025の審査員ということでスピーカーTシャツでした。今回は過去一の投稿数で、選ばれた方もそうでなかった方も、ご応募ほんとうにありがとうございました。最後にちょろっと言いましたけど実はもう一個応募した作品があったんですよね。けっこう評判よかったんですけど、よく見たらサイズ規定をオーバーしてたという…。次こそは余裕をもって作業にとりかかるぞ（って毎回言ってる気がする）。セッションスライドは https://scrapbox.io/ruby-jp/RubyKaigi_2025 にまとまっています。Make Parsers Compatible Using Automata Learning - RubyKaigi 2025系の外側から中身のオートマトンを推測する話。そんな技術があるんだ。最初にSummaryがある構成、すごく良いと思った。　- 図にするとprismとlramaで全然違うのがわかって面白い。(でも同値である可能性も一応ある…のかな？)The Evolution of the CRuby Build System - RubyKaigi 2025CRubyのビルドシステム(./configureとか)について。現状はだいぶ複雑だと思うんで、まとめてあるだけで偉業というやつ。Shakeの話は出なかったけど、Haskell製のビルドシステムらしい。へえ。どのへんに影響を受けてるのかな？次回の発表も楽しみ。Continuation is to be continued - RubyKaigi 2025聞けなかったやつ。callccは利用率から考えると正直いつ消されてもおかしくないと思ってるんだけど(例えば動かなくなったタイミングで)、shift/resetとして蘇ったら熱い。Goodbye fat gem 2025 - RubyKaigi 2025gem作者が各プラットフォーム向けのバイナリをビルドしたりセキュリティパッチを反映するのは大変だが、このままでいいのか？という問題提起。うーんたしかに。nokogiriはインストールが簡単でいいんですけど、例えばlibxml2に脆弱性が見つかるたびにnokogiri作者が頑張らないといけないんですよね。これを、gemspecで「aptがあったらapt install libxml2する」みたいに指定することで代替できないかという案。個人的にはそれでもまあいい…かな？(デフォルトで)y/nは出してほしいかも。Ruby's Line Breaks - RubyKaigi 2025改行の扱いについて整理すると、endless rangeみたいな新し目の文法について一貫性がなくなっていたという話。いかにもありそう。技術を以てカオスを切り開いていくのはかっこいいですね。State of Namespace - RubyKaigi 2025autoload対応、たいへんそう。Ruby::VERSION、つまりtoplevelのRubyが入るんだ。個人的にはとても好き。ZJIT: Building a Next Generation Ruby JIT - RubyKaigi 2025YJITの「次」について。野心的なことはせず、安定をとるぜ、と宣言されてたのが印象的だった（安定側にもチャレンジは存在する、とのことだったが）How to make the Groovebox - RubyKaigi 2025音声合成の話。こういうの楽しいよね。Speeding up Class#new - RubyKaigi 2025アーロンさんの発表、図のアニメーションをうまく使ってるとこが好き。From C extension to pure C: Migrating RBS - RubyKaigi 2025Sorbetチームの発表。RBS記法をサポートする部分を、通常のC拡張からpure C + bindingという構成に変えた話。通常のC拡張はエラーが起きたらRubyの例外を投げればいいだけなんで楽なんだけど、そのかわりGVLの制約を受けると。DiscordでRustではだめなのか？という話が出てたけど、既存のCコードがあったからCにしたということかなあ。LT PicoRabbit: a Tiny Presentation Device Powered by Ruby - Speaker DeckRaspberry Pi Pico 2からDVI経由で映像出力してプレゼンツールを動かす。すごい。ソース。スライド内容のあとにゲームの実装が書いてあるのおもろい。API for docs - RubyKaigi 2025RBSとRDocは似てるけど違うもので…という話から、気づいたら何かのinternalを説明する時間になっていて、よくわからなかった…（すいません）最初にagenda（何をどの順で説明するつもりか）のスライドがあるといいかもですねSteepはLSPを喋ることができて、その中身はこうなっていますよ、という話だったのかなThe Ruby One-Binary Tool, Enhanced with Kompo - RubyKaigi 2025Rubyスクリプトをone binary化する話。ソースだけでなくデータも含めて本当にone binaryにしたいそうで、力作だったRoad to Go Gem #rubykaigi - Speaker Deckgolangでrubygemを作る話。言語をまたぐといろんなものを変換しないといけなくて大変なんですよね。Modular Garbage Collectors in Ruby - RubyKaigi 2025RubyのGCを差し替え可能にする話。というかもうそうなってて、インターフェイスと実装が分離されているらしい。えらい。GCアルゴリズムによって特性が異なるので、アプリに合わせて選択できるようにしたいとのこと。なるほど。Matz KeynoteRuby 4.0!!イベントOfficial Party、DD4Dが飲めてびっくりした。最高かよ。（8種コンプリートしたかったけどさすがに無理だった）IT各社の採用熱が高まるまでは、RubyKaigiって別に「イベントが豪華なもの」ではなかったんで、ありがたいけどなんだか不思議な気分もあり。松山都会だった。といっても圧を感じない、ほどよい都会という感じで、いいところですね。路面電車があるので、酔ったサラリーマンをたくさん見かけたのが新鮮だった。車社会じゃないんだなあ。なんかこう文化レベルが高いんだよな。カレー屋さんで見たローカル誌とかからもそれを感じました。

RubyKaigi 2025 松山に参加しました

40% Keyboard Discordは、40%以下の小さなキーボードに魅せられた人間の集うDiscordサーバだ。言語はすべて英語だが、投稿される写真を眺めているだけでも楽しめるだろう。入口下記ページにDiscordサーバへの招待リンクがある。Home | 40% Keyboards Wikiチャンネル紹介膨大な数のチャンネルがあるが、重要そうなものをいくつか紹介する。内容は2025年現在のものなので注意。showcaseおよびchefs-choice素敵なキーボードの写真が集まるチャンネル。vendorsキーボードショップからのお知らせが投稿されるチャンネル。新作の販売やセールの開始など。ic-gb-announcementsIC(Interest Check)およびGB(Group Buy)の案内が投稿される。基本的に1キーボードにつき1つのチャンネルが作られるのだけど、チャンネル欄が長くなりすぎないように、デフォルトでは存在が隠されている。Joinボタンを押すことで当該キーボードのチャンネルが表示されるようになる。たまにJoinボタンが動作していないことがあって、そういう場合はquestion-mark-ranksというチャンネルを使う。ここに例えば?rank Discretionと送信すると、Discretionという名前のキーボードのチャンネルが左のチャンネル一覧に現れる。rankの一覧は?ranksで見ることができる。buy-sell-trade-mini-gbsチャンネルを立てるまでもない、小規模なGroup Buyを開催するチャンネル。どのキーボードにもいえることだが、チャンネルがあるからといって必ず発売されるわけではない。作者が忙しくなって立ち消えになるとか、進捗がないまま数年が経つみたいなケースもままある。その分、応援していたプロジェクトが無事GBを経て手元に届いたときの喜びはひとしおだ。

自キ沼の深淵へ！40% Keyboard Discordの歩き方

このエントリは言語実装 - Qiita Advent Calendar 2024 - Qiitaの25日目の記事です。メリークリスマス！処理系ミートアップとはプログラミング言語処理系が好きな人の集まりというオンラインコミュニティがあります。処理系ミートアップはこのコミュニティから生まれたイベントで、月１程度でオンラインにメンバーが集まって進捗報告とか進捗しない(詰まった)報告とか雑談とかをするという内容です。開催記録はCosenseにまとまっています。本年は第57回から第68回まで、11回開催されました。ゲスト回最近は私がイベントページを立て、monochromeさんが配信を用意し、raviqqeさんが司会をするというなんとなくの役割分担でやっていますが、今年は何度かTwitterで見かけた言語作者に声をかけて発表をお願いしてみました。第57回scala-jsのtanishikingさん第68回Catlaのbea4devさんまた昨年の第50回ではErgのShibaさんにお越しいただきました。YouTubeに録画があるのでぜひご覧ください。

今年の処理系ミートアップ

このエントリは言語実装 - Qiita Advent Calendar 2024 - Qiitaの24日目の記事です。ShiikaとはShiikaは私が作っている、Ruby風の文法をもつ静的型付け言語です。昨年まででInteger/String/Arrayなどの基本的なところは実装したのですが、そのあとIO機能を実装するところで、これは先に並行性のサポートについてちゃんと考えておかないとなと気付き、今年はその作業をしていました。(たとえば後から並行性のサポートを無理やり入れたため、Fileのreadとread_asyncが両方あって使い分けないといけない…みたいなことは避けたいなという話です。並行性いろいろ考えましたが、流行りのasync/awaitではなく、GoのようにIO等のタイミングで自動的に処理が切り替わるというのを考えています。ただGoのようなマルチスレッドではなく、Node.jsのようにシングルスレッド方式とすることで、より気軽に並行処理を書けるようにしたいと思っています。この場合CPUヘビーな処理が書けなくなりますが(その間他のタスクも止まってしまうため)、もともと性能最重視の言語ではないので、ジョブキューのような形で複数プロセスを使って並列化するか、そういうところは別の言語で書く、ということになると思います。ただ可能なら一部の処理だけ切り出して単独のスレッドを割り当てるとかできるといいですね。CPS変換平行性の実装ですが、Shiikaの関数(メソッド)をCPS変換した形のLLVM IRを吐き、Rustのtokioの上で動かすというのを考えています。これを実験していたのが以下のリポジトリです。https://github.com/yhara/milika(この頃はついでにMLIRを使う実験もしていたのですが、最終的には、MLIRは使わないことに決めました。上記のようなレイヤーの処理をするにはあまり向かなそうとわかったからです。GPU上で動かす言語を作るとかならとても便利だと思います。)実装にあたってはraviqqeさんのPen言語という先人の知恵に助けられました。ありがとうございます。バックポートということでなんとなく動きそうというのがわかったので、その後は実験結果を本体にマージする作業を進めています。ifやwhileなど単純なものは既に動いていますが、メソッド呼び出し、型推論、クロージャあたりを統合する作業がけっこう面倒かもしれません。まあ来年もぼちぼちやっていきます。

Shiika進捗(2024)

KeebWorld Conference 2024 松江 ←みてこのかっこいいウェブサイト！私のスライドはこちら。このイベントのために、KEEB_PDに上げてなかった秘蔵っ子たちです。イベントについて初の松江開催でしたが、いやあ、良かったですね。会場も満員、キーボードも机が足らなくて拡張するくらいの展示台数でした。カバンから手品師みたいに次々とキーボードを取り出すまつもとさんが面白かったです。運営のみなさまありがとうございました。このエントリはkoneko40で書きました。そう、koneko40も秘蔵してたんですけど、おもしろ優先選定の結果、上記のメンツになりました。

KeebWorld Conference 2024で発表しました

このエントリは言語実装 - Qiita Advent Calendar 2024 - Qiitaの10日目の記事です。最近やってた「ファミコン上で動作するRuby」ですが、シンプルなゲームが実装できるとこまでできたのでいったんv0.1.0としました。https://github.com/yhara/nesrubyゲームは先日のRubyWorld Conference 2024の弊社ブースで展示していたものです。JSNESを使ってgithub pagesにもアップロードしておきました。https://yhara.github.io/nesruby/仕組みcc65というCコンパイラがファミコン向けの機械語を生成してくれるので、それを使ってmruby bytecodeのインタプリタを実装したという形です。実装はmruby/cのソースを大いに参考にさせていただいています。ありがとうございます。最初に「こういうふうに書けたらいいな」というRubyプログラムを書いて、それをmruby(mrbcコマンド)でコンパイルして、出てきた命令を一つずつmruby/cから移植する、という感じで作っていました。まだメソッド定義ができなかったり、GCがなかったりするので、そのあたりもいつかチャレンジしてみたいですね。

ファミコンで動くRubyをつくりました

このエントリはKEEB_PD 2024 Advent Calendar 2024 - Adventarの23日目の記事です。昨日の担当はMAXさんでした。トロピカルの写真、色合いが決まってていいですね。今年の投稿今年はテーマを決めて一連の写真を撮るというのをやってみました。一つはSufferというマクロパッドにいろいろなキーキャップを付けてみたシリーズ。Keyboard: SufferSwitch: Gateron Oil King, etc.Keycap: SA Geoma#KEEB_PD #KEEB_PD_R204 pic.twitter.com/9JrTd1z5r9— yhara (Yutaka HARA) (@yhara) June 30, 2024 もう一つは逆にDeadline Studio AirWaveという夏っぽい透明キーキャップをいろいろなキーボードに付けてみたSummerシリーズです。なんでシリーズにしたかというと、自分が見てみたかったから…というくらいの理由ですが。Summer #4 (Imposter)Keyboard: Lazydesigners BoltSwitch: TECSEE JadeiteKeycap: Deadline AirWave#KEEB_PD #KEEB_PD_R210 pic.twitter.com/4y3kfRpO8T— yhara (Yutaka HARA) (@yhara) August 11, 2024 (↑お菓子の紙袋を背景にしたところ、ちょうど因幡の白兎のSAGI、が見えて、Artisan KeycapがImposter(詐欺師)という名前なので、そこだけ残してみた一枚。)KEEB_PDに参加する理由KEEB_PDへの参加理由は人それぞれだと思いますが、私の理由は「コミュニティへの還元」です。キーボードキットやキーキャップセットを購入するときって、ショッピングサイトの写真はレンダリング画像だけだったりして、インターネットに実物の写真が上がっているととてもありがたいんですよね。そういうことがあるので、自分でも入手した品物はできるだけ写真を上げたいと思っています。あとは、自キのキットは作者の好意で公開なり頒布なりされているわけで、それに報いたいという気持ちもあります。そのような機会をくれているKEEB_PDには感謝しています。ちなみに…私はもう結構長いこと参加していますが、未だに「1位」を取ったことがありません。(^^;KEEB_PDのDはDuel(だったと思う)なので、Likeを稼ぐのもいいですが、Like数だけにこだわると、例えばキーボード専用のアカウントを作ってそれ以外の発言は控えた方がいいとか、ライバルの写真にはいいねしないとか、あんまり楽しくない方向に行きそうなので、何かの偶然で1位になれたらいいな～くらいの気持ちのほうが長続きするかなと思っています。と思ったらにるぽさんもふぁぼはおまけって書いてた！来年も、こんな素敵なキーボードがあるんだぜ～という写真を撮っていきたいですね。この記事はcocot46plusとkoneko40で書きました。koneko40は12uのロウスタッガードで、僕が最初にKEEB_PDに参加したALETH42と同じ配列なんですよね。当時はLキーの右に1キーしかないことに苦戦していたのですが、littolによる30%修行を乗り越えた今ではCOMBO KEYなしでもだいぶスムーズに打てるようになりました。成長を感じて嬉しいです。明日の担当はJourkey, Ejectix, CenterxEnterなど印象的なキーボードをいくつも開発しているtakashicompany さんです。

わたしがKEEB_PDに投稿する理由

このエントリは言語実装 - Qiita Advent Calendar 2024 - Qiitaの17日目の記事です。今日は処理系実装上のTipsを一つ紹介します。例：if式たとえばC言語みたいに、  if (a) {    b    c  } else {    d  }のようなif式をもつ言語を作りたいとします。文と式が分かれている言語にする場合、Rustで実装するとこんな感じになるでしょうか。struct Stmt {  ...  ExprStmt(Box<Expr>)  //いわゆる式文。}struct Expr {  IntLiteral(usize),  ...  If {    cond_expr: Box<Expr>,    then_clause: Vec<Stmt>,    else_clause: Vec<Stmt>,  }}一方、すべてが式の言語にする場合はどうでしょうか。なんとなくstruct Expr {  IntLiteral(usize),  ...  If {    cond_expr: Box<Expr>,    then_clause: Vec<Expr>,    else_clause: Vec<Expr>,  }}みたいにthenとelseが複数のExprを持つ感じにしたくなりますが、ここに複文（ならぬ、複式？）を導入してstruct Expr {  IntLiteral(usize),  ...  Stmts(Vec<Expr>) //連続した式を順に評価する。最後に評価した値をStmts全体の値とする。  If {    cond_expr: Box<Expr>,    then_clause: Box<Expr>,  //単一の式、またはStmtsが入る    else_clause: Box<Expr>,  //単一の式、またはStmtsが入る  }}のようにするとわりと取り回しが良いです（良かったです）。注意点上記の場合、空のStmtsの扱いに注意する必要があります。簡単なのは何からの「ゼロ値」を導入し（C言語のnull、LispやRubyのnil、的な）、空のStmtsを作ろうとしたときは自動的にそれを挿入することです。この場合意味論としては、例えば  if (x) {    print(x)  } else {  }というif式は  if (x) {    print(x)  } else {    nil  }と等価になります。

言語実装tips：複数の式をまとめる

part.1の続きです。 コードを生成する必要なデータが取れるようになったので、コード生成部を書いていきます。最初に概形を示します。#[proc_macro]pub fn shiika_method_ref(input: TokenStream) -> TokenStream {    let _spec = parse_macro_input!(input as ShiikaMethodRef);    let mangled_name = "a";    let function_definition = "b";    let parameters = "c...

syn crateを使ってproc_macroを書く (part.2 生成編)

こんにちは。yharaです。私はShiikaというプログラミング言語を作っているのですが、その過程でこんなコードを書くことがありました。extern "C" {    #[allow(improper_ctypes)]    pub fn Meta_Array_new(receiver: *const u8) -> SkAry<SkObj>;}pub fn meta_array_new(receiver: *const u8) -> SkAry<SkObj> {    unsafe { Meta_Array_new(receiver) }...

syn crateを使ってproc_macroを書く (part.1 解析編)

こんばんは。yharaです。メリークリスマス！本記事は言語実装 Advent Calendar 2021最終日の記事です。昨日は@sisshiki1969さんのrurubyのガベージコレクタとアロケータでした。 Shiikaの2021年Shiikaは私が作っている静的型付け言語です。今年はenum、パターンマッチ、Maybe型といろいろ機能を足しました。来年はModuleと型推論をやる予定で、そこまでできると当初考えていた言語仕様が一通り揃います。いやー楽しみですね。はやくShiikaで実用的なプログラムを書きたい。 全てがオブジェクトShiikaはRubyの影響を強く受けて...

Shiikaの型システム - メタクラスとジェネリクス

本稿はRubyアドベントカレンダー2021-2の1日目の記事です。今年の3月に作ったsimple_twitterというgemの紹介をします。https://github.com/yhara/simple_twitter simple_twitter gemとはTwitter APIのクライアントです。twitter gemと比較して、Twitter API v1/v2に両対応している極めて薄いラッパーであるという特徴があります。 Twitter API v2TwitterのAPIには長らく使われてきたv1と、新しく作られたv2の2種類が存在します。v2はhome...