by eyesplash Mikul (flickr)

I was going to tell you about Jonathan Ive’s recent pithy pronouncement on focus groups to wit:

“We don’t do focus groups,” he said firmly, explaining that they resulted in bland products designed not to offend anyone.

But I won’t do that because when I went to Wikipedia to research “focus group” for the post, I noticed that their page had already been updated with the Ive quote. It had been updated on the same day as the original BBC dot.life article. Wikipedia surprises me again with its velocity.

update 3/29/2009 8:23 AM: Turns out Chris Eppstein is way ahead of me. Check out Compass. It’s a project that delivers your favorite CSS frameworks as SASS mix-ins. Oh and also it integrated with your favorite Ruby web development framework.

Stubbornella you have captivated me. I am now watching Nicole Sullivan’s Object Oriented CSS talk for the second time. The OOCSS framework is a terse but ambitious thing in the tradition of YUI Grids CSS and Blueprint but with opinions that reach beyond grids, resets and typography.

While I have certainly not mastered the OOCSS concepts I do have some early observations I’d like to share nevertheless. This of course is dangerous territory since I risk having to eat my words later. So be it. Feel free to feed ’em to me as appropriate…

It strikes me from looking at the UML diagram for OOCSS that something is missing, or more accurately, some things are being conflated which shouldn’t be. If we’re thinking about objects and classes here the first question should be: what are we modeling? Well the semantic HTML folks might say we need to model things like paragraphs and headings, or at another level contacts and phone numbers, or at another level sidebars and navigation. These are all semantics.

When we think about modeling these things in HTML in such as way that CSS can be profitably applied, we use HTML element types to directly model semantics where we can (p element for paragraph, h1 element for top-level heading) and we use class attributes to express the rest (’top-nav’, ‘address’, ‘phone’). If you have a look at the OOCSS UML diagram you will see in the “page layout” section a set of classes that fall into the former category ( ‘doc’, ‘hd’ for header, ‘bd’ for body, ‘ft’ for footer).

So far so good. But now how do we actually extend a class? The approach suggested in OOCSS is to change the (HTML) markup. One example from the talk is to specialize the media block class ‘media’ so that the fixed-size media is on the right instead of on the left. The suggestion is to define a new class ‘media_ext’ along with a new set of CSS rules. Then the idea is to change our HTML so that the element of interest carries two classes: ‘media’ and ‘media_ext’. And then we define some CSS for the new media_ext module, something like this:

.media_ext .fixedMedia { float:right }

This is the fundamental approach in OOCSS, so fundamental that it is on the short list of 10 Best Practices from slide 19 of the talk:

9. Extend objects by applying multiple classes to an element

The library defines a small set of base classes and a few core extensions to those. Users are invited to extend these further and we change our HTML to carry the full set of classes expressing semantics, layout and skinning too, all as separate classes.

The value in this approach is it certainly brings order to chaos. The downside is twofold: first we must pollute our HTML with layout and skinning choices and second, we must rely solely on coding conventions to ensure that each HTML element carries a self-consistent and complete set of classes.

aside: To me this feels much more akin to structured programming or maybe at best “abstract data types” than it does OO. I don’t really see language-level inheritance here, nor do I see polymorphism. But that’s just a terminological nit.

The first problem we need to solve is to get rid of the superfluous classes (on our elements). How could we make a media block (”fixed-width media object on the left with an open editable zone on the right”) into a right-handed media block without changing our HTML? Well the classic way in CSS is to use context to distinguish this situation. So let’s imagine that every odd media block ought to be right-handed. A classic approach is to have an ‘odd’ class on the element (or to use nth-child pseudo class). Perhaps something like this:

.media.odd .fixedMedia { float:right }

Where target is the fixed-width object we’d like to be on the right-hand side instead of the left. You get the idea. The problem with this approach is that we’ve just coded up some potentially reusable stuff (the {float:right} part) and we’ve got no way to reuse it in other circumstances. Also we are now guilty of committing pitfall #1 from the talk:

1. Location dependent styles

So you can see that we are definitely violating a key tennet of OOCSS. If you’re already an OOCSS dogmatist you may want to stop reading now. Still with me? OK, what if we want a right-hand media block for even rows next time? We’d have to edit that last CSS rule to look something like this:

.media.even .fixedMedia { float:right }

Yuck. What’s going on here? The problem is that CSS has no named/reusable/callable construct. No macro. No function. No Class. OOCSS does the best it can with plain old CSS by requiring us to define a new HTML class name. That lets us define a reusable set of CSS rules for it, but at the cost of polluting our HTML at each use.

I think a good way out of this is to break out of plain old CSS into a higher realm. Both SASS and CSS-SSC have a macro concept. SASS has its mixins and CSS-SSC has its base and based-on. What these actually add to CSS is named abstractions and reuse. So I could define a SASS mixin like this:

=right-hand-media
  .fixedMedia
    float: right

Now that is a reusable module. In my application I can apply that module to an element:

.media.odd
  +right-hand-media

Yay. Now I have the best of both worlds. If we have another app that wants even media items to be right-handed then we just define this:

.media.even
  +right-hand-media

The value of this is that I didn’t have to change my HTML markup in order to change the layout. There are examples of using the same approach to define a clearfix module. To those who say this approach is going to generate a lot of CSS I say, “well maybe, but I think our first priority needs to be making our source code manageable and this approach may just help us do that.”

As I already pointed out, this proposal (using SASS mix-ins or CSS-SSC macros to implement reusable modules, and then using contextual CSS Rules to apply those modules) violates a core principle of OOCSS. On the upside it solves one of the wish list items from the talk (on slide 60):

1. Extending objects—possible to make “sale module” inherit from “module”

.module{}
.saleModule{extends: module}

Now that approach is a bit different from the one I described for right-hand-media. But it is clear that mix-ins or macros could easily be used to reuse .module in .saleModule right? SASS mix-ins, for instance can be used (as in my first example) as straight-up mix-ins, or to implement inheritance. The choice is yours.

To close, I highly recommend watching the Stubbornella’s presentation. Twice. There is just a ton of gold in there. Meanwhile, I’ll go experiment with SASS mix-ins and let you know how it works in practice and how it can be combined with some of the other principles highlighted in the talk.

snap from Veerle's Duoh! circa 1997

Veerle is one of my favorite Web designers. She came clean recently and republished her first website circa 1996! She cited Jason Santamaria’s recent post about his own earliest Web work. OK so now I have another new favorite Web designer.

What’s so cool is how unappetizing, especially Veerle’s, early sites are. To be fair, hers was perpetrated four years before Jason’s. And those were four big years too. But my intention is not to criticize.

What strikes me about this exercise is that it shows once again that there is no such thing as overnight success. You see in the decade-or-so of work a progression from ugh/ho-hum to pow! Take heart. Keep working.

My daughter Mia just gave me the best Christmas present ever!

wise men, angel and special infant

I was the beneficiary of a new social norm at iPhone Tech Talk here in Seattle today. Unsurprisingly just about everybody’s got an Apple laptop and power outlets are scarce. What’s interesting is that since all our power connectors are compatible (MagSafe), folks are usually happy to just let you borrow their power supply for a while while you get a charge. Felt kinda uncomfortable at first. But that discomfort was brief. Now I’m boldly power surfing with impunity.

The first issue I’ve run into with my migration from wordpress.org (self-hosted) to wordpress.com is that I see no way to insert OpenID delegation links into my template.

See I’ve been using http://meme-rocket.com as my OpenID. By ensuring that my template had appropriate link elements, I was able to delegate actual OpenID authentication to JanRain’s myopenid.com provider. The idea was that rather than using my JanRain-issued OpenID everywhere, I’d use http://meme-rocket.com and then I’d be free to change providers at a later date if needed.

Since moving to wordpress.com I’ve found no way to add the necessary links to the template. Only answer I got on the support forum was:

Sorry, I don’t think you’re in the right place…

I get that a lot.

If I can’t get the folks at wordpress.com support to solve this it’ll mean I won’t be able to use my blog URL as my OpenID any more. That will be a little sad. Also It’ll entail groveling around to a bunch of sites and updating profiles. Worst case I may have to temporarily redirect my domain back to my (self-hosted) blog in order to authenticate (under my old OpenID) in order to change to a new one

update 15:19: well while it’s true that there is no way to insert those links, since wordpress.com is an OpenID provider I don’t strictly need the links in order for my blog URL to serve as my OpenID. I just verified that I am able to enter http://meme-rocket.com into relying party sites and that they are able to authenticate me. Minor issue that remains is that since I’m redirecting (DNS) meme-rocket.com to memerocket.com I actually get authenticated under the latter domain. So if I really want my accounts back I’ll have to temporarily un-redirect that domain and then log in to all the affected accounts and change them to use memerocket.com.

It’s been about 1 year, 8 months, 19 days since I lost memerocket.com. In the interim I ran this blog at meme-rocket.com.

Numerous issues kept me from moving it back to the original domain. First, of course, there was the fact that I didn’t have control of the domain at all for three months. When I did regain control in the summer of ‘07 I was right in the middle of the Oregon move. By then I’d been posting away and it just never seemed like a good time to switch back.

If you know me, you know I’ve got lots of opinions about what’s good and bad about our various online communication tools such as blogs, email, Twitter, forums. What better way to test some of those ideas than to um, write a prototype and then uh, use that prototype. So as ‘07 neared its end I made a little pact with myself that I wasn’t going to blog until I did so on my own stinking blogging platform (one I’d created).

Well what with the day job and design school and the family and all, that progress was slow. However in September, ‘08 I did launch a first cut as part of the Thought Propulsion corporate site. If you look at the blog tab there is a beginning there. Not a lot of the functionality is exposed yet and my assessment is that to expose a whole lot more is gonna take a whole lot more work. Go figure.

While all this was going on, my WordPress installation at TextDrive (the one running meme-rocket.com) got upgraded about once and was in need of another upgrade. I kept putting it off because I loathe upgrading WordPress. It makes me crazy that “themes” are not isolated from the rest of the system. It’s crazy that a WordPress upgrade cannot be push-button.

So I decided to go ahead and kill a few birds with a big hammer and set up a shiny new wordpress.com blog on my original domain. That’s what you’re reading now. I’m feeling great about this decision so far since:

1. I was able to use my own domain—yay!
2. I was able to reclaim my original domain
3. I was able (using my DNS provider dnsmadeeasy.com) to HTTP (permanent) redirect meme-rocket.com to memerocket.com
4. I never again have to upgrade WordPress

A few minutes after upgrading I received a positive message from The Universe in the form of a wordpress.com alert on my dashboard. It said that the system was going to be upgraded to version 2.7 in 23 minutes. And guess what. I didn’t have to back up my files or my database. And I didn’t have to do anything but refresh my browser to enjoy the sweet new UI.

On the downside I’m sure I’ll miss some customization features. More on those as I run into them. For now though, I feel like I got my old megaphone back. Get ready for some blasts. Ahem! And what of that early ‘08 pledge to roll my own. Well we’ll just have to see about that…

The question of the security of cookie-based session storage in Rails has pretty much been settled it seems to me. Out of the box, Rails uses cookie-based session storage. When you generate a new Rails app you get a nice new 128 character long (numbers and lowercase letters) secret set in config.action_controller.session[:secret] in your Rails::Initializer. That secret is used to sign and validate cookies for your application. Now the cookie data isn’t secret mind you, but it is tamper-proof. Good.

Now what if you don’t use cookie-based session storage at all? Well, just because you aren’t using cookie-based session storage doesn’t mean you aren’t using cookies. If your application has sessions at all, be they memcached ones or ActiveRecord ones, it is probably using cookies. It’s using cookies to store the session id so that when a request arrives, that id can be mapped to the corresponding session storage.

“So what” you say. “Well” I say… isn’t it cool that Rails generates that big random secret for you when you use cookie-based session storage? When we are not using cookie-based session storage, and that secret is not generated, don’t you wonder what secret is being used to secure your session id’s? You see, a session id must be hard to guess lest bad people gain access to your site. Usually when you want to make something hard to guess, you start with a secret and mix that with something that changes a lot and hash the whole shebang. So I went in search of this other secret.

What I found was that Rails calls CGI::Session#create_new_id to generate new session id’s. That routine uses no secrete per se. It hashes (MD5) a combination of:

1. the current date and time (expressed as a human-readable string)
2. the microseconds elapsed since the last second (expressed as a human-readable string)
3. a pseudo-random number greater than zero and less than one (from Kernel#rand)
4. the current process id number
5. the string ‘foobar’

Notice there is no secret keying material there. “But what about the Kernel#rand call Bill!” I hear you saying. If you go have a look at Kernel#rand and Kernel#srand you’ll see that if rand is called before srand is called with a number parameter then the random number will be generated from a combination of:

1. the current time
2. the process id number

So the security of these session ids hinges on the secrecy of current time (on the server running Ruby) and the process id. Given that the system time is returned in HTTP headers and process id’s are often in the hundreds or thousands, it’s only really the microseconds that are hard to guess here, from a statistical standpoint. Others have expressed similar concerns.

If you’re worried about this two suggestions come to mind:

• time out sessions on the server so that an attacker has to guess faster
• monkey-patch CGI::Session#create_new_id to hash its result with a great big old 128 character secret

Updated: October 15, 2008 expanded analysis of Kernel#rand and Kernel#srand and updated suggestions.

The Thought Propulsion™ corporate site is up and running. For the technically inclined, here are some interesting facts:

• hosted on Amazon EC2
• using the extremely slick EC2 On Rails Ubuntu/Ruby on Rails virtual appliance
• there’s a tasty microformatted hcard on the contact page (check it out with Operator)
• OpenID login (foreshadowing)

And of course a nice gray and orange theme just in time for Halloween.

I’ve been using Gmail since its inception and I’ve used it (the web interface) as pretty much my sole email interface for the past 18 months. During that same time I’ve been pretty much solely a Mac user and when I recently bought an iPhone 3G I thought it would be an opportune time to revisit the possibility of Apple Mail, Address Book, iCal since those integrate with their iPhone counterparts and synchronize with MobileMe (née .Mac).

Punchline is: a few days into the process I have decided not to use Mail App nor the iPhone counterpart. I am using Apple’s Address Book (with MobileMe synching). As for Calendar App vs. Google Calendar I’d say the jury is still out. Here’s what I’ve found…

Email

I wanted to continue routine all my email through Gmail in case the exercise went squirrely. Also I definitely wished to retain my Gmail email address as opposed to switching to a MobileMe one. No problem, Gmail offers an IMAP interface and the Apple mail apps both support IMAP too. One thing I found confusing was that the notion of synching email (via MobileMe) didn’t make much sense. My friends tell me that what is actually synched in that case is mail preferences and settings. The actual email messages are not synched per se since SMTP and IMAP do that job for you.

One thing I really like about Gmail is that I seldom delete emails. I delete emails forwarded from Google groups since I know they are archived on the groups. Basically I delete most stuff that I know is archived and available elsewhere. Also if someone sends me huge photos, I’ll download those to iPhoto and then delete the message. In this way I have managed to use “only” 390 MB of the 6943 MB available to me on Gmail. That’s 5%.

It is not obvious how to continue this practice using the IMAP interface. Some searching yielded a solution: to archive a message from Mail App, just drag it to the “[Gmail]/All Mail” folder. This has the same effect as archiving the message via the Gmail web interface. Problem solved.

Gmail threading is a necessity for me. The iPhone mail app doesn’t offer threading, but Mail App does. Just turn on “organize by thread” in the View menu. If the threading on Mail App worked more like Gmail’s then this would probably be acceptable since I use the laptop for heavy email use anyway.

The problem is that Mail App has a different idea of what threading means (versus Gmail). In Gmail the thread is the fundamental unit. This is not so in Mail App. In Gmail, you can archive a thread. If a new reply arrives on that thread then the whole thread returns to your inbox. This is not the case with Apple Mail. With the latter threads do not span “folders”. So once you archive a piece of a thread (one or more messages), when new messages arrive on that thread you will not see the older ones reappear in your inbox.

One of the truly great outcomes of adopting the threaded approach to email is that you eliminate the need to include original messages in your replies. In fact when you do this, Gmail hides the originals (”folds” them for you). If you assume that your correspondents are also using Gmail threading then it is never necessary to include complete originals in your replies. You end up quoting only small parts of originals and even that isn’t very frequent. So when you look at a thread it’s nice and clean. No redundancies in the replies.

A key Gmail feature that supports this approach is that the thread shows not only messages sent to you but also messages you’ve sent. Without the messages you have sent it can be hard to follow the thread (e.g. if you read it a week later). Because Apple Mail does not “knit” threads back together across “folders” and because messages you send are relegated to the “Sent” folder, you will not see messages originated by you integrated into your threads.

Gmail threading, with its elimination of redundancy and its ability to resurrect full-fledged threads when new messages arrives is critical for me. As a result I’m sticking with the Gmail interface for mail both on my Macs and on the iPhone. On the iPhone I’m using Google’s excellent integrated Google.com for the iPhone. That gives me iGoogle, Gmail with threading and Google Calendar all with iPhone optimized interfaces.

Contacts

All my contacts were in Gmail before getting the iPhone. Since then, I’ve exported them (as .vcf) and imported them to Address Book on the Mac and synched them down to the iPhone Address Book. I’ve configured address book synchronization via MobileMe. Also I set Address Book on my Mac to synch with Gmail (a feature that appears in Address Book after you’ve docked the iPhone for the first time).

Since then I’ve been combing through my contacts using the Address Book app on the Mac and the iPhone one too. Also since my contacts are now driving not just email, but the Phone app as well I’m cleaning up lots of first name/last name issues and consolidating duplicate records. It’s taken a bit of clean up since for some reason there are many duplicates.

This all seems to be working. And it is truly magical to tweak contact information on the iPhone and then see it magically updated (over the Web via MobileMe) on the Mac and in Gmail contacts. I don’t fully trust it yet since there are so many moving parts but the early signs here are very good.

I now have complete contacts available now via Gmail, Address Book App (on the Mac), Address Book App (on the iPhone) and in the Phone App on the iPhone too. It’s often bugged me that Google has not made contact management a first-class application. (I’m continually digging through links in Gmail to get to my contacts). Now I’ve got first-class contact management at my fingertips on my phone and my non-phone computers and it’s integrated not only with email but my telephone as well. This makes me very happy.

Calendar

I’ve set up MobileMe synchronization on iCal calendars but haven’t tried to synchronize between Google Calendar and iCal. Jury’s still out on this one. Essentially I have two calendaring systems at my disposal now. Both Google Calendar interfaces are darn good. There’s the general-purpose browser-based one and the iPhone-specific one mentioned earlier. Since calendar is much less critical for me than email and contacts I suspect this one will simmer for a while.