Archive for the ‘Development’ category

« Older Entries

Pass that Interview 1: Mimic a Class in Javascript

February 10th, 2010

Javascript, unlike most object-oriented programming languages, does not have the concept of Classes. Instead, Javascript uses a model in which objects are created, cloned, and enhanced by creating copies of the objects (it's loosely based on the Prototype pattern). There is a lot of power in this Prototypal system and people like Douglas Crockford have shown how Prototypal inheritance can be implemented in Javascript. This type of work is really cool; unfortunately it's not generally well-known or well-understood and many developers wish to use Javascript to simulate the more familiar Classes & objects as seen in languages like Ruby and Java.

Due to this simulation being common practice, the following has become a fairly common interview question:

How do you create a class in Javascript?

The answer is a bit wonky; but pretty simple to follow:

» Read more: Pass that Interview 1: Mimic a Class in Javascript

Comments »

Posted in Development

Tags:

My Impressions of Google Web Toolkit (GWT)

February 8th, 2010

Recently I've been asked several times for my opinion on the Google Web Toolkit (GWT)  and I've given much the same response each time. Now, it's easier to consolidate my thoughts and share them with everyone via my blog.  I want to preface this post by stating, as I always do, that I have not taken a "deep-dive" look at GWT and, due to my stance below, I haven't seen a reason to do such research.  I also want to state up-front that I don't believe there's any inherent flaw in GWT that prevents me from using it; nor do I think it's "bad technology." Finally, I've done my best to not allow my general distaste for Java influence my opinion of GWT.

I do not believe that GWT offers a unique value proposition as a platform that establishes any advantage over other Web development platforms such as traditional HTML and CSS or Adobe Flex. Additionally, there are some clear areas in which GWT lags behind these counterparts. » Read more: My Impressions of Google Web Toolkit (GWT)

Comments »

Posted in Development

Tags:

How Self-Executing Anonymous Functions Work

September 24th, 2009

In my recent post on creating a jQueryUI widget, I referenced the concept of self-executing anonymous functions. I've actually had a few questions come up at the office lately about how they work, so I figured turning it into a blog post might not be a bad idea. It's an important concept in Javascript many don't know about. Others know how to use them, but don't really understand how or why they work. Today I'll cover step-by-step how to go from a traditional function to a self-executing anonymous function; hopefully it will be clear at the end how these things work.
» Read more: How Self-Executing Anonymous Functions Work

Comments »

Posted in Development

Tags:

Create a Basic jQueryUI Carousel Widget

September 17th, 2009

One of the topics that was of great interest at #jqcon was jQueryUI and it's impressive widget library.  What didn't receive as much attention was how exactly to go about creating widgets that are compatible with jQueryUI.  In this first of a series of articles in jQueryUI development, we'll cover the basics of creating a simple jQueryUI widget.  In future articles, we'll look at how to pair widgets together using the Publisher / Subscriber (pub/sub) pattern.

This carousel is probably not quite robust enough to be deployed to production and I urge you to avoid copying and pasting this code into your live site. This basic carousel aims to teach you how to build one yourself as well as how to build a jQueryUI widget.

Create the Basic HTML Markup

To begin, we need a basic page and some photos thumbnails to work with. The thumbnails, as you'll see later, can be any size you choose and our carousel will expand to fit them. Note especially that we're only including some basic shell markup.  There are a few good reasons for this decision: First, it keeps our basic document clean and free of extraneous markup. Second, it is far less work for people implementing our widget—and fewer potential points of error in their process.

<div id="slide">
    <div>
         <img src="img/carousel/0_10.jpg" width="78" height="29" alt="" />
    </div>
    <div>
         <img src="img/carousel/0_11.jpg" width="78" height="58" alt="" />
    </div>
    <div>
         <img src="img/carousel/1_6.jpg" width="78" height="58" alt="" />
    </div>
    <div>
         <img src="img/carousel/1_4.jpg" width="78" height="58" alt="" />
    </div>
    <div>
         <img src="img/carousel/0_9.jpg" width="78" height="58" alt="" />
    </div>
</div>

For demonstration purposes, I've chosen the Cupertino theme available for download from the jQueryUI ThemeRoller application. You can choose any theme you desire—or create your own. Also, you can see I've created a reference to a  carousel.js file. We'll create this file as we continue.

Create the basic framework of a jQueryUI plugin

Now that we have our basic structure in place for the carousel, we can begin to create the javascript that will control the animation and interaction. jQueryUI provides a great construct called $.widget() that will encapsulate all of the functionality of the widget within a single namespace and construct. Let's start by creating a basic widget:

» Read more: Create a Basic jQueryUI Carousel Widget

Comments »

Posted in Development

Tags:

Quick Javascript Tip: Pass an Options Hash

July 13th, 2009

A quick Javascript tip that I pass along in a lot of code reviews is to make use of an options object as a hash to pass a large number of parameters to a function without writing each one individually.  For example:

function doSomething(id, someParameter, anArgument, optionC){ };

vs.

function doSomething(id, options){ };

By encapsulating the 3 additional parameters into an options object and passing them individually, you make for cleaner code.

A quick caveat is to check the options object to ensure that all of the necessary properties exist before running your function.

Comments »

Posted in Development

Tags:

Hiring Top Talent: It’s the Process

June 2nd, 2009

In August 2008, I was tasked with beefing up our User Interface Engineering staff for the AutoTrader Classics project.  Up until that point, managers had always been in charge of hiring new engineering staff; however, our director agreed with a suggestion that several of us made that engineers were more qualified to hire new engineers than managers.  This belief is not an indictment of our talented management team--it's only a statement that people in general are not qualified to hire for a job they don't truly understand.  So, I set about not only to hire the engineers we needed; but also to redefine our process for recruiting new talent.

37Signals suggests today that the resume is less important than the cover letter.  While I agree with their points, many companies use staffing vendors and don't generally receive any cover letters.  In the absence of such a letter, we're left with only the resume for a first impression.  These are reviewed by one of a team of Senior Engineers who focus primarily on your work experience.  Giant lists of skills with years of experience will tell the hiring company nothing that work experience will not.

Recommendation 1: Staffing vendors will want you to add a "laundry list" of skills to your resume.  Recognize that this list is for the vendor's benefit--not the hiring manager at any company.

Years of experience are downplayed; what we really look for is: "Does this candidate's resume read similarly to how our own resume looks."  This fact is a great advantage of having engineers hiring engineers--we know what it takes to be successful in our roles and can spot it far easier than someone outside the role.

From there, it's on to the phone screen. As they say, "time is money," and conducting several phone screens is far less time consuming than conducting tons of face-to-face interviews.  In our case, this screen is typically a 10-20 minute phone call where very directed technical questions are asked.  Most of them are fairly basic, but they serve two very important purposes:

  1. Resume Validation We want to see that you can actually answer questions that your resume suggests you should be able to answer easily. It is truly amazing how many people "pad" their resume so much that they quite honestly don't know what's on it.
  2. Gap Fill Your resume isn't going to hit on every point we're looking for in a candidate; we're going to use this chance to "fill in the gaps" and see if you bring more to the table.

Recommendation 2: Request a copy of the resume a staffing vendor sends to a prospective employer.  Often vendors will pad your resume themselves in hopes of making you appear more marketable.  Do not work with any vendor who insists on this practice.  You must be prepared to answer questions related to what's on your resume so you need to know exactly what's there.

Past the phone screen, it's time to move to the face-to-face interview (though this could be conducted via a web conference, it is easier, and in my opinion better, to do it in person).  We choose the panel interview as our format, 3-5 Senior Engineers (depending on the level of the positon we're hiring for) will ask questions, provide coding questions, and you'll be asked to do at least one fairly simple free-form coding exercise.  Again, there are reasons for this format:

  1. Panel Pressure Sitting up in front of a panel of Senior Engineer interviewers is daunting to say the least.  We strongly believe that grace-under-pressure is a characteristic of truly great people, and the panel is a truly organic way to see it in action.
  2. To do the job, you have to do the job I hear a lot of people saying, "I don't like coding tests in interviews." I've said it myself.  What I don't like are coding tests that are more like code reviews than exams.  We provide coding questions to see whether or not you really can jump in an work in our world.  If you can't debug some simple Javascript on command, you're likely not ready for this position.

This "grilling" typically lasts from 30-45 minutes.  The truth is, after even 15-20 minutes, we're already starting to form an opinion.  Nothing we require in an interview is truly difficult (at least, it shouldn't be for even a moderately competent engineer), and we see a lot of candidates either shine at it or fail miserably.

Recommendation 3: You may find yourself "on the bubble," you didn't breeze your way through the technical part of the interview--but you did quite well.  Personality is key!  A person on the bubble who we like will be more likely to get hired than a drone who knocked out the technical questions but bored us all to death. Never underestimate what your personality can buy you!

Those who succeed in our screening process join us as contractors for 3-6 months.  And that time period is the real interview.

Recommendation 4: Ultimately, represent yourself honestly. If you don't and you manage to sneak through a process, you will be discovered and you will be out of a job without even a quality reference to show for it.  It's better to get a job that you're qualified for and can love then to find yourself overwhelmed.

Comments »

Posted in Development

Workaround: Form Submit Method Doesn’t Fire Submit Event

May 14th, 2009

Recently I've become even more frustrated than I've been in the past with the disparity between Javascript Events and Javascript Event Methods.  This time it was specifically related to form submission.  Currently, despite the specification stating otherwise, browsers do not fire a submit event when a form is submitted via the submit() method.  Of course, this means if you have an event listener tied to that submit event (say, for form validation) it will never happen because the event hasn't been fired.  However, we can work around this limitation using a little Javascript magic!

Essentially, we can overcome this limitation by using the dynamic nature of Javascript to our advantage.  Even methods that are "native" to the browser can be extended by wrapping them.  As usual, there are some differences between browsers we have to account for.  Most notably, Firefox and other browsers that adhere to the DOM Level 2 Specification support reading and writing to the HTMLFormElement object.  IE, naturally, does not allow this so we have to take a more direct approach. In the example code, we use Prototype's Element#fire method which only allows for custom events. However, you could replace that by generating a standard event manually.

function fakeSubmit(event) {
    var target = event ? event.target : this;
    /* Fire a submit event */
    $(target).fire("form:submit");
    /* Call the real submit function */
    this._submit();
}

if(window.HTMLElement){
    /* DOM-compliant Browsers */
    HTMLFormElement.prototype._submit = HTMLFormElement.prototype.submit;
    HTMLFormElement.prototype.submit = fakeSubmit;
} else {
    /* IE does not expose it's HTMLElement object or its children
        Let the document load so all forms are accounted for */
    document.observe("dom:loaded", function(){
        for(var i=0; i<document.forms.length; i++){
            document.forms[i]._submit= document.forms[i].submit;
            document.forms[i].submit = function(event){
                var target = event ? event.target : this;
                $(target).fire("fake:submit")
                /* Call the real submit function */
                this._submit();
            }
        }
    });
}

With this in place, we can simply watch for our fake:submit event to fire and act upon it.  As I said previously, you could generate the submit event and fire it manually if you want to stick to using standard events--but this solution takes some of the cross-platform issues out of the way for you.

Edit: I've updated this code to fix a bug in IE6.

Comments »

Posted in Development

Tags:

Is Flash Still a Dirty Word?

May 11th, 2009

One thing I don't understand is that how in 2009 people are still put off by the use of Flash.  Seemingly dozens of frameworks have popped up to do animation using anything but Flash and none of them as well suited to the task as Flash itself.  There's no need to recount the gross evils perpetrated in the late-90's and early 2000's by over-zealous marketers using Flash so we can all understand where the disdain comes from.  But today I want to ask, why does it persist?

The 37Signals Blog, Signal vs. Noise, featured a post today about the new Backpack website.  In this article, the author expresses surprise that Jason, the head of 37Signals, was not opposed to using Flash on one of their websites:

It is funny looking back on suggesting Flash for the Backpack homepage. I was a bit embarrassed. Flash is such a dirty word especially when it comes to the audience reading this blog.

Also, in the comments, you find:

Wow. You guys are developing a pretty strong reality distorting field ! ;)

and

Why didn’t you just make the final product an animated GIF (instead of using Flash on the site)?

With Flash market penetration rivaling even Javascript, why is there this notion that Flash is inherently bad?  As a big proponent of Flex, I've written previously about the near-ubiquity of Flash player.  With Adobe taking Flash accessibility more seriously, and many resources availble for Flash SEO, it seems that most of the common objections are becoming obsolete. Perhaps the most compelling argument that Flash is truly mainstream is that (as of this writing) Alexa cites YouTube, a site whose primary content is served via Flash player, as the number 3 most visited website globally.

As someone who is a big fan of Adobe Flex and the possibilities it presents, I truly hope that this dislike of Flash disappears sooner rather than later.

Comments »

Posted in Development

Tags:

Kickoff to Delivery: The Most Difficult Phases

May 8th, 2009

Something I've noticed over the years of being an engineer is that project staffing tends to look something like, "Let's get our best and brightest involved early to get the project moving--once it's moving, the rest of the team can finish the job."  Part of this statement shows great sense for project delivery--and the other completely opposes it.  The two most difficult phases of any project are the initial kickoff and the final delivery--and you need a different set of people for each.

Looking at the philosophy above, it is generally understood that getting the ball rolling on a project is a difficult task.  Especially in the IT world where a project may call for some new technology that the majority of your staffers aren't yet up to speed on, it's great to bring people in who tend to be somewhat ahead of the curve.  They serve both to lay the initial groundwork in actual code--but more importantly they support the development of the staffers that will continue the work after they leave for the next project.

The best people for this phase are your leaders, your entrepreneurs.   They're some of your top technical people who also bring strong technical leadership to your team.  They inspire others to follow them into the project and motivate the people around them.  Most of all, they are able to charge into complex technical problems and tackle some big challenges early on and clear those roadblocks for the team while providing solid examples of how the team should proceed.

As these people move off the project, it is assumed that the team "left behind" will bring the project to its completion. However, completing a project presents the same level of challenge as starting it.  The challenges are different, but they are equally complex: fixing defects, tying up loose ends, and the inevitable realization that something that worked every time you tested it up until now has a couple of edge cases that, while not common, are possible enough that they must be accounted for in a new design. As a project approaches that end date, another personality type is required to join the team.  I call them "closers."

Closers are methodical, detail-oriented executors.  Winding a project to completion involves fixing often very delicate defects without destabilizing the entire system (or even large portions of it).  Rather than being solid team leaders, they are usually the absolute top technical talent you have.  They're people who have seen nearly everything that can happen as launch approaches and can maintain their calm while dealing with the challenges.  Most importantly, these closers act as a buffer between management (which is usually in full-panic mode as the launch approaches) and the rest of the team working to knock out those last few defects before launch.

We already put a lot of effort into people and process to get a project started; it's time to pay more attention to Closing the Deal.

Comments »

Posted in Development

Tags:

Emergence Drowns in a Waterfall

May 6th, 2009

In July of this year I'll be taking a class to become a certified ScrumMaster.  It will be the first industry certification that I've earned in my career--I've frankly never found them to be valuable so I've avoided them.  But as much as I'm passionate about building quality products, I'm even more passionate about the processes that enable building quality products.  And besides, what's cooler than a title that identifies me as Master.

The classical model of software development follows the Waterfall Model--that is, each process completes a set of deliverables and they "fall down" to the next tier.  At least, that's the theory.  In practice it usually works more like a set of walls that each group throws their deliverables over as they're completed--and the team who receives that deliverable is asked to follow that deliverable explicitly.  The further "downstream" you are in the waterfall, the more frustrating this process becomes as you get further and further away from the true objective of the project.

Often we find that when we fill the requirements, we don't really meet the objectives and happen upon a better way to meet the objective: this is called Emergence.  While attempting to reduce uncertainty downstream (often quite unsuccessfully), the Waterfall also restricts our ability to act on the Emergent Properties we discover in a system as it is built.  In my opinion, this restriction is the single largest cause of poor software design as it causes us to accept our requirements time leaps of faith over development time observations.

Emergent properties are very powerful tools to guide the way to great products and they should be embraced.  Scrum and other Agile methodologies support these properties while the Waterfall, with all pun intended, drowns them.

Comments »

Posted in Development

Tags: