Railsバリデーションエラーメッセージの日本語化(ja.yml設定方法) - 独学プログラマ
今回達成すること バリデーションのエラーメッセージを日本語に対応するための設定を行います。 具体的には、「I18n（アイエイティーンエヌ）」モジュールが読み込むja.ymlファイルを編集します。 I18nとはRailsアプリを多言語化対応するためのモジュールで、同一コードでもユーザーに表示する言語を切り替ることができます。 ja.ymlファイルを作成する この回でapplication.rbに下記コードを追加しました。 config.i18n.default_locale = :ja この設定をするとI18nは下記のファイルを読み込みます。 /config/locales/ja.yml 最初にI18n読み込みファイルja.ymlを作成します。 root $ touch api/config/locales/ja.yml 確認しておきましょう。 root $ ls -1 api/config
MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために - ichirin2501's diary
この記事ははてなデベロッパーアドベントカレンダー2015の12月24日の記事です。 昨日は id:stefafafan さんのエンジニアと英語でした。 こんにちは、こんばんは。 クリスマス・イヴですね、皆さんはどのような一日を過ごされる(た)のでしょうか。 僕は一人です。 改めまして、先日初めての合コンを経験/失敗して二度と行かないと誓った はてなの id:ichirin2501 です。今回は小ネタとしてMySQL(InnoDB)のBULK INSERTにおけるデッドロックの話をしようと思います。ただ、外部キー制約が絡むと複雑になるので今回は触れません。それについてはこちらを参照ください。 あ、タイトルはオマージュです*1。 Topic 検証環境 INSERTのデッドロック 避けられないケース もしくはロックする リトライ処理に注意 初期データ Duplicateの場合 Deadlockの
rails のconcernを使ってエラーレスポンスを返す忘備録 - Qiita
concernとは app/concernsというディレクトリが存在する。concernsは ・複数のコントローラー（モデル）から利用される処理を共通化する目的 ・ある特定のまとまった処理を切り出して見通しをよくする目的 上記の目的で使われることが多い。 Concernの書き方 まずはconcernのファイルを記入し、その後コントローラーにてincludeで表記する。 module MyConcern extend ActiveSupport::Concern # Scope や Callbackなどの処理を実装する included do scope :without_deleted, lambda{ where(deleted_at: nil) } end module ClassMethods def foo puts 'foo' end end def bar puts 'bar'
Railsアプリの例外ハンドリングとエラーページの表示についてまとめてみた - Qiita
Railsアプリケーションの例外ハンドリングとエラーページの表示方法については色々な方法があると思いますが、そのなかでもよく使われる方法についてまとめてみました。 前提 Rails 4.2.6 Rails 標準の仕組みで静的ページを表示する Rails は標準では Rack Middleware のActionDispatch::ShowExceptionsの仕組みで例外を捕捉して、エラーページを表示しています。その際、捕捉した例外に対してどんなエラーページを表示するのかをActionDispatch::PublicExceptionsが処理しています。 例えばActionController::RoutingErrorが発生した場合、対応する404のHTMLファイルpublic/404.htmlが表示される、という感じです。 なお、rails generateしたときに用意されるHTML
Rails によるカスタム例外の設定とエラーハンドリング - Qiita
Rails で例外を発生させたい際は，raise...つまり RuntimeError をよく使用するかと思います。 しかし，サービス上の制約から，特定の状況下で例外を発生させる場合，raiseだけでは物足りなくなる時があります。 raiseでは「何かまずいことが起きてしまいました！」程度のことしか伝えてくれません。まぁ，引数に渡す message を見れば理解できるかもですが... 兎にも角にも，特定の状況下に対する例外が存在するなら，その例外に対して名前を付けてあげましょう。 カスタム例外を設定すると，発生時に「何に対する例外か」がパッと理解できるようになりますし，特定の動作に誘導することも容易になりますので，良いことづくめです！ 参考 URL 等 項目22 | Effective Ruby（長尾高弘 arton PeterJ.Jones）｜翔泳社の本 Railsアプリケーションにおけ
RailsのAPIサーバーのエラーレスポンスで例外に対応するエラーコードを返却する - Timee Product Team Blog
はじめましてこんにちは。 夏が本気を出してきて最近麺類しか口にしていないサーバサイドエンジニアのかしまです。 この度APIにてHTTP Status Codeとは別に、例外に対応するエラーコードを返すよう奮闘したのでその知見を共有したいと思います。 やりたいこと APIにて例外が発生した場合、以下の形式でレスポンスを返すようにします。 { "errors": [ { "code": "code1", "message": "message1", }, { "code": "code2", "message": "message2", }, ] } Why？ 今回追加したAPIは外部のアプリケーションとの連携に使うため、以下の要件を満たす必要がありました。 クライアントサイドがハンドリングしやすいような設計にする エラーの識別子は不変であること そのためエラーメッセージとは別に、コードを返す
REST APIがエラー発生時に返すべきJSONの形（＋Railsでの実装方法） - Qiita
はじめに RailsのAPIでエラー処理ってどうすればいいんだろう？ どんなJSONを返せばいいんだろう？ 筆者が関わっている企業でよくこのように悩んでる人を見かけるので、自分の経験を基に記事にまとめてみました。 返すべきJSONの形 ぶっちゃけ、企業によってまちまちですし、「これが絶対正解だ！」と言えるものはありません。 いろんな企業のAPIがどのような形のレスポンスを返しているか知りたければ、WebAPIでエラーをどう表現すべき？15のサービスを調査してみたという記事が非常に参考になります。 ただ、上記の記事にも書いてありますが、2016年に出たRFC7807が、「こういう形でいいんじゃね！？」っていう標準となるようなJSONの形を提案してくれています。 RFC7807が提案する形 詳しくはRFCの方を参照していただければと思いますが、具体例を書くとこんな感じです。 { "type":
railsで404や500といったエラーを捕捉（エラーハンドリング）するには？ - Qiita
class ApplicationController < ActionController::Base # Prevent CSRF attacks by raising an exception. # For APIs, you may want to use :null_session instead. protect_from_forgery with: :exception # 他のエラーハンドリングでキャッチできなかった場合に # 500 Internal Server Error(システムエラー)を発生させる # NOTE: rescue_from は下から評価されるので記載箇所はここが正解 rescue_from Exception, with: :handle_500 unless Rails.env.development? # 例外に合わせたエラーハンドリング # 4
RailsでAPIを作るときのエラー処理について | Yucchiy's Note
RailsでAPIを雑に書いていたんだけど, コントローラとかをどう書くとエラー処理しやすくなっていいかなーと考えていて, 個人的に考えがまとまったのでブログ書いた. ※9/1に追記書いた. 良いエラー処理について 個人的にAPIを書く上で(API書くに限らない気はするけど)どういうふうにエラー処理を行うと良いかなーと考えてみると コントローラ内では基本的に, ある関数の処理が失敗して, 次の処理が行えない場合はすべて例外を投げる 例外は各々のコントローラ内で例外のキャッチは行わず, すべてApplicationControllerなど, 親コントローラ内の1メソッドで完結させる かなーと思う. APIのエラー処理は, Envelopeにステータスコードとエラーメッセージを書いて, APIのフォーマットを統一するほうがクライアントが作りやすそうだし, またこのように処理することで, エラー
Laravelエラーと対処法16選
さてさて、Laravelでなくともプログラムを使って何かを作っているときにとても重要となるのが表示される「エラー」です。 エラーはどこがどのように間違っていてうまくコードが実行できないかを教えてくれるからです。 ただ、これもいろんなプログラミング言語でも「あるある」なのかもしれませんが、そのエラーを見てもどこが間違っているのかがわかりにくかったり、そも場所が違っているという場合があったりするのも事実。 そこで、今回はLaravelで「こんなエラーが出た時は、こう対処する」という実例をまとめてみることにしました。 ぜひ参考にしてみてくださいね。（環境はLaravel 5.6 & PHP 7.2です） 【追記：2020.11.17】16番目の項目を追加しました。環境はLaravel 8.xです。 Sorry, the page you are looking for could not be
Railsアプリケーションにおけるエラー処理（例外処理）の考え方 - Qiita
はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エラーメッセージの英訳 CapmNetwork