Look at LSB init scripts for more information.
Copy to /etc/init.d
:
# replace "$YOUR_SERVICE_NAME" with your service's name (whenever it's not enough obvious)
# autoload concerns | |
module YourApp | |
class Application < Rails::Application | |
config.autoload_paths += %W( | |
#{config.root}/app/controllers/concerns | |
#{config.root}/app/models/concerns | |
) | |
end | |
end |
# yes, sometimes you need to do this. you get pilloried in a forum if you | |
# ask about it, though! | |
# this code taken from | |
# http://wholemeal.co.nz/blog/2011/04/05/rendering-from-a-model-in-rails-3/ | |
class MyModel < ActiveRecord::Base | |
# Use the my_models/_my_model.txt.erb view to render this object as a string | |
def to_s | |
ActionView::Base.new(Rails.configuration.paths.app.views.first).render( |
Look at LSB init scripts for more information.
Copy to /etc/init.d
:
# replace "$YOUR_SERVICE_NAME" with your service's name (whenever it's not enough obvious)
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.
source :rubygems | |
# We are not loading Active Record, nor Active Resources etc. | |
# We can do this in any app by simply replacing the rails gem | |
# by the parts we want to use. | |
gem "actionpack", "~> 4.0" | |
gem "railties", "~> 4.0" | |
gem "tzinfo" | |
# Let's use thin |
git branch -m old_branch new_branch # Rename branch locally | |
git push origin :old_branch # Delete the old branch | |
git push --set-upstream origin new_branch # Push the new branch, set local branch to track the new remote |
I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!
\
Picking the right architecture = Picking the right battles + Managing trade-offs
module Amura | |
class SidekiqManager | |
# a datastructure to maintain queue meta data. the structure of which is {host_name: {queue_name:{min:1,max:1,conc:10,latency:1,queue_size:10,kill_idle:-1, tags:['default'], total_checks:1,current_check:0}}} | |
# host_name - name of the machine where its running. useful in a distributed environment where app is running on mulitple instances | |
# queue_name - name of the queue (which you can mention in the sidekiq worker as sidekiq_options :queue => :mailer ) | |
# min: minimum number of processes required to process this queue on this machine. | |
# max: maximum number of processes permitted to process this queue on this machine. a upper limit to avoid memory overflow and unlimited process spawning. | |
# conc: concurreny (number of worker threads) for each of the processes. this is -C option given while booting up sidekiq. | |
# latency: this is the default safe latency which is permissable for this queue. anything beyond this will trigger new p |