git clone [email protected]:YOUR-USERNAME/YOUR-FORKED-REPO.git
cd into/cloned/fork-repo
git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
git fetch upstream
# autoload concerns | |
module YourApp | |
class Application < Rails::Application | |
config.autoload_paths += %W( | |
#{config.root}/app/controllers/concerns | |
#{config.root}/app/models/concerns | |
) | |
end | |
end |
git clone [email protected]:YOUR-USERNAME/YOUR-FORKED-REPO.git
cd into/cloned/fork-repo
git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
git fetch upstream
Dear Rubyists,
I just lost a contract because of my code in a Rails project.
The specific code in question is related to a "posting a comment" feature. Here are the details:
In this project, "posting a comment" does not simply entail inserting a row into the database. It involves a procedure to yes, insert a row, but also detect its language, check for spam, send emails, and "share" it to Twitter and Facebook. I believe this algorithm should be encapsulated. I do not believe it belongs in a controller or a model. I do not believe Active Record callbacks should be used.
The "senior developer", whom is the stake holder's right hand man, said this:
class ActiveRecord::Base | |
mattr_accessor :shared_connection | |
@@shared_connection = nil | |
def self.connection | |
@@shared_connection || ConnectionPool::Wrapper.new(:size => 1) { retrieve_connection } | |
end | |
end | |
ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection |
In this article, I'll walk through a basic Rails (3.2.x) setup for creating a nested resource for two models. Nested resources work well when you want to build out URL structure between two related models, and still maintain a RESTful convention. This code assumes you are running RVM to manage Ruby/Gem versions, and Git for version control.
$ mkdir family # create rvm gemset
$ echo "rvm use --create ruby-1.9.2@family" > family/.rvmrc
$ cd family # install rails
$ gem install rails # create new rails project
$ rails new . # version control
In researching topics for RailsCasts I often read code in Rails and other gems. This is a great exercise to do. Not only will you pick up some coding tips, but it can help you better understand what makes code readable.
A common practice to organize code in gems is to divide it into modules. When this is done extensively I find it becomes very difficult to read. Before I explain further, a quick detour on instance_eval
.
You can find instance_eval
used in many DSLs: from routes to state machines. Here's an example from Thinking Sphinx.
class Article < ActiveRecord::Base
tap "caskroom/cask" | |
cask "google-chrome" | |
cask "firefox" | |
brew "chromedriver" | |
brew "geckodriver" |
#!/usr/bin/env ruby | |
# frozen_string_literal: true | |
# README | |
# - gem install git | |
# - Update the ticket prefix | |
# - Update the branch name | |
# - Put this in /usr/local/bin and chmod +x it | |
require 'git' |