Wednesday, November 10, 2010
Elk burger: this is made of win. And elk.
Session 1 - Keynote - Mission Critical Agility - Jeff Norris
The definition of mission criticality is when everything is on the line. For Jeff at NASA this may be the fate of a spacecraft; for more run-of-the-mill programmers it may be keeping a customer, preserving the life of the company, or keeping your own job. this makes it no less mission-critical.
Taking examples from sources as disparate as Alexander Graham Bell to the 1969 moon landings, Jeff outlined key elements of success in agility.
A key factor of agility is vision: the ability to see what's possible even when it isn't on the well-trodden path. Vision normally involves a lot of risk.
Though commitment seems a virtue, it can be best to remain as uncommitted as possible for as long as possible. Agile methodologies can allow you to remain flexible until remarkably late in the project lifecycle: by developing only as little as is necessary for each iteration of development, hard commitments to certain technologies or avenues can be postponed until absolutely necessary. Early commitment to a single decision is the antithesis of agility.
Session 2 - Deep Dive Into HTML5 - Giorgio Sardo
HTML5 is undoubtedly going to change the way we develop for the web, so although we won't be able to count on all our users having a browser that supports it for quite some time yet, it's critical for us to ensure we're right on top of it from the outset.
Giorgio's a Microsoft evangelist, and it's encouraging to see Microsoft on board with web standards.
Even though the HTML5 spec isn't totally complete yet, it's already becoming supported by some browsers - or at least the parts that are stably defined.
HTML makes for much cleaner markup. The DOCTYPE tag can be stripped right down to just <!DOCTYPE html>. It's no longer necessary even to have separate <head> and <body> elements (though they can still be used if you find it helps with clarity).
HTML5 adds a bunch of new tags that though they don't render any differently to <div>s, can help with the semantics of the page, which in turn helps with accessibility.
The new <video> tag makes embedding video a whole lot easier. The only required attribute is src. Defining the video file to display is literally all you need to do to put a video on your page. There are plenty of other attributes though, such as the image to show before playback begins or if it plays automatically. You can alter the playback speed of the video. You can specify numerous <source> child tags to offer various source files in different formats, in case the client's browser doesn't support the codec of your original file. The browser will play the first <source> that it can support. For fallback, you can specify an <object> tag for Flash or Silverlight after the last <source> tag: a browser that doesn't recognise <video> or <source> will ignore those tags but still pick up on the <object> tag (or some static apology that the user can't see the video). Adding an onerror attribute to the last <source> tag ensures that HTML5-enabled browsers will also use the <object> if none of the video sources are supported. Disappointingly there's no fullscreen mode, for security reasons. All attributes are accessible and alterable via javascript, including the position of the video playback. It's also possible in javascript to detect whether or not the browser supports the <video> tag at all, or if it supports certain video codecs (though the HTML5 spec says these functions return such values as "maybe" or "probably").
The <canvas> tag is another major addition to HTML. This allows you to draw vector graphics on the page. <canvas> support can easily be detected in javascript. The canvas.toDataUrl method can be used to export the content of the canvas to a single static image. It's important to ensure the canvas has loaded before you attempt to draw on it dynamically in javascript: draw instructions made before that will be ignored. For animations you have access to the refresh frame rate of the browser. These vary between browsers and how busy the machine is, so time-based animations are generally the better way to go (though also syncing with the browser refresh makes for smooth animations with less CPU overhead). You can also draw videos on the canvas, and add matrix transformations to how the video is displayed.
HTML5 supports svg both as inline <svg> tags in the browser, and also as a source file for an image. This means you can use svg graphics for background images, etc., resulting in much lower bandwidth than you would have using a large jpeg image. SVG images can also be created dynamically in javascript and then serialized and used as source to image tags.
We touched briefly on some new features of CSS3. An interesting one was the ability to define different styles based on the size of a screen - enabling you to swap image when the browser is small, or changing the layout altogether for mobile browsers.
Session 3 - HTML5 APIs - Robert Nyman
We recapped some features of video from the previous session. Another nice feature that the BBC are experimenting with is the implementation of subtitles. These can be held in <div>s on the page (and are thus indexable by search engines; then they are shown accordingly in javascript by polling the playback position of the video.
The Raphael Javascript library is a handy tool that makes building SVG graphics dynamically a whole lot easier.
There's a tension between using SVG or canvas as on the surface they offer similar functionality. The key difference is that SVG is always vector graphics whilst canvas is always bitmap-based. SVG is often more appropriate for generating dynamic images, whilst canvas is faster and more responsive for animations and games.
Web storage goes way beyond the capabilities of cookies. Cookies are extremely limited on size (around 4KB), whilst web storage give you 5-10MB, depending on the browser. The two types are sessionstorage that disappears when the browser is closed, and localstorage.that persists between sessions. These work as key-value pairs of strings, but JSON is a handy way of serialising objects.
There's currently a fight between WebSQL and IndexedDB. WebSQL is backed by Apple, so will probably be in Safari only. IndexedDB will probably be available in all other browsers (and hopefully in Safari too).
The Worker javascript object allows multithreading. It's initialised with a javascript file and can be communicated with from the main UI thread.
New javascript property navigation.online is available to check if the browser is currently online, allowing you to alter the behaviour of your web application accordingly.
There's a drag and drop module in the HTML5 specification, but it looks like it's not going too well. If they can get it sorted out, it could be pretty useful - elements can be marked as draggable or as drop targets by use of attributes. It'll be interesting to see if and how this will be implemented on touch screen devices where a drag action needs to be distinguished from a scroll - parts of flickr are already unusable on my phone.
The drag and drop API can be combined with the file API that allows you to drag files from the client file system to the browser, and provide you with metadata about the file as well as access to the byte contents of the file. This can be inspected in javascript, and then the file contents posted to the server asynchronously. Streamed upload, multipart upload and upload progress are all available in HTML5.
The window.history object allows you to push URLs into the browser history.
Data push from the server to the browser can now be achieved with the WebSocket object. Connections can be specifically opened and closed in javascript, and events are raised when data is received from the server. web-socket-js and SocketIO allow similar functionality in non-HTML5 browsers, if you need backwards compatibility.
More at http://robertnyman.com/html5
Session 4 - Clarity Means Completion: The Psychology of Kanban - Jim Benson
Existential overhead - the things that stress your team out: all the things that take up brain space and prevent you from working. We find we get this when there's a lot of work backed up that needs doing, or that is work is progress. Being able to push things to a place called "done" frees up space in your brain to focus on the things you should be working on now. Typically developers love to start new things and often don't finish them and flush them from their minds. Kanban keeps the loop tight, ensuring you're only thinking about the things that matter right now.
Flow- being able to see the whole flow of work in the project. Though you know what you have to be caring about right now, all other tasks are visible, making it easy to push back on panic rush jobs: though you can still take them on, the fact that another task (that up till now was the most important task on the board) will be pushed down to lower priority.
Depersonalisation - The goal of everyone in kanban is to get a task off the right hand side of the board; not just to move it out of your column. It encourages co-operation between developers and testers, as developers can see when the test work queue is backing up. The fault probably isn't with the tester: with dev help they can most likely catch up with their workload. The whole team is focused on removing blockages.
Pattern recognition - Human brains (especially those in the IT industry) just love pattern matching. Kanban makes spotting problems and issues with your workflow a case of pattern matching: the visibility of the workflow leaves problems with nowhere to hide.
Learning styles - People with different learning styles tend to work in different ways: in the extreme, some will flit from the exciting part of one task to the exciting part of another; others will focus intently on one task until it's beyond perfect. Kanban keeps the balance: the goal is always to move tasks to "done" and never see them again.
Subjective well-being - It can be useful to flag tasks as being tasks you like and tasks you hate. In retrospectives, discussing what it is that makes tasks suck can lead you to realise what's causing pain in your overall processes and thus what it is you can do about it.
Session 5 - The Counterintuitive Web - Ian Robinson
This session wasn't quite what I expected: it turned out to be part of a series on RESTful practices that I wasn't all that interested in. Ah well, a few things were slightly interesting.
In a traditional web application or service oriented architecture, the server would keep track of the state of the interaction with the client - for example the position in the state machine that a customer has reached (requested order, ordered goods, paid, cancelled, etc).
In a RESTful application, we break the process into resources (quote, order, item) with verbs (GET, PUT, POST, DELETE), then specify operations (CreateQuote, SearchOrders, ReserveItem, etc) that are executed on the server in response to these verbs. Each resource then maintains its own mini state machine.
For an application to be able to evolve, we need at least one degree of freedom in our architecture: either we can continually add new verbs (as we would in an SOA), or new resources (as we would in a RESTful application.
Session 6 - Introduction to Core Animation - Marcus Zarra
Core Animation is one of the core technologies for iPhone and iPad development. It allows for animating 2D planes (or layers) in 3D space. It almost (but not quite) achieves the same as OpenGL. For most animation requirements, however, it performs slightly better than you could manage using raw OpenGL yourself.
It supports basic animation (to change a value from A to B, and keyframe animation to allow for many points which are animated between
The following can be animated: opacity, colour (including alpha), size and position. You can also animate matrix transforms. The API allows easier access to matrix transforms by exposing methods to animate rotation, translation and scaling on any axis.
Animation is best used to indicate user interaction, to give feedback to the user (for example to let them know something can be interacted with). It's also handy for simpler games. It's also very useful for highlighting alerts.
Several animations are provided for free, such as flipping the screen around on the y-axis, sliding on screen on top of another, etc. Custom animations can be created as well.
Unless you specify otherwise, the built-in animations take 250ms - long enough for the user to notice, but without them feeling like they're being held up at all.
Animations can be expensive, particularly if you're animating complex structures, or if you have layers with alpha transparency. The key is to measure performance with instrumentation rather than judging it by eye. Sometimes when you have bad performance you just have to experiment by removing features one by one to see what's actually causing the performance hit. Rounded corners, for example, are surprisingly heavy-duty.
Core Animation does most of its hard work (preparing the animation and working through the maths) on a background thread - only the actual drawing takes place on the UI thread. In later versions of iOS, even some of the drawing takes place on the background thread.
Session 7 - CSS3: Now and the Future - Jonathan Snook
The CSS3 spec is at the Candidate Recommendation stage, where it's unlikely to change much but isn't actually finalised yet. However, many browsers already support many of the features - often even features that aren't at the CR stage yet.
Some of the hotter new features are the new selectors (such as :nth-child), multiple backgrounds, border-radius, gradients, shadows, rgba colour definitions (allowing alpha on different part of an element such as the border and background), 2D and 3D transforms, transitions, multi-column support, and animations.
Safari, Firefox, Opera and IE9 support most of these features.
Multiple backgrounds look awesome and we've needed them for a long time. You get to specify as many as you like and they get layered one on top of each other. The unfortunate drawback is that there's no way to override just a single layer (for example in the rollover class for a button).
Many of the features now becoming available in CSS3 have been available for some time in various forms in older browsers. It makes the CSS pretty messy, having to include the correct CSS3 definition, along with the definitions for Mozilla, webkit and IE's proprietary legacy implementations.
http://caniuse.com is a handy resource to check which features are currently supported in various browsers.
http://www.modernizr.com detects browser support for various features and substitutes workarounds where they're not available.