I absolutely love this photo of moss growing on a little-used car in Montana. There’s a set of about a dozen closeups of the moss.
-
Archives
Flickr: Moss
Jun 8, ’05
5:46 PM
Test Post from Flickr
Jun 8, ’05
11:01 AM
This is a test post from Flickr to show Robin (and anyone else unfamiliar with it) the abilities of Flickr’s blog integration.
I went to the photo page in Flickr, selected “Blog This”, and composed this message. I had previously set up the connection to my blog application (WordPress), and customized the HTML output.
It’s very handy. (It doesn’t let me post post with the status of draft, however.)
The Apple and the Intel
Jun 7, ’05
1:38 PM
So, regarding Apple’s move to Intel processors, I don’t have terribly strong feelings either way. Except to say that I firmly believe that, when the option presents itself, change is better than not, so I look forward to what the switch brings.
I’ve been reading others’ responses, and I think Todd Dominey has some good things to say.
I agree with him when he says:
1) The move is most likely PowerBook-driven.
By all acounts, there was no way a PowerBook chassis was going to be able to handle the heat generated by the G5 chip, which is already 2 years old. PowerBook sales are stronger than Power Mac sales (plus laptop sales recently surpassed desktop sales within the industry as a whole), so Apple can’t afford to have its strongest product line (aside from the iPods) stagnating while their competitiors’ machines continue to get more powerful.
2) Apple’s preparation for the possibility that this day might come is incredibly impressive. Quoting Todd (emphasis mine):
The most impressive part of the announcement (for me anyway) was that the long-fabled “Marklar” project turned out to be true. This was the code name for a secret workshop in the basement of Cupertino where shadowy developers maintained x86 builds of OS X just in case Apple ever needed to throw the switch.
Now, think about that for a moment — to use an (admittedly cliche) car analogy, this was the equivalent of an auto maker producing alternate versions of a car’s engine, keeping them tuned, bug free and optimized, and locking them away in storage just in case the street versions didn’t fulfill expectations. Or from a web developer’s perspective, producing two, complete, functioning versions of a web site, using one online, and constantly updating the unused internal version with each and every site edit.
But we’re talking about something much bigger and more complex — a full blown operating system, and all the internal applications produced for it. Microsoft can’t seem to get a single version of Longhorn out the door for one platform, while Apple has released multiple versions of OS X for two platforms? That’s not just incredible, it’s stunning. I can only imagine how vindicated and proud Apple’s x86 team must feel.
3) The silliness of comparing magahertz numbers is over — the numbers simply weren’t 100% comparable between the processors, it’s apples and oranges, in my understanding. Now, when Intel makes a faster chip, both Apple and Windows machines can take advantage of it. Although — thinking about it — Apple is likely to stick with their traditional sales strategy, meaning specific models with Apple-chosen processors, updated once or twice a year. But who knows, perhaps Apple will start changing processors more quickly, and a Mac with new specs won’t be quite the event it is these days.
5 Years at Icon. Phew.
Jun 6, ’05
10:24 PM
Tomorrow is my 5th anniversary at IconNicholson. 5 years at Icon is twice as long as any other job I’ve had.
I was wandering through the files of sites worked on during my tenure, and I’ve worked on about twice as many projects as I would have guessed.
I should do a little Flickr gallery of screenshots. It would be kind of hilarious.
No More CSS Hacks?
Jun 2, ’05
11:46 AM
There’s an article over at Stylegala entitled No More CSS Hacks. It describes a method of using server-side script to detect a user’s browser type (instead of the traditional client-side methods) so you can write browser-specific CSS without resorting to javascript or CSS hacks.
At first glance, it sounds good. Thinking on it a bit, the examples they show would be a slight nightmare for the way I work. On a regular basis, I build fairly large, very corporate CSS-driven sites with challenging CMSs (read as: I work with integrators that aren’t always 100% familiar with HTML, much less well-formed HTML) and challenging designs (read as: designs that look good, but aren’t always conceived with ease-of-production in mind).
The upshot being I write long, dense, complicated CSS files that, on a good day, can be hard to parse (by humans, I mean).
Fortunately, I’m able to keep my CSS hacks to a minimum. The only hack I ever need these days is the IE underscore hack. If you’re not familiar:
div.foo {color: red; _color: blue;}
In IE, the color applied is blue, in all other browsers, red. The really nice things about the underscore hack is that it’s unintrusive, yet easy to spot by eye. It can be placed immediately following the item it’s overriding, so I can easily tell what is being “fixed.” In addition, making sure to throw IE6 into quirks mode means I get IE5 & 6 compatability at the same time, and the high quality of the other browsers we support (Firefox, Safari) means that I only have to hack for IE. (Not to say I don’t have other browser-related problems, but I’m able to fix them without CSS hacks.)
Anyway, back to the point. Applying the server-side techniques as they’ve laid them out, would make my CSS files a swamp of unreadable code, which isn’t acceptable, seeing as I often have to hand projects off to other developers (not to mention the client) once the initial development has occured.
That having been said, I do see a very graceful way to make use of server-side browser detection: Sniff for browsers in the HTML file, not the CSS file, and instead of writing browser-specific CSS, write a call to browser-specific CSS files. So, along with styles.css you can also have ie.css and safari.css and firefox.css, which are only written when the server detects those browsers.
It would still mean changing the way I write CSS a bit. Instead of the underscore hack, I’d write something like this:
div.foo {color: red;} /* color overwritten in ie.css */
This way I (or a future developer) wouldn’t have to be intimately familiar with the alternate CSS files, and wouldn’t go insane because I can’t figure out why the text is STILL RED in IE. (Believe me, I’ve torn out many a hair trying to debug something that was being overwritten farther down in the CSS file.)
It’s conceivable that CSS files might become a mess of comments, but which is better — a mess of human-readable comments? Or a mess of computer-readable PHP?