Selling out -- Round II

For my first "real" job, I was hired out of college before I'd finished my degree. I left to move to The Big City (Chicago) and to make triple what I'd been earning with two half-time computer programming jobs in Iowa. It was rough, as move-to-the-big-city-from-Hicksville-and-get-a-real-job first jobs often are, but the company I worked for was good, I really liked the people I worked with, and I was both challenged to come up with innovative solutions and given the leeway (if not the budget) to implement whatever solution I deemed best. However, the company was a non-profit, and I got discouraged whenever I talked with any of my old college friends who had likewise gotten real jobs and were making significantly more than I was. So, after a couple of years I jumped ship, selling out for a 20% raise and a change of scenery (to Philadelphia). The people at my new job were nice enough, but I was now a junior developer, and had to follow corporate standards and have a lot of my projects designed by some one else. I missed my old job, but there was no way to go back.

Fast forward to today. I'm working for a company I like, with people I really get along with, and I have the freedom to implement whatever solutions I like using whatever technologies I like. It's taken me a good four years of consulting and networking to get where I'm at, and I'm finally happy about my job for the first time in a long time. So I probably should have expected the phone call.

As it turns out, somebody (a recruiter) I'd worked with when I was consulting had kept a copy of my resume. He'd never been able to place me because I was only looking for jobs in Lincoln, and there weren't many companies in Lincoln that used Java. Now, it seems, one of the few that did was looking for new senior-level staff. So, under the misapprehension that "it never hurts to talk", I sent an updated copy of my resume to the recruiter. "Just to see what they had to say". Well, what they said was basically "20+% pay raise, team technical lead, possible promotion to junior architecture position within a year". So, I did what anyone who had been cast aside by his corporate overlord at some point in his career would do. I jumped. Sold out. Turned my back on the folks who had given me the freedom to exercise my technical judgement and the support to make me successful at it, and headed on down the line.

[Actually, I'm still on good terms with them, and agreed before I left to make myself available to provide whatever knowledge transfer I could once they hired my replacement, but still...]

So now, here I am, with my big paycheck and my serious-sounding title (not quite "Lord of the Realm, Defender of the Faith, Emperor of the Enterprise Service Bus", but better than "Spec Programmer II") and I'm wondering how I'm going to fit in around here. Everybody's very nice, and I've been able to contribute and I have projects and everything, but I still don't feel like I did the right thing. I mean, I did (it wasn't just for the money, there were significant career-direction factors that played a part), it just doesn't feel that way yet.

The JAXP hits!!--More--

I had a spare moment, so I thought I'd shoot myself in the foot. Well, the shooting was unintentional, but it happens so often under these circumstances, you'd think I'd have figured out when to flinch by now.

Standard near-end-of-project clean-up, replacing any remaining "err.printStackTrace()" calls with proper logging statements and other tidying-up. I had in my notes "Add input XML validation". We hadn't had any problems with XML formatting before, but it seemed like a good thing to have when we went into production (can you hear the warning siren going off?). So I cons up a quick XMLValidator class with an inputIsValid() method and get that working. Plug it into the project and test all the various inputs we have, everything is happy, so I deploy it to our test server and have our external development partner have a go at it.

On the first run, he reports "Hey, it gives me a validation error." So we check, and sure enough, he's got one of the attributes misspelled. We fix that and re-submit and he gets another one. We check, and find another one. Fix and re-submit, get another validation failure. Only this time, we can't figure out why. The error message he's getting is "cvc-elt.1: Cannot find the definition of 'SchoolInfo'" (which is one of the elements in our schema). We can't find the problem, so I cut the XML from the server log and submit it on my test system where I can step through the validation with the debugger. Lo and behold, no problem! :/

So what's different between dev and test? Same app server, same jar file, whoops! I'm running Java 1.5 on my dev server, but the test server is 1.6 (why?) . Poke around a bit (OK, a lot) and find out that J2SE1.5 uses JAXP 1.3, while 1.6 uses JAXP1.4. Hmmm, so what's the difference? Well, it's not exactly documented anywhere, but when validating under JAXP1.4, you have to explicitly make the DocumentBuilderFactory (from which you create the parser that creates the document that you pass to the validator...) namespace-aware, and tell it that the resulting parser will be used for validation. Which makes sense, I guess, it's just that all this (and so much more!) is included with the JDK, and there's no real migration guide or set of comprehensive release notes that spells out these changes. And let's face it, if there were, it would be so big nobody would read it anyway. It would be nice if they could provide total backwards compatibility, but I know that's not always possible.

I dunno, I finally got Ruby 1.8.5 installed, and got Rails set up, and I'm working through Dave Thomas's Rails book, and I'm finding it's much quicker to develop in Rails than JEE. Of course, I haven't done anything much in Rails yet (and I don't know Ruby at all), but I've got a project that I had to shelve because it was taking too long to write in Java, and I'm going to dust off those notes and see if I can get it done in Ruby. If so, then I may have to roll out some Ruby utilities here at the orifice and see if I can get them entrenched. From what I can see, .NET isn't going to make web development any quicker than JEE, so I might as well push for something that is.

Back from Web Services Hell

Well, what a long, strange, nasty, standards-ridden trip it's been! I started working on my WS project, using NetBeans and the Sun app server (aka the Glassfish Project). Everything's fine, I'm able to create a web service, deploy it on the server, create a WSDL file, create a test client, everything happy little web-service developers do. Obviously, things were going too well. So I get ready to make the service available to a third-party company we're working with. Since I can't just stick my development machine outside the firewall, I find out where we deploy our other web services. Well, it turns out all of our other web services are written in either .NET (our "approved" development platform) or LotusScript. Obviously, neither of these were going to work. However, we had a couple of legacy apps that were written in Java, so there was an app server available, it just wasn't accessible to outside users. I was assured that opening a hole in the firewall wouldn't be a problem, so I should just go ahead and test my service and once it was ready they'd open it up. OK, sounds good, I thought, and handed over a copy of my WAR file. "Oh, we can't use that." Um, what? "We need an EAR file." My blinking was met with a blank stare. OK, fine, whatever, it is but the work of a moment to create an EAR file that has my WAR file in it. I hand it over to the powers that be (who are really pretty good developers, but not sysadmins) and ask that they let me know when it's been deployed.

A couple of minutes later, I get a log file. A big one.

Seems our app server only supports Java up to version 1.4.2 (yeah, three guesses which one that is...), and I made heavy use of JAX-WS (which uses JSR-181 annotations, all of which are part of Java 1.5). Being the clever, resourceful person I am, I immediately went bitching to my manager. Turns out that even the latest version of The App Server That Time Forgot didn't support Java 1.5. However, as soon as I started looking, I discovered that they were releasing a new new version, which allegedly did support 1.5. So I downloaded it and immediately discovered that its support was pretty much limited to running 1.4.2 apps on a 1.5 JVM ("No JEE 5 support for you!").

So I got a copy of the popular open-source IDE that the app server company bases its tools on. Turns out the IDE doesn't have a "server profile" for the new new app server version, so it wasn't able to talk to it (even though it supported the new release, and the new new version was a minor release of that). So I got the "toolkit" that was supposed to work with the new new version. Turns out it didn't support JAX-WS. So I got the Web Services clip-on/extension/module. Turns out it was only mostly compatible with JAX-WS (full compatibility coming RSN). It further turns out that once the Web Services c/e/m was installed, the toolkit was only marginally compatible with the app server.

So I fudged and poked and tweaked and Googled and grepped and read and read and read. I loaded updates, I loaded patches, I got beta code, I got alpha code, I got third-party code. I got add-ons and clip-ons and extensions and modules. Finally, I caught myself humming "One Piece at at Time" by Johnny Cash, and that's when I decided it wasn't going to work.

Hmmmm, what to do, what to do... Do I scrap my current implementation and step back to those golden days of yesteryear and rewrite my code using JAX-RPC interface semantics? Or do I take that idle Oracle server I built and put the Sun app server on it and have them stick that out in the open? A quick conversation with my VP and it all started falling into place. It boiled down to the fact that I was proposing we use hardware we already owned, so we didn't have to coordinate with anyone else, and it was an already-proven solution. I was a month past my original "I could probably write this in a week or so" estimate, so expediency ruled the day and we did the deed. I was able to finish the work quickly once that was done (Total time creating web service with four methods: 2.5 wks. Total time trying to figure out how to make it work on app server X: 3 wks.).

I just deployed the service yesterday, and I'm waiting for the "We can't use this — it's just what we asked for!" call. Guess I'll just cement the curse by writing up the documentation...