We all do it. We hack and hack and hack and come up with that new something. At least it’s new to us. So, then what do we do? Here is a list of things of 10 things you could be doing to your code right now. I’m doing this with a Ruby on Rails slant, but the ideas presented here are applicable to other situations.
1. Upgrade Test::Unit
What, you aren’t testing? You should be testing all the fucking time (TATFT). After, you’ve come to grips to yourself, and realized that you have to test, you should be using something better than Test::Unit alone? RSpec is a good option (at least TATFT’n), but I’m here to talk about Shoulda made by those guys at ThoughtBot.
Shoulda is a set of macros that runs right on top of Test::Unit. What does this mean? This means that you don’t necessarily have to unlearn everything you knew in the first place. You can ease yourself in to using Shoulda as fast or as slow as you want.
Why Shoulda? My answer to this question is pretty simple. I want something pretty low weight that doesn’t get into my way to much when I’m doing the testing thing. Also, the DSL is concise and easy to pick up quickly.
RSpec is an option as well. This DSL has a huge following in the Ruby land, and many people swear by it. When it comes down to it, it is the quality of your tests and depth of your coverage that really matter, so pick something, and make sure you TATFT!
2. Try out some TDD
Now that you are testing, you should be writing those tests first. Don’t write code and try to cover it with tests afterwards. This method works. It is most likely how you learned in the first place. Test Drive Development (TDD) makes for better code. The most important foundation of TATFT is TDD.
So, how do you TATFT? It isn’t hard to do. First you write the simplest test you can, run it, and watch it fail. Then you write an implementation that makes the test pass. Then you refactor your previous code to clean it up. Say it with me slowly, “Red, Green, Refactor”. Now you do it over and over again. In a nutshell, this is Testing All The Fucking Time.
One thing that you will learn early is that TDD is hard. Hard is good. It gets easier and easier as you learn how to test.
3. Upgrade your fixtures
Most developers who come to Rails find out about fixtures love them. Well, they love them until they actually have to use them. Fixtures are one of those things that seem like a great idea right up to the time that they have to prove themselves. I guess if you look at them this way, fixtures are like Adam Sandler movies.
There are quite a few replacements for fixtures out there. Some go the old school way and get rid of fixtures all together. I’m not sure I can advocate this approach due to the fact fixtures actually do provide some use. Others replace fixtures with mocks and stubs and this approach does work although it can be verbose. There are even a few replacements for fixtures outright, and I’ve chosen one for my arsenal, the Rails Scenarios plugin.
The reason I’ve chosen the scenarios plugin is because it works like fixtures in my tests, but allows me a better DSL than YAML to define my data. I also can specify multiple scenarios in one file, and that helps keep things organized.
4. Install (and learn and use) a SCM
This shouldn’t be on my list. But it has to be on my list. Too much code is floating around and isn’t under some form of Source Code Management (SCM). The benefits of having code in some form of repository hugely outweighs it not being there. There are plenty of options out there today, but I’m gonna focus on the one I’m using day-to-day: git.
Git is special. It is special because it is a distributed SCM (DSCM). DSCMs are the future because they are made to work with other users who have other repositories.
5. Investigate Continuous Integration
So, now we are testing first and we have our code safe in our repositories. Now what? How about some more testing? What’s better than you testing all the fucking time? Automation of your testing all the fucking time? In the Ruby world we are especially luck due to the fact that cruisecontrol.rb exists. This application makes automating your tests to run at checkin next to trivial.
6. Know your code
It is one thing to write your code, but it is another greater thing to know your code. Four automated tools which can help with this knowledge are: flog, tarantula, rcov and saikuro. Each of these tools is special in their own way, and I would like to introduce you to them.
Flog is a tool which measures complexity using the ABC metric. The ABC metric stands for Assignments, Branches and Conditionals. When you run the tool, it’ll spit out some numbers which may or may not mean anything to you.
$ flog core_ext.rb Total score = 15.0880747612146 main#none: (15.1) 5.6: / 3.4: require 3.4: dirname 1.3: puts 1.3: exit 1.2: assignment 1.1: branch
What does this mean? Well, thanks to Jake Scruggs, I have this handy chart for interpreting flog scores:
- 0 – 10 Awesome
- 11 – 20 Good enough
- 21 – 40 Might need some refactoring
- 41 – 60 Possible to justify
- 61 – 100 Danger
- 100 – 200 Whoop, Whoop, Whoop
- 200 + Think of the children!
I’ve taken the liberty and simplified this chart a bit:
- 0 – 10 ring, ring, The Gods are calling and wondering where their code is?
- 11 – 20 Not bad…
- 21 – 40 Might need some TLC
- 41 – 60 Write it over
- 61 – 100 What the fuck are you doing?
Tarantula was written by some smart minds over at Relevance (the same guys who brought us streamlined). What tarantula does is spider your Rail’s application looking for bad links. This has actually saved me recently, and I’m internally indebted to them.
RCov is a pretty popular tool in the Ruby world. RCov is a C0 coverage tool. In a nutshell, it determines (with a pretty high degree of accuracy) which of your codes are under test and which of your codes are not under test. The only downfall is C0 coverage can’t test something like “if condition_a && condition_b || condition_c”. It’ll just assume the code is covered if one of the conditions passes.
Saikuro measure the cyclomatic complexity of your code. What this means is that Saikuro measures the number of branches or paths through your code. The less complex your code, the easier it will be for you or another developer to maintain it.
7. Automate your deployments
Automation is your best friend. Actions with repeatable results are the best kind. (doesn’t really matter if they are good or bad). When it comes to automation, the best tool around is Capistrano. Capistrano should be the first thing you should install after you get your project installed. Being able to automate your deployments from day one will only save you time in the future.
8. Collect some statistics
A new niche is building in the Rails world. Every week new monitoring tools that actually know Rails applications are popping up. There are quite a few to choose from: New Relic’s RPM, FiveRun’s TuneUp and Manage, and ThoughtBot’s HopToad .
I can only talk about the ones I’ve used, so let me tell you why you should be running HopToad and TuneUp.
HopToad likes Rails exception messages. It is a great boon to be able to collect all the hiccups applications make and present them in a concise way that is free to all. Did I mention this service is free?
TuneUp takes another way in capturing statistics. In development mode at page render time, TuneUp calculates how long everything took to assemble itself. Are your pages taking forever to build? Don’t know the cause? Install TuneUp and have a look. You might find something you’ve never thought of. The best thing about TuneUp is that the source is out there, and if you want, you can log into their hosted service and share your results there for more critique.
9. Read other people’s code
You want to be a better developer? Read code. Read bad code. Read good code. Read your code. Read my code. Code reading is a skill that many developers skimp on. The ability to quickly decipher foreign code and understand it is a skill that is in high demand. This is especially true in the Ruby world where metaprogramming comes easy and the principle of least surprise is violated often.
10. Blog about it
Personally, I find out all types of information while reading blogs. Be careful reading too much, as if you are absorbing all the time, you aren’t producing, and everyone needs a pet project or two or three.
I blog here on Smartic.us. Most times I’m on point, but sometimes I drift off into other fringe topics. I blog because I want to share, and I love it when other people share as well. Keep in mind that you don’t have blog about curing cancer. Just blog about something that saved you five minutes. Or some obscure technique or command that you don’t want to forget.
The best thing about blogging is that you don’t have to blog often. Blog when you feel like it, and don’t make it a job.
I must admit that I do blog less than I want. Usually when I get the urge, I spout off on Twitter (i’m bryanl on there) to see how close I get to the 140 character limit.
Everyday I think I’m extremely lucky to have the chance to do what I like to do and get paid for it. There are many working stiffs out there who will never know this joy.