Terse Systems

(Logs from the last couple of days.)

Read through the Hibernate manual and get some simple container working. It doesn’t have the functionality of ATG repositories, but it does all the basic stuff, like item descriptor inheritance and an abstract query language. The advanced stuff (derivations, cache groups, distributed locked caching, cascade updates, etc) is outside its purview, but it’s sensible, well-behaved, and it doesn’t suck. (I realize I sound like a zealot regarding ATG. So be it.)

Installed Spring. Got it working with Hibernate. The IoC framework is roughly Nucleus without layers or scoping. The page flow component (aka Spring MVC) is not so hot, judging from the tutorial. The controller will provide a model that you can access through JSP, with the ModelAndView class calling the actual JSP page and providing a model. So a class has to be written for every page, providing a model to it, and registered with the framework? It’s MVC, but I don’t see the added value here. Decide to look at something else.

It’s very hard to get an overview of all the different frameworks… either they’re one line “Oh yeah, this is a framework like this other framework” or they go for the full-on Prevayler slobber.

Look at WebWork, a page flow framework. Just from initial reading, it doesn’t seem crazy and it has good reviews. But hang on. For a framework designed for the JSP template engine, it’s a bit strange to be using Velocity behind the scenes. How many template languages should you need to know to put a website together? And what’s with xWork?

Look at SiteMesh. It’s a page flow framework for decorating output. After the response is sent to the OutputStream, SiteMesh then manipulates that output using a series of postprocessors. I don’t see how it can do this without some unpleasant implications: either it caches the response for every request (big memory overhead there) or it writes to a commited OutputStream (which, IIRC, causes IllegalStateException in J2EE apps). Thanks, I’ll pass.

Look at JSF. Rave reviews, if your last name is Hightower. Everyone else seems to hate it. According to Matt Raible it does a POST for every request. He can’t be serious. Who would release a framework like that?

Struts may be the least of all evils. From reading the blogs, it seems like no-one really likes it. But everyone agrees that it’s servicable. But I think I’ll be ambitious and try WebWork.

Ah. AppFuse. Presumably because it fuses all these applications together. Except that it’s set up to use MySQL and Tomcat by default. I’d actually prefer it to be broken by default and have modules that I can just plug into it. It never makes me feel comfortable when I have to strip out application servers in the code base. They should be factored out into a different file (deploy-tomcat.xml, deploy-orion.xml, etc.) and then have the tasks imported into build.xml. At least PostgreSQL settings exist (although commented out).

ant install-webwork
ant package-web

Huh. Where’s the EAR file? Oh. No application.xml file. It just makes the WAR. That’s wierd. Time to copy over some code.

ant deploy
java -jar orion.jar

Well, Spring doesn’t like that very much. Lots of complaining about missing beans. Time to hunt for the web.xml file… which is split into several different pieces and merged together with xDoclet. Isn’t that cute. I suppose this is because having a single file is too complicated.

Edit web-settings.xml

What is classpath*? Okay. Whatever it is, Orion doesn’t support it. Time to pull all the XML files together. Nope, still doesn’t work. Okay, AppFuse generates Spring and Hibernate XML files dynamically using xDoclet. How very… clever. Grrr.

Okay, now it’s complaining about missing tables. That’s a good sign. Create database, create tables… Oh. Okay. We need some user data to put in the tables… which is in an XML format and run through Ant.

ant setup-db

Read through some more documentation. Equinox is a “simpler AppFuse.” The documentation couldn’t have mentioned this straight out?

Still populating drop-downs and then nothing. Look at the source code. Ah. The StartupListener in AppFuse doesn’t catch exceptions, so it’s just headed off into the void (Why doesn’t Orion have a logging method for exceptions that bubble all the way up to the top of the stack?). Putting a try / catch / log block around it shows that I’m missing the “lookupManager” bean.

Now it says “No class def: ListenerDescriptor.” Google shows this as an Orion problem. Fixed by Orion 2.0.6, the experimental version. Great.

Okay, now I get a recursive error page. Somewhere in FilterToBeanProxy. What’s up here? Ah. This is actually an Orion problem again. When I installed Orion 2.0.6, I didn’t install the tools.jar file from the JDK. You’d think it would have a better way of telling me it can’t do page compilation.

Now I get a “Yikes!” page with no info. There’s nothing in the logs. I turn everything in log4j.properties up to DEBUG, and run through it. Nothing. It could be another code piece without a try / catch block, but I have no way of knowing where.

Time to use a debugger and step through it. Set up Eclipse with libraries. Ah, here’s something in the logs. Except that it just tells me I need more dependent libraries for runtime. My environment is swimming in small libraries that do almost exactly the same thing. (Side rant: I have yet to see anyone give a valid reason for using dom4j. Oh, you don’t like the API? Write utility methods in your own code and suck it up. Don’t pass it off to me, I have enough problems with the classpath as it is.)

Orion libraries are obfuscated and without debug information. And I can’t get Eclipse to breakpoint on a thrown Java exception. This just isn’t working.

I wish I could take Tomcat seriously. I’d go back to Jetty, but it doesn’t even support JNDI. But… I know enough about how AppFuse works now to migrate small pieces in my own project. It won’t be nearly as fancy, but I understand how it should work now, and I’ll know why something doesn’t work, because it will have worked before. So that’s what I’ll do.

I toasted another computer last week. I won’t say this is a habit, but there’s a reason why some IT departments call me the Angel of Death.

My biggest problem with computers is that I’m too trusting. System Optimizer says it’s compatible with my system? Let’s run it. Uninstaller says no-one’s using this DLL? Go for it. Guide says I can speed up the computer by tweaking the registry settings? Who could argue with that?

With predictable results. With the best will in the world, if you play with breakable stuff long enough, it’ll break. This time it was MSI Live Update, saying that there was a BIOS update I could install for my motherboard (K8N Neo Platinum, MS-7030, BIOS 1.9 for the googler). Perfectly risk free. Came with a utility called WinFlash to install the BIOS for me. Point and Click.

I reboot the computer, and nothing happens. Just a black screen. And beeping.

I’d never installed a corrupt BIOS before, so I didn’t know how screwed it will make you. Corrupt your BIOS, and the machine won’t POST. I cleared the CMOS and took out the battery, but it was too late. The BIOS chip was fried. The motherboard has to go back to MSI, who will pull out the chip and reinstall a new one.

I didn’t wait. I bought a new motherboard from Fry’s (Gigabyte, thank you) and was on my way. Great motherboards, but a lousy QA process.

I was confused about all the different frameworks, until I realized that many of them only attempt a small piece of the domain. I came back to it again once I felt confident I’d gotten past the hype. I haven’t examined every solution closely, but so as far as I understand it, the current state of the art looks like this:

If only DAS had been open-sourced 10 years ago. It could have been so different.

Currently playing around with AppFuse, the short way of saying for “I’ve got a sample application using all of this stuff integrated together, and it actually does work, if you use a code generation framework, use Tomcat, and don’t poke around with it too much.” Masses of documentation, but still a big pile of libraries. No conceptual integrity. And glue code to stick everything together. Argh.

Still, much better than last time I looked. They’re getting there, but it’s a long way to go yet.

It amazes me what people can get away with.

I am way too self-conscious to go outside wearing anything with a label on it. I don’t even like the little symbols that come on clothing, let alone actual words.

For example, I bought a diesel t-shirt several months ago. Wore it outside once, to eLuxury, as a joke. Never wore it otherwise. It just didn’t fit with anything else.

Felix sees it and goes “Dude! This goes with everything!”

“No, Felix,” I say. “It doesn’t go. It’s too fashionable for the plain clothes, and it’s doesn’t fit with the fashionable clothes.”

“No, you don’t understand. It’s not SUPPOSED to go with anything. That’s why it works.”

And he is right.

What is the best way to make decisions? Given a limited amount of time and information, how do we decide on the best course of action? And how do we determine what “the best” is?

Cognitive Science studies how people make decisions in real life. There’s also a branch of cognitive science which tries to form models of decision making. I read Simple Heuristics That Make Us Smart as a way to figure out if there were any shortcuts to decision making. I didn’t find anything globally applicable, but the book is fascinating, and I’ve been meaning to write about it for two years now… so bear with me while I run through this.

Decision making in academic literature is referred to as rational choice theory or rationality. The book goes into some detail about different kinds of rationality: unbounded rationality assumes total knowledge of the situation (as in the “perfect market” economic theory) whereas bounded rationality suggests that the human brain has limits and “uses approximate methods to handle most tasks.” It also suggests that bounded rationality exploits the environment: different heuristics are applied in different environments, and a simple heuristic may work extremely well when applied to a specific environment.

The book divides bounded rationality into two categories: satisficing and ”fast and frugal heuristics.”

Satisficing is a heuristic organized around making an acceptable decision in the shortest possible time. It is literally “decide what you need, then pick the first acceptable solution.” Don’t bother looking at the other options. Don’t even try to find out if there are other options. Pick the first solution that meets your needs.

Satisficing is a good heuristic in time constrained situations. It’s a good strategy for buying a house. But it’s not the best heuristic, because deciding what you need can be complex, and deciding what option is the best one can be complex. Satisficing can lead to sub-optimal solutions. But it’s a great way of avoiding analysis paralysis.

Fast and Frugal Heuristics are the approach that receive the most attention in the book. They are environment specific heuristics. They may not work in some situations, but they will make the right choice more often than not. And they work better in spite of using less information than general decision making.

The best way to describe a frugal heuristic is by an example from the book. When a patient is admitted into a hospital, there are 15 different variables (also known as cues) which could describe whether the patient is at high risk for a heart attack. A doctor could look at every single variable and come up with a decision, but it turns out that only three decisions need to be made:

“Is the minimum systolic blood pressure over the initial 24 hour period more than 91?”
“Is Age > 62.5?”
“Is sinus tachycardia present?”

If the answer to these three questions is yes (or the first answer is no), then the patient is high risk. If not, the patient is low risk. This may seem like an oversimplified example, but this heuristic actually works better in the field than the one which examines all possible variables.

The interesting thing is that this works not because it’s a generalized strategy. It works because the environment is fairly static – patients come in and either get heart attacks or don’t. Given enough time and data, heuristics like these can be derived. However, they can’t be known ahead of time. You know this stuff from experience. It is, to the people who know the heuristics, “common sense”, even if they can’t define it.

The nice thing about heuristics is that they’re practical. Using a heuristic will lead you to making the wrong decision some of the time, but it works better when you have to make a decision, and you know that making a decision is more important than getting it wrong.

There are a number of useful heuristics that appear in the book, and the greatest challenge to writing this post is that I want to write about all of them. Instead, I’ll just present summaries and go over them briefly.

Ignorance based decision making

People know when they know something. There’s even a saying: “Better the devil you know, than the devil you don’t.” A recognized quantity is more likely to be better than an unrecognized quantity. Heuristics exploit recognition to put a greater weight on a cue with a known value. This principle opens the door to a number of heuristics, notably “Take the Best.”

“Take the Best” can be described as follows: All things being equal, pick the movie with Tom Hanks in it. If not, at least go for an actor whose name you recognize over one you don’t. There are other one-reason decision making rules, but I’ll focus on this one because it’s clearly the one the researchers like best.

Take the Best makes an intuitive amount of sense, even if it does have the big weakness to “Take the Best” is that it has to be trained to know what’s a valid cue (you have to know who Tom Hanks is). Or as the book charmingly puts it, “the validity of a cue is defined as the number of correct inferences divided by the number of correct and incorrect inferences made using the cue alone.” In short, you have to know who Tom Hanks is before Take The Best will do you any good.

In a competition pitting heuristics to guess the size of Germany’s largest cities, these three fast and frugal heuristics, using at most 3 cues, were more accurate than heuristics that looked up all 10 of the cues. The effectiveness of the frugal heuristics varied with how much information was known, but was still higher than the non-frugal ones. Sometimes having all the information isn’t a good thing.

In practice, people tend to use a strategy called LEX, a generalization of Take the Best. Lex is defined as “the highest cue value on the cue with the highest validity. If more than one alternative has the same highest cue value, then for these alternatives the cue with the second highest validity is considered, and so on.” If there are two movies with Tom Hanks, then pick the one directed by Ron Howard over the one directed by Michael Bay.

Why does it work?

These class of heuristics work in situations where the information is “non-compensatory” (i.e. a movie with an A-list actor and an A-list director is unlikely to have a D-list cinematographer) and the information is “J-shaped” (which I think corresponds to Zapf’s Law… there are only a few excellent movies each year). In addition, this heuristic works very well in situations with “scarce information” (you don’t know everything about every movie) and “decreasing population” (that is, good movies run longer than bad ones). This covers a large percentage of situations, without tying the heuristic too tightly to a particular situation.

Satisficing in Mate Search

There are situations where a “Take the Best” heuristic is not the best one. While you can choose between several movies, only the determined or foolhardy dates several women at once and compares them against each other.

There’s a puzzle called “the secretary problem” in which the best secretary must be picked from a pool of applicants. However, the applicants appear in random order, and once a secretary has been rejected, she doesn’t come back. The best solution to this problem (and bear in mind that this problem assumes a lot) is to interview the first 37% of the candidates, and then pick the next candidate who is better than the best in the sample size. Following this rule, you will end up with the best applicant 37% of the time.

But the secretary problem misses one small issue: while you are searching for the best match, your match is also looking around for his or her best match. Ironically, there is not much research into the best practices for mutual search. There is some research into the mate search strategies that people actually use, notably the charmingly named “one bounce” rule, where people continually look for the best mate, but stop as soon as the next prospect is less attractive than the current selected one.

And here is where I go off the geek deep end, past even Dating Design Patterns: the book actually goes looking for simple satisficing search heuristics for “biologically realistic mate search problems.” Oh baby.

If you have high date value, and know that you’re a good catch for any prospective mate, then the simplest dating strategy is called “Try a dozen.” The best chance you ever have of meeting the perfect mate is 37% – not very good odds, and that’s assuming you date at least 30% of the available population. The mitigating factor in mate search is that you don’t have to find the absolute best mate: you just have to find a good mate. Instead of taking the next best from 30% of the population, we can sample a smaller size and relax our restrictions a bit for a faster result.

By only dating 14% of the population, you have an 83% chance of finding a mate in the top 10% of the population. If you are willing to settle for a mate in the top 25% of the population, then your numbers get even better: dating 7% of the population will find you a suitable mate over 92% of the time.

Even though this looks statistically inviting, 7% of the population still looks daunting given a large enough population. However, the interesting thing is that the statistical significance of mate quality goes up with the rise in population: to find a mate in the top 25%, only 1% or 2% of the population needs to be checked. So Try a Dozen works for even large populations, although there does come a point where it doesn’t scale.

But there’s a catch. Try a Dozen only works when you have a mate value and know that none of your candidates are going to reject you.

The researchers wrote a dating simulation program, where they could see the best overall strategy for mutual date search. In this simulation, individuals had the same problem that we do: it’s hard to know how attractive you are to prospective mates from the inside. In fact, your dates have a better idea of how much of a catch you are than you do.

The only realistic way to know your own mate value is to go through a learning stage (“adolescence” in the book) where you date a number of candidates and determine your own attractiveness through feedback. If a highly attractive mate proposes to you in adolescence, then you increase your own rating by a value proportionate to the mate’s attractiveness. If a low-rated mate rejects you, then you decrease your own rating proportionately.

There are two measurements of success in this simulation. The first is the number of matches: if too many individuals have unrealistic expectations, not everyone will be matched. The second is the spread between matches: if a high value individual “settles” for a low value individual, then the match is not optimized ideally.

It turns out that with a short adolescence, most of the high valued individuals pair off immediately with the first random person, and the low valued people remain single because they are overconfident. But give the individuals an extended adolescence, and the group equilibrium quickly comes within 10% of optimum. Best of all, this heuristic works only even when the total size of the population is not known, and seems to be asymptotic after checking 20 individuals.

This also seems to make intuitive sense. However, the researchers explicitly state that the model is lacking some of the finer details common to dating. Populations are not fixed. Different age ranges may have different fitness criteria. The distribution of mate values are not as evenly distributed as they were in the simulation, and individuals don’t have a chance to change their mate value based on their adolescent experiences.

The researchers are also careful to explain that mate search is not just a matter of percentages, even if it can be simulated as such. Love, they carefully explain, is essential in making decisions stick: in the heuristic of dating, love is the stopping rule.

I didn’t really like University all that much. There were too many lectures based around a curriculum started in the 1960s, and never really updated since then. I still remember the database schema lectures we had which had to be written in the appropriate database set algebra – completely pointless for undergrads.

So I’m surprised how much I’m going back to university material for information. Part of it is that some of the ideas I’m interested in (automated code review, design by contract, empirical software engineering) are really only covered there. There’s relatively few people who are actually interested in covering this stuff, and they’re not good at hype or pushing their message out to people in the field.

They know this. I kept hearing David Parnas’s name in reference to information hiding, a concept over thirty years old. But he’s been around consistently. I bought a book of his essays (Software Fundamentals) and was astonished at his range. He’s been around for years. He’s been talking on the need for spreading concrete software engineering knowledge for at least two decades, but doing it inside an academic framework. It’s not that engineers don’t have a good idea of who Parnas is… but the only knowledge they have is from their undergrad CS days, and no-one ever updates them on it. I’m not opposed to Joel Spolsky, but isn’t it backwards to have him more well known than Parnas or Basili?

I think part of the problem is that academia assumes that they are listened to and followed in the field. That stops the minute people leave academia, and it’s very rare that people ever go back to update their knowledge. Most people rely on their peers for tips and tricks, which is where the whole blogosphere thing comes in.

Academia has one thing going over blogs though. Compared to blogs, they have a very high signal to noise ratio. It is very rare that you will read a bad academic paper; at worst it will be redundant, and at best it provides top quality information with almost no hype or dogma. For example, read The Inevitable Pain of Software Development. Every single word he has written is obviously based on years of experience.

Even better is watching the lectures. The University of Washington makes its lectures available online, and they have several years of lectures given by good, solid people.

For example, watch Computer Science: Still Crazy After All These Years. This is a colloquia that goes over the next five years of computer science, and who is working on what, and it’s fascinating. Make sure you watch to the 38 minute mark, as he drops some extraordinary statistics on undergraduate majors. (They also have hardcore stuff on guessing how to fix bugs and automated software testing.)

But they also have good lectures by people in the industry. Want to know what Google is doing? Watch Google: A behind the scenes look and Eric Schmidt’s perspective on IT.

Want to know what Amazon is doing? Watch a lecture from Jeff Bezos on their plans and their data.

Like Steve McConnell’s books? Watch his interview. In fact, they have a whole series on IT leaders.

I love reading this stuff, because it provides a larger context of what happens outside of my immediate work on one programming language. The irony is that this information is provided to people who aren’t actually working in the field: you get out and start doing real work, and you have to work for your information instead of getting it coming to you.