Second month of frequent fitness studio visits. As was to be expected, I was not able to keep up going in the morning (not even once this month), and shifted to after work. It can still claim a daily basis, though, I skipped only four times. Unfortunately, there has not been another increase in buffness, maybe because of that laziness, or maybe I maxed out already. But there is an unexpected positive side effect: Since taking showers is now mostly outsourced (for both me and Cissy), we have seen the gas and water bills drop to all time lows (no impact on electricity).

	June 30	July 29	Sept 02	Ideal
Weight	69.7	70.7	70.6	77.1
Muscle	56.7	59.2	58.7	62.1
Fat	9.8	8.1	8.6	11.6
BMI	20.6	20.9	20.9	18.5 to 24.8
Body Fat Pct	14	11.5	12.2	10 to 20
Tipness Score	76	80	80

I have spent a lot of time recently at $day_job (actually more like work.DayJob, I am 100% Java these days) trying to come up with an easy-to-use, yet powerful, flexible and efficient object persistence scheme. Traditionally, it has all been hand-rolled SQL here, which is repetitive (hence both boring and error-prone), verbose, and has has poor tool support. For a new project, we started to use Hibernate, which is very powerful, and widely used and supported, but it seems to suffer from the "leaking abstractions" problem: While you can happily declare all your entities and relationships at a very high level, if you want to have any semblance of reasonably efficient storage and scalable query performance, you have to understand the inner workings of Hibernate. Unlike other OR-mappers, Hibernate knows about this problem, and does not try to hide the underlying database: It does not claim exclusive ownership of the data, it encourages you to tune the interactions between the layers, and it even supports direct SQL queries. All this makes Hibernate a great tool for people who know what they are doing, but it probably does not work as the magic black box we would have liked to have. This is of cause not a shortcoming of Hibernate. With a problem domain so complex as generic object persistence, there can be no simple solution. What I am looking for now is a tool that limits itself to a narrower set of tasks, and by thus eliminating complexities in the problem domain also eliminates complexities for its users.

Specifically, I have developed a potentially unhealthy fascination with write-once-never-update ways to store data. By introducing this one simple constraint, everything becomes so much easier:

• Transactions: Because data is never updated, there can be no dirty reads. You still want atomic inserts, unique primary keys, and guaranteed durability from your database, but there is not much need for long running transactions.
• Lazy-loading: Because data never changes, if you obtain a reference (like a primary key) to the data, you can easily defer access to the content to a later time, without having to worry about getting an inconsistent view.
• Caching: Because data never changes, you can aggressively and at all layers cache everything, without having to worry about the cache becoming stale.
• Shared storage for nested objects: If you have a nested data structure, there is no need to deep-clone anything when writing it to the database. It is totally safe to share pointers, because none of the involved objects can ever change the contents of that pointer. By extension, you have to store every unique value only once. This can save a lot of disk space.
• Backup: There are only incremental backups of new data.

So how can one store real data, which happens to change over time? One way to tackle this would be the approach of a versioning system: Regard every revision of the object as its own piece of data, and store those. An update to the object becomes an insert of a new revision. This way, you also get an update history, undo functionality, and an audit trace, all of which you probably want anyway. It may be necessary to layer a few normal (updatable) tables on top, to maintain pointers to the current versions in order to achieve acceptable query performance, but those should be very simple (and small).

Stuntman Mike (Kurt Russell) has a death-proof car. He likes to stalk pretty girls to ultimately kill them by causing a car crash, which he only he can survive, thanks to his tricked-out stunt ride. But then he meets a trio of stuntgirls who turn the tables on him.

Death Proof was supposed to be part of the Grindhouse double feature, together with Robert Rodriguez' Planet Terror, and a couple of faux trailers by various guest directors. Because it tanked at the US box office, extended versions of both movies are released independently (I wonder what happened to the trailers, though).

7 points

Since the first day of the month is cheap (well, cheaper) movie day, and I was already there, and Grindhouse would have been a double feature, I stayed on for Jackie Chan and Chris Tucker's latest offering. No big surprises here, Jackie Chan must be getting too old for the more crazy stunts and Chris Tucker gained a few pounds. I liked the French taxi driver.

5 points