komagataのブログ

最低限のFeature Flagの機能とWeb UIを備えたgemを作りました。

komagata/switchlet: Minimal feature flag gem

インストール

bundle install
rails generate switchlet:install
rails db:migrate

使い方

if Switchlet.enabled?(:my_feature)
  # my_feature code
end

（まだ存在しないフラグはfalseになります。）

よくあるパターン

# 6月1日以降に有効にする
if Switchlet.enabled?(:my_feature) && Time.current > Time.parse('2025-06-01 00:00:00')

# 4分の1のユーザーに有効にする
if Switchlet.enabled?(:my_feature) && current_user.id % 4 == 0

# スタッフユーザーにだけ有効にする
if Switchlet.enabled?(:my_feature) && current_user.stuff?

Web UI

下記で使えるWeb UIからフラグを作成・ON/OFFできます。

mount Switchlet::Engine => "/switchlet"

本番環境でWeb UIからフラグのON/OFFすることを想定しているので複数の方法でWeb UIへのアクセスを制限できます。

# config/initializers/switchlet.rb
Switchlet.configure do |config|
  # Devise + admin role
  config.authenticate_with do |controller|
    controller.authenticate_user! && controller.current_user.admin?
  end
end

上記はdeviseとの組み合わせ。Basic認証やIPでの制限、それぞれの組み合わせもできます。

作った理由

Feature Flag系のgemを色々試したのですが、僕の用途にとっては複雑でオーバースペックなものが多かったためです。 上記に書いた、どういう条件で有効になるかみたいなものは表現力の高いruby自体で書きたかった。

Machintosh Plus付属のM0110インスパイアのVortexのM0110を買いました。

M0110 Triple-mode - Retro design - Vortex Keyboard

「配列といい、見た目といい、俺の求めてた理想のキーボードだ！」

と思って喜び勇んで購入しました。

届いた実物は、ボディがびみょう〜・・・にチープ感があるというか、なんかテンションが上がらない感じ。寸法とか完璧なんですが質感がなんか・・・。打鍵感・打鍵音もTofuと全然違ってどうなんだろうなぁという感じ。

ただ、メインにしてしばらく使っているとこの控えめな感じが良くなってきました。キー配列が俺にとってベストであるのは確かなので、ミスタイプが無くて生産性は上がってます。（ここ数年、常に何らかのキー配列修行をしている感じだったので…）

また、ファームウェアと周辺ソフトウェアもイマイチな感じがします。Triple modeのを買ったのでキー設定はVIAとかでなく、専用のソフトなんですが、最初試したmac版はイマイチうまく設定できませんでした。Windows版を試したら大丈夫でしたが、後で調べてみるとmac版は最初存在しなくて後で出てきたようで、イマイチ評判が良くないです。

また、無線の2.4GhzとBluetoothはそもそも接続が成功してないし、技適もないので有線で使ってます。最初から有線版にすれば良かったかも。

もうちょっとスイッチやキーキャップを変えたりいじって試してみたいと思います。

久しぶりにキーボードを買いました。

Tofu60 Redux Kitです。

KBDfansじゃなくて遊舎工房で買ったら翌日届きました。（スゴイハヤイ）

スイッチとキートップは昔買った家にあったやつです。スイッチはGateron Clearでキートップは・・・名前忘れました。（TOKYOなんとかだった気がします）

分割からの帰還

肩が痛くて分割型じゃないとダメだったので、ずっと分割型のLily58 Proを使ってました。壊れたりしながら３台連続で使っていました。（ブログに書いてないけど、下記の後に無線化されたやつを使ってた）

• Lily58 Proを作った - komagataのブログ
• Lily58 Proの2台目 - komagataのブログ

最近は何故か分割型だと逆に肩が痛くなっってきたので非分割型に戻ってきました。60%か65%で迷ったんですが、HHKBで慣れてる60%で一番オーソドックスっぽいTofuを手始めに買ってみるかって感じで買いました。

思った以上にTofuで角が怖いくらい尖ってます。

スタビライザーを使ってるキーが軒並みパンパなく安っぽいカチャカチャ音がしていて、静穏化方法を試したり、すでにカッコいい別のやつを見つけて注文してしまったりして、再び沼ってます。

来週の27日にHireRooさんの下記のイベントでお話しさせていただくことになりました。

NEXT StepUp ! Web企業へ転職したいとき気をつけることはなんですか？ - connpass

フィヨルドブートキャンプでのメンター以外にフィヨルドエージェントという名前でエンジニア紹介業務もやっているのですが、そこで色々な方を紹介してきた経験から実際にあったことを踏まえてお話しする予定です。

またこれからのAI時代のエンジニア就職・転職についても話せればと思っています。

また本イベントの参加者は、技術者のみとさせて頂きます。

こう書いてありますが、プログラミングを勉強中の方（スクールの生徒の方）もOKとのことです〜。

鳥井さんに「伝わるコードレビュー」を献本いただきました。

プログラミングスクール「フィヨルドブートキャンプ」（以下、FBC）のレビュワーとして、またこれから学ぶ生徒の視点に立って読ませていただきました。

本の構成

本書は、以下の3部構成になっています。

• Part 1. 心構え編
• Part 2. 実践編
• Part 3. TIPS編

心構え

最初に心構え（原理原則）について述べられている点がとても良かったです。

FBCでも、同じ指摘が続くとカリキュラムのドキュメントにTIPS的にまとめる取り組みをしてきましたが、心構えのような原則まではカバーできていませんでした。
本書のように、TIPSだけでなく心構えを体系的に示してもらえると非常にありがたいと感じました。

コードレビューとコミュニケーション

FBCの卒業生を紹介した企業の方から、

「FBCの卒業生はPRベースでチーム開発をした経験があり、とても助かる」

というお声をいただくことがあります。

これまでは、GitやGitHubの使い方に慣れている点が評価されているのだと考えていました。
しかし本書を読んで、コードレビューにおけるコミュニケーションにも、言語化されていない多くのノウハウがあることに気づかされました。
そして、生徒たちはチーム開発の経験を通して、そうしたノウハウを自然と身につけていたのだと改めて感じました。

特に印象的だったのは、「生徒同士でレビュワー役も担当するようにした」タイミングで、PRやコミュニケーションの質が一気に向上したことです。
レビュワー側を経験することで、わかりやすいDescriptionやこまめなコミュニケーションの大切さを実感できるようになったのだと思います。そう言った点も本書でさらに深く学べると思います。

まとめ

本書で語られている内容は、私自身がこれまで意識してきたことや、読んできた本の考え方と方向性が非常に一致していました。
FBCの生徒にもぜひ伝えたいと思い、参考書籍リストに追加させていただきました。

今後、もしコミュニケーションミスが発生した際にも、本書を土台にして話し合えると思うと、非常に心強いです。

2025年明けましておめでとうございます！

12月下旬に千歳烏山から川崎に引っ越しました。 前が駐車場がちょっと離れた場所にある家だったので駐車場が付いてるマンションがいいなということで引っ越したんですが、色々環境が変わって四苦八苦しています。

荷物を運んだり、新しい家で設置したりする過程でディスプレイがイカれました。 これは引っ越し屋さんのせいとかではなく、完全に俺のせいです。

速攻でおくるだけに送って新しいディスプレイを買いました。 壊れたのは曲面のウルトラワイドディスプレイだったんですが、デカいし、僕のやるゲームはほとんどワイドさを活かせなかったりワイドな解像度に対応してなかったりして意味薄かったので新しいディスプレイは仕事向けに普通の平面4Kの27インチにしました。

RubyのParser周りの動きを追っかけた - komagataのブログ

parse.yは大幅に変えずにbisonをlramaに切り替えられたってこと？

ちょっと前になっちゃうのですが、STORES Tech Conf 2024に参加しました。

席についた時、たまたま隣がkanako.yさんで、「あ、隣kanakoさんだ」と思ってたんですが、

見ていた発表が終わってkanekoさんが、

「(lramaは)parse.y、bisonと互換性あるので読めますよ」

と言って立ち去りました😆

疑問点が作者本人によって解決するとは思いませんでした。

しっかし、その方法ってparse.yが変わらないわけだから、マルっと変えちゃうよりもこれまでrubyを開発してる人大満足の方法だなと思いますが、僕にとっては、

「理屈はわかるけど現実的に可能ものなの？」ってレベルの難しさ・大変さな感じでびっくりです。凄すぎ。

prismは"A new compiler for CRuby 3.3+"と書いてあるけど、YJITと競合するってこと？ https://speakerdeck.com/kddnewton/why-prism?slide=32

こちらの方はアフターパーティーで@joker1007さんに教えてもらいました。

prismはデータ構造を変えてるので、その部分をVMへのバイトコードにコンパイルする部分は自前で用意する必要がある（用意してる）のでその辺りのことを示してるそうです。

お二人に感謝です。やっぱりイベント行くとお得なことがありますね〜。

先日、福岡Rubyist会議04に行って @yui-knkさんや@kddnewtonさんのParserの話を聞きました。

僕はRubyKaigi2023は松本まで行ったものの中耳炎で発熱してずっとホテルでダウンし、RubyKaigi2024はギックリ腰で中途半端にしか参加できませんでした。つまり一連のParserの話に完全に乗り遅れてしまっていました。

これまでのRubyKaigiの動画やブログエントリーなどを見て追っかけて見ました。ruby内部や言語実装について詳しくないので理解が間違ってるかもなのと、いくつか疑問点が出てきたのでXなどでご指摘いただければありがたいです。

現状の理解

rubyのparserには下記の問題がある。

• メンテナンス性
• エラー許容性
• 処理系ごとにparserが別

これらを解決する手始めとして@yui-knkさんが既存のbisonを置き換えるlramaを作った。 @kddnewtonさんとshopfyはprism(旧yarp)を作った。

ruby3.3でbisonがlramaに置き換わった。prismはdefault gemになった。

疑問点

prismは"A new compiler for CRuby 3.3+"と書いてあるけど、YJITと競合するってこと？
https://speakerdeck.com/kddnewton/why-prism?slide=32

prismは「3.3ではオプション、3.4プレビューではデフォルト」って書いてあるけど、これはparserの話？compilerとしての話？
https://speakerdeck.com/kddnewton/why-prism?slide=100

parse.yは大幅に変えずにbisonをlramaに切り替えられたってこと？

追記：いろいろ解決しました Parser周りの疑問が少し解決 - komagataのブログ

車を修理に出していて、代車のダイハツのタントで@machidaとのお台場ランチに行った帰り道。

首都高から永福ICで20号に下りてすぐの辺りでボンネットから煙が出てきてガッタンガッタンいったあと、車が全く動かなくなった。ボロいボロいとは思っていたけど止まるほどとは。クッソ暑い昼間だったのでエンジンにも厳しかったんでしょうな。

妻が110番して警察がすぐに駆けつけた。

安全な場所まで車を押してくれる警察の方々。

消防も駆けつけてなんだかえらいことになった。

レッカーを呼んで車屋さんまで行って新しい代車の日産マーチを借りて帰りました。

車屋さんの

「代車はマーチでいいですか？あ、もうウチの車乗りたくないですかね？（笑）」

という自虐ジョークに苦笑い。

早く慣れた自分の車に帰ってきて欲しいです😭

7月1日にFBC（フィヨルドブートキャンプ）でフロントエンドエンジニアコースをオープンしました。

既存のRailsエンジニアコースではTypeScriptをやらないし、ReactやNextをがっちりやるコースとして作りました。

また、Railsエンジニアコースでは実質バックエンド・フロントエンドやってインフラもちょっとみたいなフルスタックコースになっているので必要な技術が多くて、卒業までの時間が2年とかかかる方もいたりと長過ぎになってたのでフロントエンドエンジニアコースではフロントエンドだけでバックエンドやインフラは意識的に入れませんでした。

このあと、Railsエンジニアコースの方はフロントエンド関連はHotwireにしちゃってReactからStimulusに変える予定。これができれば役割分けがすっきりして両方とも卒業までの期間を圧縮できそう。

あとは、生徒の方がコードの問題をたくさん解くことができるように、ブラウザ上で競プロみたいに問題を出す機能を作っています。Rubyの方はwasmでJSはそのまま実行。競プロだと実行時間や不正対策が難しそうですが、スクールの練習問題としてはそこまで厳密でなくていいので使えそうです。

フロントエンドエンジニアになりたいって人が新しいコースに入ってくれれば嬉しいなあと思います。