Rob MacGrogan's blog

We haven't yet come to grips, as a society, with what it means to store so much of our vital stuff as zeros and ones on disks and flash cards here and there. Such stuff isn't really real, is it? It's easily lost, or even worse, stranded.

What the OO solution to this problem gives you, though, is some nice name-spacing, the potential for type safety in your map method and a potentially much more readable batch of code. What's the major issue with this?

"You may leave your message after the tone. When you are finished, you may hang up, or press pound for more options. To leave a callback number, press six. To page this person, press star star."

We hear so much about wireless networking these days that another, more slowly growing connectivty option has gotten almost no notice at all. I'm talking about broadband over powerlines.

It seems that the world of XML has some very sloppy practices built into it. These are sloppy practices used by developers all around the world, including myself, and they are a recipe for disaster.

After six years of experience in programming in an Object Oriented language, I've identified five different types of classes that occur in OO programming. Knowing and understanding the distinction and knowing how to build each of these types of classes is, I think, essential to writing decent code that is easy to read, understand, debug, and maintain.

Our jobs, as software developers, are made up of work and not work. The work is the good stuff--writing software, designing architecture, even doing maintenance code. The not work is what kills us.

The basic gist of the suit is that NTP (actually just one guy) filed a patent some years ago for the concept of "wireless email." Did they create a wireless email device or any software to run it? No, they did not. They simply patented the concept before anyone else did. This is the basis of their suit.

Coders think in terms of code. It's the old saw about the hammer. When that's the only tool you've got, everything starts to look like a nail.

Coders, of course, have more than one tool at their disposal. We have worlds of tools. But coders do like to code (see Andy's recent post if you don't believe me). It's what we like to think we do best.

Before I get too far along here, let me clarify what I mean by code. I argued for a broad definition of source code in a recent comment, and I'm not backing away from that really, but maybe clarifying a few terms. Let's say, for the sake of argument, that code is that which is written in a programming language such as BASIC, C, Java, and the rest. I won't attempt to define it further. And let's say that what I called "source code" in that other post might better be called simply "source." Only three paragraphs into my post and I've already gone off on a tangent. Typical.

The point I want to make here is that coders like to work in familiar territory. Present a coder with a problem and his or her mind will immediately go to work on solving that problem in the software language of his or her preference. For example, if you present me with a problem, I'll probably start right away with a possible solution using Java and some of my recent favorite technologies, such as Hibernate, SOAP, and maybe JMS. Java is my favorite hammer and I like to use it.

But many many problems are not best solved by building a mighty computer program, as I recently learned.

Anyone who's spent much time using the Eclipse IDE knows that this piece of software is all about plugins. In fact, in many ways Eclipse itself is basically just a platform into which various plugins are installed. All of the Java IDE stuff, in my understanding, is implemented by the Eclipse team using the same plugin architecture that other developers use to make their own plugins.

I recently spent some time in Eclipse plugin land. I'd been avoiding this for a couple of years, because sometimes I just get tired of learning how to use new tools. Java development, especially, seems to call on you continuously to master some new best-of-breed framework (Struts, Hibernate, J2EE, JSTL, and so on). So a certain amount weariness had set in. But SourceJammer (my open-source VCS product) did not have an Eclipse plugin and users were constantly crying out for one. So finally I just broke down and got to work.

This evening I spent nearly two hours cleaning up a (non-computer related) blog site I maintain. The url is http://www.halfreycottage.com, but I've moved my blog to a new site at http://sprucepine.halfreycottage.com. I've been keeping the site going for a little over a year so I can post photos and musing about gardening, bugs, and birds. Simple, quiet stuff.

The reason I had to clean it up was not to fix the layout or to get rid of old content. The site is in pretty good shape as that goes. No, I had to spend almost two hours cleaning out several hundred spam comments all over the site, 100% of them for online poker.

My saga of frustration and woe in trying to build a simple Web Objects application continues.

I hope I don't come off as someone who just wants to crack on Web Objects, but the more I work with it, the less there is to like. I think my essential problem is with the "one-tool-fits-all" approach behind Web Objects. As I explained earlier, WO is basically a case tool for web development. And like all such tools, it requires developers to do everything in exactly one way, using proprietary tools, while hiding all kinds of relavent information.

I've got a solution to some tricky Java printing problems. The bottom of this post contains code that you can re-use, for free, to very easily print the multi-page contents of Java Swing components.

[Note: The WO series goes on hold while I work on other stuff for a while.]

It was at a Christmas party in Atlanta last year that my good friend Trevor Conn (I always want to spell it Kahn. Kaaaaahhhhhnnnnnnn!) started telling me about a new software development project he was working on. It was to be a web-based application developed using Java/JSP. Ahh. My bread and butter.

Trevor's background is more on the Microsoft side of the fence, so there was a bit of a paradigm shift for him. I'm not talking about syntax or event models or software frameworks. That stuff is pretty easy to figure out, and genereally there's an equilivent concept somewhere under the hood, only with a different name. In fact, there is a much deeper division that separates the Microsoft world from the Java world.

I'm talking about money.

The consulting shop I work for is small and, by necessity, general purpose. We like to be compliant to our clients' needs instead of shoving our technical ideas down their throats. One result of this approach to development is that I'm called upon to learn new tools (good and bad) all the time.

Sometimes this is all good stuff. For example, last year, as part of a new project, we started using Hibernate and I got to learn some valuable stuff about using a new, cutting-edge, OR mapping tool.

But sometimes this is not so much fun. Right now, I'm teaching myself to use an Apple technology called WebObjects, which is what the WO in my title refers to. (In full disclosure, I've copied the title of this entry from an old article I found here.)

In theory, WebObjects is neat stuff.