Thinking Inside a Bigger Box » Links

Video of my JavaZone talk about Continuous Integration

Johannes Brodwall — Sat, 11 Oct 2008 22:33:32 +0000

The videos from JavaZone are up.

Here’s my talk about Extending Continuous Integration, which talks about how I automatically run system level integration tests after every build.

Link: Waterfall works for risk-free projects

Johannes Brodwall — Sun, 28 Sep 2008 10:45:50 +0000

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.

JBehave 2.0 released

Johannes Brodwall — Mon, 08 Sep 2008 17:52:14 +0000

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)

[link] Package by feature

Johannes Brodwall — Tue, 29 Jul 2008 19:28:15 +0000

Stand up and be counted. Which one do you think is best of the following?

Package by layer:

com.app.controllers
com.app.model
com.app.repositories
com.app.exception

Or package by feature:

com.app.orders
com.app.invoices
com.app.products

I recently added a new site to my RSS reader. John O’Hanly just published a though provoking article about harmful java code idioms on JavaWorld. I don’t agree with everything he suggests, but I do find his point about “Package-by-layer: Preventing the use of package-private scope” very intriguing. John expands on this theme on his website.

The most important argument to package by feature is the following:

As a direct benefit of being at a high level of abstraction, the application becomes more self-documenting : the overall size of the application is communicated by the number of packages, and the basic features are communicated by the package names. [...] The fundamental flaw with package-by-layer style, on the other hand, is that it puts implementation details ahead of high level abstractions [...]

A point that he doesn’t cover, but that I would like to add is that if you organize your classes by feature, the task of delivering one specific user story will likely involve mostly one package. This is a very good test of whether the code is organized correctly.

Yet, package by layer is by far the most used way to structure code.

The question is: Will you dare to break with the herd and opt for a better solution?

“Hi, I’m Ruby-on-Rails”

Johannes Brodwall — Sat, 19 May 2007 13:55:47 +0000

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):

Click here to view on YouTube

Talk: Barry Schwartz on the Paradox of Choice

Johannes Brodwall — Sat, 31 Mar 2007 14:45:31 +0000

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.”

Link: Open Source in the Enterprise

Johannes Brodwall — Sun, 11 Mar 2007 12:45:01 +0000

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.

The talk is a bit fleeting and unstructured (and someone’s phone keeps ringing during the presentation!), but Rangaswami presents a lot of very interesting opinions:

He observes that the business environment in banking industry (and other industries?) are less focused on standards than before. He believes Open Source development has a better chance of achieving cooperation than standards in a business environment where “everyone want to be top dog”
He explores the model of Open Source Bonds. A company issues a bond promising to pay whoever develops X (for example) a sixth of what it would cost them to built it in house. He hints to a possible network of brokers and service providers.

Personally, I found the Q&A part the most valuable:

Question: “What should I tell the executives in my company who consider open source ‘high risk’?” Rangaswami talks about how there are only four interesting risks during software procurement: 1) The vendor disappears, 2) The vendor gets a different focus from you, 3) quality, and 4) security. Open source has a “build-in escrow” clause (just without the lawyers), which takes care of the first two as well as commercial software can. He further points out that within the industry, nobody is held accountable for software failure. This means that quality is not something you can buy. Finally, the inspection value when it comes to security is considerable.
Question: “What should the architecture department be doing?” This was the most interesting question to me. Rangaswami gives a long and thoughtful answer. The architect is not unique and different from everyone else, except that (s)he is more committed to learning. The architect should work through “control-freakery”, but through influence, advice and support. An architect should not “try to write an architecture (I am proud of being accused of not having one)”
Question: “What is the main cause of project failure in the software industry?” Rangaswami points out how we’re not very good at saying “no” to the customers. Project failure is caused by a culture that is unwilling to accept failure. What is “worse than failure”? Not learning from that failure because you’re not accepting it.

Link: Spring-MVC Cross-Site Scripting Vulnerabilities

Johannes Brodwall — Tue, 06 Mar 2007 19:54:56 +0000

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: Features, not tasks

Johannes Brodwall — Sun, 21 Jan 2007 17:00:26 +0000

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

Colorless Green Ideas Sleep Furiously

Johannes Brodwall — Sun, 21 Jan 2007 16:22:32 +0000

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.

Here is the best entry:

It can only be the thought of verdure to come, which prompts us in the autumn to buy these dormant white lumps of vegetable matter covered by a brown papery skin, and lovingly to plant them and care for them. It is a marvel to me that under this cover they are laboring unseen at such a rate within to give us the sudden awesome beauty of spring flowering bulbs. While winter reigns the earth reposes but these colorless green ideas sleep furiously. – C. M. Street

Now, that is “thinking inside a bigger box”.

Here’s another linguistic treat for you: “Time flies like an arrow. Fruit flies like a banana”

Source: wikipedia.