Lucas Húngaro

Testing time-dependent code with the time-warp Ruby gem

2009-09-30T00:00:00-07:00

Testing time-dependent code with the time-warp Ruby gem

30 Sep 2009 – São Paulo, SP – Brazil

The need to “manipulate time” is common when we’re specifying code whose behavior depends on exact moments in time.

A viable technique is to stub Ruby’s Time class and manipulate it according to our needs. This works, but personally I have a gut feeling that says to me that whenever I’m doing this kind of thing on “system code”, very bad things can happen. Specifically, stubbing or mocking “internal” classes may lead to obscure and hard to track bugs.

Luckily, there is a neat Ruby gem called time-warp. It provides a layer over Ruby’s time-related classes that allow us to control the clock inside a code block. Here’s an example from our Rails Rumble application:

it "should only silence tweets with the desired word inside the configured time interval" do
  pretend_now_is(Time.now.utc.beginning_of_day + 1.hour) do
    tweet1.sent_at = 2.minutes.ago
    tweet2.sent_at = 32.minutes.from_now
    tweet3.sent_at = 1.hour.from_now

    collection = [tweet1, tweet2, tweet3]

    Silencer.apply(collection, {:word => "soccer", :until => 30.minutes.from_now})
  end

  tweet1.should be_filtered
  tweet2.should be_filtered
  tweet3.should_not be_filtered
end

The gem adds the method pretend_now_is, that receives the desired time as a parameter and a block. Inside this block, all code executed “travels in time” to the defined moment. Besides being a more secure way of dealing with time classes, the code is way more elegant and readable.

For more details, consult the gem’s README file.

Rails Rumble 09 - the experience

2009-08-28T00:00:00-07:00

Rails Rumble 09 – the experience

View Comments

28 Aug 2009 – São Paulo, SP – Brazil

Rails Rumble 2009 occurred this weekend and I have participated, together with ArthurGeek and Nando Viera, of team Awesome.

Our application is called TWT and here is its original description:

It’s a Twitter web client that aims to provide a set of flexible filters so one can only receive tweets with real value, not random “mundane” ones that really drains time and attention.

Among the filters we plan to do: mute (indefinitely and time based), by words (both “don’t show tweets with these words” and “show only tweets with these words”) and “valuable” tweets (i.e. only tweets that have been re-tweeted at least 3 times by friends).

It will be also an API, so later on we can develop desktop and mobile clients

Needless to say, there wasn’t enough time to finish all that features, but the application is online with some basic ones (and some bugs too): Twtapp

The weekend was fun and stressful. Here is the summary of the experience and some thoughts/tips:

Your app should be really small: seriously, really small. My advice is that the entire application shoulb be ready by the end of the first 24 hours. The second day should be spent polishing the application, bug fixing and “marketing” aspects: a product tour, standard static pages (about, feedback), 404 and 500 pages, a screencast and so on;
The team should be “physically together”: remote work will hurt the team’s overall productivity;
Brainstorm and define the entire application before the Rumble starts: do not let doubts to be discussed during the competition. The team should know clearly what each member should do and exactly how the application behaves before start developing any code;
Sleep;
Don’t do last minute changes: please, don’t write any Ruby code during the Rumble’s last hour. You can fix css, static text and images, but don’t code anything;
Limit test/specs to the application’s core: do not spend time writing specs for boilerplate code. Write only the specs for the critical parts of the application. During the Rumble the team shouldn’t try new things, just use things all members know and work with daily – this way you can let basic, well-know aspects, without specs;
Having a specialized web designer on the team will help as developers can focus the application core;
If a member decides to abandon the team hours before the competition starts, kill him/her. ;)

We expect to continue to develop the application. Soon it will be the application we’ve planned and we’ll let you know.

Increasing your productivity by eliminating distractions

2009-08-27T00:00:00-07:00

Increasing your productivity by eliminating distractions

View Comments

27 Aug 2009 – São Paulo, SP – Brazil

(or: How I learned to stop worrying and unsubscribed from feeds)

No, I’m still not a super-hyper-productive person, but here’s how I managed to increase my productivity using some tricks (and the awesome operational system that is Mac OS X with some wonderful applications on top of it):

Don’t check your e-mail more then four times a day: if you are expecting some important e-mail, ask the sender to alert you when he/she sends it – using something like an SMS;
Don’t check your e-mails if you won’t be able to act upon them immediately: an example is checking work e-mail on Friday afternoon, do it on the Monday;
Get rid of your feeds subscriptions: you won’t miss something until you stay some time without it. If, after some days, you miss a feed, subscribe back to it, but don’t check it more than once a day;
Let people be your filter: trust me, if something is really important (or banal, but “hot”) it will get to you, you don’t have to dig for it. The Google Reader shared items feature is awesome in this point, and I’m on my way to start using only it, unsubscribing from every feed I currently subscribe to. If you need to find something, Google is your friend;
Disable unnecessary notifications: like the Growl ones or the “red counters” on app icons in the OS X Dock – keep only the ones that you really want to be notified about (for example, I keep the Propane one, as knowing what my co-workers are saying on Campfire is important);
Don’t use a monitor that is too large: it may sound weird, but some research shows that after a size around 26-inch, user productivity starts to decrease. It’s obvious: too much things in your visual field will distract you. Use Spaces and split screens by the kind of task you have to do (one for programming, one for internet browsing and so on);
Increase screen real estate and eliminate items from your desktop: configure Finder to don’t show hard disks on the Desktop (I let only optical disks and removable devices appearing when connected). Eliminate from the Dock the apps you don’t use very frequently. Use QuickSilver or something similar to reach the apps and files you don’t use often, just don’t let them pile up on your Dock or Desktop;
Eliminate fom the Menu Bar the items you don’t need, like the Bluetooth status icon, the AM/PM indicator (it’s ease to know that by looking outside your window), the Time Machine icon and so on;
Use Adium and configure it to be hidden unless it’s the active application (see here: active, inactive, settings 1, settings 2);
Use Fluid to create SSBs for the web applications you need to work: the reason behind this is to avoid having a “full” browser opened with a lot of tabs distracting you. With Fluid “apps” you can focus only on the task at hand;
Use Tags to ease the process of organizing and finding files.

Some actions are really hard to take, like getting rid of your feed subscriptions – especially because nerds/geeks usually are bragging about how many feed subscriptions they have. It’s plain stupidity, like competing to see who stays up coding for more time and sleep less.

Anyway, give it a try. You will miss the things you really need (I recommend trying for at least 10 days) and can get them back anytime you want.

Firefox add-ons that I use and recommend

2009-06-08T00:00:00-07:00

Firefox add-ons that I use and recommend

View Comments

08 Jun 2009 – São Paulo, SP – Brazil

Even using just Macs I prefer Firefox to Safari (which I use through Fluid for some web apps) ‘cause of it’s great extensibility and variety of add-ons. Below is a list of the ones I use and recommend for web development and general internet surfing:

Firebug – you know it, it’s obligatory (Safari 4’s developer tools are great too);
YSlow – brings to you Yahoo’s performance guidelines for web pages;
Page Speed – a Firebug extension from Google similar to YSlow;
Firecookie – an extension to Firebug that allows you to view and manage cookie’s contents;
Web Developer Toolbar – a collection of nice tools for web development (like markup validation, browser window resizing, page elements manipulation and a lot of other tools);
Ubiquity – many describe it as Spotlight for Firefox – I agree;
Wolfram Alpha Google – integrates Google and Wolfram Alpha knowledge engine (really nice);
Speed Dial – enables direct access to your favorite websites through Firefox’s start page;
Download Statusbar – less intrusive download management (think Google Chrome);
TwitterFox – simple integrated Twitter client;
Locationbar² – enhance your browser’s location bar (highlights domain name to prevent spoofing, linkifies URL segments and other options).

What add-ons you like the most?

Reclaiming disk space from MacPorts

2009-05-26T00:00:00-07:00

Reclaiming disk space from MacPorts

View Comments

26 May 2009 – São Paulo, SP – Brazil

I use and like MacPorts for some software that have a too cumbersome/bugged compilation process. Many people use it extensively and others just dislike and ignore it.

A frequent complain about MacPorts is that it takes too much disk space (since it installs its own libraries instead of using the system ones). This is a valid concern and there’s a way to mitigate it. MacPorts allows you to clear files used to build a port, namely work files, distribution files and archives. To remove all of them from all installed ports, execute the following command:


sudo port clean --all all

This will clean all kinds of file for all ports. The syntax is simple. Let’s say you want to clear only work files from the port icu:


sudo port clean --work icu

More information can be obtained on the port command man files.

Another thing you can do to reclaim some disk space is uninstall inactive ports:


sudo port uninstall inactive

These two commands worked very well for me, managing to reduce MacPorts directory (/opt/local/var/macports) size from 1.3 Gb to 730 Mb.

Over-mocking, over-stubbing and avoiding over-stubbing with Mocha

2009-05-13T00:00:00-07:00

Over-mocking, over-stubbing and avoiding over-stubbing with Mocha

View Comments

13 May 2009 – São Paulo, SP – Brazil

I’m not a “fan” of the way most of the developers community make use of mocks and stubs. In my humble opinion, it’s a bad use of a very useful tool.

With this kind of use some issues arise, like over-mocking and over-stubbing – the overuse of mocks and stubs. Over-mocking makes your tests brittle, which means that they fail when you change the code even if there are no change on the behavior of the component under verification. Over-stubbing makes your tests weak, which means they pass even if they’re unsynchronized with the code, verifying behavior that isn’t real anymore.

Here’s an example of over-mocking:

Note that even “setter” methods are under expectations here. If you make a simple change on the implementation and, for example, one of these methods aren’t called anymore, even if you don’t change the behavior, the test will fail. This will end up happening anyway when you use mocks (that’s why you need integration tests), but you can diminish the bad consequences.

Here’s an example of over-stubbing:

With this approach you can end up with stubs of methods that no longer exists or even of objects that are no longer a dependency.

The best way to avoid this issues is to learn from trying and studying but, if you use Mocha, you can configure it to help prevent over-stubbing through the class Configuration:

In the above examples, when Mocha finds an “improper” use of stubs, it will throw an exception of the type Mocha::StubbingError. This occurs ‘cause we’ve made use of the method prevent. There are three levels of “protection”:

Note: of course, you shouldn’t use this as a solution for problems with over-stubbing. I think this feature is a good help for teams learning to do TDD or migrating from a “isolationist” style to a more traditional one.

Mocha::Configuration RDoc
Mocha Configuration – James Mead

Tests should reveal code intent

2009-05-12T00:00:00-07:00

Tests should reveal code intent

View Comments

12 May 2009 – São Paulo, SP – Brazil

This is nothing new to anyone – or, at least, it shouldn’t be. However, it’s much easier to say it than to do it for real.

It’s a really good thing that the testing mentality has spread around. This way many approaches to the practices of test driven development have been developed and improved. One good example are the testing frameworks. While they get more extensible and efficient by building cleaner beautiful DSLs, many people forget that, independently of the tool, of the syntax and of the technical approach being used, the intent of the written code is what really matters and has to be explicit.

Note: throughout this article I’ll use the expression “test driven development”, but you can replace it with “behavior driven development” or with any similar approach.

What is code intention?

The code intention has much to do with something that has been extensively discussed: the software behavior. A definition of behavior is “a system’s observable response to stimulus”. So we can say that what really matters is to verify if the observable response of a software component is the expected one, given one or more predefined stimulus.

In some cases this means just to define a state, call some method and verify the result. In other cases, means to verify the effect propagation too (that’s where mock objects are very useful). This depends on the component under development and on the approach you like the most.

How?

The question is: how tests help me to reveal code intent?

If you write a lot of confuse code and, after that, write some tests to validate this work, these tests won’t help on that goal. But, if you use tests to drive your implementation process, you will discover the fundamental role that they play on creating code that is clear and easy to understand, extend and modify. With a scenario specification (the predefined state where the stimulus will occur), it’s much easier to design and verify the necessary behavior.

Usually, when writing tests before the implementation, you get other benefits like: good naming, simplicity and code that’s easy to refactor. All of this thanks to the fact that, by practicing test driven development, you effectively think more about what you’re writing before you do it.

Example

I’ll try to exemplify the steps to create a simple component with and without tests driving the implementation. This way, by the end, we’ll have a better perspective of the effects of the process.

So I want to write an application to catalog my movie collection. I need a class that represents the movie:

That’s enough for this example.

Now let’s start the implementation of the class responsible by the management of the collection. First, no tests.

I know I need a class that have a list of movies and allows me to add, remove, seek and list all the movies. So we have:

Ok, that’s simple and it’s ready in two minutes. Let’s use it (on irb):

It works and meets our requirements. But, the code isn’t consistent. The movie collection (in practice, an instance of Array) is exposed and can be manipulated directly. This can be especially bad if some method of MovieShelf do some additional actions while operating the collection (like some logging when adding/removing a movie), ‘cause it won’t happen when we manipulate the collection directly. The naming isn’t very clear too, among other small issues. I also don’t like the way I’m creating objects of the class Movie.

Now, let’s start with a bit of specification of what is needed. This way I’ll have more time to think about good names and about a direct and clean way to use the code.

Just by establishing this first expectation regarding the behavior of this component, we have the idea of a initial implementation:

Continuing:

Implementing:

Of course this is a contrived and somewhat “silly” example, but note how the interface is way better now and also how we discover new functionalities in the process. This is one of the main advantages you get with test driven development: rich interfaces through code that is modular, flexible and have clear intent.

I won’t go on with the coding avoid a huge article. I believe I managed to expose the importance of clear code intent and how tests can help we reach this goal and obtain clear code.

What do you thing about this subject? Give your opinion, comment, example, criticism or suggestion. :)

Test Driven Development: Programming by Intention
The BDD cargo culting

Ready. Set. GO!

2009-05-10T00:00:00-07:00

Ready. Set. GO!

View Comments

10 May 2009 – São Paulo, SP – Brazil

Hello there! This is the first post of this blog.

I’ve been blogging since 2007 in portuguese and now I think it’s time to try to reach a wider public – the developers from all around the world. This will help to learn more from comments and criticism and also help to improve my communication ability in english.

Sometimes I’ll cross-post translated articles on my blogs, but there will be “exclusive” content on both of them too.

I like many facets of software development – from agile methodologies and the human aspects of a knowledge based activity to frameworks and dynamic languages. My current main interest is TDD/BDD, so you’ll be reading many articles concerning this practice if you chose to follow me along. Thank you and welcome!

Ready. Set. GO!