What I Work With in 2010: Day Job Edition
Having taken a squeegee and cloth to the website, now is as good a time as any for a quick overview of the tools I ply my trade with. The tools I discuss are ones I spend significant time working with (or wish I had more time to work with) and/or require a deep knowledge to work with effectively. If you have a yearning desire to know more about my recent adventures with Crosslogix, Python, Actuate and other similar members of the special-case tools menagerie, do write and I’ll try my best to satisfy you.
In software development, for better or worse, who you are is as much a function of what you work with as anything else might be. Below I discuss two major toolsets I expect to be working with in 2010 as part of my professional employment; for brevity’s sake I’ll defer discussion of my after-hours preference to a later post. Read on and form your own opinions as to my character.
(Nothing following should be construed as my employer’s opinion on technology, but rather mine alone. This is hopefully obvious, but best I not assume anything.)
My 15 year companionship with Java continues, but the vigor left the relationship long ago as its metamorphosis from “The Language That Would Change Everything” to “The COBOL of the 21st Century” proceeds unhindered. It does a variety of jobs, everyone knows it, enterprises large and small run themselves on it, there’s an API to accomplish pretty much everything short of raising the dead (and there’s probably an in-process JSR being designed to handle that case.) You won’t go wrong with Java and no one is getting fired for knowing it, a truth which keeps many of us satisfactorily employed. But it’s an empty pairing these days, with most of the late stage JSR’s being either driven by the biggest-of-big-enterprise edge cases, exotic refinements to existing capacity and the very occasional knee-jerk reaction to some darling feature of another language. It’s a sad endgame to what was an exciting platform once upon a time. With IBM and Oracle the two large pachyderms in the room determining most of the real priorities this isn’t going to change anytime soon. I keep at it and keep working, since my expertise in it keeps me in employ. But I have no expectations for satisfaction beyond that. As long as it keeps the trains running on time and the PT result forms flowing it’s doing its job and I can’t ask any more of it. Which is a shame.
The Oracle ecosystem is somewhat more stimulating, simply because it’s relatively new to me. My employer has gone all-in on Oracle; we collectively are learning quite a bit about many tools in a short amount of time. Some of these are well-known and well-regarded (the all-conquering Oracle database technology), some well-known and somewhat of a pain (eBS, which does a great job of running a business as long as your business runs The eBS Way), some obscure (most of their security stack), a bevy of rebranded/merged/repurposed middleware (Fusion), plus the legacy Oracle technology used to run everything else, zombie-fied worse than Java but untouchable until the Fusion stack matures and is better integrated (OAS). Keeping track of the acronyms alone is a full-time job, let alone actually wrangling the bits. Way too early to have set opinions on this, but it is clear we will have the same struggles adapting the The Oracle Way to the The College Requirements that every other business does when it hops on the Enterprise Software horse. We’ll end up with either a model ERP implementation or Frankenstein’s monster on application servers and I’m not laying odds as to either at present.
