Video of my JavaZone talk about Continuous Integration
The videos from JavaZone are up.
The videos from JavaZone are up.
I don’t normally post just a link to another blog, but More thinking about “Agile” vs “Waterfall” by Jason Yip is just too important. It the most well-argued, well-referenced, short post I’ve seen about the subject. Here’s a taste:
Be careful about saying that Waterfall is more disciplined. The waterfall model is simple and structured but the “discipline” is in following prescribed steps as opposed to “discipline” in thinking. The second kind of discipline is by far the more important.
I’ve learned the value of dealing seriously with connecting requirements to the actual code. The JBehave project started work to make formal, “business friendly” requirements into executable specifications, but due to limitations in Java, it was very clunky to use. JBehave 2.0 has just been released, and it has a much better model.
Here’s a specification:
Story: Play Tabs
As a music fan
I would like to convert guitar tabs to music
So that I can hear what they sound like
Scenario: My My Hey Hey
Given tab
e|---------------------------------
B|---------------------------------
G|---------------------------------
D|----------0--0-------------------
A|-0--2--3----------2--0-----0--0--
E|------------------------3--------
When the guitar plays
Then the following notes will be played
A0 A2 A3 D0 D0 A2 A0 E3 A0 A0
The scenario is connected to Java code. While JBehave 1.0 used anonymous inner classes to do this, JBehave 2.0 uses annotations:
public class PlayTabSteps extends Steps { @Given("tab $asciiTab") public void tab(String asciiTab) { } @When("the guitar plays") public void guitarPlays() { } @Then("the following notes will be played $notes") public void theFollowingNotesWillBePlayed(String notes) { } }
For more, see Ray Greenhall’s tutorial. The tutorial is good, but it suffers from an unintended large weakness: The second half of the tutorial contains the convoluted design that is often the result of overuse of mock objects. The last year, I have spent more time removing mocks from code than actually using mocks, and I’m just about fed up with mock-ish design.
Can you spot the nefarious effect of the mocks on the design? How would it have looked if the example had followed The Simplest Thing That Could Possibly Work?
(Still: A very good introduction to a promising new tool)
Stand up and be counted. Which one do you think is best of the following?
Package by layer:
Or package by feature:
Inspired by the “Hi, I’m a Mac” ads of Apple, Gregg Pollack and Jason Seifer has made these cute Ruby-on-Rails ads (featuring Ruby-on-Rails versus Java and Ruby-on-Rails versus PHP):
I have been watching videos from the Technology, Education and Design conference (TED) all afternoon. One particularly fascinating talk was Barry Schwartz talking about The Paradox of Choice. I find an almost Buddhist-like understanding of the problem of humanity in the modern world in his talk. But it was the closing words that fascinated me the most: “If you shatter the fishbowl, so that everything is possible, you don’t have freedom, you have paralysis.”
CIO JP Rangaswami at investment bank Dresder Kleinwort Wasserstein talks about why he considers open source a corporate IT asset. In this talk, Rangaswami describes how DrKW wanted to create an internal incubator environment in order to combat skill attrition in the late 90s. In the course of doing this, they acquired OpenAdaptor and discovered almost accidentally benefits of the open source development model.
Sverre Huseby examines some security issues with Spring-MVC. As it turns out, the Spring JSP form-taglib provide no HTML-escaping by default, making it very easy to get Cross-Site Scripting vulnerabilities included in the code. The article comes complete with a standalone application that illustrates the problem.
Ron Jeffries reminds us: “… hours aren’t burndown. Accomplishments are. A team that focuses on hours isn’t focusing on getting things done.[...] The point [...] is getting backlog items done, not getting tasks done” This really cannot be said too often!
Via Jason Yip
This phase has been stuck in my head lately: Colorless green ideas sleep furiously. It was first used by the linguist Noam Chomsky as an example of a sentence that is grammatically correct, yet has no meaning.
Interestingly, in 1985 this was taken up as a challenge. The result was a literary competition to write a short text that gives the sentence meaning. Before you continue reading, think for a while about how the sentence could have meaning.