One Year Ago My Life Changed

One year ago I had an argument with my spouse. You might think “Boy, that must have been a bad one, if you remember it one year later!” But it was one of the best things that ever happened to me:

I was really angry and needed a way to vent, so I put on a pair of shoes, went outside and started to run. At that time I was really in bad shape. Definitely overweight. I felt how my belly fat sloshed around my middle and after like 500m I was breathing hard and had to walk for a while. Running and walking I needed about 20 minutes for 2.5 km and was quite exhausted afterwards. But I enjoyed it! My mood improved. And I did it again on the next day. And I’m running more or less every other day since then.

It changed a lot of things for me. Lost 12kg! Imagine you are carrying 3gallons of water around for every second of your life. And then you just drop them and walk around without them. It is an awesome feeling. I can run 4km in just a little over 22minutes. I can run 12km without a break. For some pants I still use a belt, but one year ago I used it because I wasn’t able to close the button. Now I use the belt because otherwise the pants would just slide down. I sleep better. My mood changed for the better. I can concentrate better.

I always thought running would be boring. But it turned out, running is the perfect sport for me: It gives you a time slot where your body is busy but you can think a lot almost without interruption. Thinking for one hour and a half about some difficult problem with nobody interrupting you … it doesn’t get much better, does it? Also running is flexible. You can do it always and everywhere: You can start at your door, or a hotel, there is just no excuse not to run. You can run on a hot summer day, in the rain, in snow and you need next to no equipment. Actually you can run with bare feet, if you are careful and it is quite enjoyable!

If you, like probably many readers of this blog, weigh too much and don’t move enough, change this NOW! Put on some comfortable shoes and start to run. Don’t run fast. Walk as much as you have to. Go as far as you can. Repeat tomorrow and three times a week after that.

Test your Dependencies with Degraph

I wrote before about (anti)patterns in package dependencies. And of course the regular reader of my blog knows about Degraph, my private project to provide a visualization for package dependencies which can help a lot when you try to identify and fix such antipatterns.

But instead of fixing a problem we all probably prefer preventing the problem in the first place. Therefore in the latest version Degraph got a new feature: A DSL for testing Dependencies.

You can write tests either in Scala or in Java, whatever fits better into your project.

A typical test written with ScalaTest looks like this:

  1. classpath // analyze everything found in the current classpath
  2. .including("de.schauderhaft.**") // only the classes that start with "de.schauderhaft."
  3. .withSlicing("module", "de.schauderhaft.(*).**") // use the third part of the package name as the module name, and make sure the modules don't have cycles
  4. .withSlicing("layer",
  5. ("persistence","de.schauderhaft.legacy.db.**"), // consider everything in the package de.schauderhaft.legacy.db and subpackages as part of the layer "persistence"
  6. "de.schauderhaft.*.(*).**") // for everything else use the fourth part of the package name as the name of the layer
  7. ) should be(violationFree) // check for violations (i.e. dependency circles)

The equivalent test code in Java and JUnit looks like this:

  1. assertThat(
  2. classpath() // analyze everything found in the current classpath
  3. .including("de.schauderhaft.**") // only the classes that start with "de.schauderhaft."
  4. .withSlicing("module", "de.schauderhaft.(*).**") // use the third part of the package name as the module name, and make sure the modules don't have cycles
  5. .withSlicing("layer",
  6. new NamedPattern("persistence","de.schauderhaft.legacy.db.**"), // consider everything in the package de.schauderhaft.legacy.db and subpackages as part of the layer "persistence"
  7. "de.schauderhaft.*.(*).**") // for everything else use the fourth part of the package name as the name of the layer
  8. ),
  9. is(violationFree())
  10. );

You can also constrain the ways different slices depend on each other. For example

  1. .withSlicing("module", "de.schauderhaft.(*).**").allow(oneOf("order", "reporting"), "customer", "core")


  • stuff in de.schauderhaft.order may depend on de.schauderhaft.customer and de.schauderhaft.core
  • the same is true for de.schauderhaft.reporting
  • de.schauderhaft.customer may depend on de.schauderhaft.core
  • all other dependencies between those packages are disallowed
  • packages from and to other packages are allowed

If you also want to allow dependencies between the order slice and the reporting slice replace oneOf with anyOf.

If you want to disallow dependencies from reporting or order to core you can replace allow with allowDirect.

See the official documentation for more details, especially all the options the DSL offers, the imports needed and how to set up Degraph for testing.

I’m trying to get Degraph into maven central to make usage inside projects easier.
I also have some changes to the testing DSL on my to-do list. And finally I’m working on a HTML5 based front end. So stay tuned.

And as always: Feedback including feature requests and pull requests is welcome.

I Don’t Give A Damn About Your Standard

When I get into a discussion about what library to use, or what tool to use, some people bring up the argument:

But it is the standard!

You know what? You can put your standard where the sun doesn’t shine!

Don’t get me wrong, some standards are awesome. I have boxes of hex cap screws. And boxes of nuts. And three different sets of wrenches. And I have never a problem of finding a matching triplet. Except once when I had a screw that wasn’t shaped according to the metric system. A PITA. The metric system and the norms for screws are so awesome because everybody adheres to them (at least where I live). And everybody adheres to them within reasonable precision. Of course if you measure exact enough, you will find out that certain pairs of screw and nut fit better than others. But I don’t care as long as I can put the nut on the screw and use it for fixing whatever needs fixing. And the final reason: I need lots of screws and nuts. If I ever only need one screw with a matching nut, I’d just get a matching pair and couldn’t care less if I find ever a matching nut again.

Unfortunately software standards often aren’t like that. For various reasons:

  1. They aren’t precise enough. I don’t care if two webspheres adhere to some JSR xxx or not. What I do care is: Does my web application work on that websphere. And if “that webserver” happens to be a different one, then the one I use in development, chances are, it won’t. That’s because basically there is next to zero tolerance in software. It’s not so much that software has to be perfect, or better than hardware. It’s more that with hardware it is often easier to determine what the properties are that matter, and what doesn’t matter.
  2. I’m not going to mix 5 different Dependency Injection Containers from 5 different vendors. I’m going to use one. The 10th production server will have the exact same version of the exact same DI Container as the first 9, or somebody will have to do a lot explaining. The basic use case for standards just isn’t there.
  3. The standard is not what some committee says, but what everybody uses. So, it is nice that Java Utils Logging is the official standard for logging in the Javaverse, but if you want to use stuff that everybody knows, you better use log4j or slf4j. By the way this one is true for ‘real world’ standards as well.

So when we talk about libraries and tools the questions are:

  1. Does it solve the problem?
  2. Can the developers use it?
  3. Does it work with the rest of the stack?
  4. Can operations support it?

And the answer to “is it a standard?” is “Go away!”

Softwaredevelopment, Learning, Qualitymanagement and all things "schauderhaft"