My Impressions of Google Web Toolkit (GWT)

February 8th, 2010 by Brian No comments »

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)

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter
  • DZone
  • HackerNews

Hello Brightcove!

November 3rd, 2009 by Brian 1 comment »

Monday was my first day in my new role as Prinicipal UI Engineer for Brightcove and I'm quite excited to begin this new chapter of not only my career, but my life as well.  Brightcove is headquartered in Cambridge, MA which means the first major physical relocation in over 20 years for me.  More importantly, it's the first time I'll be living outside of Atlanta as an adult.

There were may reasons I chose to accept this opportunity and uproot my life to come here. Most notably, I believe the word "opportunity" truly applies.  I spent a good portion of my half-day interview in Cambridge in early October talking about where I want my career to go; and not just anecdotally via the typical "Where do you see yourself in 5 years?" interview question.  We talked about how my desired path can fit into the Brightcove structure and culture and we talked about how to leverage my current skill sets to make those transitions possible. While I grew tremendously in my time at ATC, I believe I'll grow much more, and much more quickly, and Brightcove.

I also saw the opportunity to come to a company that sits on the leading edge of technology on the web; and a company where initiative would be embraced from engineers rather than stifled.  And the company showed tremendous faith in me throughout the whole Interview and Negotiation process.

The fact that they use the Scrum methodology certainly didn't hurt things either.  Oh, and they have some of the world's best Flex developers for me to learn from as well.  :)

All of these things, and the general feeling of excitement I had when I walked out of that interview, made it a very easy decision for me to pack up and move to New England.  When I arrived for my first day, I found that people know who I am, are happy I'm there, and are ready to look to me for leadership in the UI Engineering discipline.

I look forward to this adventure!

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter
  • DZone
  • HackerNews

Goodbye ATC

October 23rd, 2009 by Brian 2 comments »

Today is my last day at AutoTrader.com.  I've been here just shy of two years and it's been a fantastic experience. I've learned, grown, and met some wonderful people with whom I hope to remain friends for years.  At ATC, I was able to truly able to embrace the discipline of UI Engineering and learn so much from so many people that I'm ready to take that next step.

The first year was simply the best work experience I've had. I met people who twisted my mind in ways it'd never been twisted before. I learned about enterprise software architecture and the unique challenges faced in that type of environment as opposed to client work. I attended my first major web conference in nearly 10 years, and, of course, I made some fantastic friends along the way. I participated as a lead engineer in one of the greatest feats of enterprise web engineering ever accomplished; one that won't be talked about in engineering circles, but if you were there, you knew what we accomplished was truly incredible.

Over time, I came to the realization that despite my and others' efforts, the company would never shed it's very conservative nature.  And frankly, it's hard to argue that potentially putting off many millions of unique visitors a month by becoming more "cutting edge" is a great idea when revenues are at stake. But the inescapable fact, as famously explained by one of the executives, is that "AutoTrader.com is an advertising company," not an engineering company. As such, after a time, an engineer is going to begin to feel somewhat "stifled" in that environment. Once I began to feel as if it were sapping my motivation, I knew it was time to move on.

All that said, I did not look for a new opportunity; one fell into my lap at the right time and I've chosen to seize it.  I'll write about my new company in a separate post; and I'm very exciting about the whirlwind of change it means for my life!

Goodbye AutoTrader.com and the wonderful people I've met there along the way; you will very sincerely be missed.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter
  • DZone
  • HackerNews

How Self-Executing Anonymous Functions Work

September 24th, 2009 by Brian 3 comments »

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

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter
  • DZone
  • HackerNews

Create a Basic jQueryUI Carousel Widget

September 17th, 2009 by Brian No comments »

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

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter
  • DZone
  • HackerNews

Collected (abridged) thoughts on #jqcon

September 14th, 2009 by Brian No comments »

I spent September 11-14 in Boston for jQuery Conference 2009.  For $150, this conference was probably the best value I've seen in a conference.  Packed with great speakers on great topics, it was more than I was expecting.

I spent most of my time tweeting the event using the #jQCon tag, but I wanted to collect some thought here in a slightly more robust way than I could using Twitter.  Here it goes:

  • jQuery 1.3.3 looks really sick; John and the whole core team have done some fantastic work.  I really appreciate that these guys are really committed to making jQuery competitive in the running for "fastest" JS library.  A 3.5x speed increase overall in 1.3.3 is nothing to sneeze at.  I can't wait for the release!
  • There are a lot more implications selectors being parsed right-to-left in jQuery than you might imagine.  As always, specificity plays a big role; but not necessarily in intuitive ways.  I'll probably write a more full post on this topic as my mind really got swirling around this one.
  • People are totally stoked about jQueryUI and jQueryUI Labs.  That's a good thing as I see absolutely huge potential for jQueryUI and I've been developing some widgets that I plan to release on github relatively soon.
  • The guys from JavascriptMVC are interesting characters.  And they get huge props for handling an attendee asking them to "fast forward" their presentation in a humorous way.
  • ARIA is fantastic technology that people should really, really be looking into.  An interesting project would be to make all jQueryUI widgets ARIA-compliant.
  • People who use and preach jQuery love Event Delegation.  I was in really good company with these guys and I was happy to see it getting so much press.  jQuery's $.live() handles delegation for you which is just slick.
  • TestSwarm, as I anticipated, is going to rock. Javascript testing got a lot of press too and I'm really stoked that it did.  I was a little disappointed that there wasn't much coverage of testing frameworks (not even qunit)
  • Steve Souders is even more passionate about front-end performance than I expected him to be.  Also, big ups for doing his presentation on less sleep than I had the night before.
  • There's a lot of talk about how to organize your code with jQuery.  It seems that the fact that jQuery doesn't enforce some type of structure is both a blessing and a curse.  I've often said that for ATC, a big barrier has been that prototype's class functionality gives us something that we haven't been able to replace in jQuery.  The good news is that a lot of people are thinking about it and there are some great solutions out there.

I also have some thoughts about the social aspects of the conference

  • The question I was asked most:  "how about the ratio?"  It had to be at least 25:1; but it could have been 30:1
  • There's an iPhone version of the drinking game "Circle of Death" out there.  That made for every bit as much fun as you might imagine.
  • After enough adult beverages, John Resig's "smooth-jazz" voice does lighten a bit. :)
  • It was great to find so many people there who were truly social.  I was expecting to have a harder time getting people to open up--but there were others there that shared my mindset.
  • Off the top of my head (and if you're not on the list, it's because I simply didn't think about it very long or we only talked briefly) it was great to meet and spend time with @bobholt, @jeresig, @voodootikigod, @rmurphey, @snookca, @bitofgrace, @bpartridge, @binary42, @Cowboy, @defunkt, @dainbrain
  • I still wish I'd met even more.

Great time; more to come from me on the conference.  But that's an early round-up!

For those that weren't there, @bobholt set up a site to aggregate the slides.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter
  • DZone
  • HackerNews

Quick Javascript Tip: Pass an Options Hash

July 13th, 2009 by Brian No comments »

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.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter
  • DZone
  • HackerNews

More on Keeping Track of Focus

July 10th, 2009 by Brian No comments »

A bit over a year ago, I wrote a post on Keeping Track of Focus using Javascript.  Unfortunately, the code is severely flawed (though I haven't yet figured out why it continues to work where I implemented it--but that's a question for another day).

PPK points out that unlike most javascript events, focus does not bubble. He also offers a solution which uses event capturing to get around the problem.  I've taken that solution and modified it for use with Prototype.js as the original version was created that way.

var FocusReader = Class.create({

    initialize: function(){
	this.currentFocus = null;
        var focusRead = this.focusRead.bindAsEventListener(this);
        document.addEventListener("focus", focusRead, true);
        /* Also add the listener for IE which does not
            support capturing */
        document.onfocusin = focusRead;
    },

    focusRead: function(e){
        /* Need to force extending the event since
            it won't be extended by default */
        e = Event.extend(e);
        this.currentFocus = e.element();
    },

    getCurrentFocus: function(){
        return this.currentFocus;
    },

    getCurrentFocusId: function(){
	if(this.currentFocus.identify) return this.currentFocus.identify();
    }

});
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter
  • DZone
  • HackerNews

Easing Equations in Scripty2

June 26th, 2009 by Brian No comments »

Just a quick note here today--for those who aren't aware, Robert Penner's easing equations, which I ported to script.aculo.us several months ago have been merged into scripty2.  They exist in the s2.fx.transitions package and are available for use directly from the library.

I'm pleased to have contributed code to such a great project as scripty2.  Thanks to Thomas for including my work!  Head on over to the official scripty2 site and download the alpha or even just take a look at the demos.  He's got some great stuff going on in this release.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter
  • DZone
  • HackerNews

Hiring Top Talent: It’s the Process

June 2nd, 2009 by Brian 2 comments »

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.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter
  • DZone
  • HackerNews