var selector

I haven’t posted something random like this in a while. I need to post more short content here since all of my long form writing is going on at other venues (more on that soon, I hope.)

Anyway, when building applications there’s often a need to build CSS selectors dynamically. This is typically some existing pattern paired with a loop counter or something pulled from a data attribute.

When I’m faced with that task I like to create a variable (called selector) and craft the selector on its own line. I then pass selector into jQuery. I do this for clarity and cleanliness. The clarity comes from the obvious way in which the selector is constructed. The variable name and the line solely dedicated to building the string makes it pretty clear what’s going on. The cleanliness factor is obviously a matter of opinion, but to me, passing a big string concatenation into jQuery just looks ugly.

So, what does it look like?

//slightly updated with feedback
//rest of a singleton here...
},
selector:function(id){<br />
//take the passed in id and build a selector with it
  var selector = id+&quot; &gt; tr:last&quot;,
	myHTML=&quot;&lt;p&gt;This is my paragraph...&lt;/p&gt;&quot;;<br />
//add some stuff to it
	$(selector).append(myHTML);<br />
},
deleter : function(){ 
//later on in  different function...
//grab the a data attribute from the element firing this event
//this would be an anchor or a button
var dataId = $(this).attr("data-id");
//build a selector with it 
  selector = "#list li[data-my-id="+data-id+"]";
//and remove the element from the list
  $(selector)
    .remove();
//unbind this click and remove the data attribute since
//the target element to delete is gone
$(this).attr("data-my-id","").unbind("click");
}

(Look at that, a nice, painless post knocked out in a few minutes. I could get used to that kind of pace.)

On Interviewing Front End Engineers: Be Prepared (or at Least Pretend You Are.)

On more than one occasion I’ve been interviewed by someone and they’ve told me, point blank, that they “didn’t prepare at all for this” or “didn’t even look at your resume.”

Really?

While this is lame no matter what industry or role, with front end engineers it’s incredibly frustrating.

Throughout the “Ajax era” any other experienced front end engineer has been interviewing from a relative position of strength. In my personal situation, I’ve been employed over the past five years by good companies, working with people I like and respect; but anyone with a strong background in HTML, CSS and (especially) JavaScript who is looking for a job is going to have several options available at any given time. That’s just the nature of the industry right now. We’re in an extremely fortunate place right now.

So… with that in mind it should be clear that if you’re hiring on the front end you have to actively recruit. This is just the reality of hiring front end engineers. Everyone wants someone great and there just aren’t that many great people around. If you find someone you’ve got to put forth some actual effort. I know all about this from both sides of the table. For example, we’ve had this role open at Isobar for ages and we haven’t found the right fit just yet.* There aren’t all that many people that fit those requirements.

So, what’s a candidate supposed to think when someone walks in and admits, in effect, that the candidate’s time and/or the role isn’t important enough to merit even minimum effort?

How is that recruiting?

It’s not, and speaking from experience, being on the other side of some of those comments it reflects poorly on the organization as a whole. People picked to screen and interview staff should recognize that it’s important for a team or organization. It should never be such a burden that they can’t even do the minimum, and in the rare occasions where it’s impossible to do proper set-up they have the common decency to pretend that they did so as to not insult the candidate. If the person you’ve picked to do interviews can’t do that minimum, it’s probably time to pull them out of the rotation.

Putting it simply: it’s hard hiring people that do what we do. You’ve got to take it seriously.

*Hopefully moving downtown will help us fill it (plus don’t you want to work closely with me? Wouldn’t that be awesome?)

In Cased You Missed It… Isobar Code Standards Updated and Posted to Github

So, as you probably noticed I did a bunch of writing for IBM earlier this year. Because of that I’ve got about a million draft posts here that I’ve got sitting in various states of completion. I’m going to work my way through them over the next few weeks. You’ve been warned (in a good way, I hope.)

Anyway, this happened a couple of weeks ago, but it’s still interesting (and important to me personally) so I thought I’d point it out again, in case you missed it the first time.

Over at Isobar we recently relaunched our Front-end Code Standards & Best Practices document and posted it up on Github to solicit feedback and changes from the community.

This document has made a strong impression in the year plus since Paul announced it and because of that we take it pretty seriously. To that end we wanted to update the design a little bit (just because it needed it) and have revisited a lot of the content to make sure it remains fresh and still reflects the current trends of web development.

So, check it out and let us know if there’s anything we can improve.

My Latest IBM Article is Live: “An introduction to Ajax”

An introduction to Ajax.

Get a technical introduction to Ajax programming, and discover the core JavaScript code and popular library implementations. This article presents a brief history of the technology, then outlines the technical basics of Ajax interactions using core JavaScript coding as well as three popular JavaScript libraries.

I’m Going to Be Talking About HTML5 at the Enterprise 2.0 Conference, June 23

Here’s the description of the panel I’m on:

HTML5 and its Impact on Enterprise Architecture (Location: Room 1)

Although not yet ratified as an official standard, HTML5 support is showing up across a variety of different browsers. And for very good reason: HTML5 includes support for an important range of functionality – much of which has a direct bearing on Enterprise 2.0 applications.

Join a panel of experts who will critically review the prospects for HTML5 across three areas:

* Enterprise Architectures
* Social Computing Applications
* Mobile

HTML5 is not a panacea, but it should simplify application development and help enterprises support a much wider set of mobile platforms. Come find out how.
Moderator – Jarrod Gingras, Analyst, Real Story Group
Panelist – Jonas Jacobi, Co-Founder and CEO, Kaazing Corporation
Panelist – Rob Larsen, Interface Architect, Isobar

I’ll be focusing on the mobile angle. I’ll be doing a 20-25 minute presentation and then will stick around to answer some questions.

It should be interesting as the audience for this is going to be far different than my regular open source and developer-centric audience. The really interesting part is that I’m going to be able to sell HTML5 to a crowd that might not be totally hip to the fun we’re already having.