Vaadin

I worked with Vaadin this week. Trying to nail down form items.

If it's generic, it will be avoided. If it's too specific, it goes too slow, if it's too optimized it will take away too slow to make.

We all just want a framework that just works. Fast to write, secure, future proof, performant.

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.

Bean mapping

I taught again this week. I don't know why o do it. Probably because I feel productive.

I worked on bean mapping. Having a layer protecting your exposure to third party helps... but at what cost?

I'm building that layer now for our intf with WebLogic. I don't quite understand why it was used in certain places but such is life.

Building it after is in that case of: it works, why spend time on it????? And the answer is technical debt. Startup costs, security costs.

People try to tack on lower cost of future maintenance but I don't buy it. If your car works, and someone offers you a service saying: "I'll replace your air intake manifold for $1,000, it will save you wear and tear on you engine" I'd say, "Hey. There were smart people testing and designing this originally, where is your proof yours is better?"

So we get layers. The most important thing in our program is our capability of changing out our ORM if you looked at lines of code.

The things I want to change are to go stackless; use akka, or vertx. Where is that bean mapping capability?

Web layers tell you to pollute your beans with json, request args, and post method mapping. DB layers tell you to pollute your beans with column, table, and join information. Service layers tell you to pollute your bean with validation information and XML information. So we end up with bean mappers.

I like raw java mappers (static converter utils) for the task.  Orika, Dozer, w\e just add bad, half implemented DSLs to learn the edge cases for. The java converter is easily updated and doesn't require anything from either layer other than setters.

Ubuntu time

This week was a little all over the place.  I helped debug jpa queries(equals in jpql is case sensitive. Why would you expect it not to be???) I helped tighten up ssl on IIS6.(5 registry keys to create? Really? I hate that system config location is the same spot as app config locations. Linux is no better with /etc...) I wrote 126 java interfaces. (Daos for a very large web service). I wrote Ruby to spit out java for the osgi services that needed all those interfaces. I learned about gradle and wrote a dependency downloader script. I used that to compare cxf bundle (58 mb with a bunch of jars) and metro osgi (38mb with only a few jars.) Metro also looks more promising because its the jax ws reference implementation. I learned about dependendency resolution with scr's @Reference. I learned about enRoutes "compile-only" hack to make sure apis are pushed out with an implementation and never included in an osgi runtime alone. ( you have to add the api package to exports in bndtools view of your provider project's bnd.bnd and it will copy the class files. It's a bit too magic for my taste but whatever)

And I went in for 4 hours (3-7pm) Saturday so I could install Ubuntu on the server I bought. I'm a bit worried about weblogic... But it will force me to finish the bamboo deployments on check-in.... Hopefully it will force me to finish the weblogic spi jar to wrap our weblogic dependency as much as possible...

Also I need to write a basic telnet network stack for LVM. That is ULTRA dumb that you need to be physically at the server to enter the LUKS pw to decrypt at boot time. Like. WTF. I think I saw some solutions but they seem old.

When the boss skips town

This week my boss left town. A patch release went in but needed a patch release itself. That also went in.

We have an intern and I didn't quite know how much freedom to give. We deploy on WebLogic 10.3 so there are limitations with what one can build. Also my experience with that platform enables me to see issues beforehand.

Additionally, I came up with a deployment idea. The intern knew nothing of ears. I am also struggling to explain mocking, as I just read the tutorial myself.  The main algorithm of the app I came up with as well. I even just now writing this came up with an idea for a DISPLAY_WHEN column that is a velocity template to determine if a question is displayed or not.

In other news, I've been working with bndtools on Eclipse Mars. I've been trying to do it right: interfaces with javadoc and unit tests will be mockito like the intern is doing. We will see how much that slows things down.