This is my very first screencast and I’m really excited to share knowledge this way, so expect more in the future.

Note: It is spoken in portuguese

Every developer has its own way of doing things and a set of programs he likes to use when developing, and having your work station tuned to get the most out of you is very important. Yet, when working in teams some ground rules must be set so that everyone is on the same page and that everything goes as smooth as possible.

There are enough bugs in an application, we don’t need more in the development process.

These rules can go from which version control software to use to code indentation and method naming, it is entirely up to you and your team to define these criteria at the beggining of a project. You can even go as far as writing them down so no one forgets them, or if a new member enters the team he can quickly get up to speed, here’s the set of rules we adopted at Group Buddies.

It is my personal belief that the ultimate goal in a software project is to write quality and functional code, defining these rules is but a way to get off on the right foot. As anyone who has done more than school programming assignments knows, code in a big project tends to become cumbersome and to decay in quality, making the project hard to work on and more adverse to change. Let this go on long enough and you’ll get to a point where you have only two options, rebuild from scratch or abandon the project.

That’s why great code is not just a plus, its a must have!

By now you’re probably thinking this is going to be yet another rambling about how awesome TDD or BDD is, well, it is not. TDD is definitely awesome, but nowadays I, as a developer, take it as part of coding. If you’re writing code and not testing it yourself you’re doing it wrong, at least in a web development project (and almost any other, I’d risk say).

Confused? No need for that, what I’m going to write about is a development flow that focus on improving code quality. It can be divided in 5 major steps:

1. Develop features in separate branches
2. Code
3. Run quality tests a.k.a. check for code smells
4. Peer code review
5. Wrap up

By now some of you might be shaking your heads in complete disapproval of what I just proposed, that’s fine, this is just the way we found to best serve our goal of improving code quality, you’re more than welcome to do it your own way and to share it with others as I’m doing, if you so please.

If you’ve read until here though, I’m assuming you agree with at least 80% of what I’m saying. Let’s try and get you to 100%.

1. Develop features in separate branches

This step may be a little bit git oriented, but that’s what we use, you’re more than welcome to adapt this to your version control system.

Whether you use git workflow, Github flow or any other flavor of these, one thing is certain, each new feature should have its own branch with a descriptive name (I like putting my initials at the beggining of the branch’s name, so everyone knows I’m responsible for it).

This serves two purposes, the first is that master or/and development should not be developed on as it will lead to a big mess of a history log and make it really hard to rollback a commit. The second is that having your own branch to mess around with, gives you a lot more freedom and a lot less fear to commit often.

One thing of note though, do not forget to rebase from the development branch from time to time (I find it ok to rebase once a day, but it depends on how big your project and team are). Also, resist your urge to create a branch from a feature branch, ALWAYS branch out from the development branch, or else you might get yourself into a branching nightmare.

2. Code

No, I’m not going to teach how to code.

This is where you do your job as best as you can, but remember: Red - Green - Refactor.

3. Run quality tests a.k.a. check for code smells

This is probably the step the least people do on a regular basis or have ever done before, still I assure you your code will get better and you a better developer with it.

In order to attest the quality of code you can rely on some great gems to help and guide you to where a refactor is due. The first of these is the flog gem, which uses ABC metric to assign each of your methods with a value which you should aim to keep low (between 10 and 15 should be a reasonable range).

On running these tests always remember that they are mere signs of a potential problem and a help on your quest for good code, if at any point it starts being an impediment, by all means stop doing it.

Other gems worth looking at are reek and flay.

Recently we’ve been using Code Climate to test the quality of our code and I have only one word to describe it. AWESOME! You should definetly check it out.

Both these methods will only tell you where your code might have problems, not how to fix them. For that you might want to take a look at Ruby Science and Clean Code.

4. Peer code review

After your code passes your own code review, it is always good to give it to someone else to take a look. This is a great policy mainly for two reasons:

Firstly you might have let an error slip or the person doing the review might have a different opinion on how to implement something. Secondly if you have code that is hard to understand that person will probably pick it up, and that is something your future self will appreciate when he reads the code again.

We do peer code reviews through Github’s pull requests which allows for a discussion to happen on the same place where the code is. Then the code should be reviewed by a certain number of people (quantitative) or by someone in particular (qualitative), it’s up to you. We approve a code review as soon as anyone from the team gives a thumbs up.

5. Wrap up

At this point you should have an accepted pull request with pretty good code, now just rebase your branch with the development branch, merge development with your branch and delete your branch.

And we’re back at the beggining, ready to do this all over again for a new feature.

Doing TDD is hard at first, but in the long run it surely pays off and with time (and practice) it gets easier to think test first. One vital part of developing this way is that your red-green-refactor cycle is as fast as possible, and you most definitely don’t want to waste a whole bunch of time looking at your computer waiting for the test suite to run.

You can speed up running the whole suite with gems as guard and spork, and you can even limit the scope of the suite to the tests you are running with rspec filters. I’ll even talk about these in a later post, but no the case of model testing, or unit testing, you should only need to load ActiveRecord, so why are you loading a full fledged rails app?

Active Record Spec Helper

The solution to this problem is having a separate spec helper which will only load ActiveRecord:

1
2
3
4
5
6
7
8
9
10
11
12
13

require 'active_record'

connection_info = YAML.load_file("config/database.yml")["test"]
ActiveRecord::Base.establish_connection(connection_info)

RSpec.configure do |config|
  config.around do |example|
    ActiveRecord::Base.transaction do
      example.run
      raise ActiveRecord::Rollback
    end
  end
end

We then include this helper instead of our regular spec helper in the model tests and also the model file, like so:

1
2

require 'active_record_spec_helper'
require_relative '../../app/models/team_role'

The rest of the test file remains exactly the same, as long as you use no other library apart from AR. If use something like FactoryGirl, you can load it in the active record spec helper, however this kind of defeats the whole purpose of this optimization.

You might also have to change your regular spec helper file by replacing config.use_transactional_fixtures = true with require 'active_record_spec_helper'.

In Practice

Running a test suite of only two tests (in a rather big rails app) with both the regular spec helper and the active record spec helper I got from 20.604s to 1.683s of running time. This proves that 95% of time is wasted in the loading of unused libraries.

via

The first time I created a Rails Engine, there were some parts of it that were confusing as it was just like a Rails App, but no quite, just like a gem, but not quite. There was a lot of digging through old or non existing documentation about how to configure an engine I’ve just created.

Nowadays with the rising popularity of engines, the documentation is getting better, still there are always some little things I have to do every time I create a new engine. Since this is boring work, I decided to create a gem to do this boilerplate work for me. And thus, Mechanic was born!

This idea is largely based on thoughtbot’s Suspenders that tries to do the same thing for normal apps. Mechanic is very new and still a diamond in a rough, so if you spot a bug or have a feature you would like added please let me now in Mechanic github issues page.

Well, it seems today is a great for me in terms of gem finding. I’ve been taking a look at rails 4.0 new features, which are mostly already available as gems such as Turbolinks, and another one really stole my attention.

It’s called cache digests and it makes it super easy to do russian doll caching.

I’m assuming you’re also going to need to use memcached if you want your expired caches to be removed automatically, but other than that it just works.

I have been under a heavy load of work and not having much time to post as frequently and as awesomly (not sure this exists…) as I would want, but just found a gem that is so awesome I needed to share with you guys.

Getting to the point

Turbolinks is a gem mostly developed by DHH that makes following links in your web application faster without, and this is the best part, you having to change any server side code. It’s like pjax on steroids!

Basically it works on the same premise PJAX does, which is that loading all your JS and CSS files everytime you follow a link is expensive (even if it hits cache), so it will just load the title in the head and the body.

Steve Klabnik has even made a benchmarker so you can get the exact amount of speed improvement your app will get. He has also posted the results for Basecamp Next, so you can check that out.

TL;DR

Get Turbolinks.

Octopress is a really awesome library to build blogs on top of Jekyll. I’ve just now ported my blog to this and I’m loving it.

Today I was experimenting with jQuery plugins and came up with Better Pagination.

Better Pagination is a jQuery plugin written in coffeescript that provides infinite scroll and/or loading of elements by clicking on a show more button. This is often useful when listing a lot of elements and you don’t want to do normal pagination within a table. It is kind of like what facebook does when you are scrolling down your news feed.

It’s a very small file (1.64KB min version) and fully configurable. All requests happen through AJAX.

Any doubts, concerns, sugestions or corrections you want make, github issues page is a great place to do so.

It is not possible to change the background image of a DOM element with animate (misleading title, sorry about that :P), so here is a pretty nice workaround that will get you that fade in/fade out effect you always wanted when changing images.

This works by first reducing the opacity of the current image to 0, making it invisible, and when this has finished apply the new style and making the opacity 1 again with a soft fade in effect. Nice. :D

$("#image").stop().animate({opacity: 0},1000,function(){
    $(this).css({'background-image': "url('/images/alt_image.png')"})
           .animate({opacity: 1},{duration:1000});
});

Note: The stop function is there just to prevent the effects queue to grow to deep, i.e, if this is triggered by a click and the user clicks multiple times, only the last animation will actually run, all the others will be stopped.

Check out my latest talk about git.

The target of this talk is everyone that has never used a version control system or has done so with great pain (yes, svn guys, it’s you). Please feel free to share it.

And on the topic, visit git’s brand new website. It’s awesome!