Aspirations

For every dream there is a reality check, but for every action there is an impetus. 

When OSGI-on-glassfish was the new hotness at my company, I spent 2 weeks trying to figure out how to get Smooks and Camel to load a flat file though EJBs. I rewrote it in 5 hours on Friday with SQL*Loader including an hour for load time.

Last week I spent 3 hours helping get a solid drools deployment done. I was only tertiary help. The code was written, but the deployment was just not there. If only they were just pulled from a DB....

I spent the rest of my time on Gatling. I am really new when it comes to Scala and I went down a lot of dead ends trying to load test a complex Vaadin app. I think I have an approach now but I'm still working on creating realistic workloads. 2 weeks and all I can do is click a button.

I just wish Vaadin came with a simple tool like SQL loader.

Blogger for Android sucks. It deleted text and now won't type. I finished this with something about golang being simple.
https://splice.com/blog/golang-improved-simplicity-reduced-maintenance/

Making peace with interfaces

While co-designing a new product, I had to also switch schools of Java.  

I came from an immutable-is-king school where all fields are public finals, constructors are private, and builders are fluent. In this school if you have a task you break it up into necessary data transfer objects. Any gateway communication like sql or soap is hand crafted and hidden inside methods of your data model.

I'm switching to a functional grouping of modules. In this way interfaces are designed while tests are created. Your tasks first get APIs, then get necessary data accessors. Public final fields are from this view too restrictive in data location.

For example in the first way a documentID is stored and a method to send a document then is in charge of using it.

In the second way, a document accessor interface is defined and an implementation is passed when any user needs a document, allowing any module to locate documents reliably and without duplication.

It makes pragmatic thinking more difficult while not limiting it. For this cost you get consistent reliable implementation visibility control.

More business and less programming if you ask me.

Re-implement would make the same mistakes

When you switch technologies you understand why things are the way they are. 

From pure Maven JEE5 we switched to "bndtools". bndtools is an eclipse plugin. bndtools is a way to rapidly work on bnd based projects. bnd is a rapid way to work on OSGI bundles. OSGI is a way to modulate Java code. A bundle is the OSGI module. 

QueryDSL is an API for database communication from Java. QueryDSL uses the pattern of creating a customized API based on your data model. It does this by generating Java code. I refer to this generated code as "Q classes" because they all start with Q.

The Maven way of generating these Q classes is with a plugin. Compiling and other things like testing and packaging is referred to as building. Maven has a build lifecycle which includes the normal phases like compile and test. One of the standard Maven lifecycle phases is "generate-sources". This phase is meant to cover exactly the use case QueryDSL uses, that is to generate Java used to code against. 

For the bndtools project my tech lead suggested eclipse's built in "builder" to call QueryDSL to generate the Q classes. I've never done that, took me a day or two of spare time. 

Of course this means the build box can't generate the Q classes. So now I have to it it in a Gradle task and call that from the eclipse builder. 

I miss Maven right now.