Archive for June, 2008

Going Slower to Go Faster

Saturday, June 21st, 2008

In Taking a Smoking Break… For Non-Smokers, Vlad Doleza makes a case for taking a 20–30 minute break every 90 minutes or so at work. The claimed benefits are:

  • You will be more relaxed
  • Your concentration will improve
  • You will accomplish more

I’ve been trying it for a week. I think I’m more productive in my work, but one thing is clear, I’m less tired at day’s end leaving energy for other things outside of work. So I’m certainly more productive at life.

Save & Cancel Buttons in AJAX Forms

Wednesday, June 18th, 2008

More than one button on a HTML form is possible (e.g. Save and Cancel). The details are not obvious, but there are tutorials: Using multiple submit buttons on a single form and Multiple Submit Buttons in HTML. The key is using the same name attribute for each button but different value attribute values. The server can sort them out by value.

On AJAX forms, this doesn’t work. The browser sends all value attributes. Several Websites I use do this so it is possible. Digging around in them and watching the requests and responses with Firebug reveals some interesting things. Many of the Cancel buttons are purely client-side! No server request or response.

I’ve found out enough to do what I want, but this article is hardly complete. For the buttons after the first, use a different URL. A GET request would do what I want, so whether a POST would send the form contents is left as an exercise for the reader.

To build a browser side Cancel button for in-line (AJAX or remote) edit:

  1. Give the content to be edited some enclosing tag with a unique ID, e.g. “task_123″. The server should change the style to “display: none“.
  2. Insert the edit form after the element with ID “task_123″. Give it a unique name, e.g., “form_task_123″. Firefox at least will let you open up multiple in-line edits.
  3. At the end of the form place tags like this:
    <input class="save" value="Save" name="commit" type="submit" />
    
    <input class="cancel" value="Cancel"
    
            onclick="Element.remove('form_task_123');
    
                  Element.show('task_123');"
    
            type="button"/>
  4. Enjoy

Hope this is sufficient detail, if not you can look at the details in my Ruby on Rails app TagFlow hosted at RubyForge. Look at the inline_edit and inline_update actions the tasks controller and the associated RJS templates.

Programming, Process, & Feedback

Monday, June 2nd, 2008

The original waterfall model of programming process had no feedback loops, i.e. “complete and correct” requirements were handed off to the architects who produced a “complete and correct” system architecture, etc. It quickly became obvious that the various documents were seldom completely “complete and correct” so some rework was required. But the various process “gurus” still make pronouncements like “complete and correct” is still doable and try to pretend that the various feedback loops wouldn’t be necessary if you would just do the process right. It’s pretty obvious that that emperor has no clothes.

Most of the agile processes elevate feedback to a first class part of the process. On-site customer or stakeholder representatives give feedback, unit tests give feedback, if pair programming is used, programmers give each other feedback, etc. Feedback is no longer reluctantly allowed in to accommodate imperfect programmers but is encouraged, built into the process, and pushed to as early as possible. Testing can begin as soon as there is executable code.