2025年6月25日、26日に開催された AWS Summit Japan 2025 に参加してきました！弊社からは、総勢 15 名のエンジニアが参加しました！日々の業務で利用している AWS の最新情報をキャッチアップするとともに、AWS コミュニティの熱気をダイレクトに体感してきました。今回は特に印象に残ったセッションやブースを紹介します。

今回は、Flutterアプリケーションにおいてユーザーが漢字で姓名を入力した際に、自動的にふりがなを補完する機能を実装した際の技術的な取り組みについてご紹介します。特に、FlutterのMethodChannelを活用してiOSネイティブAPIと連携し、オフラインで動作する漢字→ひらがな変換機能を実現した過程を詳しく解説いたします。

かつてシングルコアCPUが主流だった時代は、毎年のようにCPUのクロック周波数の向上やトランジスタ数の増加が続き、ソフトウェアはその性能向上の恩恵を容易に享受できていました。しかし、物理的な限界からCPUのシングルコア性能の向上は頭打ちとなり、代わって複数のコアを搭載するマルチコアCPUが主流となりました。このマルチコアアーキテクチャの恩恵を最大限に引き出すためには、並行・並列処理を実現する必要があります。直列 (Serial) と並行 (Concurrent)、並列 (Parallel) の違いを図に表すと、以下のようになります。

MaximeさんはShopifyのRuby開発チームのリーダーで、RubyKaigiでも2021年から毎回 JITコンパイラの進化について発表している、いわば常連です。 毎回YJIT に関連する心躍る発表を用意してくださるMaximeさんでしたが、今回はなんと新しいJITコンパイラ「ZJIT」について発表されました。スケジュール一覧の中でも「ZJIT」のキーワードはひときわ目を引き、開催前からとても楽しみにしていました。この記事ではセッションの内容に沿って、RubyにおけるJITコンパイラのこれまでについての振り返りから始め、ZJITの開発背景や技術的詳細、そして今後の期待される展開などを紹介します。

PicoRubyとは、組み込み環境でRubyを動かすために開発された、超軽量なRuby実装です。通常のRuby（MRIやCRuby）は、PCやサーバのようなある程度リソースがある環境向けに作られています。一方、PicoRubyはマイコンのような小さな機械でも動作するように設計されています。

Low-level Ruby Observability API とは、Ruby プログラムを動かす CRuby VM のレイヤーに近い、通常は意識されない詳細に関わる計測を行う API のことです。これらの API を使うことで、アプリケーション内部の動きを可視化できます。アプリケーションの応答結果は正しいが応答時間が長すぎる場合や、検証環境では問題ないのに本番環境でのみ問題が発生する場合の原因として、いくつかの例が挙げられています。

本記事では、RubyKaigi 2025の2日目に行われたMisaki Shioi(@coe401_)さんによるセッション、「Making TCPSocket.new "Happy"!」について紹介させていただきます。が、その前に前提知識として Happy Eyeballs について軽く紹介します。1981年から長く使われてきた IPv4 ではアドレス数の枯渇が問題となっており、その解決策として1990年代から IPv6 の普及が進められています。日本ではユーザー側の回線で IPv6 の普及が進んでおり、報道によれば2024年2月に IPv6 普及率が50%に達したところです。

2日目はpicorubyやビルドシステムに関する話を中心に聞きました！ その中でも自分が紹介したいのは、Alexander MomchilovさんによるFrom C extension to pure C: Migrating RBSというセッションです。本記事では、その内容をまとめてご紹介します。

本記事では、1日目の Mari Imaizumi (@ima1zumi)さんによるKeynote セッション、Ruby Taught Me About Encoding Under the Hoodについて紹介させていただきます。今回紹介するセッションの登壇者はハンドルネーム@ima1zumiとして活動し、Stores,inc に在籍されているMari Imaizumi さんです。(以後ブログ内では @ima1zumi さん と呼ばせていただきます)2025年3月にRubyコミッターに就任し、主にIRB・Relineのメンテナンスをなさっています。本セッションでは @ima1zumi さんが実際に出会って対処した issue や Unicodeのアップグレード作業の内容について具体的な事例を交えて紹介します。

2025年4月16日-18日に開催された RubyKaigi 2025 に参加してきました。ということで、RubyKaigi 2025 に3日間参加してきたレポートをお届けします。今年の RubyKaigi 2025 は、愛媛県松山市の愛媛県県民文化会館で開催されました。会場は道後温泉や松山城にもとても近く、Techouse 参加者の全員が夜は毎日温泉に行ってました。

Rubyは動的型付け言語であり、型宣言に該当する文法が存在しません。一方で、Rubyで型を扱う手段が一切ないわけではなく、型宣言を記述するための言語であるRBSや、RBSを用いて型検査をするgemであるSteepなどが開発されています。RBS::Traceは、この発表のスピーカーである@sinsokuさんによって開発されているgemで、テストを実行することで型宣言を自動で記述してくれるツールです。

Rubyではオブジェクト指向プログラミングの基本として、Class#newメソッドを使ってインスタンスを作成します。この基本的かつ頻繁に使用されるメソッドの最適化は、Ruby全体のパフォーマンス向上に直結します。この記事ではRuby 3.5（4.0）にてClass#newがどのようにして高速化されるかについて解説します。

Masato Ohba(@ohbarye)さんによる「On-the-fly Suggestions of Rewriting Method Deprecations」についてご紹介します。このセッションでは、開発者なら誰もが経験する「メソッド非推奨化」に伴うコード修正を、もっと楽にするためのツールとその仕組みが提案されていました。

本記事では、RubyKaigi 2025 2 日目の NAITOH Jun さんの講演 Improvement of REXML and speed up using StringScanner の中で触れられていた、REXML が v3.2.7 で遅くなった件について、その原因と解決までの流れを調査した結果をご紹介します。個人のメモのような内容になってしまいますが、同じ疑問を抱いた人の理解の一助になれば幸いです。

本記事では、RubyKaigi 2025 1日目のYuichiro Kaneko (@spikeolaf) さんによるセッション、「Ruby's Line Breaks」について紹介させていただきます。Rubyを書いていると、どこで改行できるのか、迷うことがあると思います。例えば、以下の2つのコードを見てみましょう。

コード懇親会 はアンドパッド様とクリアコード様が主催する、通常の懇親会とは一味違ったコンセプトのイベントです。一般的な懇親会では参加者同士が飲食しながら会話を楽しむ形式が多いですが、コード懇親会はその名の通り「コード」を軸にした交流の場となっています。

Rubyには、parse.yからパーサージェネレータを使って生成したパーサーと、手書きパーサーであるPrismの2種類のパーサーが存在します。 本セッションでは、「オートマトン学習」という技術を用いてこれら2つのパーサーの間の互換性の問題を発見したことについて述べられました。 また、オートマトン学習のアルゴリズムの1つであるAngluinのL*や、その背景知識となるオートマトン理論の基礎についてもわかりやすく解説されました。

RubyKaigi 2025 DAY2 の @asonas さんによる "How to make the Groovebox" というセッションについて紹介させていただきます。私自身は音楽制作をしたことがない初心者です。専門用語や理論について誤った解釈がある可能性があります。ご理解をお願いします。Groovebox は、asonas さんにより開発された Ruby で電子音楽を作ることができるCLIアプリケーションです。シンセサイザー、ステップシーケンサー、エフェクターなどを組み合わせて音楽制作するためのツールで、すべてが Ruby で実装されています。

今回は RubyKaigi 2025 の二日目のセッション、junk0612 さんの「The Implementations of Advanced LR Parser Algorithm」について内容を紹介させていただきたいと思います。junk0612 さんは Ruby で実装された parser generator である Lrama のコミッターであり、主に parser を生成するアルゴリズムを実装されている方であると認識しております。昨年も RubyKaigi 2024 にて「From LALR to IELR: A Lrama's Next Step」というタイトルでお話をされていました。昨年の発表の内容は、parser の生成アルゴリズムを LALR から IELR への移行することを主題とし、IELR のコンセプトや実装の概要についてお話されていました。当時はその PullRequest は Draft の状態でしたが、一年の間にその PR がマージされ、IELR アルゴリズムを利用して parser を生成できるようになりました。以下のように lr.type オプションを ielr に指定することで、LALR ではなく IELR を利用して parser を生成することができます。

今回は、RubyKaigi 2025 で開催された「TRICK」というイベントに参加した経験と、自分の作品について紹介させていただきます。TRICK (Transcendental Ruby Imbroglio Contest for rubyKaigi) は、Ruby の言語特性を活かした技巧的なプログラミングを競うコンテストです。参加者はRubyの特徴を活かした驚きや面白さを感じさせるコードを投稿し、数名の審査員が評価を行うという内容です。今年のRubyKaigi で開催された TRICK 2025 は作品のレベルが非常に高い回だったようで、私の作品は入賞には至りませんでしたが、佳作という形で紹介いただきました。

2024年04月18日、弊社ではOSS Gate ワークショップというイベントを開催しました。このイベントは新卒向けの内容であり、講師として株式会社クリアコード様をお招きし、OSSにIssueを立てて実際にPull Requestを作成するまでを伴走していただく内容でした。詳細なイベント内容については弊社の過去ブログをぜひご参照ください。

ジョブハウスは、工場やドライバーなどの仕事を探すことができる求人メディアです。今日は、「この求人を見た人は他にもこんな求人を見ています」というレコメンド施策を例に、ABテスト基盤の実装やABテストを利用した結果ついて紹介します。

今日は、ジョブハウスで使用している Ruby on Rails の ViewComponent を用いて UI コンポーネントを実装する際に利用しているライブラリを紹介します。ViewComponent（UI コンポーネント）× Lookbook（プレビュー）× rspec-snapshot（スナップショットテスト）という、フロントエンドエンジニアには馴染みのあるようなエコシステムを、Ruby on Rails 上で実現しています。

2023年10月にリリースしたジョブハウスアプリは、FlutterとGraphQLを組み合わせたモバイルアプリとして開発を進めています。ユーザーが手軽に求人情報を検索・応募できるように毎月機能を追加しながら、成長を続けてきました。この記事では、アプリをさらに速く改善しやすくするために実施した「アーキテクチャの変更」について紹介します。ジョブハウスアプリの技術スタックや主要なパッケージについては以下に列挙しますが、詳細な説明は省略します。ここでは「なぜアーキテクチャを変える必要があったのか」「旧アーキテクチャと新アーキテクチャはどのように違うのか」を中心にお伝えします。

みなさんはモノづくりが好きですか？私は好きです。モノを作る過程は楽しいですし、自分の作ったモノが世の中を良くできたら嬉しいですし、うまくいったらお金ももらえます。最高ですね。起業する前の個人開発時代から考えると約15年間モノづくりに関わっておりますが、上記の理由から私としては今後も関わり続けたいという想いがあります。そんな私がモノづくりの最前線に立ち続けるため何をやっているのかを今回はお話します。

今回は、社内で利用しているWebブラウザベースのVoIPサービス「CallConnect (以下、コールコネクト)」における通信不安定の問題と、その解決に至る過程を共有します。TechouseではWebブラウザベースのコールコネクトを利用し、セールス担当者・カスタマーサクセス担当者・キャリアアドバイザー担当者とお客様との間の連絡にフル活用しています。Webブラウザからコールコネクトの画面を開いてボタンをポチるだけでお手軽に外線電話をかけられるので大変重宝しております。

定義：主体とは「ものごとに変化を生み出す力の源泉」である「主体性がある」とは、ものごとに変化を与える性質があるということである。 「主体的である」とは、ものごとに変化を与えようとする振る舞いをしているということである。主体というのはエネルギーの流れでありエネルギーの固まりである。 主体はいろんなものに宿る。

最近関わった機能開発において、JavaScriptを使ってフロントエンドのコードを書く機会がありました。本記事では、そのJavaScriptコードの単体テストを書く際に苦戦した理由と、テストを書きやすくするために行った工夫を書いていきます。Jestは、JavaScriptのテストフレームワークです。クラウドハウス労務では今年からJestが導入され、新規に開発された機能については単体テストが書かれていますし、インターン生を中心にテストが書かれていない既存の機能のテストを書くプロジェクトが進行しています。ソフトウェアの品質を継続的に保つためには自動テストは不可欠です。特に、クラウドハウス労務のような短いスパンでのリリースを繰り返すSaaSプロダクトでは、新機能のリリースに伴うデグレードを回避するために自動テストは殊更重要です。私たちのチームではテスト駆動開発が推奨されており、コードレビューの際には、テストが欠けたコードをリリースしようとすると必ず指摘を受けます。

Techouse では AWS をフル活用してサービスを提供していますが、利用しているサービスの1つに Amazon Neptune があります。 Amazon Neptune 、ご存知でしょうか？ Amazon Neptune は高速かつ、高い可用性とスケーラビリティをもつフルマネージドのグラフデータベースサービスです。といっても、そもそもグラフデータベースがどのようなものかご存知でない方も多いのではないでしょうか。 本記事では、実際に弊社の SaaS プロダクト「クラウドハウス労務」に Amazon Neptune を導入した事例を紹介し、 RDB との対比で Amazon Neptune (グラフデータベース) がどういったものかをご紹介したいと思います。

今回はクラウドハウス労務のメンテナンス中に起きた事件と、今後同じ事件が起きないようにするために講じた対策について紹介します。ある日私たちはデータベースのメンテナンスを行いました。来たる新機能のために必要な新規テーブルを追加したり、既存のテーブルに変更を加えたりするメンテナンスです。メンテナンス当日、新規テーブルは次々と作成されていき、順調に思われました。しかし異変は急に訪れます。マイグレーションがいつまでも終わらないのです。どうしてここまで時間がかかるのか。私たちは急いでログを確認しにいきました。ログを確認したところ、あるALTER TABLE文の実行にとても長い時間がかかっていました。対象テーブルは1000万レコードを超える巨大なテーブルだったため、変更に膨大な時間がかかってしまっていたのでした(終わりそうになかったので当日はプロセスを中止し、後日時間のかからない方法で完了させましたが、データベースのクローンを用意して同等のSQLを実施したところ完了まで3時間30分かかりました)。