Eric DeLabarWeb 2.0 from a Web Purist and J2EE Developer

From what I’ve seen, most of the popular JavaScript frameworks out there provide some form of the $ method. This method is usually a cross-browser translation of document.getElementById with a few extras. What this means is instead of always having to type document.getElementById("myId") you can now type $("myId"). All-in-all it’s a very nice shortcut and will probably cut quite a bit of typing out of your JavaScript projects. My problem is with the number of times I’ve come across inefficient uses of this helper function because it’s easier to type. This usually manifests itself as something along these lines (this example written using prototype.js):

1
2
3
4
5
6

if( $("myId").style.display.toLowerCase() == 'none' ) {
	$("myId").style.color = 'red';
	$("myId").style.height = '10px';
	$("myId").style.width = '100px';
	$("myId").style.display = 'block';
}

This code looks pretty concise, if you know what the $ function does it’s also pretty simple, but take a second to think about performance. In this code it’s possible that you’re calling document.getElementById five times! Ignoring whatever else the $ function does, the document.getElementById function could traverse the entire DOM on each call. (I’m not saying it does, but you really don’t know what the browser is doing under the covers and since you’re designing for all JavaScript enabled browsers, it’s better safe than sorry!) If you actually had to type out the document.getElementById you would probably consider something like this:

1
2
3
4
5
6
7

var myId = document.getElementById("myId");
if( myId.style.display.toLowerCase() == 'none' ) {
	myId.style.color = 'red';
	myId.style.height = '10px';
	myId.style.width = '100px';
	myId.style.display = 'block';
}

With this code, you’re only calling document.getElementById once, and therefore only traversing the DOM once. Makes a little more sense right? Let’s look at some metrics.

For this experiment, let’s make the assumption that the larger your document is the longer it will take to perform a DOM traversal, so in order to see some results we’ll need a decent sized document. For that we’ll go to wikipedia and grab something off the front page, in this case it’ll be Harry Potter. To get my test document I viewed the source, grabbed the main body content, and pasted it into a new HTML document. I also removed all of the images since I didn’t want broken images or to be hitting wikipedia’s servers for my experiment. I wrote a quick JavaScript class that will do my benchmarking, and a quick test case that calls my two methods above as well as two other methods and single calls to both the $ function and the document.getElementById function. To perform the benchmark, I run each method 1000 times. I initially tried smaller numbers but there was not enough visual difference to prove my theory since JavaScript is only accurate to the millisecond. You can find the test code here, the benchmark class here, and you can run the test here. I’m using Firebug Lite for the console logging, but if you have Firebug installed it will use the Firebug console. As I said before I just wrote the benchmarking class, but look for a future post and improved version now that the seed has been planted.

I have successfully run the test on Safari 3.1 on OSX 10.5, Firefox 2.0.0.13 and IE 7.0.6000.16643 on Windows Vista Business 64-bit, and IE 6.0.2900… and Safari 3.0.4 on Windows XP Pro. My results were as follows:

Across the board the optimized functions performed better, and in most cases the $ function was slightly slower than the document.getElementById function. The most surprising result is Safari on Windows because it’s actually the slowest machine that these tests were run on. The only problem that I can think of with this test is that it does quite a bit of looking up by id, and that’s probably not an accurate test case, but even if you’re cutting out only a few milliseconds on an event, somebody will notice the improvement. I’m welcome to any suggestions or comments on my testing methodology.

Let’s pretend, be it from VC’s, angels, or remortgaging your house, you’ve come into some investment capital and are looking to build a web application.  Here are my top 10 ways to spend every penny of it and still fail miserably.

1. Over-complicate your concept

   So you have an idea, a good idea is a simple one. Take your core concept, develop that and only that, and get it out to the public. Run a closed beta, or even a public beta, and see if there’s interest. You and your investors may think it’s the greatest idea in the world, but if nobody else does it’s not going to make any money. Before you consider your user interface, chew on this for a while.

2. Buy tons of expensive hardware and software

   If you’re taking my advice on number one, this one is easy. A simple concept with a simple implementation doesn’t require a quarter million dollars of hardware and software licenses. When you start out you won’t have tons of data, or users, and if your app is programmed correctly I would hope you don’t have tons of processor load. Try out shared hosting, or maybe a year-long contract on a dedicated server, or if you must buy or lease hardware, acquire a simple 1U machine or small cluster and see how it works. Build your app on a platform that scales well, and design it to be scaled. Hardware gets cheaper by the day so three months down the line you’ll get more disk, RAM, and gigahertz for less money and it won’t all be sitting at 99% idle while your user base is ramping up.

3. Develop to a functional specification

   A functional spec looks great on paper, but sit down and think about it. Can you honestly tell me that you can think of EVERYTHING your app needs to do right now? You don’t even know what your users are going to think of it or do with it, they could end up using your application for something you never even thought of, and your entire business plan my have to evolve to accept it. Consider agile development, you’re probably going to pay developers by the hour and have to spend time working with them, but you can adjust as necessary when you see something just isn’t working. Agile development offers a finished product that is exactly what you need now, not exactly what you thought you needed three months ago. It may even save you money if you decide to make radical functional changes or that your app is perfect without feature A. Remember point number one here; your app is done when people love it and use it, and you won’t know that until they’ve had a chance to put their hands on it. If you’ve still not sold, read this.

4. Waste time

   This is the internet, first to market gets the buzz and everyone else is a copycat. The more time you waste with things like functional specifications and bulky frameworks or languages, the higher the chance somebody else is going to do it first.

5. Ignore the early adopters

   Web 2.0 applications live and die by the blogosphere, get your beta out there, make sure some of the movers and shakers are interested, and listen to what they have to say. If they love it, your lucky, if they don’t, listen to them, if they hate it, cut and run. If the blogosphere doesn’t generate any traffic for you it’s pretty unlikely that any other advertising will. Geeks try things first, geeks tell their friends and family if it’s worth it, but geeks may also tell you what you can do to make things better, and if you listen, they’ll probably tell even more people because you did.

6. Ignore the experts

   Maybe you’re not a web developer by trade, so you hired some company to help you develop this application; you’ve hired them, they must be good so listen to them. Chances are they’ve done more of this then you, they understand the technologies and the medium, and they just know how this stuff works. You hired them, trust them, don’t tell them how to do their job.

7. Get more investors

   If you’re looking for more investors I’m assuming you’re looking for more money, and I have to ask “why?” Is there something wrong with your business plan? Did you start with less money than you thought you needed, or are things going badly? Investors take wooing, possibly traveling, these things cost money, consider cutting the fat from elsewhere first and don’t waste your resources.

8. Use buzzwords

   Buzzwords are expensive. If you’re not a developer and you walk into a software shop and start throwing around AJAX and Web 2.0 you’re bill is going to go up. Let the shop tell you when AJAX is appropriate, let the shop define Web 2.0, because it’s not just animations and shiny buttons. You won’t impress anyone with how well you can use buzzwords in a sentence you’ll impress people with how well (and appropriately) you use the underlying technologies in your application. If you want to use buzzwords, try usability, accessibility, and progressive enhancement, you’ll get more credit from an informed developer and your application will be much better for it.

9. Hire too much management

   Managers are expensive. They suck up time with unnecessary paperwork, meetings and bureaucracy. Spend you money on quality developers and let them do their thing.

10. “Improve” somebody else’s idea

    In my experience, first-to-market usually wins, hence rule number 4, but if you want another opinion, read this. Basically there’s room for three, the first, the free, and the best. If they already exist you better be able to cover the free and the best or maybe just the best but if you have an incredible marketing team. Users get entrenched and usually won’t switch, so if your market is saturated, it may be a good time to consider a new idea.

That’s my two cents, if you like it, listen to it. If you want to use my experience and work with me, please contact me. If you disagree, comment, I want to hear why.

To state for the record, the opinions expressed in this article are those of the author and not his employer, while his employer may be willing to work under different terms, this is not their SOP.

Let me start out by saying I love my job, as far as I know my employer is in great standings and will be in business for years to come, and as of this moment, I’m not actively looking for a new job. With that being said, if an offer-I-can’t-refuse lands on my lap, I’m probably outta’ here. The problem with that statement is why should an offer like that land on my lap? I have this website (which at the moment doesn’t do much showing off at all), a LinkedIn profile, and a community theatre website, on a generic WordPress theme, to show to my name and abilities.

I work a 40+ hour week, have a wife and new child, and participate in a number of activities and have quite a few hobbies, so my time is definitely at a premium. In the past I’ve done freelance work but none since I’ve worked here, and none I’d want my name associated with today. (Experience has taught me a lot.) My work here is in most cases hidden behind firewalls on corporate intranets or protected by non-competes or privacy clauses that keep me from saying I’ve done work for Client A so that Company B doesn’t know who their competitor is using. The work I do complete that’s publicly available and open for discussion is rarely more than 10% mine, and more often than not does not exercise any of the design ideals I believe in. Even if it was I don’t believe it’s in my right to use these in a personal portfolio that exists to potentially take me away from my current job. Which basically means I have nothing to show from four-years professional experience and ten years web experience other than a unstyled blog and a low-traffic, locale-specific website I don’t have time to make amazing.

I guess the point of this post goes back to something Andy Rutledge said a few weeks ago regarding design professionalism. In the words of some insurance company life comes at you fast; I don’t know what tomorrow is going to bring and I have a family to support should my job disappear for some reason. I feel I should have a portfolio and a resume, be it from freelance or from some side business, or even from my work at my current employer. I don’t think it’s a matter of unprofessionalism, it’s a matter of self preservation. My high-school guidance counselor said statistically speaking I’d have something like fifteen jobs in the length of my career, I’m on number five, (maybe six or seven, depending on your definition of a job), I can’t afford to be unemployed, so where does that leave me? Right now, partially by my own fault, possibly by my employer’s intentions (which I can’t blame them for), I’m stuck in a hole, destined (or doomed) to work here as long as my job exists. Again, don’t get me wrong, I like my job, I don’t think it’s going anywhere, but there’s a lot of wisdom in not placing all of one’s proverbial eggs in a single basket.

Last week at the Emerging Tech Conference I dropped my card in the fishbowl at the Manning Publications table to win a free eBook. Turns out I actually won! This morning in my e-mail I found a free eBook copy of Groovy in Action. I haven’t read any of it yet, but I would like to thank Manning for the book, and I will definitely write up a review when I’ve had some time to read though it.

Until then, if you’re interested, Groovy is a scripting language that runs in the Java Virtual Machine. Until the Emerging Tech Conference I really was not all that interested in Groovy, but then I saw a presentation on Grails, a Ruby-on-Rails like application framework that uses Groovy instead of Ruby. The neat thing about Grails is that it’s really just a wrapper around a Spring Framework back-end, including a Hibernate-based persistence layer. I still need a chance to play with the whole stack, but it’s definitely on my list of things to do because it offers a lot of the neat things about RoR without learning an entirely new language and set of libraries. So far the only downfall I see is that like RoR, Grails really doesn’t run on a shared (read cheap) hosting setup, so if you want to put a Grails app into production you probably need a Java App Server, which typically costs quite a bit more the PHP hosting.

To continue the discussion on the design of this blog, I’m going to take a moment and step onto my soapbox. But first, a brief introduction to the topic at hand.

I think I noticed this whole grid revolution back in December 2006 when Cameron Moll mentioned it in his article Gridding the 960, based on the optimal layout width for a 1024px wide screen. I was interested, and sites designed using a grid seemed pretty sharp, so I added it to ma.gnolia and moved on. A few months later I caught an article on ALA about the baseline grid, a post to 24-ways about vertical rhythm, and after that a nice 7-step guide to creating a grid-based design, and a great piece on incremental leading. Between these five articles, (and about a year’s worth of time) the concept finally clicked in my mind.

Enter the frameworks. Sometime in the last few years a number of CSS frameworks have emerged, including frameworks from giants like Yahoo, and brand-new frameworks like the 960 Grid System. The most popular, as far as blogosphere-based chatter is concerned, is probably Blueprint, which recently released version 0.7, giving you a pretty good idea of how young this technology is. So, with (at least) three frameworks out there you must be saying. “Surely one is a suitable fit for EricDeLabar.com?” That’s exactly incorrect, at least for Blueprint, but not for 960.gs and here is my reason why.

Semantics. Please, put the pitchforks and torches down, I’m not saying that Blueprint and 960.gs are is un-semantic, I’m saying they it could be more semantic. I’m a strong believer in separation of content from presentation, and IMHO, this is the reason why CSS is as amazing as it is. If you’re not 100% sold on this concept, check out Zen Garden and order yourself a copy of Dave Shea and Molly Holzschlag’s book The Zen of CSS Design. For today’s post I’m going to ignore YUI, mainly because it’s too huge for my taste, and concentrate only on Blueprint and 960.gs.

Both Blueprint and 960.gs use HTML class names to specify the width of the grid, these class names are specifically named with the number of columns the content block is supposed to span. This violates the separation of content from presentation because now the HTML contains instructions on how to render the page. That’s it, my two-sentance, semantic-web-purist’s argument against the current batch of CSS frameworks. Can it be fixed? Of course it can! The easiest way to do this is probably with some sort of script-based solution that provides CSS post-processing. Initially I thought of CleverCSS, but then I realized that the newest version of Blueprint already does this! Imagine my surprise when I discovered this wonderful fact a half hour into writing my post! Oh well, I’ve learned something, and the web is a better place, so I’m going to post this anyway, send you over to the details on the Blueprint Compress ruby script on jdclayton.com, and formally state that I stand corrected and I will probably be using Blueprint for this site’s layout.

As of today, if you run a Google search to see what pages of my site are in the index you’ll find quite a bit. However, the pages in the index reflect a URL structure that I’m not thrilled with for SEO reasons. In order to remedy this problem I did some playing with Google’s webmaster tools and my .htaccess file. As of today we’re going to employ some 301 redirects to get the SERP’s pointing in the right place, remove some old pages from the index, and modify my robots.txt. Hopefully these changes will concentrate my search results to show off the real content of this site and lose some of the fluff. Along the way, we’re also going to find out how long it takes for these corrections to take place.

First things first, here’s the problem, if I do a google site search like this site:www.ericdelabar.com I get results that look like this:

Notice the entries that look something like www.ericedelabar.com/?cat=11? They all work, but they’re not ideal for SEO, so first things first, the .htaccess file.

1
2
3
4
5
6
7
8
9
10
11
12
13

redirect 301 /?cat=1 http://www.ericdelabar.com/
redirect 301 /?cat=5 http://www.ericdelabar.com/category/standards
redirect 301 /?cat=6 http://www.ericdelabar.com/category/seo
redirect 301 /?cat=7 http://www.ericdelabar.com/category/firefox-extensions
redirect 301 /?cat=9 http://www.ericdelabar.com/category/eclipse
redirect 301 /?cat=10 http://www.ericdelabar.com/category/the-hard-way
redirect 301 /?cat=11 http://www.ericdelabar.com/category/css
redirect 301 /?cat=12 http://www.ericdelabar.com/category/view-from-the-trenches
redirect 301 /?cat=13 http://www.ericdelabar.com/category/user-behavior
redirect 301 /?cat=14 http://www.ericdelabar.com/category/usability
redirect 301 /?p=5 http://www.ericdelabar.com/2007/02/in-beginning-there-was-doctype.html
redirect 301 /?p=7 http://www.ericdelabar.com/2007/03/lets-talk-about-tools-part-2.html
redirect 301 /?p=8 http://www.ericdelabar.com/2007/03/css-things-i-learned-hard-way-absolute.html

Each line in the file is a rule, the redirect is the command, the number is the type, which in this case is 301, which means “moved permanently,” the original URL comes next, and then finally the desired URL. Looking at my list, I have two basic redirects here, redirects to convert from category id to the category name, and redirects to convert from post id to post slug. These lines must be before the # BEGIN WordPress comment in your .htaccss file, if they are not, they will not work.

Now that categories and posts are redirecting, there is one final problem, the last few pages of results contain quite a few search result pages. These pages have a URL pattern something like the following: http://www.ericdelabar.com/index.php?s=firebug. I don’t really want my search result pages in the SERPs, but I’m not ready to get rid of them all yet. To remedy this I simply installed the Search Permalink plug-in which redirects the ?s=keyword pattern to /search/keyword/, which is not perfect, but looks a little nicer than the query string. In the long run I will probably remove them from the SERPs altogether, but I haven’t decided on my search strategy for this site yet, so I’ll leave that for another day.

Next we want to keep Google out of the site admin, so we add the WordPress login page and admin section to the robots.txt file by adding the following lines.

4
5

Disallow: /wp-login.php
Disallow: /wp-admin

Next, we’re going to use the Google Webmaster Tools to remove the wp-login and wp-admin pages from the index. This requires that the pages have either a robots.txt file disallowing them or a robots metatag with noindex specified. Since our robots.txt file should handle this, our request should look like the following:

Finally, we resubmit the site for crawling and hope that this gets cleared up within a few days.

Now this methodology only specifically addresses Google, my site has also been indexed in MSN, Yahoo, and Ask, and steps will have to be taken to resolve these as well, but fixing Google is definitely a good start!

Since I found out that HappyCog redid the admin for WordPress 2.5 I’ve been interested to see what it looks like. This morning I decided it was time. I originally used the DreamHost one-click install to setup my initial install, and although it is a nice feature, I decided that SVN was more my thing. Going through the steps provided was pretty simple, and my upgrade was complete in about five minutes total.

As far as compatibility, all of my existing plugins “worked” but the XML Sitemap plug-in looks a little funny thanks to the new admin design. While I was at it I added the ClickPass plugin as a follow-up to my recent foray into OpenID. I’m not sure it’s working correctly, I can login with my ClickPass account (which I’m assuming is cookie based), but have been unsuccessful merging my preferred OpenID, or even the one Technorati provides. I will have to look into that one a little further, but until then, no ClickPass for me.

Ok, I’ve been blogging for two weeks now, I think I may have the habit for it. I say this because if I don’t have a post done by my second cup of coffee I start twitching uncontrollably. Yeah. Seriously though, I’m a procrastinator, if I don’t have a deadline I will simple put things off forever, so in order to get this site a skin, I need a hard due date.

So, in honor of this year’s May 1st Reboot, the new style is going live on May 1st. I’ve signed up, submitted this site, and I now have roughly 29 days to make it something other than black on white. Now that doesn’t mean it will happen any time soon, in fact I’ll probably do most of it the week the site is down in preparation for the reboot, but I can assure you, May 1st is it, no more black and white.

It all started last week when I read an article on Vitamin about the launch of ClickPass at SxSW. I’d noticed OpenID before, mainly on the Ma.gnolia login page, but I never really saw a reason to get one for a single site. Today, I finally decided to check it out.

I started at ClickPass, which lead me to OpenID.net, which listed a page containing all of the OpenIds that I already have. Not really wanting to tie myself to a particular web app, I choose myOpenID because I liked the logo. I quickly created an account, then noticed that you could get a myOpenID for a domain, since I own delabar.org, openid.delabar.org was born. After some quick configuration, I had my open personal OpenID that was easy for me to remember and ready to use. Very cool.

Looking into the topic further, I found Sam Ruby’s instructions for setting up OpenId without using a service, interesting from a privacy perspective since you’re in complete control of your information, but at the same time you lose the third party verifying your identity. Leaving that debate for another day, the best part of the post was the first section where Sam talks about using delegation to claim your blog. With a simple block of code in your html head, something like the following, you can use your blog as your OpenID.

10
11

<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://openid.delabar.org/eric" />

Using this quick test I verified this, and I can now use my blog URL as my OpenID. Now, what is my reason for doing that? I really don’t have one, since I’m already using my own domain as my OpenID. However, if I was using some other OpenID, like my Flickr URL for example, I would have a level of redirection that would allow me to swap Flickr out for Technorati without having to go and re-authenticate at all of my sites that use OpenID. Now, let’s bring in the Social Graph, a quick bit of XFN code in my link above, and now my OpenID identification page is part of my social graph.