今日で現職在籍ちょうど一周年🥳 オファー承諾から一年経った🎞️ (入社日は8月10日) pic.twitter.com/aBF6mLo67L— Ryuta Kamizono (@kamipo) 2026年8月3日 この一年ぐらいの出来事をいくつか振り返ってみようと思って書き始めたら、仕事パートだけでだいぶ量いったからタイトルを「仕事の近況2026」にした。その他の近況については気が向いたらそのうち書く。 あと、2026年9月19日(土)に名古屋Ruby会議05でなんか話すのでよかったら聴きに来てね👂 昔書いたコードの話してもアレなんでたぶん最近Railsコミッターとして書いたコードについてなんか話すと思います🙂‍↕️ 仕事 Rails 7.0から最新Rails対応企業に 仕事で遭遇した問題の修正をupstreamに 基本的にRailsアプリケーションのPRは全部巡回してて気になると

Railsコミッター kamipoが、IVRyで不完全さと向き合う理由 ── Tech and Me #6 世界的なOSSであるRuby on Rails。その内部挙動や歴史的経緯を深く理解し、自らコードに手を入れてきた「Railsコミッター」の一人が、上薗竜太（@kamipo）です。 Railsのコアに向き合い続けてきた圧倒的な技術力と、完成度に妥協を許さない姿勢。かつては、自分のペースで深く掘り下げながら進める開発スタイルの中で強みを発揮していた彼は、なぜ今、IVRyで他者と前提をすり合わせながら進める立ち上げフェーズに取り組んでいるのでしょうか。 「得意なことだけをやっている時間は、新しい扉を開けていない時間だ」 Railsという巨大なコードベースを支えてきた彼が、40代を迎えて選んだのは、あえて自分の「苦手」を引き受ける挑戦でした。他者と価値をつくり、これまでの延長線上にはない景色

「Ruby on Railsのテーブル設計とトランザクション処理 LT Night」で話した内容のフォローアップです。主に懇親会で id:kamipo さんから現地でもらった質問を受けての補足となります。 speakerdeck.com 図中のオレンジ枠と緑枠のトランザクションを分けているのはなぜ？　ログレコードが保存できてイベントレコードが保存できないことなんてなくない？ 説明がスッポリ抜けていたのですが、ASPからwebhookを受けて諸々の処理をする部分は非同期処理になっているのでそもそもライフサイクルごと分かれていたのでした。つまり、webhookを受けたタイミングでログレコードを記録してからキューイングし、それを非同期的にイベント処理をするので必然的にトランザクションが分かれる。 それはそうとして、イベントを扱う処理中に不慮のクラッシュが発生した時にロギングが巻き込まれると後の調

はじめに 「Just use Postgres」という言葉を初めて聞いたのは、いつだったか覚えていません。Twitter か Hacker News か、あるいは社内の Slack か。どこで聞いたにせよ、私の反応は決まっていました。「また極端なことを言う人がいる」と。 「それ、〇〇でもできますよ」——この手のフレーズはもう100回は聞いてきました。そして大抵の場合、その〇〇は専用ツールに置き換えられていきます。技術が専門分化していくのは自然な流れです。 全文検索なら Elasticsearch。時系列データなら InfluxDB。メッセージキューなら RabbitMQ。それぞれの分野に専門家がいて、専用のソリューションがあって、ベストプラクティスがあります。「とりあえず Postgres で」なんて、それは思考停止ではないか、と。でも、心のどこかで気になっていたんです。 www.mann

回答: Java, JavaScript, Pythonなど、多くの言語でUnicodeを用いたUCS(Universal Character Set)方式を採用している理由は、推測ではありますが、 * Unicodeで十分と思った * UCS方式の問題にあまり遭遇したことがなかった * CSI方式は実装が複雑すぎて現実的ではないと思った とかではないでしょうか。これらの言語の設計者はみな欧米人で、だいたいASCIIかISO-8859でテキストが表現できてしまうので、マルチバイト文字の闇を覗き込む機会はほとんどなかったんですよね。 一方、私を含めて日本人(またはアジア人)たちは...

概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Frozen String Literals: Past, Present, Future? | byroot’s blog 原文公開日: 2025/10/28 原著者: byroot -- Railsコアコミッター、Rubyコミッターです 日本語タイトルは内容に即したものにしました。 frozenは基本的に英ママとしました。 なお、Ruby 3.4以降ではRUBYOPT環境変数でRUBYOPT="--enable-frozen-string-literal"のように指定すれば、その環境で文字列リテラルをデフォルトでfrozenにできます。また、Ruby実行時に--disable-frozen-string-literalを指定すれば一時的にこの設定を解除できます。 Rubyistの皆さんなら、Rubyソースコードのほどんどのフ

こんにちは。メドピアのお手伝いをしている@willnetです。最近寒くなってきましたね。毎年この時期に風邪をひくので最近は手洗いうがいを怠らないようにしています。このたび久しぶりにテックブログに寄稿します。 insert_allの仕様変更に関するPR メドピア内のとあるRailsアプリケーションのバージョンを7.2から8.0にアップグレードしたときにinsert_allの仕様変更に気づいた話をします。　insert_allの仕様変更に該当するのは次のPRです。 Fix active record insert values of type cast and serialize by OuYangJinTing · Pull Request #48139 · rails/rails 上記PRではsaveメソッドとinsert_all(及びinsert、insert_all!)メソッドで値の変

「これからのキャリアが不安だ」というエンジニアの悩みをよく聞きます。 AI時代、プレイヤーとして活躍し続けたいけど、果たして生き残れるんだろうか？ 事業理解やマネジメント力も身につけた方がいいのか？ とはいえ、どうやってそれを身につければいいのか？……といったことです。 先の見えない時代をどう生き抜けばいいのかわからない。 エンジニアに限らずですが、そんな迷いを抱えた人は多い気がします。 そのヒントになりそうだと思ったのが、スタメンの創業CTO、小林のキャリアです。 小林さんはヤフーの新卒１期生。グリーでは役員として上場にも貢献し、そのあとCTOとしてスタメンを創業。僕らの主力サービスである「TUNAG」を作り上げ、さらには０から開発チームの組織を作ってくれました。 今はスタメンの子会社である「株式会社スタジアム」という会社で、VPoEをやってくれています。 創業CTOのコバさん。いつもパ

Amazon Web Services ブログ Amazon DynamoDB におけるシングルテーブル vs マルチテーブル設計 この文書は、AWS ヒーローであるAlex DeBrie によるゲスト投稿です。 Amazon DynamoDB について学ぶ人にとって、シングルテーブル設計という考え方は、最も心を揺さぶるコンセプトの1つです。DynamoDBのテーブルは、エンティティごとにテーブルを持つというリレーショナルデータベースのような概念ではありません。多くの場合、1つのテーブルに複数の異なるエンティティを含みます。 DynamoDBのシングルテーブルに関するデザインパターンについては、DynamoDBのデベロッパーガイドを読む、re:Inventのトークやその他のビデオを見る、私が執筆した本をチェックするなどで理解することができます。シングルテーブル設計の賛否両論に特に焦点を当て

このデータ重複は、開発現場で地味ながらも厄介な問題を頻発させていました。 データ不整合のリスク: ユーザー情報更新時に片方のテーブルしか更新されず、データが食い違う危険性。 開発効率の低下: 「どちらのnameを参照するのが正だっけ？」という確認が毎回発生し、開発やレビューの効率を阻害。 これらの課題を根本から解決するため、usersテーブルから重複しているnameとemailを削除し、auth_usersにデータを集約することを決断しました。 統合戦略：段階的なアプローチが鍵 データ統合のような影響の大きい変更は、一度に行うとリスクが非常に高まります。そこで、私たちは安全性を最優先し、段階的に進めるアプローチを取りました。 ステップ1：delegateでシンプルな参照を片付ける まず、最もシンプルな参照箇所を修正するため、Railsのdelegateメソッドを活用しました。 # app/

去る3月24日、BLACKNAZARENEのラストライブを見届けた。 ✦••――――••✦••――――••✦ BLACKNAZARENE LAST LIVE TOUR -奇祭- FINAL ✦••――――••✦••――――••✦ BLACKNAZARENEのラストライブ 本当にありがとうございました 7年間、出会ってくれた全ての方々に感謝いたします… pic.twitter.com/Um1GNTY4cD— BLACKNAZARENE (@blacknzrn) March 25, 2025 これはオタクとしての感想エントリーというよりは、これまでの人生を振り返った自分語りを、ひとつの物語を見届けたこのタイミングで残しておきたかったという内容になると思う。 ナザレには推しがふたりいて、どっちかだけに言及するのはSNSではしないようにしてたんだけど、ここではアイドル東出ひみこの物語を語らせてほし

これはなに この記事は米シリコンバレーでデータベースコンサルや教育事業を展開するKloudDB社がポストした『Understanding How ONLINE DDL (INPLACE) works in MySQL』の翻訳記事です。 この記事ではDDL（スキーマ変更クエリ）の内部処理について詳細に解説しています。DDLはシンプルに利用できるものの、一歩踏み込むと複雑怪奇で理解の難易度は高いものでした。この記事はそこに焦点を当てたものになります。 翻訳するにあたり、技術的な正確性を担保しつつ、日本語表現として自然になるよう努めました。もし記事の中で技術的な観点で不正確な箇所があれば訳者の責任ですので、コメント欄などでご指摘いただけると幸いです。 また、翻訳について許可を下さったSrinivasa R Inaganti氏（同社CEO）に感謝します。 以下、訳者による前書き的なものを挟んで、翻

Redditで話題になっていたポストを訳してみた。 僕は自分が思っていたほどは頭がよくなかったという高校生の独白にたいしてつけられたこのちょっと長めの返信がとても的確で示唆に富んでおり、多くの人のこころをつかんでいました。私自身、勇気づけられるというか身につまされるところがあり、忘れないために翻訳をしてみました。 まずは高校生の独白から。 僕は自分が思っていたほどは頭がよくなかった 僕はいま高校の最終学年で、次の６月に卒業する予定です。高校の成績は、いままでずっとAを取りつづけていましたが、去年始めてBをとってしまいました。もしそのBがなければ、卒業生総代に選ばれていたでしょう。 総代にふさわしいのは自分だ、つまりクラスで本当に一番頭がいいのは自分だと思いたいです。でもこの一年で、僕にそれほどの知性はないし、僕より頭のいい人はたくさんいるんだということを思い知らされました。 また僕は、自分

特定のリポジトリに対して機能追加・変更やバグ修正などを行う場合、エンジニアはPull Requestを発行します。プログラミングを続ける過程で数えきれないほど発行されるPull Requestは「エンジニアが歩んできた道のりそのもの」と言っても過言ではありません。 ならば、オープンソースコミュニティで活躍する方々が「特に印象に残っているPull Request」には、その人のOSS活動への思いや日々の研鑽が結実しているのではないでしょうか。今回は8名の著名エンジニアの方々に回答していただきました。 ※人名の50音順に掲載。回答者は敬称略。 k0kubunが紹介『Count trace_running for internal event』 github.com これは私が新卒1年目に初めてRuby本体に送ったPull Requestです。 当時、私は社内の開発者の生産性を改善するチームに所

チンポプラというコピペがある