This is the second version of this post, I pulled the first off the net earlier this week because I really wasn’t satisfied with it. I wrote the first out of frustration, and that never works well for me 🙂
It started with my own hyperbolic metaphor:
Because I was frustrated about this hyperbole from Maciej:
If you listen to the WordPress people, the answer to this is ‘be extremely zealous about updating your software’, which is the same as saying, devote half your life to learning and understanding WordPress administration.
I think I’m frustrated with the hyperbole because I hear this kind of thing all the time, and for a peer technologist to pervade the myth that being responsible with software is going to cause a significant investment in time or that the only way to protect yourself is not run the software in the first place? That’s frustrating. But we technologists, we like the hyperbole.
There are two core points I think: keeping your software upgraded (well at least most software upgraded, and that includes basically everything short of things like SAP and Peoplesoft) does not require you to spend “half your life” You do maintenance on your cars, you do maintenance on your house, you just do these things. If you don’t, and sometimes we don’t, then things change over time, the externalities cause things to break. You just hope that the software is updated, or hopefully it’s licensed in a way that you can find somebody that can update it for you if you can’t.
It takes some upfront responsibility and education to understand what you are doing, and it takes some ongoing responsibility to stay on top of things. That’s just what responsible people do. You run software update for your OS. You keep your apps updated when folks fix flaws and bugs. You update your web software when it needs it.
There are some that won’t make that investment. I think it would be foolish to say they “can’t” As my grandfather used to say “can’t never could do anything”. Anybody can do it, just like I can change my own oil. But I don’t, because it’s not worth that investment for me. For others, maybe it’s not worth the investment to run your own software. In that case, it’s fine, let somebody do it.
But you can do it. You just have to want to. And don’t listen to the suggestion of anyone that tells you not to do it if you do want it. Because it’s not that hard.
A few weeks ago I mentioned that I was revamping my lens lineup. This is probably my next experimental evolution with photography – which for better or worse consists mostly of pictures of these two jokers.
My first DSLR lens was the Nikon 18-200. It’s a really great travel lens, it’s hard to beat the range. Over time though, I tired a bit of the lens creeping (which should be mitigated with the second generation of it) – and I guess I was a little bit spoiled with my third lens purchase, the Tokina 100mm Macro – which at 150mm effective and fast enough to get the dogs running around the yard, has become more of a portrait lens than a macro lens for me.
It may be still my favorite. Giving me pictures like this:
And after completely data-geeking out on running exiftool against all my 18-200 lens photos and realizing that almost 50% of all the pictures I took with it were at 18 or 200 – I decided I’d be well served going Wide. And Long. And trading in the one to broaden my horizons a bit.
So I went with the Nikon 10-24mm on the Wide end.
And the Nikon 70-300mm (VR) on the long
And even with quite the dance of lens-changing on the trails – I haven’t had that much fun with my camera in quite some time. I couldn’t be more pleased with both – especially on my first outing with them, a trip my wife and I took to the mountains on the NC/VA border:
All three (the two lenses and the Mountain Vacation 🙂 ) are highly recommended.
Because every good technical discovery is based on trying to prove someone else wrong, I set out this evening to try and prove that the iPhone cache limits are no longer what this 2008 YUI blog post says.
The 2008 article is awesome, but the problem is that the article is taken as gospel now. And the problem with that is that the prototype framework (and I assume the jquery framework too, but I’m not as familiar with technical details there) is well over the gospel-assumed 25K limit. Prototype in one of our rails apps (which is using Prototype 18.104.22.168) clocks in at 126KB uncompressed and 29KB when compressed using mod_deflate.
The gospel then assumes that you can’t use prototype in iPhone (Mobile Safari) web views without killing performance. My own assumption was “WTF? That can’t be right”
And at least with the iPhone 3.0 Mobile Safari on my iPhone 3GS – I’m pretty convinced this is not the case. After spending about 30-40 minutes realizing that I had the cache disabled in Firefox. And then I had mod_expires loading, but not active for our web apps – I’m watching an approximately 39 item, 562KB web page (yes I know, don’t ask, but mod_deflate is turned off) being happily cached in Mobile Safari. Either getting 304’s for everything, or just not making the request once I finally fixed the mod_expires headers issue.
I do not know what the limits are, search turns up questions and no answers. And I’ve gone through iPhone developer and other documentation – even WebKit Framework headers (not that I really expected them there, but you never know) – and I can’t find an answer on what the limits are.
I just completely believe right now, with the limited testing that the limits are no longer 25K and 19 items. It’s definitely higher. But I need to do more testing and probably get some peer confirmation out there.
Lazywebs? Any better answers here?
Ain’t gonna be no rematch, don’t want one