How to target="_blank" a link while keeping it XHTML compliant with jQuery

I had to make a bunch of links for a site I am working on for a client at work open in a new window.  It's not ideal but it was what was requested.

So I set up my links like such:

http://ralphwhitbeck.com

I run my page though a HTML validator and am quickly reminded that the target attibute is not allowed in the XHTML 1.0 Strict standard.  I do a quick Google Search and the first couple of results bring back the following function to make it compliant:

function externalLinks() {
 if (!document.getElementsByTagName) return;
 var anchors = document.getElementsByTagName("a");
 for (var i=0; i    var anchor = anchors[i];
   if (anchor.getAttribute("href") &&
       anchor.getAttribute("rel") == "external")
     anchor.target = "_blank";
 }
}
window.onload = externalLinks;

This function expects there to be a rel="external" attribute inside the links you want to open in a new window.

That function to me looks scary and ugly.  jQuery to the rescue.

$(document).ready(function(){
    $("a[rel='external']").attr("target","_blank");
});


I was able to shrink all that down to one line of jQuery.  And it's a lot easier to read and more importantly it now makes the document XHTML compliant.

Note: I did notice a huge argument/discussion on if this is really truely standards compliant.  As when you take the generated html code and run that through the validator you still get the same compliance error.  While others say that you are separating the action from the presentation and that satisfies the standard.  Thirdly others say that target was depricated and as such we should never use it because the standards people think we shouldn't open new windows on people.   I don't know whose right or whose wrong but I did find the discussion interesting.  Thoughts?

Book Review: "Smart & Gets Things Done" by Joel Spolsky

I went into Borders the other night to look at books that I wanted to buy.  I wasn't actually going to buy them but just wanted to see what books looked good and would pick them up on Amazon.  Cause let's face it Borders charges full price for it's books Amazon doesn't.

Anyways, I ran across a book by Joel Spolsky called "Smart & Get Things Done".  Now I know of Joel from the Stackoverflow podcast he is doing with Jeff Atwood.  He is the founder of Fog Creek Software that makes the project management software FogBugz. Before that he worked for Microsoft and Juno Online Services.  He was even a paratrooper in the Israeli Defense Forces (an interesting fact that I learned from the book).

The book is pretty small and short. It's 182 pages and I was able to read it cover-to-cover in a few hours in one sitting.  This book is aimed at those who hire technical talent to their organization (aka Programmers).  This affects me as I have recently been tasked with hiring co-ops for 6 month positions at BrandLogic.  I have hired three people so far but I feel that I could learn quite a bit in the interview and selection process.  I actually purchased the book from Borders that day because it was less the $20 ($16.99 at Borders, $11.55 at Amazon) and because I found it to be an easy read and it would be a great help to me going forward.  I think this book would also be great to programmers who are about to head into the job market.  This is a great insight into what hiring managers are looking for.

Joel goes through the whole gamut in hiring a developer.  He starts out by outlining how one measures a great developer, defines where to find great developers, to what makes a developer happy.  He then goes through the selection process with how to sort through the resumes to weeding out candidates with a phone interview. He gets into the details of the interview once you have a candidate that has passed through the selection process before it.  Finally, Joel takes through the hiring process and talks briefly on how to fix suboptimal  teams.

I felt that the book was direct and outlined the issues with hiring developers and talked about how the great developers are not on the market.  Advertising for jobs in traditional job boards (Monster.com, Craigslist, etc.) is only going to bring out the desperate job seekers the great developers are going to seek out the exact job that they want.  Getting resumes from the traditional methods is only going to bring in a lot of noise and lot of resumes that just don't fit.

So where do you find great developers? Joel states three ways to finding great developers: 1. Go to the mountain- Go to conferences where great developers will hang out and start conversations.  WWDC for Apple Devs, PDC for Microsoft Devs, etc. Go to conferences where early adopters might hang out (Ruby on Rails, etc) and talk to them.  2. Internships - This is the method that BrandLogic employs.  Being that 100% of our office is RIT graduates we also feel our duty to help fellow RIT students with achieving their credits to graduate.  Anyways Joel's philosophy is that if you can bring in a student one, two years before they graduate and have them working in a summer internship it's like 6 months of an interview at the end of which you can thank them for their work and send them on their way or give them a offer in which you know exactly how they are going to work for you without anymore risk. And Finally the third way is to Build your own Community.  Basically if you start a blog or are known to people in the blogosphere and have a community following then when it comes down to needing to fill a position and you post a comment on your blog about that you will seem to get a higher quality selection of resumes to pick from.  Of course this is all easier said then done.  The how to build a community and being able to attract people is all hit or miss and Joel alludes to that.  It's not the easiest thing to do but if you can build a community it's a great resource to draw from.

Joel tries to define a developer in terms of how to make them happy and egger to work and thus more productive or be hired.  He stats each  developer needs his own private office.  This will make them more productive.  He goes into the reasons behind all of this.  One point is that developers seem to get into a zone when developing and a private office will help them stay in that zone longer.  Additionally he goes into the physical office, big monitors, Areon chairs, etc.   But the important part and the piece I think we've really tried hard to encompass at BrandLogic is that the personality of developers has to be inline with everyone else.  You can't hire jerks and think that people are going to be happy to work with jerks, even though he states Microsoft does just that.  Ha!

Sorting out the resumes.  Joel lays out his criteria for sorting out the good from the bad.  Don't hire someone based on a resume but eliminate people based on their resume.  Some criteria to look for Passion (look for evidence for passion to work with computers), Pickiness (look at their resume for glaring errors), English (can they communicate effectively in their resume, if not probably aren't going to communicate effectively in a team), Brains (high GPA or some other high honors [I disagree with this as it relates to our selection process at BrandLogic]), Selectivity (Has the applicant been though another selection process meaning did he make it into a school that only accepts 30% of it's applicants or something similar [again at BrandLogic we favor RIT and usually only advertise at RIT that this isn't an issue for us]), Hard-Core (ability to work in hard-core languages like Assembler etc. is seen as being better then working with Java or PHP [again I don't entirely agree with this statement, we look for someone with web programming experience so hard-core languages don't usually add to the experience desired for our needs]) and finally diversity (ability for new people to bring new ideas and ways of thinking to the table [I whole-heartily agree with this statement]).

After you've sorted through the resumes you need to weed through the resumes with a phone interview.  This will save money as you can probably get eliminate many people by just talking to them.  One example Joel gives is that after ten minutes he felt he couldn't stand listening to a candidate any longer. He was able to weed that person out and saved money on not having to bring him out.  The benefits to a phone interview is that you can listen to what someone is saying without visual prejudices getting in the way.

The Interview.  Joel works in NYC so for him he uses the city to entice his potential hires or if they don't work out in the interview at least use that experience to still leave an impression on that person. When they go home and tell their friends how awesome the place was and how awesome the interview was, their friends will apply next summer for that chance for the trip. This all goes back to how to find great developers.  By using your interview as a way to get known virally it's another way to draw them in. 

The interview needs to be a conversation and needs to have the applicant writing some kind of code.  It doesn't matter what language the code is in or if it's right or wrong the purpose is to get the person talking to find out how they think, how are they going to solve a problem.  If they make mistakes see if they catch them, ask them "Are you happy with this code?" and see if they catch their mistake.  Even if they don't make a mistake it'll be great to see if they are confident to say yes it's perfect when you ask them if they are happy with their code. Don't dwell on the technicalities you should base your decision on whether the person is 1. smart and 2. can get things done. 

Joel's company has many developers interview a person and usually has them come back with a HIRE or NO HIRE verdict within 15 minutes of the interview.  One person usually can't decide their fate but once a certain number of people come back with NO HIRE the interview is over and they won't be hired.

The rest of the book goes into how to hire someone and how to deal with a team that might be poisoning the rest of the team.  I'll leave those chapters to you to read.  I think the dealing with a team chapter is just a brief insight into management but Joel gives his recommendation into other books you can pick up to help with project/team management.

I really enjoyed this book. It was easy to read and was clear and to the point.  I have many ideas on how I can update and tweak our interview process at BrandLogic for future hires.

Help support this blog by purchasing this book from my Amazon link.

My first JSON Implementation

I wanted to share my first real use of JSON (JavaScript Object Notation) I created today at work.  The reason I find this exciting is cause I never really understood the use of JSON or how to create and use it.  I found a simple use when I wrote about pulling in twitter updated into my blog using jQuery and the Twitter API using the JSON data, but I didn't create the JSON and was just consumming it.

Well today I was tasked with creating a JavaScript array that could be easily updated by an administrator of a web site and the data would be used to populate a dropdown box.  Yes there are probably better solutions to populate a dropdown box but this was what I was tasked with. 

Now a year ago, I would have probably created an XML file to hold onto this data but a recent blog post from Jeff Atwood over at Coding Horror made me realize that XML is ugly.  From that article JSON seemed like a cleaner choice.

So basically my data needed to hold geographical regions of the US with sections or cities for each region.  Each region/city would have a url associated with it.  So in a separate js file I created this:

{ regions: [
                    {
                        text: "NorthEast",
                        value: "http://ralphwhitbeck.com/northeast",
                        sections: [
                                         {
                                            text: "New York",
                                            value: "http://ralphwhitbeck.com/newyork"
                                         },
                                        {
                                            text: "Boston",
                                            value: "http://ralphwhitbeck.com/boston"
                                         }
                                     ]
                   },
                    {
                        text: "South East",
                        value: "http://ralphwhitbeck.com/southeast",
                        sections: [
                                        {
                                            text: "Orlando",
                                            value: "http://ralphwhitbeck.com/southeast"
                                        }
                                      ]
                    }

                ]

}

So looking at this you can see that it's very clean and easy to read.  We can see that it's two levels deep and we can see which sections are related to which regions at a quick glance.

Now I needed to take this JSON data and consume it and populate a dropdown.  I turn to jQuery to help me out (which was very slow today due to the 1.5 release of the UI plugin).  Here is the code to consume display it:

$(document).ready(function(){
    $.getJSON("sections.js",function(json){
        $.each(json.regions, function(i,ritem){
            $("#select_dropdown").append("" + ritem.text + "");
            $.each(ritem.sections, function(i,sitem){
                $("#select_dropdown").append("--" + sitem.text + "");
            });
        });
    });
});

This requires a select element on the page with an id of select_dropdown. 

Download the example code JSON_Example-DamnRalph.zip (1.24 KB)

Update: So an interesting problem came up at work today where we needed to validate the JSON because the data we entered had a syntax error (we figure this was the case cause it wasn't working as expected) and so we needed a validator to validate the JSON data.  Unfortunately the way we are consumming the JSON if it tries to parse it and it's not valid then the user doesn't get an error (is this the desired choice in jQuery's getJSON method?) so there is no feedback to what the sytax problem might be.  We found this online JSON Validator that worked to help us identify the syntax errors.