Eastern US is Fertile Ground for Ruby Development

Eastern US Ruby Jobs and Consultancies

Eastern US Ruby Jobs and Consultancies

As I was perusing jobs on Rubynow I thought I was seeing a concentration of jobs in Florida, New England, and the Washington DC area. To test the idea a little, I decided to throw a sampling of the recent jobs onto a map (see Ruby on Jobs and Consultancies »). To that map I also added some of my favorite Ruby consultancies:

If you look at the whole (world) map I think you will agree that there is a definite concentration of Ruby jobs and kickass consultancies in the Eastern US. There are many biases at work here of course, especially when it comes to the consultancies I’ve listed. Nevertheless, it does seem like something’s going on here.

I’m intrigued by a few points:

What’s going on down there in Florida? Seems like I see lots of Ruby jobs down there.

What’s up with that DC area. I’d say the presence of Intridea and Viget within what, 10 miles of each other qualifies DC as a hotbed.

Look at that New England cluster. I think there is general awareness a big presence in New York, but the number of jobs in New England surprised me.

What is it about the Eastern US that makes it such fertile ground for Ruby? Is there some bias in the job listings on Rubynow? Or is this simply a reflection of Ruby moving into the enterprise. Is there a particular kind of enterprise that’s predominant in the East and that’s adopting Ruby technology?

Posted in marketing, Ruby on Rails | Leave a comment

Ive on Focus Groups

by eyesplash Mikul (flickr)

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.

Posted in Web as Platform | Leave a comment

OOCSS + SASS = Fewer Classes On Your Elements

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.

Posted in CSS, Ruby, tool | 12 Comments

Design Hope

snap from Veerle's Duoh! circa 1997

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.

Posted in design | Leave a comment

Secular Manger

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

wise men and a special infant

wise men, angel and special infant

Posted in diversion | Tagged | Leave a comment

Promiscuous Power

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.

Posted in Apple | Leave a comment

wordpress.com Migration Hang-up: OpenID Delegation

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.

Continue reading

Posted in OpenID | 4 Comments

Home Again

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…

Posted in DNS, identity, One Step Forward | 1 Comment

Are Ruby Session ID’s Secure?

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.

Posted in Ruby, Ruby on Rails, security | 3 Comments

Thought Propulsion™ is Go For Burn

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

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

Posted in design, iPhone, OpenID, Ruby on Rails, Web as Platform | 3 Comments