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.
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.
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
In this post I will summarize some of the main principles of Jez Humble and David Farley’s great book on Continuous Delivery and share my experiences of applying them on software projects I’ve been involved in.
First, I’d like to share a story to give this discussion some context:
Meet Joe. Joe is a software developer. It’s a regular Friday afternoon, 15 PM. Before heading home, Joe has to start this thing called a “weekly build”. Joe makes sure everyone on the team has checked in their changes to the source control system. Joe starts the fully-automated build at the click of a button. The current build process takes some time, so he grabs a coffee. Five minutes later Joe returns to his computer, only to be shocked by what his monitor is displaying: build failed. Joe’s palms suddenly get sweaty, because he’s been in this situation before. It has been a week since the previous build was performed. He inspects the version control history: his team has committed tons of changes this week, most of them having self-explanatory descriptions like “Fix for Bug 1421, should work now”. The operations team will be breathing down his neck waiting for the binaries, since the quality assurance department expects a version of the product containing the latest features to start testing Monday morning. Having no idea how long it will take him this time to fix the build, Joe grabs another coffee and calls his girlfriend: “Don’t wait up honey, I’ll be home late.”.
Have you ever been in a similar situation? I feel your pain. Please read on for some ideas that will make your life easier and your boss happier. Otherwise, your team may have picked up the practices of continuous integration (or to a further extent, continuous delivery). Good for you!
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 