API Developer Interview: Jonathan Isabelle of Jack of Cars

Over a month ago, the Edmunds API was released. Today, we have 100+ developers on the platform who have made in excess of 1 million API calls. One of those awesome developers is Jonathan Isabelle of Jack of Cars. Here's our interview with Jonathan:

Hi Jonathan, could you please tell us your full name and what you do?

My name is Jonathan Isabelle. I have been a programmer since the early 80's--yes, I learned to code on the TRS-80 :P--and have been loving it as a creative outlet ever since. Most recently I work as a Software Architect for desktop software and develop phone apps in the wee hours of the night.

What is Jack of Cars?

Jack of Cars is an app for Windows Phone 7 that leverages the Edmunds API to allow users to look up car details, prices, pictures, and dealers.

Why did you build it?

There have been so many times where I stop to look at a car on the side of the road or at a dealer and just want to quickly look up and find out the engine size, the cost, and the private party or retail value. I've had friends call me from the road to look up similar information on line.

How many people use your site on average?

Jack of Cars released only 8 days ago but has had been used over 3,000 times.

How did you hear about the Edmunds API?

I heard about the Edmunds API in Mashery's "New APIs" notification and immediately got excited.

What do you think of it so far?

The API is amazingly detailed and has many different ways of drilling down into the data. I use the Vehicle API and the Dealer API. Most interfaces are flexible allowing a minimum amount of required data and multiple optional parameters. The docs are very good and consistent providing formats as well as example requests and results.

What would you like to see on the Edmunds API portal?

Some results include detailed lists like options but don't have user-friendly names. Although these generally have easy to use links to get further detail, if one were follow all these links to fill a list for the user to choose from, you might be making 5 or more API calls. Including a user friendly name in the brief lists would allow the application developer to build a list from a single request and then only drill down into the data the user selects.

How easy was it to find the data you're looking?

I had no difficulty locating services to fulfill all my app's needs.

How easy was it to implement it?

Building the URIs to make the calls is very straightforward and readable. Since the data comes back in JSON, it's easy to try a call and peruse the results to get an idea of what to expect. The only thing that was tedious for me was building the JSON description for my JSON deserializer. Still, it was a small effort for access to so much data.

How many 3rd-party APIs do you used in Jack of Cars?

I am currently using three 3rd-party APIs. Obviously, I use Edmunds Vehicle API to look up car details, photos, and values. I use Edmunds Dealer API to find dealers. I use Telerik's RAD Controls for Windows Phone for interpage transitions and busy indicators.

What other Edmunds datasets are you interested in using in the future?

At first, I misunderstood the Inventory API and thought it could return details on a particular car like links to its history. I think this would be a good bridge between applications built on the Edmunds API and the Edmunds site itself. I'm not sure if that data is available.


* To find out more about Jack of Cars or contact the developer, please visit us on Facebook.

API Developer Interview: Eric Sanders of findacar.us

A month ago, the Edmunds API was released. Today, we have over 100 developers on the platform who have made in excess of 500,000 API calls. One of those awesome developers is Eric Sanders of FindACar.us. We have interviewed Eric earlier in the week. Here's how that interview went:

Hi Eric, could you please tell us your full name and what you do?

My name is Eric Sanders and I am a Manager of Software Engineering at HomeFinder.com. I have been a Software Engineer since 2007 and have been a manager since 2010.

What is findacar.us?

findacar.us is a hobby site of mine, so it is 100% a work in progress, that I work on during my morning train commute. The goal is to make it a viable source for people to find information about vehicles and car dealerships.


Why did you build it?

I built findacar.us as a way to pass the time while making use of two 35 minute train rides per day. As a Software Engineer I use the site as a way to learn and use new technologies. It is the first project that I have built in the cloud as well as my first project using nginx. I also went into this hobby wanting to learn more about SEO. I have learned many aspects of SEO while experiencing significant highs and lows in the eyes of Google.

How many people use your site on average?

My site is only 13 months old at the moment and it only started getting any meaningful traffic starting in March. Since then I saw the month of June with just under 42K visitors while over the last four months I have averaged just under 20K visitors. Since I only have seven months of valuable data I am curious to see what the seasonality trends are for vehicle searches are. It will also be nice to see what my year over year numbers are to see if the site has improved or not.

How did you hear about the Edmunds API?

I heard about the Edmunds API via the September 22nd Mashery API Network notification email.

What do you think of it so far?

The API is blazingly fast. I am currently using two services and, according to Mashery, the average latency is around 88ms for the calls that I am making. I will say that the API is somewhat overwhelming. The documentation is great, however, there are a lot of endpoints to keep in mind. My biggest problem right now is deciding what it is that I want to build with the data available to me. To be honest, I find it too good to be true that all of this information is so readily available.

What would you like to see on the Edmunds API portal?

I would like to see a list of all possible attributes. I can see through calls that I may get back 20 attributes which have very different ids. I've seen these values range from 1 though 586. It is going to be hard to do any meaningful data mappings when there are so many attribute types and each call only returns a few handfuls of ids.

How easy was it to find the data you're looking?

Again, the documentation was very thorough so it was very easy to find the data I was looking for.

How easy was it to implement it?

This is where things get a little tricky. I'm finding it tedious/inefficient having to make several calls, sometimes tens of calls, to get the full details of a vehicle by make/model/year. For instance, if I do a search by make/model/year I will get back useful information for that vehicle, however, I also get an array of "links" within the equipment object. In one case I have 57 "links" that I would have to make API calls for which doesn't make a whole lot of sense. I'm guessing this is done to reduce the amount of data returned, but it is painful.

The only other piece that makes it somewhat difficult to implement is the value of the name member variables. Although "MANUFACTURER_OPTION_NAME" is meaningful it is not user friendly. It would be helpful if a user friendly version was also available. It wouldn't be too hard for me to create a mapping for these values if all possible values were made available in documentation.

How many 3rd-party APIs do you used on findacar.us?

I am currently using four 3rd-party APIs. I'm using Oodle for primary vehicle search, CityGrid for Dealership searches, the YouTube API for the vehicle details page, and most recently the Edmunds API for vehicle images on the vehicle details page.

What other Edmunds datasets are you interested in using in the future?

I can't really answer that as I don't know what other datasets are even possible. I'm sure I'll have more to say about this in the future as I build out more features for findacar.us.


* I would like to point out that I have only had to invest around $50 total for this site. All of the data that I use is freely available and I am also running this on the free micro-instance tier on AWS. I used Feedback Roulette (http://feedbackroulette.com/sites/view/27) to get some user interface feedback. If anyone has any comments/suggestions they can leave comments at http://www.facebook.com/pages/Find-a-Car/167050096657805.

To Developers Everywhere: The Edmunds API is Here!

The Open Platform team at Edmunds is excited to announce the immediate availability of the Edmunds Developer Network, which offers access to the Edmunds portal. The portal offers vehicle specification and pricing for over 36,00 different trims of over 6,000 vehicle models from 1990 onward. It also offers dealer information and a VIN decoder capability with more data points to be made available in the next weeks and months.

All of this data is offered to developers through an Application Programming Interface, or API, hosted by the leading provider of API management services, Mashery.com. After a 4-months due diligence process, we select Mashery as our Open API provider for its leadership in the API space and its extensive developer outreach program amongst other things.

Developers can now access the Edmunds data by simply registering an account with the portal and then apply for an API Key. That's all that's needed to get started!

In the next few weeks, an API Console will be available to give developers an opportunity to explore the data quickly and effortlessly. We're also working on exposing our editorial, reviews and ratings data in the coming months. If you want us to expose a particular dataset that we haven't mentioned, please feel free to tweet me @ielshareef, leave a comment here or in the forums.

In preparation for this release, we have compiled a list of tools and sample codes to help developers get started:

• JavaScript SDK (github): A simple JavaScript wrapper for the Edmunds API


• Edmunds Buddy Chrome Extension (crx | github): A Chrome extension that scans the page you're on and provides you the Edmunds True Market Value pricing for all vehicle mentioned on the page if any


• TMV Widget (github): A simple True Market Value pricing widget that can be dropped on any page, including web mobile apps


• Ask Edmunds (github): An innovative demo app that uses the Edmunds API with a speech recognition API

If you build a great application with the Edmunds API, we will feature it on this blog and on the portal. So have at it :)

The Edmunds Developer Network is in its early stages and will always be a work in progress. Our goal is to empower the developer community to create impressive, innovative and meaningful automotive-related experiences with our data. We are committed to that goal. We will work closely with our friends at Mashery and with the community at large to address any issues that stand in the way.

Let's create something awesome!

The Business Case for HTML5

There is plenty of talks and presentations on the technical aspects of HTML5 but not a whole lot on the business benefits of HTML5. This presentation helps identify some of those benefits:

The Business Case for HTML5

View more presentations from Ismail Elshareef

Hack Days Videos: Vehicle Image Classification

Bennett Neale, Director of Software Engineering, discusses his team's attempt to create a system that automatically recognizes a vehicle image when it's fed to it. He goes on to discuss basic concepts of image processing and machine learning.

The project didn't have a working demo, but the process of what the team tried to accomplish is explained in the video.

Hack Days Videos: Cloud-Based Logging

Carlos Macasaet, Sr. Software Engineer, talks about using the cloud and MongoDB to process log files for speed. The idea was born out of current frustration with a product we use internally that is slow and has its limitations.

The demo shows how fast it is to run complex queries on our Apache log files after we load them into a MongoDB server sitting on an Amazon EC2 instance. Carols shows how this helps get fast reports on possible issues affecting the site.

Hack Days Videos: Vehicle Image Classification

Bennett Neale, Director of Software Engineering, discusses his team's attempt to create a system that automatically recognizes a vehicle image when it's fed to it. He goes on to discuss basic concepts of image processing and machine learning.

The project didn't have a working demo, but the process of what the team tried to accomplish is explained in the video.

Hack Days Videos: Cloud-Based Logging

Carlos Macasaet, Sr. Software Engineer, talks about using the cloud and MongoDB to process log files for speed. The idea was born out of current frustration with a product we use internally that is slow and has its limitations.

The demo shows how fast it is to run complex queries on our Apache log files after we load them into a MongoDB server sitting on an Amazon EC2 instance. Carols shows how this helps get fast reports on possible issues affecting the site.

Hack Days Videos: "You Auto Know" and "The Changing Vroom" Ideas

Many great ideas came out of our second Hack Days event. The videos below are of two of those cool ideas and they were created by the same team. How awesome is that?!

None of this particular team members was a developer, so they improvised and created a detailed Keynote prototype that clearly demonstrated what their ideas were about.

The first idea was called, "You Auto Know," which was designed for our Josh persona (professionals that are tech-savvy.) It's an iPhone app that presents interesting and unusual facts about cars to entertain Josh when he's on the go!

The second idea created by the team was called, "The Changing Vroom," for our Becca persona. The idea is about a product that allows Becca to see how she looks like in a car to help her make the right decision for her before making a purchase.

More videos from Hack Days will follow. Stay tuned.

Hack Days Videos: "You Auto Know" and "The Changing Vroom" Ideas

Many great ideas came out of our second Hack Days event. The videos below are of two of those cool ideas and they were created by the same team. How awesome is that?!

None of this particular team members was a developer, so they improvised and created a detailed Keynote prototype that clearly demonstrated what their ideas were about.

The first idea was called, "You Auto Know," which was designed for our Josh persona (professionals that are tech-savvy.) It's an iPhone app that presents interesting and unusual facts about cars to entertain Josh when he's on the go!

The second idea created by the team was called, "The Changing Vroom," for our Becca persona. The idea is about a product that allows Becca to see how she looks like in a car to help her make the right decision for her before making a purchase.

More videos from Hack Days will follow. Stay tuned.

Hack Days: Innovation Rejoiced at Edmunds!

Last week, Edmunds.com held another successful "Hack Days at Edmunds" event that promotes innovation by allowing employees to work on cool and fun projects they are excited about. The number of participants doubled from the eighteen that participated in the inaugural event back in May 2010 to thirty five this time around. The projects were diverse and very creative. They ranged from an iPad game that tests the user's car IQ to a blazing fast bulk loading of our content to the production environments.

The teams definitely delivered and that's with just a day and a half to get their ideas from abstract concept to demonstrable prototype.

Seth Berkowitz, COO at Edmunds.com, gave the kick-off keynote on Wednesday, April 6th, and David McPherson, VP of Product and Marketing at Gifts.com, gave the closing keynote on Friday, April 8th.

Photos from the event are posted on our Facebook Page:

Santa Monica Java Users Group is Meeting at Edmunds on March 24 @ 7 PM

Edmunds will be hosting the March 24 meeting of the Santa Monica Java Users Group.

We'll meet on Thursday, March 24, from 7 - 9 PM.

Here are the directions to our facility: http://www.edmunds.com/about/jobs/map.html

The format of the meeting will be Lightening Talks: An Evening of 8 Short Presentations on Java Related Technologies by Coders for Coders.

Here is the Meet Up Page the describes the event.

http://www.meetup.com/SM-JUG/

You can RSVP on that page.

We'll be meeting in the Great Room. Food will be provided.

Here are some photos of the Great Room, with food!

Using Google's js-test-driver and Maven

Using Google's js-test-driver and Maven

Here at Edmunds we've been looking into adopting TDD and continuous integration practices for javascript development for some time.  We've written tests in YUI test, but since we never automated them, they quickly became outdated, as any tests that are not automated will. 

We already attempt to follow TDD and continious integration best practices for our java development, but haven't really had good tools to do the same thing with javascript.  There are a number of javascript testing frameworks, such as YUITest, JSUnit, etc, that do a good job at allowing you to test your code via assertions in multiple browsers, etc.  However they usually don't integrate that well with Maven (which we use) and can be a bit cumbersome to automate. Google's js-test-driver allows us to easily integrate with our existing continious automation processes (hudson, etc) which make it such an attractive option.

After experimenting with  Js-test-driver for a day , it seems to have thought of almost everything to facilitate for TDD and continuous build practices.  I am not going to get into the specifics of TDD with javascript or attempt to outline all the features js-test-driver has, but I'll attempt to show you how to do 2 things in this post that took me a little bit to sort out:

1. How to automate your tests using the js-test-driver Maven plugin and the latest js-test-driver core.


2. Setup a slave js-test-driver server that uses both Safari and Firefox to run your tests against.

I assume you already know some java basics, how to use Maven and understand the concepts of using js-test-driver.  If you don't you should read up on these before continuing.  Another thing to note is that I did all this on my Mac, so there may be some corner cases if you run on Windows or another OS :) 

Required Artifacts:

Listed out below are the required artifacts you'll need to work through this post.

• Java 5 SDK or greater (http://www.java.com/en/download/index.jsp)


• Maven 2.0.9 (http://archive.apache.org/dist/maven/binaries/)


• Subversion (required to check out plugin from google-code)


• jstd-maven-plugin-read-only-1.2.2-SNAPSHOT (I'll show you how to download and build locally)


• hello-world.zip (maven project we'll use for example, this includes the latest JsTestDriver-1.3.0.jar).  This is the "Getting Started" app that is in the js-test-driver docs.

Building the js-test-driver Maven Plugin

Before you actually build the plugin locally you need to download the source files by running this command below:

svn checkout http://jstd-maven-plugin.googlecode.com/svn/trunk/ jstd-maven-plugin-read-only

Once you've got the plugin sources downloaded to your local machine you'll need to update the js-unit-test-driver dependency from 1.2.2 to 1.3.0. To upgrade the dependency, modify the Maven pom.xml file located at: "jstd-maven-plugin-read-only/pom.xml". I couldn't get the drivers to work without the upgrade. See snippet below:

....

 <dependency>

     <groupId>com.google.jstestdriver</groupId>

     <artifactId>jstestdriver</artifactId>

     <version>1.3.0</version> 

</dependency>

....

Next you need to install the updated JsTestDriver.jar included in the hello-world.zip to your local maven repository.  Go to the root directory of "hello-world/" and run this command:

mvn install:install-file -Dfile=JsTestDriver.jar -DgroupId=com.google.jstestdriver 
-DartifactId=jstestdriver -Dversion=1.3.0 -Dpackaging=jar

Once you've installed the latest version of js-test-driver you should be ready to install the plugin to you local maven repository, using the command:

mvn install

At this point you should have the js-test-driver maven plugin installed which uses version 1.3.0 of js-test-driver.   To verify that all this worked run this command:

mvn dependency:list | grep "com.google.jstestdriver:jstestdriver"

You should see this output below.

[INFO]    com.google.jstestdriver:jstestdriver:jar:1.3.0:test

If you don't then the plugin you built and installed locally didn't work as expected (post a comment and I'll get back to you).

Now we'll move on to the next step which is actually starting up the slave js-test-driver server...

Starting up a slave server

A slave server is the server that the tests will actually be run on. For demonstration purposes, I am going to show you how to do this on the same machine that is running the maven build. Once you are comfortable running this locally, a more realistic setup this would involve a couple of slave servers running various versions of windows, osx, linux, etc. By running multiple operating systems and browser combinations you will be able to really test out a wide range behaviors to ensure you haven't made any cross platform errors. To allow jsTestDriver to use the browsers on the slave server you need to run jsTestDriver and tell it what browsers you want to test with, then you need to start each browser and "capture" the browser window to make it available to jsTestDriver.

Starting the jsTestDriver appliction

To start up jsTestDriver you need to go to the "hello-world/" root directory and run the command below. Notice that the command specifies two browsers after the -browser argument. Since I am running everything on my mac laptop, I am going to test with both Firefox and Safari.

java -jar JsTestDriver.jar --config src/test/resources/server-jsTestDriver.conf 
--port 9876 --runnerMode INFO 
--browser /Applications/Firefox.app/Contents/MacOS/firefox-bin,
/Applications/Safari.app/Contents/MacOS/Safari

Capturing Browsers

Next you need to "capture" the browser windows for the tests to be able to run.  To do this open up both Safari and Firefox (assuming you are using these same browsers) and go to "http://localhost:9876", in each browser.  You should see a "Capture this browser" link.  Click on this link.  The browsers should now be in a "captured" state, so that the tests can run against them. See the screen shots below of how the browser should look in Firefox: 

Browser not yet captured. Notice link to capture browser below:

Browser in captured state below:

Once a browser is captured you shouldn't have to re-open the browsers if you restart the slave servers, as js-test-driver will auto detect them. The browsers stay in a listenting state. That said I have seen issues with the way Safari keeps the captured browser open (you may notice how the progress bar doesn't ever actually finish loading) and will sometimes not re-register itself correctly with the slave server. Meaning that js-test-drive will think it has the browser captured when it actually doesn't. You'll know this is the case if when you run your tests you don't see them run against Safari, just Firefox. In this case it's best to just restart the slave server and browsers, and re-capture them.

Now we'll move on to actually running the tests via the maven plugin using the slave server we just configured.

Running the tests using Maven

To run the tests using Maven all you should have to do (assuming all the steps you did above are correct) is run this command below from the "helloworld/" root directory.

mvn -Pjstests test

The command above tells maven to use the profile jstests.  You should now see output similar to this below. Notice the log output indicates that the tests ran in both Safari and Firefox.

INFO: Running com.google.jstestdriver.browser.BrowserActionExecutorAction@3da1c42f
Firefox: Runner reset.
Safari: Runner reset.
Firefox 3.6 Mac OS loaded /test/main/webapp/js/Greeter.js
Firefox 3.6 Mac OS loaded /test/test/webapp/js/GreeterTest.js
Safari 533.19.4 Mac OS loaded /test/main/webapp/js/Greeter.js
Safari 533.19.4 Mac OS loaded /test/test/webapp/js/GreeterTest.js
Safari 533.19.4 Mac OS [PASSED] GreeterTest.testGreet
[LOG] JsTestDriver Hello World!
[LOG] Hello Browser!
Firefox 3.6 Mac OS [PASSED] GreeterTest.testGreet
[LOG] JsTestDriver Hello World!
[LOG] Hello Browser!
Total 2 tests (Passed: 2; Fails: 0; Errors: 0) (2.00 ms)
Safari 533.19.4 Mac OS: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (2.00 ms)
Firefox 3.6 Mac OS: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (0.00 ms)

Conclusion

Hopefully at this point all this worked for you as it did for me and you can begin to see how one could adopt practices such as TDD and continuous integration, traditionally used in the Java world when developing javascript applications. 

All About Design Thinking, All of the Time

Compared to many major online publishers Edmunds is small in terms of employee count. We're about 400 strong.

One of the many advantages of being small is that when the time comes, we can turn on a dime. And we have. We're moving in a new direction in which Design Thinking is becoming core to the way we do business.

Over the last 6 months we've been all about Design Thinking, all of the time! We've established a group of researchers that go out into the field to find out as much as we can about the people that use Edmunds.com and how they use Edmunds.com.

We're reaching out and we're reaching in. The company has organized Challenge Teams. Each team has a particular focus on improving how Edmunds experience for its users, both external and internal. Now, before we put our nose to the grindstone to make something, we talk to the user first. It's becoming more common to go past a conference room and see a group of Edmunds employees in a video conference call with an end user on the other end of the conversation. Or, if we're developing an internal tool, the development team will run a paper prototype past the internal group requesting the work.

The month of January has been an exciting month. All the employees went through formal training sessions to learn the particulars of Design Thinking. Also, all of the Edmunds Challenges Teams had to walk the talk. We ran a month long exercise in which each Challenge Team had to use the Design Thinking process to create a product or service.

The culmination of these creative efforts was a company wide Design Thinking Trade Show. Each Challenge Team presented its product/service in our company's common room following a trade show format. (We call the common room, The Great Room.)

Each Challenge Team set up a booth. Employee walked from booth to booth to get sold on the Challenge Teams idea. And, as an added kicker, each both had a "vote sheet" upon which a wandering employee graded the booth, as Best Booth, Second Best, Third Best. At the end of the Trade Show a winner was determined by a tally of the votes given.

We shot video and photos of the event. Below we've posted the photos of some of the Challenge Teams at their booths with a brief description of the idea they developed. Enjoy!

Not to git

Back in October, I wrote a post "To Git or Not To Git." At the time, one of our teams started to work with distributed revision control (drcs). The team looked at both Git and Mercurial. At the end of the day they decided to test using drcs with Mercurial. I tried to stay out of the decision as, on the face of it, both systems offer the same basic feature set. After a few months we took a look at our usage to decide if we should move forward or not.

First a little background, we chose to test the use of drcs with a brand new project to ensure we did not have to worry about existing source structures in perforce. The new project is the rewrite of our data warehouse ETL system using Hadoop. The code part of the project breaks down into data loaders, data transform workflows, and data exporters for each subject area (ads, clickstream, etc.) as well as common components shared across subject areas. The configuration part breaks down into puppet configurations and mcollective deployment agents for pushing our code. For the beginning of the project we focused on a single subject area. Besides keeping the test project limited in scope, we wanted to ensure we could fail easily. The ability for both git and mercurial to sync back to perforce meant that regardless of the outcome we had a fall back scenario that ensured we could fail without too much consequence.

We liked a number of things we found when using drcs; performance was great, developers could commit code from home or elsewhere without network access, developers could make changes safely and easily isolate their changes from others. We liked the ability to have a robust model for creating authoritative repositories and the ease at which we could merge feature type branches. In short drcs had a lot going for it.

However, there were a number of things we did not like. The ability to commit changes offline is nice, however, unless you push the changes to a central server for others to see your commit is, in a sense, incomplete. Watching our central hg server, I do not see a lot of people pushing changes up on a regular basis. Knowing that people are not pushing up makes me wonder if they are pulling on a regular basis. Granted, not pulling, or syncing, is an issue with any rcs, however drcs adds the further requirement to not only commit but push your commits up. It also gives you the ability to choose where you pull changes from. If you don't have to push and can pull from anywhere how do you maintain a sane stable continuous integration environment?

As we move our organization towards continuous delivery the fact that there are numerous branches of code and an unknown integration state seems to be problematic. I would rather have everyone checking into a common trunk with no branches to ensure we are always in an integrated state. While the drcs tools provide great merge tools, textual merges do not always result in semantically correct code. Fundamentally, I do not think that having feature branches allows us to get to the continuous delivery model we are pushing towards (flame here ;-).

Additionally, in order to have clean push, pull, branch semantics one does not want to have a single monolithic repository. The question then becomes what is the appropriate granularity for a repository? We decided that a repository granularity was dependent on a deployable unit of code. However, this lead us to have seven repositories for our small project. With repository explosion I wonder how a new developer to the team would even know where to start. There are additions to both hg and git to allow rudimentary project grouping, however, compared to our perforce implementation we would not be able to create the nice logical source tree we have now.

I do not believe any of the above issues are insurmountable, however, given the issues, we became uncertain if the cost was worth the benefits. For now, we are staying on perforce. However, given the power of the git and hg integration with p4 we have a number of developers that are sticking with the tools that work best for them. At the end of the day developer productivity is what is more important to me and it seems, as far as scm is concerned, we are in a good place.

Google Tech Talk: How Edmunds Got in The Fast Lane

Last week, I had the pleasure to speak to a room full of smart people about the exciting practices we have employed here at Edmunds to make our pages faster. I wrote about these practices earlier and co-authored a blog post on the Google Code blog about it as well.

Here's the deck I presented:

The 5 Rules of 3rd-Party Widget Development

As web developers, we incessantly complain about other people's code that we embed (out of necessity sometimes) on our pages.  Most of the time, our complaints are justified since the vast majority of 3rd-party providers develop their widgets and code in a way that negatively impacts the performance and functional integrity of the host page.

Now that we're embarking on becoming 3rd-party providers ourselves, we want to make sure we avoid all the traps that others have fallen into and that we've complained about endlessly.  Here is a list of the 5 rules that I think could make 3rd-party code a pleasure to work with:

1. USE STANDARD WEB TECHNOLOGY: Completely avoid plugins, including Flash, when building out widgets. Almost everything you can do in Flash is doable using HTML 5.
   
   


2. DO NOT IMPACT PERFORMANCE: One of the main complaints we developers have about most 3rd-party widgets is that they invariably bring our page performance down.  With page performance being part of the overall credibility of sites these days, it's very important that the widgets you create are not impacting performance at all.  This is done by:




1. Using non-blocking methods to download resources


2. Making as little HTTP requests as possible


3. Executing code when needed


4. Cache resources that don't change often
   
   




3. DO NOT USE document.write(): If you do not want to piss off the developer that is working with your code, don't use document.write().  The problem with document.write() is that it needs to be executed before the page is done loading, which doesn't give the developer much choice of when and how to include the widget.  Avoid it at all cost!


4. DO NOT DEPEND ON DOM EVENTS: Depending on onLoad or onDOMReady or any other time event on the page is a bad idea.  You're forcing the developer to add your widget before these events are fired, which might impact the performance of the page he or she is developing. 
   
   


5. PROVIDE AN API FOR YOUR WIDGET: The power of the Application Programming Interface (API) is that it gives the end developer control of when, where and how to incorporate your widget on his/her page.  The goal here is to be as unobtrusive as possible and with an API you can make that happen.  Developers will love you for it!

What do you guys think?  Does this make sense?  Did I miss anything?  It would be great to develop a test through which every 3rd-party widget goes to make sure it plays well with other components on a page.

Looking forward to your feedback.

Software Development by Any Other Name

I figured out something. I figured out how to learn everything that you need to know about the best practices in software development in 3 days. It's called the Edmunds All Company Meeting.

Allow me to elaborate.

The Edmunds All Company Meeting is the semiannual gathering of all 400+ Edmunds employees. We gather together in the Summer and in the Winter to get the latest information from the CEO, COO and President about the past performance, present state and future direction of the Company.

The 2010 Summer and Winter Meetings, of which I was the producer, were held at the Broad Stage nearby in Santa Monica. The Broad Stage is a very professional venue capable of hosting anything from a traveling Broadway production to any corporate event.

The Meeting is a big deal...a big expensive deal that involves the efforts of many people. We had designers working with the executives creating the Keynote presentations. We commissioned a production company to make a complex graphical video, the Edmunds Way. (The video outlines the future philosophy and direction of the company.) We added extra musicians to support the employee-musicians of the Edmunds Orchestra that plays throughout the meeting. Edmunds employees served as stage hands and production staff.

All members of the meeting, production staff and executives, spent weeks in preparation for the event. The culmination of the preparation was a night spent in the studio in Orchestra Rehearsal and a full day spent in the theater in what we call, "Dress Rehearsal", and then the Day of the Meeting. For all intents and purposes, the All Company Meeting is a fully fledged theatrical production. In terms of a full staffed production, we had 3 days to prepare and perform.

So you may ask, what does any of this have to do with software development?

Software development and theatrical production have a lot of things in common. You get an idea in your head about an experience that you want to create. You spend time, money and lots of people-hours working to make the idea real. Then, after all the money is spent and the preparation work is done, you put what you've done in front of an audience. If the audience likes what you've done, you continue, it not..... well, the show closes.

It's all about curtain time/ship date. All the time invested, money spent, hours worked does not mean squat if the show does not go on. In fact, if the show does not go on, if the software does not ship, the entire effort is one big, expensive waste.

So again, what does all this have to do with software development?

Effective software development teams tend to look like high functioning theatrical productions. The term "they've been bitten by the bug" is applicable to both groups. Individual motivation is high. All participants have a clear, common idea of the production process, what the final product looks like and all understand each individual's role in the production overall. Most times awareness of the production is so pronounced that members can function in many roles and can "fill in" for others should the need arise.

Mitigating Risk: Understudies and Backup

On the practical end, mitigating risk is a continuous undertaking in both environments. Producers/managers are always asking, "What happens if Joe or Jane gets hit by a bus?" In the theater the major roles have understudies. In a well run software development team technological expertise is distributed. No one head holds mission critical knowledge.

No production is ever comprised because an important piece of equipment malfunctions. Nobody goes on stage at a Rolling Stones concert and says "Mick can't sing tonight because we blew the amps!" The Edmunds site does not go down because we lose a server. Just as there is always a back up amplifier, we have backup for all of our hardware dependencies.

For me the most telling aspect that a theatrical production is software development by any other name is the paramount importance of reliability-- that the investors and audience can rely upon the crew and cast to ensure that the show will go on...no matter what.

reliability = (showing up on time) + (being ready and able to do what is expected of you) + (letting others know what's going on with you)

Allow me to elaborate some more.

(showing up on time)
Keeping an entire production crew, theatrical or software, waiting for you to show up to do your job wastes time and costs money. Professionals show up on time, if not early.

(being ready and able to do what is expected of you)
Drunk talent in a dressing room sucks. A developer zoned out playing Mafia Wars sucks. 'nuff said.

(letting others know what's going on with you)
Leaving the theater during rehearsal to go to the bathroom without telling anybody that you are leaving means that the production crew gets to play, "Where's Jerry? He was here a minute ago. We need some lights adjusted."
 
Going offline during a critical deployment means the development team gets to play, "Where's Mary? Her code is not building. We need to tell her to make a change. It looks like she's on Instant Messaging. But she's not responding."

Neither of these games are fun.

Software Development by Any Other Name

It's been my long held belief that if you can be a reliable member of a theatrical production, no matter the role, large production or small, professional or amateur, there is a good chance that you'll make an excellent member of a software development team. Yeah, you have to know code and code related stuff to do software. But the core desired behaviors exist in both environments:

• being willing to contribute to a common vision


• showing up on time, being able to perform as expected


• being able to take and give direction


• not disappearing unexpectedly


• making a commitment that no matter what, the show must go on.

So as I learned in my 3 days producing the Edmunds All Company Meeting, "The show that does not go on, isn't" and "software that does not ship, ain't".