JuanitoFatas

<snippet>
  <content><![CDATA[
Upgrade rails from ${1:old_version} to ${2:new_version}.

- Updated: [rails](http://github.com/rails/rails), [${1:old_version}...${2:new_version}](https://github.com/rails/rails/compare/v${1:old_version}...v${2:new_version})
- Updated: actionmailer, ${1:old_version}...${2:new_version} ([CHANGELOG](https://github.com/rails/rails/blob/v${2:new_version}/actionmailer/CHANGELOG.md))
- Updated: actionpack, ${1:old_version}...${2:new_version} ([CHANGELOG](https://github.com/rails/rails/blob/v${2:new_version}/actionpack/CHANGELOG.md))
- Updated: actionview, ${1:old_version}...${2:new_version} ([CHANGELOG](https://github.com/rails/rails/blob/v${2:new_version}/actionview/CHANGELOG.md))
- Updated: activejob, ${1:old_version}...${2:new_version} ([CHANGELOG](https://github.com/rails/rails/blob/v${2:new_version}/activejob/CHANGELOG.md))
- Updated: activemodel, ${1:old_version}...${2:new_version} ([CHANGELOG](https://github.com/rails/rails/blob/v${2:new_version}/activemodel/CHANGELOG.md))

dbalatero

This is an example of how I combine interaction/service classes with Wisper event broadcasting in Rails.

In this example, I show a UsersController#create API, a corresponding service object, and all the test code/listeners to make it all happen.

The outcome is:

• Concepts in your system ("Signing up a user", "Creating an order") have a single entry point in your codebase, vs. making raw ActiveRecord calls to object.save in dozens of places.
• Since your concept has one entry point (the service class), you can easily grep for usage of it.
• Stupid easy to attach listeners to the service class
• All event listeners are very small and easily unit tested

Joseph-N

// turbolinks addthis
var initAdthis;

initAdthis = function(){
    // Remove all global properties set by addthis, otherwise it won't reinitialize
    for (var i in window) {
        if (/^addthis/.test(i) || /^_at/.test(i)) {
            delete window[i];
        }
    }

jodosha

Gem::Specification.new do |s|
  s.name        = 'lotus-sinatra'
  s.version     = '0.1.0'
  s.platform    = Gem::Platform::RUBY
  s.author      = 'Luca Guidi'
  s.email       = '[email protected]'
  s.summary     = 'Building Sinatra with Lotus'
  s.description = 'A step by step guide about how use Lotus to build Sinatra'
  s.homepage    = 'http://bit.ly/1e4e58T'
  s.license     = 'MIT'

teohm

rAndom ruBy tiPs >>--(o_0)-->

afeld

Updated for Rails 4.0.0+

Bower

1. Set up the bower gem.

2. Follow the Bower instructions and list your dependencies in your bower.json, e.g.

   // bower.json

{

adamhjk

# A sample Guardfile
# More info at https://github.com/guard/guard#readme

require 'guard/guard'
require 'mixlib/shellout'

module ::Guard
  class Kitchen < ::Guard::Guard
    def start
      ::Guard::UI.info("Guard::Kitchen is starting")

adstage-david

I recently got PATCH mostly working with Backbone and Rails 3, here's what I needed to do.

Sticking Points:

1. [Rails] JSON Patch gem needs updated.
2. [Rails] Routing verb for patch missing - I believe this is fixed in Rails 4, haven't investigated.
3. [Rails] Need to parse the 'application/json-patch+json' content type in sort of a crazy way
4. [Rails] Building a patch and applying it to an activerecord model is kind of a pain, ideally we'd have a ActiveModel#apply_patch(json_patch)
5. [Backbone] Building a patch from a set of attributes is tricky - I've done the bare minimum using a loop over a hash to build add operations, which should probably cover a good chunk of cases for backbone. (I imagine most people aren't going to need the json-patch support for moving, copying or deleting keys generally.)

justsee

#!/bin/bash -e

export RBENV_ROOT=/usr/local/rbenv
export PATH=/usr/local/rbenv/shims:/usr/local/rbenv/bin:/usr/local/bin:"$PATH"

APP="<%= @options[:app].application.name %>"
APP_PATH="<%= @options[:app].path %>"
RAILS_ENV="<%= @options[:rails_env] %>"
UNICORN_CONFIG="/etc/unicorn/${APP}.rb"
CUR_PID_FILE="${APP_PATH}/shared/pids/unicorn.pid"

czarneckid

Zero downtime deploys with unicorn + nginx + runit + rvm + chef

Below are the actual files we use in one of our latest production applications at Agora Games to achieve zero downtime deploys with unicorn. You've probably already read the GitHub blog post on Unicorn and would like to try zero downtime deploys for your application. I hope these files and notes help. I am happy to update these files or these notes if there are comments/questions. YMMV (of course).

Other application notes:

• Our application uses MongoDB, so we don't have database migrations to worry about as with MySQL or postgresql. That does not mean that we won't have to worry about issues with the database with indexes being built in MongoDB or what have you.
• We use capistrano for deployment.

Salient points for each file: