use Perl

IMHO etc.
There are views/ with an index and a "main" layout - I can guess what they're about.
Three config files, I can guess how that's supposed to work - must be a dev/test/live switch somewhere
Public dir with css and images - sounds OK. The 404/500 are clearly error pages. Might not want them, but at least I know how to do them now.
The top100.p[lm] are clearly my main app files.
All that's left are the app.psgi and dispatch files. I don't know what they're for, but I'm a newbie, so I don't know loads yet.

I think you've forgotten how to be a newbie :-)

Can you start the app as directed? (just blindly following instructions)
Did it work, and could you tinker?
1. Add static text to index template
2. Add a variable, stick a value in it
3. Add a second page

Yes? Congratulations, that's another user for your framework.
Couple of extra files - pshaw(*) - there are five thousand mysterious and indecipherable files on any modern O.S.

Fiddling with the TT tag markers - spot on there though, makes no sense to me either.

(*) Apologies to any web 3.0 doods out there - tweet my facebook google-wave via my ipad if you need help with this term.

Now consider a simpler, yet silly, example: SELECT first_name FROM employee WHERE salary > 50000; What happens if the salary field is NULL? You'll get a list of employees whose known salary is NULL.

I can't figure out what you meant to say there, but the query doesn't seem to go with the text.

In this scenario, it is the case that everyone has a salary; you just don't know what some of them are. So here's the kicker: SELECT first_name FROM employee WHERE salary = salary; That won't return anyone on the board of directors, even though you know they have a salary.

You don't know that though. Not within the terms of the database. If you did, they'd have a numeric salary and not NULL.

Furthermore, most would think it's self-evident that p = p, but in three value logic of databases, this is sometimes true and sometimes false.

No, not quite right. The expression p = p will always be either TRUE or NULL. Anything compared to NULL returns NULL. This will behave the same as FALSE if you test for truth since the test will still fail.

If you aren't enjoying bashing your head on these little "features" then I recommend staying well away from how nulls interact with record types. There appears to be no logic there at all.

The advantage of explicitly counting dots (rather than relying on string length to always increase with the number of dots) is that it makes path-lengths comparable. Not directly applicable to this problem, but not uncommon.

have been wrestling with these sort of concurrency issues for decades now (and of course you can view the DB as a set of assertions). With something like mvcc you're not even dealing with a single timeline any more.

• http://www.postgresql.org/docs/8.3/static/mvcc.html
• http://wiki.postgresql.org/wiki/MVCC
• http://www.postgresql.org/docs/8.3/static/transaction-iso.html

There's been a recent discussion on the pgsql-hackers list wrt some issues of implementing true serializable transactions that might feed in to what you're interested in.

And of course, if you find a simple, efficient, easily understandable implementation then don't forget us little people once you get your Nobel :-)

You might want to check out the fail2ban utility. You can set it to monitor log files for smtp, imap, ssh, apache failures and after a set number ban that IP for a set time. Patterns, durations, actions etc. are all configurable.

One of the advantages of a slick IDE would be that you could trap many of these mistakes at edit time even, rather than compile time. Purple method-names are overriding something, blue aren't (or whatever).

One of the things you get for free with Smalltalk's image system I suppose.