#えむけーろぐ

間違った事を書いていたらやさしく教えてください

RubyKaigi 2024に参加した #rubykaigi

イベント

はじめに

RubyKaigi 2024に参加してきた。

ハンバーガーの写真。下から野菜・マグロカツ・なにかのソース。大きくて頬張るのが大変。

ウミカジテラス MK CAFEの「マグロカツバーガー」

Rubyプログラマ・Rubyコミュニティの一員として、とても楽しく刺激を受けることが出来た最高の3日間だった。

RubyKaigi関係者のみなさま、会期中コミュニケーションさせていただいたみなさま、ありがとうございました！

事前準備

参加前の準備として行ったことは、下記の通り。

また、直接RubyKaigiのためにというわけではなかったのだが、無職期間を利用して『インタプリタの作り方』という本を読んでいた。（濃厚過ぎて無職期間中に終わりきらなかった。最近は業務時間前にちょっとずつ進めている……。）

book.impress.co.jp

技術面

長くなったので別記事へ。

blog.m6a.jp

コミュニティ面

新型コロナウイルス感染症をきっかけに引きこもり続けていた結果、ITコミュニティとの関わり全般がなくなってしまった。「このままじゃいかん」と思って2023年にKaigi on Railsに参加*2して以降、徐々にRubyコミュニティと関わらせて頂くように。また、この春に転職をして、Rubyコミュニティに近い所で働くようにもなった。

そんな状況でのRubyKaigiだったので、数年ぶりにお会いする人、はじめましての人、知り合いの知り合いな人などたくさんの人とお会いすることが出来た。同僚にもたくさん会うことが出来た。

改めて感じたのが、フィヨルドブートキャンプ勢の層の厚さだ。友人のふくろく（@fukuroq）が入学（？）してからとても楽しそうにしていて、良いコミュニティだなぁと思っていた。今回、彼についていって様々なフィヨブー関係者の方とお話させていただいた。みなさんとても熱量高く勉強熱心で、とても良いなと思うとともに、自分も見習わなければと思い直した。自分は特に関係者ではないのに快く輪に入れてくださったみなさん、ありがとうございました。

業務として

実はこの5月から働きはじめているのだけど、ありがたいことに既存の社員さんと同じ扱い*3でRubyKaigiに参加させていただけることになった。

フルリモート勤務の会社なので、なかなか同僚のみなさんとお会い出来る機会がないはずだったのだが、入社してすぐのタイミングで沖縄に大集合出来たおかげで、自分にとって最高のオンボーディングになった。

Day 1はスポンサーブースに立たせていただいていた。ブースに立ち寄ってくださったみなさん、ありがとうございました。

Podcasterとして

高専時代の友人とやっている「ゆるふわPodcast」のオーガナイザーとしても参加してきた。

事前にステッカーを用意して、プレゼント企画みたいなことをやってみるなど。

思ったよりも多くの方々に声をかけて頂いたり、前々からの知り合いの方で実は聞いてますだったりがあって、なかなかうれしい話であった。おかげさまで、自分の分は全部配りきってしまった。リスナーのみなさま、ありがとうございました。

イベント中に外でシュッと収録して出すというやつに憧れがあり、収録機材を持ってきていた。会場でお会いしたyarukinai.fmのsugaiさん（@sugaishun）をゲストにお迎えし、RubyKaigiの興奮をエピソードに閉じ込めることが出来た。収録はDay 2のAfternoon break中に会場となりの公園で行ったｗ

週明けに出そうとも思ったが、こういうのはアツいうちに出すのが良いだろうと思ってその日の夜に編集して公開した。ぜひ聞いてみてください。

yuru28.com

その他

会場に妻の知り合いがめちゃくちゃいて、僕を「ことみんの夫」として認識して頂いていたりすることがあってすごかった。なんだかここ2〜3年くらい活発にやっとんなーと思っていたけど、まさかここまでとは。ことみんフックで話しかけたり話しかけられたりして出来たつながりが数多くあり、ありがたい話だ。

ことみん公式アカウント*4で僕の存在に言及するのってたぶん初な気がするのだけど、どういう風の吹き回しなのかを聞いたら「妻がお世話になってます〜」的なフックで他人に話しかけやすいように、とのことらしい。ありがたすぎる。めちゃくちゃ活用させていただきました。

今後ともよろしくお願いします。

おわりに

そんなわけで、最高の3日間を過ごすことが出来ました。

改めて、RubyKaigiに関わるすべての皆様、ありがとうございました！

*1:紙書籍は入手困難らしいけど、達人出版会でPDF版が購入できる。Rubyのしくみ　Ruby Under a Microscope【委託】 - 達人出版会

*2:Kaigi on Rails 2023で登壇してきた #kaigionrails - #えむけーろぐ

*3:チケット代・交通費・宿泊費をご負担頂き、3日間は業務扱い

*4:学生のときからあるアカウントと対比して勝手にこう呼んでいます

RubyKaigi 2024 聞いたセッションとメモと感想

ソフトウェア開発 イベント

RubyKaigi 2024参加記事を書いていたら長くなりそうだったので、ひとまず聞いたセッションとそのメモだけを記事にした。

技術以外の話は下記記事でどうぞ。

blog.m6a.jp

生まぐろ（一度も冷凍していない）のどんぶり。まぐろ・ガリ・大葉・海ぶどうでごはんが見えない。

生まぐろ丼 トッピングで海ぶどう（ウミカジテラスの親父のまぐろにて）

はじめに

ちょうど『インタプリタの作り方』を読んでいたこともあり、「これなら少しくらい理解できそうかな？」というものを中心に聞いていった。

手元でのメモを中心に見聞きしたことを数行で書いていく。正直、少ししか理解できなかったので、ググりワードを並べるくらいの気持ちで書いていく。

この記事の読者様も、どうかそのおつもりで……。。。

Day 1: The grand strategy of Ruby Parser

スライド: The grand strategy of Ruby Parser - Speaker Deck

事前準備の記事でも言及させていただいたパーサジェネレータのLramaを開発したkanekoさんによる発表。一言で言うとparser keynoteという感じだった。まぁThe grand strategyだしそりゃそうか。

  • なぜ◯◯か
    • パーサジェネレータ: Rubyはすごく変化する言語なのでBNFで文法を定義出来るパーサジェネレータ便利
    • LR Parser: 人間にとって理解しやすいのはLRに近いのでは的な
    • Lrama: Bisonのツラミ脱出（機能不足・version問題）
      • 今思ったこと→ **env for Bisonみたいなのないのかな。Terraformにおけるtfenv的な。そうすればBisonのversion管理いろんな環境でうまく出来そうだけど。
  • チャレンジ大戦略
    • LSPと周辺ツールを提供すること
      • LSP / TypeProf / Rubocop いろんなツールがASTを使う。これらから使いやすいASTを。
        • CRubyはASTレベルでの最適化が多くそれでASTと元のコードに相違出てるとか、共用体を多用しているのでキャストしにくいとか
        •  入力中に正しくない文法があってもパースしてほしいとか
          • CPCT+っていうアルゴリズムがいいらしい
      • parse.y大変
        • lexerは通常state持たないがRubyのは持ってる
          • PSLR(1)で解決できるが、前段階でIELRが必要
          • Day3: From LALR to IELR: A Lrama's Next Stepにつながる
        • 素朴なBNFより表現力豊かにしたい
          • Parameterizing rulesってやつでなんとかなりました
          • Day 2: Does Ruby Parser dream of highly expressive grammar?につながる
    • ユニバーサルパーサを提供すること
      • CRubyのパーサはCRubyの他の機能に依存していて、他のRuby実装（mrubyとか）から使えない
        • 依存を解いて使えるように
          • Day2: Unlock The Universal Parsers: A New PicoRuby Compiler
          • Day2 LT: Contributing to the Ruby Parser
  • 真のユニバーサルパーサとは？
    • 現状のパーサはC言語で実装されているため、他の言語で素直に扱えない
    • なんらかの中間言語があって↑をSKIP出来ればそれは真のユニバーサルパーサだよね的な？

Day 2: Does Ruby Parser dream of highly expressive grammar?

スライド: Does Ruby Parser dream of highly expressive grammar? - Speaker Deck

kanekoさんの発表で紹介されていたもの。

  • 「Bisonがもっとリッチな文法をサポートしていればなー」→「Lramaになったので出来るように。」
    • その一例としてのParameterizing Rules
    • BNFのパターンに名前をつけてルールを明確化し、再利用可能に。
    • OCamlのパーサジェネレータであるMenhirから拝借したアイデアとのこと
  • ↑によって、抽象化・構造化が出来るように。これはすごいこと。
  • Parameterizing Rules with Tag
    • 諸々聞き逃してしまった。。後ほどキャッチアップ。
  • Standard Library
    • 「一般的な構造をいちいち定義することなく使いたいよね」的なRubyの哲学はParser generatorにも適用されるはず。
    • Standard Libraryとして一般的なParameterizing Rulesを提供。オプションでOFFにもできる。
  • リッチな文法定義はまさにlexer / parserが密結合している故のもの。
  • Parameterizing Rules with Conditional Statements
  • コンフリクトの解消
    • （自分調べ： パーサにおけるコンフリクトとは）
      • あいまいな文法を食わせたときにおこるエラー？
    • 解決策としてのInlining
      • これもOCamlから拝借してきたアイデア

  • 文法ファイルのメンテナビリティを向上し、それがRuby自体の発展に寄与すると信じて、やっていきたい的な話

Day 2: Unlock The Universal Parsers: A New PicoRuby Compiler

スライド: Unlock The Universal Parsers: A New PicoRuby Compiler - HASUMI Hitoshi - Rabbit Slide Show

こちらもkanekoさんの発表で紹介されていたもの。kanekoさんは、CRuby以外からも使えるユニバーサルパーサを提供したいって話をしていたけど、これはそれを使う側の視点からの話。（ってkanekoさんがおっしゃっていたように理解した）

  • Ruby実装ごとにどのパーサを採用しているか違う
  • PicoRubyはRPi Picoで動かすのでメモリフットプリント小さくあってほしい
    • PicoRubyでも使えるくらい小さなメモリフットプリントじゃないとuniversalじゃないよね
  • PrismもLramaもめっちゃいい
    • 令和5年、parse.yはno longer a labyrinth
      • Lrama-genなおかげ
        • （自分メモ： Lramaによって生成されたパーサには名前はついていないが、この方以外も結構みんなLrama-gen parserと呼んでいた。）
    • PicoRuby compilerは両方使います（？）
  • mrbc_lrama: A mruby compiler using Lrama-generated parser
    • ver. 0.0.0.0.1: libruby-static.a をリンクしてやる→9.985MB
    • ↑から始まり、脱GC・脱VALUE・脱IMEMOなどを経て、39.91KBになった。（96%減）
    • 一方、ROMサイズは24MBある。
      • arm-none-eabi向けのクロスコンパイル試したがエラーになる
        • none-eabiはstdio.hのような標準ライブラリをサポートしてない
      • 今後、bare-metalに対してconfigure出来るようにCRubyのbuild-process見直したい

Day 2: Lightning Talks

LT一覧: LT - RubyKaigi 2024

あまりメモは取らなかったのだが、Enjoy Creative Coding with Ruby / The Journey of rubocop-daemon into RuboCop / Drive Your Code: Building an RC Car by Writing Only Rubyの3つが印象に残っている。

特にrubocop-daemonの話は良かった。rubocop-daemonというRuboCopをdaemonizeして速くする3rd-party gemがいかにしてRuboCop本体に取り込まれたかみたいな話。著名なOSSの本体にContributeするのはハードル高くても、3rd-party gemという選択肢もあるんやでというような話だった気がするが、まさにという気持ちで聞いていた。自分もやってみたい、となったとき今パッと思いつくものが無いのだが、常に脳裏にそういう思想を置いておくことで、なにか不便を感じたときに放置するのではなく自分が新たに3rd-party gemを開発するという発想になれると良いなと思うし、実際にそれをやられたという意味で非常に勇気づけられるLTだった。

Day 3: How to implement a RubyVM with PHP?

スライド: How to implement a RubyVM with PHP? - Speaker Deck

ちょうど『インタプリタの作り方』で、VMを作ってたので親近感が湧いたので聞いてみることに。Rubyコードの字句解析・構文解析・意味解析、そしてYARVバイトコードへのコンパイルまではRubyにやってもらって、そのバイトコードを実行するVMを自作する、という話。

  • 新しい言語を普通に学ぶのがシンドいな、おもしろくないなと思い始めて「そうだ、VMをつくろう」となったらしい。
  • RubyVMがどう動くか
    • RubyVMとは？→ YARVのこと
    • なので今回はYAYARVつくった
    • YARV命令列の構造について
  • RubyVMをPHPで実装するにはどうするか
    • JVMは企業主導の仕様書がある。Rubyは企業が作っているわけではないので無い。OSSなのでコード読めばOK。
    • RubyVM::InstructionSequence.compile.to_binary でYARV命令列が手に這入る。
    • YARV header -> iseq offsets -> global objec offsets -> byte-code -> エントリポイントの実行という順番で処理していく。
    • PHPでどうバイナリを読んでいくか
      • ファイル処理関数とunpack。unpackはPHPでうまくバイナリを扱うために必要。
    • YARV命令列の構造の解説
      • ヘッダ部を読む話
        • 先頭nバイトは◯◯って決まってるので愚直に
    • YARV命令列を上から読んでスタックマシンのスタックに積んでいく話
  • CallInfoEntryとは
    • 引数の数とかみたいなメタデータ入ってるやつ
  • RubyVMはどれくらいの命令セット数があるのか？
    • 200個くらいある。実際によく使うものは100個くらい？Ruby3.3から6個増えたらしい。
      • Hello WorldやFizzBuzz、クイックソートくらいならそんなにいらない。
    • RubyコアコードからどうRubyVM理解する？
      • compile.cやifb_read_*を読むと良い
  • デモでHello World出来てめでたい

Day 3: Using "modern" Ruby to build a better, faster Homebrew

スライド: Using "modern" Ruby to build a better, faster Homebrew - Speaker Deck

Homebrewということで聴講。英語全然聞き取れませんでした……。HomebrewがmacOS標準添付のRubyではなく新しいRubyを使うみたいな話という予習はした。発表内容はほぼ聞き取れずなので間違い多めかも……）

  • Homebrew and Ruby
    • FormulaはDSL。Formulaを継承したRubyクラス。#installやtest blockのoverride。
    • brew caskは cask "1password" do ~ end みたいなDSL
    • 各種コマンドもRuby実装。AbstractCommandを継承したクラス。
  • Homebrew Ruby tools
    • Homebrew Rubyバージョンの変遷。
    • macOS添付のRubyバージョン（/usr/bin/ruby）を使っていた。macOS添付のRubyバージョンは古いので2016年に1.8.7だったり。
    • 今はportable-rubyを使っている
  • Building Better brew
    • brewのいろいろなコマンドの紹介
    • brew listをはやくした

Day 3: From LALR to IELR: A Lrama's Next Step

スライド: From LALR to IELR: A Lrama's Next Step - Speaker Deck

kanekoさんの発表で紹介されていたもの。LramaがPSLR(1)をやるために、まずはIELRをやるという話。昨年のTokyuRuby会議14でたまたま隣の席に座っていて繋がらせていただいた@junk0612さんの発表。（びっくりした）

  • Lramaはbuilt with ruby
  • junkさんの実績
    • LramaにNamed referencesを実装

    • Lramaの内部パーサーをraccで生成

  • CRubyのlexerの状態管理が大変だからなんとかしたい
    • 教科書的にはparser / lexerは分離可能だが、現実問題としてlexerの状態はparserの状態に影響を受ける。
      • || がきたのでORと思ったら実はブロック引数のやつでしたとか
      • <<- がHEREDOCかと思ったら配列に-1をpushしてましたとか []<<-1
    • ↑をどうにかするためのイチアイデアとしてのScannerless Parser
      • ↑のイチ実装としてのPSLR(1)
    • PSLR(1)のためには、IELRが必要。
  • LALR(1)とCanonical LALRの比較
    • LALR(1)は実用的・省メモリだが、Canonical LALRだとパース出来るものが出来ない

  • IELR Overview

    • Canonical LALRとLALR(1)のいいとこ取り
  • 今後
    • IELRのPRをマージに持っていく
    • PSLRパーサの実装
    • parse.yのリファクタとlex_satteawayの廃止

全体的な感想

たまたまインタプリタ本で手書きlexer / parserを実装したのでパーサまわりの発表を聞くことが多かった。Rubyに特化していない一般論、発表中に出てきた言葉を借りれば教科書的な話は「わかるわかる」という感じだったが、Ruby特化の話やちょっとアカデミック的な話が出てきたときに「ウッなんもわからん」となった。

印象的だったのは、「Lrama（というかLR Parser）によって、既存のCS知識・資産を活かせる」みたいな話。実際、ML系言語のparserから拝借してきたアイデアがRubyに取り込まれたりという話があった。これまで触れた言語はどれも仕事都合で学ぶ必要のあったもので、だいたい似たパラダイムのものである。が、より良いRubyのコードを書く*1ためには、他の言語のことも知る必要があるわけで、「あぁそういうのも触らんとなー」と。ひとまず、『7つの言語 7つの世界』でも読もう。ML系出てこないけどまぁいろんなパラダイムの言語を触る訓練として。

「授業でやったくらいで」「本1冊読んだ程度で」と言われてしまえばそれまでだが、高専の授業でlex/yaccを、本で手書きスキャナ・パーサをそれぞれ実装したので、パーサジェネレータと手書きパーサの比較の話や、字句解析がパーサの状態に依存するみたいな話は結構頷けるところがあった。これまでアプリ開発にしか目が向いてこなかった自分にとって、ちょっとでもそういう話に共感を覚えるというのはなにか新鮮な体験であった。

おわりに

登壇者のみなさま、とても刺激的なお話をありがとうございました。

*1:二重の意味で

RubyKaigi 2024の準備（心構え系と技術系）

ソフトウェア開発

はじめに

来週、RubyKaigiに参加する。

rubykaigi.org

RubyKaigiに行くのは2018年の仙台以来。「沖縄行ったことない*1しめちゃ楽しみだー！」とか、「久々にRuby界隈の人たちに会えるのが楽しみだー！」とか思いつつ……。

今回、会社に諸々の費用を出していただいて参加する*2ので、それなりに準備をして臨もうかなと思っている。

まずはRubyKaigiとはなんなのかを改めて認識して心構えのベースを作る。その上で技術的な話、特にそもそもRubyがどう動いているかだとかどういうトピックがRubyKaigiで扱われるのかといったところをキャッチアップしていければと思う。

技術系の話は、Web上に記事や資料が存在しているので、それらをリンク・引用させていただきつつ、自分なりの理解を書いていくという感じの構成でいきたい。

心構え系

まずは、RubyKaigiに参加する上での心構え的なところから。

大前提抑えておくべきなのは、「RubyKaigiはプログラミング言語Rubyの国際カンファレンスである。」ということだ。「いやいや、そんなこといったら◯◯カンファレンスだって、プログラミング言語◯◯のカンファレンスじゃん？RubyKaigiはなにか違うの？」と思うかもしれない。

RubyKaigiで登壇しているのは、僕らのような「Rubyを使っている人たち」というよりは、「Rubyを作っている人たち」だ。当然、話される話題もRubyそのものの話が多くなる。僕を含め、Rubyを使っている人たちがよく理解できるものかというと必ずしもそうではない。むしろ、わからないことの方が圧倒的に多いはずだ。

昨年、RubyKaigi 2023の会期中に収録されたRebuild EP360でも、Rubyの父まつもとさんが同様のことをお話されている。というか、僕の文章自体、このエピソードで話されていたことや、後ほど紹介する松田さんの発表の受け売りだ。
※ 該当箇所は10:58頃。下記リンクはそのタイムスタンプ付きのURLになっている。rebuild.fm

というわけで、後ほど紹介させていただく「ふつうのWebサービス開発者がRubyKaigiを楽しむためのRubyの知識」にも書いてあるとおり、"予習した上で「わからないを楽しむ」"くらいの心構えで臨むのが良いのではなかろうか。

最後に、先日参加したRubyKaigi 2024事前勉強会の基調講演スライドをリンクさせていただく。

初心者のためのRubyKaigi入門/RubyKaigi Introduction - Speaker Deck

これは、RubyKaigiチーフオーガナイザーである松田さんによるものだ。どういうことを考えてこのカンファレンスを作っているのかが書いてある。一読しておくとどんな心構えで参加すると良いかを考えるきっかけになるはずだ。

技術系

続いて、技術系の話。

僕らはふだんRubyでコードを書いて実行しているわけだけど、じゃあ具体的にどういうものがどう関わってプログラムを実行してるんだっけ？という概観をキャッチアップしておくと良いだろう。

RubyKaigi 2023開催に向けて書かれた下記の記事では、Rubyの処理系というものについて解説していただいている。RubyKaigiに行くと、MRI / CRubyやmruby、RubyVM / YARVそしてJIT / YJITといったキーワードを見聞きすることになると思うのだけど、それらが何者なのかを知ることができる。

qiita.com

zenn.dev

 

今回のRubyKaigi 2024に参加するにあたって追加でキャッチアップしておきたいものがあって、それがパーサとパーサジェネレータの話だ。

「Ruby処理系はRubyのソースコードを解析して構文木を生成する」というようなことが上2つの記事に書いてあったと思う。その役割を担うのがパーサである。パーサをつくるには、手書きで書くか、パーサジェネレータを用いて生成するかのふたつのやり方がある。

2023年12月にリリースされたRuby 3.3では、Prismという新しいパーサが追加され、また新しいパーサジェネレータとしてLramaが利用されるようになった。

www.ruby-lang.org

ここで自分は「Lramaというパーサジェネレーターによって、Prismがつくられたってこと？」と思ってしまった。実はそうではないのだが、同じような疑問を持つ人は少なくないようで、Twitter / Xを「Ruby Prism Lrama」で検索するといろいろと出てくる。自分がわかりやすいなと思った解説ツイートがあったので、こちらを引用させていただく。

Ruby 3.3において、構文木をつくるのは「Lramaによって生成されたパーサ」だ。一方、僕らRubyプログラマがRubyプログラム上で構文木を扱いたいとなったら、Prismというパーサを利用することができる。また、 --parser オプションを指定してrubyコマンドを実行してくれれば、デフォルトのパーサではなくPrismを使うこともできる、と理解した。

ここまでで、Lrama / Prismの役割や関係性をなんとなく理解した。そのうえで、それぞれについて解説されている記事を読んでおくと理解が深まりそうだ。

gihyo.jp

gihyo.jp

 

最後に、下記のスライドを読んでおくといい感じにRubyKaigi 2024の概観を掴むことができると思う。

ふつうのWebサービス開発者がRubyKaigiを楽しむためのRubyの知識 - Speaker Deck

これは先ほど紹介させていただいたRubyKaigi 2024事前勉強会で発表されていた資料である。このスライドでは、最近のRubyKaigiで扱われるトピックをまとめ、それぞれについて解説してくださっている。トピック解説のあとに、「該当する発表はこれです」という感じで紹介されているため、自分の興味と発表とを紐づけながらスライドを読むことができる。

おわりに

以上が、RubyKaigi 2024の自分の心構えと、予習したつもりの技術トピックだ。これによって、RubyKaigiで行われる議論を少しでも理解し楽しめると良いなと思う。

記事中で引用させていただいたみなさま、有益な記事やスライド、ツイートそしてエピソードをWeb上に残していただきありがとうございました。

この記事が、僕のようにRubyそのものについてキャッチアップしていく人の助けになれば幸いです。

*1:というか九州以南に行ったことないかも！

*2:5月入社の自分にも既存の社員さんと同じ扱いをしていただけた。大感謝。

2024年4月30日 無職最終日

8時半頃起床。

10時から無職もくもく会。最後の無職もくもく会となる。4月毎日お互いもくもくしていたのは、結構すごいことだと思う。読み進めていたインタプリタの作り方はちょうど30章あり、1日1章ペースだなとか思っていたがそんなに甘くはなかった。働き始めても進めていきたい。

ランチ後、一緒に無職もくもくをやってくれたふっくんと無職もくもく振り返りエピソードを収録した。月曜配信の通常エピソードとは別に、特別会として適当なタイミングで編集してシュッと出しておく。

夕方前くらいにカフェに行って読書。今は『「アジャイル式」健康カイゼンガイド』と『なぜ働いていると本が読めなくなるのか』を並行で読んでいる。後者の本めちゃくちゃおもしろい。本当は働いていないうちに読み切ろうと思ったけど自分の読書スピード的に間に合わず。しかし、働きながら読んだほうがあとがきの「あとがき 働きながら本を読むコツをお伝えします」とかが身にしみそう。楽しみ。技術書やら自己啓発書やらの類は1日1章ペースだが、新書はもう少し多く、2〜3章ずつくらい読めているる。

スーパーで買物をしたあと、偏頭痛の前兆が来てしまった。本当は夜ご飯を作ろうとしたのだけど、諦めて各種片付けやら入浴やらを済ませて寝ることにした。頭痛がはじまってきたタイミングで布団に入り、18時から始まったファイターズ戦をradikoで聞きながら安静にしていた。20時過ぎくらいに目が覚めたときには、ファイターズは勝っていたし、頭痛もおさまっていてよかった。

本当は無職期間振り返りブログでも書こうと思っていたけど、まだ体調万全ではないし、明日は初日で物理出社だしで、早めに寝ようかな。

というわけで、明日からは労働をやっていきます。いやーーー、最高の1ヶ月半だった。僕の最高の1ヶ月半の話を聞きたい人は、ぜひPodcastの最新エピソードを聞いて下さい。

yuru28.com

2024年4月29日 コナン

日記

8時半ころ起床。

10時からもくもく。今日はPrattパーサというやつを実装していた。プログラミング言語の処理系を実装する際、パーサはYaccやBisonのようなパーサジェネレータを使うか、手書きで書くかという選択肢がある。この本は、Javaでツリーウォークインタプリタを作った第2部も、C言語でVMを作る第3部も一貫して手書きパーサを採用している。高専の授業でもコンパイラを作ったのだが、スキャナはLexを、パーサはYaccを利用したため、ここまでガッツリと手書きはしていない。とても楽しい。

ja.wikipedia.org

午後は夫婦でお出かけ。横浜方面に行って、買い物したり、映画を観たりなど。

いよいよ明日が無職最終日。いろいろやりたいことやって過ごしていこうと思う。

2024年4月28日 編集作業のBGMに邦楽を聞く

日記

8時半頃起床。

10時半から編集もくもく。の前に、デスクまわりのセットアップをしていた。昨日の夜は机の組み立てをして力尽きてしまったので……。いつも12時過ぎくらいには編集が終わるのだが、今日は終わらずランチで中断。

ランチに作ったねぎだく鶏ささみがめちゃくちゃ美味しかった。おすすめ。

macaro-ni.jp

ランチ後、編集作業の続き。自分の中で「Podcastの編集をするとき邦楽を聞きながらだと集中できないだろう」という思い込みがあった。明日公開のEP243でも読書に関して似たような話をしたのだけど、そういう思い込みを捨てる週間をやっているので、あえて音楽を聞きながら編集作業をやってみた。結果、全然イケる。読書も編集作業も、変に神格化し過ぎて捗らないくらいなら、好きな音楽でも聞きながらノリノリでやってしまう方が僕にとっては良いのだ。

夜はもくもく会。インタプリタの作り方を進める。が、あまり集中できなかった……。やはり夜にもくもくしてしまうと、昼間のうちに溜まった雑念からくるノイズが気持ちに載ってしまい、集中力が阻害される印象がある。20:30-22:00のもくもく会だが、あまり集中できず、この時間までおかわりをやっていた。

このあとは、寝る準備をして、ちょっと読書をして、寝る。

2024年4月27日 FlexiSpotの組み立て

8時45分頃起床。モーニングサーブ脂質高い。

10時から無職もくもく会。インタプリタの作り方を進める。今日はファイル処理のコードをたくさん書いた。めちゃくちゃ懐かしい。そういえばC言語によるプログラミングの授業においてポインタはあとの方で登場する概念だけど、ファイル操作は結構序盤でやって、そのときしれっと「ファイルポインタ」っていうワードが登場するよね。

昼は昨日作ったサバ缶リゾットの残り。本当はイワシ缶リゾットになる予定だったのだけど、僕のイワシ缶はいま開かなくなった宅配ボックスに閉じ込められている*1ので、サバ缶で代用することにした。

ランチ後、副業で忙しい妻に無印良品でのおつかいを頼まれたので外出。夕方からFlexiSpotの組み立てをすると考えると、今読書しておかないと絶対夜やらないよなぁと思ったのでカフェで読書もした。

それが大正解。16時半くらいから組み立て始めて、机の組み立てが終わったのが今。夜の11時過ぎ。途中、夜ご飯やらネジ穴開けるやつを探し回ったりやらでロスしたぶんを差し引いても、4時間くらいかかったことになる。しんどすぎる。しかも終わったのは机の組み立てだけで、これから各種ケーブル類の引き回しがはじまる。

もう続きは明日だな……。

FLEXISPOT 昇降デスク E7H パソコンデスク スタンディングデスク 電動 メーカー5年保証 無段階高さ調節 耐荷重160kg デュアル静音モーター搭載 人間工学 メモリー機能/USB機能付き 配線整理(足（黒）, エッジ加工天板（ウォールナット）)

FLEXISPOT 昇降デスク E7H パソコンデスク スタンディングデスク 電動 メーカー5年保証 無段階高さ調節 耐荷重160kg デュアル静音モーター搭載 人間工学 メモリー機能/USB機能付き 配線整理(足（黒）, エッジ加工天板（ウォールナット）)

  • FLEXISPOT
Amazon

*1:2024年4月26日 無職期間最後の収録日を参照