Intro J2EE Books

So as a part of my new job I may, as time goes on, have a need to deal with the looming monster of J2EE in one way or another. We have a lot of Java code in the system, and while I don't actually work on it, there are definately going to be times when the part of the system I work on will intersect the part of the system I know virtually nothing about.

You see, despite the fact that I do, in theory, know Java, and in fact that I've been paid in the past to write both desktop Java applications and Java web applications, I really know very little about J2EE. Honestly, I don't even like the term J2EE. If people could just say "Java Web Applications" I'd be fine with it, but as soon as they try to use the term "Enterprise" to make something like a web page sound impressive I really start to glaze over.

Despite this, I do recognize that there are a lot of smart J2EE developers out there, and they have built a number of impressive systems using those technologies, and since I do have a need to interact with this stuff it's probably a good idea that I actually learn something about it. So this weekend I stopped at a book store and tried to find a decent looking intro J2EE book. So far, I've been largely dissappointed. I picked up a copy of "Core Servlets and Java Server Pages", which seems reasonable enough for the JSP and Servlet stuff, which I already know, but could probably use a reference on, but it's like 3 inches thick, and covers a bunch of useless "HTTP and HTML 1.0" crap that nobody who's been alive in the programming world over the past few years should need to see again.

Plus, it doesn't cover anything other than Servlents and JSP, plus a smidgen of things like JDBC. I mean I've got no freaking clue about EJBs, or any number of other acronyms that show up in the J2EE world, but I'm certainly not willing to go out and buy a 40 dollar book for each and every one of them, and from what I can see that's what you're buying into when you start picking up books in the J2EE space.

So does anyone have a good intro J2EE book they'd like to recommend to me? Something to get me to the point where I can be conversant in the terminology and know enough to poke around in some code without being totally lost, but where I don't have to spend hundreds of dollars and waste weeks of my time reading hundreds of pages of crap?

OpenGrok

Back when Sun launched OpenSolaris, I was pretty psyched about the whole thing, but one of the things that actually interested me the most was their online source browser. For those who haven't played with it, it's pretty much a reimplementation of LXR, which you may have seen in use over at lxr.mozilla.org.

Of course, at the time, the code to this part of the OpenSolaris web site wasn't available, so I just sort of wrote it off as "pretty cool, I wonder if it'll ever be released".

Well, apparently its code was actually released last week, it's called OpenGrok, it's written in Java, uses Lucene for its searching, and calls out to exuberant ctags to parse source code in a dizzyingly large variety of languages.

I just downloaded it and pointed it at a copy of the Subversion source code, and I've gotta say it's pretty cool. The instructions were pretty straitforward, just run a simple command to index your code, edit a few lines in WEB-INF/web.xml, drop the war file in Tomcat's webapps directory, and away you go.

It'd be nice if it had actual Subversion support built in (so far just CVS and SCCS), but that's on the todo list. Other than that my only complaint is that it requires Java 1.5. Requiring Java at all is a pain, but I can get over that, considering that it comes from Sun and all. The Java 1.5 thing really sucks though, since it means there's like zero chance it'll work with the open source Java implementations.

Also slightly annoying is the fact that while the code is available, there doesn't seem to be any way to contribute changes back, or at lease none that's mentioned on the web page. It's basically just source and binary distributions with some instructions on how to get started.

Hopefully a public source repository and some mailing lists will show up in the future, because it's really a neat tool, and I'd love to at least keep track of its development, if not actually contribute to it.

Subversion in C++?

So a while back one of the Subversion committers mentioned that it might make sense to write some (as yet theoretical) future version of Subversion in a dialect C++ instead of C.

You see, Subversion is VERY object oriented, at least for C code, and we jump through a LOT of hoops as a result of the C language. For example, there's about a million places in the source tree where we pass around void pointers as a way of storing context for some callback. In C++ we could pass objects that carry their own context around with them, instantly cutting in half the number of arguments we need to keep track of.

Anyway, I was thinking about this on the drive home from work today, and I started to wonder what would be required to make that really possible. The first thing that jumped to mind was making APR interoperate with C++. Virtually all resource management in Subversion is done via APR pools, and we're kind of used to that by now, so switching to a non-pool based world would be kind of weird. But APR pools deal in void pointers, low level raw memory C stuff, and setting up higher level cleanups is a pretty manual process.

Now it's possible to take the raw memory you got from a pool and turn it into an instance of a C++ object, via something called placement new, but it's kind of a pain in the ass, and even then you have to manually call the destructor when you're done with the object, which is kind of contrary to the point of allocating things out of a memory pool...

So the question is, how do we allocate a C++ object from a pool, but automatically register a cleanup that takes care of calling the object's destructor when the pool is cleared or destroyed?

It took a little doing, but I managed to come up with something I like. It looks like this:

int
main (int argc, char *argv[])
{
  apr::initialize();

  apr::pool p;

  for (int i = 0; i < 10; ++i)
    {
      p.clear();

      Foo *f = p.allocate();
    }

  return EXIT_SUCCESS;
}

Now to make that work, you do have to jump through one little hoop. The Foo class needs to have a static 'cleanup' function defined on it, which calls the object's destructor. That function will be used as the pool cleanup callback, so you don't have to worry about cleaning it up yourself. To simplify the process of writing this function, there's a helper macro that pounds it out for you, so the Foo class looks like this:

struct Foo
{
  Foo()
  {
    std::printf("in constructor\n");
  }

  ~Foo()
  {
    std::printf("in destructor\n");
  }

  APR_DECLARE_CLEANUP(Foo);
};

That really doesn't seem like such a horrible price to pay for the convenience of being able to work with pools the way we've come to expect, right?

Anyway, I doubt this will ever really be used for anything, but if you want to check out the code I wrote to make this work, you can grab it here.

Back From The Weekend

So I flew out to MA this weekend for my Dad's surprise birthday party. It was a total success, he didn't know that anything was happening until my sister showed up saturday morning, and she told him I couldn't make it, so when I showed up later that afternoon the surprise was complete.

I got to hang out with my relatives, which is always cool, and generally had a good time. It was kind of odd that it was like 70 degrees out (what the heck, it's November in MA for crying out loud!), but I did get to see actual autumn foliage, which I've missed being out in CA this year.

One odd thing, the flight from San Jose to Boston, which has been totally packed every single time I've taken it so far, had empty seats on both friday's flight out and sunday's flight back. Is this just a slow weekend or do people no longer want to fly from San Jose to Boston as much as they did when Jet Blue first started doing this particular route?

The Problem With The West Coast

So I'll be the first to admit, there are a lot of great things about living on the west coast. I've got a cool job, this place is filled with incredibly cool computer geek stuff to do, it doesn't snow, and the list goes on. But none of that changes the fact that I just got an evite to Rob and Jessica's annual pre-thanksgiving get together, and I won't be able to go.

If/when I bail and head back to the east coast, it'll be because of things like this. I mean really, how can I be asked to pass up on like 10 different kinds of mashed potatoes for multiple years in a row?

Oh well, at least I'll be home for the week between giftmas and new years, that's something.

Movies

So I stopped at Fry's on the way home from work tonight, with the intention of picking up a copy of Batman Begins, which just came out on DVD last week.

But of course, they were out of Batman Begins. This happens to me every time I try to get a new movie at Fry's, you'd think I'd eventually learn...

Instead, I picked up the new From the Earth to the Moon boxed set. Man this is a fantastic series. I mean I loved Apollo 13, and this is like watching the 12 hour extended directors cut of that movie.

If you have any interest in all in space, you've probably already seen it, but even if you have you should still pick up the DVDs and watch it again, it's that good.

Week One

So I just finished my first week at CollabNet, and man has it been cool.

I keep having these moments where I'll just have hit send on an email to the Subversion dev list, and I think to myself "ok, now I need to get some real work done", and then it occurs to me that sending that email was part of my real work ;-)

In more mundane news, I've managed to come to an understanding with whatever deity is in charge of the Bay Area commute, and now my morning and afternoon drive time has settled down to about 45 minutes each way. That isn't really all that bad, especially when you consider that it's 45 minutes of actual driving, as opposed to an hour of stop and go hell, which is what I was dealing with at the beginning of the week before I figured out the magical series of roads that would let me avoid taking 101 all the way up the penninsula.

Anyway, I'm off to the east coast for the weekend. Tomorrow is Psi U's 3-3, and everyone knows I just can't pass up an opportunity to spend 12 hours at a party after 6 or 7 hours on a plane. Also notable about this trip is that I'm actually leaving my laptop at home. I can't recall the last time I flew without one, but for once I'm actually not in danger of getting paged at 3 in the morning and having to drop everything to fix some problem. It's a nice feeling.

A Trip To Windows Land

I'm involved, in one way or another, with several projects that build and run on Windows systems. Now most of the developers tend to be Unix people, so the Win32 side of the fence rarely gets as much love as it should. Part of the reason, frankly, is that it's really easy to get a development version of your average piece of open source software up and running on a Unix machine, and it's really hard to do the same thing on Windows.

Why is it so hard on Windows? Well, there are two major reasons.

First, the tools tend to be harder to get. Your average Unix machine either comes with all the compilers and libraries you're likely to need, or you can get them really easily. The same tools don't tend to come in the box with your standard Windows install, so you have to go out and get them. This means spending money, or at least it did until very recently when Microsoft released their Visual Studio 2005 Express Edition, basically just a cut-down version of Visual Studio that you can download for free. Even with the appearance of a free-as-in-beer win32 development environment (I don't consider cygwin or mingw real alternatives, if I want to use Unix tools I'll do it on a Unix system) it's still pretty hard to get things up and running. Installing the Microsoft Platform SDK and getting Visual Studio to recognize it took me most of this morning, for example. That said, this is a Beta version of the IDE, so hopefully it'll be easier when the real thing ships.

The second problem is sort of a catch-22. It's hard to build most projects on Win32 systems because not too many people do it. This means that the ones who do build them tend to be able to deal with the "Pain in the Ass" nature of the system, so the process doesn't tend to get better. In Unix land there are enough people going through the pain that sooner or later they fix the problems. Thus, fewer people work on the win32 versions because the barrier to entry is so high, and the cycle repeats itself.

Anyway, this weekend I got a bit motivated, and actually downloaded and installed Visual C++ 2005 Express Edition, got the Microsoft Platform SDK working (for the record, the instructions they post don't seem to work for me, I had to use the trick mentioned here where you copy the headers and libraries into the Visual Studio install directory), and I'm inching towards getting Subversion and APR to actually build.

I'm hoping that with the advent of some decent free-as-in-beer tools it'll be easier for us Unix people to actually confirm that things work in Windows land, and the first step seems to be going through the process and figuring out how to streamline it a bit.

Producing Open Source Software

If you've ever wondered exactly what makes an Open Source project successful, and I mean really successful, as in building a sustainable community, not just having one guy madly hacking away in his spare time and giving the results away to the world, then you should absolutely take a look at Karl Fogel's new book, Producing Open Source Software. Karl's one of the reasons that the Subversion community has taken off the way it has, and while reading over the online version of the book this weekend I was continually struck by how on-target his observations were. I mean I was actually there for many of the situations he writes about, and I still didn't see all the angles that he covers.

Seriously, go read the book, and buy a dead-tree version when it hits the stores, you won't regret it.

I was particularly interested in chapter 5, Money.

Why? Well, it's all about how to keep things from getting all weird when people start getting paid to work on the project, either as full time sponsored developers who work for a company with a vested interest, or as contractors paid to fix a specific problem one of their clients needs fixed, or whatever. You see, I'm going to have to deal with that issue personally real soon now. I just accepted a job offer from CollabNet working on their Subversion team, so for the first time my day job will actually be working on some of the stuff I do in my spare time. As you might expect, I'm looking forward to this particular application of the stuff Karl writes about in chapter 5.

This is where I insert the "I'm going to miss the people at Bloglines" and "I'm really looking forward to this new opportunity" sections, but everything I write sounds totally lame. So just assume that I wrote something to that effect, cause I really will miss working on Bloglines, and at the same time I'm really psyched about getting paid to hack on Subversion.

When Should I Have Learned This?

A few days ago I read a blog entry by chromatic about the kind of things that people learn in Computer Science programs these days. He was talking about the difference between theoretical computer science and the kind of skills you need to make it as a professional programmer, two things that are somewhat related but nowhere near identical. That dichotomy is interesting, but it's not what I want to talk about today. I want to talk about the million and one bits of information that have come out of the CS world but that for one reason or another you don't really learn in a CS degree.

Every CS major back at RPI had to write an implementation of strstr at some point, but I don't remember ever learning about better ways to do it than the naive algorithm. At some point between then and now I heard the term "Boyer-Moore Algorithm", but until today I never actually read the paper and saw how it worked. If I hadn't been poking around in the mod_include source code a few weeks ago I'd never have heard of a BNDM search algorithm. Both of these are really cool ways to do a faster string search, but even with my CS degree I'd never heard of them. Fortunately, I tend to hang out in the kind of places you hear about such things, but do we really want people to learn about these sort of things by accident?

How about techniques for multithreaded programming? If I hadn't read the documentation on the Boost threads library I wouldn't have learned the trick about figuring out lock ordering based on the address of the two mutexes, and if I hadn't been following the writing of Herb Sutter I wouldn't have realized exactly how many ways that solution can break down. If I hadn't read the FreeBSD mailing lists religiously for years I wouldn't have learned about the importance of lock ordering at all, despite the fact that I recall at least two classes back in school that taught the basics of multithreading. This isn't like the string searching stuff, where we're just talking about getting the answer faster, this is about how to write multithreaded programs that actually work at all.

If there's this much more to the topics that I did learn in school, what about the topics I never learned there? That's the thing that really worries me. It seems like it's way too easy to think you're doing things the right way and to be completely and totally wrong. Where should programmers be expected to learn this sort of thing? The thing that really worries me is that most of them just aren't learning them, and as a result are going to spend most of their careers screwing up stuff that collectively we've already figured out, but nobody got around to telling them about it.