Alex Russell gave an interesting talk this morning on Building Responsive Web UIs with DHTML. My notes are below. Updated Aug 6, 12:38: I fixed the errors in the post pointed out by Alex Russell. BTW, he’s an excelllent speaker, if he ever gives a talk and you are able to go, I heartily recommend doing so.

Building Responsive Web UIs with DHTML

Alex Russell Namespaces

• you NOT are the only thing in the interpreter. deal
• do nothing in global namesapce
• declare the start of a namespace
• Object.prototype.foo = “”; is EVIL
• MyObject.prototype.foo = “”; is GOOD

Events: The old way

• clients treated a dumb renderers
• iframes make some partial content workable

Events the DHTML way

• multiple models
• onclick=“foo()”
• DOM2 style: attachEvent (or addEventListener for IE6)

Events the Dojo way

• dojo.event.connect()
• transparently handles multiple listeners
• makes browser differences go away
• builds in memory leak protection for IE
• connects normal functions too, not just DOM nodes
• dojo.event.connect(fooNode, “onclick”, doFoo);
• dojo.event.topic.subscribe(“/foo”, bar, “baz”);
• dojo.event.topic.publish(“/foo”, “arg1”, “arg2”);

AOP … Say What?

• Aspect oriented
• does name method interception
• advice types available past the default of after

I/O: the old way

• full page refreshes
• iframes provided some partial page refresh capability

I/O the DHTML way

• XMLHttp requests

  • sync or async
  • browser capability detection code
  • no file upload
  • usability problems

• iframes

  • ugly, gratuitous hacks
  • plays nice with forms

I/O the Dojo way

• common interface to multiple “transports”, incl. XMLHttp
• single response and multi response API (ready for LivePage, mod_pubsub, etc).

Packaging the old way

• tags
• absolute URLs
  • External CSS files and template systems

Packaging the DHTML way

• tags
• no dependency tracking
• no load ordering
• no transparent optimization

Packaging the Dojo way

• built in pkg system:

  • integrates and is transparent with the build system
  • yes, we make builds to optimize your code for you

• dependency satisfaction at runtime or build time

• partial builds can call source versions of this that aren’t baked in
• just use dojo.require()

Widget Reuse the old way

• you build modularized PHP or *SP
• CSS moved to external files
• behavioral code always copied
• JS potentially moved to libraries/external files
• No re-use previously available for DHTML

Widget Reuse the Dojo way

• build with HTML and CSS fragements
• amazingly fast to prototype
• look and feel can change w/o changing JS class
• automatic reuse:
  • previously everything had to have unique IDS that you managed
  • Dojo does that counting work for you

Demos

• Corkboard (from JotSpot)
• Turbo DbAdmin

Functional Testing

• LiveTest — testing the deployed application (part of the Neuvaux (sp?) project). Only in svn for neuvous (sp?)

Slides available here.

For the final session of the day I decided to take a lighter one (i.e. not programming intensive as my mind had been pickled in Ruby code throughout the day), so I attended Andy Lester’s Preventing Crisis: Project Estimation and Tracking That Works. My notes are below (along with links to the slides/velocity chart). Andy was introduced by Damian Conway (who was complimenting him on his practical sensible advice). Everyone hates crisis, problems and the stress that goes with them. This is how Andy and his team do project tracking — it works for them, it may not work for everyone. Will we make it? How we doing? 190 hours short in example (10 week project). Is it a crisis or readjustment — don’t realize that you’re screwed until just before the end. Find out how things are going, early on so they can be addressed early on. Goals: – accurate schedules (they make customers happy) – bad news early (surprise makes customers happy) – fun for you (otherwise, why bother?) Tools & Principles – honesty with everyone – changes & mistakes happen – tasks are either done or not (no more 90% done) – nothing is free (get across to customers and self) Assumptions: – you have version control – backups – bug tracking How to do projects – Get a project – some sort of written doc (even if you have to write it) – does it have all of the info you need to do the project? – How complete? It’s up to you (think leaflet, not phone book) – Nothing is set in stone – “signed off” on means “as best we know now” – changes will happen, don’t pretend they won’t – the requirements establish a baseline from which work can start – Do a swag – silly wild-assed guess (spend a day coming up with it, not weeks) – fast & cheap – not a commitment – estimate in days or weeks – figure out confidence – those responsible for the work OK the swag – Swag Example: 12 weeks – DB set up – 1 week – User Screen 1 – 3 weeks – User Screen 2 – 1 week – User Screen 3 – 2 weeks – Reports – 2 weeks – Admin screens – 2 weeks – Status web page – 1 week – Do a task list/estimate/schedule – start breaking up swag – outline form is fine, but not necessary – put them in chronological order – tasks may not be longer than 4 hours (½ day) Four hours??? – you can’t estimate accurately above 4 hours – distributes risk (estimates are usually off by 100% not 10%) – requires rocks to be turned over – You’re doing design as you go, so keep notes – Those responsible for the work OK the task list/schedule (otherwise the developers will resent mgmt, also serves as a sanity check/peer review on the task, in case something was missed) Task Breakdown Example – foo report – 4 days – bar report – 2 days – etc. Task Breakdown Further – Foo report – data input – 2 hrs – Foo report – data marshalling – 4 hrs – Foo report – web detail – 3 hrs – etc. “I might as well write the thing” – this is not programming! – the developer thinking about the tasks is more valuable As you write the code – plan for upcoming weeks – do one task and complete it – do the next task and complete it – don’t jump more than necessary (too much jumping around is bad because you want chunks of functionality completed in case you need to ship a subset of the product, i.e. less features, early). Planning for the week – assign tasks so each person knows what they are doing each day of the week. – try to assign less than 8 hours of estimated work per person per day Track progress – keep track of how many hours the task actually took – don’t check it off until it’s actually done – keep track of how long bug resolution takes as well – re-evaluate remaining tasks if completed tasks were inaccurate (i.e. they took twice as long). – velocity only counts those tasks which were completed Tracking the weeks – keep track of total points (hours) of work remaining (the Sophos guys call this “burn down”) – if missing tasks are discovered, it increases the total amount of work (moving the “finish line” out) and thus the work remaining won’t decrease as much – towards the end more bugs will pop-up and the team’s velocity will be impacted. – all tasks are binary (done/not done) – track points completed on a velocity chart – no points for rework (bug fixes and rework are buying on credit) – don’t bother going back and fixing the time estimate for completed tasks, but for future tasks you should re-evaluate the time estimates (maybe those tasks need to be broken down into smaller tasks). We want to know about these types of issues sooner, rather than later. You can’t be a “little pregnant” – a task is done or not done – I’m done with that code, I just need to clean it up — you’re not done – I’m about 90% done with these tasks — you’re not done Adjust – reorder tasks if necessary – re-estimate and break up tasks if you need to Handle requests – Can do you X? Yes – How long will it take? I need a day to tell you – Can you just give me a ballpark? Yes, if I can take a day off of the project to estimate for you. A non-commital swag is ok here. Slides at Preventing Crisis: Project Estimation And Tracking That Works Related excel chart: Velocity chart for Preventing Crisis

Jim Weirich gave an interesting presentation on dependency injection entitled, Dependency Injection: Vitally Important or Completely Irrelevant? Since the slides are available online and my wrist is beginning to bother me, I’ll sum it up quickly. Is dependency injection important in a dynamically typed language? No.

Why the lucky stiff dazzled the audience with his performance art piece entitled, A Starry Afternoon, a Sinking Symphony, and the Polo Champ Who Gave It All Up for No Reason Whatsoever. My mind was blown and my gut busted. O’Reilly should hold a Monday Night Extravaganza at next year’s OSCON and give the entire night to Why (and his band, The Thirsty Cups). My (very limited) notes are below. This was an incredible experience including about four different movies (two with shadow puppets — yay!) and two live performances by Why and the Thirsty Cups. First Why extolled the virtues of the future — such as the octagonal paper they were using (as seen on Battlestar Gallactica) — this octagonal paper has literally changed their lifes (when asked where one could purchase such fancy paper, Why simply replied, “The future”). After a storytelling session (movie with shadow puppets) and possibly a musical performance (sorry, so much happened my mind is a blur — I was too busy trying to capture it all on film to take accurate notes), Why noted the dearth of programming resources for children — claiming that the only books he could find at Amazon dated from the mid-80’s (over 20 years ago); unless he was doing the wrong search — when asked what “kids” are called now-a-days an audience member replied “gangsters” (or was that “gangstas”, it was difficult to tell) — a search for “gangster programming” turned up a single book on Amazon. After that it all become a blur with more movies and another musical performance. Snapshots from the (pre)-show at FOSCON are here: http://www.onestepback.org/articles/depinj/index.html Once I get access to a proper USB cable, I’ll post my photos to Flickr as well. Also, Why said that he would post torrents of the movies at his site: http://redhanded.hobix.com/ What I want to know is when we can purchase Why and the Thirsty Cups on iTunes …

Glenn Vanderburg presented on Metaprogramming Ruby. I thought it was quite interesting as I had only done this previously in ANSI Common Lisp. My notes from the talk are below.

Metaprogramming (MP)

• programming your programming
• change the way you program in your programming lang
• transform your general-purpose lang
• make it domain specific
• program ing a lang designed for the problem you’re solving

Lisp

• origination of metaprog

Ruby

• MP is rediscovered
• style and idioms are changing and adapting
• rails leverages mp heavily (to great effect)
• ruby is a natural for MP

Why?

• Dynamic and reflective
• everything is open to change
• blocks allow writing new control structs (add continuations to get fancy)
• Most declarations are executable statements
• only slightly less malleable than Lisp (no macros)
• a fantastic syntax
  • neutral and unobtrusive
  • enough to distinguish different kinds of constructs
  • not enough to complicate straightforward statements

Built-in Examples

• declaring object properties: attr_reader :id, :age attr_writer :name attr_accessor :color
• These are just methods from Module (not syntax)
• How are they written? Unfortunately, in C. Still instructive but doesn’t tell you how to do it in Ruby.

Mathieu Bouchard’s X11 Library

• Wrote a DSL which defined the X11 Protocol Spec in a way similar to the way in which the spec itself was written.

Styles Have Changed

• A DSL was created in similar fashion for the Java Debug Wire Protocol.
• executable protocol spec which could be printed from source

Dave Thomas’s Summer Project

• RubyConf 2002 “How I spent my summer vacation”
• Created a DSL which would build objects based on the contents of a DB or generate the DDL for the database or generate the graph code for an ER diagram.

How to think about metaprogramming

• Def new constructs for your programming lang
• Ok, but constructs to do what?
• Whatever your DSL needs to do.

Another way to think about it

• a new bag of tricks for eliminating duplication (and other smells) from your code
• two ways to go about it: write your app and extract (Rails), layout design first (ActionStep).

Conventional Constructs

• DSLs need: types, literals, declaration, expressions, operators, statements, control structs

Most DSLs also deal with things you don’t usually find in gp langs

• context-dependence
• commands and sentences
• units (unit conversion)
• large vocabularies ( sometimes unbounded)
• hierarchy

Contexts

• Establish a context for a set of statements:

  • constrain those statements to the context
  • multiple, concise operations on the context

• What’s a context? A scope.

Commands & Sentences

• multipart, complex statements or declarations

field(autoinc, :reg_id, pk)

• It’s just a method call (optional parens are handy for sentences
• First param is a method call: restricts the arguments to predefined alternatives (prevent errors)
• Second param is a symbol: restrict syntax to goo name-like strings
• Additional params are method calls:
  • options, constraints
  • methods return objects that encode constraints

Units

• general purpose langs deal with scalars
• most DSLs deal with quantities

Impl Units

• Classes representing quantities

  • don’t forget to support math
  • user operator overloading if it makes sense
  • may require mixed-based arithmetic (time certainly does)

• Next: natural expression

Large Vocab

• Roman numerals (Roman.CCXX, Roman.XLII)
• Jim Weirich’s XmlMarkup class (used in Rails):

How do you impl large vocabularies?

• override method_missing
• Be careful! Bugs lurk here. Sometimes method missing intercepts something that really is a name in an outer scope — it’s also hard to find bugs if you misspell a real method name.

Hierarchy

• XmlMarkup again (see slides)

How to implement?

• call from method_missing:

You could use instance_eval to avoid typing xm. before every call. But don’t. If you make a method call within the block and use instance_eval, the method is looked up in the wrong context and get a no such method error. Slides are available here.