Post-checks for Quality

 All Articles, Featured  1 Response »
Mar 252009
 

Just like the pre-checks, I also have post-checks to ensure quality. Here they are:

Layout

  • Margins/padding match comp
  • Liquid layout does not introduce gaps on resize
  • Capitalization matches comp
  • Text styling matches comp
  • Coloring matches comp
  • Text leading matches comp
  • Proportions and relative sizes match comp
  • Indentical or downlevel rendering in FF3, Safari, IE7, IE6
  • Navigation does not wrap in small liquid layout
  • Status bar features do not wrap in small liquid layout
  • Links do not wrap in small liquid layout
  • Headings/headers do not wrap in small liquid layout
  • No hard-coded duplicate CSS in views
  • CSS definition blocks are in external files
  • JS functions are included via external links

Wireup

  • All db operations incorporate user id or role in WHERE
  • No input params are trusted to directly control privileged operation
  • Front end is not trusted for security checks
  • JavaScript/Ajax and downlevel compatibility in FF3, Safari, IE7, IE6
  • FireBug console statements are not present or console() function is overridden in case it is not present
  • Database tables, pks, and fks follow mvc-style conventions
  • File uploads stored on disk with UUID referencing database table holding MIME type, original name, posting date, disk file name, and user ID if needed
  • Thumbnails generated dynamically
  • View helpers used where possible
  • Database FK’s indexed
  • No off-screen validation failures are possible
  • Transactions are used only if user’s current work can be restored to the screen upon transaction rollback
  • RESTful routing used
  • Route helpers used for all RESTful paths
  • No hard-coded <a> tags for site paths
  • All calculations in models – none in view or controller
  • Form helpers are used instead of <form> tag
    document.getElementById() is $()

  • Paths to root and core are constants and not hard coded
  • JS functions are included via external links
  • Raw $_REQUEST not used ($params) instead
  • No raw <input> fields
  • No magic values in code
  • File paths refactored and DRY’d into constants
  • TIMESTAMP type not used
  • DATETIME defaults to null if you want it to auto-populate
 Posted by Ben at 9:20 am  Tagged with: , , , ,

AJAX Frameworks: prototype, scr.iptaculo.us, jQuery, ExtJS

 All Articles  No Responses »
Dec 132008
 

‘git’, src=>’/wp-content/uploads/2008/12/ajax.jpg’) )?>

I know that AJAX isn’t the same as client-side scripting. I’m lumping them together here because you can’t have much of one without the other.

I’ve used most of the JS frameworks out there. They all share a similar strength. They make complex cross-browser scripting easy. With them, you can hook into events, set timers, perform animations and transitions, create popups, and in general make the browser window behave like a desktop app.

Every once in a while I see some useful AJAX applications. I like edit-in-place solutions if validation is handled properly. I like Lightbox for slideshows. I kind of like what Facebook did with the profile drag-and-drop layout management.

But so often, AJAX errors and validation are improperly handled ignored because, well, it’s hard to do right. How do you handle unpredictable errors with AJAX? Normally a framework or web server would return a generic error to the user. After all, the point is that something unpredictable happened. Your application didn’t anticipate it, so the underlying framework caught it and ended as gracefully as possible. But when that happens in AJAX, the user doesn’t see it. The AJAX operation looks like it completed, but you find out later that your data did not save.

AJAX is hard to debug, hard to fail with grace, and can sometimes get a little carried away to the point that it starts smelling like RIA. Too much animation, too much solving problems differently for its own sake.

Overall, I give AJAX a cautious thumbs up.

 Posted by Ben at 6:31 pm  Tagged with: , ,
© 2011 Ben Allfree :: Painless Programming