Git: Commit Early, Commit Often
Posted by Jaime Bellmyer in 
Don’t Be Afraid of Commitment
The phrase “save early, save often” was a mantra of early computer science. It’s good advice, but it’s only half the story. If you’ve ever sat down for a fast and furious coding session only to realize hours later that you removed something important, you know the frustration of not being able to get it back. It can mean hours lost.
Getting in the habit of regular commits has a number of benefits. First, you can go back to any previously committed version if your coding goes off-track. You can reference earlier parts of your work even if you don’t need to revert to them. Best of all, it an actually have a positive impact on your code itself.
Better Code through Committing
Just as Test-Driven Development influences us to write a larger number of shorter/simpler methods, frequent committing pushes us to think of atomic changes. Atomic in this context means the smallest possible self-sufficient change. Consider this snippet from git log:
commit b0e77532b5a8cf236d95f1b3324aabc194568c60 Author: Wally Date: Tue Feb 29 23:58:05 2011 -0600 added comments to blog posts
This is an example of a commit done at the end of a feature. Lots of code has probably gone into this, and if you wanted to see any of the steps along the way, you’re out of luck. It’s also not very easy to see what was changed in the app.
An Example of Frequent Commits
Now look at this version:
commit e8bba8ad1a4b5c1353c328b505bfa2a9f4816d07 Author: Alice Date: Tue Feb 29 14:58:05 2011 -0600 added edit/delete links to each comment if user has permissions commit 8bba8ad1a4b5c1353c328b505bfa2a9f4816d07e Author: Alice Date: Tue Feb 29 13:58:05 2011 -0600 allowed admins to edit/update/delete any comments commit bba8ad1a4b5c1353c328b505bfa2a9f4816d07e8 Author: Alice Date: Tue Feb 29 11:58:05 2011 -0600 restricted edit/update/delete actions to user's own comments commit ba8ad1a4b5c1353c328b505bfa2a9f4816d07e8b Author: Alice Date: Tue Feb 29 11:36:20 2011 -0600 created controller/views commit a8ad1a4b5c1353c328b505bfa2a9f4816d07e8bb Author: Alice Date: Tue Feb 29 10:03:31 2011 -0600 made comments nestable in the model commit 8ad1a4b5c1353c328b505bfa2a9f4816d07e8bba Author: Alice Date: Tue Feb 29 9:39:24 2011 -0600 defined activerecord associations among users, posts, and comments commit ad1a4b5c1353c328b505bfa2a9f4816d07e8bba8 Author: Alice Date: Tue Feb 29 08:38:01 2011 -0600 added base comment model and migrations
You can clearly see the evolution of this feature, and it makes sense. Not only can you step back (if user permissions were implemented incorrectly, for instance) but Alice was “forced” to think about each logical step of her development process, instead of jumping in head first. It’s engineering 101 – break a problem in its atomic elements, and attack each of those.
Incidentally, this can also help explain to coworkers, bosses, and clients why a seemingly simple task took longer than expected. As you squirm and attempt to justify what you know is an elegant solution, you might not remember all the steps that got you there.
Git remembers.
Thebes, profiling spork, backup rubygem
Thebes, a new minimal sphinx gem for Rails
Thebes is a wrapper around Sphinx, the search engine we use on most of our projects. Thebes differs from other solutions by staying as far away from your Rails code as possible. Instead of hiding the Sphinx configuration file behind a domain-specific language, this library assumes you will write Sphinx config files by hand. In Thebes, you edit an ERB template of your Sphinx configuration and populate it with variables at generation time. For developers needing the most flexible or fastest solution possible, this is a great way to work with Sphinx.
We’ve been doing some interesting things with search and reporting that are going to require faster lookups than directly querying the database. From the article “the [Thinking Sphinx project] has a lot of complexity and ties to ActiveRecord 2.x code. Consequently, the porting of TS to Rails 3 isn’t turning out to be the smooth road we hoped for. So, for Rails 3 projects, this looks like a good way to go if you’re willing to get your hands dirty and build some sphinx files yourself.
Profiling Spork for faster start-up time
Spork allows you to preload Rails environment files into a process, then it forks that process and runs your tests against the new process. In essence, your tests will start faster because they’re not loading everything. You can specify files you want to be reloaded each time (for instance, model files).
The code:
This prints out everything being loaded up, so you can move files that don’t change into the preload block for that extra bit of snappiness.
Backup, a rubygem for database and file backups
Backup is a RubyGem (for UNIX-like operating systems: Linux, Mac OSX) that allows you to configure and perform backups in a simple manner using an elegant Ruby DSL. It supports various databases (MySQL, PostgreSQL, MongoDB and Redis), it supports various storage locations (Amazon S3, Rackspace Cloud Files, Dropbox, any remote server through FTP, SFTP, SCP and RSync), it can archive files and folders, it can cycle backups, it can do incremental backups, it can compress backups, it can encrypt backups (OpenSSL or GPG), it can notify you about successful and/or failed backups (Mail or Twitter). It is very extensible and easy to add new functionality to. It’s easy to use.
Check out the README for all the details, but this allows you to backup your app via command line, pushing to S3 or rsync’ing to another server. You can schedule it with the fantastic Whenever gem too.
A :limit of Rails’ Migrations
Migrations in Ruby on Rails use the “:limit” symbol to set the maximum length of the underlying field’s data type. Take for example, the following example migration:
create_table :things do |t| t.string :name, :limit => 32 t.string :description t.timestamps end
By default, Rails will create :description as data type “varchar(255)” and :name as “varchar(32)” in a MySQL database. But did you know you can set :limit to be greater than 255?
For whatever reason, many of us have gained the impression that 255 is the longest :string can be, but that just isn’t the case. If I wanted the :description field in the example above to be greater than 255, I could just define it as follows:
t.string :description, :limit => 1024
In fact, strings (i.e. varchars) in MySQL can hold up to 65,535 bytes of data.
The opinionated nature of Ruby on Rails is a great asset in most instances, but we have to be careful not to let its opinions :limit us.
Note: I’m pretty sure Rails sets the default limit of strings to be 255 for two reasons: 1) cross database compatability, and 2) MySQL’s InnoDB (utf-8) engine can’t index varchar fields exceeding 255 characters.