先日のKaigi on Rails中の雑談として @ima1zumi さんから、RDBに対して秒間1000コミットぐらいで処理が詰まってる場合ってどうするのが良いのか、という質問を受けまして、雑談の中で色々答えてたんですが、せっかくだから記事にまとめておこうと思います。 ちょっとしたKaigi Effectって感じですね。 今回のKaigi on Railsのトークの中では、 数十億のレコードを持つ5年目サービスの設計と障害解決 by KNR - Kaigi on Rails 2023 の話なんかは割と関連がありますね。ユーザーの行動履歴というのは、ユーザー数 * N * タイムスパンで増えていくレコードなので、書き込みとデータ量が爆発しがちです。トランザクションで堅牢に処理しなければいけないケースもそこまで多くないので、RDBだと書き込みに対する処理が過剰なケースが多い。実際のところこの

SmartHRでは開発にRuby on Railsを広く採用しています。 今日は負債解消のために、開発しているサービスでRailsのモデル名をすべて変更した話を紹介します。 既存のモデル構造のつらみ 私達が開発しているサービスでは、モデルの親子構造が分かりやすいということで、モデルをネストした構造にしていました。 例えば、 User に紐づくプロフィール画像 User::ProfileImage は、 app/models/user/profile_image.rb に配置する具合です。 パッと見の構造が分かりやすいのですが、時が経つにつれて次のようなつらさが顕在化してきました。 Railsの規約(推奨ルールのようなもの)に則っていないので、関連定義が冗長になる テーブル名が長くなる。 外部キーや関連名が長くなる。 関連名と外部キー名が一致せず、カラムを呼び出したいときにDB定義を見ないと

会計チームで債権周りの開発をしている hachi (@hachiblog)です。会計チームが開発している freee 会計は freee の中で一番歴史が長いプロダクトです。加えて会計というドメインは複雑かつバグを生むと顧客の業務を大きく阻害するという点で一度作ったものを変更しづらいという特徴があります。 そのような環境で今回、債権のチームでは freee会計の初期からある「自動で経理」という機能の一部リファクタリングを行いました。リファクタリングのしづらい環境下でうまくリファクタリングをすすめるための tips は多くの人に役立つのではと思い、このエントリを書くに至りました。 今回「自動で経理」でリファクタリングしたときに事前に以下のことを行いました。 課題の発見 課題の具体化 設計とスケジュール見積もり テストコード実装 それぞれについて今回意識したことを書いていきます。 課題の発見

しおいです。 みなさまRubyKaigi 2022お疲れ様でした! わたしはありがたいことに去年に続き、DAY2に登壇する機会をいただきました。 rubykaigi.org 今年は3年ぶり2回目となる現地参加となり、本当に楽しいあっという間の3日間を過ごすことができました。 この記事では、今回のテーマを選んだきっかけ、実際に作ったもの、登壇本番のことや会期中のあれこれを振り返ります。 Wireshark + mruby + dRubyのお話をするに至ったきっかけ 今回は「Packet analysis with mruby on Wireshark - dRuby as example」というタイトルにて「mrubyを組み込んだWiresharkでdRubyパケットを解析する」という内容でお話をしました。 こうした登壇テーマを選ぶに至ったのは、去年2021年のRubyKaigi Takeo

こんにちは、Software Engineer in Qualityチーム(通称SEQチーム)の @teyamagu です。 私たちのチームは普段自動/手動テストの基盤開発や開発フィードバックサイクルの高速化に向けた開発をおこなっています。 その一環で、先日、社内でfreeeの自動テストシステム全体像を共有したのですが、この辺りのことを社外の友人達と話したところ、自動テストの具体的な構成や普段の運用など事例が少なく、どんなことをやっているのかイメージしにくいとの話を伺ったので、社内向け原稿をちょっと手直しして、おすそ分けと言うことで、ここで紹介します。 特に変わったことをおこなっているわけではありませんが、自動テストの関係性の理解に参考になれば幸いです。 基本的な考え方 自動テストが既存のデプロイ・リリースのブロッカーではなく、開発のフィードバックを加速させるために、自動テストそのものが高

誰かからの相談がなかった時、遅かった時、どうして相談してくれなかったのか、なぜ勝手に物事を進めるのかと憤りを感じることがあると思う。 自分の経験から言うと、相談されない時は相談を受ける側に理由がある。いや実際には違うかもしれないが、そう考えておいた方が楽。相手の行動を変えるより自分の行動を変える方が簡単だしコントロール可能だからだ。100%自分に理由があると仮定して物事を考える方が建設的である。 相談されなくなる理由は大きく分けて2つしかない。「相談する必要がないと考えている」か、「相談したくないと考えている」かのどちらかだ。 「相談する必要がないと考えている」 この場合、どういう時に相談をしてほしいか相手とすり合わせる必要がある。デリゲーションポーカーなどで権限委譲を見直したりしてもいいかもしれない。 目的とインパクトの大きさの認識があっていないこともある。まあこれも話すなり明文化するな

こんにちは、プログラミングを勉強中のデザイナー、sugiweと申します。 福岡周辺の地域RubyコミュニティであるFukuoka.rbのロゴデザインコンペが開催され、ありがたいことに自分の提案を採択していただきました！ Rubyというのは、まつもとゆきひろ氏により開発された日本産のプログラミング言語で、Rubyで書かれたRuby on Railsというフレームワークは国内外問わず非常にたくさんのサービスで活用されています。 今回ロゴをデザインさせていただいたFukuoka.rbをはじめ、RubyやRuby on Railsに関することを自主的に学ぶ勉強会や団体が数多くあり、それらは地域Rubyコミュニティ（あるいはRubyコミュニティ）と呼ばれています。 今回の記事では決定したロゴのご紹介とともに、最終的なデザインに至るまでの過程などについて書いていきます。 背景note記事で触れるのは初

Apple Silicon の時代が来る Repro でサーバーサイドの開発をお手伝いしているうなすけと申します。 2021年10月19日に行われた Apple の新製品発表において、M1 チップを搭載した MacBook Pro が発表されました。この発表により、Intel チップを搭載した MacBook はラインナップから消え、今後は M1 チップ上で開発する機会が増えることは確実です。 ところで、私達の開発環境は M1 に対応しているのでしょうか？ 社内の開発メンバーの大半は MacBook を使用しているので、もし対応していない場合、なるべく早く対応させないと新しい社内端末を購入できなかったりするので、結構影響が大きいです。 またインターネット上で、M1 Mac を使用している人々からの「全然発熱しない」だとか「ファンが回ることがない」とか「電池の持ちがすごい」とかの良い評判を目

こんにちは。プロダクトエンジニアの @sugamasao です。 SmartHRのプロダクトエンジニアは中途採用で経験者を採用していますが、必ずしもRuby/Rails経験者ばかりではありません。 今回はそういった方向けに binding.pry でデバッグする際の使い方をお伝えできればなあと筆を取っております。（昨今ではdebug.gemやbinding.irbでも代用できる気配を感じていますが、それはそれということで何卒） また、以下のコードはRuby 3.0.2とPry 0.14.1で動作確認をおこなっています。 binding.pryってなに ソースコード上に binding.pry と記載してからプログラムを実行すると、該当行で処理を中断し、ターミナルから直接プロセス内の状態をpryで参照、変更することができます。 binding.pryで止まると、こんな感じの内容がターミナルに

Kaigi on Rails 2021の振り返り この記事では先日行われたKaigi on Rails 2021の振り返りを行います。 私（@okuramasafumi）はチーフオーガナイザーですので、主催者目線での振り返りとなります。 ブースについて 個人的には、今年のKaigi on Railsの最大のポイントはやはりオンラインブースでした。これはまだあまり前例がない試みであり、カンファレンス全体の印象を左右しかねない試みでもありました。ありがたいことに概ね好評をいただいている今回のオンラインブースについて、振り返ってみましょう。 オンライン開催、再び Kaigi on Railsのカンファレンスは前回のSTAY HOME Editionに続いて2回目です。開催形態はまたしてもオンラインとなりましたが、前回終了時点でオフライン開催の見込みが全く立たなかったことから今回もオンラインでの開

こんにちは、鈴木です。 「テストが無い」状態を脱却しました。 「いつの時代かよ！」と突っ込まれるかもしれませんが、モノタロウは創業から 20 年ほど EC をやっています。昨日書いたコードも、15 年前に書いたコードも、元気にビジネスを支えています。 本記事ではモノタロウの EC を支える API の話をします。「テストが無い」状態がスタートラインでした。そこから、CI を導入して、ローカル開発環境の整備して、テストコードを書いて、リリースマネジメントを導入しました。 目新しいことは書きません。長寿の大規模システムであっても、愚直に数年取り組むことで、「前進できる！」「変えられる！」という実例を書きます。 ※本記事の初出は、 Software Design2021年9月号「Pythonモダン化計画（第2回）」になります。第1回の記事は「Software Design連載 2021年8月号

こんにちは、id:r7kamura です。業務委託という形で1年ほど関わりながら、美容のクチコミサービスLIPSに利用しているRuby on Rails (以下Rails) というWebアプリケーションフレームワークのバージョンを、4.2から6.1に上げました。 Rails 4.2のリリースは2014年、Rails 6.1のリリースは2020年なので、およそ6年分のバージョンアップを一気に推し進めたことになります。 今回はこれを題材に、この手のフレームワークのバージョンアップ時に起こりがちな諸問題や、やって良かったこと悪かったこと等について振り返ろうと思います。 あまりRailsに限った話はしないように心掛けて書いたので、こういったバージョンアップ作業に興味がある方にはぜひ読んでいってもらえればと思います。 変更の粒度など レビューのやり方 複数データベース対応で困った話 テストがなくて困

こんにちは、ForShcool事業部の島田です。好きな漫画は「ドラフトキング」です。 スタディプラスではこの度、会社として RSpec に寄付をしました。 rspec.info なぜOSSへ寄付するのか 2020年12月からGitHub Sponsorsで、企業がOSSのスポンサーをすることが可能になりました。 GitHub Sponsorsで、企業がオープンソースプロジェクトや開発者をスポンサーすることができるようになりました。これによって皆さんの企業で利用しているオープンソースプロジェクトを支援しましょう！#GitHubUniverse https://t.co/jQI3fdT5tc— GitHub Japan (@GitHubJapan) 2020年12月9日 この発表の後、日本でも多くの企業がOSSの寄付をしたという記事を目にしました。 時雨堂として GitHub Sponser

デジカル開発メンバーの末永(@asmsuechan)です。電子カルテの開発を通して医師や医療事務の方の「書く」をサポートしています。 みなさん、マークダウンでテキストを書いていますか？私はマークダウンで書くことが好きで、プレーンテキストでもほとんどのメモをマークダウン記法で書いてしまいます。この記事もはてなのマークダウンを使って書いています。*1 マークダウンを使えるサービスを挙げていくとGitHubやStackOverflowなど開発者ならば誰しも知るサービスが多く出てきます。このことからもわかるように、マークダウンはもはや開発者とは縁の切れないものとなっています。 しかし、普段の開発時によく使うマークダウンですが、実際にはどのような仕組みで動いているのかを知る人は少ないのではないかと思います。 この記事ではオリジナルのマークダウンパーサ「minute」をTypeScriptを使ってハン

「Deep Running」が産まれた日 もう元記事は消えてしまったのですが、なんか的はずれだなーと個人的に感じた「分身ロボットカフェ」を批判する記事がありました。記事の内容はどうでも良いのですが（すでに忘れました）。その記事にあった「ディープランニング」というパワーワードがみょうにツボに入ってしまいました。 指摘が的はずれなことに加えて "ＰＥＰＰＥＲ君のディープランニング技術" は笑う（笑） ランニングするんかいw https://t.co/quYVKUY01w— からあげ (@karaage0703) July 25, 2021 「Deep Running」の奇跡 我慢できず、勢いだけでGitHubに「deep running」というリポジトリをREADMEとライセンス(MIT)だけ作成してみました。 多分、イオンで買い物していたときだったので、iPhoneでリポジトリ作ったと思いま

はてなブックマークに導入されたYahoo! JAPANのAPI 治安の悪いはてなブックマークにYahoo! JAPANのAPIが導入されたようです。 これで、はてなブックマークの治安が良くなってくれたら嬉しいですね。また、これに関連して、THE GUILDの深津さんから以下のようなコメントががが。 「Yahoo!ニュースにおける建設的コメント順位付けモデルの導入」という論文を読んでる— 深津 貴之 / THE GUILD / note (@fladdict) July 19, 2021 ちょっと自分の理解だけだと自信ないので、 @karaage0703 先生に確認願いたいなり— 深津 貴之 / THE GUILD / note (@fladdict) July 19, 2021 自分も全く自信ないですが、面白そうなので読んでみることにしました。 なにせ、はてなさんはこのブログでお世話になっ

本エントリはiCARE Advent Calendar 2020の25日目です。 僕はiCARE社内で技術顧問としていろんなことをやっていますが、そのうちの一つとしてRailsアプリケーションのテスト改善があります。具体的には「たまに失敗するテスト」で難しいものがあったときに調査して解決をしています。この「たまに失敗するテスト」はiCAREに限らず、ほとんどの会社が苦しめられているのではないでしょうか。僕のお手伝いしている他の会社でも同様なので、複数社の社内ドキュメントツールに「こういうふうに調査するといいですよ」という文章を書いています。しかしこれらはどれも社内wikiどまりで、現時点で公開されている文章が存在していません。 そこで今回この場を借り「失敗したテストがあったときにどうしたらいいのか」の決定版を書いて、今後は「これ読んでおいてください」で済ませたいなと思っています。 前提 R

本章は、Rails初期化プロセスの内部について解説します。上級Rails開発者向けに推奨される、きわめて高度な内容を扱っています。 このガイドの内容: bin/rails serverの利用法 Rails初期化シーケンスのタイムライン 起動シーケンスで通常以外のファイルが必要な場所 Rails::Serverインターフェイスの定義方法と利用法

最近RackとSinatraのコードリーディングをしていて、RailsアプリのコードをRackアプリケーションとして読めるようになってきたので、$ bin/rails sをしたら内部では何が起こっているのかを追ってみた。 precondition Ruby: 2.6.5 Rails: 6.0.1 MacOS: 10.14.5 ここから本編 $ rails new で作ったばかりのRailsアプリケーションを、$ bin/rails s を実行した時の挙動を見ていく。 # bin/rails #!/usr/bin/env ruby begin load File.expand_path('../spring', __FILE__) rescue LoadError => e raise unless e.message.include?('spring') end APP_PATH = Fi

こんにちは、Quipper iOS エンジニアの @manicmaniac です。 現在スタディサプリ iOS アプリ開発チームのエンジニアリングマネージャをしています。 今回はスタディサプリで長らく使われていた React Native のコードを Swift に書き換えた話をします。 実は React Native から Swift への置き換え自体は半年ほど前に完了していたのですが、ブログに記すのに時間がかかってしまいました。 スタディサプリにおける React Native の利用 Quipper では 2017年ごろから React Native を iOS / Android アプリ開発に利用し始め、スタディサプリでは 2018年3月ごろから徐々に React Native を iOS アプリケーション開発に導入していました。 iOS 版スタディサプリの、git から取り出した