Brian Crescimanno

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.

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.

Technorati: events, javascript

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.

Technorati: accessibility, flash, flex, seo

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.

Technorati: process, project management, staffing

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.

Technorati: agile, process, scrum

Jonathan Snook recently posted an interesting article titled Old Browsers: Do they still exist that explores the often hotly-debated topic of when it's ok to pretend a legacy browser no longer exists.

My pragmatism comes into play, like that little devil and angel on my shoulders telling me each side of the story. The fact is, these are old browsers. Why haven't these people upgraded? Why are all these people still using Firefox 2? So what if it's a little (or a lot) broken for them. They should upgrade.

I think most of us as designers and developers would agree with that sentiment; they should upgrade!

The problem, as is often the case, comes from outside the design and engineering teams responsible for building these sites.  It comes from business folks and QA teams that truly believe that "support" means 100% equivalency across browsers.  Any designer or developer will tell you it's a pipe dream and inevitably some concessions are made--but I'd be very interested to hear how much money is spent every year in this industry on trying to come as close as possible to identical cross-browser experiences.  This problem can be defined simply as a lack of consensus on the definition of "support."

My classic argument has always been:

Cross-browser consistency is nice--but in no way critical.  The vast majority of any audience is only ever going to see your site in one browser so let's instead of striving for identical experience let's strive for working experience.

The core of the problem is that we, as stakeholders in our projects, are by definition not users.  As a stakeholder, we open the site in multiple browsers to test, we know the expeirence we want to deliver--and it's easy to become frustrated when one browser behaves differently.

But to focus on the differences across browser is to ingore the truth: Your users aren't going to see your site in every browser.   Users will experience your site in their chosen browser and any feature that is inaccessible in that browser will simply not exist in their eyes.  It's called Progressive Enhancement, and its not a revolutionary concept.

It is, however, what can allow us to deliver a consistently working and functional experience to all users while still providing the "bells and whistles" to those who stay up to date.

Macro-level Support, that is, support for a site, is not about cross-browser consistency--it's about cross-browser functionality.  It's an important distinction.

Technorati: design webdesign browsers

Animation and motion are becoming more and more commonplace in modern web application design.  It's no surprise then that many Javascript frameworks provide sets of tools that allow you to easily add this motion to your application.  MooTools and jQuery both integrate a set of easing equations to improve upon the look of linear animation.  Script.aculo.us, however, lags behind in that while it does provide some functions to help the animation appear more "natural," it lacks a truly elegant solution.

Quick Link: View a Demo

Back in 2003, Robert Penner wrote a book on animation using Flash and with that book released a set of "easing equations" that could create natural-looking motion in Flash.  These equations attempt to model real-world motion behavior on the screen; and they do a remarkably good job of it!  So well, in fact, that both MooTools and jQuery have adapted Robert's easing equations into their animation libraries.  After searching in vain for a while to find an implementation of these equations using Script.aculo.us, I decided the best thing to do was create my own--not an overly easy task since Robert's equations were not directly compatible with the "Script.aculo.us way" of handling animation.

Today I'm releasing easing.js for Script.aculo.us 1.8.  I consider this version to 0.8 of this plugin since it does not succeed in porting the entire range of equations from Robert's original set.  The missing equations are:

• EaseInBounce
• EaseInOutBounce
• EaseInElastic
• EaseOutElastic
• EaseInOutElastic

The elastic functions should be fairly simple to port over; I simply haven't done them at this point.  The bounce functions, however, were originally written by Robert in such a way that they don't have easily identified counterparts in the Script.aculo.us world.  I will continue my efforts; but I do hope that in the true spirit of open source that others can contribute and improve upon my work.  Ultimately, I hope to submit this to Thomas for inclusion in the Script.aculo.us distribution.

I have provided a quick demo of each effect which is also included in the download package for your convenience.  Please feel free to provide any feedback in the comments.  I hope you find this contribution useful in your projects!

Download easing.js for Script.aculo.us 0.8

Technorati: animation, easing, javascript, motion, prototype scriptaculous, tweening

Taking a break from code samples and examples today, I want to talk a little bit about my philosophy about development.  Though it may surprise those of you reading this, I don't like writing code.  Sure there's that little bit of excitement that comes from a particularly ingenious snippet; but in general I don't like the process of writing code.  However, I contend that my greatest strength as an engineer is that I don't like to write code.

Lots of code is not brilliant code

I see them (and their code) every day; people who genuinely enjoy and revel in writing code.  These people can get completely engrossed in solving a problem; spend hours and hours working on the problem, and churn out 500+ lines of code that are truly a marvel to look at.  You stare in amazement as you look at this code; how thorougly complicated it seems.  The natural instinct of many developers is to look at that code and say "Congratulations to the brilliant person who solved this obviously incredibly complex problem."  It's just that there's a larger issue: a truly adept engineer will look at their code and say "Well why didn't you just do this?" and proceed to write 10 lines of code that do the same thing in a far simpler, more understandable, and easier to maintain fashion.  I'm sure just about everyone working in any type of software development environment has seen this.  The problem, I contend, is that it doesn't happen enough.

Don't write the code; solve the problem.

Technorati: code, engineer, overengineering

Javascript is, by it's nature, not an object oriented language.  However, everything in Javascript is an object.  So what you have are using objects to write procedural code; a truly intriguing concept.  It brings to light that having objects does not make a language object oriented.  Today I want to talk about the other two important concepts of object-oriented programming in Javascript--classes and inheretance.

In object-oriented programming, a Class is used to define an object; that is, it defines what characteristics an object has (its properties) and what it can do (its methods).  Javascript does not allow for either of these concepts in its native implementation (though we can work around this limitation with some clever programming that I'll cover in another article).  Today I want to look at how the Prototype library provides an easy way for developers to create and extend classes and objects of those classes.

We're going to start with creating a basic class.  Most tutorials at this point degenerate into some silly example involving a car, or an animal.  Given that I'm trying here to provide some real world perspective, I want to look at something we might actually try to implement.  In this case, we'll use a photo viewer.  We want to set up a viewer that can be passed a photo and display it.  Then, we'll use inheretance to extend the class to allow for effects.

Creating a Basic Class

var PhotoViewer = Class.create({
    initialize: function(){
    }
});

There are two important things to note in this example:

1. The Class.create() method is a prototype method that sets up a class for us.  The primary benefit we get from this is that the class can extend another class (which we will do shortly).
2. When a new object of this class is created, it will automatically call its initialize method.  In Prototype, initialize is the class constructor.

Now we need to add some methods to our class:

var PhotoViewer = Class.create({
    initialize: function(){
        this.photoContainer = $('container');
    },

    showPhoto: function(url){
        var imgEl = new Element("img", {src: url});
        this._show(imgEl);
    },

    _show: function(imgEl){
       this.photoContainer.update(imgEl);
    }
});

So now we've created our first class using Prototype.  The showPhoto() method is a public method that can be called from outside the object.  A URL for an image is passed into it and a new image element is created using that URL.  The _show method is a "private" method that cannot (in this case, should not) be called from outside the object.  It handles the displaying of the element.

Note that Javascript has no concept of public vs. private methods; therefore users could technically call this method wherever they see fit.  The _methodname convention is sometimes used to denote that a class should be considered private by developers and thus not called.

Extending a Class

Now that we have created our basic PhotoViewer class, let's create a class called AdvancedPhotoViewer that extends PhotoViewer to add animation to the image loading.

var AdvancedPhotoViewer = Class.create(PhotoViewer, {
    initialize: function($super){
        $super();
    },
});

There are again two important new concepts introduced here:

1. Notice that the Class.create() method now has two arguments, the first is the parent class.  By defining a parent class, our class now has access to all of the properties and methods of its parent.
2. The $super() method calls the method within the parent class that has the same name as the method in the child class.  By calling $super() in the initialize method of our AdvancedPhotoViewer, we call the initialize method of the parent class.  Were we not to call $super() on a method that has an identically named method in the parent class, the method would overwrite the parent method (which there are many times you want to do, which is why this is left for you to decide whether or not you wish to perform all of the tasks from the parent method first). You will see an example of this in a moment.

Now we want to add some animation using Scriptaculous.  We want the element to begin hidden and then appear using a fade-in transition.  For this, we can override the _show() method to call our animation rather than simply calling update():

var AdvancedPhotoViewer = Class.create(PhotoViewer, {
    initialize: function($super){
        $super();
    },

    _show: function(imgEl){
        /* Notice we don't call $super as we want to override the original method */
        this.photoContainer.insert(imgEl.hide());
        new Effect.Appear(imgEl, {fps: 50, duration: 0.5});
    }
});

As you can see, we've added code which will cause the element to fade in rather than simply appearing.  Notice also that even though we never explicitly created it within the AdvancedPhotoViewer class, we can access the this.photocontainer property because we called the parent constructor that defines it.

So there you have it; a brief tutorial on creating and extending classes using Prototype. I hope you found this tutorial helpful. Please feel free to post any questions you may have in the comments section.

Technorati: class inheretance, javascript, object oriented javascript, object oriented programming, oojs, oop, prototype

After my recent tutorial was posted on NETTUTS, I found the feedback filled with comments such as:

Jquery is the best and can be used to do all of this stuff plus more.

and

Yeah, I agree NETTUTS should only go away from jQuery when it can’t perform something

Reader Tim commented:

Nice. but which is best? Scriptaculous, Mootools, jQuery, or Dreamweaver CS3 built in apps?

What amazes me is not the sentiment so much as it's the nearly religious zeal with which these people are dedicating themselves to a code library.  So I wanted to take a moment to examine the question without that same type of bias--Which JS Framework really IS "the best?"

To attack this problem, we should first really define what "the best" means.  After all, if some code library is worth this type of devotion, I want to be pretty damn sure that it's the best!  So what does it mean to be the best Javascript library?  Here are some thoughts:

1. It's the smallest
2. It's the fastest
3. It provides the most functions
4. It provides the strongest application structure
5. It provides a plugin system
6. It provides clean methods to implement Object-Oriented Programming
7. It integrates with a powerful back-end development platform
8. It provides easily maintainable and extensible code.
9. It's the most widely adopted by the biggest sites

That list was literally written in 30 seconds off the top of my head; I'm sure the true criteria to establish which Javascript library is the best is a far longer list.  That said, we'll use these 9 criteria.   What do we notice about these requirements?  If you answered that some of them lie in nearly direct opposition to each other (such as 1 and 3) you're right.  If you answered that some of them can compensate for weaknesses in other areas (for example, 5 or 8 and 3) you're also right.  Even with a short list of 9 requirements, we know two things:

1. No one library is going to meet all of these criteria
2. Not all of the requirements are always requirements

If you're busy debating which Javascript framework is "best," you're fighting a religious war that cannot be won; simply put--no one Javascript library can be objectively defined as "the best."

Gee, thanks Brian.  But which should I use?

In my opinion, for every project, you should evaluate which library makes the most sense to use.  It is certainly reasonable to have a preference (for example, you may feel that jQuery works for about 75% of all the project work you do) and that's great.  You may even find areas of overlap where you continue to use your preferred framework simply because it makes sense. For example, if you know prototype very well but are less experienced with jQuery, you may want to choose to use Prototype in the interest of speeding development even if based solely on the requirements of the project jQuery would be a "better" choice.

My personal opinions

Since you're reading my blog, I will give you what I consider to be my reasonably well-informed personal opinions of the libraries I have worked with and when they make sense:

The library I'm most experienced with is Prototype.  The primary reason is that it is the library we have standardized on here at AutoTrader so I work with it extensively on a daily basis.  My feelings on Prototype are that it is a great library that provides a lot of great functionality, is for the most part reasonably quick (with some notable exceptions).  Both jQuery and MooTools have their roots in Prototype, so moving between those 3 libraries are probably easier than moving to and from others.  For general development, my familiarity with Prototype makes it my first choice.  The biggest thing Prototype has going for it is its implementation of classes and inheritance easing the transition for those very familiar with object oriented programming.

For everything I like about Prototype, I dislike Script.aculo.us.  The way its implemented seems silly to me (creating a new object for each effect is how you execute the effect?) and it doesnt "fit" well with Prototype's code style.  It lacks an implementation of Robert Penner's easing equations which make its animations look less impressive.

I have a strong love of jQuery; it's incredibly small, incredibly fast, and very much follows the paradigm of "get out of the way."  The plugin architecture is fantastic, and the jQuery UI library is great--fully integrated with the jQuery style of coding and integrates everything I'd expect from a fully-featured animation library.  These guys have taken the concept of dereferencing objects to an extreme level--and it can make jQuery code difficult to read at times when you have one line that chains 35 methods.  That said, once you understand its power; its actually quite elegant.

MooTools is another great library, and if you're looking to do a lot of heavy animation work, I'd even suggest it over jQuery.  MooTools began as an animation extension to Prototype that evolved into its own library--but their heavy focus has always been on providing the fastest, smoothest animations of any library.  Obviously its not limited to only animation work; but that's certainly where the bulk of its strength lies.

I'd also like to mention SproutCore--if your goal is to build a fully functional application within a web browser that relies less on Ajax and animation and more on solid application architecture, SproutCore appears to be an excellent choice.  I have far less experience with it than other libraries, but from what I've seen, it's MVC implementation is quite impressive!

I'll refrain from in-depth comments on other libraries with which I have no experience--but there are certainly a multitude of choices out there!

Always remember to take your requirements for the library into account on a project-by-project basis--and don't be afraid to work with multiple frameworks.  It only makes you that much more valuable to an employer!

Technorati: framework, javascript, jquery, library, mootools, prototype, sproutcore