I noted in a previous post that I was changing jobs, hopping over to the Java side of the fence. Note that I had spent the past two years building enterprise Microsoft .NET systems, so this was something of a change of pace. Not that I hadn’t done Java before: before those .NET 2 years, I was building Java systems for a government health research project. [Noting a habit of mine to change technologies, and to use the word ‘note’.]
More than a month into the new job, it’s a good time to take stock of what I’m doing, and what the surprises have been:
1) Knowing Java is no longer enough. To accomplish things in Java, you seem to need to know a large variety of frameworks or open source projects. On our project, we’re using AppFuse, Struts, Tiles, Hibernate, IBatis, and Lucene, just to name a few. (Trust me, there are more.) Note that while I could have told you what most of those do before this job, I had little-to-no hands on experience with any of them.
2) The toolsets used are radically different than my experiences in Visual Studio and SQL Server. Eclipse and Oracle are the tools of the day, with a hearty dose of Ant and CruiseControl. Subversion is also a different beast than was StarTeam, PVCS, or Visual SourceSafe.
3) Unix administration background is a big plus. Although our local dev environments are Dell laptops, our development server uses RedHat SE. There’s no handy EventLog pane in a Unix environment, and vi has become my friend again. I generally get out of the way when there’s a real admin problem, but have reminded myself how to do some rudimentary administration stuff, and can sudo with the best of them now.
4) The set of unit testing tools is much more comprehensive. Sure, we have JUnit, but then we have StrutsTestCase, MockJ, and Canoo, too.
5) Oh, forgot to mention Spring. Its pattern of bean injection is cool, so long as you set up your context files well, but I haven’t quite got the hang of its AOP logging. I’ll remention AppFuse, too, as the way it generates many things causes some learning curve in and of itself. Think you’re looking for struts-config to put your info in? Welp, AppFuse makes use of XDoclet to generate that struts-config, so it doesn’t actually exist in your source tree, only in your generated build output. AppFuse also uses XDoclet to generate your database schema, but XDoclet only goes so far in that task. To actually do things like set up a database index or set a start value on a sequence, you’ve got to do some monkeying around with the build process.
6) Eclipse is cool. It deserves a post all on its own in the labor-saving stuff I’ve been able to make use of, and I’m certain there’s more I haven’t yet tripped across.
7) “Tripped across” is a good metaphor occasionally for how we end up solving problems. Trying to figure out how to do something with Acegi, I go wandering the forums and the blogs and the Wikis trying to find someone who’s done something similar to what I want to do. Bam! Got it! It’s something that’s got supported classes in the jars I have locally. But that stuff wasn’t even mentioned in the documentation, other than in the javadocs, and the javadocs of course don’t tell you how to actually use the stuff, just what to pass into its methods.
Think that’s enough for now… given the amount of I’ve picked up over the past month, you’d think I hadn’t gotten anything else done besides wade through documentation and code. But we’re (and even me – turns out no one has complete experience with all of this stuff, so we’re all picking up some amount of things) actually getting stuff built pretty quickly. And quickly it has to be.. only some 70 some days before Alpha!
