うなすけとあれこれ

Translated by AI (and reviewed by me) from handwritten Japanese text. (日本語が後に続きます)

RubyKaigi 2026 follow up and Fastly Tech Meetup vol.1

I gave talks at two events in September:

At both events, the people I met there greatly influenced my progress this month. Thank you all very much. Perhaps I should make a habit of regularly stepping outside my home.

quic-ruby (quic gem)

https://github.com/unasuke/quic-ruby

At the follow-up event, I was encouraged by someone saying, “Since you’ve secured a good namespace, you should…”, which motivated me to finally address the untouched diffs in my repository. The diff in question was related to distributing the gem as a fat package by adopting LibreSSL as the encryption layer, as ngtcp2 had listed it as “experimental” in their README.

Later, during a conversation with kazuho at the Fastly event, he suggested using h2o/picotls. At that time, one unclear point was whether picotls would function properly when running on systems with LibreSSL instead of OpenSSL (specifically, whether the OpenSSL APIs picotls uses were available in LibreSSL). However, subsequent testing with MCP app revealed that this approach might actually work, so I decided to proceed with this direction. In other words, instead of distributing as a fat gem containing both ngtcp2 and LibreSSL, I modified the distribution method to download and install ngtcp2 and picotls at runtime, utilizing the C APIs of either OpenSSL or LibreSSL depending on the execution environment.

https://github.com/unasuke/quic-ruby/releases/tag/v0.0.2

Raiha

This is a Pure Ruby implementation. As previously noted in an issue reported by thekuwayama regarding TLS layer implementation, there were some inefficient aspects in the initial design. While I could use AI to drive the development process and successfully discuss the QUIC protocol, I realized that continuing implementation while carrying over these inefficiencies would be overly challenging, so I decided to thoroughly redesign the architecture.

My Personal MPC: mcp-coderunner-app

Throughout the extensive design iterations, there were numerous instances where I needed to write code to validate whether the design was reasonable or to determine which approach would perform better in benchmarks. While I could technically use Claude Code on my local machine, when I wanted to do this even on my smartphone while on the go, the terminal interface becomes significantly limited in screen size, making operations noticeably sluggish. Therefore, I developed a Rails application that communicates with MCP. The screenshot at the beginning shows the management interface for this application.

https://github.com/unasuke/mcp-coderunner-app

This is a MCP server that allows you to execute arbitrary Dockerfiles and scripts on your home machine via MCP and return the results. While lightweight scripts can be executed directly on Claude.ai, scenarios like wanting to test different language versions, testing in environments with specific libraries, or verifying that external library builds succeed would naturally benefit from offloading these tasks to more powerful resources. Thus, I created this application that combines a lightweight management interface with local docker run workers. Although it’s publicly released as OSS, it’s strictly for my personal use. Having the code publicly available means I get free CI services and easier deployment…

I’ll be off in October.

Everyone, please come to Kaigi on Rails 2026.