Rails: 本当にやった「責務過剰クラス」の事例（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: When objects become super objects - Write it simple 原文公開日: 2020/08/11 著者: Juan Manuel Ramallo サイト: Write it simple - Simple programming short articles. Mostly ruby focused. 日本語タイトルは内容に即したものにしました。 鉛筆は、何かものを書くのに使います。それ以上のものではありません（お尻に消しゴムが付いている鉛筆もありますが、この際考えないことにしましょう）。 今は何でもデジタルに移行する時代ですよね。鉛筆本体に簡単なOCRスキャナを取り付けて、書いたものが片っ端からデジタル化できたらさぞ便利でしょう。 私は会議で意見を交換中、手元で書いたちょっとした技術用の
赤いラクダは3倍早い！ピーク時毎分1400件を捌くための決済処理のチューニング紹介 - pixiv inside
こんにちは、4月からBOOTH部になったorekyuuです。 この記事では、転属後の一番大きな成果である、BOOTHで発生する大量の注文(ピーク毎分約1400件)を整合性を取りつつ高速にさばく改善について解説します。 BOOTHが抱えていた課題 まずはBOOTHが抱えていた課題について説明します。 BOOTHでは販売開始時刻が事前に予告されていた場合などの理由で瞬間的に決済が集中し、サーバーが大量の注文に耐えきれないケースが度々ありました。 その原因は在庫の処理にありました。擬似コードですが、注文の処理は以下のようになっていました。 def checkout! ActiveRecord::Base.transaction do 商品の悲観的ロック # 在庫数を同時に編集しないようにロックを取る 商品の在庫の減算処理 注文を確定済みにする 決済の請求APIを叩く end end 上記のコード
GraphQL について思うこと - Diary
GraphQL について思うこと GraphQL まとめ食いできるのが利点だから一回のリクエストごとに数百個のエンティティとってくることを想定しなければならず、そうなってくると ActiveRecord 構築の遅さが本格的に問題になるので GraphQL を Rails でやるのは厳しいというのがやってみた感想 — 黒人 (@ssig33) September 12, 2017 という問題がまずある。ヘビーな API コールは想定せずに、 API の型情報を規定して各レイヤーに共有する仕組みとして使うならいいんだろうけど、しかしそれオーバースペックじゃねーかな。 クライアント上で N+1 を起すかサーバー上で N+1 を起すかみたいな問題になってくるんで、今はなんかクライアントとネットワークのコストがアレだねーみたいな状態なんでサーバーはカリッカリに書かないとあかんね、そうしないなら RE
RailsでActiveRecordの代わりにMongoidを使う - Qiita
はじめに Ruby on Rails(以下Rails)でMongoDBを使う際のORマッパーとして現在はMongoidが標準的に使用されるようになりました。MongoidはActive Recordに似たAPIを備え、かつMongoDBのスキーマレス、ドキュメント指向、ダイナミッククエリ、アトミック操作といった特徴をRubyから容易に扱えるように設計されています。 本記事ではMongoid 4.0.0、Rails 4.1.8をベースに、RailsでMongoidを使う利点を述べ、実際にサンプルアプリケーションを動かして紹介したいと思います。 Mongoidを使う利点 これまでのプロジェクトではActive Recordを介して主にMySQLを使用していましたが、Mongoidを使用するようになって、以下の利点を実感しています。 Active Recordと共通もしくは拡張したクエリと永続化
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
