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.