ActiveModelを活用するための属性定義拡張系gemについて - Qiita
ActiveModelをベースにしたモデルクラスやFormオブジェクトを作ってると、attribute定義を沢山書くことになります。 その際に、セットで考えなきゃいけないのは、タイプキャスト、デフォルト値、初期化方法です。 で、この辺りを楽にしたいと考える人は大勢居るもので、これらの定義を楽にしてくれるgemがいくつかあります。 今日、いくつかチェックしたので軽くまとめておきます。 cgriego/active_attr solnic/virtus jetrockets/attrio barsoom/attr_extras active_attr, virtus active_attrとvirtusは、ActiveModel::ModelがRailsに入る前からActiveRecordっぽいインターフェースを持ったオブジェクトを定義しやすいように、モジュール自前で色々持ってます。 更に値を
Rails4へのアップデート時に引っかかったポイントいくつか - Qiita
Rails 4.0.0がリリースされたので今参加しているプロジェクトのアプリのアップデートが出来るかを試してみました。 やってみた結果としては、2.3 -> 3.0や、3.0 -> 3.1に比べると大分楽にバージョンアップできる感じです。 たまたま今のプロジェクトで引っかかった問題について、メモがてらまとめておきます。 rake rails:update diffを見ながらconfigファイルを書き換える。 そんなに大きな変更は無い。 rails4からはinitializerに色々移せって感じで、application.rbが軽量化されてるけど、元のままでも別に問題無い。 設定項目の重複だけ注意。 strong_parameters 元々、gemで先行導入して取り入れていたので概ね問題無く移行できました。 attr_accesibleを利用したセキュリティ対策は、外部のgemに分離されてい
Ruby 2.0 向けのデバッガー byebugについて - Qiita
Ruby 2.0系でのみ動作するdeivid-rodriguez/byebugというデバッガーが存在する事を知りました。 少し触ってみた所、2.0系とdebuggerではどうにも動作が不安定だったステップ実行がちゃんと実行できるし、動作も軽快で良い感じでした。 debuggerとの違いは以下のようになってます。 1.9系では動かない。2.0系のみ対応 2.0で追加されたデバッガ向けのC APIを利用しているため、MRIのソースに依存しないクリーンな実装。(debugger2みたいな感じ) debuggerで現在も残っているissueをいくつか解決している 特に正しいバックトレースを返してくれる点が良い 外部エディターサポートは組み込んでいない スレッドはまだサポートされていない。まだ新しいAPIでサポートされてないかららしい アクティブにメンテしてる pryコマンドを組込んでいるので、by
pry-docでカジュアルにRubyのソースコードを読む - Qiita
RubyのREPL環境として一般的なpryというgemがあります。 pryの非常に便利な機能としてshow-sourceというコマンドがあり、指定したクラスやメソッドのソースコードをpry上で表示してくれます。 [15] pry(main)> require 'tsort' true [16] pry(main)> show-source TSort#tsort From: /Users/joker/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/tsort.rb @ line 133: Owner: TSort Visibility: public Number of lines: 5 def tsort result = [] tsort_each {|element| result << element} result end デフォルトのままのp
rails, rspecでVimのsnippetを使うためのベストプラクティス (自己流) - Qiita
Vimにはtextmateちっくなsnippet補完を実現するためのプラグインがいくつかあります。 neocomplcache-snippets-complete, snipMate, UltiSnipなどなど。 私が利用しているのは、neocomplcache-snippets-completeなので、それを利用する時の流れについての話です。 neocomplecacheを使っていると、補完が統合されるので、neocomplecacheユーザーは大体これに落ち着くと思います。 ちょっと調べたところだと、UltiSnipはかなり高機能っぽいのですが、pythonインターフェースが必要で、ちょっと複雑過ぎるかもしれません。 読み込みのルール 現在のneocomplecacheは、内部でvimのバッファが持っているファイルタイプとは別に、 独自のファイルタイプ情報を持っています。 最近になって
「Docker時代の分散RSpec環境の作り方」の補足 - Qiita
この記事は、大江戸Ruby会議06で発表した Docker時代の分散RSpec環境の作り方 // Speaker Deck の補足です。 何人かに質問されたことや、良いことばかりじゃなくて現状存在している課題について補足として、ここで書かせてもらいます。 まず、良く質問されたのがテストケースの分割方法です。 テストケースの分割は、現状とても雑にやってます。 まず、featureスペックのファイルだけをリストアップして適当にシャッフルして詰めます。 その後で、他のテストケースを順番に詰める、という感じです。 多少、無駄ではあるんですが、前のテスト結果のプロファイルの収集と詰めるロジックを書くのをサボっても、現状大分早くできたので、とりあえず作りを簡単にする方を優先しました。 課題の中で最も大きな問題は、ログが見辛いという点です。 ECSはログを準リアルタイムで確認するのが、かなり難しいという
RSpecのフォーマッターの出力結果を任意のデータストアに保存できるgem rspec-storageを作った - Qiita
最近、手元でRSpecを全部流すなんてことはあんまり無くなってきた。 CIサービス上で結果は確認できても、色々情報を収集したり加工したりしたい場合ローカルのファイルシステムに吐くより、S3とかGCSとかに吐ける方が何かと便利なことが多い。 というわけで、gemで何とかしてみた。 https://github.com/joker1007/rspec-storage RSpec自体にこういう処理を差し込めるAPIが無いので、出来るだけメンテしやすい形でモンキーパッチを当てている。 こんな感じで使う。(GCSの場合はgs://) $ rspec -r rspec/storage spec/example_spec.rb -f doc -f json -o s3://your-bucket/spec_result.json パースして加工することを前提にするならjsonフォーマットで吐いておくのが
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
開発しやすいRails on Docker環境の作り方 - Qiita
最近、Rails界隈でDocker使い始めました、という話を聞く機会が増えてきたので、自分が開発環境整備用に構築したDockerの設定をまとめておく。 ちなみに、production運用については以前書いたので適当に探してくださいw 結論から書いておくと、volumeをちゃんと活用すればいい、ってだけの話です。 まず、本番用と開発用のDockerfileは分けた方が良い。一つでやろうとするとどうにも無理がでるので。 自分はDockerfileとDockerfile-devというものを用意している。 docker-composeはほぼ必須です。少なくともrailsプロセスとDBだけでも二つは必要だし、Dockerfileを分けてると事故るので。 Dockerfileはこんな感じ。 FROM mybase:ruby-2.3.1-debian RUN echo "deb http://http.
YAML生成を工夫してembulkの設定ファイルを使い易く - Qiita
embulk meetupの後にsonots先輩に何か書いてくださいよーって言われたので、 embulkに限った話ではないのですが、関連する話題なのでEmbulk Advent Calendarに書かせてもらおうと思います。 embulkは設定ファイルがYAMLです。 現時点ではテンプレート機能はまだ限定的な機能しかなくて、それ程表現力がありません。 それならもう、YAMLの生成を別に任せようと思って簡単なgemを作りました。 joker1007/yaml_master YAMLの設定ファイルの大本になるマスターファイルを作っておいて、そこから特定の範囲だけを別のYAMLとして出力するだけのgemです。 その際にerbでRubyを埋め込めるようにしているので、Rubyで表現できることは何でもできます。 環境変数から日付を取ってそれをRangeにしてループしたり、ActiveRecordから
embulk bundleだけでJavaで書かれたプラグインをインストールし利用する方法 - Qiita
以前embulkのjava pluginをbundlerっぽくgithubからインストールして実行できるラッパーを作った - Qiitaという記事を書いた。 要はJava製のプラグインをgithubから直接インストールしてリリース前のものを使いたいというものだ。 で、コマンドをラップするgemを作ってみたのだが、DSLの挙動をちゃんと制御するのは面倒だしコマンドをラップするのは色々とポータビリティが悪い。 しかし、ある時天啓が降りてきた。 「Bundlerを弄ればいいや」と。 で、ソースコード読んで、gemspecの判別がどうなってるのかとモンキーパッチを当てるのにちょうど良い場所を探して試してみた所、とてもシンプルなハックで上手くいった。 Gemfile上でBundlerにモンキーパッチを当てるというダーティさに目を瞑れば割と便利ではないだろうか。 こんな風に書く。 require 'b
production環境でRailsアプリをdockerコンテナとしてECSで運用するために考えたこと - Qiita
実際には、まだ本当の本番環境では運用できてなくて開発用のステージングで運用が開始できたぐらいで、他にもやること一杯あるんだけど、ある程度知見が溜まったのでまとめておく。 ちなみに、規模はそんなに大きくないがデータ量は多いアプリケーションで運用環境はAWSのECSを想定しており、現時点で普通のEC2ノードとコンテナで並行稼動している。 docker-swarmなりで自前でコンテナプールを構築してもいいのだが、そうするとサービスディスカバリとか考えなければいけないことが増えるので、後回しにしている。 (注: かなりサービス固有の事情が含まれるため、もし参考にされる方が居たとしても、そのままの形では適用できない可能性が高い) 追記: RailsアプリのためのDockerfileとdocker-compose.ymlのサンプル - Qiita コンテナ化のモチベーション CentOSのお守りからの
Ruby製のシンプルなワークフローエンジンRukawaの紹介 - Qiita
Bigqueryを使ったバッチジョブを色々と実行しているのですが、Rakeで複雑な依存関係を管理したり、並列実行させたりするのが辛くなってきたのでRukawaというワークフローエンジンを自作しました。 自作したのは、RailsプロダクトにAirflowとかLuigiとかAzkabanとか入れるにはちょっと重厚過ぎる感じだったのと、Rubyで書ける方が楽で良いやという理由からです。 RukawaとはRUby KAntan Workflow Assistantの略です(後付け) (本当はミッチーとか水戸の方が好きなんだけど良い名前が浮かばなかった) 実際は、並列実行を可能にして書き方を変えてみたRakeとそんなに大差無い。 Rukawaの機能 ジョブの定義 まず実行したい処理をジョブクラスに記述します。 module ExecuteLog def self.store @store ||= {
Railsのurl_forを30%高速化するgemを作った - Qiita
まあ、タイトルは若干釣りで、特定のユースケースにおいて3割程度の高速化が見込める、というだけです。 joker1007/curl_escape: This gem provides fast URL escape by libcurl. 以下、実装経緯。 Railsのurl_forを辿っていくと、最終的にクエリパラメーターとして渡したハッシュやらArrayやらに対して、Object#to_queryを発行します。 このObject#to_queryの実装は、ほぼCGI.escapeの実行です。 やたらとlink_toの数が多くて、クエリパラメーターをそれなりに渡している、というページを表示しようとすると、割とこの処理時間が馬鹿にならない感じになってきます。 ということで、CGI.escapeを早くすれば、ちょっとはマシになるんじゃないかと思いました。 しかし、CGI.escapeの実装をR
EmbulkでMySQLからBigQueryに入れ子になったJSONファイルを直接インポートする方法 - Qiita
{"id": 1, "nickname": "joker1007", "comments": [{"id": 1, "body": "comment body"}, {"id": 2, "body": "next comment"}] SELECT CONCAT( '{', '"id":',users.id, ',"nickname":',IF(users.nickname, CONCAT('"', users.nickname, '"'), "null"), ',"comments":',CONCAT('[', GROUP_CONCAT((CONCAT('{"id":', comments.id), CONCAT(',"body":"',comments.body,'"}')), ']'), '}' ) AS payload FROM users INNER JOIN comments
Rubyのコードを読むのが捗る技 (Vim) - Qiita
Rubyでソースコードを読む時の小技について書いてみようと思う。 この投稿も参考になる。 Rubyでメソッドの定義場所を見つける方法 #Ruby - Qiita http://qiita.com/items/fc8a61b421d026a23ffe ちなみに、私はVimmerなので、Vimに寄った話です。 emacsについては身近にemacsユーザーに聞きましょう。 ctagsを活用する ctagsでtagsファイルを出力しておけば、メソッドの定義元に飛ぶのが非常に楽になります。 Railsで開発しているなら、Railsのプロジェクトルートで以下のようなコマンドを打ちます。 (bundlerでプロジェクト内にGemがある場合を想定) langmapとかは別に無くても大丈夫だと思いますが。 --excludeを付けずにctagsを実行するとjavascriptのライブラリもタグ付けされて、
[小ネタ]実はRubyのブロック引数受け取りにキーワード引数が使える - Qiita
今更ながらブロック引数の受け取りにキーワード引数が使える事に気付いた。 よくよく考えるとブロック引数の受け取りはメソッドの引数受け取りと同じ処理してるんだから、メソッドの定義で使えるものは基本的に使えるはずで、至極当たり前の事といえばその通りなのだが……。 (自分は今日意識するまで気付いてなかった……) だからこんな感じで書ける。 [23] pry(main)> [{hoge: "fuga", foo: "bar"}].each do |hoge:, foo:| [23] pry(main)* puts hoge [23] pry(main)* puts foo [23] pry(main)* end fuga bar
![[小ネタ]実はRubyのブロック引数受け取りにキーワード引数が使える - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/40e49cbb4d1aa83d3fac96f9ea68ca8d36e248e2/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU1JUIwJThGJUUzJTgzJThEJUUzJTgyJUJGJTVEJUU1JUFFJTlGJUUzJTgxJUFGUnVieSVFMyU4MSVBRSVFMyU4MyU5NiVFMyU4MyVBRCVFMyU4MyU4MyVFMyU4MiVBRiVFNSVCQyU5NSVFNiU5NSVCMCVFNSU4RiU5NyVFMyU4MSU5MSVFNSU4RiU5NiVFMyU4MiU4QSVFMyU4MSVBQiVFMyU4MiVBRCVFMyU4MyVCQyVFMyU4MyVBRiVFMyU4MyVCQyVFMyU4MyU4OSVFNSVCQyU5NSVFNiU5NSVCMCVFMyU4MSU4QyVFNCVCRCVCRiVFMyU4MSU4OCVFMyU4MiU4QiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9OWEwYzVlZjFmMGM4MDI5ZjI0MDJiOTc4MzVhNDFhY2Q%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBqb2tlcjEwMDcmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTFjYzBhZjE1ODg5ZDNkMGUzMDYzNDdkOWIzNGIyZDY5%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gUmVwcm_moKrlvI_kvJrnpL4%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Dedb4cc95e1b4f588092e7f2b5b0f9151)
そろそろポリモーフィック関連について一言いっとくか - Qiita
class Notification < ActiveRecord::Base belongs_to :notifiable, polymorphic: true end class Message < ActiveRecord::Base has_one :notification, as: :notifiable end class Like < ActiveRecord::Base has_one :notification, as: :notifiable end 一行で色んなクラスに対する関連が指定できて便利感がある。 だからって、これを安易に使う前にちゃんと考えよう。 ポリモーフィック関連は単に関連の定義を省力化するためのものじゃない。 ポリモーフィックという名前が示す様に、これは多態性を持ったものに対する関連を定義する事であって、インターフェースに対する関連の定義だということ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
rails_adminをカスタマイズする方法まとめ - Qiita
RailsアプリのためのDockerfileとdocker-compose.ymlのサンプル - Qiita
