Warning: This is a live blog post. I’ll be typing as it happens. Expect typos, mistakes and my own distinctive interpretation of the night’s events.
Frances Berriman will be discussing testing, and group hugs.
Small team, with various issues.
3 people on the team. 2/3rds live in london.
Quite a lot for the three of them to do, but not a lot of face-to-face time.
Problem 1: Communicating what to make
Miscommunication is the source of most project woes. Issues arise when a specification has been misunderstood. Someone does work, but the response is, “That’s nice, but it’s not what I wanted.”
Need to communicate accurately over email.
The unwrap() method
People skim prose.
All communication of requirements is done in code in JSDoc.
Empty source files are created in their repository with JSDoc, then they commit them. Makes it easier to follow than email.
Locking themselves in a room and have a fight. Go through the docs line-by-line.
Everyone has to read it. Everyone has to understand it.
Bits get removed. Bits that aren’t really needed, so no one wastes time coding it.
Then someone goes away and codes it.
Because they are using JSDoc, they get free documentation.
Problem 2: Checking what we’ve made actually works
Unit testing. The first thing you should think about doing is turing examples from you docs into unit tests.
They use Qunit. setup and teardown are really useful, but don’t seem to be documented.
Sanity checking & code reviews
Notorious at the BBC. Some people may have cried.
Somebody stands over you shoulder and tells you what is wrong.
They make sure it doesn’t read like a W3C standard because nobody can read a W3C standards.
Also check punctuation and make sure it’s understandable by an external user.
We fall out, and there is no resolution.
But debate is good. No one holds a grudge.
Problem 3: checking what we’ve made is fast
How do we know what is we made is fast? We benchmark in Woosh.
Live demo of Woosh, comparing Glow to other libraries.
- Treat writing documentation like writing code
- There’s no such thing as too many unit tests
- Benchmark regularly if you want to go fast
Events left behind
Used Photoshop CS5 content fill to generate his notes.
Making an application work off of the keyboard is more complicated than you’d think it was.
We need to be abele to be able to track more than one event (polyphony).
Key actions. Key repeating – this differs between operating systems and depending on user settings.
Key actions are monophonic.
Mouse events are pretty well documented in the W3C DOM 2 specs.
What about keyboard events? No a lot.
What do the browsers do?
keypress – The exceptions in Internet Explorer and Webkit actually make more sense. Only keys that generate characters generate a keypress event. Exceptions are more random in Opera and Firefox.
Should keydown really repeat?
Is there a way we can normalise the event order?
The plan for for Glow 2:
- Event order is keydown, keypress, keyup
- keypress is the only event that repeats
- keypress always fires
- (missed it)
Problem with fixin keypress: it isn’t always fired. We need to fake a keypress event when needed. Need to decide this. And to do this, we need browser detection. 🙁
Keycodes on various television remotes aren’t the same. There’s no spec to tell them what the keycodes should be.
Opera doesn’t distinguish number pad number keys from other number keys, so this behaviour is repeated in Glow (lowest common denominator).
Great photo of the messy cupboard in the search to find an American keyboard.
Unfortunate closeup of a keyboard found in the messy cupboard.
keys x keyboards x browsers x operating systems = Archibald’s constant of misery
The good news: Erm, no good news, but there will be soon. DOM Level 3 Events covers keyboard events in detail (though the spec is volatile).
IE uses key instead of keyIdentifier and location instead of keyLocation.
- Keyboard events are awful
- They’re going to get less awful