Safari tip
Find Safari crawling to a halt?
This hint suggests why: the favicon cache, which is never cleared.
Mine was well over 6MB, and given that these are tiny icons, that's a lot. Hundreds. Try this:
find ~/Library/Safari/Icons/ -type f -atime +10 -name "*.cache" -delete
This finds all cached icons that haven't been accessed within 10 days (substitute a number of your choice), and deletes them (remove the
-delete to just list them). Let's see how it improves things…
Posted at 2004-09-01 14:50:14 by Richard • Link to Safari tip
, trackbacks.
Debugging
It's amazing the number of little errors I make in Cocoa that cause hours of debugging hell. Failing to retain an object in one situation caused no problem (because it didn't autorelease yet). In another, everything stopped working. In C, I would never have made these errors — I can
never tell when something is autoreleased, or I have to retain or release it. You know where you are with
malloc! Still, at the end of it I've got a little app that can sensibly request my newsfeed, download it, and feed it into my RDF store.
Things are starting to come together; I'm using another app to check that everything's loaded in, and to delete previous runs from the store — interoperability!
I think most of my problems are down to OO (which I do thoroughly understand, if not perfectly) and side effect-based programming (which is enormously unforgiving and hard to test). Paul Graham wrote in
ANSI Common Lisp about OO and spaghetti code
*:
The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. This is not necessarily bad, but it is not entirely good either.
A lot of the code in the real world is spaghetti code, and this is probably not going to change soon. For programs that would have ended up as spaghetti anyway, the object-oriented model is good: they will at least be structured spaghetti. But for programs that might otherwise have avoided this fate, object-oriented abstractions could be more dangerous than useful.
I notice this kind of thing a lot: contained classes having to maintain links to superclasses in order to call out to others, or every class having to have pointers back to shared utility providers. You end up with a UML sequence diagram that looks like a crossword, with webs of classes relying on calls in just the right order not to fall down. Are patterns the answer? I'm not sure (
i.e. they aren't necessary in an
expressive language). Patterns are codified observations about problems that often arise (and their solutions), quite probably because of the “materials” used. Just as when concrete removed the need for wooden frames, buttresses, and pillars, a more expressive language doesn't need many of the patterns people use daily in C++ or Java.
Also, I feel that life would often be easier if things were done more functionally, or even imperatively. Seeing Redland's client applications (which use “C with classes” to construct parsers,
etc., but are called from imperative code) it strikes me that OO is something that really only works with thorough design, in certain situations. As with all fads, it is often applied unnecessarily. Fortunately, scripting languages might cause a change in the prevailing wind.
But this could be my tiredness talking.
Posted at 2004-09-01 14:25:24 by Richard • Link to Debugging
, trackbacks.
Paul Ford on the Banality of Google
Brilliant. Worth reading for this alone:
They tested the evil brand concept one day, and the good brand concept the next. On evil day, they brought in vampires, werewolves, Satan, and a kraken.
- Google Focus Group Coordinator:
- When I say “evil” what do you think of?
- Vampire:
- Virgin necks!
- Satan:
- I am evil!
- Kraken:
- Can I have another 20,000,000 Diet Cokes?
Posted at 2004-09-01 00:29:28 by Richard • Link to Paul Ford on the B…
, trackbacks.
