In der vergangenen Woche war ich in der glücklichen Situation, einen weiteren Kurs mit Gernot Starke, Peter Hruschka und Carola Lilienthal zu besuchen.

Der IMPROVE Kurs war nicht nur ein hervorragender Baustein im iSAQB CPSA Advanced Level, sondern ein hervorragender Austausch zwischen Entwicklern und engagierten Trainern.

Natürlich fand’ ich auch die konkreten Themen zum Refactoring auch spannend, aber nicht so sehr wie den Schwerpunkt auf Analyse (und auch wenn es schwer fällt, auf Evaluate).

Bzgl. Refactoring und dem Plädoyer von Carola, Architekturen bzw. Konzepte und Muster nicht nur “auf dem Papier” zu haben, sondern auch zu leben, reicht eigentlich schon diese Einschätzung alltäglicher Aufgaben:


Die (bekannten?) Top 5 Gründe für Probleme / Issues in Softwaresystem und Software:

  1. Unrealistische Zeitpläne
  2. Feature Creep
  3. Mitarbeiterfluktuation
  4. Interessenskonflikte von Stakeholder
  5. Produktivitätsunterschiede (“10x Programmer”)

Eigentlich war ich ganz froh, dass die Unterlagen (unverschuldet) nicht pünktlich da waren, denn ich habe mir endlich noch mal was mitgeschrieben. Da ich leider nicht so toll zeichnen kann wie einige, habe ich die mir wichtigen Impulse mal in eine unsortierte Mindmap gebracht (das Bild ist mit einer PDF Datei verlinkt):

Was mir – wie auch im Foundation Kurs mit Peter und Gernot – gefallen und Spaß gemacht hat, waren die praktischen Übungen. Übungen, die einen aus der Komfortzone bringen und insbesondere von Peter mit gefühlt großen Vergnügen forciert werden.

Für mich nehme ich – bei allem Spaß am Programmieren und refactoren – mit, dass meine weiteren Schwerpunkte ganz bewusst auf Softskills liegen werden. Schon alleine in den Übungen merkte ich wieder, wie wichtig es ist, sich auf andere Menschen einzulassen. Jede Architektur ist in meinen Augen auch immer ein Abbild des oder der Menschen dahinter und insbesondere ihrer Art, miteinander zu kommunizieren.

Und im übrigen, der beste Spruch bzgl. misslungener Kommunikation hinsichtlich Projektstatus, den ich aufgeschnappt habe:

| Comments (0) »


NetBeans IDE plugin supporting programming with Spring Boot

There are several plugins out there for supporting Spring development in NetBeans, but the


by Alessandro Falappa seems to be the most feature complete. At the moment installation must be done via manual download from here but that should be fixed soon.

You’ll get a really nice Spring property support:


Great integration with


And also some useful templates for different Spring artifacts (just one hint, Alex, make the suggested name uppercase):


I’m gonna pass this on to my colleagues and friends, I think it’s a very great addition to NetBeans.

| Comments (0) »


On dependency injection

Today is one of those days where I either react to short tempered or don’t get my point across:

This is what I’m experiencing those days, with some projects at work and also with Daily Fratze those days.

In younger (more current) projects I took really great care to avoid setter or attribute based dependency injection. You can do completely without – at least in a Spring based environment, where you can use an injectable entity manager as well.

There are enough blog posts out there that emphasize the advantages for testing, having only “complete” and ready to use instances in you hands and so on, but the above point is one of my personal main advantages.

When I first came across a real dependency injection framework nearly a decade ago I was like “wow, this is awesome!” and had suddenly @Autowired (or @Inject) at nearly every attribute and managed to create “god classes” in no time. At the beginning I still generated getters and setters as well… Not being aware, that the fields would be set via reflection anyway (removing them showed one flaw: How to test stuff without firing up the whole thing?).

Anyway, the “god classes”: Big piles of mud having a dozen collaborators or more and doing “everything”.

I’m not sure how that looks today with junior developers… Do they learn that stuff in university? Or is this temptation still real?

If you use constructor based injection you immediately get two advantages:

  • The pain of having a constructor with a dozen parameters, knowing that your thing *will* have too much responsibility.
  • A slap by your DI framework if you have circular dependencies.

Why use yet another tool in your build process to point out your obvious code smells when start up fails? If you really have to have that circle, there are ways (for example having a setter for that one dependency but than the “problem” is obvious and at last or framework dependent solutions).

Last but not least: You get dependency injection done right in my eyes, which is: no obvious need for a DI framework. You can construct and use your objects “by hand”, if you want to. That is especially true for the latest Spring Framework release 4.3, you can even omit the @Autowired on a unique, non default constructor.

The current problem I fixed today was like this: I have to create to entities that might depend on each other. For both creations I used a separate service and both services where directly accessing an entity manager and both where depending on each other (the one using the other for creating an instance, the other using the first for accessing stuff from the other entity). By introducing a data access layer in form of a Spring Data repository both could easily be decoupled. By further taking care that if a relationship between the two instances of the entities exist, the entities can only be instantiated completely (that is, fully populated, valid and ready to be persisted), I solved the circular dependency, got rid of an unnecessary BeanValidator in a service (I had to use a command object to call the other one) and remove somewhat along 40 lines of code.

| Comments (0) »


Talking about custom Spring Boot Starter at Spring I/O

2 weeks ago, i flew over to beautiful Barcelona, visiting Spring I/O, one of the (if not the) largest Spring and Groovy related conferences in Europe, primary organized by Sergi Almar.

I’m now running a user group for a year now which is mostly fun but takes some time if you want to do it right. I don’t want to imagine the work that Sergi pour into a full 2 day conference. Thanks a lot for it, it was well prepared and executed, from the speaker event, the event itself and the after show. Thanks a lot.

It was nice that my talked was scheduled right after the keynote, little time to build tension for me. The keynote by Stéphane Nicoll and Phillip Webb was really great and entertaining, though they said a lot about Boot that I wanted to mention 😉 Also Jürgen Höller was there and talked about present and future Spring and set the topic for larger parts of the conference: Reactive programming with Spring.

I was more than glad seeing Phillip and Stéphane at my talk and having their feedback. Thanks again. My talk was basically around about wether it’s “magic” or just really good design for extending Spring Boot and you’ll find it at my Github repository here: It’s a kind of magic? – Custom Spring Boot Starter:

Here’s a screenshot of the last step of the demo, in case you’ve missed it:

My conclusion: I’m very glad that I took the step “outside” my blog and I’ll happily do it again. In case you want me to speak at your JUG or similar event, just drop me a line.

The “rest” of the conference was really enjoyable. I learnt a lot about what “Reactive” actually is, what the current state of Spring Framework is and how the framework is evolved yet another time to work “as used to” and at the same time will be innovative. Listening to the people from the Spring core team was great and it was actually as kind as described here.

Daniel Fernández from the Thymeleaf project was there as well and spoke about the new features in Thymeleaf 3.0. I really like Thymeleaf (although I don’t think that JSPs have been bad, actually), but I wonder if it’s a good idea to extend Thymeleaf into doing JavaScript generation. We’ll see.

Here are some more posts I found about the conference:

Now I’m eagerly looking forward for the videos of the talks and pictures being uploaded somewhere… I’m really excited if I can stand to watch myself 🙂

| Comments (0) »


On software improvement

As you may know, I’m running the daily photo project Daily Fratze for more then 10 years now. What started as a simple PHP script in the late summer of 2005 grow into a Ruby On Rails application during 2006 and in 2010 i started writing the current version in Java, based on the Spring Framework. During those all those years, my database model stayed practically the same and has mostly seen additions so far.

I may have written it before, but Ruby On Rails was, despite all its hype, an eye opener for me. I was so deeply into desktop software, i really had no clue how to write web applications at that time and visiting some courses explaining J2EE (which Java EE was called backed then) didn’t help a lot, quite the contrary.

My love with Ruby On Rails last for over 3 years but our relationship broke eventually as I faced the several migrations from Rails 1.1 to 1.2, several 2.x and finally to 2.3 that really hurt though I did things as “in the book”.

The codebase I started in December 2010 is pretty much the same and something I’m only proud of as it was my way to come up with something like this and other stuff I do for a living.

Otherwise I wouldn’t really code anymore like this.

The last 1,5 years I didn’t do much on the site. I regularly updated some projects that have been extracted from the application but that was pretty much it. I put time into my Java User Group, the biking site and especially and certainly most rewarding, my family.

If you leave a software alone it ages and often not in good shape. If you skip a version of the libraries you’re using and then some you’ll often find yourself in a trap where one upgrade lead to dozens of others and minor upgrades that would bring security fixes and the likes leads to all kind of problems.

It didn’t come this far with Daily Fratze, i was only one version behind until last weekend, but this is how it starts.

Through my work with Spring Boot the last 2 years my first intuition was something like “Throw all but the entities away and start from scratch with boot” and I actually have 2 version of a new application floating around. One I started in December 2014 / January 2015 but abandoned very soon. The turn of the year 2014 to 2015 wasn’t a good time for me. I was highly depressed and for the first time in my life took an antidepressant and not only self-educated myself with beer. The question why programmers so often tend to run into this kind of problems is worth at least one another blogpost.

After somewhat finishing my biking application by even co-writing a book about it, i needed something new todo and startet a second try rewriting Daily Fratze from scratch and actually had some nice results this March.

But then I listened to Gernots Talk about the aim42 software architecture improvement method which needed some weeks to sink…

…and lead to asking myself the following questions

  • What are the main problems?
  • I’m I still happy with the UI or more specific (my) UX?
  • What is the cost on my family life creating a really complex and feature rich thing like the one I have again?
  • Can a brownfield project teach something I cannot learn on greenfield?

Outdated dependencies can become Daily Fratzes main problems. The UI, which pretty obviously has 2010/2011 style just works fine for me. It isn’t responsive in todays sense, but works better than half the Bootstrap based themes I tried and has less bloat. Yeah, it’s mostly still server side rendered HTML but guess what, I like it that way.

That leads to second: Yes, it does all the things I want and most of the stuff my faithful users want and are accustomed to.

The impact to my personal life was immense in March and April. Before going on a 9 days bike trip I was again at the edge of burnout. Working 9 to 10 hours a day, being a father and then coding until late after midnight takes its toll. Been there, done that. Don’t want to be there again.

And last and most important: As much as I dislike the way I programmed 5 years ago, I was the one writing down most of the requirements, listend to users and implemented it. So I know what is down there and I can change it for the better without the dead weight of not knowing why stuff is there.

Some weeks ago, on my bike in Denmark, I made the decision to stop working on a new version and made the old one a better one.

I started by upgrading all the dependencies (apart from the ORM, where I have to touch to many queries) and reduce most obvious coding style flaws.

That version went live on the weekend and already is faster:

First and immanent problem solved and fixed several bugs that neither me or a user has noticed before on the way.

The next thing on my list is: Writing real tests. I had no clue how to really do this 6 years ago. The tests I have crap and much of the code isn’t actually testable right now. So writing tests and changing stuff to actually be able to will have a significant impact.

So far, I’m really happy with my decision. My problem isn’t on the surface, I’m happy with the UI. And I’m happy with the algorithms I wrote. I’m not happy the way I wrapped them, packaged them and so on.

Gernots hint on stepping back and having a look at the bigger picture is of great value and even if its a pretty obvious hint, we rarely do this if we have the “start from scratch” option at our hands.

| Comments (1) »