並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 83件

新着順 人気順

logrageの検索結果1 - 40 件 / 83件

  • 『Sustainable Web Development with Ruby on Rails』はRails使ってるなら絶対面白いと思う

    『Sustainable Web Development with Ruby on Rails』はRails使ってるなら絶対面白いと思う David Bryant Copelandの『Sustainable Web Development with Ruby on Rails』を読んでいますが、この本めちゃめちゃ面白いですね。 Railsの設計で悩んだことのある人なら絶対読んで損はないというか、共感したり反発したりにやにやしたりで楽しめると思います。RailsというかWebアプリ開発の歴戦の勇士(正直あまり若くなく、つらい経験を重ねてきた生き残り的な人)が語るベストプラクティス感があります。 本書の構成 大きく3部構成です。 Introduction その名の通り導入です。本書の目的、Railsのアーキテクチャの紹介と、ビジネスロジックの話など。 「Sustainable」とは何か? とい

      『Sustainable Web Development with Ruby on Rails』はRails使ってるなら絶対面白いと思う
    • Awesome Ruby : 素晴しい Ruby のライブラリ・ツール・フレームワーク・ソフトウェアの数々

      元記事: Awesome Ruby Ruby 以外の言語, ソフトウェアについては を参照してください. Awesome List in Qiita Awesome Java Awesome JavaScript Awesome Node.js Awesome Python Awesome Go Awesome Selenium Awesome Appium 抽象化 ActiveInteraction - アプリケーション固有のビジネスロジックを管理します. Cells - Rails のコンポーネントを表示します. Decent Exposure - コントローラに宣言的インタフェースを提供するヘルパー. dry-rb - 共通のタスクをカプセル化するための, 次世代 Ruby ライブラリコレクションです. Interactor - 1回のリクエストで複雑なインタラクションを実行するため

        Awesome Ruby : 素晴しい Ruby のライブラリ・ツール・フレームワーク・ソフトウェアの数々
      • Rails × ECS でオートスケーリング&検証環境の自動構築 - メドピア開発者ブログ

        マリオカートでカーブを曲がるときに体を傾斜させてしまうCTO室 kenzo0107 です。 今回は 2018/04/02 にリニューアルしたイシコメの Rails × ECS についてです。 イシコメとは? 「イシコメ」は、医師10万人の声でつくるヘルスケアメディアです。 医師と一般の方々をつなげることで、医療情報格差を埋めることを目指しています。 MedPeerの10万人の医師会員に協力いただいたアンケート結果をもとに編集部で記事を執筆し、医師監修の上で配信。多くの医師の声を反映することで、より正しい情報を提供しています ishicome.medpeer.jp リニューアル経緯 リニューアル前は以下のような構成でした。 フロントに Laravel 5 バックに Drupal Docker on EC2 コンテナイメージの S3 でのプライベート管理 Docker がまだ出てきて間もない頃

          Rails × ECS でオートスケーリング&検証環境の自動構築 - メドピア開発者ブログ
        • Rails: Evil Martiansが使って選び抜いた夢のgem(翻訳)|TechRacho by BPS株式会社

          概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Gemfile of dreams: the libraries we use to build Rails apps—Martian Chronicles, Evil Martians’ team blog 原文公開日: 2023/01/17 原著者: Vladimir Dementyev(首席バックエンドエンジニア)、Travis Turner(技術記事編集者) サイト: Evil Martians -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 日本語ブログ: 合同会社イービルマーシャンズ - Qiita 日本語タイトルは内容に即したものにしました。また、gemごとにGitHubリポジトリへのリンクカードも追加してあ

            Rails: Evil Martiansが使って選び抜いた夢のgem(翻訳)|TechRacho by BPS株式会社
          • Fargate x Railsで考慮したassets配信・ログ・秘匿情報管理・モニタリングについて - ZOZO TECH BLOG

            こんにちは。WEARリプレイスチームの id:takanamito です。 先日、社内で初めてAWS Fargate上でRailsを動かす環境をつくったので、その事例報告をしようと思います。 Fargate導入のきっかけ コンテナ環境で動かすにあたって考慮したこと assets配信 ログ出力 秘匿情報の注入 リソース監視 苦労した点 まとめ Fargate導入のきっかけ WEARでは先日RubyKaigi 2019のスポンサーセッションでお話したように、Ruby on Railsへのシステムリプレイス作業を進めています。 そんな中、手作業で行っている運用を管理画面上でツール化したいという要望が上がってきました。リプレイス作業中であるため、できれば新機能はRailsで実装をしたいところです。しかし管理画面に相当するアプリケーションをデプロイするインフラはまだありませんでした。 WEARリプレ

              Fargate x Railsで考慮したassets配信・ログ・秘匿情報管理・モニタリングについて - ZOZO TECH BLOG
            • Railsのログをなんとかしたい人生だった - Qiita

              Railsのログ問題 便利なことにRailsは特に設定しなくてもproduction.logにログを吐いてくれる。エラーメッセージやSQL文も出力してくれるので助かる反面、以下のような問題点がある。 1リクエストで複数行流れるので、エラー調査や緊急対応時にgrepできない デフォルトだと若干冗長すぎる Fluentd等のログの活用を考えた際にパースが非常に面倒 Rails.loggerをオレオレカスタマイズするのも無くはないが、メンテナンスのことも考えて、ログ出力用ライブラリLogrageを使ってJSON形式のログをスマートに出力するようにした。 Logrageとは Railsのログのいい感じに出力してくれるライブラリ https://github.com/roidrage/lograge ちなみにLogrageの説明ではRailsのデフォルトログを「noisy and unusable,

                Railsのログをなんとかしたい人生だった - Qiita
              • Collecting and Analyzing Ruby on Rails Logs | Fluentd

                Scenario You have an application written in Rails and want to collect data into MongoDB, HDFS, Elasticsearch, et. al. for analytics/search. Logging directly into MongoDB/HDFS/Elasticsearch is not highly recommended since synchronous logging is slow/potentially hazardous for the backend. You can build asynchronous logging into your application, but Fluentd can sit between your application and backe

                • GitHub - roidrage/lograge: An attempt to tame Rails' default policy to log everything.

                  You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                    GitHub - roidrage/lograge: An attempt to tame Rails' default policy to log everything.
                  • 綺麗なコードを書くためのコードレビューチェックリスト - Qiita

                    綺麗なコードを書くためのコードレビューチェックリスト PR出す前にこの観点は必要だよねリストまとめ 1. 設計と仕様の整合性 コードが既存のシステム設計に一致しているか確認します。 例えば、MVCアーキテクチャを採用している場合、モデル、ビュー、コントローラーが適切に分離されているかをチェックします。 機能要件 コードが仕様書に記載された機能を正しく実装しているか確認 テストケースを使って期待される動作を検証すると効果的 非機能要件 パフォーマンス、セキュリティ、拡張性などの非機能要件も満たしているかをチェックし YAGNI(You Aren't Gonna Need It)の原則 必要な機能だけを実装し、将来の要求に備えて無駄な機能を追加しない。これはコードの複雑さを減らし、保守性を高めます。 オブジェクト指向設計の原則 単一責任の原則 (Single Responsibility Pr

                      綺麗なコードを書くためのコードレビューチェックリスト - Qiita
                    • Rails でリクエストの HTTP ヘッダを取得してログに出力する - xyk blog

                      環境:rails 4.2.0 Rails でリクエストの HTTP ヘッダはrequest.headersから取得できる。 すべてログに出力するなら # すべてログに出力する request.headers.sort.map { |k, v| logger.info "#{k}:#{v}" } 個別に取得するなら # ユーザーエージェントを取得する request.headers[:HTTP_USER_AGENT] request.envからでも取得できる。 # ユーザーエージェントを取得する request.env['HTTP_USER_AGENT'] 今回やりたいことはクライアント側から HTTP ヘッダに API のバージョンを埋め込んでリクエストしてくるので、すべてのリクエストの API バージョンを取り出してログに出力したい。 リクエストのパラメータを curl で再現すると以下

                        Rails でリクエストの HTTP ヘッダを取得してログに出力する - xyk blog
                      • Rails8.0.0マイルストーンの現状 - おもしろwebサービス開発日記チラシの裏

                        これはなに 8.0.0 Milestoneを見て気になったものをまとめています マイルストーンは先週くらいにできたのですがもうマージされているやつもたくさんあります DHHが年末年始にめっちゃ働いている 気になったものたち Ruby3.3以上のサポート DHHは最初3.3以上で、という気持ちだったんだけど流石にみんな大変やろ、という意見が出て結局リリース時(2024年の予定)にサポートされているRubyのバージョン、つまり3.1以上に落ち着いた PR: Bump the required Ruby version to 3.1.0 by byroot · Pull Request #50491 · rails/rails ↑のPRでは「メジャーバージョンアップ時にRubyのサポートを落とす」だとRails自体のメンテも大変だしアプリケーション開発者も大変なので、毎回マイナーバージョンアップ

                          Rails8.0.0マイルストーンの現状 - おもしろwebサービス開発日記チラシの裏
                        • LTSVをNginxで使ってみる - Hidden in Plain Sight

                          id:stanaka のLTSVがバズってるみたいなので乗ってみた。(Hacker Newsにもポストしたんだけど、瞬時に流れてしまったよ。。) Nginxでの設定を(主にキーの命名で)1時間ぐらい試行錯誤した結果、とりあえず以下に落ち着いた。 log_format ltsv 'ts:$time_iso8601\t' 'ip:$remote_addr\t' 'method:$request_method\t' 'path:$request_uri\t' 'status:$status\t' 'size_req:$request_length\t' 'size_res:$bytes_sent\t' 'size_body:$body_bytes_sent\t' 'time_req:$request_time\t' 'time_app:$upstream_response_time\t' # '

                            LTSVをNginxで使ってみる - Hidden in Plain Sight
                          • Awesome Ruby : 素晴しい Ruby のライブラリ・ツール・フレームワーク・ソフトウェアの数々 - Qiita

                            元記事: Awesome Ruby Ruby 以外の言語, ソフトウェアについては を参照してください. Awesome List in Qiita Awesome Java Awesome JavaScript Awesome Node.js Awesome Python Awesome Go Awesome Selenium Awesome Appium 抽象化 ActiveInteraction - アプリケーション固有のビジネスロジックを管理します. Cells - Rails のコンポーネントを表示します. Decent Exposure - コントローラに宣言的インタフェースを提供するヘルパー. dry-rb - 共通のタスクをカプセル化するための, 次世代 Ruby ライブラリコレクションです. Interactor - 1回のリクエストで複雑なインタラクションを実行するため

                              Awesome Ruby : 素晴しい Ruby のライブラリ・ツール・フレームワーク・ソフトウェアの数々 - Qiita
                            • Awesome Ruby : 素晴しい Ruby のライブラリ・ツール・フレームワーク・ソフトウェアの数々 - Qiita

                              元記事: Awesome Ruby Ruby 以外の言語, ソフトウェアについては を参照してください. Awesome List in Qiita Awesome Java Awesome JavaScript Awesome Node.js Awesome Python Awesome Go Awesome Selenium Awesome Appium 抽象化 ActiveInteraction - アプリケーション固有のビジネスロジックを管理します. Cells - Rails のコンポーネントを表示します. Decent Exposure - コントローラに宣言的インタフェースを提供するヘルパー. dry-rb - 共通のタスクをカプセル化するための, 次世代 Ruby ライブラリコレクションです. Interactor - 1回のリクエストで複雑なインタラクションを実行するため

                                Awesome Ruby : 素晴しい Ruby のライブラリ・ツール・フレームワーク・ソフトウェアの数々 - Qiita
                              • GitHub - gramantin/awesome-rails: A curated list of awesome things related to Ruby on Rails

                                Note: Rails versions of these apps are valid as the date of latest commit. They are defined in their Gemfile and/or Gemfile.lock and they might be outdated. If you find it outdated, don't forget to notfiy us by opening a pull request. FAE - A modern CMS developed by FINE (using Rails 5.2) activeWorkflow - An intelligent process and workflow automation platform based on software agents (using Rails

                                  GitHub - gramantin/awesome-rails: A curated list of awesome things related to Ruby on Rails
                                • Railsのログを awslogs で Cloudwatch Logs に出力する - アクトインディ開発者ブログ

                                  morishita です。 今回はいこレポでのログ出力について紹介します。 いこレポの動作環境 いこレポは ElasticBeanstalk を利用してアプリケーションサーバを稼働させています。 ElasticBeanstalk ではプラットフォームを選択できますが、 Multi Container Docker を利用しています。 この場合、実際にRailsが稼働するのは ECS上に起動された Docker コンテナとなります。 Dockerではコンテナ内に永続化するデータを保存しないことが基本ですが、ログも コンテナ削除時に消えていい情報ではないので何らか外に出す必要があります。 その方法としては次の方法があるかと思います。 案1. ホスト側のディレクトリをマウントして、そこにログを保存する 案2. Fluentd でログサーバに転送する 案3. Cloudwatch Logsに転送す

                                    Railsのログを awslogs で Cloudwatch Logs に出力する - アクトインディ開発者ブログ
                                  • 週刊Railsウォッチ: VSCodeでRubyコード実行結果を表示、rubygems.orgがgem作者に多要素認証を呼びかけほか(20220621後編)|TechRacho by BPS株式会社

                                    こんにちは、hachi8833です。RubyKaigi 2022のCFPが一昨日締め切られました。 Final Call: CFP for RubyKaigi 2022 closes at midnight today (in JST). Don't forget to submit your proposal(s) within 6.hours.from_now! 🥷💨 https://t.co/mLjIuqCsyM #rubykaigi — RubyKaigi (@rubykaigi) June 19, 2022 週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを(鍋のように)社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@h

                                      週刊Railsウォッチ: VSCodeでRubyコード実行結果を表示、rubygems.orgがgem作者に多要素認証を呼びかけほか(20220621後編)|TechRacho by BPS株式会社
                                    • Logging of Rails in Lograge - Qiita

                                      ログはアプリケーションの開発中はもちろん、運用でもとても大切な情報です。 Rails の標準機能のロギングではアクセスログやエラーログなど様々な情報が混在しています。 ログはアクセスログ・業務ログや正常系・異常系など関心事を分離して設計することが大切です。 今回はアクセスログに注目したログの入門編としてサンプルを作成しました。 Rails はスケールアウトを構成することがあるのでログは Fluentd で集めて 全文検索機能がある Elasticsearch などに登録するとよいですね。 Environment Ruby: v2.2.3 Rails: v4.2.5 Elasticsearch: v2.1.1 Fluentd: v0.12.16 Simple Authentication まず、ログのサンプルに単純な認証のWabアプリケーションを作ります。 Setup rails new の

                                        Logging of Rails in Lograge - Qiita
                                      • Kaigi on Rails 2021 に参加 / 登壇しました - ねこものがたり

                                        イベントページ kaigionrails.org 登壇しました speakerdeck.com 内容としてはスライドの通りで、テストを早くしたいなーそのためにテストデータを作成している部分にアプローチしたいなーそれを効率よくやりたいなーと思って取り組んでいることについて話しました。 登壇のきっかけ 最初は登壇したいという気持ちも、CFP を出そうという気持ちもありませんでした。 それでも CFP を出した理由は2つあります。 1つ目は、チーフオーガナイザーの大倉さんが「あなたもCFP を出しませんかー」と各 Ruby コミュニティーを巡っていたらしいのですが、自分もそれに遭遇して、声をかけてもらって前向きに考えるきっかけになたことです。そしてその時に 角谷さんが「 CFP 出すのも練習だよ」とおっしゃっていて、「なるほどー練習かー」となんだかハードルが下がったことです。 大倉さん、角谷さん

                                          Kaigi on Rails 2021 に参加 / 登壇しました - ねこものがたり
                                        • HerokuをMackerelで監視する - Mackerel ヘルプ

                                          Herokuでのご利用は公式サポートの対象外です。 Herokuはウェブアプリケーションを動かすためのPaaSです。 ここでは、Mackerelを利用してHeroku上のアプリケーションを監視する方法を紹介します。 ただし、公式サポート対象とはなっておりませんので、使用上のご質問等にお答えできかねます。なお、対応環境についてはこちらをご確認ください。 Dynoを監視する サービスメトリックを投稿する RailsでJSON形式のログを出力する rsyslogを設定する Heroku Drainsを設定する fluentdを設定する サービスメトリックの監視ルールを追加する Dynoを監視する Herokuは自動でホスト(Dyno)が増減しますので、Auto Scaling環境で使うの設定をHerokuに合わせて利用します。 Herokuでアプリケーションを起動するための Procfile で

                                            HerokuをMackerelで監視する - Mackerel ヘルプ
                                          • 週刊Railsウォッチ: Evil Martiansが使っているgem、JavaScriptガイドが更新ほか(20230131前編)|TechRacho by BPS株式会社

                                            こんにちは、hachi8833です。RubyKaigi 2023のCFPは今夜1/31いっぱいが締め切りです。 “about 15 hours left to submit your proposal” 🏯🏔️📝👀💨 #rubykaigi https://t.co/n4CUDDLf6X pic.twitter.com/klXhtyZqpY — Kakutani Shintaro (@kakutani) January 31, 2023 週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを(鍋のように)社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 Tech

                                              週刊Railsウォッチ: Evil Martiansが使っているgem、JavaScriptガイドが更新ほか(20230131前編)|TechRacho by BPS株式会社
                                            • 週刊Railsウォッチ: Shopifyのlanguage server ruby-lsp、PostgreSQL 15 Beta 1リリースほか(20220607後編)|TechRacho by BPS株式会社

                                              週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを(鍋のように)社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます(例:週刊Railsウォッチタグ) 🔗Ruby 🔗 Rubyでスクレイピングを書いて中古ギターを買った(Ruby Weeklyより) 元記事: Scraping Buy: Scripting

                                                週刊Railsウォッチ: Shopifyのlanguage server ruby-lsp、PostgreSQL 15 Beta 1リリースほか(20220607後編)|TechRacho by BPS株式会社
                                              • HerokuのログをBigQueryへエクスポートする | tsuchikazu blog

                                                Herokuのログはどんどん流れていってしまうため、どこかに保存しなくてはなりません。そのため、PapertrailやCoralogix Loggingなどのaddonを使って、外部サービスへlogを流して、そちらである程度の期間分、永続化するなり、検索して活用するなどしているかと思います。大量のアクセスがきて大量のログが流れるアプリケーションの場合、ログが大量になりプランアップにしなければならなくなり、addon料金も馬鹿にならない。ということになったりしないでしょうか? そこで、addonを使用せずにGoogle BigQueryへログを転送して、利便性を損なわずにコストダウンを図るということをやってみたので、それの紹介です。ざっくりの概要としてはこのような形。 Loggingライブラリ Heroku上のアプリから、Loggingライブラリなどを利用して、Cloud Loggingへ書

                                                  HerokuのログをBigQueryへエクスポートする | tsuchikazu blog
                                                • 検索・集計がしやすいロギング環境の構築 - mrk21::blog {}

                                                  調査しやすいロギング環境について社内勉強会で発表したやつをまとめたやつです。 問題が起きたときなどにログを調査することはよくあることだが、ここでは調査しやすログとはどのようなもので、どうやって構築していくかについて述べる。 何も考えずにロギングしたときの問題点 ログファイルが巨大すぎて大変 ログファイルが複数に大量に分かれて大変 複数のリクエストのログが混ざって識別が困難 ログを検索するときに正規表現などで検索しなければならず大変 調査や集計などがしやすいロギング環境への改善 上記の問題を解決するためには以下を行う。 ログをローテーションする ログを集約する リクエストを判別できるリクエストIDなどを付与する ログをJSONなどに構造化する ログをローテーションする ActiveSupport::Logger や logrotate を使う ログを集約する CloudWatch Logs

                                                    検索・集計がしやすいロギング環境の構築 - mrk21::blog {}
                                                  • 週刊Railsウォッチ: GitLabがRailsにこだわる理由、Rails7アップグレードのハマりどころほか(20220620前編)|TechRacho by BPS株式会社

                                                    こんにちは、hachi8833です。 インボイス制度の施行のために、年商一千万円を超える全ての法人の所在地、個人事業主の屋号と氏名が、csv で全面的に公開されることになりました。 Web APIで名前の一部だけ返す仕様で良かったはずなのに、国内の全事業者リストを公開するとはね。 https://t.co/bDR77U5ZBZ — 藤井 太洋, Taiyo Fujii (@t_trace) June 14, 2022 つっつきボイス:「年商一千万円を超える全ての法人と個人事業主が対象、マジで?」「年商は売上のことですね」「あくまで登録リストが公開されるだけで額までは公開されていませんけど」「そういえば高額納税者リストは廃止されてましたね↓」「公開する理由がよくわからないな〜」「APIで個別に公開しても一気にリストを取得する人はいそうですけどね」 参考: 高額納税者公示制度 - Wikipe

                                                      週刊Railsウォッチ: GitLabがRailsにこだわる理由、Rails7アップグレードのハマりどころほか(20220620前編)|TechRacho by BPS株式会社
                                                    • RubyJunky.com

                                                      RubyJunky.com A Ruby, Rails, and general programming blog by Brian VanLoo Cleaning Up Rails 4 Production Logging I’ve seen some very effective use of application logging to debug difficult problems. The foundation of good logging is being sure that your application is logging the right things. However, it’s just as important for your log files to be easy to parse - both for a human reading the fil

                                                      • Railsのログをなんとかしたい人生だった - Qiita

                                                        Railsのログ問題 便利なことにRailsは特に設定しなくてもproduction.logにログを吐いてくれる。エラーメッセージやSQL文も出力してくれるので助かる反面、以下のような問題点がある。 1リクエストで複数行流れるので、エラー調査や緊急対応時にgrepできない デフォルトだと若干冗長すぎる Fluentd等のログの活用を考えた際にパースが非常に面倒 Rails.loggerをオレオレカスタマイズするのも無くはないが、メンテナンスのことも考えて、ログ出力用ライブラリLogrageを使ってJSON形式のログをスマートに出力するようにした。 Logrageとは Railsのログのいい感じに出力してくれるライブラリ https://github.com/roidrage/lograge ちなみにLogrageの説明ではRailsのデフォルトログを「noisy and unusable,

                                                          Railsのログをなんとかしたい人生だった - Qiita
                                                        • 小さいチームで実践する!開発速度・信頼性向上のためにやってよかったシステム改善3選 - dely Tech Blog

                                                          こんにちは、クラシルリワードのSRE担当のjoooee0000です。 私はクラシルリワードのサービスローンチの約3ヶ月後にサーバー兼インフラエンジニアとしてjoinし、サービスの成長と共に、開発速度とシステムの信頼性の向上を目指してシステムの改善を行ってきました。 その中で、特に開発速度と信頼性向上に寄与したと思う3つの改善を紹介したいと思います。 改善を行う際に「コスト(金額、導入共に)と効果のバランス」「運用しやすいシンプルな設計」に特に気をつけたので、参考なると幸いです。 (話すこと: 取り組んだ施策の概要紹介、 話さないこと: 細かいhow to) やってよかったこと3選 ブランチ戦略の見直しとシンプルな検証環境の維持 ログの構造化とNewRelicログUIの導入 インシデント管理ツールの導入 それぞれ、改善前にどのような課題があったか、改善後のメリットなどを紹介していきます。 1

                                                            小さいチームで実践する!開発速度・信頼性向上のためにやってよかったシステム改善3選 - dely Tech Blog
                                                          • Top 10 errors from 1000+ Ruby on Rails projects (and how to avoid them)

                                                            Top 10 errors from 1000+ Ruby on Rails projects (and how to avoid them) To give back to our community of developers, we looked at our database of thousands of projects and found the top 10 errors in Ruby on Rails projects. We’re going to show you what causes them and how to prevent them from happening. If you avoid these "gotchas," it'll make you a better developer. Because data is king, we collec

                                                              Top 10 errors from 1000+ Ruby on Rails projects (and how to avoid them)
                                                            • Ruby in Production: Lessons Learned

                                                              Having deployed a variety of Ruby apps (Rails and non-Rails) over the course of many years, here are some lessons I’ve learned to keep things afloat. Tools like Mina and Capistrano already do most of these (more on that further down), but its good to have a first-hand understanding of what needs to happen. All these instructions are available a ready-to-use repo: ruby-deploy-kickstart Ruby/Rails d

                                                                Ruby in Production: Lessons Learned
                                                              • RailsのログをfluentdでBigQuery、あるいはS3に取り込む - kotaroito's notes

                                                                GCP BigQueryやAWS Athenaを実際に触る機会が欲しかったので、RailsのログをfluentdでBigQueryやS3に取り込んでみます。 とりあえず触ることが目的で、実用できるかはとりあえず脇においておきます。 なお、fluentd(td-agent)はOS Xに0.14.21 をインストールしています。 Rails fluent logger Railsのログはデフォルトでは log ディレクトリに出力されるため、これをfluentdで扱えるようにする必要があります。 ドキュメント Collecting and Analyzing Ruby on Rails Logs | Fluentd に従って、lograge と act-fluent-logger-rails を使ってみます。 ほぼドキュメント通りですが、以下のように設定しました。 config/applicat

                                                                  RailsのログをfluentdでBigQuery、あるいはS3に取り込む - kotaroito's notes
                                                                • 退職しました - nazolabo

                                                                  from: UUUM株式会社(2015.06-2019.10) to: まだないしょ 在籍期間中に会社の技術ブログに書いた記事は以下になります。 Railsプロジェクトを引き継いでから安定させるまでに行ったこと 社内勉強会でサービスクラスがなぜ存在するのかについて紹介しました ansibleでECSのタスク定義を更新し、安全に機密情報を管理する ECSをより便利に使うためのポイント解説 ElasticsearchをMySQLと同期しつつ手軽に無停止アップデートする AWS CloudWatch LogsでECSのログを手軽に取り扱う 4000以上のチャンネルを支えるデータ解析基盤をBigQuery, Go, embulk等で整備した話 PHPなチームがRuby on Railsでの開発を行って得られたもの CircleCIでRailsのDockerコンテナをECSにデプロイする Docke

                                                                    退職しました - nazolabo
                                                                  • Heroku で動いている Rails アプリを ECS Fargate に移行する - Qiita

                                                                    この記事は SmartHR Advent Calendar 2019 7日目の記事です。 最近 Heroku から ECS Fargate に移行するプロジェクトを担当しました。そちらが一段落したので、移行する上で検討したこと、どのように実現したかを共有します。 SmartHR では、いくつかの機能ごとにチームが分かれており、リポジトリもインフラもチームごとに分けて開発が進められています。私のチームで開発しているアプリケーションはもともと Heroku の上で動いていたのですが、最近 ECS Fargate に移行するプロジェクトを完了しました。 この会社に来るまで、 Heroku を使ったことは無かったのですが、Heroku の印象として、インフラ周りの運用は全てお任せして開発に集中できるという観点では最高だなというところです。 ただ、 Heroku のレールから外れたことをしようとする

                                                                      Heroku で動いている Rails アプリを ECS Fargate に移行する - Qiita
                                                                    • Better Rails logging | phawk

                                                                      When insignificant messages are clogging up your application logs it can be very difficult and time consuming to debug errors happening in production. Luckily, Rails logging is highly configurable and with a few tweaks you can pinpoint exceptions much faster. 12 factor logsIf you haven’t read the 12 factor app do so post-haste! TL;DR your app should log to STDOUT and not concern itself with anythi

                                                                        Better Rails logging | phawk
                                                                      • RailsをECSで動かす時のログをどうするか考える - onigra.github.io

                                                                        RailsをECSで動かす時のログをどうするか考えるMay 4, 2020 by Yudai Suzuki 実験リポジトリhttps://github.com/onigra/rails_sandbox制約Fargateリバースプロキシは別の Service で動いているh2o, nginx など http server のログは考慮しないApplication Server は Unicorn方針Rails, Unicorn のログは全部 STDOUT に出すSTDOUT に両方のログがまとめて出るLog Format は JSONUnicorn のログ も JSON にするログは FireLens と fluent-bit 使っていい感じに集約する ログは全部CloudWatch Logsに吐いて、その先はKinesis FirehoseRails, Unicorn のログは全部 STD

                                                                        • Managing and enhancing Rails application logs

                                                                          Product { this.openCategory = category; }, 160); }, clearCategory() { clearTimeout(this.timeoutID); } }" x-init=" const menu = document.querySelector('.product-menu'); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(mutation) { if (mutation.attributeName === 'class' && !mutation.target.classList.contains('show')) { openCategory = 'observability'; } }); }); obse

                                                                            Managing and enhancing Rails application logs
                                                                          • Fluent Bit で ECS コンテナログから特定ログを抽出する - メドピア開発者ブログ

                                                                            SREチームの左サイドバック @kenzo0107 です。 今回は ECS コンテナログから特定のリクエストによるログを抽出し、 Athena でクエリ捜査できる様にした話です。 コンテナログから特定リクエストによるログを抽出する目的 以下への一助としたい為に実装しました。 アプリケーションの改善となるデータの集計 問題発生時の調査 コンテナログはどのように出力されるか ECS コンテナログを JSON 形式で出力すると以下の様になります。 { "source":"stdout", "log":"{\"method\":\"GET\",\"path\":\"/sre/boshuchu\",\"format\":\"html\",\"controller\":\"SRE::BoshuchuController\",\"action\":\"show\",\"status\":200,\"du

                                                                              Fluent Bit で ECS コンテナログから特定ログを抽出する - メドピア開発者ブログ
                                                                            • kibana4によるRailsアプリの可視化 EC2 Amazon Linux - Qiita

                                                                              Railsとkibanaで新しい情報がまとまってなかったので、まとめました。 出来ること Rails logの可視化 アプリの速度の分析、高速化などに使える デプロイ時に、各種数値変化をリアルタイムでモニタリングできる(切り戻しの判断) ステータスコードの割合 処理時間の分布 クローラーや、PC、スマフォなどのユーザーの動向を分析 特定のユーザーの行動を追うことが出来る(運用保守) お試しなのでいろいろ妥協している kibana 4.4.1 elasticsearch 2.2 ネットワーク、セキュリティーグループの設定は省略。 前提条件として、kibanaとrailsのサーバーは同じネットワークにいて、 private ipでやり取りしていることにする。 Rails 下準備 gem "lograge" #elastic_search用 log整形 gem "logstash-event"

                                                                                kibana4によるRailsアプリの可視化 EC2 Amazon Linux - Qiita
                                                                              • Shipping Rails logs with Kamal and Vector

                                                                                The ability to record and see everything happening across your web applications is essential when building resilient and highly available systems. All of your events—from application logs to errors to user behavior—contain data that could be useful to you and your team. When you have a central place to access all this information, finding issues and their root causes becomes easier because you hav

                                                                                  Shipping Rails logs with Kamal and Vector
                                                                                • logrageではRails.loggerのログ出力がJSON形式にならない問題 - Qiita

                                                                                  はじめに RailsログをJSON形式にしたいだけなんですが、解決方法が意外とめんどくさかったので、ググってたどり着いた誰かのためにメモを残しておきます。 「Railsログ JSON」で雑にググるとlogrageというgemをいれるとよさそうな感じです。 https://github.com/roidrage/lograge gem入れるだけでバーンといいかんじのJSONになることを期待したのですが、以下の記事に書いてあるとおり、このgemはコントローラのアクセスログや例外しかJSON形式で出ません。 https://qiita.com/amanekey/items/b921ef73d871dac299eb おもむろに Rails.logger.info("foo") とかしてもJSONにならなくてそのまま出力されちゃう。 つまりこんなかんじ。 {"method":"GET","path"

                                                                                    logrageではRails.loggerのログ出力がJSON形式にならない問題 - Qiita