「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 http…
リーダブルテストコード / #vstat
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 http…
CoC が苦手な奴、認知資源が乏しいだけ説 - Neo's World
CoC が苦手な奴、認知資源が乏しいだけ説 「設定より規約」「CoC (Convention over Configuration)」と呼ばれる設計思想がある。 参考：設定より規約 - Wikipedia フレームワークやライブラリ側で、ベストプラクティスなデフォルト設定を規約として決めておくから、利用する開発者はイチイチ考えなくていいよ、というワケだ。 コレは、ともすれば、「Opinionated (自己主張的)」なフレームワークやライブラリだとみなすこともできるだろう。 参考：Opinionatedなライブラリとチーム開発 - Runner in the High 僕は CoC が割と好きだし、CoC か否かに関わらず、Opinionated なツールも好きである。だが、自分の回りでは「CoC が苦手」とか「柔軟性のないフレームワークは嫌い」といった人が多く、疑問を持っていた。 今回、
APIの命名規則はフロントエンド・バックエンドどちらに合わせるべきか？｜TechRacho by BPS株式会社
morimorihogeです。ちょっと色々忙しくて死んでますが、深夜の勢いで書いてみます。 ことの起こり Twitterにてこんな発言を見かけました この2017年の記事だと、RoRのテーブルのdatetime型にはatをdate型にはonを付けようと書いてあるけど、APIでカラムのデータを返す場合、フロント側としてはdateというサフィックスが付いていた方がやりやすいという意見があって、この辺のベストな感じが気になったhttps://t.co/8MMMHlFvGx — yotuba@Railsエンジニア (@yotuba_eng) July 1, 2021 元記事（翻訳）はこちら Rails: 日付や時刻のカラム名を命名規則に合わせよう（翻訳） 本件について、Twitterではreplyしてみたのですが、文字数の都合で詳細に書きづらいということもあり、一度自分の意見をまとめてみようという
100万行オーバーのモノリシックRailsアプリをマイクロサービス化したクックパッドの手順 - エンジニアHub｜Webエンジニアのキャリアを考える！
100万行オーバーのモノリシックRailsアプリをマイクロサービス化したクックパッドの手順 マイクロサービスの導入事例を、中の人が徹底的に語ります。クックパッドでは、100万行オーバーの超巨大なRuby on Railsアプリのマイクロサービス化に挑みました。アプリをいかに分離し、連携できるようにするか、など、同社が採ったマイクロサービス化の戦略を聞きました。 Ruby on Railsのバージョンアップに1年かかっていた 【マイクロサービス化戦略】まずはコードを減らすことから 【マイクロサービス化戦略】アプリ固有のバッドノウハウを減らす 【マイクロサービス化戦略】まずは分離しやすい部分からお試しで 【マイクロサービス化戦略】データベースが切れていればサービスも切りやすい 【マイクロサービス化戦略】インフラ構成を標準化する 【マイクロサービス化戦略】サービスメッシュを入れて通信の課題をクリ
普通のチームで立ち向かう - Railsアプリでのテストコードポリシー - - LiBz Tech Blog
皆さん自分たちのプロダクトにテストコードは書いているでしょうか？ LiBzCAREERではRspecやCIなどテストコードを書くための仕組みは割と初期から用意していました。 ただし、テストコードを書くべきかの基準が明確になっておらず、テストコードが書かれているかは実装者に任されていました。 それではテストコードの書く書かないの判断が、実装者のテストコードに対するスキルや志向によってバラけてしまうため、今回の開発チーム再編のタイミングでチーム全員でテストコードを書くという意思決定をし、テストコードポリシーを定めました。 チームやプロダクトの状況 自分が所属する開発チームの体制はこちら エンジニア5人 Ruby on Railsを採用 チームにこれまでもテストコードを書いてきたエンジニアは1名だけ 既存のプロダクトコードにもテストがない箇所が多々ある SPAやJSフレームワークの導入など、フロ
イミュータブルデータモデルへの取り組み with Ruby on Rails - リサーチ・アンド・イノベーション 開発者ブログ
こんにちは。リサーチ・アンド・イノベーションの中村(konk303)と申します。 いわゆる「railsおじさん」的な立場で、主にサーバーサイドの開発をしています。 Introduction 本稿ではQiitaのイミュータブルデータモデルと webアプリケーションにおける現実解にインスパイアされて、弊社でのイミュータブルデータへの取り組み(とその苦しみ)を紹介したいと思います。 qiita.com イミュータブルデータモデルとは? まるっと引用。 イミュータブルデータモデルと webアプリケーションにおける現実解 - Qiita 詳細はリンクに譲りますが、「履歴を全て残すようなデータ設計にし、 UPDATE を廃することで情報の追跡可能性を確保、堅牢な設計にする」モデリング手法です。 原則この手法に従うと、そうそう汚いモデルにはならないという優れもの(雑) です。イベントが起こる度に新規レコ
Railsのファットモデル問題に対処する前に読んでほしい記事 - Qiita
背景 Skinny Controller, Fat Model Railsではスキニーコントローラー、ファットモデル（Skinny Controller, Fat Model）という方針のもと、 コントローラーのコード量を少なくして、モデルを分厚くするという書き方が推奨されていました。 10 Ruby on Rails Best Practices — SitePoint Rails Best Practices 1: Fat Model – Skinny Controller このような背景から、ファットモデルという設計が目指すべき設計という認識となりました。 「ファットモデル問題」の登場 ところが、原因はわかりませんが、次第にファットモデルが問題があるものとしてみられるようになりました。 界隈では「ファットモデル問題」として取り上げて解決するという方法が紹介されるようになります。 20
Rails + AWS でモバイルフレンドリーな動画配信サイト構築 - メドピア開発者ブログ
あけましておめでとうございます。 メドピアのSRE @kenzo0107 です。 2018年もよろしくお願いします。 今回は昨年リニューアルした動画配信システムについてです。 経緯 これまでのメドピアの動画配信は CloudFront 経由で S3 上の mp4 を video タグで参照し配信してました。 この配信方法では CloudFront でキャッシュしづらく 通信状況によってはファーストビューまでに時間が掛かり、サイト離脱へ繋がります。 また、直リンク禁止の動画の場合、 リファラチェック等をするかと思いますが 一部 IE Edge のバージョンで video タグでリファラ参照ができないという仕様があり*1 既存の仕組みをフロントから変える必要がありました。 以上の経緯から動画配信の仕組みを見直し要件を洗い出しました。 要件 動画は mp4 で納品される為、HLS形式へエンコード
複数の rails プロジェクトが共存する開発環境を Docker 化した話を晒してみる
アプリケーションエンジニアの西辻です。 今回のブログでは、弊社のローカル開発環境を Docker 化した話をご紹介したいと思います。 このブログでは、なぜローカル開発環境を Docker 化する考えに至ったのかに始まり、 具体的にどのような方法で Docker 化を進めていったかを振り返りながら書いていきます。 また、Docker 化したことで受けた恩恵などを最後に書いて終わります。 Overview 大きく以下の項目について書いていこうと思います。 自分の仮想化環境への考え方について 今の現場に Docker 開発環境を導入する判断について 実運用している構成例を用いての説明 Docker for Mac のファイルI/Oのパフォーマンス改善方法 Tips: Docker コンテナに対して binding.pry を利用する ローカル開発環境を Docker 化した恩恵 自分の仮想化環境
SchemaRD - RailsのER図を生成 MOONGIFT
Ruby on Railsではデータベースのスキーマをコードを使って自在に作成できます。テーブル同士の関連性もコードで記述できるので、殆どデータベースを意識せずに作り込んでいけます。しかし、時にER図が必要になるケースもあるでしょう。 そうした時に使ってみたいのがSchemaRDです。Ruby on Railsのスキーマファイルを読み込んでER図に展開してくれます。 SchemaRDの使い方 最初の表示です。テーブルはただ並んでいるだけです。 テーブルの配置はマウスで変更できます。さらにちゃんと記憶しておいてくれます。 リレーションのファイルを生成すればテーブル同士のつながりも可視化されます。 SchemaRDを使えば現在のテーブル構造を可視化できるようになります。さらにi18nにも対応しており、日本語で表示も可能です。システム開発をRuby on Railsで行っており、そのER図を随時
Rails アプリでオンラインでカラムの削除やリネームを行うには - eagletmt's blog
前提知識 Rails アプリにおいて、テーブルの追加やカラムの追加は簡単なものの、カラムの削除やリネームは慎重に行う必要がある。たとえアプリからそのカラムを参照してないとしても、いきなりカラムを削除するとエラーになる可能性が大いにある。 というのも Rails にはスキーマキャッシュというものがあり、テーブルのカラム情報をモデルがキャッシュしているからだ。このキャッシュはたとえばいわゆる N+1 クエリ問題を避けるために includes (eager_load) するときに参照される。 SELECT 句で t0_r0 のような機械的に別名が振られるようなクエリを見たことがある Rails エンジニアは多いと思う。 機械的に全カラムを取得するためにスキーマキャッシュを利用しているため、このようなクエリが実行されてる中でカラムを削除したりリネームしたりすると、スキーマキャッシュをもとに並べら
Swagger+JSON SchemaでAPIの型をテストして開発サイクルをスピードアップさせた話 - pixiv inside
CTO兼福岡オフィス立ち上げ担当として新アプリを作っている@edvakfです。 JSON APIを開発しているとこういう問題がありがちですよね。 仕様どおりにAPIの形式を作ったはずだけどなんか自信が持てない テストでいくつかのキーが存在するかの簡単なチェックはしてるつもりだけど、全部チェックするのは大変すぎる APIのControllerやViewをリファクタリングしたらレスポンスの形が変わってアプリがめっちゃクラッシュし始めた というのが怖くて誰もリファクタリングできなくなった APIドキュメントがメンテされない 知らない間にレスポンスのフィールドが増えてたけどドキュメントに書いてない これらを解決したい！と思って試行錯誤したら、スマートに解決することができました。この記事ではRailsのことについて書きますが、考え方は他の言語・フレームワークでも同じです。 なお、今回使ったgemのバ
RailsとAmazon Aurora利用時のフェイルオーバー問題を解決 - matsukaz's blog
tl;dr RailsのコネクションプールとAmazon Auroraのフェイルオーバーの仕組みは相性が悪く、フェイルオーバー時に致命的な問題が発生する 解決方法の1つは、コネクションプールを使わないこと ただし、都度接続だと接続コストがかかる New Relicなどを使ってる場合は、自分の実装以外で使ってるコネクションまで都度接続になってしまう 別スレッドでDB操作を行っている場合、処理中であってもそのスレッドのコネクションまで切断されてしまう（Railsのコネクション破棄がプロセス単位のため） コネクションプールを活かしたままこの問題を解決できたので、その方法をご紹介します。ちなみにRails 4.2の話。 RailsとAmazon Aurora利用時のフェイルオーバー問題とは 詳しくはこちら qiita.com 問題が発生する状況をまとめると以下の通りです。 Amazon Auror
RailsアプリをECSで運用するまでにやったこと、これからしていくこと - スパイスな人生
おはようございます。一番よく使うemojiは 👀 (:eyes:) のうなすけです。 さて弊社では、最近社内Railsアプリをひとつ構築しました。それをECSで運用することにしたので、そこに至るまでの経緯、つまづき、これからの課題などなどを記事にしていこうと思います。上の図は現時点での簡単なAWS上での構成図です。 以下、見出しは時系列順でやったことを記録していきます。 社内Railsアプリ、一体どんなもの？ ここで新規に構築することになった社内Railsアプリですが、特に凝ったことはしていない単純なRailsアプリです。初めからECSで運用することにしていたので、開発環境も全てDockerで構築しています。Railsのバージョンは5.1.0、Docker imageのFROMにはruby:2.4.1-silmを採用しています。 Docker imageのtagについて developm
１台あたり10,000人を捌くRails製Webサーバのチューニング - dely Tech Blog
SREの深尾です。kurashiru [クラシル] のインフラを担当しています。 タイトルのとおり、クラシルのwebサイトではRailsを使っており、１サーバあたり10,000人程度のアクセスに耐えることができます。実際には余裕を持たせて5,000人/サーバを目安にスケールさせており、TV CMをガンガンやったり、国内外のTV番組で特集されたり、芸能人にSNSで拡散されても動じませんが、実は過去に１度だけWebサイトがダウンしてしまったことがあります。それは2017年3月11日にSmaSTATION!!というTV番組でクラシルが取り上げられた時のことでした。 以下はその時のリクエスト数を表すグラフです。ダウンしてしまったので計測できなかったユーザの数字は含まれませんがそれでもアクセス数は１分で数万人を超えていました。 それまで、Webサイトの負荷対策はあまり行っておらず、２台のWebサーバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアが作りたいものを本気で作るための起業という選択肢。レビュー支援サービスSiderの着想から現在、未来 | Rails developers meetup Day 3 Extream
ActiveRecordデータ処理アンチパターン / active-record-anti-patterns
コードレビュー自動化の最前線から
普通のRailsアプリをdockerで本番運用する知見
Railsアプリケーションのパフォーマンス改善手法 / #ginzarb
