BarCampLondon3 - Day 1

The time for another BarCampLondon3 has rolled around, and I was lucky enough to get a ticket. We all turned up at Google's swanky offices in Victoria knowing we would have a good time, but not quite realising what a great time we were in for.

The organisation went very smoothly, the wifi was rock solid, there was more food, beer and snacks than even a BarCamp-load of geeks could consume (well, apart from the beer - it's the first time Google's fridges have been emptied, oops!)

As usual with an unconference, it was all about the sessions folks decided to give, and we were treated to some really thought-provoking and fun discussions. It was a shame that out of the 100 attendees, about 30 chose not to present. So the schedule was a little light at times, but that's not always a bad thing - nice to catch your breath every now and then! Jeremy marked up the timetable for us all to refer to easily.

The first session I went to was Tom Morris - Scraping Sucks - where he was giving us more usable alternatives to scraping HTML, namely doing clever stuff with GRDDL. He says it's much easier that way. As usual, I nodded sagely at the time, and then a couple of hours later, wondered what it was all about. Tom is a great geek, but he's several steps ahead of me when it comes to brain-wracking abilities :-) He's put up a page of GRDDL Profiles here - which lets you look at (X)HTML and with an XSLT transform, spits out XML/RDF which can be used as you want.
[Tom gets stuck in to his presentation]

Norm's Law
This was an excellent presentation from Mark Norman Francis. He gave us some very good reasons for doing code his way - especially for fostering interoperability betweeen different members of the team, or yourself coming back to code at a later date. Some points included:

• Use spaces not tabs
• Code goes no further than col 77
• No-one ever died from using too much whitespace
• Separate operators and braces - more of a cognitive burden to parse squashed up code
• Always indent by 4 spaces ONLY
• Line up assignments of variables (equals sign in the same place etc)
• Line up data tables too (arrays or whatever)
• Space keys out from brackets $vote[ $value }++; etc
• Space keywords out not functions
• Vertical rhythm - break bits up with comments for each sub part - make a story out of it
• Respect left-to-right comprehension
• K&R bracketing - opening brace should be tied to RHS end of line, closing brace should be on a new line - aligned with the starting coment
• Don't cuddle and else!
• One statement per line - you can easily miss the ";" in the middle of the line separating the two commands
• Break lines before operators - EXCEPT in JavaScript or it won't work
• Ignore operator precidence - use brackets to make it more "English readable"
• Use single quotes where possible - ' in PHP will just be stuffed in, " will make PHP parse the contents looking for variables
• Factor out long expressions and use intermediate variables (with english-sensible names) to break up
• Always use x on regexpressions
• Don't use camelCase! unless you're in JavaScript
• Systems Hungarian is harmful, Apps Hungarian is too
• All short variable names are harmful
• Use grammatical variable names and function calls
• Optimise for humans first! Machines - throw more hardware at it - but you can't refactor comprehension
• HTML indents use 2 spaces not 4
• Write the whole document FIRST before you do any CSS etc
• Insert Microformat classes
• Always use single quotes in attributes
• Inline CSS means you've done it wrong
• If it only works in JS don't
• VALIDATE
• Start with base stylesheets - reset, fonts, layout
• Use Uppercase tags in HTML
• Keep z-index below 50

[Norm - I can haz 4 skreenz]

Next up was a session about new developments from the BBC's web team:

BBC APIs First Look
PIPs is the system to list all broadcasted stuff - telly and radio

• bbc.co.uk/programmes
• Gives a list of all current programmes - by genre or alphabetically
• Nice URLs which can have .yaml or .json can be added for the feed in that format
• bbc.co.uk/programmes/formats
• Pid is the 8-character id for each episode - taken from user experience tests and will always be constant (never change)
• JSON and YAML are the two formats currently supported - XML coming? - RDF ontology has been produced
• RSS feed is coming so you could subscribe to know when "every episode of Doctor Who" is on
• Data model - "programme" can be brand, series or episode - an episode can have multiple versions (signed, extended etc) which then have broadcast (tv) or ondemand (iPlayer) times
• Historical data back to May 2006
• Can filter out to network (tv or radio) eg Radio4
• Next release (API stuff) in New Year
• http://catalogue.bbc.co.uk/ - is historical data - grand plan is to have them merged

DIY User Research - Leisa Reichelt
Leisa gave us lots of good advice on how to carry out some DIY user research - her premise being that it doesn't have to take days and days and cost big bucks - and often talking to more than half a dozen victims volunteers gives you diminishing returns. Leisa's slides are already available at the Slideshare BarCampLondon3 group.

Building Lifestream with Yahoo! Pipes - Cristiano Betta
I didn't take many notes as I was listening as I was actually playing with a real Yahoo pipe of my own and trying to follow along with what Cristiano had to say. I've been meaning to use Pipes to create my own Lifestream for some time, but had a quick go before and things weren't coming out as I wanted. Cristiano has done a series of excellent blog posts to get you going, or you can watch Tom Morris' video of Cristiano's presentation. Or view Cristiano's own Lifestream.

10 Things You Should Do In Project Management But Probably Don't - Gareth Rushgrove
Gareth's top ten tips:

1. Use Source Control software
2. Validate markup - XML, RSS, Atom and JSON
3. CSS validation
4. Broken Links! check them thoroughly - W3C Link checker
5. Performance - do you have metrics for measuring the performance - YSlow is a Firebug enhancement, httperf - use uptime checker too such as Pingdom
6. Maintainable Javascript - JSLint gives you good tips
7. Carry out Unit Testing
8. Carry out Functional tests
9. Asset Compilation
10. Building Scripts
    

More at morethanseven.net

Learning jQuery - Simon Willison
Simon gave us a lightining half hour tour of the jQuery Javascript library with great examples and succinct slides - you can get them from Slideshare. I've been meaning to beef up my JavaScript skills, and getting to grips with jQuery sounds like a good place to start.

[Simon talks about jQuery's Ajax capabilities]

Ask Them Anything
For the final sessions of day one, Norm and friends held an Ask Us Anything panel - just a bit of silliness to round off the proceedings before dinner. The guys from the Londonbubble did a live stream of the session to their mogulus chatroom, and it all got a bit recursive when this was put up on the main screen behind the guys:

[Behind you!]

The chatroom folks even got to ask a question or two - and Ross got a marriage proposal from a lady named Picki which he had to graciously decline!

[Ross, Norm and Ryan answer the online questions]

And so to dinner... but that's for another post.

Flickr And Self-Referential Folksonomy

I've been thinking a lot about Flickr and tagging recently, having just had to bash a load of tags onto my BarCamp pictures.

Lots of my mates are members, and when we've got together for socials, we share the pictures via Flickr afterwards. Many tag the images by subject, or use something like Upcoming's machine tags: upcoming:event=138806, which refer to the relevent event tag, and can be used by Upcoming's API to display photos from that event (held on Flickr), in the event page on Upcoming. "Old hat", some of you may say.

The other thing that regularly happens is that folks tag pictures with people's names or nicknames. Thus, you can see all the photos of me on Flickr (which have been appropriately tagged), whether they be in my photostream or someone else's. But here's where we get the problems.

Some people have particular tags by which they would like to be known, as well as their normal names. Ben (74 results currently) is a case in point, who also goes by the nickname of Kapowaz (56 results, some of them the same). Mark Norman Francis (390 pics) (aka Norm! - 2,324, not all of them him) thinks he's King Of The Britons (122). Adding all these tags by hand every time gets very tedious.

Now Flickr is very good at letting you organise your pictures, by set, date of upload, geographical position, etc. Their drag and drop interface is easy enough to get your head round with a bit of practice.

So I was thinking, why not let each Flickr user asign their own tags to describe themselves. Then give the Organiser Panel the facility to set which Flickr users appear in the photo, and that user's tags then get applied automatically. As long as you know that a person in one of your pictures is a Flickr member, you ought to be able to drag their icon onto a picture to set up the tagging, even if they are not in your friends, family or contact lists (these could easily load by default in the appropriate new "choose Flickr member" panel):

[mockup of the "choose member in photo" facility, via the Organiser panel]

Or when you come cross an individual picture in your Flickrstream, you can currently add it to a group via one of the fuction buttons at the top. Similarly, you could have:

[mockup of the "add member in photo" facility, in the Flickrstream view]

I'm sure that would save some donkey work on everyone's part, and would be quite interesting to follow the reference tag trails around Flickr until you get dizzy.

Comments anyone?

BarCamp Day 1 - Evening Sessions

Mark Norman Francis on Don't Be Scared of Code Reviews

Norm explained that the purpose of a code review is not to criticise other people's code. The findings are not escalated, there is no formal output - just for folks involved. Except Security problems, which are tracked in Bugzilla. So why bother?

• Verification - adhere to internal standards.
• Training - informal education of expectations of new hires
• Collective wisdom - [you will be assimilated!] Experts pass on their knowledge.

They are looking for, in HTML - valid, semantic, accessible.
CSS - valid (hacks separated out), modular (hung off ONE id - means you can reuse code on another part of site without relying on cascade), cross-browser (graded browser support)
Javascript - unobtrusive (pull it out into separate files, still get to the content with JS off), optimised, cross-browser.

Don't care too much about programmed page weight - ads multiply page weight hugely anyway. Page weight is not very relevent to each user but is to Yahoo!, since so many hits could mean server overload.

Perl/PHP must be documented (in the code, externally), understandable, standardised

[Olé Norm!]

How do they work? Time taken doing them is minimised. Quiet time is set aside beforehand for people doing the reviewing, away from email, IM etc.
During review, items are explained by reviewer, while the coder keeps quiet. A mooderator takes notes for them both, which are tabled for later. Then follow-up - the lead developer confirms that the problems identified have been rectified before code goes live.

Me on Taking Better Pictures
I'll post the main contents of my presentation in later posts, but it seemed to be fairly well received, with about a dozen folks coming to listen.

Andy Mitchell & James McCarthy on "Free Schmee"
Andy and James were talking about APIs and using them in a modular fashion - why invent the wheel again when you could reuse another API to do certain tasks, such as user verification. They freely admitted they'd been penning their presentation hastily when they'd rather have been attending mine. But never mind, it was still an interesting few minutes!

[James and Andy argue about who's going to work the slides...]

Next was dinner: geeks + pizza + beer = culinary carnage. At least there was no washing up!

[Colin Schlüter surveys the carnage]

I stayed chat with Andy Mitchell and John Wilson for quite a while after dinner, but made it to the main auditorium , back end of Ask Us Anything panel. Someone rashly asked to see the panel dance!

[Norm! shakes his booty, watched by Simon, Steve, James and Aral]

Of course, it wasn't long before someone asked "when can we play Werewolf!" So, most reconvened to the restaurant area and three groups started. Not sure how many games were played altogether, but I think it was at least nine, with various permutations of people flitting from one circle to anther.

[a wolf in gnome's clothing, perhaps? Tom Coates ponders who he's going to bite next; James Wheare (Wolf??) and Cristiano Betta don't seem worried by his proximity!]

And so to bed, perchance to sleep, at 4am... fat chance - wished the floor wasn't so hard. Got up again 4 hours later to find most still comatose:

[geek dorm, aka conference room]

WSG London #2 - Microformats

The second London WSG meeting was all about Microformats, something I've been meaning to get to grips with for a while. What are they, and what are they good for? We had three Microformats "Ghosts" to help us understand more about them:

The Ghost of Microformats Past - Mark Norman Francis Esq of Ye Olde Yahoo! Corp. Norman gave us an overview of what Microformats are for, and why they have evolved:

• They should be there for humans first and machines second
  
• They are a way of encoding data
• Start simply, and re-use building blocks from other standards
• They are modular and embeddable
• And most importantly, they should attach extra (explicit) meaning to (implicit) content.

One of the first Microformats to evolve was the XFN standard in 2003. In its simplest form, this adds the "rel" tag to an anchor link (for a person's blog, say), where you can specify your relationship to them. See my other post on XFN for more info.

In 2004, the Creative Commons Licences took off, and the rel="licence" tag was added to the Microformats arsenal, eg: Creative Commons, <a href="http://creativecommons.org/licenses/by-nc-sa/2.5/" rel="licence">some rights reserved</a>

A lot of sites have invisible meta data hidden in their pages, but which might as well be invisible - visitors can't see it, and content authors often forget to update it. Norm's phrase was out of site/sight, out of mind. If a human can't see it, the metadata might as well not be there.

He briefly discussed why using XML namespaces was considered harmful. They are not well supported, even in modern browsers, and are antisocial (giving rise to the namespaces Tower of Babel).

But on 20th June 2005, http://microformats.org was unleashed on the web community. In 15 months, there has been a huge adoption of them, basically because they are simple, sensible and extensible. Most popular have been the hCard and hCal formats, along with the rel-licence, rel-tag and afforementioned XFN.

Out in the wild, heavyweights such as WordPress, Yahoo!, Google, Technorati have adopted microformats. With a very small tweak to one of their PHP templates, Yahoo Local have suddenly made 15m new hCards available on the web!

Next up was The Ghost of Microformats Present, Mr Jeremy Keith of Clearleft

Jeremy started out by reminding us that the (X)HTML specs do not have specific tags for semantic items such as contact details, relationships, events or reviews, and with the addition of a little bit of extra markup (mainly attributes to existing elements), we can explicitly specify these things in existing markup.

• Elemental Microformats
• the rel attribute:
  <link href="mystyle.css" rel="stylesheet" type="text/css" />
  In this case, the rel atribute defines the relationship of the linked resource to the current document (something that had never really occurred to me until the blindingly obvious was pointed out!) Similarly, <a rel="help" href="help.html">Help page</a> might explicitly define a help document for the page containing the link.
  <a rel="tag" href="http://en.wikipedia.org/Microformats">Microformats </a> tells us that the link is also a tag.
  He also mentioned rel-licence and XFN as above.
• the rev attribute:
  Less well known and trickier to get your hear round, the rev attribute defines the reverse relationship to "rel". So in the above example, on the help.html page, you might find a link thus: <a rev="help" href="checkout.html">the checkout page</a> which would say, the current page is the help resource for the checkout page.
• the vote-for/against attribute:
  You might include a link to someone else's blog, which expresses an opion (be it negative or positive) which you agree with. Then use:
  <a rel="vote-for" href="review.html">a damning critique</a>. The rel="vote-against" is of course, the opposite (you disagree with the opinion, whether it is positive or negative)
• Compound Microformats
  These add more than one attribute - usually classes - to elements. We mustn't forget that classes are for general purpose processing by user agents - NOT just for CSS - and should add extra semantic meaning to a document. He cited the hCard example for contact details on a blog:
  

  <address class="vcard">
  <a href="http://joebloggs.com/blog" class="url org">
  Joe's Blog</a> is the online home of
  <a href="mailto:me@jobloggs.com" class="email
  fn">Joe Bloggs</a>, a <span class="title">web
  developer</span> living and working in <span class="adr">
  <span class="locality">London</span>,
  <span class="country-name">England</span>
  </span>.
  </address>

Other things we need to consider are tools for creating and viewing Microformats. The hCard-O-Matic will give you a head start on writing an hCard for contact details, as will the hCal-O-Matic for events. Brian Suda's Microformat Cheat Sheet should also be a must if you're needing a quick reference guide.

On the discovery end of things, the Tails extension for Firefox is great for finding microformats on a page. For those folks not running Firefox, John Hicks has written a client-side stylesheet to highlight microformats, and he's updated it already. Tantek's microformats favelets let you copy hCard or hCal information into your address book or calendar. And Technorati have started to index microformats too!

Jeremy has kindly put his slides together as a PDF - but they're never as much fun as seeing them delivered "live" ;-)

Finally, a taste of things to come? The Ghost of Microformats Future, aka Drew McLellan , also of Yahoo! Europe, and a member of WaSP

Drew immediately got everyone's attention by asking, could using Microformats on your current site effectively replace your API? He demonstrated numerous instances where complex calls to APIs could be supplanted with the relevent microformat codes in the page, and pretty much showed us what they could become given enough widespread adoption. You cane see Drew's slides online, as I didn't have time to scribble all the fiddly bits of code he demonstrated.

One site which has no API but is littered with useful microformats is corkd.com. You can extract contact info or reviews at will, if you have the right plugin widgets.

Drew also drew our attention to some useful tools:

Brian Suda's X2V transformer - takes XHTML hCal/hCard and munches them into vCard/iCalendar files. Then there's Drew's new tools.microformatic.com site.

Questions and answers were welcomed by our Three Musketeers. Yahoo! memory sticks were given out as goodies to anyone who asked a question. One interesting question that stuck in my mind was asking if there were any microformats for mobile? Jeremy quipped that they are smaller than that, and there's more information on picoformats at the microformats wiki.

A very long post; wrapping up I'll say we all enjoyed a beer with the other geeks in the pub afterwards! Thanks to Stuart for organising the meet. He's already put up the podcast feed from the event. I'm looking forward to the next one, whenever that comes round.