Raven+fluentd+Elasticsearch/KibanaでRailsの例外を集約する - so what
SentryというPythonやRubyなど様々な言語の例外を集約して閲覧するWebサービス/OSSがあります。個々のログを検知・閲覧するにはいいんですが、全体を俯瞰して分析するならKibanaの方が良さそうだったので、Sentryに集めているログをKibanaに流してみました。 用意するもの 壊れたRailsアプリ Raven-Ruby Sentryのクライアント（Ruby版） Raven::Transports::Fluentd Ravenの出力をfluentdに向けるためのライブラリ fluentd fluent-plugin-elasticsearch fluent-plugin-raven-decoder RavenでエンコードされたRailsエラーをデコードするためのfluentdプラグイン Elasticsearch/Kibana セットアップ Rails まず、Railsを
react-railsでサーバーサイドレンダリングしつつクライアントでsetStateできて最高になった - Qiita
土日でreact-railsとturbolinksを勉強してみた成果です やりたいこと 画面遷移するときは<div id='content'></div> の中身だけ入れ替えて、pushStateで行き来できるようにしたい reactを使ったリッチなページでも、イニシャルロードやSEOの為にサーバーサイドでレンダリングしておきたい サーバーサイドレンダリングした要素を破棄することなくReactで初期化してsetStateでガンガンViewを書き換えたい 結果どうなったか サーバーサイドでReactComponentをレンダリングしてクライアントのReact.renderで初期化情報を揃えて引き継ぎ どんな画面でもapp.component.setState({})が反映されて最高 TurbolinksでReactComponentをマウントしたルート要素だけ入れ替え その為にTurboli
新規サービスの管理画面を短期間で見栄え良く実装する - クックパッド開発者ブログ
こんにちは、クックパッド料理教室の京和です。 管理画面はほとんどのウェブサービスに存在し、ユーザサポートやサービスの状況・KPIなどを確認するために、スタッフが毎日利用するとても重要なものです。にも関わらず、新規サービスでは人員が不足していることから、ついおざなりなデザインや実装になりがちなのではないでしょうか。 今回はクックパッド料理教室で採用している、RailsのMountable EngineとBootstrapのデザインテンプレートを使った、見栄えがよくメンテナンスしやすい管理画面を短期間で実装する方法についてご紹介します。 Mountable Engineとは Mountable EngineはRailsアプリケーション上で動く、ミニRailsアプリケーションのようなものです。 ミニと書きましたが、Railsアプリケーション(Rails::Application)はRails::
Mountable Engine だらけの Rails アプリ開発 - onk.ninja
Mountable Engine だらけの Rails アプリ開発 はじめに これはドリコムアドベントカレンダーの 2 日目です。 1 日目は id:sue445 さんによる ドリコムを支える中間ポイントシステム - くりにっき です。 お前誰よ id @onk ドリコム歴 2006/12/01 中途入社 9年目に突入しました 仕事 アプリケーションエンジニア 2009/04 から Rails アプリを触るように 主にサーバサイドを担当しています 今日の話 「普通に Rails アプリを作ると Mountable Engine を少なくとも 5 個は使う時代になったよね」って話をします。 目次 Mountable Engine とは Mountable Engine の作り方 Mountable Engine のテストの書き方 Mountable Engine の設定を書きたい 管理画面付
Ruby on Rails で NOT IN な SQL をかく。 | そんなこと覚えてない
Rails 4 で NOT な条件をもつ WHERE 句 が非常に書きやすくなりました。 Rails 4 なら NOT IN な SQL も簡単に書けます。 User.where.not( name: ["hoge","goro"] ) 条件にリストを渡せばよいです。SQLは以下のようになります。 SELECT "users".* FROM "users" WHERE ("users"."name" NOT IN ('hoge', 'goro')) サブクエリも使えます。これが便利すぎて困る。 query = User.select(:name) User.where.not name: query SELECT "users".* FROM "users" WHERE ("users"."name" NOT IN (SELECT name FROM "users")) Rails 3 の
APIフレームワークGrapeをRuby on Railsの中で動かすと遅いぞ - yuumi3のお仕事日記
ある仕事でスマフォ用のAPIサーバーを作る事になり、REST-like APIが簡単に作れるフレームワーク grape を調査してみました。grapeの良さは、DSLで簡単にAPIサーバーが書ける点とRackで動く軽いフレームワークなのでRuby on Railsに比べ高いパフォーマンスが期待できる点です。 システム構成 Grapeは Mounting に書かれているようにいくつかの構成で動かせます Rack: Rack上で動かす ActiveRecord without Rails: Rackの上で動かすけど ActiveRecord を使う Rails: Ruby on Railsの中で動かす ... 今回のシステムでは管理者用のWebアプリは Ruby on Railsで作るので、モデルを共有できるRuby on Railsに組み込み使うのが魅力的です。 評価用コードを作ってみた 準
pplogのGemfile - ppworks.jp
Gemfile pplog のGemfileです。 rev: 38530c94aebae07372f184ee3b726b988ea53aa4 source 'https://rubygems.org' ruby '2.2.0' # Framework gem 'rails', '4.2.0' gem 'responders', '~>2.0' # Database gem 'pg' # Authentication gem 'authority' gem 'devise' gem 'omniauth' gem 'omniauth-twitter' # APIs gem 'twitter', '>= 5.11.0' gem 'airbrake' gem 'hipchat' gem 'idobata' gem 'grape' gem 'pusher' gem 'em-http-request
RSpec をやめて Test::Unit に戻る - tmtms のメモ
最近の RSpec は、それまで obj.stub(hoge: value) と書けたものが、 allow(obj).to receive(:hoge).and_return value と書かないといけなくなったりとか、正気の沙汰とは思えないような変更をしたりするので、何年かぶりに Test::Unit を使ってみようとリハビリ中です。 RSpec は、テストケースを入れ子にできたり、テストケースや example がクラスやメソッドではなく、文字列で自由に書くことができたりしたのが良かったのですが、最近の Test::Unit ではそれもできるようになっています。 [ruby-list:48926] [ANN] test-unit 2.5.2 このリリースはとみたさんに使ってもらえるように改良したリリー スです。新しく追加した--locationはRSpecの--line_number
%25E3%2583%2597%25E3%2583%25AD%25E3%2583%2595%25E3%2582%25A3%25E3%2583%25BC%25E3%2583%25AB%25E6%259B%25B4%25E6%2596%25B0%25E3%2581%25BF%25E3%2581%259F%25E3%2581%2584%25E3%2581%25AA%25E3%2582%2584%25E3%2581%25A4%25E3%2581%25AE%25E6%25B3%25A8%25E6%2584%258F%25E7%2582%25B9)
(Railsで)プロフィール更新みたいなやつの注意点 - けんちゃんくんさんのWeb日記
前職と現職で2アウト案件。 Railsに限らないけど、ログインユーザの情報を変更するときは current_user みたいな変数を変更するんじゃなくて、DBを引き直して更新しましょうって話。 ダメな例 class ProfileController def update if current_user.update(profile_params) redirect_to :root else render :edit end end end 良い例 class ProfileController def update @user = User.find(current_user) if @user.update(profile_params) redirect_to :root else render :edit end end end なんでだめなの？ バリデーションエラーが起きた時に
Railsをバージョンアップし続けるために必要なこと - Qiita
本当は、RubyWorld Conf辺りでこういう内容も交えてなんか話せればいいなあと思ってたんだけど、CFPに落ちたのでQiitaにポエムを書いてみました。 Railsはそれなりに学習コストはかかりますが、慣れてくるとデフォルトで便利なものが揃ってるしサードパーティライブラリも豊富で、未だに最も便利なWebアプリケーションフレームワークの一つだと思います。 なので、最近のスタートアップ界隈ではRailsで開発をスタートする、という話をよく耳にします。(個人の感想です) しかし、Railsは本体に新しい要素をガンガン取り入れてくるので、バージョンアップのサイクルはかなり早く、それに追従していくのはそれなりに大変です。 Railsで開発をする場合には、一旦レールに乗ったらプロダクトが死ぬまで走り続ける覚悟が必要です。(時速60km以下になったら爆発する) それを最初に理解しておかないと、あっ
『パーフェクト Ruby on Rails』は本番Railsアプリの完成度UPに良いと思う - fujimuradaisuke's blog
"Startup Java"と揶揄されるくらい定着したウェブアプリケーションフレームワーク、Ruby on Rails。情熱的なRubyコミュニティ、スタートアップ業界中心の圧倒的な需要が合わさって、巨大なエコシステムが形成されました。チュートリアルや入門書も充実して、すっかり始めやすいフレームワークになった感じです。 けど、プロダクション・クオリティのものを作るに当たって完成度を上げていくための情報って案外まとまってなかった印象があります。例外通知とか、CIの整備とか、プロビジョニングとか、モデルを整理する方法とか。『パーフェクト Ruby on Rails』はそこら辺がカチッとまとまってます。 ガチRailsエンジニアのいないスタートアップでコードの品質あげる、とか、ぴったりだと思う。 あと、RubyもWeb開発もある程度わかるんだけどRailsが巨大過ぎて手を出せてない人。Rails
パーフェクトRuby on Rails 読みました - 月曜日までに考えておきます
パーフェクトRuby on Rails買って、家庭持ち朝方エンジニアなので毎日朝25分ずつコツコツ読んでて読み終えたので感想書きます。 全体として 実践的なテクニックがいっぱい書いてあって、「これいいね、すぐやろう！」とか、「こんな便利なものあったのか！」みたいな感動をたくさん経験できる本です。 一方で、リファレンス的なことはそんなに書かれていないので、そういうのはRails公式ドキュメントを読むか別の本を読むのが良さそうです。 手元において調べ物をしたいときに読む本というよりは、まず読んでみて、「なにこれすごい」って思ったことをすぐに実践してみて、またしばらく時間を置いてから読むとその時に気づかなかった別の凄いテクニックに気づく、みたいな本だと思います。Ruby本で人気のあるメタプログラミングRubyとかもそんな感じですね。 これやろうと思ったこと NewRelicの導入(p.313)
【翻訳】DockerとVagrantによるRails開発環境 - Qiita
（2014年の記事ですよ。） オリジナル："A Rails Development Environment with Docker and Vagrant" by Ben Dixon http://www.talkingquickly.co.uk/2014/06/rails-development-environment-with-vagrant-and-docker/ （デプロイ経験あまりないので訂正、つっこみなど大歓迎です。訳しづらかったところは原文も入れてます。Benさんから翻訳&&シェアOKの許諾もらっています。このテーマでさらにいくつか記事を投稿していく予定らしいです。） 既存のRailsプロジェクトに新しい開発者を招き入れることは、本来あるべき簡単さよりもまだまだはるかに難しいタスクです。アプリやアプリ一式の開発環境構築作業の大部分（正しいバージョンのrubyやデータベースその
Rails でテストをどう書くべきか備忘録
今朝聞いた今週の rebuild.fm のポッドキャストで、テストに関する話題がとても面白く勉強になりましたので備忘録メモ。全部テスト書いてたら時間が足りないし、個人的にはどの部分を重点的にテストすべきか、削っても良いのはどこかに注目して聞きました。 Rebuild: 43: Kent is More Professional (Kenn Ejima) 以下 rebuild.fm 話題から参考にしたいメモ ・テスト書くのは良いが、テスト原理主義、100％カバー、全部テストファーストにこだわるのは疑問。 ・内部構造、実装に対するテストは書かない。 ・モックは一番外側のAPI、インターフェースに対してだけ使う。（※） ・モックのためのモックとかは避ける。 ・リファクタリングのためにテストを書き換えなきゃいけないようなテストは駄目。 ・テストとコードを同時に変更すると、トラブルに気付きにくくなる
バリデーションエラーの理由がログから分からなくてイラっときたときに便利なGem「WhinyValidation」 | mah365
本番環境でもテスト実行中でも、意図せずバリデーションエラーになっていて422が返っているログがあるのだけど、ログからは理由が全く分からなくてイラっとすることはありませんか？ 僕はあります。 そんな人に便利なのがWhinyValidationというGem。 gem 'whiny_validation' とGemfileに一行加えて、config/initializer以下にwhiny_validation.rbというファイルをつくり、以下のように記載するだけでバリデーションエラーの内容がログに流れるようになります。便利ですね！ # config/initializers/whiny_validation.rb WhinyValidation.configure do |config| config.log_level = :info end 中の実装についてはIntroducing Whin
Rails 4.0.4を4.1.0にアップグレードした
Rails 4.1.0が出ていたので、このブログをアップグレードしてみました。 例によって、作業ログを残しておきます。 Riding Rails: Rails 4.1.0: Spring, Variants, Enums, Mailer previews, secrets.yml http://weblog.rubyonrails.org/2014/4/8/Rails-4-1/ (1) GemfileのRailsのバージョンを4.1.0にする (2) 以下のコマンドを実施。 {{{code bundle update rake rails:update }}} -config/routes.rbはスキップ -config/application.rbは特に変化が無かったのでスキップ --（備忘録：4.0.2から4.0.4にアップグレードした時は少し変化があったので修正した記憶があります）
Rails 4.1.0: Spring, Variants, Enums, Mailer previews, secrets.yml
Rails 4.1.0: Spring, Variants, Enums, Mailer previews, secrets.yml Rails 4.1.0 might carry a minor version bump, but there’s nothing minor about the bag of goodies it carries. It simply means that upgrading from 4.0.x should be a relatively mild affair as most of the changes are additions or improvements, not backwards-incompatible changes. Let’s go over some of those new goodies. Spring is our ne
Ruby と Rails を覚えるために約1ヶ月半でやったこと - takatoshiono's blog
仕事で Rails を使ったサービスを担当し始めて約1ヶ月半、Ruby と Rails にもだいぶ慣れてきたので、ここまでどうやって勉強してきたか書いておこうと思います。いや、まだ初心者もいいところなのですが、そのうち忘れてしまって今しか書けなそうなので、書いておきます。 とはいえ、こういう情報は時間の経過と共に意味のないものになってしまいがちなので、なるべく時間に左右されない本質的なことを織り交ぜながら書いていきたいと思います。 irb(main):002:0> Date.new(2014,4,4) - Date.new(2014,2,19) => (44/1) 当時の知識 パーフェクト Ruby を途中まで読んだ Ruby on Rails Tutorial の Chapter 4 Rails-flavored Ruby をやっていた という程度。 パーフェクトRuby (PERFEC
Railsアプリつくった - ✘╹◡╹✘
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
Rails向けエラー通知系サービス調査
8. 登録＆開始方法 トライアルの 行いやすさ △ ○ ○ ○ 最低金額 （月額） $39 $9 （固定） $29 $14 インストール の手軽さ ○ ○ ○ ○
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
