Possum Death Spree!

Sick but funny! Get ready for Possum Death Spree! ... I particularly liked the they've been frozen in the permafrost ... now global warming has set them free and:

Dying cop:

They killed the dinosaurs?

Handcuffed scientist-guy

No, they killed half the dinosaurs; they made the other half watch!

@media AJAX 07 final thoughts

It was a great conference, with a good mix between "techy" and some "designy" stuff from some really world-leading presenters. Well done Patrick :-) If I can get the funding I'll be back for @media 2008.

(& my reason for the over-long, verbose summaries of the talks was to give some flavour of the conference to my students.)

@mediaAjax day 2.6: Wrap-up discussion panel

The final session of @mediAjax was a discussion panel, starring Brendan Eich [BE], Stuart Langridge [SL], Alex Russell [AR] and Douglas Crockford [DC], ably chaired by Jeremy Keith (so Patrick & Jeremy made up, which is nice) and it ran with JK posing questions submitted by the audience and moderating the discussion:

Mobile & JS:

[Nobody mentioned Cameron Moll-style mobile user-centred design.]

Not much impact other than [BE] report from Opera regarding eBay, use of eval for self-modifying code and its impact on battery life.

Libraries:

No consensus other than [SL] use what works with you/your team and use libraries to level the DOM playing field.

WCAG2 & JS?

Dojo and ARIA are interim measures.

Standardise libraries?

Not necessary but combine forces for a common voice.

Can JS ever be secure?

[DC] No, we need a secure dialect, but there are things we can do to help.

[BE] Things like mashups are the killer problem & there is no silver bullet.

[AR] Google Gears, "trust domain", Open Ajax Alliance.

[BE] Gears' "worker pools" excellent & might end up in Firefox.

[AR] Must remember that in life risks are mitigated not solved, only Internet gives the false impression that it’s 100% solvable. (Mentioned "Capability Models"? see "Confused deputy" by Norm Hardy.)

JS2 = Java?

[BE] No, JS2 class is for integrity not Java-like object model. JS2 is not fixed & they’d welcome feedback but class & receive/dispatch methods are needed.

[DC] Standpoint is don’t add syntax.

[AR] All of the toolkits do this stuff so JS2 should follow if it’s needed.

Is proprietary a hindrance? (Silverlight, Air, Flash, Gears?)

[AR] If the text on the wire is lost, lots of collateral benefits will be go (spidering etc.)

[BE] Tension! Proprietary gives better control but Open Source encourages competition, both benefits.

To be honest, the discussion panel was a bit disappointing and JK rounded it up with a bland "we've made progress from the WASP DOM Task Force days", but it was a tough conference to sum-up and there were obvious tensions between the panel-members.

I guess they needed my special question so it was a shame I'd not gotten around to asking it! Here it is: What skills do employers of web developers want in graduates? What should educational institutions teach for workers in the modern web? Comments welcome...

@mediaAjax day 2.5: JavaScript: The Good Parts

Douglas Crockford's title and opening remarks were complimentary to JS, emphasising that there are very good parts to the language, as evidenced by the range of users, from computer science graduates to cut'n'paste coders. JavaScript is succeeding in an environment where Java failed.

Good things include prototype inheritance, 1st class functions (lambda) and loose typing. Closures work because of lambdas and garbage collection and is the best thing in programming languages.

Bad things are:

• globals (particularly user-defined and overwritable)
• semicolon insertion
• typeof object==typeof array==typeof null!
• with/eval use of eval is a cry for help
• phony arrays (performance)
• type coercion (==)
• too many negatives (null, undefined, false, NaN) why? E.g. object[name]==null is commonly used but gives false +ve with 0, null, '' property values – must use object[name]===undefined.
• C heritage, optional braces + permitted empty statements.
• Use of IEEE floats whereby 0.1+0.2 !== 0.3
• Dense constructions like ++ and –-
• Switch/case fall-through
• new – forget it and assignments overwrite the constructor

These are mainly things that can have disastrous consequences from minor typos but oftentimes seem useful.

Advocated JSLint.com and the professional subset of JS that it permits but warned JSLint will hurt your feelings and unlearning is hard.

Style isn’t subjective, e.g.
return { ok: true } vs
return { ok :true }
;-insertion means the second returns null, ok is a label and produces no syntax error and the braces wrap an empty statement that does nothing but is permitted…

Douglas’ perspective is to make JS more like JS should be. Deprecate the worst features, don't break the syntax, keep it simple, keep it safe (a subtle LOTR reference ;-). Add JSON.stringify, JSON.parse, safe/restricted eval, add a "don’t enumerate" flag to objects, no experimental features (hard to remove), no radical changes & no new syntax. More languages: two small languages are better then one large language.

More security but that would break current JS syntax. JSLint "ad safe" mode c.f. Google Caja (Caja allows this; JSLint does not.)

(This is a long post as lots of it was using notation I'm familiar with, hence my notes were legible and concise, but personally I'm with the JS2 pack: I teach students who learn Java first so if I can use Java-like syntax, so much the better, but DC's arguments are worth paying attention to.)

@mediaAjax day 2.4: Dojo 1.0: great experiences for everyone

The enthusiasm of Alex Russell, the speaker for the fourth session of the second day of @mediaAjax, was apparent instantly -- he spoke almost continuously, rapidly and coherently for the full hour of his talk: quite an achievement! He opened by listing "Maslow's hierarchy of needs" and relating them to the web, but there was so much new information contained in this part of his talk that I couldn't take it all in. I did remember a few choice quotes, such as:

• The idea that we'll continue to limp along using Java is laughable given languages like Python, Ruby, Erlang
• Not caring that it's broken is our best weapon on the open web... if we had to care about everything that was broken we'd never get anything done.
• The HTML/JS/CSS stack is wickedly hard to learn (because of bugs and interactions -- the basic stuff was easy for basic sites in the 1990s).
• HTTP is one of the best things to happen to mankind … compound interest, penicillin, the wheel and HTTP! LOL!
• And the most important for understanding the rest of his talk was: Good semantics allow you to say what you mean and get what you want. (But at the moment we only have one or the other -- HTML/CSS are currently liabilities, e.g. menu, tree, video, column...)

As for Dojo, the mantra was "build with (dojo), not on", which I hope I remember correctly was meant to imply that there Dojo team want to work closely with developers, and developers, so is the talk it doesn't do what you want then ask!

Dojo's approach is obviously different from jQuery, not only because they supply widgets and are committed to accessibility (whereas jQuery is low level and leaves the consideration of accessibility to the developer), but also in action because they use custom attributes within the HTML markup. Alex gave as an example a simple lightbox widget that used something like the following markup:
<img src="img1.png" dojoType="dojox.image.lightbox" group="a" />
<img src="img1.png" dojoType="dojox.image.lightbox" group="a" />
which Dojo and converts into a lightbox slideshow.

Alex also emphasised their commitment to WAI ARIA "states and roles", their enthusiasm about HTML 5 and how they look forward to browsers implementing HTML 5 so that they can ditch all of the extra code that it would make redundant.

(It was a great talk but information-packed talk and I'm sure I've missed stuff...)

@mediaAjax day 2.3: Metaprogramming JavaScript

Dan Webb's talk turned out to be an explication of the JS language, notably the primitives, objects, functions and prototype inheritance. It was good to see those concepts explained in a clear fashion again but at the time I didn't get the link with metaprogramming which Dan defined as:

Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data...
(http://en.wikipedia.org/wiki/Metaprogramming)

which was a shame (it's the as their data bit I missed.) Actually, Dan did show examples of using class methods from Array with other array-like objects (notably arguments), building push methods in implementations that don't have them and a genuine "Meta" addEvent function that self-modified on the 1st call to avoid repeatedly checking for implementation features (namely IE vs DOM2 event model), so that seems to cover the metaprogramming aspect — guess I wasn't paying sufficient attention (or it's a classic example of how taking and writing-up notes can clarify things in your mind.) He finished with a book plug: "The Art and Science of JavaScript", soon to come from SitePoint. (Note to self: get a copy for the library!)

@mediaAjax day 2.2: Building Interactive Prototypes with jQuery

In day 2, session 2 of @mediaAjax, John Resig gave an excellent demonstration of the elegance and simple syntax of jQuery, so much so that I'm inspired to use it to replace/augment my teaching of the DOM next year. He said his slides would be available and that the jQuery site has lots of documentation and tutorials, so I'll not reproduce the example code here; suffice it to say that jQuery looks good, useful and relevant to what my students need to know

Some of the extra details he gave: jQuery's Ajax support allows 3rd party JSON and uses something like eval or a dynamic <script>. jQuery supports a document "ready" event that triggers before "onload" to allow the JS to manipulate the DOM before the user sees it. jQuery is extensible and also interacts well with Firebug (as John demoed) and leverages the DOM so that it also works with XML documents loaded e.g. through Ajax.

He finished with a geek tease, showing a JavaScript port of a visualisation tool ("processing") running on <canvas> with super-cool, interactive graphics -- tease/cool!

@mediaAjax day 2.1: JavaScript 2 and the Open Web

Brendan Eich's the father of JavaScript – – and opened the 2nd day of @mediaAjax. He started with some excellent geek movie/culture references (Star Wars, Lord of the Rings and Firefly!! Who could want more? Well, the audience apparently: Sadly hangovers were in evidence and these did not get the cheer they deserved — sorry, Brendan), followed-by general reasoning behind the need to extend JavaScript together with the info that JavaScript v1 arose out of 10 days work in May 1995 when Netscape rushed it to market (broken & out of his hands.) JavaScript is not going away (it's the most deployed & "fuzz tested" [?] programming language worldwide) and browsers need to evolve. All three of the following need to improve: security, APIs and language support. Things in motion already include Screaming Monkey, "rumours" of IE8, WHATWG HTML5, Opera/Safari/Mozilla runtimes and Google's Gears.

JavaScript 1 is too small in a bad way (few primitives means hard to optimise, lacking integrity features and has bolted-on security) and JS1 is taught too infrequently (too many "Java U." programmers [are we guilty of this?!], too few middle-road JS programmers).

Opinion:

• Users deserve optional typing (not tedious error-checking that people don't do anyway!) so that APIs can prove facts about arguments. Most JS on the web won't use typing and doesn't need it.
• Integrity: support static things const
• Namespaces
• Packages
• Compiled units
• Bug fixes (fix stuff ECMAScript v3 broke)
• Distributed extensibility -- the dream of Java that dies in 1997 -- Flash/Tamarin is already the most distributed VM.

Non-issues: Performance? DOM is the client-side problem; trace-based JIT can deliver similar speed improvements to static typing JIT/approach Silverlight C# speed. Other language? No need! JS2 learns from ActionScript, Python etc.

Integrity is a real issue: JS1 global scope can be overwritten (CSRF), ECMA specification is a mess, JS2 will make things immutable. JS1 objects too mutable, JS2 classes not to follow Java but to permit immutable/private/protected objects and properties (maybe call them fixtures?). JS1 allowed hijacking of constructors and vars, JS2 will have const and final. Structural types in JS2 will make type-checking easy and therefore much more likely to be done: evolutionary programming and gradual typing.

Finished with a geek-tease demo of <video>: SVG embeddable, planned for Opera/Mozilla, currently implementing Ogg Theora and Vorbis, maybe finalising on H.264 -- multiple videos playing simultaneously, audio from the element with focus, 2D/3D rotation in realtime ;-)

@mediaAjax day 1.6: Ajax at work -- a case study

ppk's been one of my favourite JS developers for years so I was excited to see he was scheduled to be the 6th speaker on the 1st day of @mediaAjax. His talk focused around a genealogy application he was writing using Ajax/XHR-methods. I really enjoyed the "case study" approach (it was also very polite of him to use British royalty as his data source on this day, the Queen's 60th wedding anniversary, seeing as we were within shouting distance of her celebrations in Westminster Abbey!) His discussion of the "X" in Ajax -- the data transfer specification, whether to use XML, JSON, HTML or CSV -- was very clear and the reasons for choosing XML ("social", i.e. associated with the project and its people) were well and entertainingly explained.

It became clear during Q&A that he really needs a database and/or SQL/PHP developer. If you read this, ppk, I'm willing to help out! Turning the "relational" XML data underlying family trees into a relational database would be a fun student project...

@mediaAjax day 1.5: Planning JavaScrip and AJax for large teams

Christian Heilmann's was the 5th talk on @mediAjax's first day and it was an excellent description of managing teams of developers, which we probably ought to be expounding to our students and some of which I'll be trying out ("code review" as assessment practice and "lightning talks" for Faculty dissemination seem like good ideas...) His list of bad assumptions is worth repeating here -- don't assume that:

• I don't need to tell anyone this, they must already know.
• Surely everyone knows this.
• This works now, we'll never need to change it.
• This hasn't worked in the past therefore it'll never work.
• This is a minor issue; no need to file a bug.
• Hack it now, we'll have time to fix it properly later.

Some other good (mis-remembered) quotes: A good developer is not necessarily good because he's talented or gifted. He's the guy who works well with others … and works for the next guy (the guy who takes over his code!) JS and Ajax are part of the development cycle, not add-ons. Web products are never finished.

Reasons/procedures for conducting code review:

• Identify problems and solutions.
• Training needs become obvious.
• Share knowledge.
• Identify reusable resources (then give team-members time to make them publishable.)
• Don't innovate during production (except at team level.)
• Ignore the "inner hacker", the "feature creeper".
• Promote team players.
• Optimise for production but keep code maintainable and understandable ("compile").
• Use libraries.
• se comments sensibly and meaningful variable/method names.

I liked his description of modern web developers as more "librarian" than "memory guy" -- like I tell my WebTech students: I don't expect you to remember all of this [CSS, JS, DOM stuff] but I do expect you to know where to look it up.

Overall he was the 2nd person to kind-of say that the "waterfall" development process was dead and that Agile/scrum was the way to go...

@mediaAjax day 1.4: How to destroy the web

A funny wake-up after lunch on day 1 of @mediaAjax, Stuart Langridge firmly tongue-in-cheek described ample ways to keep the web from becoming useful and in the hands of we, the web geeky-elite ;-), including sucking bandwidth by ignoring Yahoo's YSlow plugin style recommendations, discouraging the use of well-designed libraries & reinventing the cross-browser wheel, permitting cross-site request forgery by building web app's accepting requests like http://site/delete.php?id=54 (great for web spiders! Make sure you have a page listing all things to delete and links to each document's delete link!!) It was a genuine laugh with a serious side: The web is approaching some level of maturity so don't let a Microsoft-style FUD "fire and water" attack put us on the back foot.

@mediaAjax day 1.3: Real world accessibility for Ajax-enhanced web apps

Derek Featherstone is an entertaining speaker and I always enjoy his @media talks. The 3rd talk of @mediaAjax was no different but he touched only lightly on the Ajax accessibility question: he talked about taking Google Maps and replacing the naff <div onclick…> "buttons" with real buttons for his ironman site, demoed using DNS (everytime I see someone else use DNS I find out better ways of using it ... I'm such a novice!) His use of a hidden form field updated via JS to signal unobtrusive JS changes to a page in response to onfocus events that screenreaders don't otherwise pick up was good advice and it was great to see him emphasise semantic markup, unobtrusive JS approaches and accessibility, but I'd have liked a bit more Ajax-related stuff (I'm desperate to find ways of "fixing" the back button, for example.

@mediaAjax day 1.2: But I'm a bloody designer!

The second talk on the 1st day of @mediAjax was an entertaining talk from Mike Stenhouse about the upskilling necessary to be a good designer in a modern web development team and how Ajax makes it even more-so: Ajax means you're designing the user experience and need to know how that's going to interact with the server, which means you need to know some JavaScript, front-end and back-end code etc. He talked about experience using Agile and "scrum" development methodologies, pair development, which differs from "pair programming" in that the designer and developer work together on the design or the code, and the insights that enables. The most interesting bit from my pov was how neatly this ties-in with my interests in combining our "Web Development" field with Design (from a different Faculty) ... web designers and web developers are not such separate jobs these days.

@mediaAjax day 1.1: The State of Ajax

The State of Ajax

@mediaAjax opened with a fascinating comparison with the current state of Ajax wrt the state in 2006 according to Ajaxian (where the authors wanted better/faster JavaScript, offline support, framework consolidation, tools inc. debugging: Speed increases in Firefox and Safari were contrasted with no change from IE, and the tantalising suggestion of a JIT compiler from Adobe from Flash 9 (Tamarin?) and Screaming Monkey (a Mozilla plugin for IE?!) bears further investigation (and drooling...) JavaScript 2 (optional typing, object model, namespaces, packages etc) is the subject of a talk tomorrow but the Ajaxian guys described two political camps -- those who want improvement and change, and those who want stability. Offline JS? Google Gears and Adobe Air. Graphics? <canvas> and SVG are slow but Firefox and Opera have hints of OpenGL acceleration in the pipeline. As for frameworks (Dojo, YUI, Prototype, script.aculo.us, JQuery, Mochikit, ExtJS, GWT, DWR, …), despite Prototype and JQuery moving together the guys' recommendation was throw a dart at the wall to choose between them ;-) Tools? Firebug (yay!), IE dev. toolbar, Safari DOM Inspector.

Referring-to Ran Aroussi's Time Breakdown of Modern Web Design got a deserved LOL so I'm copying it here:

Then they talked about a few of the categories, mentioned WHATWG and HTML5 (where apparently Ian Hickson, also at Google, leveraged the Google search index to look for common class names etc -- this is potentially relevant to a PhD project I'm involved in supervising.) Interaction lag was mentioned (quoting Nielsen: 0.1s delay is noticeable, 1s interrupts workflow, longer wait is nasty) and the fact that Ajax is constrained by browsers' single thread model, which causes UI lag if compute-intensive/slow tasks are running (and Ajax encourages background tasks...) Google Gears adds "worker pool" threads to solve this and Caja for security.

Ajax on the desktop? Adobe AIR, Joyent Slingshot (for Rails), Mozilla Prism.

They finished by describing an encouraging trend, quoting Apple's British chief designer that the days of "functional", just-working app's is over, JS/web app's have matured so that users expect "sexy" design, quoting Donald Norman (author of Emotional Design): Attractive things work better.