(The) Bundler

Touted by its developers as "the best way to manage your application's dependencies", Bundler is one of the most often used tools in Ruby/Rails developer's toolbox. As usual, this tool too has a "lifecycle" of its own (the steps to be followed from initialization of the tool parameters, the current usage, and - where the case - the closing/termination of the process).

So, for Bundler, the relevant steps are as follows:


1. Installation

First of all, in your project directory, you should have a Gemfile file, which contains all the gems needed by your application (each gem is declared with a line lilke gem 'gemname'  - but much more complex options are available - such as requiring an exact version of the gem, a minimal version of the gem, creating groups of gems which are loaded selectively, etc.)

Then, run (I assume the gem installation was already done with gem install bundler):

    bundle install

Now, there are two cases:

a. If in your project directory there isn't a Gemfile.lock file, this will be created. Basically, the Bundler looks for all needed gems dependencies, and creates the .lock file which contains ALL the gems needed for your application to run properly. This case is actually meaning that you are the author of the application, you already have the gems installed on your machine, and want the rest of the world know what they should have in order to run it successfully.

b. If in your project directory there is a Gemfile.lock, then the Bundler will look for all needed/declared gems and will install them (from the source declared in the Gemfile, typically source 'https://rubygems.org'). This case is actually meaning you have downloaded/cloned the application from somewhere else, and now you want to prepare your Ruby environment in order to run properly.

An interesting version of the command (very often used) is:

    bundle install --without production

Which actually tells the Bundler to install ALL the gems, BUT the ones declared in the production group (useful if we think that, for instance, we may want for production to use PostgreSQL, which we may even not have installed on our machine).


2. Checking and updating

In order to see the current state of affairs with your installed gems, you can:

    bundle check (that will tell you whether or not the requirements for your app are met)

    bundle show (similar to bundle list, it will tell you what are the gems and versions actually used)

    bundle outdated (self-explanatory, I guess...)


In order to update the gems installed, run:

    bundle update


3. Running gem-related commands using the bundler

First, the command:

    bundle exec command

Now, the rationale: imagine that you carefully build an application using version x of a gem - only to find out that there is a new, better version y of the gem (we assume no RVM, more about this in a future post). You update the gem (with gem update [gemname], as indicated in a previous post). All well, only to find out that your app stopped working with the new gem version.

In order to avoid such unpleasant situations, many gems have a self-control which prevents them from being used on a wrong version (instead of running, they will issue a "command_name aborted" warning. In order to make sure you use the command with the exact version of the gem that is required by your app environment, one has to prefix the command with the bundle exec.

The end result can look discouraging to newbies (yes, I've been there...) which sometimes feel they have to read from a book of spells in order to make Ruby/Rails work. Something like this:

    bundle exec rake db:seed

(I haven't said yet anything about rake, but this is going to happen soon enough :-)).


4. Oh, and I almost forgot:

    bundle help


Web reference: http://gembundler.com/

On-the-fly reloading for Sinatra

Unlike Rails, Sinatra does not provide out of the box an option to reload the files on-the-fly (an option more than useful for the developer tinkering with the pages/files many many times before the final version).

The typical answer to this is "use Shotgun". That's all nice, but... not if you are (like I am) a happy user of a Windows box... Shotgun doesn't fly on these boxes, and in order to make it run one ought to fiddle quite a lot in Shotgun's source files.

The solution for us, Bill's loyalists, is Sinatra reloader. Initially an independent gem, it is now part of a mix of gems grouped under the title of "sinatra-contrib".

Knowing this, the steps to install/use the reloader are pretty simple:

1. gem install sinatra-contrib (in the command line)

2. require 'sinatra/reloader' (in the main app .rb file)

3. Simply run ruby filename.rb (forget about shotgun, you can simply uninstall it)

... and it will work like a charm, on the standard Sinatra port (4567), except now it will update when you modify the files, without restarting Sinatra...

As a side note, Sinatra reloader tends to work much better with thin (rather than WEBrick) as web server. Generally speaking, Sinatra was designed to run with thin... 

When gem install thin - then Sinatra will automatically start using it as web server. Now, of course, installing thin with windows raises other kind of headaches (it needs the development kit installed on the machine), but that's another story/post :-)

Gem lifecycle

As I have mentioned in a previous post, I will review the basic life-cycle of another Ruby tool - gem (full name RubyGems). It is hard to imagine how the plethora of "add-on" functionality (aka the gems) available for Ruby developers could be controlled without gem (more than 56k gems, downloaded more than 1.5 BILLION times to the latest count...). 

If with Rails things are somehow eased by "the bundler" (more about this in a next post), for plain old Ruby gem is THE tool (well, even Rails is typically installed as a gem...). So, let's start:

1. Installing a new gem

    gem install gemname

2. Uninstalling a gem

    gem uninstall gemname

3. Updating a gem to the latest version

    gem update [gemname]

Bear in mind the fact that the name of the gem is optional - if no gem is mentioned ALL the installed gems will be updated to the latest version.

Another interesting fact is that more than one version of a gem can be kept installed at one given time - it is up to the developer to choose what version of the gem he/she will use.

A more special version of the "update" is the one used to update the RubyGems itself:

    gem update --system

4. Checking the current status

One can use (typically) the "old-fashioned" version of

    gem list

or, in a more modern fashion, could start a mini-website providing info about the installed gems, their respective versions, and a brief explanation/description of the installed gems:

    gem server

5. And, as usual, the most important gem command

If you lose it, you can always try:

    gem help [topic]

Web reference: http://rubygems.org/

Tools of the trade

I've been asked by a friend what are the "screwdrivers" and the "hammers" in a Ruby and Rails developer toolbelt. Basically, here's the ones which can be found in mine:

• A fairly decent shell: I happen to work on a Windows box (that's why this is a problem :-)), so I prefer PowerShell. For Ubuntu or Mac, this problem auto-magically disappears... Talking about PowerShell, I strongly recommend you install Posh-Git in order to make sense of the git-related info available in your environment, as well as ANSICON, for getting colored information in your shell
• The text editor - Sublime Text 2 does everything I ever needed and a bit more than that. Here too, there are a number of packages that would make your life easier (first, you will need the Package Control itself, and then I have installed the CoffeeScript and Git packages)
• The core stuff - the ruby interpreter (and irb), as well as the rails command line (mostly the console)
• A GUI for SQLite - I use SQLite Expert Personal Edition
• The browser - I prefer Google Chrome with its built-in Developer Tools
• A number of "smaller", but crucially important tools for the normal dev cycle:
• git for version control (of course, when I said "small" I was kidding...)
• gem for ruby gems management
• the bundler for managing application dependencies
• heroku toolbelt for pushing the app to the cloud
• and, the ultimate "Swiss army knife", rake for a wide-range of admin commands

A few notes to the above:

• This is by no means a complete list of the Ruby and Rails applications landscape/ecosystem - I will try to sketch this particular picture in a future post (things like the web/app server stacks, the Ruby interpreters, the available IDEs, the tools used for TDD and BDD, frontend dev options, deployment tools, cloud options for Ruby and Rails developers etc.)

• I think the "smaller" tools are generally overlooked, but in fact due to poorly understanding them the beginner programmers end up spending countless hours with arcane error messages, when in fact the issues are simple/standard (yep, I've been there many times...). That's why I will have a series of posts for each of these tools, trying to explain the basic lifecycle and the most important commands for each of them (I have already did that for git, and the others will soon follow).

Best Ruby & Rails books

After reaching to 100+ books in my Ruby and Rails library, here are some hints about what the best books about Ruby & Rails might be (a matter of personal taste, of course):

0. General

• The Passionate Programmer (2nd edition), by Chad Fowler
• The Productive Programmer, by Neal Ford

1. Plain Ruby

• Programming Ruby (aka "The pickaxe book", 3rd edition), by Dave Thomas
• The Ruby Programming Language, by David Flanagan and Yukihiro Matsumoto (aka Matz)

2.a Plain Sinatra

• Jump Start Sinatra, by Darren Jones
• Sinatra Up and Running, by Alan Harris and Konstantin Haase

2.b Plain Rails

• Agile Web Development with Rails (4th edition), by Sam Ruby, Dave Thomas and David Heinemeier Hansson (aka DHH)
• Learning Rails 3, by Simon St. Laurent, Edd Dumbill and Eric J. Gruber

3. Advanced Ruby

• Design Patterns in Ruby, by Russ Olsen
• Eloquent Ruby, by Russ Olsen

4. Advanced Rails

• The Rails 3 Way, by Obie Fernandez
• Rails Antipatterns, by Chad Pytel and Tammer Sale

Web references:

http://pragprog.com/

http://oreilly.com/

http://www.sitepoint.com/

http://www.informit.com/

Basic git cycle

Here are the basic (very basic) steps one should take when using git and github for his/her projects. I am more or less intentionally ignoring the details of the more cumbersome matters regarding branching, resets, etc. More about these in a future post.

0. Concepts

Okay, so here it is (and I pray now to the gods of version management to forgive me for the simplistic explanations):

- we work with projects (which are basically files and directories grouped under one project directory)

- all the files and directories are tracked by git in a repository (or repo for short) - where each and every modification (adding/removing files, changes in the tracked file) is  monitored, but only when the changes are committed to the repo.

- each repo keeps track of the entire succession of the commits, and one could see (or even revert to) a previous commit state (no, we don't provide these below)

- moreover, one could "fork" a repo in multiple simultaneous states, by branching the repo (you won't find this below though; just for the future, although we won't be using it anywhere below, the current state of the current repo is referred to as HEAD)

- and finally, besides the local repo (the one in your computer) there could be many remote repos with which the local repo gets periodically synced (most notably, the github repo which is the default remote for most of us, and the one on heroku).


1. Creation

This can be done either by using a local project (all commands are in the project directory, unless specified otherwise):

    git init

or by using an already existing project in a repo:

    git clone repo_name

(This is not to be typed from within a project directory, as there is no project directory yet. The git clone will create one).

Both commands will create a .git directory in your project directory, where all the details of the repo/branches/commits are to be held.

As a side note, you can instruct git what to always ignore by setting up a file called .gitignore, which will contain wise notes such as (folders and files to be ignored):

    /db/*.sqlite3
    /log/*.log
    /tmp

As a side side note, a README file in the root of your project directory will tell github what to use as a description of your repository. It supports multiple formats (plain text - no file extension, markdown - files with .md extension, and RDoc - files with .rdoc extension).


2. Finding current situation

    git status

    git diff

    git log


3. Adding and removing files

    git add . (or just the needed filename)

    git rm filename (yes, there is also a recursive option for the rm, but it is dangerous enough to leave it out for now :-)).


4. Committing changes to the repo

    git commit -m "comments"

(If you feel lazy, git commit -a -m "comments" will do both the add and the commit part, but I prefer having it in two steps... because this auto-adds only the already tracked files)


5. Updating/syncing the other repos

One can either update his/her local project by using the repo:

    git pull

or can update the repo using the local as the source of truth:

    git push

Here a few more words:
- the name of the local repository is by default master
- the default name of the remote repository is origin

However, typically this needs to be created when first initializing the local repo with:

    git remote add origin remote_repo_name

The first push towards the new origin ought to be a little bit more explicit:

    git push -u origin master

But after that git push will be enough for git to know the right direction.

 - there could be other remote repos defined (such as for instance when we create a heroku instance, which also creates a remote repo in the local project directory, with the predictable name of heroku). Hence, syncing with heroku will be:

    git push heroku master


6. And finally, the mother of all...

    git help command

If you don't know even the name of the command you're looking for, just use git...

Web reference: http://git-scm.com/

Ruby on Rails!

Hi there! I've just finished GoTeaLeaf's first course (Ruby), and now looking forward for the second (Rails)! Will be back soon with more details about it...