はじめに 自分が rails をさわり始めたときはバージョン1からバージョン2に変わるあたりだったのですが、バージョン2が出た年を振り返るとなんと2007年でした。 月日の流れが速い事に驚く中、早く知ってたら良かったのになぁって事をつらつらとまとめてみました。 最近 rails さわり始めてみたよ！って方の参考になれば良いなと思います。 今回は便利な gem とかではなく、素のrailsで出来ることを挙げています。 ちなみにバージョンは以下の環境です。 About your application's environment Ruby version 2.1.3-p242 (x86_64-darwin14.0) RubyGems version 2.2.2 Rack version 1.5 Rails version 4.1.8

Ruby Advent Calendar 11日目 Ruby - Rails開発で有用な便利Gem一覧：2013年版 - Qiita ↑去年のAdventCalendarで書いた上記の記事の2014年版です。 だんだん毎年恒例的になって来ました。 最近はデファクトスタンダードがほぼ固まってきて、かなり毎回使うGemのリストが固定化して来ました。 ※2014/12/11時点 DBアダプタ sqlite3 pg mysql2 この辺りはもう変わらないですね。 RubyやRailsのバージョンが上がっても継続的に開発が続けられているのは素晴らしいと思います。 ログイン認証 omniauth omniauth-twitter omniauth-facebook omniauth-github omniauth-identity (omniauth-githubのリポジトリのURLが変わってました。

すいません。締切守れませんでした…。 やっぱ、java-jaの忘年会の翌日は辛い…。 はじめに Webシステムを開発していると切っても切れないのがJavaScriptです。 Railsはかなり早い時期からalt-JSや結合、minify等を組み込めるようにフレームワークにそれを取り入れてきました。 それを支えているのがRails3.1から導入されたsprocketsです。 それに伴なってJSのライブラリをどうやって管理するかという点について、独自の路線を取ることになりました。 JSのライブラリを同梱したgemパッケージにラップしてrubygemsとして管理する方法です。 ある程度は上手くいっていたし、今もその流れは続いているんですが、時々問題になることもあります。 例えばメンテナの対応時期がズレてて古いバージョンのままだったり、似たようなgemが乱立してややこしくなったり。(backbon

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 の設定を書きたい 管理画面付

Slides for Rails Israel 2014 talk "Is Rails Slow?" http://railsisrael2014.events.co.il/

インフラストラクチャー部の成田（@mirakui）です。 Rails の OR マッパーである ActiveRecord ですが、みなさんどのように運用していますか？ ActiveRecord を使うと、 SQL を直接扱うことなく、抽象化された表現で RDB にアクセスできるので、アプリケーションの開発効率という観点ではメリットが大きいです。 一方で、 ActiveRecord が駆使されているアプリケーションをサーバに配置してプロダクションとして運用する立場からすると、いくつかの問題に突き当たります。 まずはクックパッド本体アプリケーションにおける、最新の rake stats をご覧ください。 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC

本当は、RubyWorld Conf辺りでこういう内容も交えてなんか話せればいいなあと思ってたんだけど、CFPに落ちたのでQiitaにポエムを書いてみました。 Railsはそれなりに学習コストはかかりますが、慣れてくるとデフォルトで便利なものが揃ってるしサードパーティライブラリも豊富で、未だに最も便利なWebアプリケーションフレームワークの一つだと思います。 なので、最近のスタートアップ界隈ではRailsで開発をスタートする、という話をよく耳にします。(個人の感想です) しかし、Railsは本体に新しい要素をガンガン取り入れてくるので、バージョンアップのサイクルはかなり早く、それに追従していくのはそれなりに大変です。 Railsで開発をする場合には、一旦レールに乗ったらプロダクトが死ぬまで走り続ける覚悟が必要です。(時速60km以下になったら爆発する) それを最初に理解しておかないと、あっ

Ruby on Railsというフレームワークを使うとrails new Hogeとかでアプリケーションのひな形ができちゃって、rails serverでサーバーが立ち上げられたりするわけですが、これは一体どうなってるんだというのを追っていけたらなと思います。誰にでもわかるように書きたいです。今回こそはくじけずに書ききりたい。 railsとbin/railsの違い railsはシステムにインストールされたrailsコマンドを呼ぶ（/Users/ユーザー名/.rbenv/shims/railsみたいな）。 bin/railsはそのプロジェクト下のbin/railsのコマンドを呼ぶ。 bin/rails Railsプロジェクトを作ると、binというディレクトリの中にrailsというファイルがある。これをエディタで開いてみる。 $ vim bin/rails 中身はこんな感じ。 #!/usr/b

ActiveRecord4でこんなSQLクエリどう書くの？ Merge編 では、関連先のscopeを使うことができるmergeを紹介しました。mergeを使う事で、変更に強いクエリを美しく組み立てることができました。 今回は、ActiveRecord4で書きにくいSQLクエリたちを紹介します。 書きにくいクエリとは、具体的には以下のものがあげられます。 比較演算ORlikeleft outer joinunionサブクエリexists ActiveRecordでこれらのクエリを組み立てる場合、どうしても美しくない（SQL文字列をべったり書いてしまうような）書き方となってしまいがちです。 この処理を美しく書くためには、ActiveRecordだけの機能では足りず、ActiveRecordが内部で使っているArelというライブラリを使う必要がでてきます。 今回は、Arelを使って華麗にSQLク

ActiveSupportによる既存Rubyクラスの拡張は人間をダメにするんじゃないかと思いますが、知っていると周りのプログラマに差をつけられるテクニックが満載だと思います。今回はHashの拡張メソッドの話。 よくあるコード some_hash = { key_a: "some content", key_b: "some content", key_c: "some content" } # :key_aと:key_bを取り出したい some_hash.select{|k, _| %i(key_a key_b).include? k} #=> {key_a: ..., key_b: ...} # :key_cを除外したい some_hash.reject{|k, _| k == :key_c} #=> {key_a: ..., key_b: ...} some_hash = { key_

[2014/07/03追記] Rails4.0以上ならadd_reference使えばOK. [追記終わり] Stack Overflowに全く同じ状態の投稿があったのでその通りにして解決. 一応こちらにも書いておく. 現象 次のようにreferencesを指定してmigrationファイルを生成したとき, rails g migration AddUserCategoryToUsers user_category:references class AddUserCategoryToUsers < ActiveRecord::Migration def change add_column :users, :user_category, :references, :default => 1 end end db:migrateに失敗する. rake db:migrate == AddUser

はじめに dockerでrailsを動かす場合にどうするのが良いかなーと試行錯誤し、構成も落ち着いてきたのでまとめます。 お試しバージョン 一番最初はとりあえずってことで、railsリポジトリ + railsを動作させるコンテナの組み合わせで試してみました。 Dockerfileの内容 FROM base # rubyインストールに必要なパッケージを用意 RUN apt-get update RUN apt-get install -y --force-yes build-essential curl git zlib1g-dev libssl-dev libreadline-dev libyaml-dev libxml2-dev libxslt-dev # rbenv, ruby-buildをインストール RUN git clone https://github.com/sstephen

結論: Javascriptの乱用をやめるのが一番。 はじめに書いておきますがしょうもない話です。 結論、開発者としてはどのような方向性でやるべきか、を書いています。 JS多い時代でのフレームワークの根本的な問題云々のことは書いてません。 さて、現状、モバイルにおいて、Javascriptでまともに動くものを作ることは難しいです。 Twitterから引き抜いた超優秀なWebエンジニアを多数抱えるMediumですら、未だにモバイルで多数のバグを抱えています。 超優秀なエンジニアを世界一抱えているであろうGoogleのGmailですら、モバイル版のWebはすぐクラッシュします。また、自前スクロールに致命的なバグも抱えています。 正確には「UIが不審な挙動をする」ですが、エンドユーザにとっては同じことで、「バグ」です。 サーバサイドで起こるバグと同じ程度、いやそれ以上に、サービスに影響を与えます

File: SIGNALS [Unicorn: Rack HTTP server for fast clients and Unix] の一部を超訳しただけ