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' |