Coda: Awesome Looking New Dev Tool

Wow! Panic, the Mac development shop will the coolest shopping cart system ever just announced what looks like a tremendously useful web development tool called Coda.



Lots of great features, but I especially like the built-in terminal, and how it nicely bundles all of your files, access credentials and other assets into a collection for each site. Just as a purely organization aid, I love that concept. Anyhow, my download is almost done, I have to go play with it!

Screenshot:

Dave Coustan on Corporate Blogging at EarthLink

Jenerous.com has a good interview of Dave Coustan, former writer for HowStuffWorks.com and full-time blogger for EarthLink for the past 1 1/2 years.

This podcast's a good insight into "Corporate Blogging" at a company that serves over 5 million paying subscribers, with ~2,000 employees.

Dave's a great guy with a rare knack for effectively conveying techie concepts to humans.

With a few hundred employees, roughly 1% of world-wide web traffic going through one of the online destinations we serve, Internet Brands isn't the smallest fish in the pond, yet perhaps the "Biggest Internet Company the World's Never Heard of".

In certain ways it's "strategically neat" to stay below the radar. Yet it occasionally hurts us when it comes to "attracting developers". While not exactly a "corporate blog", ibbydev aims to bring an occasional geek-friendly glimpse into the stuff we do behind the scenes.

Wikitravel: Webby Award Nomination!

Congratulations to Evan, the Wikitravel.org community, and the Internet Brands Travel Team, for their Webby Award Nomination!

Recruiting: The Acronym Soup Phenomenon

Joel Spolsky has on many occasions mused about the challenges of attracting and retaining great developers. In my ever so irrelevant opinion, Joel's one of those few hiring managers who "get it". He's been in the coding trenches, and has a keen understanding of how developers think, and some strong strategies for attracting new talent.

In his "Sorting Resumes" article, Joel points out:

To top programmers, the most maddening thing about recruiters is their almost morbid fascination with keywords and buzzwords.

... and further explains:

The keywords section of a resume can’t be trusted much, anyway: every working programmer knows about these computer programs that filter resumes based on keywords, so they usually have a section of their resume containing every technology they have ever touched, solely to get through the filters.

Having endured the challenges of filling various developer positions in my team, I can most vividly relate to this problem, affectionately (less so these days) calling it the "Acronym Soup Phenomenon" (ASP).

Invariably, candidates feel the urge to fill their skills section with a slew of Acronyms, claiming in one fell swoop "Expert Knowledge of" areas ranging from front-end Document Authoring and User Interface Engineering, to Database Administration, Systems and Network Engineering.

While Great Developers with amazing breadth and depth of experience are out there, Joel's articles and empirical evidence teach us that odds are likely they didn't send you the pile of Acronym-ladden resumes you're looking at, assuming they even have an updated resume.

As an example, seeing "XML, XSLT, and XPath" in a candidate's Acronym Soup, I would look forward to discussing the potential merits or shortcomings of an XML Database with an XPath or XQuery API for storing and exposing syndicated XML content to applications ... Only to find them shying away from writing on the whiteboard a sample expression for a "foo" element child of a "bar" element.

AJAX is a hot acronym that shows-up in everyone's soup, and one would think most "AJAX developers" coming-in for a User Interface Engineer position would have by now read Jesse James Garrett's piece or acquired a little more knowledge and/or practical experience than copying script.aculo.us code samples.

When asking candidates about what they think AJAX is, 30% can indeed spell out what the acronym means, and one candidate so-far was able to give a slightly interesting description of the various technologies and schools of thoughts that make it up, while showing cursory knowledge of various DOM methods or the XmlHttpRequest object.

Some candidates might casually mention they "slipped" AJAX in the skills section because they're interested in learning it. That's how hot AJAX is.

As a result of the Acronym Soup Phenomenon, a resume with less buzzwords focusing on a specific discipline tied to the open position, is more likely to get attention.

When interviewing at any decent company, it's fair to expect candidates will be asked to demonstrate the appropriate level of expertise to their prospective colleagues.

Upon passing the screening process with a rich Acronym Soup, bring patience to the interview and we'll provide water, food and a sleeping bag: we'll want to know how thick it is. Not because we're sadists with nothing better to do, but rather because we run a lot of applications, both internally and customer-facing, serving a myriad of business needs on a wide variety of code bases: PHP on a LAMP stack, ASP .Net, Java/Servlet Container, Java/EJB Container, Spring+Hibernate, DWR. Breadth of experience with adequate depth won't go wasted.

And yes ... we "do" AJAX.

Reviewing Google Desktop for Mac

Google today just released Google Desktop for Mac.

TheAppleBlog.com has a good review of it.

QuickSilver and Spotlight users may wonder where Google Desktop fits-in, and from using all 3 apps, here are some guesses:

- Spotlight is a simple view into Mac OS X's real-time file-system-based indexing technology: Every time you save something on your Mac, Mac OS X detects this "event", and tells Spotlight to "index" or "re-index" the file in real-time. This is why it's possible to create a text file anywhere on your hard drive, type some text in it, save it ... and searching for that text in spotlight instantly reveals the file you just created. More importantly though, Spotlight will find just about any piece of information stored in just about any document on your hard drive, whether it lives in the file name, or in the file itself.

- QuickSilver leverages Spotlight to near-instantly keep track of installed Applications, but also various types of documents fitting certain categories. From here though, QuickSilver is far more about "Acting Without Thinking" than it is about merely "Finding Stuff":

In the end, Quicksilver has one very important effect: the effort of frequent tasks fades into the background and you are able to act without thinking. After an adaptation period, Quicksilver becomes an extension of yourself; the process fades away leaving only the results.

In this sense, QuickSilver and Spotlight are very complementary technologies.

- Google Desktop for Mac, however, appears to be reindexing the entire hard drive without so-much relying on the "live index" being kept by Spotlight. This isn't entirely surprising as Google may be leveraging custom indexing and searching algorithms to surface more relevant results than Spotlight otherwise would.

As a good neighbor though, the Google Desktop Preferences pane indicates that Google Desktop will obey all no-indexing privacy directives specified in Spotlight, which is a nice integration touch.

It will be interesting to see whether Google Desktop will pick-up "real-time" changes to the file system the same way Spotlight does.

Similarly to its Windows counterpart, it runs a web service that appears to solely bind to localhost on port 7468, which is reassuring. The last thing you want is for someone on your network to query your hard drive. Trying to connect to port 7468 to my LAN IP from another machine on the network did, as I was hoping, refuse the connection.

If it does deliver on speed and results relevance, Google Desktop might if anything be more of a "replacement" for using Spotlight for day-to-day file searches, while providing a more elegant integration framework of Mac OS X with the overall Google Ecosystem.

Barcamp Los Angeles 3 Wrap-Up

Joe stopped-by for a few hours on Saturday and taped his business card to our sponsor logo, reminding attendees that we are, indeed, hiring :)

Sunday morning started with a lavish breakfast, and Heather giving a very interesting demo of ooVoo, with a colleague of hers travelling through Hong Kong, telling us all about his exciting Tuxedo Travels adventures.

After having spent time in the morning putting together some sample demo code, I gave the 10:30am presentation on "DWR, XHTML, JS ...". The first question I asked of the audience was whether anyone had ever heard of "Internet Brands", and much to my surprise, a few hands actually rose.

While we're best-known for CarsDirect.com, we also operate many exciting destinations such as Wikitravel, World66.com, SlowTrav.com for travelers interested in less "touristy" experiences, Loan.com which provides education, advocacy and a vibrant marketplace for consumers seeking Ethical Lenders, DoitYourself.com for home improvement and home repairs, RealEstateABC and its best-of-breed Home Valuation tool, WikiCars.org for all things automotive, autos.com for car research.

I had a Firefox window opened with tabs for all these sites, and after quickly flipping thru them, I went on to our latest project: the complete redesign, rebuild, re-architecture of CarsDirect.com's Used Cars Marketplace, and the challenges associated with developing an advanced, dynamic User Interface, while keeping it maintainable.

The audience asked very pertinent questions about some of the issues and challenges we're still addressing, such as the ability to bookmark various searches as we refine results, and our current inability to get any SEO juice out of the search results page. Many expressed interest in being able to "subscribe" to vehicle searches via RSS. Doug had actually implemented this feature, but we still need to surface it and fix a few cosmetic issues. But if you're curious, here's a feed for Used Cars in Hermosa Beach, CA, with a power convertible top, and manual transmission.

We've got ... a few ideas for RSS, and possibly more advanced feeds, allowing for more exciting applications ... and not just ones built by us.

Beyond user interface, attendees realizing that each click on the results page triggered an asynchronous call, were curious to know how we returned data so fast. When i joined this project, Doug and his team had already built a proof of concept they called "wireframe" that truly showcased this "instant satisfaction" we get from interacting with the interface. It felt ... impressive, leading to a major "Neo-watches-Morpheus-jump-to-the-next-building ... Wow" moment when he explained how they'd architected the app to make this 1) possible, and most importantly 2) scaleable.

But I digress. The rest of the presentation covered the sample code I'd put-together, showing how we can use "cloned templates with mapped data fields" to facilitate the process of injecting data contained in JavaScript Objects into a document, enabling you to keep the Markup away from the Scripting. So-far we still have management's approval to release this framework into a library, but we do need to find time to re-factor a few things.

After the presentation, I got to meet, chat, and reconnect with a number of interesting people:

Jason Fields from fellow IdeaLab company Snap.com was passing around stickers and reminding us about their very cool "Snap Preview Anywhere™" feature.

Chris Gagne showed me Student of Fortune, and later-on gave a talk on leveraging Open-Source concepts to solve real-world problems.

Zach Greenberger told me all about Valuewiki.com. It's a very interesting concept: They're providing a community-driven securities research site. Being a Wiki, user-contributed content can, to some extent, "self-correct" itself, resulting in much-higher quality information than what you might find on a typical "stock message board" such as Yahoo Finance. They also run "Free the Market" blog, with insightful posts covering the Wiki and Business Worlds. Their PayPerPost.com interview with Dan Rua even got slashdotted yesterday!

Belkin, a fellow sponsor, showed-off a preview of their very cool "Networked USB Hub", to be priced around $120 if I remember correctly. I would have bought one right-away had it been 1) available for sale, 2) had a Mac OS X driver ready. It turns out they're a couple of months away from releasing it, and they do have a Mac OS X driver ready, they just need to get it out of the "beta" stage.

Crystal Williams demoed practical applications of Microformats to a packed audience.

Karl Roth gave us a presentation on his Solar Illumination system, to cost-effectively bring sunlight into just about any building, to complement existing electric lighting with dramatic energy savings during daylight hours. This cost-effective solution would pay for itself in under 2 years in energy savings alone, not taking into account extra revenue resulting from increased productivity from dramatically improved working conditions.

Working with DWR

Update 6/26/2007: See also Working with DWR on the IBDOM site.

Update 5/15/2007: Meet IBDOM, our enabling framework.

Direct Web Remoting (DWR) is one of a few nifty enabling frameworks to build more interactive web applications with less pain.

Unlike most other frameworks, DWR doesn't so-much focus on User Interface. Instead, it focuses on enabling developers to expose business logic written in Java to web browser calls, through a Servlet Container such as Tomcat, Jetty or Resin.

It provides a layer that serializes data returned by a Java Method, into JavaScript JSON-esque objects, retrieved over XmlHttpRequests, and passed into JavaScript call-back functions for client-side processing.

What's interesting about this approach is that what goes over the wire is little more than just "data", versus "markup + data" ... Which doesn't matter if you're only dynamically updating a small portion of an HTML document. But if you're retrieving, say 30 listings, each of which has many fields you need to represent in a table with 7 columns, the Markup required to draw each row really starts adding-up.

Say that in Java-land, we have a SearchManager class, that has a method called "getListings(int zipcode)", that returns a collection of Listing objects. Pretending this method is "static", we could call it from another Java class as such:

listingsCollection = SearchManager.getListings(myZip);

The DWR framework exposes this very class to JavaScript, as well as all of its public methods, so calling this method from JavaScript looks very similar. But when calling it from JavaScript, we always must pass a reference to a JavaScript call-back method: it will receive the output of the method call as a parameter.

SearchManager.getListings(90254,displayListings);

Where displayListings is defined as a simple JavaScript function as such:

function displayListings(theListings) {
...
}

The question now becomes ... "what happens inside of function displayListings(theListings)" ?

The function receives a JavaScript Array, whose members are Objects whose properties match those defined back in Java in a Listing bean. We need to loop thru the Array, and for each member, update the HTML in the document, to render that listing:

listingsTable = document.getElementById("listingsTable");
for (i=0; i < theListings.length;i++) {
currentListing = theListings[i];
listingsTable.innerHTML += "" + currentListing.id + "" + currentListing.title + "
...repeat 5 more times for each column ;
}

...

ew.

.innerHTML is very simple to use, but it facilitates the mix of Markup inside scripting and that has a few disadvantages: Since it's possible to pass any string to .innerHTML, it's very possible to generate broken markup, and when broken enough, it could even crash some old version of Safari, sweet! -- not.

Further, having markup live inside JavaScript, makes it more tedious to rethink and tweak the user interface, or simply troubleshoot presentation issues. Which means more work.

Last, .innerHTML isn't part of the DOM specification, or any other spec for that matter. But all browsers do support it.

Instead of using .innerHTML, one could stick to pure DOM methods to update the listingsTable, such as:

loop ...
theRow = listingsTable.appendChild(document.createElement("tr")); theCell = theRow.appendChild(document.createElement("td"));theText = theCell.appendChild(document.createTextNode(listing.id));...repeat 6 more times for column in the row
end loop

... Sticking to DOM methods pretty-much prevents us from injecting horribly broken HTML.

But this gets very tedious, fast, and we're still building Markup inside JavaScript, leading to ... more work.

...ew.

We were looking to easily "Map JavaScript objects to HTML Elements". Imagine having reusable "templates" in your HTML document, made of any number of elements inside of which you placed "data:somePropertyName" placeholder values:

<tr class="resultRowTemplate">
 <td>
 <a href="data:vehicleDetailUrl">data:listingTagLine</a>
 </td>
 <td>
 $<span>data:price</span>
 </td>
 <td>
 <span>data:mileage</span>
 </td>
 <td>
 <span>data:distanceFromDealer</span>
 </td>
</tr>

This template was mapped to a JavaScript object with the following fields:

listing.vehicleDetailUrl
listing.tagLine
listing.price
listing.mileage
listing.distanceFromDealer

Achieving this set-up thoroughly increased the fun of working with DWR, and beyond DWR, ought to be highly useful in any situation where developers are faced with injecting JavaScript Object data into HTML documents.

We're looking to gauge interest from fellow JS/AJaX/DWR developers (Yes, YOU!), in our releasing some enabling libraries within an open-source context. Our current code is in need of serious re-factoring before any sort of public consumption. If you come across this entry, please voice your thoughts in comments. Some of us will be at BarCamp Los Angeles 3, hoping to do a little demo, code reviews about this and a few other things.

Also: We're looking for a User Interface Engineer to help out with existing similar projects, and many cooler "things" coming down the pipe.

Harnessing Transparency

Power or Ease of Use, Power and Ease of Use, being feature-rich or simple, being feature-rich *and* simple. A few of many questions it's safe to assume Jonathan Ive and his team ask many times over with each product Apple brings to market.

Thankfully though, we're not Apple ... We're not "quite" out to tackle profound industrial design challenges.

Unlike hardware designed in utmost secrecy, manufactured and shipped to millions of homes, with only one shot at getting things right, we get to build products in the far more flexible, transparent world of Web Applications.

With tonight's release and this post, Doug's clearly out to harness this flexibility and transparency.

Unleashing a new application unto an established user base is an unnervingly exciting rush, riddled with disconcerting lows and euphoric highs, adapting to some challenges we did not expect, carefully preserving preexisting business requirements while paving the road for new opportunities.

As developers we can never know enough. On one hand we face a healthy backlog of "Phase 2" issues we want to tackle, on the other hand we face this nagging suspicion that we have not yet begun to understand what does, indeed, need to be tackled.

So we reach out.

See also: Seeking the Zen of buying used cars.