mp911de

Imagine you're talking about something today with your product owner or boss. It get's the highest priority for today, because it's cool or something. Tomorrow you're not done with it but have again a cool feature idea. Or a collegue of you. And guess what, it gain's again highest priority.

And what about the first topic? Forgotten again. Not having a mid-term or long-term plan can get a horror. Not having a product vision or a strategy for your product is even harder. Every day things can change, old stuff gets obsolete and there is no red thread what your system is and what it's not. How it behaves and how not. This causes uncertainty and the involved developers cannot be confident about their implementation. Always and ongoing discussions and changes of directions are the consequence. The whole product looks and works like a mixed litterbox which causes confused users and no one is happy with the application.

Don't become that team.

I’ve released today logstash-gelf 1.2.0, I’ll be available until this evening on Maven Central.
(more…)

Applications querying datasources can run into it. And perhaps you’ve seen it already: Custom built queries:

(more…)

Since today logstash-gelf supports log4j2. The experimental support allows dynamic field since log4j2 provides a very flexible configuration.

(more…)

Recently I gave logstash a try. logstash is a log management tool (processing, storing). It can push log messages also into elastic search. This setup is ideal for central logging. The easiest way to push log data into logstash seems to me to be gelf (Graylog Extended Log Format). It is a JSON-style format which can be GZIPed using UDP connections. There are a few implementations for GELF using Java (gelfj, gelf4j) which work nicely with Graylog itself. If you try to use them with logstash you’ll run into a few problems, which are caused mainly due the chunk size. gelfj has a fixed chunk size of 1420 bytes. Maven Central contains none of them (only some reassembled artifacts).

(more…)

Lots of companies I know tend to work still in a plain old style. Top-down bosses, either water-fall, ad-hoc or chaos-driven development. Long term release cycles and inefficient, expensive style of development. Continuous Delivery: What’s that, do they ask, why do we need such fancy things?

Many „something as a service“ companies are agile and deliver updates to their services seamless, without any down-time. As soon as they would go down for maintenance a lot of people would stop using it. Imagine Amazon or Google would go offline every day or week for a couple of hours.

In contrast to that, the least other companies go for efficient development, Continuous Delivery and all that other „fancy“ stuff. Some sort of agile development is the most you can expect from german companies. If you’re lucky, they’re doing Test-Driven development or Clean Code, but that’s it. So I started to investigate why this is.

(more…)

Some weeks ago SEMAT hit me: Somewhere Uncle Bob said something about Ivar Jacobson’s book „The Essence of Software Engineering: Applying the SEMAT Kernel“. This was reason enough to sneek peak and after a couple of minutes I bought that book.

(more…)

A couple days ago I wrote about Clean Architecture. I was also excited, how it will look like within code. How does it feel? How can I progress.

(more…)