RVM is super easy to use, and it manages Ruby Gems well. Most of the Ruby/Rails projects I work on are using its Gemset feature.
I was running RVM version 1.6 and decided to perfom and upgrade.
Second command from above is extremely useful. As per example above, it updates my local Ruby 1.9.2-p180 to 1.9.2-p290. All gemsets associated with the 1.9.2-p180 are also relinked to the new 1.9.2-p290. Handy!
We store configuration strings in YAML files. It’s common that we need to substitute part of the string with runtime values. Hence we introduce some kind of placeholders in the config strings. Given an example that our application may need to hit an external URL to retrieve some remote resources at runtime. To do this, we could make a config string in our application’s config YAML file like this
Then in our code, we substitute “RESOURCE1” and “RESOURCE2” with the real resource names we require. In my early days of programming in Ruby, I used some very ordinary string substitution method like this
It works, but I don’t really like it… So I found something better, that is to use Ruby’s string interpolation methods
A lot nicer, but still can be better. Thanks to a colleague of mine, Aleksey Gureiev, another more elegant way can be used
Most of applications require application configuration files. The Rails applications I worked on pretty much all require an initialiser (or should it be the Rails convention initialiZer) to load a configuration YAML file. I’m aware that there are gems out there providing this kind of configuration solutions, such as SettingsLogic. For a simple problem like this one, I think we could roll our own too (oh, the not invented here syndrome).
The codebase I worked on typically has an initialiser called load_config.rb. It’s got something like this
Easy and good. There’s one more thing I’d love to add to this. I’d love to have a local config file, config.local.yml, that can overwrite config values defined in the config.yml. And this config.local.yml is not source controlled, means every developer can make tweak the configs to tailor to their own development environment without needing to touch the source controlled configuration file, config.yml.
To do this, just add the following block of code to the load_config.rb
I’m recently asked what my recent technology excitement is, of course in the context of programming. The name of Heroku came into my mind instantly. I’ve been using Heroku for all my Rails based applications recently. I’m amazed how easy it is to deploy and scale (to a degree) applications on to Heroku.
Heroku’s default way of running background jobs is using the delayed_job Ruby gem, which essentially records background jobs into a database table. And on Heroku, you can start a worker to monitor and process the job queue. This involves a lot of database polling as you could imagine.
So, in one of the applications I’m working on, I tried something more elegant (in my opinion). Github uses a Ruby gem called Resque for their background jobs.
Resque uses a Redis based backend to store queued jobs, so it's fast in job logging and job retrieving.
Resque allows you to separate jobs into different queues, so everything becomes better categorised.
Resque also provides a Sinatra based web interface to monitor all jobs including failures, so better monitoring and better debugging.
All good. I also opted to use a Resque plugin called resque-heroku-autoscaler. This allows me to dynamically scale the number of Heroku workers up and down base on the jobs recorded in the queue. Since Heroku charges on worker usage, so with this auto scaler, I only pay for what’s used.
As for the implementation, it’s scattered across many files. Here’s my implementation, which handles the delivery of welcome emails upon membership creation.
I’ve started my “senior” developer role in doing Ruby on Rails projects for a bit over 2 months. Reason I quoted the “senior” bit is that I’m really a newbie to it. I guess the seniority is more about general web based application development rather than RoR. Having said that, RoR isn’t that foreign to me at all. I started studying it a year ago. However my self-study doesn’t compensate my lack of real world working experience. In the past 2 months, lots of ideas and knowledges are exchanged between me and my peers. I learnt a lot of Rails of course. And I believe I have also contributed some non-rails thinking into the Rails project.
2 months in, I learnt that Rails is moden and rapid in doing web development (I absolutely love it). However it’s convention over configuration nature sometimes dictates the way developers think too much. Somehow, developers’ creativities become canvased by Rails. You find yourself battling with routes, ActiveRecord models, DRY controllers a lot. The application architectural deliberating stage is somewhat overlooked, if not bypassed. Most of the time, this will lead to future potential problems, which could be security issues, scaling issues, performance issues or just tedious labour work in doing repetitive tasks.
As I’m still learning, what I believe now is that don’t let Rails control how you author software,
write non AR models to describe your domain if required
use service layer classes to encapsulate business logic if it makes sense
off load long running, non critical tasks to a job queue (loving the resque gem now) when it's appropriate
the list goes on
Let Rails help you instead,
use its powerful command line tool
utilise its ecosystem, all those wonderful gems
make a use of its RESTful controllers, exposing API is never as easy as before
look into it's respond_to feature, making your RESTful API respond to XML, json, or whatever is made super easy
the list goes on
To summarise, the basic software engineering practices apply to Rails or non Rails applications the same way.
Bend the rails to let your train reach it’s destination. Expect more Rails related posts from now on.