関西Ruby会議08での発表資料です https://regional.rubykaigi.org/kansai08/
テストの正常系、異常系、準正常系について ソフトウェアテストは正常系、異常系、そして準正常系のケースをカバーすることが重要です。これにより、アプリケーションが予想どおりに動作し、エラーや問題に対処できるかどうかを確認できます。 1. 正常系テスト 正常系テストは、アプリケーションが正常な状態で正しく動作するかどうかを確認します。ユーザーが期待通りの操作を行う場合の挙動をテストします。例えば、ユーザーがログインし、メールを送信するなどです。 2. 異常系テスト 異常系テストは、アプリケーションが異常な状況に遭遇したときにどのように振る舞うかを確認します。ユーザーが誤った情報を提供したり、システムエラーが発生した場合のテストです。これにより、エラーメッセージが正しく表示され、セキュリティの問題やデータ損失を防ぎます。 3. 準正常系テスト 準正常系テストは、正常系と異常系の中間に位置します。一
Userモデルにユーザーの平均年齢を計算してもらい、分析テーブルに現在時点のデータを保存するサービスを想定してみました。(実際には平均年齢以外に男女比とか平均課金額とか、そういうデータも一緒に集計すると思いますが、ここでは説明のため省略しています。) このサービスのテストコードを書けと言われて、ぱっと思い浮かびますか? 初心者でも思いつくのは、 Userテーブルのテストフィクスチャを用意して、実際に平均年齢を計算させる Analysisテーブルに保存されたレコードを検索して、実際のレコードの値をアサートする こんな方法でしょう。でも、ちょっと待ってください。Railsのテストでも操作しやすいリレーショナルデータベースに値を保存しているから「簡単じゃん」と思うかもしれませんが、、、 例えば保存する先がリレーショナルデータベースでなくredisなら...? 例えば保存するのではなくチャットサー
WEB+DB PRESS vol.49で、「現場で役立つDRYの基礎知識」が特集されています。とても、良い記事だと思うので、ぜひみなさん、読んでください。 ただ、ちょっと補足をしておきます。 記事の中で、DRYは、「達人プログラマー」の中で、とりあげられ、Railsによって広まったとされています。確かに、Rubyの世界ではそうかもしれないけど、DRY原則というのは、ERモデリング(DOA)の世界では、ずっと「One Fact In One Place」という言葉で知られてきました。 ERモデリングにおける正規化は、「One Fact In One Place」を具体的に実現するための手段です。 DRYという言葉そのものを広めたのは、間違いなくRailsです。しかし、DRYの考え方そのものは、昔からあったし、「One Fact In One Place」という言葉も、昔から有名だったというこ
This document discusses using Rails as a backend for front (BFF) layer in a microservices architecture. It describes how Rails was used to build the BFF layer for an e-commerce site called HPB, acting as an API gateway between the client and various backend services. Key points discussed include using Puma to improve throughput, caching APIs to reduce response time, and implementing an API gateway
技術開発本部の qsona です。 先日、 ぎんざRuby会議01 というミートアップが開かれました。これは、弊社の技術顧問のwillnetさんを含む3人の方によって運営されている Ginza.rb というコミュニティの50回目を記念して開かれたものです。 このミートアップにCFPを投稿し、採択いただきました。かなりの高倍率の中、目にとどめていただけたこと、また普段お世話になっているコミュニティの節目の会での発表の機会を頂けるということで、非常に有り難いことでした。 発表資料以下がその発表資料です。また、引用した文献をこの下に列挙したので、適宜ご参照ください。 引用文献p3 マイクロサービス時代に捧ぐ、Railsでの中規模APIサーバ開発のための技術構成 — qsona (Qiita) p27 step-by-step BFF — Yosuke Furukawa (Speaker Deck
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 経緯 casyというインターネットを使って手軽に家事代行を頼むことができるサービスのプログラマをしています。 Webだけでなく、スマホアプリも出すことにあたり、Webアプリサーバ(Rails)から機能を切り出し、APIサーバ(Rails)を別途作成し、Webアプリの場合はWebアプリサーバからAPIサーバを呼び出し、アプリからは直接APIサーバを呼び出すような仕組みにしました。 ただ、全部の機能をAPIサーバに移すのは容易なことではなかったため、いくつかの機能はまだWebアプリサーバに残っていて、アプリよりもWebのほうが機能が多い状態
2016 - 05 - 06 Rails アプリケーションにおけるリファクタリングの実践 Ruby on Rails こんにちは、MERY のサーバサイド開発をしている末並 @a_suenami です。 TDD、 アジャイル 、DB 界隈等によく出没しますが、最近では糖質警察としてのほうが広く知られている気がする今日この頃です。糖質制限に興味ある方はぜひウィスキーを片手にケトン体の話でもしながら飲みましょう。 さて、現在、MERY は Ruby on Rails で開発されていますが、最初にリリースされたのはもう 3 年近く前であり、その頃とはサービスを取り巻く状況が大きく変わってきています。これまで多くのユーザの「かわいい」を支え、よい体験を提供し続けてきた現在の MERY とそのコードベースを否定することは決してできませんが、日々変わるユーザの「かわいい」ニーズと我々のビジネス状況の変
図7 Mix-inによるStreamクラスの構築例<BR>クラス階層はツリー構造を保ちつつ，コードのコピーも避けている。 継承には2つの意味がある Javaのような静的型のオブジェクト指向言語の変数には，変数を介して呼び出されるメソッドを制限する働きがありました。ただし，制限がかかるのは「どのようなメソッドを持っているか」であって，「どのように実装されているか」ではありません。 今まで一まとめにして継承と呼んできましたが，実は継承には2つの異なる概念が含まれています。一つは，「どのようなメソッドを持っているか」あるいは「どのように振る舞うか」ということに着目した「仕様の継承」です。 もう一つは「どのようなデータ構造を使い，どのようなアルゴリズムで処理するか」ということに着目した「実装の継承」です。 静的型言語では両者の区別が重要になります＊4。Javaでもこの2つを明確に区別しており，実装
あけましておめでとうございます。 大晦日は実家でプログレ聞きながらコード書いてました。 今さらながら Heldon の Stand by とか聞いてたんですが、Tangerine Dream を思わせるミニマルなシンセサイザーの反復と、リシャール・ピナスによるロバート・フリップばりの暴力的なギターソロが絡みあっており、大変良いですね。 作ったもの また説明長くなりそうなので、はじめに作ったものの紹介です。 dee dee-rails この Dee というのが DI コンテナの本体です。 名前は Ozzy Osbourne ソロ 1st Blizzard of Ozz におけるランディ・ローズのギター曲からです。 50 秒と短く、メタルアルバムの中にあってクラシック風の静かなギター曲ですが、同時にアルバムから欠かせない存在感を放つ名曲です。 何が言いたいかというと、Dee はコンパクトな実装
今日は、railsで開発する場合は必ず使用している gem rails-erd を紹介したいと思います。 rails-erd の使い方を説明するまえに、軽くerd の説明をば。 ERD とは データの構造や関係を記述するための構造モデル E-Rモデル を記述するための表記記法で、 こんな感じのやつです。 詳しくはこちらを御覧ください。 rails-erd を使う前に rails-erdを使う前に必要なソフト graphviz をインストールします。 homebrewを使っている場合は brew install graphviz でOKです rails-erdの使い方 使い方はいたって簡単です。 Gemfileに gem “rails-erd” 本番では必要ないのでこちらでも全然問題ありません。 group :development do gem “rails-erd” end と追記して、
私は開発する際に、cakephpなどのフレームワークを必ずと言っていいほど使用しています。便利だし、クラスなどの役割が明確になるので、誰が触っても似たような感じになります。 フレームワークを使わない場合でも、いつもいつもMVCで開発するべきだと、会社の後輩にも口を酸っぱくしていっているが・・・私の考えているMVCは実はMVC2と呼ばれているものでした。 私の無知さを教えてくたのが、以下の記事である。 PHPerのMVCの一体どこが間違っていたのか - MugeSoの日記 この記事を読んだ時に、理解が出来ませんでした。 何故ModelからViewを参照しているか？CakephpにModelを監視するクラスやメソッドが無いし、そもそもModelクラス自体呼び出す事が出来ません。（例外はあるけど、標準ではない） 全然納得が出来ませんでした。 でも、このままでは間違った認識で、後輩たちに情報を発信
zusaar.com - zusaar リソースおよび情報 参加してきました。 以下、粒度にばらつきありますが、気になった点のメモです。ほぼ引用ですが、意図と違う表現になってしまっていたらすみません。 RESTful APIとしてのRailsとクライアントとしてのJavaScript (@ppworks) no title RESTfulの指向で考えると統一されたインターフェースで、URLを見ただけで何するかわかるのが良い JSはassetsのほうに統一しアクションごとに処理が書けるjQuery-Routerなどを使うと良いのでは RailsはだんだんAPI化していくのではないか 通常のHTTPリクエストと非同期HTTPリクエストを同じ統一インターフェースであるRESTfulな設計で管理すると一貫性が出て開発効率の向上につながる リソースモデリングパターンの提案 (@tkawa)
Ruby on Railsをはじめとする最近のWebアプリケーション・フレームワークの多くは，MVCと呼ばれるデザイン・パターンを採用しています。今回は，このMVCパターンの「正体」について考えます。 MVCはGUIを備えたプログラムを設計する際の指針となるデザイン・パターン＊1の一つです。「モデル」（Model），「ビュー」（View），「コントローラ」（Controller）という3つの構成要素の頭文字から命名されました。多くのデザイン・パターンはプログラムの一部のみの構成を決めています。しかし，MVCはアプリケーション全体の構成を決めることが多いため，「アーキテクチャ・パターン」と呼ばれることもあります。 MVCは，元々プログラミング言語Smalltalkにおいて，ウインドウ（GUI）を持つアプリケーションを構築する際の指針として誕生しました。 MVCを発明したのは，当時，米Xero
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
