Thedwick

I’m pleased to announce I’ve got a side gig, writing the latest and greatest Java news over at InfoQ. It all started with my “8 tips for legacy Java code” article, after which they asked me to write regularly for them: one quick news post a week.

So, if you’ve got some Java news you think the rest of the world will be interested in, please let me know. Introductions to people I can interview are even better!

I just had one of the best user experiences ever trying to install Xdebug for PHP.

Get this: you paste information about your installation using the extremely common “phpinfo()” function and the website parses the free-text output and tells you:

1. Exactly what to download and from where
2. Exactly what to put in which configuration file with paths tailored to your setup and, here’s what kills me…
3. Exactly where that config file is on your file system

Now that’s looking at things from your user’s point of view.

Apple has finally removed the self-destructive restrictions they put on developer tools. I couldn’t believe they’d do that in the first place and it’s good to see they saw the light. The question is: is it too late? I for one vowed to choose Android over iPhone when I had the option and lifting the restrictions now hasn’t really changed that inclination.

I happened across an HTML element I didn’t know existed today. The ‘header‘, which is not to be confused with the ‘head‘ element, is a section of the HTML body that can contain, you guessed it, header information like a table of contents or some titles. It’s been supported by browsers for ages, including IE6.

I just figured I’d post something about this under-appreciated element here to boost its Google recognition a smidgen and separate it from its better-known, more-popular-at-parties cousin: the ‘head’.

I saw a good resource and a cool meme today: “hyperpolyglot”. That’s where I found some good side-by-side cheat sheets for scripting languages. As the days go on, I find myself working in many different languages simultaneously and it sure is nice to have a reminder around to look up the maddeningly different syntax for each.

I was surprised to discover today that, out of the box, it’s difficult to include one Velocity template from another if you are using Apache Camel. For once, a search of the Internet didn’t easily find the solution.

So, for the benefit of others, here is the solution….
-

In-memory application caches are a fantastic way to improve application performance. In some cases, they can be done quickly and cheaply with stunning performance improvements. But in-memory caches can also kill application performance in myriad ways. For this post I’ll focus on only one: pre-loading caches on application start up.

I have worked on half a dozen different applications that pre-load caches on start up. In every one of those cases, the application server container would start up and then there would be some kind of hacky, custom-built startup class that held back client requests until some other custom code queried various data sources and filled in-memory caches with data. Only when all caches have been filled are client requests allowed to proceed. Some of these applications had huge caches–well into the gigabyte range–and took ages to warm up.

This. Is. Bad.

It’s bad for the obvious reason that it takes longer for the application server to start up and be serviceable, thereby increasing the length of development and testing cycles. Across an entire project’s lifetime, the time spent with team members waiting for caches to pre-load on startup alone can add up to hundreds of thousands of dollars.

But the obvious reason isn’t even the worst reason. The worst reason pre-loading on startup is bad is that it leads developers to assume that the cache will always be populated and that it will always be populated with the entire dataset. This assumption is a disaster for your application because:

• Then logic to detect cache misses and fetch individual items on a miss never gets written or is written badly, and as a consequence…
• Nothing can ever be evicted from the cache, which means…
• Operational teams have no options when faced with memory or data consistency issues in production, and…
• Keeping cache data synchronized with external “golden masters” is more difficult because you have to actually figure out the differences and re-query the golden source each time there’s a change instead of just invalidating the cache entry and lazily re-fetching it later, plus…
• Buggy code tends to be written that assumes literally the same object is in memory at all times and anything can be attached to it, including objects that are in other caches, which leads to…
• A tangled mess of cache inter-dependencies, which is very difficult to untangle a few years down the road when the team realizes cache pre-loading on startup is a bad idea and tries to do something about it.

“You’re just being alarmist, Tim. Those things never really happen because application teams know better than to get into that situation,” you say. Balderdash. Every, single, pre-loading application I’ve ever seen eventually falls into exactly the same scenario I just described. This is because of the Possibility Law: anything that is possible in your application’s code will eventually be done by some junior programmer somewhere. If you pre-load caches on startup, then you’ve made it possible for someone to assume caches are always full and always contain the entire data set. If you don’t pre-load, then you haven’t made that ubiquitous-data assumption possible.

But there is one draw-back to not pre-loading caches: when the application is cold and the cache is empty, warming the cache by grabbing data from the data store on a onesie-twosie basis is fantastically inefficient. I have a solution for this problem….

We developers and technologists are obsessed with abstractions and generalizations. Tell any developer they will be implementing a series of business rules for an insurance company, and they’ll roll their eyes. Tell the same developer they will be implementing a generic rules framework that lets business users specify any rule they want without any coding and they will start to salivate.

This obsession with abstraction and generalization is usually a good thing. It drives us to see patterns that others don’t see and invent new ways of thinking that drive the productivity improvements that keep our economy booming.

But there is a limit to it how useful generalization can be. That limit comes when it slams up against what I’ll call the Law of Preservation of Complexity. My Law of Preservation of Complexity says: “There is only so much of a problem that can be generalized away. Once the theoretical maximum generalization has been achieved, what remains is the fundamental problem that must be solved through brute force. Any attempt to further generalize will actually be adding complexity or obscuring the problem.”

Imagine the case of squeezing a semi-inflated water balloon. The water inside is the fundamental complexity of a problem and the shape of the balloon is how you’ve chosen to generalize the problem. If you squeeze one end of the balloon to make it smaller, then the other end of the balloon will get bigger. If you poke the other end with your finger, then the sides of the balloon will get bigger. No matter what you do to the balloon, it will still hold the same amount of water.

Now imagine this concept in a system. Say someone designed a system with data storage that’s nothing more than one giant table of name-value pairs. “This is fantastic!” the architect will say, “we can change the data model without having to change the database!” True and not true. The fact is there’s a fundamental complexity (relationships between entities that could have been represented with tables and foreign keys) that has simply been pushed up into the application layer. The complexity did not go away, it was simply moved somewhere else, possibly into a technology that’s less adept at handling it. In the worst case scenario, the complexity was moved to more than one place; it was shot-gunned across the system at random instead of compartmentalized in one, logical place.

Whenever I have a team proposing an abstraction or a generalization to me, I ask, “is this really removing complexity all together, or is it simply pushing it around, like a toddler would do with lima beans he doesn’t want to eat on his plate?” Only if the proposal passes that test do I recommend proceeding.

So if some complexity is inevitable, then what should we do with it? I recommend compartmentalizing it in one place. Put it behind an iron-clad facade with a well defined interface. Behind the interface, be as ugly and brute-force as necessary, but beyond the interface keep the system elegant and generalized. Then at least the complexity is obvious, discoverable, and easier to maintain.