When test-driving your code, you shift between red (write a failing test), green (write the code needed to make the test pass) & refactor (clean up). But how do you kickstart this loop? What heuristics can you use to guide selection of the next test you write? This article summarizes the most common heuristics and highlights the one I use predominantly:
Continue readingPick the test that forces you to add one (and only one) new facet.
We need to talk about refactoring. Or rather, about the frequent misuse of the word, the dangers this encompasses and what we can do about it. Time to reclaim what is an intrinsic part of software development!
As with many words in the English language, people use the word refactoring for different concepts. It’s a human thing to do, but it keeps surprising me how open for interpretation most terms are in a “scientific” field like computer science. Just try to Google an exact definition for the concept of a unit test: you’ll find about as many interpretations as there are people writing about it.
Monday morning, 6 AM. You vault out of bed and into the shower, pick out your nicest outfit and leave for work. Finally, a new project. A breath of fresh air. The excitement of starting on a new team. The joys of digging into an unfamiliar codebase!
In this post I provide some techniques I use to get a grasp on a new codebase fast. It’s always fun to start a new green-field project, but let’s be honest for a moment and acknowledge the fact that most projects you will work on as a software developer will start from an existing codebase. These tips and tricks will help you hit the ground running, even when you land in a muddy brown-field mess.
Does the term “rewrite” scare the bejeezus out of you? Good. It should. A rewrite is not something to be taken lightly and should be your very last resort. There are less painful routes you can take, but what if there really is no valid alternative to The Big R?
Last year I had the opportunity to work on the development of a browser extension for multiple browsers. As I wanted to minimize the amount of browser-specific code and wanted to avoid duplicating my extension for every browser, I used the Crossrider framework. This post provides an overview of my experiences with developing a cross-browser extension using the framework.
The extension I had to create was meant to search through web pages as the user visited them and then add some extra functionality to certain keywords on the page. I won’t go into details here, but it’s something similar as Skype’s Click to Call, which does the same with phone numbers: Click to Call recognizes phone numbers and adds a button to the webpage to easily call this number through Skype:
Skype Click to Call in action – copyright http://www.skype.com
While everyone was sleeping out last saturday, groups of software developers worldwide assembled to participate in this cool event called global day of coderetreat. The concept of a coderetreat is simple: whereas the only way for other professions like musicians to get better is to train their skills by regular practice -just for the sake of practice-, software developers never seem to really “train” their skills. They get dropped in one deadline-prone project after another, but never really take the time to perfect their skills (or as Corey Haines likes to call this, get industry best practices under their fingers). Software developers can train their skills individually by performing code katas, or they can do so in group by attending a coderetreat.
Just as musicians get better by practicing scales and jamming with other people, developers can improve their skills by performing code katas and attending coderetreats.
One of the key ideas I took with me from Devoxx a while ago was this: mobile app development is hot. I wanted to gain some experience in this field so I decided to create a pet app to mess around with: WhereIsMyCar. It does exactly what the name implies: the app lets you take a picture of your parked car and it stores this picture and your current coordinates so you can easily find it again after a long night of coding. The reason I went for this kind of app is twofold:
After deciding on which app I was going to build, I hit the next bump in the road: should I go all-native, or should I create my app in a non-platform-specific way? Martin Fowler has an excellent infodeck on this topic here. Since I did not want to limit myself to the Android platform right off the bat, I went for the cross-platform option.
Cross-platform app development = HTML5 + javascript + device wrapper framework
jvaneyck 