The Code Dump

As we’re approaching a year and half here at BillGuard, I’ve started thinking back a bit about our testing habits and how well that’s turned out.

I’ve seen a lot of posts about testing in startups, some saying startups shouldn’t bother to test because they’ll have to change the whole damn thing 5 minutes after they’re done, others claim testing is the only reason they were able to keep working. Here are some of my thoughts looking back.

Our Background

When we started, only two of us had a test-infected background out of the five technical guys, me being big on TDD. Two other developers never wrote tests before. We agreed that tests were important, but that’s about it. I set up a continuous integration server and with that we were off. With time, the habit of writing tests spread out among the team. Some are TDD passionate, some write tests after the fact, but we generally all believe that tests should be written extensively.

None of us, ever

Not everything is worth testing

We’ve seen several quite rapid changes to our UI. Having less tests in this area makes sense. We rely on QA for making sure all buttons are displayed etc. To make this clear: we have no selenium-like tests for UI components but have tests for most logic being done by the UI. I think this is generally a good practice, since having to maintain selenium tests would be hard when you throw things around a lot and change flows. Some basic automated sanity tests pretty much does it.

Everyone learned to love tests

I love seeing other guys in the team delete a line of code to see which test breaks and understand why it’s there. Even more I love the frowning face when no tests break. This addiction to tests shows how much value the team’s getting out of having solid tests, hands down. No need to stress this further I believe.

Tests save our asses repeatedly

Having an extensive suite of tests allows us to make rapid changes to our code base, as is needed in most startups, and rely on the solid tests to tell us whether we’ve screwed something up. All the code that has anything whatsoever to do with sensitive and important information is heavily tested which is a huge bonus and a necessity in our line of business (personal finance protection).

TDD is just magical with complex algorithms

We have quite a few complex algorithms that require multiple entities and ideas to perform. I find that the parts we’re most satisfied with maintainability-wise are the heavily TDD-ed algorithms we’ve got. Being written with rigorous TDD gives us so many advantages:

• This critical code usually has a lot less defects.
• The code is a lot more readable, well decomposed and allows for easy changing once we find out a need for tweaking the algorithms.
• Working in TDD magically forces us to form our problem domain better, making us have a language of our own in talking about the problem. This happens less naturally in other forms of working on algorithms.

Summing our testing experiences

All in all, I think the whole team would agree that dedicating time to writing thorough tests is proving itself valuable and because of that people are writing more and more tests without any of us ever stopping and saying “we should write tests” (well, I swear I didn’t do it too much). It happens naturally when people get the value out of it. It’s fun seeing how today BillGuard has become a company that organically values testing so much I don’t even feel a great need to stress it to new people because they’ll quickly see there’s no real other way. We’re far from being the poster children of Clean Code, but I’ve got my fingers crossed.

If you’re interested in accomplishing the same at your work, you might find this recent post of mine of some help.

You should subscribe to my feed or follow me on twitter!

Pushing forward with the Autonomous Craftsmanship Core series. This week on our plate: How can you force pairing down the throat of your team even if they’re not really into it?

I’ve already touched on this subject a few times before, especially since it’s one I find really important and had to handle a few times before.
Pair programming feels to me like the best technique currently known to the software industry for making a team highly productive and have global code ownership. It’s one of those things that didn’t click right away when reading Extreme Programming Explained, but man did I get it wrong.

I’ve loved pairing from the moment I started doing it and ever since I find it hard doing hard work without a pair by my side. The problem is that most of the software shops around are still not pairing regularly, making it hard for a pairing junky like me to have fun.

So, how can we stop bitching about our team not pairing and actually get shit done with a pair? As opposed to the previous posts on the Autonomous Craftsmanship Core, this is not something one can do alone, and so is a bit harder to work around.

Basically, don’t calling it pair programming. It might be a bit tricky socially, but it’s worth it. Some real examples:

Can you help me out?

If I have a short task (ideally – no more than 30-45 minutes) that I want some help with, I just find someone on my team and ask for some help. Hopefully, you’re not in a team where asking for help sounds problematic. Then, once you’re both on your computer and working on the problem – you’re pairing. That was easy, wasn’t it? Do it enough times (without looking like an idiot that always needs help) and your mates get acquainted to the idea fast.

Volunteer to help people

I love walking around the team and seeing what people are doing. Every once in a while, simply walking by someone and asking how are things going might trigger a “Take a look at this” response, and you can help a fellow coder get unstuck. I used to do this even outside of my team. Spending 15 minutes with someone to help him solve a problem and share some knowledge and technique in the meantime is just awesome.

Review code to be in the loop

I try and read most of the commits being done to projects I’m involved with. It has many advantages, and one of them is that I’m familiar with most of what’s going on around me. That means I might find little problems, ideas and changes that might help my team. I then just go to the person that made the changes and share my ideas. Sometimes that would drag us both into a short pairing session.

These are basic techniques that I’ve found helpful several times. Even people that have never heard about pairing start liking it (if they really find you helpful and not annoying, of course). I just love seeing how after a few weeks, people come and ask for help if you’re not around, and how slowly the idea of doing some tasks together becomes obvious. I don’t have to have them call it pairing, and it doesn’t have to be 100% of the time. The bottom line is that good practices stick, even unconsciously.

You should subscribe to my feed or follow me on twitter!

Continuing on the thread of the Autonomous Craftsmanship Core, we reach another problem: “they” just won’t let you use the right tool, or in the right way. As I’ve said in the previous posts if anything is so bad you can’t work with it – leave; otherwise, you gotta learn how to make do.

A pragmatic programmer uses the right tool for the job. We all know that if you have a hammer, every problem looks like a nail. In this post I’m talking about the situation where you have an awesome toolbox right there and yet they’re forcing you to unscrew something with your pinky’s nail. Excruciating to your brain.

The thing is, a lot of the times you can just use the right tools and the hell with everyone else. Yes, you can’t just write code in whatever programming language you want, but in a lot of other situations, you can do what you want to. I think this is best shown with a few examples:

“Don’t commit too much. Say once a day”

That’s a real quote a friend’s boss told him. Turns out committing multiple times a day is too messy. Most programmers might just sulk and do as they’re told, but with today’s technology you’re no longer bound to these stupid rules. Your team uses subversion? So what! You can use Git locally, do whatever you like, and just push once a day everything via git-svn. Same solutions are available for just about any VCS combination you can think of! I’ve done this several times working on projects with a VCS I didn’t want to mess with.

“We can’t have a CI server”

Why would someone be against that? Maybe your company doesn’t want to allocate a new server for such a “useless” thing, or maybe the system admins don’t have time for your little “developer toys.” Lucky for everyone, it’s no longer the case that you need complex setup for such stuff. It’s just a matter of looking around. For example, if you’re doing open source you just need to give Travis a look and see you’re suddenly all set. On the other hand if you’re code isn’t open sourced setting up a local Jenkins server is so so easy. You just double click a file and you’ve got it running. If your build isn’t too CPU hogging, you can run it on your box! And I’m almost certain you can find some server with some spare cycles to install it on.

Autonomous Craftsmen Make Do

That sums it up. A craftsman’s gotta do what a craftsman’s gotta do.

You should subscribe to my feed and follow me on twitter!

My first team had (among many other great attributes) the custom of strictly following a style guide. It was followed so religiously, I’ve yet to come across another place that does so to the same extent. It wasn’t really written down anywhere, but after a couple of weeks of pairing with the other guys you got it.

What does that mean exactly? It means that we wrote code that looked, to a large extent, like it was written like the same guy. We put 2 blank lines between regions. Members had a specific way of documenting. We even used the same idioms for creating empty lists etc. (Java).

If we paired with someone and saw him indent the code the wrong way, we’d go all OCD until it was fixed. And it was regarded totally OK. We didn’t feel like we were nitpicking on each other. It was the way things got done. I even know a guy that would notice extra whitespace at the end of lines (without any IDE help).

Ever since, whenever I see code written with careless indentation and whitespace I feel like the coder who wrote that just doesn’t care enough for the craft. Yes, No Whitespace – No Care!

What’s the big deal?

If code isn’t written in a consistent style in your team, whenever you come across code with the spacing a bit wrong, the first thing your head’s going to process is “I didn’t write this.” This is a natural feeling, and as we all know coders have a hard to restrain impulse to rewrite any piece of code they didn’t write. Once all the code looks the same, that feeling isn’t that hard and you can actually focus on the code itself and have a better sense of ownership. I know, it sounds stupid, but that’s the way our stupid minds work in.

A big part of the Extreme Programming principle Collective Code Ownership is obtained by simply keeping a consistent style. Anything important enough to become a core value of the only methodology that works must be worth the effort to take notice of.

The next time you see code with reckless spacing, change it and let your teammates know. It might be hard at first but the end goal is important – the ability to fluidly read code, without feeling like you’re wearing someone else’s shoes.

You should subscribe to my blog and follow me on twitter!

Just recently my Dreamhost plan, the one this blog is hosted on, expired and I had to renew it. Seeing the amount of money they took charge me realize that surely I can find something cheaper than >$10/month. After some snooping around I’ve settled on moving my WordPress blog to EC2. This is my story.

Disclaimer: this worked for me. If you lose your blog, too bad. Backup is your friend, my friend. You need some devops-chops to follow along.

After being tipped of by a couple of friends, I decided to look into setting up my site on EC2. Basically, my blog is really small (the WordPress export file is about 2MB), and it’s not like I get tons of traffic. That alone means that for a year now I can use the EC2 free tier, making this blog cost pretty much nothing.

Initial setup

First step was to register and AWS account. I created a micro instance, which is enough for most blogs and free for a year. The AMI (image) of the instance I used was Bitnami’s prebundled WordPress image, which you can read more about here. Do make sure to create your instance on an EBS and not instance store. That means that the data will be persistent. Change the instance’s security group to allow connections to port 80 (HTTP) and port 22 (SSH) from any IP.

You can assign a static IP to your instance for free! Just allocate a new Elastic IP on the EC2 console and attach it to your instance. Note that Elastic IPs cost nothing while attached, by if they aren’t attached your bill will start growing (after all, fresh IPs are a rare resource).

So you’ve got your instance up, eh? You can point your browser to your instance’s public DNS name, like so http://ec2-something-something.com/wordpress and see the default WordPress hello page. Go to /wordpress/wp-admin to login as admin (the default bitnami user/password are user/bitnami). Here you can start and setup your blog again.

Importing

On your original blog, you can use the export utility and then import all your posts and comments to the new machine. Easy as pie. If you have a lot of plugins and configurations, you might want to search for one of the many plugins that do that for you. If you’re like me and only have a couple of plugins and one theme, installing them manually takes about 3 minutes.

Moving WordPress to the root of the site

If you’d like to move WordPress to the root of your site (/ instead of /wordpress), remove the path from the General settings page and then SSH to the machine. Replace the first two lines of the file /opt/bitnami/apps/wordpress/conf/wordpress.conf with:

Alias / "/opt/bitnami/apps/wordpress/htdocs/"

Then, go to /opt/bitnami/apache2 and do:

sudo ./bin/apachectl restart

Gotchas

Got permalinks? You’ll need to:

chmod g+rw /opt/bitnami/apps/wordpress/htdocs/.htaccess

Want to receive email notification for new comments etc.? You’ll need to do:

sudo apt-get install sendmail && sudo ln -s /usr/sbin/sendmail /usr/bin/sendmail

If you have attachments in any of your posts, you might need to fix the URL after the final move.

Testing

Make sure all your links, widgets etc. are working before making the final move. Post something, add a comment.

Going live

In the General settings panel, change the URL of the blog to your domain. Go to wherever you were hosted before, find the DNS panel and change the DNS entries for your blog. Danger: This is an “expert” step, and if you don’t know what it means, I recommend grabbing someone with more knowledge. Change the A records for your domain to point at the elastic IP you gave your instance. That’s it! Wait a bit for DNS propagation and everything should be working!

Backups

I found out about the backup to dropbox plugin, which simply uploads all your blog to dropbox! Sweet, awesome and easy for small blogs!

Costs

So, using 1 micro instance with an EBS store of 10GB is free for the first year. Given nothing crazy in terms of network, you shouldn’t be paying at all for the first year, maybe about $1 a month. After that year passes, the instace and EBS store start kicking in. If you’re in it for the long run, like me, paying for the instance a year in advance costs about $9/month (3 years is like $7), and the EBS store costs $0.1 per GB, meaning $1. That’s about $10-$8/month, depending on how you pay for the instance. A great save compared to Dreamhost!

You should susbcribe to my feed and follow me on twitter!

Diving deeper into the idea of the Autonomous Craftsmanship Core, this time I’d like to talk about one of the first problems a lot of developers face when wanting to start doing clean code.

You read Uncle Bob’s Clean Code, or went to a talk and then go all “Next day at work I’m gonna write tests!!” Then you come to work, and you give the “let’s write tests man!” speech to your teammate, and he just yawns, and slowly the rush fades.

Lots have been written before about introducing tests to a team as a grunt, but I’ll do a quick recap:

You don’t have to ask anyone in order to start and write some tests. Write that first test. Make it pass. Commit. Not that hard, isn’t it?

Usually the next problem is that if no one else on your team runs the tests, they will keep breaking. But can you blame your team? You need to make them understand that running the tests will actually get them something.

For example, I’ve seen that after someone makes a commit that breaks the tests because of a bug, coming over to him and telling him what went wrong and how you found out might make him more interested in the idea of testing. A friend recently told me that he made running tests as simple as a double-click for the developers that don’t write tests. Once it got that easy, they started running them because everyone likes knowing that what they wrote works.

What if your boss won’t let you write tests? Frankly, why the fuck should your boss care? Does he also tell you when to use “while” instead of “for”? I don’t find things such as these to be something any boss should decide about. As I’ve said in the first post, if you find yourself in a place so resistant to change, leave. If you have to stay, do what you have to do. If they won’t let you commit your tests to source control or set up a continuous integration machine, there are solutions, which I’ll discuss on my next post.

In the mean time, focus on writing tests that help your teammates find problems and see how slowly your little tests get more and more traction. It’ll work, because Success begets attention!

You should subscribe to my feed and follow me on twitter!

A lot of developers I know keep bitching about how their team isn’t as passionate as they’d like it to be, or about their boss not letting them do things like it should be done. They get into this habit and never advance in the right direction because something is holding them back. I know this situation well, I’m usually one of these guys.

In the spirit of Positivember I’d like to tell you a secret. You can stop whining and start improving. You don’t have to wait for all the stars to align. That cliché about changes starting from yourself is actually right.

I’ve heard almost every complaint in the book:

“My teammates don’t write tests.”
“They won’t let me have a continuous integration server.”
“I can’t use Git.”
“My boss hates it when I make a lot of commits.”
“I was told not to write tests.”
“We’re not doing agile development.”
“I can’t do pair programming.”

If everything above applies, or you really have lots of problems like these, just quit. A developer that really cares about these things usually can find a better job easily. But, if it’s only some of these, remember that no work is perfect. There will always be suboptimal stuff to live with. The trick is not to be all bitter about it, but to actually try and make changes happen, slowly, so you still have fun.

Most if not all of these problems are things you can work around, technologically, mentally or socially. If you just stick to your good ways, you’ll eventually get some followers too.

Step up and realize that everything can start by you and your habits. An Autonomous Craftsmanship Core as I like to call it. Sometimes, you core will seem so awesome from the outside that people will join in on some of your practices. Sometimes it will go unnoticed and you will happily go on programming better and better.

I will blog more on tackling some of the problems I mentioned above, but as a starting point I recommend Apprenticeship Patterns and Driving Technical Change. These great books help a lot in accepting that fact you should take matters into your own hands, and stop bitching.

You should subscribe to my feed and follow me on twitter!

I’m always looking for the easiest way to make my code better, or to train myself to pay more attention to the quality of the code I produce. My latest find is quite obvious yet so very powerful I had to share. Simply put, it’s just going over your code once more before a commit.

Every once in a while, I commit code and forget to add a file. Even worse, I sometimes leave around dead code that I really hate. I’ve found out that simply making a mental note to go over every file I changed before making a commit makes a big difference. It seems like the Boy Scout Rule from Clean Code is a special case of this rule.

The trick is to simply go over every file you’ve changed and look for common pitfalls:

Unused code – Are there methods your changes just made obsolete? Maybe a conditional with an “else” clause that can no longer happen? Delete code! It’s the best code you’ll write today!

Zombie code – Did you start with something that was too complex and is no longer needed? Often in retrospect you can see how to simplify something and spare your colleagues the woes of zombie code.

Overdue refactoring – Look at your changes. Are you pushing a method too far? Maybe making a class too bloated? Maybe it’s time to for some cleaning.

Do you have a better name for it now? Sometimes when you start with something you don’t have a great name for it. After finishing it, you might be able to slap a better name on that class that will make it more obvious to everyone.

Any dangling TODOs? I hate committing TODOs unintentionally.

Make sure it’s all coherent in class-level – Some changes make sense when you’re knee-deep in a change. But step back and make sure it all still makes sense.

You should subscribe to my feed and follow me on twitter!

If there’s anything I hate more than dead code, it’s zombie code. Dead code is code that’s remained in the system even though it’s no longer really used.

It might be small, like unused imports, instance variables and methods. It can be whole classes that make up entire features no longer used.

The biggest PITA is when you’re not really aware of the fact the code’s dead and unused, sitting there and occupying precious bits, and stumble across it as part of a task, trying to understand how it influences what you want to do next.

Whenever I recognized something that looks like dead code but I’m not entirely sure, I find it pretty easy to delete it quickly, once I take a look in the version control logs and see when it became no longer in use and why.

Zombie code is code that was never alive, and so couldn’t really become dead. It’s the undead code – code that died right when it was committed. Code that never ran or never worked. The are two reasons I hate zombie code more than “plain” dead code.

The first reason is that it simply wastes more of my time. Looking back in version control won’t help me see the commit in which the code was “decommissioned”, it would just appear to always sit there. That means I have to take extra care to verify that it, in fact, never worked.

The second reason is that it’s plainly someone saying he doesn’t give a damn. I mean, let’s put aside TDD. Heck, let’s put aside unit testing at all. It means the code never even ran the damn thing and saw in his own eyes it did what he claims it did.

Be kind to your teammates. If you’re not a good enough coder to test it, at least see that it runs once in your own eyes.

You should subscribe to my feed and follow me on twitter!

One of the concept I had to get used to moving from Python to Ruby was that regular objects aren’t callable, and that there was a closed set of objects that can be called. Meaning that where in Python it was possible for any class to implement __call__ and so allow us to call it with obj(), Ruby doesn’t allow this. One of the advantages of that syntax in Python is that each class implements its constructor using this. For example:

class MyClass:
    def __init__(self, value):
        self.value = value

my_class = MyClass(1) # We are calling the class to get
                      # an instance, instead of
                      # MyClass.new(1) in Ruby

This was a nice little trick I liked in Python but quickly got used to living without it. That was until I saw Ruby code that seemed to allow the exact same behavior:

Integer.class
#=> Class

Integer(1)
#=> 1

How’s this so? Can we really make classes callable? A quick glance at Integer’s source code in the Rubinius code reveals that there’s no magic going on in it, and that it actually has no reference for this method I’m looking to call. Instead what we’ll see is that alongside the class definition there’s also a method definition:

class Integer
  #...
end

def Integer(value)
  #...
end

So the whole trick is simply to define both. But how exactly does this work? How are names not clashing?

What actually happens is that whenever we define a new class or module, its name is added as a constant that points to the actual class. Similarly, when we define a method at the top level it’s added as a private method to Object. That means that whenever we type in a name that looks like a constant (starts with a capital letter) without parenthesis, Ruby will search for that constant:

Object.const_defined? :Integer
#=> true

But when we add parenthesis, Ruby understands that it should seek for a method instead:

Object.private_method_defined? :Integer
#=> true

This nifty little trick is all it takes for Ruby to allow this nice syntax.

Hope you learned a new thing! In case you want to dig deeper, two great books that really helped me wrap my head around dark corners of Ruby are Eloquent Ruby and Metaprogramming Ruby.

You should subscribe to my feed and follow me on twitter!