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.

This Norwegian languauge article pertains to an article in the Norwegian news magazine “Ny Tid” and my letter to the editor. (Dette er mitt debattinnlegg som ble publisert i Ny Tid 11. juli. Innlegget er oppfølging til Christian Lundestads veldig gode artikkel om åpen kildekode i ny tid 27. juni.) Som lead software arkitekt i Bankens [sic] Betalingssentral (BBS), leste jeg Christian Lundestads artikkel om åpen kildekode i Ny Tid 25/2008 med stor interesse og mange samtykkende nikk.

In Let your examples flow, Dan North describes how “Don’t Repeat Yourself” (DRY) isn’t necessarily the most important guideline for tests. While I agree with his conclusions, I think the DRY principle is still extremely important for tests. Dan’s point is that the most important attribute of tests is that they can be read like a story. “Store a page with the text ‘foo’ in the database, simulate a web request, check that the word ‘foo’ is present in the response”.

The TED conference has some amazing talks. If you never knew you were interested in car seats for children, classical music, or feet (yeah!), some of these talks will blow you mind. A recent video that really moved me was Benjamin Zander, the conductor of the Boston Philharmonic. His insights and inspiration is invaluable for everyone who considers themselves a leader. “The conductor doesn’t make a sound, he depends for his power on the ability to make other people powerful… I realized that my job was to awaken possibility in other people.

At the last meeting in Oslo Lean Meetup Geoff Watts talked about BTs transition to agility. The most memorable part to me was when BT transformed a huge, waterfall type project with a delivery schedule measured in years into an agile project. The project set out to convert all BT customers to a new network with a brand new set of services. The new objective was simpler: Deliver one service to one customer in eight weeks.

People always talk about how learning is something that happens in groups. Last week, I got reminded of the point as a task I had previously struggled with alone became trivial in a pair programming episode. The first time I tried coding “a bowling scoring program” was in 2001. I’ve practices the exercise many times later. In 2004, I tried to write a more challenging version: Write a program that prints the numbers that should be displayed on a score board for a partially played game of bowling.

Three years ago, I was asked by one of our teams to give advice on how they should write a parser for a structured file format. Just having read up on SAX again, I recommended that they looked into designing it as a push parser. A push parser works by the design that the parser generates events each times it reads parts of the input. These events are sent to an event handler, which then builds up the internal object structure or whatever the program needs.

Warning: This article requires a lot of editing love before it is very useful. It might be somewhat incoherent. Read at your own risk. ;-) Silo (software): A silo system cannot easily integrate with any other system. In software, the term “silo” is used to refer to a system that is constructed as one unit from the front end to the data storage. Everything is tied together to work with the rest of the silo, but not with other elements.

This article is a Norwegian-language version of my article Four bold claims about SOA. Dette er et utkast til en artikkel jeg ønsker å få publisert. Jeg setter stor pris på tilbakemeldinger om uklare tanker og formuleringer. To av de vanskeligste problemene vi møter innen programvareutvikling er integrasjon og det som gjerne kalles “business-IT alignment” eller forretningsorientering, altså: IT skal understøtte virksomhetens strategiske mål. Tjenesteorientert arkitektur, eller Service Oriented Architecture (SOA), hevder å kunne løse begge disse problemene.

In my last article, I showed how to implement authentication with Ruby on Rails. But security is about more than simple login. For many applications, we want to grant permission to manipulate a resource to a set of users. In this article, I will guide you though adding functionality so that users can modify the permissions for who gets to edit an article. Before we start implementing access control, we should get our application ready by encapsulating all access control checks.