Maven woes

Maven just doesn't seem to be everybody's friend. I for myself cannot say that I have really grasped it yet.

Recently I tend to come quite frequently across projects that have maven related problems.

There are also more and more and more signs floating in the cloud...

This picture now seems to pinpoint the maven-woes in a funny way ...

Journeyman: Apprentice to Master or Novice to Senior?

I consider myself as a journeyman. I tried to move on when it was time. I am far from being settled.

Now I came across this post by 'Uncle Bob' Robert C. Martin that formalized my gut-feelings: Multi-dimensional Seniority

picture by objectmentor

I am in the consulting game. I fancy that this puts me on the path of Jasmine in the picture above... but maybe I am just a coding wore...
This leaves me still pondering about transforming from coding whore to opinionated developer. Is being opinionated a quality for the bumps in Jasmines career?

follow me on twitter, I need some friends :-)

Don't call us, we call you ...

This is a very insightful statement from FubuMVC:

Many frameworks are very draconian in their requirements of the application consuming them. They require your application inherit from the framework's base classes, implement their interfaces, etc in order to gain the framework's functionality. In this, more common, style of framework design, the application serves the framework.

That's probably the best subsumption of the ideas behind POJOs as a design concept.

follow me on twitter, I need some friends :-)

Lord of the Domain

Domain-Driven Designis the Lord of the Rings of computer books.

- David Laribee,
Deep Fried Bytes Episode 7

follow me on twitter, I need some friends :-)

Drag&Droppers vs. Console-Freaks

In Episode 392 of DotNetRocks Carl and Richard discuss with Ron Jacobs. When they come to M, the modeling language in the Oslo Project, they talk about developers that don't like Drag&Drop-Editing (Designers, Wizards, complete IDE-Integration, whatsoever ...):

... some people really like that. They are like: That's great! And then there is a group of people who are like keyboard guys. They hate to take their hands off the keybord and even touch the mouse...

They give the impression, that those kind of developers are stuck in some age long past, likely ignoring reality and completely indulged in their religious debates about vi versus emacs ...

That's an attitude I often encounter in marketing-infiltrated management persons.

They think that they are enlightened because they have seen some shiny click-and-go demo of the newest flavor of The Application-Generator(tm)... and they think that all the developers out there in the trenches of enterprise IT just refuse to see the light, because their convoluted brains cannot grasp that their existence becomes irrelevant since The Application-Generator(tm) would make coding unnecessary ...

Thats just snotty ... most developers have had experiences with Drag&Drop-Wizard-Whatsoever-Editors, but they have been burned!

Most of the stuff is just demo-ware! A heavy toolchain focussing on an initial surprise effect.

But the resulting solutions are just not elegant, not sustainable and not scalable from a development perspective!

The problem with the Designer in the recent .NET Entity-Framework seems to be a typical example for this ...

Another thing are tools that only integrate into the IDE and do not offer a standalone (this usually means 'command-line') execution. This is just not scalable from a development perspective, because it prevents automated builds! Not having to touch the mouse is not really a personal issue here!

follow me on twitter, I need some friends :-)

Java EE Testing Workshop

Last week I was holding my semi-annual workshop about Java EE Testing at the Software Schule Schweiz (SWS).

The workshop material can be downloaded here.

One thing I did newly include was EasyGloss: a framework for simplifying unit testing of annotated classes that require injection in order to function.

Apart from that I did only very few changes compared to last time. This time was the first time where my preparation effort was actually quite low, which made me somehow proud ...

... but then again, the whole topic is out of fashion as I learned in this interesting presentation: Testing is overrated. Maybe I should start looking for another topic ...

follow me on twitter, I need some friends :-)

Only dead fish swim with the stream...

While I am still pondering about my idea of the transformation from Coding Whore to Opinionated Developer, I stumbled over some quite opinionated statements:

Joe Armstrong (inventor of Erlang) about object oriented programming:

When I was first introduced to the idea of OOP I was skeptical but didn't know why - it just felt "wrong".

Graeme Rocher (founder of Grails) about Maven:

I think only Java people would be willing to accept a build system like Maven with all its complexities. Any other community would be like "what the hell is this?". For me Maven is the EJB2 of build systems: over complicated, over engineered

follow me on twitter, I need some friends :-)

Give me a hint: How are programming languages related to problem domains?

From Jay Fields' The Cost of Net Negative Producing Programmers:

Java and C# are not silver bullets. The languages are good solutions to a certain class of problems, using them for problems that could be better solved with a different language stagnates the growth of other languages.

Now I am wondering: Is a general programming language really predestined for certain kind of problems and not suited for other kind of problems?

I can see that performance could be an issue. But apart from that, is the problem domain really a relevant aspect for choosing a language?

I could agree that platforms and frameworks could be targeted a certain problem domains, but I cannot really see if this is true fro languages. I also think reality shows that the same kind of applications can be solved with all kind of languages, and the results are equally valuable.

I think there are much more important influences for choosing a language than the problem domain. Like experience of the team, available knowhow and infrastructure, reusing investments and creating homogenous environments ...

Can anybody explain to me how the problem domain is relevant for choosing a general purpose language? I would be very much interested in examples ...

I agree that DSLs offer a whole new perspective on this topic, but we are talking about general purpose languages here ...

I also agree that there are niche problem domains (like scientific calculations) that could certainly better solved with special languages, but again, we are talking about general purpose languages ...

follow me on twitter, I need some friends :-)

Followup: From coding whore to opinionated developer?

My post "From coding whore to opinionated developer?" earned some comments which put me in the position of a spoiled whining smartass...

Now Jay Fields has posted The Cost of Net Negative Producing Programmers.


Here two quotes that remind me of the theme of my post:

These NNPP architects build entire armies of NNPPs around them and single-handedly waste millions, if not billions of dollars, annually. And, potentially worse, they ruin or at least drastically hurt the careers of eager to learn teammates.

I do think there are things we can do to help move the industry in the right direction. The good programmers can refuse to work with bad programmers. That might mean moving to an organization where that's a goal, or making that a goal of your current organization.

... it seems that Jay is quite opinionated!

(Eric Evans from Domain Driven Design did say something in the same direction.)

On the same front Obie is blogging about Attributes of Good Clients.

follow me on twitter, I need some friends :-)

From coding whore to opinionated developer?

Have you also been on projects where things were done entirely different to your own opinions.
Maybe they totally contradicted values that are most important for you? But you coped and went along?
Did you feel compromised, even dirty, for not resisting? Did it make you feel like a coding whore?

37signals and Ruby on Rails shaped the concept of opinionated software.

As most ideas from 37signals, I like the concept of opinionated software.

Now I am wondering if the concept of being opinionated could be extended from software to ... the developer?

When coming to a new project, take a good look! As a developer you don't have to put up with everything! Evaluate your opinions:

No Source Control? - Where is the exit, please ...

No Unit Tests? - Thanks, I am out ...

Continuous Integration is a foreign word? - Sayonara from me ...

Staging, what is that? - Good bye ...

Stakeholders are not readily available? - These boots are made for walking ...

...

Is that being arrogant?
If you have opinions, why should you not commit to them?

follow me on twitter, I need some friends :-)