- Dynamic Dispatch
- Dynamic Method
- Ghost Methods
- Dynamic Proxies
- Blank Slate
- Kernel Method
- Flattening the Scope (aka Nested Lexical Scopes)
- Context Probe
- Class Eval (not really a 'spell' more just a demonstration of its usage)
- Class Macros
source 'https://rubygems.org' | |
gem 'rake' | |
gem 'lotus-router' | |
gem 'lotus-controller' | |
gem 'lotus-view' | |
group :test do | |
gem 'rspec' | |
gem 'capybara' |
require 'faraday' | |
require 'forwardable' | |
module Soup | |
class Agent | |
extend Forwardable | |
def initialize(domain = 'https://www.soup.io/') | |
@agent ||= faraday(domain) | |
end |
Originally published in June 2008
When hiring Ruby on Rails programmers, knowing the right questions to ask during an interview was a real challenge for me at first. In 30 minutes or less, it's difficult to get a solid read on a candidate's skill set without looking at code they've previously written. And in the corporate/enterprise world, I often don't have access to their previous work.
To ensure we hired competent ruby developers at my last job, I created a list of 15 ruby questions -- a ruby measuring stick if you will -- to select the cream of the crop that walked through our doors.
Candidates will typically give you a range of responses based on their experience and personality. So it's up to you to decide the correctness of their answer.
class MyJob < ActiveJob::Base | |
queue_as :urgent | |
rescue_from(NoResultsError) do | |
retry_job wait: 5.minutes, queue: :default | |
end | |
def perform(*args) | |
MyService.call(*args) | |
end |
Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
- Follow standard conventions.
- Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
- Boy scout rule. Leave the campground cleaner than you found it.
- Always find root cause. Always look for the root cause of a problem.
module Storage | |
module Models | |
class Brand < ActiveRecord::Base; end | |
end | |
end |
class LinkedList | |
class Node | |
attr_accessor :next, :data | |
def initialize data | |
self.data = data | |
self.next = nil | |
end | |
end | |
attr_accessor :head, :tail, :length |
Method lookup is a simple affair in most languages without multiple inheritance. You start from the receiver and move up the ancestors chain until you locate the method. Because Ruby allows you to mix in modules and extend singleton classes at runtime, this is an entirely different affair.
I will not build contrived code to exemplify the more complicated aspects of Ruby method lookup, as this will only serve to confuse the matter. If you are having trouble following method lookup in your own programs, it is not because Ruby has strange rules (it does), it is because your code is too tangled.
When you pass a message to an object, here is how Ruby finds what method to call: