ActiveRecord の insert_all で発行されるSQLに ON DUPLICATE KEY UPDATE がある理由
タイトルに書きたいことが長いとタイトル付けに困りますね。 今日は、「Ruby on Rails の ActiveRecord の insert_all で MySQL向けに発行されるSQLに ON DUPLICATE KEY UPDATE foo = foo が含まれている理由」について、知っておこう。（調べました） TL;DR Ruby on Rails の insert_all で発行されるSQLには ON DUPLICATE KEY UPDATE foo = foo が末尾に指定されている foo はどうやら INSERT INTO で登録先として指定している列の1番目 upsert_all に ON DUPLICATE KEY UPDATE が指定されているならまだしも、insert_all にこの指定があるのは感覚的に気持ち悪い 該当の実装部分はここ https://github
Next.js App Routerの"use server"雑感 : Rails視点から
はじめに Next.jsにServer Actionが新しく導入されました。サーバ上の関数をブラウザから直接呼び出すようなコードの書き味を提供するもので、非常に魅力のあるコンセプトだと私は思っています。ただしサーバ上で実行されるコードとブラウザで実行されるコードの境界が曖昧で、"use server"のセキュリティ上の懸念もよく議論されています。 一方で、私の先日の記事Next.jsで簡単なCRUDアプリを作りながら気になったセキュリティ: Railsの視点からで、私はこの"use server"問題には言及しませんでした。まだ非常に新しい話題でかつNext.js側の対応も進行中だというのもありますが、実は個人的にあまり気にならないのが最大の理由です。 気にならなくなったきっかけは、Server ActionをRuby on Railsのコントローラと同じように考え始めたことです。こうする
rails mysql5.7から8.0アップグレード時の注意点📝
railsが参照しているrdsをmysql5.7から8.0にアップグレードした時の注意点メモ utf8mb4を指定した場合は以下のパラメーターグループをutf8mb4にする必要がある character_set_database データベースの文字セットを定義します。文字セットは、文字を数値で表現する方法を定義するデータエンコーディングの一種です。 この設定は、新しく作成されるテーブルとそのカラムに使用されるデフォルトの文字セットを指定します。特定のテーブルやカラムに対して異なる文字セットを設定することも可能ですが、character_set_databaseはデフォルトの設定で、特定でない指定がない場合はこれが適用されます。 character_set_client ユーザーからのSQLステートメントがエンコードされている方法を定義します。クライアントからデータベースサーバーに送信される
OpenAPI x Rails x Next.js でIVRyを０から作り直した話
こんにちは、電話自動応答サービスIVRyでエンジニアをしている小瀬です！ 実は先月、ユーザーさんには伝わらない形で大幅な「作り直し」を行っておりました。 余談ですが、このブログを書いている時にちょうどこのツイートがバズっているのを見かけました。 過去のコードを作り直したいけど、作り直せない、みたいなことってあるあるなんだなと改めて思いました笑 今回僕らは勇気を出して作り直す決断をして、過去のコードはレポジトリ単位で捨てて、新規でAPIを100本弱、2-3ヶ月ほどかけて粛々と実装しました。 完全な作り替えだったので、リスクの高めのリリースでしたが、無事に障害なく乗り越えることができました。 今回は、作り直しの動機や、失敗しないために気をつけたことなどをブログにまとめていきたいと思います。 さらなる飛躍のために、一時停止 IVRyは、初めからリッチな構成で作ったわけではなく、どちらかと言うとプ
Blitz.jsをRuby on Railsエンジニアが触ってみた感想
感想です。 何をしたか 現状でBlitz.jsで本番サービスを運用できるかの調査。 Railsで運用している本番サービスの一部機能を、3日間ほどかけて移行を試してみた。 結論 (Railsの主戦場でもある)新規事業開発の文脈でのクイックな立ち上げを想定するなら、本番運用するにはまだ厳しい。 特に、RailsユーザーとしてはActiveRecordがないのが厳しい。 開発効率そのものはRailsと比べて多少落としても、Railsよりもスケーラブルで型安全に開発したいなら、割と良い選択肢に思う。 もろもろ可能性は感じるので、引き続き応援していきたい。 良かった点（＝Blitz.jsに興味を持っている理由） 型安全な開発 サーバーもフロントも全てが型に守られた開発、そしてIDEの恩恵を受けられるのは、いうまでもなく心地がいい。 型は補助輪のようなものなので、ユーザースキルが高ければ必須ではないく
Re: Rails を主戦場としている自分が今後学ぶべき技術について
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
