Stability or creative chaos?

January 4, 2012

Last night I joined Karthik Hariharan, Curtis Summers, and Greg Vaughn on the very low-tech bar stools at the front of the Dallas Ruby Brigade‘s monthly meeting. We, the panel, were there to discuss our versions of “The Path to Ruby”–topic courtesy of super-organizer Mark McSpadden.

Among the many interesting topics to emerge was the differing circumstances in which each of us were launched into our careers, post-university.

To over-simplify, I found myself contrasting my work-force entry roughly 20 years before my co-panelists.

1980s:

Stable but deadly?

  • Small-ish number of large employers
  • High demand for programmers: have Computer Science degree? Welcome aboard!
  • Nascent start-up/venture capital ecosystem (so as to be pretty much invisible to new grads)
  • Seemingly clear traditional career path
  • Well-defined, and narrowly defined, roles for CS grads

Early 2000s (ignoring for the moment the post-dot-com, post-9/11 meltdown):

Burning out of control?

  • Large number of small- and medium-sized employers
  • High demand for “rock star” programmers
  • Start-up/VC culture in full bloom
  • Many more career path options
  • “Programmers” often expected to double/dabble in stuff you didn’t learn in school, like visual design

Couple this with the rise of open source software, the ubiquity of the blog-twit-IM-chat-osphere, the trend toward shorter job tenures and multiple careers, and my younger co-panelists have spent their early careers in an environment radically different than the one I found post-university.

Which is better?

Depends.

We’re all different. From some of my colleagues last night, I heard a little yearning for a more stable work life. Understandable, particularly when you’re young and perhaps starting a family.

Call me a glass-half-full guy, but as much as I appreciated being in demand post-graduation, I also very much like today’s more dynamic, more creative environment. Never before in history have “hackers” been able to be so creative, to bring so much value into the world, as they are right now.

How about you? Pick your mix. What blend of stability vs creative chaos would you pick? 50/50? 75% stability, with a dash of chaos? Vice versa?

IE8 doesn’t like my HTML

August 3, 2011

The problem

jQuery('div#space-for-' + institutionId).html(data);

This seemingly simple line of code was working fine in Chrome and FireFox, but did not result in placing the “data” HTML content in the selected div. Nothing at all changed on the page when in IE8.

I tested it in jQuery-1.4.2 and jQuery-1.6.2 with identical results.

The cure

Finally, I tried inserting a simple HTML string directly in the html() method:

jQuery('div#space-for-' + institutionId).html('<h1>Testing</h1>');

And it worked. Hmmm.

Mind your closing tags

After some careful parsing of my HTML, I discovered a missing </div> tag. That was causing IE8 to ignore the (fairly length) inserted fragment altogether. Add in the missing tag and…voilà…all is well again.

Why is my select value not selected?

November 19, 2010

Hours battling this one. Symptom: select tag in a form was not displaying the value of the attribute from the database, although one could select a new value and have it saved as expected.

Had a simple (!) select tag, looked something like this:

  <%= af.select :state, options_for_us_state %>

No matter what manner of manipulation I did, including explicitly setting :selected =>, would cause the value of the state attribute from the ActiveRecord object to be selected upon page presentation.

After digging through the Rails code, I noticed that the select form helper was calling options_for_select. Looking at that code, I noticed that if the container of options that is passed in is a String, no :selected or :disabled processing is done.

But I’m not passing in a string, I’m…oops, my options_for_us_state helper was already calling options_for_select, thus giving me a string, thus bypassing the :selected and :disabled processing.

Interestingly, it created the select tag just fine, which is what did me in for so long.

Seems like possibly a Rails oversight. The doc for options_for_select doesn’t say that you can pass in a String. Nor does it say that you can’t, and Strings do respond to the each method.

But still, it’s odd behavior, no?


Follow

Get every new post delivered to your Inbox.