RIP, Steve

Steve. Bill. Larry. If you're about my age, and in the "computer" business, you know who these people are. They're iconic. These three, more than anyone, created the on-line, desktop, hiptop, and palmtop world in which we live. They led the rest of us into a connected world. A world where we're instantly available to our friends and they to us, changing the way we stay in touch. A world where information flows almost effortlessly to wherever we are, changing the nature of discussion and debate, art and science. A world where governments can't hide their oppression, news can't be controlled by those who own the presses,  people can't be told there's no hope for a better life.

Moving away from Google

Recent and not-so-recent posts by a number of bloggers (e.g. 1, 2; just 2 of the 6 or 8 I've read in the past few days) regarding getting locked out of their Google accounts have reminded me why personal computers boomed in the workplace so quickly.

In the early days, PCs (well, except for Macs) were hard to use, had horrible interfaces, minimal software choices (WordStar, VisiCalc, dBase II, and AutoCAD were the exceptions), and were in huge demand everywhere. Why? I think it was largely because they allowed us to control our work. We had word processing, databases, and CAD systems before PCs. They were controlled by others--we could be locked out, inconvenienced, our work confiscated and our access revoked by those in control, without appeal and without warning.

Sound familiar?

Six steps to JBoss (and Tomcat) with IIS 7

I've had a devil of a time getting IIS 7 talking to JBoss. It took 3 different sites and flash of insight to get all the settings working. I'm not a system administrator, and I'm not an IIS expert, so I may have missed a default somewhere or gone further than I needed to. Here's what I did, in hopes it helps you.

Java Components and Package Visibility

I have a recurring problem: I want to build a component within a large application. Here's an example: I want to synchronize QuickBooks Invoices with my application's invoices. The component API produces and consumes application invoices, sales reps, accounts, and customers, but the internals of the sync task are very complicated, involving 3rd-party Invoices, maps to interface invoice-like objects, synchronizers, etc. The main app has no need to know most of this stuff.

Java provides no mechanism to build a subclass structure for my sync component--I must either build the whole thing in a single package containing hundreds of package-scoped objects, or I must build public objects visible to the rest of my app so my component can have an internal package structure which models its behavior.

What I really need is a visibility modifier making classes only visible to their sub-packages.

Creating Healthy Craftsmen

There's been a healthy debate over on the software craftsmanship mailing list about what craftsmanship means in the context of software development. I've been a proponent of, among other things, some set of standards by which a practitioner's capabilities can be measured. That's been unpopular, as you might imagine.

Documentation in the wild

I just started a new project.  I has no documentation except the code.

In this particular project, this is generally a Good Thing--the code in question is clear, well written, and (ahem) completely without comments.  I'm not having a lot of trouble understanding it, overall, because it really is very good code.  But... I've spent 2 days trying to figure out how one important feature works.

http://thedailywtf.com/Articles/Documentation-Done-Right.aspx

'Nuff said.