This is a screendump of a small project I did at work to get more comfortable with both Play! Framework and our own products. One of our products is an email lookup, and this project is simply a front-end for it built in Play.
To use the product, the user simply uses the query parameter “emailAddress” to specify which email address to look up. For example, http://www.some-domain.com/emailAddress=michael@yahoo.co.uk. Using the form just hits the site again, and adds the form value to the query parameter on the end.
Result page for /emailAddress=michael@yahoo.co.uk.
I did not take the screen dump at that time on purpose.. I really enjoy working in Play. It gives you a clear definition of your models, views and controllers, and is very easy to get up and running. It also comes with a great test functionality, and lots more. The Play website’s tutorial is great if you want to take it for a spin.
Want to mention this even though it is 5 weeks after it actually happened. Bournemouth Barcamp was absolutely worth the time, in case anyone googles for opinions on it when next years event is approaching. It is free, friendly, and had some interesting talks! Definitely enjoyed the presentation on Firefox’s Gamepad API (video demo here) from Mozilla Tech Evangelist Rob Hawkes.
Feels like about time browsers can be controlled by joysticks. And hopefully, we’ll see a lot of in-browser games (and other stuff) with gamepad support games this year. Not only in Firefox though, Chrome developers seem to have come a long way as well.
Working in pairs bring benefits, such as constant code review, knowledge sharing, improving team spirit, help applying good practices under pressure, and design discussions.
Sometimes, situation occur when the reasons for pairing can be questioned. For example working with code that the team understands and is very unlikely to introduce bugs, like style changes to a web page. The code produced during these sessions might not need code review, and there’s no knowledge to share in the team.
Another reason pair programming get criticism is because it collides with something developers are known to love, namely spending hours and hours on code without interruption, being in the zone or having flow. But even though I’ve only been pair programming a few months, I have definitely witnessed the existance of pair flow. When working alone, I’m usually easily interrupted and need music or complete silence to stay there. If the task is boring for too long, or if I get completely stuck, my mind can easily drift and I am likely to take up something else. In my experience, getting into a pair flow is much easier than the solo equivalent, and it is possible to keep up the pace even though the environment is a noisy. The pair’s discussion will simply mute the environment. When you get stuck, you can talk your way through it and boost each other’s morale when you’re feeling like throwing it all away.
Sequential pairing is for those times when pairing feels unnecessary. One developer completes a short and easy task, and simply hands the result to a colleague who can review the work and commit it. That way, you get a new set of eyes on your work, and you also share whatever you did for possible improvements, or a potential hand over. Complete soloing shouldn’t be done on anything advanced in my opinion, for reasons I want to write more about in the future.
I love looking at radiators. At Ebay, we had radiators showing the regular agile software project information. A table-like structure showing stories moving from Ready, to In Progress, to Completed and finally to Accepted. This was usually complemented by a burn-down chart to show if the team was on track.
In my current team, we’re not doing Scrum like at Ebay, but Extreme Programming. I love the concept of choosing which story to work on daily. Placing individual avatars to represent who is working on which story is less necessary if everyone is working on the same set of stories during the whole iteration. I’ve seen Information radiators where the developers use their real picture. Others use the characters from The Simpsons. We don’t have a theme. I’m represented by a photograph of a Swede (also known as a rutabaga) since English people have dry humor and I’m the only Swedish guy on the team.
A team using Simpson avatars to represent the developers. In this image, the radiator shows team members who are on vacation.
Since we’re doing Extreme programming, we’re doing pair programming all the time. After every standup, everyone chooses what to work with. Every pair put their avatars on the story they’re working on and crack on with their task. Naturally, it happens that we’re working in odd numbers, which is no disaster of course. But to keep it to become a regular occurence, anyone who is “soloing” is partnering has to put a cowboy hat avatar next to his own. This works a reminder to the solo coder that pair programming is the preferred way.
Something we’re not using, which I miss, are burn-down charts. A burn down chart works perfectly when the scope is static, which is the case when working in iterations. Changing stories is allowed, but it is not allowed to increase the number of man/pair hours.
A burn down chart displays the team performance compared to its estimation. There's a bump towards the end. It is possible that either scope was increased (violation) or some work that was deemed completed wasn't accepted.
Even if you’re working in iterations where the scope is indeed static, the customer is still allowed to throw in new stories in the back log of total work to be completed. Displaying this in a burn down chart is possible but becomes a bit awkward. Instead, one could use a burn up chart.
A burn up chart has a roof. When the roof is hit, the project is complete. If there’s more added to the back log, the height to roof is increased. The project begins at the floor, or at origo on a graph, and as stories are completed, a line is drawn closer and closer to the roof.
Burn up chart showing iterations along the x-axis, and completed stories (y-axis). The yellow line is the ideal completed stories per iteration, and the green line is the actual completed stories per iteration. The white line represents the entire project's back log.
This burn up chart shows how the total number of stories (or story points) have increased with time. The project is completed when blue meets red.
The need for radiators differ from company to company, but could and should be utilized differently. Before Alistar Cockburn coined the term Information Radiator, it was already used in plenty of places. “No accident in ___ days”, for example, reminding workers to follow safety procedure.
I hope to see more creative radiators in the future. Such as these ones..
Lava lamp and street lights showing the status on continuous integration machine.
During a brief discussion about refactoring at last iteration’s retro, a colleague mentioned that the feeling that refactoring has improved the code might be somewhat illusive.
Some changes are more obvious than others. For example, changing a data structure from a linked list to a hash table for a function that is used for searching will decrease the function’s time complexity from O(n) to O(1). The way these sort of refactorings change the function can easily be measured. Removing a magic number will increase readability and can be measured.
Other refactorings will be much harder to measure, such as changing names or moving around loops if-then-else-blocks. To be able to make changes to the names of functions and variables, one has to go through them to understand their meaning. Changing their names might not decrease the time someone else needs to understand the code though. In this unfortunate case, the refactoring has been pointless.
Magic numbers can mean several things, but the one I’m going to address is the sort of number which doesn’t give the reader any idea of why it has a certain value.
This piece of Java code gives an example of a magic numbers:
World world = new World(); world.addCountry(46);
Without looking further into the code, it would be very difficult to tell why the parameter sent into the addCountry-method is 46.
final int COUNTRYCODE_SWEDEN = 46; World world = new World(); world.addCountry(COUNTRYCODE_SWEDEN);
The code takes up more lines, but becomes both easier to read and more flexible. Sweden’s country code might be needed again, and by making it a variable it only needs changing at a single place.
JavaScript is a prototypal language. It is object-oriented, but with a different style than Java or C++ (which are class-based, as opposed to object-based). Inheritance in prototypal languages isn’t a relationship between classes, but between objects. The object which corresponds to the superclass acts as a prototype, which the other object clones.
Here’s a short example of using inheritance to attain polymorphism in JavaScript.
// Ball will serve as our prototype
function Ball() { }
// Ball's prototype is Object, JavaScripts root prototype
Ball.prototype = new Object();
// Setting the constructor method of Ball to the Ball function
Ball.prototype.constructor = Ball;
// Adding another method to the prototype
Ball.prototype.throw = function() {
console.log("Throw not implemented.");
}
function TennisBall() { }
// TennisBall's prototype is Ball
TennisBall.prototype = new Ball();
TennisBall.prototype.constructor = TennisBall;
TennisBall.prototype.throw = function() {
console.log("Threw tennis ball 56 meters.");
}
function BowlingBall() { }
// BowlingBall's prototype is also Ball
BowlingBall.prototype = new Ball();
BowlingBall.prototype.constructor = BowlingBall;
BowlingBall.prototype.throw = function() {
console.log("Threw bowling ball 2 meters.");
}
// Get any kind of ball
function getRandomBall() {
var randomNumber = Math.random(1);
var ball;
if (randomNumber < 0.5) {
ball = new TennisBall();
} else {
ball = new BowlingBall();
}
return ball;
}
getRandomBall().throw();
