Smidig 2010: Norges største smidige konferanse Har du fått med deg at Smidig 2010 arrangeres 16.-17. November på Radisson BLU, Holberg plass i Oslo? Konferansen har åpnet for foredrag. Early bird prisen på billetter varer KUN TIL TORSDAG, så det gjelder å bestemme seg fort! Opplev vårt unike format, med over 70 lyntaler og 100 diskusjonsgrupper! Smidigkonferansen er den årlige nasjonale hendelsen som samler mennesker fra alle typer roller i IT-bransjen; prosjektledere, produkteiere, utviklere, bedriftsledere og testere og flere.

At JavaZone 2010 I will be giving a lightning talk on APIs that use dynamic subclasses. These APIs make it possible to do things in Java that seem like pure magic. Here are some ideas of what you can get from these APIs and a look under the hood, so you really understand what’s going on. Mockito - “the best Java library named after a summery drink” Mocking is a hotly debated subject within testing camps.

As I release more frequently, I start to focus on automating the actual process of deploying a release. One of the most powerful steps of automating deployment is to automatically upgrade the database schema. This technique first saw mainstream use with the Ruby-on-Rails framework. Today, there are several mature tools that will help you organize and execute database changes (Scala Migrations, Ruby-on-Rails Migrations, dbdeploy, Liquibase, dbmaintain). And if none fit you perfectly, it’s easy to create your own.

A software architect who doesn’t care about what his system is supposed to do isn’t worth his salt. For the term “software architect” to hold any meaning at all, it must be to describe someone who understands what the customer needs and designs a system that is fit for this purpose. Sometimes, however, people talk about “technical architects”. I have myself been guilty of falling into this category once or twice myself.

If you want to release your code frequently, you have to automate the release process. If your software interacts with shared components or other applications, the release script may have to update shared configuration files. In this blog post, I recall when I solved this with a crontab file. The problem My application needs a cron job. However, the operating system user that runs the application has other cron jobs it also needs to run that don’t belong to my application.

If you want to release frequently, a problem you may encounter is that some features, even though functionally complete, don’t stand well on their own, but require other features to be valuable to the user. If you want to release the system in this state, you need a way to hide features. A Feature-on/off-switch is a simple idea for dealing with this. A feature-on/off-switch is some mechanism to hide features from a system.

As a general observation, it seems that when software architects try to solve general problems, they come up with horrible designs; when they solve specific problems, they come up with good designs. Designs made without reference to a problem often become complex and not very fit for purpose when we’re solving specific problems. As a general rule, avoid generalizations. Some examples: An Enterprise Service Bus may create a big project and maintainable needs for something that turns out to be only a few simple integration points.

When developing a system that people use in their day to day work, I often meet the following requirement: “A user should be able to see all tasks from each functional area on a single screen.” This requirement requires integration with all parts of the system, making it architecturally costly. Luckily, the requirement might often not be needed at all! Everyone will tell you: The most powerful technique for dealing with a large problem is breaking it up in smaller problems.

“Design” is a verb, not a noun. If I want to create a good program, studying the process of getting there is much more important than the resulting software. This is why I use coding katas as a form of study. I find an interesting problem problem and then solve the same problem over and over again. In this blog post, I will focus on six principles of software design. I will illustrate each with a screencast from a kata.

My colleague Thomas sent me a very interesting link about attempts to solve Sudoku using test-driven development. The article, somewhat unfairly, pits Ron Jeffries’ explorations of Sudoku using test-driven development against Peter Norvig’s “design driven” approach. I found both attempts lacking. However, while Ron Jeffries freely admitted that he didn’t even know the rules of Sudoku when he started, both Norvig himself and his readers fawn over his solution. I didn’t find it very understandable.