The Big Dumb Developer

Software and Football

noreply@blogger.com (Steve) — Tue, 06 Oct 2009 00:16:00 +0000

Football has metrics - yards per rush, completion percentage, time of possession. Do you think Mike Tomlin talked about their yards after the catch after they won the super bowl? Do you think Arizona fans cared that their team won the time of possession battle? In football, metrics are useful tools for the teams and only important in fantasy football. Every football player and coach in the NFL understands that the only metric that matters is W's.

We have metrics in software - burn downs, lines of code, reopen rates. We spend years delivering metrics and no products. We have SMART goals to justify our bonuses. We WORSHIP our metrics. In our fantasy world, we are world class developers and have the metrics to prove it. When our products don't fly in the market, our business owners are idiots, we got bad requirements, our sales people suck; but our metrics are awesome.

Are you smarter than the average linebacker? Has your software career been concusion-free? Then stop trying to be a rock star in fantasy development and start focusing on your product's success.

A startup isn't a business

noreply@blogger.com (Steve) — Sat, 07 Feb 2009 07:31:00 +0000

At a startup you are not really "In Business", you are trying to build a business.

When you work at a startup, all you see is the vision. The customers, the business model, the cash-o-la, your expanding team of minions. WE CANNOT FAIL. When you look at your competition, you see their current business - and it looks like crap.

Trust me, their vision is just as grand as yours.

And your reality is just as crappy as theirs.

Have a vision, but don't lose site of the current state.

Cisco VPN on Vista

noreply@blogger.com (Steve) — Mon, 30 Jun 2008 14:24:00 +0000

If you use the Cisco VPN client on Vista this, bookmark this: http://www.verier.co.uk/subtext/archive/2008/01/09/reason-442-failed-to-enable-virtual-adapter-with-cisco-vpn.aspx

And, to avoid such problems, disconnect the VPN before you let you computer go to sleep.

Installing DB2 on Vista

noreply@blogger.com (Steve) — Thu, 10 Apr 2008 04:40:00 +0000

In case anyone else runs into this, you have to log in as an administrator to install DB2 on Vista. Logging in as administrator is different than logging in with an account that has administrator access. And, because they said so, the administrator account is disabled by default. Follow life hacker's instructions to enable vista's administrator account.

My actions GET POSTs

noreply@blogger.com (Steve) — Wed, 16 Jan 2008 16:50:00 +0000

Quick note on a pattern I've picked up from tinkering with Rails and have happily used in other web platforms - using the same controller action for both GETs and POSTs. Basic pattern looks like this (pseudo code):


someAction()
{
    if( request.isPost() ){
       handle the posted data...
    }
    else{
       handle setting up the form...
    }
}

In your HTML, you don't have to specify an action, it will just POST to whatever GET was used to fetch the form in the first place. I'm implementing some file-import functionality today, and this came in handy as I can reuse the file form view for all of my various import actions.

In Rails, you can accomplish this with routing - same rout pattern sent to different actions based on the request method. There isn't an equivalent in my Struts 1.x app, so far that hasn't bothered me, though.

I would love to hear what other people think about this pattern. My initial thought was that coupling generating the form and handling the response was a negative, but in my day to day work I've yet to run into an example where coupling them together was a bad thing.

Safari won't set cookies from javascript on localhost

noreply@blogger.com (Steve) — Wed, 14 Nov 2007 16:34:00 +0000

Ran into this today - if you're testing your work with Safari, it won't set cookies from javascript on localhost. Hit you local box using 127.0.0.1 and it will work. Grrrrr :(

Metaprogramming in the wild - script.aculo.us effect's afterUpdate only the first time

noreply@blogger.com (Steve) — Mon, 08 Oct 2007 19:04:00 +0000

So, I want to fade in some content and I need to adjust a scroll on the content.

I can't adjust the scroll while it's hidden because none of the scroll info will be set.

I can't update it after the animation, because there will be a nasty jump.

What I really want is to adjust the scroll after the first frame of animation - after the content has been shown but while it's still mostly transparent.

The only script.aculo.us hook that will fire at this point is afterUpdate, but it's also going to fire on every animation.

Enter some metaprogramming. Define a afterUpdate that cleans up after itself:


new Effect.Appear( this.details_div, {duration:.5, 
    afterUpdate : function(){
        FooManager.adjustScroll();
        this.afterUpdate = undefined;
    }
});

This works like a champ.

All Code is Business Logic

noreply@blogger.com (Steve) — Tue, 25 Sep 2007 18:35:00 +0000

Worse than Failure really hit it out of the park with The Mythical Business Layer. It's a great article that makes the point that developers don't like solving the boring old business problems, so they transform them into big "enterprise" problems that are fun and challenging to solve ... with disastrous results.

If you want to be successful, stop thinking about yourself and start thinking about your customers. This is not a new concept - Dale Carnegie figured this is out 1937.

Undo isn't easy

noreply@blogger.com (Steve) — Tue, 18 Sep 2007 15:14:00 +0000

Aza Raskin says undo for web apps is easy. *cough bullshit cough* I completely agree with Aza's overriding premise: undo is a lot better than a warning. This makes his current article that much more frustrating - he's using an incorrect argument to champion a correct idea. Kind of like saying performance doesn't matter because CPUs are cheep.

So, to the point. Aza argues that you should use undo instead of warning because undo is, despite the prevailing opinions on the subject, easy to do in web apps. This is just plain wrong - a general solution to undo in AJAX web apps is a hard problem. He's off the tracks quickly:

In this series of blog posts, my goal is to explain just how easy it is to provide Undo functionality

So, you need a series of posts to show how easy something is. Ok, if it's so easy, why does it take a series of posts?

Next, Aza deploys a commonly used (and completely incorrect) approach to prove his point: he offers up one specific example where his conjecture holds. This is about as clever as saying "Everyone drives a Honda. See, I drive a Honda". To prove that undo is easy, you can't just show that in one specific example it is easy, you have to show that it is easy in all situations. The comments are ample proof that there are scenarios where a solution is tricky.

Aza continues, either out of ignorance or religious devotion, to defend his position by pointing out that his example is only valid in a specific, simple scenario. This amounts to defending your position by agreeing you are wrong.

Using a default params hash :: Avoiding defaulting with ||

noreply@blogger.com (Steve) — Tue, 18 Sep 2007 11:30:00 +0000

I saw mention of Crockford's javascript style recommendations yesterday. I'm a big fan. One pattern, though, that I have begun generally avoid is using the || operator to specify default values. Consider this code:


function doStuff(params){
  params = params || {};
  var foo = params.foo || 'fooValue';
  var bar = params.bar || 'barValue';
  ...
}

I love how clean this pattern is. The API is flexible and it reads very easily. Unfortunately, there is a very subtle bug - you can't pass in values that are falsy because || uses type coercion. So this:


function doStuff(foo){
  foo = foo || 'foo not specified';
  alert( foo );
}

foo( '' );

will give you 'foo not specified' when the intent was to use an empty string. You can only rely on the default operator when falsy values cannot be valid values.

I have begun to use a default hash pattern I first saw in Ruby on Rails code (and is also used extensively in script.aculo.us):


function doStuff(params){
  params = params || {};
  var default = { foo : 'fooDefault', bar : 'barDefault'};
  params = merge( defaults, params );

  alert( params.foo );
};

This will give you what you want.

Here here an example merge function:


function merge(ontoObj, fromObj){
    for( var i in fromObj ){
        if(!fromObj.hasOwnProperty(i))
            continue;
        ontoObj[i] = fromObj[i];
    }
    return ontoObj;
}

replaceHTML - remove, insert, put back is better

noreply@blogger.com (Steve) — Thu, 13 Sep 2007 16:00:00 +0000

** Updated **
Steven put up another speed demo that demonstrates that replaceHtml is in fact faster than the remove-update-replace method, though not by nearly the same gap as innerHTML.
*************

Read an piece on Ajaxian this morning covering Steven Levithan's replaceHTML post on innerHTML being too slow and offering a replaceHtml alternative that is much faster. It works by creating a new element, using innerHTML on it, then replacing the existing node with the new node. Here is the code:


/* This is much faster than using (el.innerHTML = value) when there are many
existing descendants, because in some browsers, innerHTML spends much longer
removing existing elements than it does creating new ones. */
function replaceHtml(el, html) {
 var oldEl = (typeof el === "string" ? document.getElementById(el) : el);
 /*@cc_on // Pure innerHTML is slightly faster in IE
 oldEl.innerHTML = html;
 return oldEl;
 @*/
 var newEl = oldEl.cloneNode(false);
 newEl.innerHTML = html;
 oldEl.parentNode.replaceChild(newEl, oldEl);
 /* Since we just removed the old element from the DOM, return a reference
 to the new element, which can be used to restore variable references. */
 return newEl;
};

This is a lot faster, but there really isn't any need to create a new node. The reason the method is so much faster is due to using innerHTML on an element that is not in the DOM vs. one that is in the DOM. Instead of creating a new node and deleting the old one, you can just take the node out of the DOM, use innerHTML, and then put it back. This has the added benefit of not invalidating any existing references to your element.

I whipped up an example to compare the differences. I generated an HTML string with 15,000 elements and used three different methods for updating a a div to this content - innerHTML, removing the node before innerHTML, and then the replaceHtml function. I did each four times and profiled with Firebug. Here is the script:


var html = [];
for( var i = 0; i < 15000;i++ )
{
 html.push("<span>CONTENT</span>");
}
html = html.join("");
var el = document.getElementById("div");
el.innerHTML = html;
function doit(){
 withoutRemove(el, html);
 withRemove(el,html);
 el = replaceHtml(el, html);
 withoutRemove(el, html);
 withRemove(el,html);
 el = replaceHtml(el, html);
 withoutRemove(el, html);
 withRemove(el,html);
 el = replaceHtml(el, html);
 withoutRemove(el, html);
 withRemove(el,html);
 el = replaceHtml(el, html); 
}
function withoutRemove(el,html){
 el.innerHTML = html;
}

function withRemove(el,html){
 var nextSibling = el.nextSibling;
 var parent = el.parentNode;
 parent.removeChild(el);
 el.innerHTML = html;
 if(nextSibling)
  parent.insertBefore(el,nextSibling)
 else
  parent.appendChild(el);
} 

function replaceHtml(el, html) {
 var oldEl = el;
 /*@cc_on // Pure innerHTML is slightly faster in IE
 oldEl.innerHTML = html;
 return oldEl;
 @*/
 var newEl = oldEl.cloneNode(false);
 newEl.innerHTML = html;
 oldEl.parentNode.replaceChild(newEl, oldEl);
 /* Since we just removed the old element from the DOM, return a reference
 to the new element, which can be used to restore variable references. */
 return newEl;
};

And here are the results:

Method Average Time
------------- ------------
withoutRemove 4914.063ms
replaceHtml 656.25ms
withRemove 601.563ms

using innerHTML with DOM methods

noreply@blogger.com (Steve) — Wed, 12 Sep 2007 20:34:00 +0000

I tend to prefer to generate content following this pattern:


var html = [];
html.push('<h1>CONTENT!</h1>more content...');
...
el.innerHTML = html.join('');

In most cases in most browsers this is the fastest way to create markup it's a lot easier to grock the markup this way verses using DOM methods.

One issue I have with the approach is that you need a 'hook' element to dump the html into. This leads to a lot of empty nodes sitting around waiting for script to innerHTML them. Eventually, I stumbled on a way to avoid the hook elements and still have my innerHTML.

The key is to create a temp element


var temp = document.createElement('p');

us it to parse an html string


temp.innerHTML = '<h1>content!...</h1>';

then using DOM methods to insert the content


while( temp.childNodes.length > 0 )
  el.parentNode.insertBefore(temp.childNodes[0], el);

Example:


var html = "<div>A lot of content...</div>";
var temp = document.createElement('p');
temp.innerHTML = html;
var el = document.getElementById('idOfElementToInsertBefore');
while( temp.childNodes.length > 0 )
  el.parentNode.insertBefore(temp.childNodes[0], el);

5 truths about web users

noreply@blogger.com (Steve) — Wed, 05 Sep 2007 20:58:00 +0000

1. Users don't care if you have an awesome build script.

Does the gmail development team have a continuous integration process? Does Expedia.com's development team have full unit-test coverage for all their code? Can Linked In deploy the website by pushing one button?

I don't know and am still one of millions of happy customers.

A kick ass environment can really help you build a great product - but it won't build it for you. People tend to focus on problems they are comfortable with to avoid the really hard problem. Like setting up a great environment instead of creating a great product that people love to use.

Worry about having a great product before you worry about your development environment.

2. Users have more than a LAN between their browser and your servers.

I am in the middle of building the latest and greatest. The main page has 15 uncompressed javascript files, 10 background gifs, a couple of extra css files, and sends almost half a meg of data to render the page. It takes about a second for all of this to show up in my browser.

Of course, my browser is sitting on the server, and I've got endless RAM and multiple processors.

When I put this on a test server and hit it from home through DSL, the cloud, and our shared pipe at work - a second becomes over 10 seconds. Long enough that I check ESPN for any new football news.

Having a slow app is like building a car with doors that don't open. People won't buy a car if they have to crawl through the window to get in.

Put your app on an external server and hit it with consumer-grade net access.

3. Masturbatory animation only satisfies the developer.

I need tabs. I know how to use multiple animation frameworks. Hell, I can roll my own animation! So my tabs animate, rotate, morph, slide, and fade. YEAH.

Here is what I think:

Ooh, my tabs rotate, change color, animate, and play a sound when you hover over them. That's SOOO HOT!

Here is what my users think:

What the shit!

Don't do anything just because you can - it will just get in the way.

4. Users don't know flash or html.

Check out this photographer's site.

Here is what the developer thinks:

HTML and Flash - I'm giving my users the best of both worlds!

Here is what the average user thinks:

What the shit!

When your application asks users a question, first ask yourself "do I really need to ask?" If you do, ask yourself "would my mom know how to answer that question?" If they answer is no, rethink your solution.

5. You users will not print out you home page, frame it, and hang it on their wall.

Your application is not art. Users do not care if it "pops" or "looks hot". Users care that it does what they expect when they click a link. Users care that they can use the app without having to constantly think "how do I do that?". Users really care when you app makes their lives easier.

Don't worry how your app looks hanging on your wall, worry about how happy your users are.

Simple, synchronous AIR configuration

noreply@blogger.com (Steve) — Mon, 27 Aug 2007 22:46:00 +0000

I've spent some time the last couple of weeks poking around with AIR. The Adobe Integrated Runtime promises to let you build desktop applications using Javascript. Basically, it gives you Webkit and a series of APIs you can access through the window.runtime object that provide all sorts of things like access to the file system, drag and drop, and a SQL Lite database. You can also use Flash and Flex, but I'm not smart enough for that. I ended up trying to build a persistent key/value configuration system and quickly ran into a frustrating reality of AIR's SQL API - everything is asynchronous. This makes using the DB for storing configuration frustratingly convoluted.

You have a simple config table - key:string, value:string. Say you want to read the value for the key "foo". You end up with code that looks something like this:


var stmt = new air.SQLStatement();
stmt.sqlConnection = conn;
stmt.text = "select value from config where key = :key";
stmt.parameters[":key"] = "foo";
stmt.addEventListener(air.SQLEvent.RESULT, function(){
  var fooValue = stmt.getResults().data[0];
  doStuffWithFoo...
});
stmt.execute();

Which makes me throw up in my mouth a little bit. I want to do something like this:


var fooValue = getConfig("foo");
doStuffWithFoo...

But that damned async call just keeps getting in the way.

Adobe hasn't committed to building this yet "because of the development effort it would require". My thoughts on that can be summed up in my previous post: "Programmers are expensive, CPUs are cheap" does not justify rapid development of slow code.

So, I wrote some convoluted code, scream "fuck this shit!" a couple of time, and wrote a little utility to provide a synchronous API - the Big Dumb Javascript AIR Configuration. To install, include Configuration.js:


<script src="Configuration.js"></script>

You then have to initialized the configuration system.


BigDumbDev.Configuration.init( function(){ air.trace('configuration ready'); } );

Reading and writing configs goes like this:


BigDumbDev.Configuration.getConfig('key');

BigDumbDev.Configuration.setConfig('key', 'value');

BigDumbDev.Configuration.removeConfig('key');

Sets and removes are immediately available, so you can do this:


BigDumbDev.Configuration.setConfig('foo','bar');
var foo = BigDumbDev.Configuration.getConfig('foo');
// foo is bar

You can see all the details in the source code. There is no magic - it still does the DB calls asynchronously. I cache the config values and read from the cache. Update change the cache and then kick of the async call to update the database.

You can download a sample AIR app that utilizes the system.

Dynamic image resizing

noreply@blogger.com (Steve) — Wed, 22 Aug 2007 13:18:00 +0000

I found this image resizing software on wonko this morning. That's pretty awesome. I wonder how long before I can use that with image magick...

Web development and the iPhone revisited

noreply@blogger.com (Steve) — Tue, 14 Aug 2007 15:29:00 +0000

I read a great post over at Ajax Performance defending AJAX as the iPhone development environment. This reminded me of my own take during the iPhone brouhaha, and I decided I had a little more to say.

Web development is has come a long way, but building a local app still has a lot of advantages. But, hey, when the first cars came out, horses were still a lot better. Apple didn't decide on AJAX because you can build cooler apps - they decided on it because it is the future, it is where the talent goes, and because the horse business hasn't done much for Microsoft the last decade. Google has managed to become the most valuable brand in the world without an OS and a native API.

Apple is obviously committed to this - they were willing to pay the price of not bothering with an native API. Time spent with a Cocoa iPhone is time not spent making the web better.

Build a better skimmer - part 2

noreply@blogger.com (Steve) — Mon, 13 Aug 2007 03:42:00 +0000

We saw in part 1 that we can build a more efficient skimming implementation by using a "film strip" image instead of a bunch of single images. For my example, I built the filmstrip by hand - it sucked. So, I whipped up a quick ruby script for creating a filmstrip of all the jpg's in a directory. If you don't already have RMagick installed, you can find instructions for installing it on the RMagick Homepage.

The script first crops the images to 160x160, then creates a vertical strip using RMagick's montage functionality.


require 'rubygems'
require 'RMagick'

files = Dir['*.jpg']
imageList = Magick::ImageList.new
numImages = 0
files.each do |file|
  unless file == 'filmStrip.jpg'
    puts "adding #{file}"
    img = Magick::Image.read(file)[0]
    img.crop_resized!(160,160)
    imageList << img
    numImages = numImages + 1
  end
end  

filmStrip = imageList.montage do
  self.geometry = "160x160+0+0"
  self.tile = "1x#{numImages}"
end
  
filmStrip.write('filmStrip.jpg')

Build a better gallery skimmer - part 1

noreply@blogger.com (Steve) — Sat, 11 Aug 2007 04:04:00 +0000

Apple's web developers could do better. This is the first entry in a big dumb effort to implement a faster and more efficient version of Apple's new skimming functionality than their current .mac gallery implementation.

You have probably seen Apple's new gallery preview skimming functionality. This is really cool. Surprisingly, though, the implementation is rather pedestrian. 15 seconds with firebug and it's clear - Apple sure doesn't care about doing this efficiently. Maybe they saved a few weeks developing this, but that demo site takes almost 1 minute to load - on my PowerBook G4 over DSL. But, if they did care about speeding it up and just ran out of time, wouldn't they have at least stripped all the whitespace and comments out of their javascript? Here are the last 128 lines from the main gallery.js:


/*

require('core');

Gallery.WebWidgetPanel = Mac.FormView.extend({
 isPanel: true,
 outlets: ["widgetCode", "photo", "reflection", "flash", "lTitle", 'lInstructionalText', 'lCopySnippetLink', 'lDoneButton'],
 widgetCode: ".widgetCode?",
 widgetTag: "",

 lTitle : Mac.LabelView.extend({localize:true}).outletFor(".lTitle?"),
 lInstructionalText : Mac.LabelView.extend({localize:true}).outletFor(".lInstructionalText?"),
 lCopySnippetLink : Mac.LabelView.extend({localize:true}).outletFor(".lCopySnippetLink?"),
 lDoneButton : Mac.LabelView.extend({
 localize:true,
 toolTip: "_VisitorExperience.AlbumOptions.WebWidget.Done.Button.Tooltip"
 }).outletFor(".lDoneButton?"),


 flash: ".flash?",

 getSmallest: function() {
 if (Gallery.albumController.get("videoSmall"))
 {
 return Gallery.albumController.get("videoSmall");
 }
 else
 if (Gallery.albumController.get("videoMedium"))
 {
 return Gallery.albumController.get("videoMedium");
 }
 else
 {
 return Gallery.albumController.get("videoLarge");
 }


 },

 generateData: function ()
 {

 if(Gallery.detailView().isVideo && Gallery.detailView().showOnIndex) {
 var height= Gallery.albumController.get("thumbImageHeight") + 16;
 var width = 320;
 var noScript = false;
 var widgetID = 'galleryWidget_' + Math.floor(Math.random() * 100000);
 var widgetAlbumTitle = Gallery.albumController.get("title");
 var widgetAlbumURL = Gallery.albumController.get("url");
 var widgetPosterImg = Gallery.albumController.get("medium");
 var widgetMovieURL = this.getSmallest();
 var styleTxt ="<style type=\"text/css\" media=\"screen\">.widget_header a { color: white ! important; display: block; text-align: center; font-size: 11px ! important; font-family: \"Helvetica Neue\", helvetica; text-decoration:none ! important; background:transparent url('http://gallery.mac.com/g/flash/gall_link_arrow.png') no-repeat scroll top right; padding-top: 3px; padding-bottom: 0px; padding-right: 16px; margin-right: 0px; height: 12px; padding-left: 5px; text-overflow: ellipsis; overflow: hidden; } .widget_header:hover a { text-decoration: underline ! important; color: white; background-image: url('http://gallery.mac.com/g/flash/gall_link_arrow_on.png'); } .widget_header { overflow: hidden; text-overflow: ellipsis; background: black url('http://gallery.mac.com/g/flash/gallery_widget_bg.png') repeat-x scroll top center; height: 20px; width: 100%; display: block; top: 0px; z-index: 4; cursor: pointer; } .widget_header a{ } .movie_div { display:block; z-index: 1; position: absolute; top: 20px; left: 0px; cursor: pointer; background-color: #000; } .movie_play_badge { width: 40px; height: 30px; position: absolute; left: 50%; margin-left: -20px; display: block; top: 50%; margin-top: -23px; background: transparent url('http://gallery.mac.com/g/flash/movie_play_bg.png') no-repeat top center; filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='http://gallery.mac.com/g/flash/movie_play_bg.png'); } .qt_ctrls { background: transparent url('http://gallery.mac.com/g/flash/qt_control_left.gif') no-repeat top left; height: 16px; text-align: right; display:block; margin: 0px; }</style>";

 var htmlTxt = '<div id=\"'+ widgetID+ '\" class=\"shared_movie\" style=\"text-align: center; width: ' + width + 'px; display:block; height: '+ (height + 22) + 'px; position: relative;\"><div class=\"widget_header\"><img src=\"http://gallery.mac.com/g/flash/gallery_logo.png\" width=\"21\" height=\"19\" alt=\".Mac Gallery\" style=\"float: left\" /><a title=\"' + widgetAlbumTitle + '\" href=\"'+ widgetAlbumURL + '\" target=\"_blank\">' + widgetAlbumTitle + '</a></div><div id=\"movieDiv\" class=\"movie_div\" ><a id=\"movieLink\" class=\"movie_link\" href=\"'+ widgetAlbumURL + '/' + widgetMovieURL + '\" target=\"_blank\"><img id=\"playBadge\" class=\"movie_play_badge\" src=\"http://gallery.mac.com/g/flash/movie_play_badge.png\" border=\"0\" width=\"40\" height=\"30\" alt=\"Play Movie\" /><img class=\"movie_poster\" id=\"moviePoster\" src=\"' + widgetPosterImg + '" width=\"320\" alt=\"\" border=\"0\" style=\"padding: 0px; margin: 0px\"/></a><div class=\"qt_ctrls\" id=\"qtCtrls\"><img src=\"http://gallery.mac.com/g/flash/qt_ctrl_right.gif\" width=\"57\" height=\"16\" alt=\"\" ></div></div></div>';


 var scriptTxt = "<script src=\"http://gallery.mac.com/g/flash/gallery_moviewidget.js\" type=\"text/javascript\" charset=\"utf-8\"></script><script type=\"text/javascript\" charset=\"utf-8\"> initWidget('"+ widgetAlbumURL +"','" + widgetMovieURL + "', 320, "+ height +", '"+ widgetID +"', true);</script>";

 var source = Gallery.albumController.get("path");

 this.flash.innerHTML = styleTxt + htmlTxt;

 this.widgetTag = styleTxt + htmlTxt + scriptTxt;
 this.widgetCode.value = this.widgetTag;

 var links = this.flash.getElementsByTagName('a');
 for (i=0; i<links.length; i++){
 links[i].removeAttribute('href');
 links[i].setStyle({cursor: 'default'});
 }

 } else {
 this.widgetTag = this.createSnippetCode();
 this.flash.innerHTML = this.createSnippetCode(true);
 this.widgetCode.value = this.createSnippetCode();
 }
 },

 createSnippetCode: function(previewBool) {
 var height = 260;
 var width = 320;
 var source = Gallery.albumController.get("path");
 if (previewBool) {
 previewTxt = 'preview=true&';
 } else {
 previewTxt = '';
 }
 var flashvars = previewTxt + 'feed=' + source + '?webdav-method=truthget&depth=infinity&feedfmt=atom&widgetWidth=' + width + '&widgetHeight=' + height;
 var widgetTag;
 widgetTag = '<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" width="'+width+'" height="'+height+'" id="photowidget" align="middle">';
 widgetTag += '<param name="allowScriptAccess" value="always" />';
 widgetTag += '<param name="movie" value="http://' + HOST + '/g/flash/photowidget.swf?def" />';
 widgetTag += '<param name="quality" value="high" />';
 widgetTag += '<param name="bgcolor" value="#000000" />';
 widgetTag += '<param name="wmode" value="opaque" />';
 widgetTag += '<param name="flashVars" value="' + flashvars + '" />';
 widgetTag += '<embed src="http://' + HOST + '/g/flash/photowidget.swf?abab" quality="high" bgcolor="#000000" width="' + width + '" height="' + height + '" wmode="opaque" name="photowidget" align="middle" allowScriptAccess="always" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" flashVars="' + flashvars + '" />';
 widgetTag += '</object>';
 return widgetTag;



 },

 copyToClipboard: function()
 {
 var flashcopier = 'flashcopier';
 if(!document.getElementById(flashcopier)) {
 var divholder = document.createElement('div');
 divholder.id = flashcopier;
 document.body.appendChild(divholder);
 }
 document.getElementById(flashcopier).innerHTML = '';
 var divinfo = '<embed src="/g/flash/_clipboard.swf" FlashVars="clipboard='+escape(this.widgetTag)+'" width="0" height="0" type="application/x-shockwave-flash"></embed>';
 document.getElementById(flashcopier).innerHTML = divinfo;
 new Effect.Highlight(this.widgetCode, {duration: .5, startcolor: "#70b0ff", endcolor: "#ffffff" });
 },

 commitForm: function() {
 this.set("isVisible", false);
 this.style.display = '';
 }

});

*/

That's right, it's one big comment!

Next up, images. It requests a lot of them. A LOT of them. Here is a screenshot from firebug:

That's right, 137 images. Most of these (let's say 100) are 160x160 images for making the skim gallery effect. Looking into the gallery code, the image is swapped by changing the src on an image. This approach has some drawbacks:

You're eating your net latency once for each image (divided by ~4, as the browser will request more than one at a time). Even if you're latency is only 100ms, you've got 100 images / 4 threads * 100ms = 2500ms. So, two and a half seconds eaten up in overhead. This gets worse the farther away you are from the server (light is only so fast, after all).

You can do better than changing the source

A common web developer tool is to use one bigger image as a background to a smaller element and shift the position of the background to achieve some effect. Example: rounded box borders. We can use this here. Instead of 20 images for each gallery, create one image per gallery that's 160px x 3200px, then shift it to display whatever image we want. So, for 5 galleries, you're downloading 5 images instead of 100. This will cut out a lot of latency.

But is it faster? Well, how about an example. I took 5 gallery images and constructed a film strip image. I built a test page/script - same 5 image - one method uses the filmstrip and background offset, the other uses an image src.

Here is the example. The top image uses the film strip approach. The bottom uses Apple's mechinism.

I used firebug's profiler to compare the performance:

big dumb dev - ~~.23ms~~.41ms average
apple - 2.1ms average

So, better than 4x improvement.

And this is where part 1 ends.

Next up - part 2 : how to build a film strip image.

Don't use "new Array()"

noreply@blogger.com (Steve) — Fri, 10 Aug 2007 19:49:00 +0000

Check out these two lines of code:


var foo = new Array();
var bar = [];

They do the same thing. So, save yourself 9 characters, and use [].

Dynamic table search/filter using a single input

noreply@blogger.com (Steve) — Fri, 10 Aug 2007 05:36:00 +0000

I've seen a lot of tables with column filters - each column has a filter. This is the Excel Model. My buddy Travis asked me if I had ever seen it done with one search box - the iTunes Model. Well, I haven't, and some time spent searching around didn't turn up anything. Honestly, I didn't search that hard, because I wanted to build it myself.

Here is the end product. Note, I have only tested this in Firefox and Safari. Update: tested in IE.

So, how do you build it?

First, the behavior:

The table to be searched has an arbitrary number of columns.

There is one text box for searching

Searching is dynamic - start typing and it starts filtering

When you search, each word you search for has to appear in at least one column in a row, or that row is hidden

All the words you search for don't have to appear in each column.

It's late, so I'll leave the rest of the details for now.

Crapcasts

noreply@blogger.com (Steve) — Thu, 02 Aug 2007 20:29:00 +0000

I stumbled onto a "great" screencast for preloading images in javascript today. These "crapcasts" are like puzzles in the Sunday paper - how many problems can you find? I'll leave that to the comments.

"Programmers are expensive, CPUs are cheap" does not justify rapid development of slow code

noreply@blogger.com (Steve) — Sat, 21 Jul 2007 19:41:00 +0000

If you've seen at least one argument between a Ruby on Rails Fanboy and an Enterprise Java Fundamentalist - you've heard something like this:

"RoR is 100 times slower than Java."
"Developers are expensive and CPU cycles are cheap. It's more important to save developer time than CPU time!"
"You aren't a real developer!!"
"At least I don't use tables!!!"

I am troubled by how pervasive this "I'm expensive, CPUs are cheap, I don't need to concern myself with performance" attitude has become. Comparing the relative costs of processing cycles vs. a developer is just silly.

Everyone knows, programmers are expensive and CPUs are cheap. This is obviously true. Developers like to point this out right before they tell you interpreted languages are better, or OR Mapping is better, or loose typing is better. Like stating the obvious will somehow qualify their point of view. Could anyone who likes to spout this please stop! You might as well say "Puppies are cute, roaches are ugly. Python is better than C++" or "Rocks are harder than pillows, pointers are evil".

First of all, it's not the development cost vs. operational costs. You have to consider how often the product is going to be operated. Think of it this way - "Automobile engineers cost 100k a year. Gas costs $3 a gallon. Engineers are way more expensive than gas. Who cares that it only gets 5MPG, or engineers were able to design the car twice as fast." If your product is successful, there should be many more man-hours of operation than there were development.

Secondly, CPU cycles are inconsequential when measuring the "cost" of slower code. How about the value of our customers' time waiting on all those extra CPU cycles? Think of it this way - "Engineers are expensive, electricity is cheap. It doesn't matter that our microwaves take twice as long to pop popcorn, we saved a lot of money developing them." People don't care about CPU cycles, but they do care deeply about their time. Imaging trying to use the argument on the other end: you are demoing your latest project to the big-wigs for the first time:

"And there you have it, what do you think."
"It feels slow."
"Don't worry, CPU cycles are cheap."

Please note: I am a big fan of interpreted languages and loose typing. These technologies are great and there are many situations where they are the most appropriate tools.

But, please, stop with the "Developers are expensive, cycles are cheap" bullshit. That's about as insightful as pointing out bananas are yellow and lettuce is green. The trade-off for slower code isn't just so-cheap-they're-free CPU cycles, it's your customers' TIME, and that is very expensive.

Javascript image anchor highlighting

noreply@blogger.com (Steve) — Sun, 15 Jul 2007 14:06:00 +0000

When using an image as an anchor, you very often want to make the image "highlight" when you hover over it. We've all seen this before - create a highlighted version of the image, add some javascript, and you get the effect. Here is an example:

Here is the markup:


<img src="http://brewer.designvigilante.com/files/imageHover/moveDown.png"
onmouseover="this.setAttribute('src','.../moveDown_over.png');"
onmouseout="this.setAttribute('src','.../moveDown.png');"
/>

This works for one image, but quickly become bothersome as you use more images. So, how to pull this out into a script that does it automatically for us? First thought - walk the DOM and get all the images, then add the event handlers to each one. This will work, but it is not optimal:

Walking the DOM can be expensive.

If you have a lot of images, you're adding a lot of event handlers. Each one takes up memory, and is also a potential memory leak if you delete the element later on without deleting the handlers.

If you add new images after the page loads, you'll have to remember to add the handlers to each.

We can avoid all of these problems by using event delegation. Event delegation allows us to attach one event handler to the document body. When an event is fired on a node, the event will bubble up DOM tree unless is is canceled. The event object contains the original target element, so we are able to write one function to handle image highlighting for the entire page. Here is what the event handler code should look like:


var handleMouseOver = function(e)
{
  e = e || window.event; // handle IE
  var el = e.target || e.srcElement; // e.target points to the element that was moused over.  srcElement is for IE
  // If the element is an image, and it's parent is an anchor
  if( el.tagName.toLowerCase() == "img" && el.parentNode.tagName.toLowerCase() == "a" )
  {
    // add _over to the name of the image.
    var src = el.getAttribute( "src" );
    var dot = src.indexOf('.');
    el.setAttribute( "src", src.substring( 0, dot ) + "_over" + src.substring( dot ) );
  }
};

// Mouse out is the same, except removing '_over' from the image
var handleMouseOut = function( e ){
  e = e || window.event;
  var el = e.target || e.srcElement;
  if( el.tagName.toLowerCase() == "img" && el.parentNode.tagName.toLowerCase() == "a" )
  {
    var src = el.getAttribute( "src" );
    el.setAttribute( "src", src.replace( "_over", "" ) );
  }
};

Note that you need to upload a highlighted version of the image for this to work.

So, how to bind these to the document body? We need o be concerned with handler collision - that is multiple handlers binding to the same event and overwriting each other. We will explore this more in a upcoming post, for now we'll just ignore this case.


var ImageAnchorHoverHighlighter=function(){
    var handleMouseOver = function(e)
    {
        e = e || window.event;
        var el = e.target || e.srcElement;
        if( el.tagName.toLowerCase() == "img" && el.parentNode.tagName.toLowerCase() == "a" )
        {
            var src = el.getAttribute( "src" );
            var dot = src.indexOf('.');
            el.setAttribute( "src", src.substring( 0, dot ) + "_over" + src.substring( dot ) );
        }
    };

    var handleMouseOut = function( e ){
        e = e || window.event;
        var el = e.target || e.srcElement;
        if( el.tagName.toLowerCase() == "img" && el.parentNode.tagName.toLowerCase() == "a" )
        {
            var src = el.getAttribute( "src" );
            el.setAttribute( "src", src.replace( "_over", "" ) );
        }
    };
    
    return {        
        init : function(){
            var b = document.body;
            document.onmouseover = handleMouseOver;
            document.onmouseout = handleMouseOut;
        }
    };
}();

Working example

Later on, I'll look at solving event collision, handling missing highlight image, labels, and background images.

When comments suck

noreply@blogger.com (Steve) — Thu, 12 Jul 2007 21:05:00 +0000

Here are some big dumb comments I stumbled upon today:


    con = getConnection(DB_POOL);           //get the database connection
    stmt = con.prepareStatement( query );   //prepare the statement
    rs = stmt.executeQuery();               //execute query

This code is Department of Redundancy Department Approved /*approved by the department of redundancy department*/

I love that the variable names are so short and unclear.

Steve Jobs gives the iPhinger to Mac developers

noreply@blogger.com (Steve) — Tue, 10 Jul 2007 13:51:00 +0000

Apple is waving a white flag. They are in the same API wars as Microsoft - it's the OS vs. the web, and Apple is changing sides. You see, Apple has "very sweet solution" for development on the iPhone - and it doesn't include core animations.

If you go cuckoo for Cocoa, faithfully attend the WWDC, and live by the covenants of the HIG, you would probably expect to have a leg up when it comes to "the next big thing" from Apple. Well, sorry, you lose - web apps will be the only 3rd party apps allowed on the iPhone. While you were standing in line outside an Apple store, web developers were able to build and launch the first 3rd party iPhone apps. Steve Jobs has repaid you for years of loyalty with a big, revolutionary, game-changing iPhinger.

It's a web app world.