The Big Dumb Developer

If you use the Cisco VPN client on Vista this, bookmark this:

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

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.

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.

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 :(

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.

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 .

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.