Here we go again at Web Developer Conference New Zealand (WDCNZ) – tech talks for web devs! All the action is happening at the Michael Fowler Centre in Wellington with over 380 participants, well up on last year.
Your live bloggers today, thanks Xero dev team, are Tokes, Liam, Craig and Owen. That’s Owen Williams not Owen Evans the WDCNZ organiser, but thanks to the latter Owen for organising, along with Charlotte Hinton of course.
Jason Naylor from We Do Photography is official photographer. We’ll post some here with more ending up on Flickr. Video will be available on vimeo.
You can follow the conference on Twitter with hashtag #WDCNZ. Sponsor Strea.ma from the Hawkes Bay, will be presenting tweets, facebook posts and instagram pics as they happen on the big screen and the web using their exciting cloud software.
Let’s get in a mention of the rest of the sponsors – Xero, Heyday, 3Months, Github, Rackspace, Wellington City Council, TradeMe, LilRegie and Campaign Monitor – check out their details.
All the programme details and speaker information are on the WDCNZ website
Jump below for latest Live blog content
9.05am – 10.40am with Tokes
So we’re off – Owen Evans on stage in his element, celebrating the our third ever WDCNZ. Exciting!
Usual Wellington house keeping rules… earthquakes, what are the chances?
* Julia Grace, Tindie
Location Unplugged: Handling Geospatial data across the stack.
Julia is heading of engineering at Tindle, she’s got a background in distributed systems. Spent a lot of time at IBM Research (even stared in a commercial for them – she’s famous! Well her voice is…)
EVERYTHING will have location – your emails, pictures, github commits even. Will be just as important as the TimeStamp.
What?! Even your eggs will be geo-tagged. People, you really need to know where your eggs are laid (you just may not know it yet).
”As we enter the age of the “Internet of Things”, if your data is or has any location metadata, at some point you’ll make use of that data through, sorting or filtering or faceting.”
The code is coming folks…
Spark Core: Wi-Fi for Everything – you can add this thing to anything and you can connect anything to the internet…
Timeline…
Mid-2012 – Julia started WeddingLovely. Early on they captured peoples’ addresses through a hard-coded drop down box of locations registration forms. Really inflexible.
So, Julia wanted to build an “OmniBox” (like TripAdvisor)… they had a free text entry for location that was “smart”, it autocompleted, understood cities, towns, villages… But Julia wanted to take this further to capture geolocation.
Geometry lesson – calculating the distance between 2 points (i.e. how far is the nearest wedding planner from my location?) is a bit tricky – used the Haversine formula initially but then ended up using GeoDjango
For every location stored in her database she stored a point – points are stored as a funky string of characters that can be converted to Lat/Long.
So how to get the lat/long from a string entered by the user?
Options
- Google Geocoding API (have to display Google Map)
- Yahoo! BOSS Geo (costs$)
All have compromises – some have rate limits, availability, performance, bad docs.
Julia went with Google API, which rate limits by client IP (which since the code runs on the client means it’s not too much of a problem in Julia’s scenario).
Side bar: Julia’s next start-up is a T-Shirt that says, “I was rate limited by Google”
BAck to the show…
GeoDjango makes it easy to,
- work out radius searches – what wedding planners are in a 20km radius from me?
- an ordered list of the closest results
Talking about Tindie, Julia’s current venture, that sells circuit boards and electronic stuff… and it also sells “a robot that plays Angry Birds” – and (what?!) they sell out all the time!
Performance is a really big deal when you’re using location services (especially when a Google Bot is spamming your site!)
It’s not if you’ll deal with location but when…
Thanks Julia!
* Zach Holman, GitHub
Git and GitHub secrets (this could be really interesting to Live blog – Yikes!)
America’s a bug – we’re working on it
What?! A dig at Avatar – I loved that movie!
So Git makes as much sense as Cameron’s Avatar – funny 
Merge strategies… good grief, he’s talking at light speed, slides are flashing past my eyes…
for more info…
> man git-merge
(note to reader: Zach’s slides will be available for download)
Zach doing a great job and getting awesome feedback on twitter.
@sudojosh: I finally understand what git means when it says its doing a recursive merge – thanks @holman! #wdcnz
@johnclegg: Awesome drinking the Git tips coolaid! #wdcnz
@megahbite: Emoji diffs. Yes! #wdcnz
@_MarkHolland: git commit -m “fixes shit” is not what Linus had in mind #wdcnz
@jeef3: Loving @holman Git talk! #WDCNZ
“You can probably use Emacs, but then you have the downside of using Emacs”
Zach’s favourite Emoji – :shipit:
Great set of tips – sorry I could keep up on the blog folks, but as I said, the slides will get posted after the event. Here’s the slide deck that Zach used at WDCNZ.
11.10 – 12.50: Owen W (@ow)
François Marier @fmarier
“I’m here to tell you about passwords – passwords are a liability”
Problem: Passwords are hard to remember. “We’re all geeks, we all have password managers”
Users either use a password safe, a physical book or simply resort to an easy password like ‘Password123.’ Oh dear.
There’s a problem with password resets – email password reset is a great idea, unless someone has control of your email account. If they have control of your email account, then they can control *all of your accounts.*
A popular alternative now is outsourcing your password/identity management to… a for-profit American company, like Facebook or Twitter.
On the topic of using Facebook logins, Fracois says “People want a little dating before marriage” (Eric Vishria – Rockmelt) and aren’t likely to trust you to use their real identity straight away. You’re already losing a large group of potential users.
OpenID just doesn’t work for the average user because they don’t associate a URL with themselves. Power users might, but the average person won’t.
François believes the existing login systems don’t work. The ideal web-identity system should be:
- Decentralised
- Simple
- Cross-browser
So. What if it was built into every web browser? That’s what Mozilla Persona is. It uses the email address as the base, if you can prove you own it. They’re doing an on-stage demo with people to show how the certificate and private key approval process works. You can read more about this process here for yourself.
Persona is already a decentralised system. But, while decentralisation is a good idea, it’s not a good strategy to wait for all domains to support it. The solution is that we have a temporary centralised fallback. As soon as an email domain gets support, this goes away. What this means is Persona works with all email domains, regardless of if it is officially supported yet.
Right now, Persona works with all modern browsers on desktop and mobile. Incredible!
Walter Rumsby’s presentation from the other session
To get Personas going right now:
1. Load JS library
2. Setup login/logout callbacks
3. Add login and logout buttons
4. Verify proof of ownership
Francois finishes by saying if you’re building a new site, you should default to using Persona as a first option and use something else if it makes sense. If you’re using an existing site, you should add support for Persona to get rid of your fallback login mechanism.
Questions from the audience:
Does it work on mobile apps? Yes – it’s similar to OAuth systems where you show a browser and get a token like other apps. We’re working on iOS and Android SDK’s to make it easier.
What about if Javascript is disabled? Well, if it’s disabled, you’re pretty much out of luck. We need to have Javascript to use crypto on the client.
Is it possible to use the BrowserID system without Mozilla branding? We’re trying to remove our branding as much as possible. We need to put a little bit – to be able to recognize that it’s our system so that it’s easy to spot on any site.
Have you talked with other browser creators to see if they will add native support for Personas? For Native support we don’t have it yet for Firefox as we rely on Javascript. First, we’re finalizing the API for site owners and then adding it to browsers once we’re done. We’ll reach out to others once we’ve finished it for Firefox.
What usage metrics do you have? On Voost, we’ve found that more people use Facebook login than Persona on their site after we added it. Going back to the quote, we need to build user trust. 20-30% of users were using email sign in rather than Facebook (off the top of his head).
What happens when the user changes their email address? It depends on how the site handles it. The site needs to allow for backup options.
What happens if a identity provider goes down? You can’t sign in. The same as what happens when your email goes down.
Up now – Ryan Seddon on Web Components
This is:
- Custom elements
- Shadow DOM
- Templates
- Imports
- Decorators
What does it solve?
Encapsulation – an iframe without baggage.
Modularisation.
Easy to use.
Getting an element in “makes you wanna endlessly throw a raccoon.” I think that’s a reference to Kevin Rose throwing a Raccoon over the weekend!
We’re talking about how to create a custom element right now. To register a custom element, you can do it inside the element using this.register() or do it programmatically in your script using document.register().
Custom elements:
- Are real DOM elements
- Only supported in Firefox and Chrome nightlies (which are both unstable).
Onto the Shadow DOM:
- It’s where encapsulation happens.
- Browser vendors have had this already
- Gives markup and style encapsulation (that don’t show in the user DOM)
- Enormous amount of information
You can show the Shadow DOM inside the Chrome dev tools – it’s hidden behind the cog on the bottom right. There’s a great summary of what Shadow DOM actually is here.
Pseudo elements allow you to target specific parts of your CSS classes, such as inserting content before or after them or selecting the first line. Read more about it here.
Recap time!
- @host: allows you to reach outside the Shadow DOM
- pseudo: reach inside the Shadow DOM
- ::distributed: style distributed elements
- Only supported in Chrome at the moment and only partially works.
On to templates:
- Inert chunk of the DOM
- Not quite native handlebars
- Activates on DOM injective
These allow you to only download content in the DOM when you want to. I.e you can hide a div and only download the image inside it when the user clicks on a button.
All of these components: templates, custom elements and the shadow DOM are really powerful when brought together. Styles inside of styles!
Currently discussing a “Extend the web forward” article that expresses the need for web developers to be able to have low-level API access to allow them to build new features themselves. Check out the post for yourself here.
The Responsive Web Design picture element that’s under discussion is one of these. RWD and retina displays require different retina images. If we had web components now, we could create our own components to allow for this.
Take a look at Ryan’s slides - ryanseddon.github.io/web-components
Photo from the other session – Jason Kiss
And…we’re all done here for the morning! Slides up soon.
13.50 – 15.50: Craig (@craighamnett)
So, how was that lunch? A fantastic feast of friands with friends. Your bellies are full, your thirst is quenched and you are in for a feast of intellectual proportions.
The Accessibility Panel
Hosting and steering the panel is Lynn Hamilton (@dryglue) and facing the questions are:
Word on the street is that the chair of the panel is battling a self induced headache. The speakers were treated to a slap up meal last night with unlimited refills on the wine. Good conversation and coherent conversation aren’t mutually exclusive.
If you need to heckle the accessibility panel, ensure your insults are also thrown as braille plated pieces of steel for maximum reach. Right, settle down folks, let’s hear what they have to say!
Owen back on stage with his trademark Austin Powers dance, whoops from the crowd.
Who is the target audience for accessibility?
Jason: Ensuring access by people with disabilities, reading, learning and cognitive disabilities.
Nic: Make website usable for everyone regardless of disabilities. It can sometimes be the technology which fails us. It’s not just about people.
Julia: STOP MAKING EVERYTHING GREY!
Is there a distinction between usability and accessibility
Garann: It’s a false distinction. Accessibility is something which falls out of a developers usual work remit.
Jason: Very rarely does colour contrast get thought about. If you solve that you are one step closer to achieving universal design.
Nic: It’s human nature to think about usability. It’s tactile, it’s how we use it. It boils down to user experience.
Should I bother with accessibility if they aren’t my target audience?
Jason: All people have family and friends who skateboard. Everyone should be able to purchase skateboards.
Are there benefits into building accessibility in a site?
Nic: Google is the largest screen reader on the internet. If Google can read it you’re half way there. Make sure your code is well formed and you will find portability to mobile becomes easier. Often there are government requirements in certain counties with decent discrimination laws.
Garann: This is the basis of good, clean code.
Julia: Accessibility isn’t charity. Doing the right thing has benefits to your business. Accessibility should be a business discussion, it’s valuable and it’s the right thing to do.
Jason: I’ve seen lot’s of great progress in creating awareness. How many developers unplug their mouse and try to navigate with just a keyboard? How about that for an accessibility throw-down? More carrots, less sticks. Creating laws doesn’t help that much and isn’t very positive.
Nic: I don’t like using the stick. But it works. Sticks open up discussion. “How can I avoid a lawsuit like that video content company?” Hotels were complaining that they had to spend money to make their rooms accessible because no disabled people came to the hotel. Turns out they didn’t come because they weren’t accessible. Chicken and egg scenario.
Do you think accessibility should be a charity? Should it receive grants?
Julia: If you force someone into a corner and give them grants you take away the reason that developers should be working.
Nic: If accessibility starts as charity, it will always be seen as charity and won’t be seen as intrinsically good. Plain and simple language is much better for translation.
Questions from the floor:
Keyboard focus in modal popups, how does that work?
Jason: Maintain focus within the modal with JavaScript. Play with aria-hidden for screen readers so the page gets reduced for those users. This restricts and focuses on that content.
What is a good way to get real testers?
Nic: Don’t ask your blind friend to do it, one person isn’t a good enough sample size. Try Knowbility or similar NZ companies.
Who built their sites with accessibility in mind?
Audience: 40% of hands shown. Very few did formal training, none of those want to speak.
Julia runs into walls.
Can you do accessibility wrong?
Jason: You can do everything wrong. But doing a little bit of accessibility right is better than doing none of it wrong.
Garann: Having a greater diversity of developers. More specifically older developers as we are an ageing population. Change the notion of what a developer is and entice older people to the developer arena.
Julia: If you want to make most of the web accessible, include it all in the Twitter Bootstrap. ONE DAY THE WHOLE WEB WILL BE BOOTSTRAPPED.
HOT TRIVIA from Jason
Including a broader range of individuals creates better solutions. The phone was invented to attempt to overcome some form of accessibility. Vint Cerf, founding father of the internet was profoundly deaf. The “curb cut effect” – make curbs accessible for disabled folks. The has the side effect of being able to push your trolley home from Countdown.
Correction: Jason has informed us that Cerf isn’t deaf; he was just hard of hearing.
Now up in the Renouf Room, Alex Gibson and his talk:
Data driven Delirious: An Intro To Data Visualisation Using D3.js
You can also follow this talk here on PrototypeAlex.
There are three main JavaScript visualisation libraries:
- Raphaël.js
- Processing.js
- D3.js
We’ll be focusing on D3. Edward Tuft has done great work on data visualisation principles. Visualisation is nothing without good core concepts.
SVGs are used because they can scale without losing quality. Unlike gifs or jifs or jefs, however that is pronounced theses days. The downside to this is the lack of IE9 support and below. Upgrade yo browser (or use Raphaël.js if you want IE support)!
CoffeeScript is Alex’s choice of JS compiler, he wrote a haiku.
JavaScript is quite nice.
But CoffeeScript has no semicolons;
What more can I say?
Here’s a CoffeeScript primer. An example of code in JavaScript:
var log_me = function (d) { var to_be_logged = d; return console.log(to_be_logged); };
…and here’s the same in CoffeeScript:
log_me = (d) -> to_be_logged = d console.log to_be_logged
Alex has now tricked everyone into coming to a SQL talk. He’s using joins to Enter, Update or Exit his sets. This talk is going way too fast to keep up with code samples. What you need to know is that there are lots of pretty circles on the presentation. The circles are pink, purple, and blue. There was also a mention of bacon. Everyone loves bacon, right?
A very cool practical example of plotting the minimum and maximum wages compared to GDP in different countries. There are now four circles on the screen.
Meaning and context is provided to visualisation with axes, or axis. Alex pulls out the classic “here’s one I prepared earlier line”, and magically D3.js has put all the lines on the grid and put labels on those axis too. We have to come to the slow realisation that New Zealand is behind the other countries.
So, after crying about the dire state of the country, back to the graphs. We just slap on a transition, add some delays, and there you have it. A static graph has turned into a far better graph. It moves!
Alex has a solution for how to make us better. Plump up 100 niche companies within the country and all of a sudden we are beating Australia. Surely that is something to shout home about? Want the codes on how to do all this? Here’s the D3.js code:
countries = # countries with new data svg.selectAll('circle') .data(countries, (d) -> d.name) .transition() .duration(2000) .attr('cx', (d) -> x(d.wage)) .attr('cy', (d) -> y(d.work)) .attr('r', (d) -> z(d.gdppc))
Don’t say I don’t give you anything! But seriously, take a look at the slideshow for this presentation, it’s much fuller than I could keep up with.
Amy Palamountain is up in the main auditorium. Her talk is about existing in the web, not just on it. Somewhat disappointingly, it’s not about actually being sent into the Matrix and living in the tubes. Let’s see if Amy go rescue it.
API’s suck! They break all the time. We should be following the grain of the web to unsuck them. SOAP APIs aren’t accessible, they don’t leverage the HTTP features such as cacheability. Getting good error messages out of them isn’t easy. So, how do we make them better?
The first step is to move towards a resource centric API design. They are entities, not database tables.
Now onto interacting with these resources with HTTP verbs. We apply these verbs to a noun. Hope everyone went to the English refresher course before. Here’s an example:
Let’s effectively use status codes to make our API understandable. Amy is begging you to use them!
- 1xx
- 2xx
- 3xx
- 4xx – I have no idea what you just said
- 5xx – The server is exploding
Make user friendly endpoints and people who are trying to consume it will understand it much easier because it actually makes sense. We can infer how the API works just by the URI structures. Failing that, there’s always the docs you can read. As you may have heard when asking for help online… RTFM.
We don’t change the browsers when code changes, the server should be updating the resource availability.
Hypermedia
Sounds scary. Let’s just call it a link with a REL tag. We can define the semantic meaning through HAL instead of JSON or XML. These links enable changes within the problem space. However there is a catch, hypermedia API’s need hypermedia clients. They need to agree on a representation.
Why include links in APIs’s?
Hypermedia doesn’t solve all problems but here’s a couple of use cases:
- It reduces the overhead of updates, you don’t need to update your app in the app store or wait for users to download it
- Run time discoverability is a big deal.
Your API’s should be flexible and stand the test of time. Build them the way HTTP works, use the web, don’t just build on it. Embed yourself!
Donald Gordon shows us all how to shower with his talk on Lather, Rinse, Release. Wait, maybe he’s talking about deployment!
Before I forget, I just want to revisit the topic of accessibility.
I would like to commend the Michael Fowler Centre on their terrific disabled toilet stall. To cater for those who have a below average number of arms, they have toilet roll dispensers on both sides of the lavatory. Truly ingenious. They are a thought leader in accessible toilet layout design.
Right, that’s all from me. Time to go and grab a toffee apple.
LiveBlogging is now with Liam.
Rob Conery
So Rob comes out to Tina Turner so loud even he calls it excessive. He’s now talking about how children are the best source of graphics for a conference talk.
$5 a piece! Those kids know how to milk it. (Maybe? These slides are pretty fantastic. I think his kids undercharged.)
So the talk begins as if we were having a heart-to-heart chat about witchcraft JavaScript, and Rob explains that when it comes to JavaScript you should just let the code wash over you, feel the code, “take a deep breath and pretend you understand, like we do each day”.
“Dude! I can do this all with jQuery!” We should stick with the frameworks that are from people who are really good at this stuff. Likewise, JaveScript is not a fad like Gagnam Style (direct reference).
There’s some code on the board. “It’s not Hypermedia; don’t tell Amy.” I can’t read it as I forgot my glasses. I think she’s safe.
From what I can tell, MVVM (Model, View, View Model) is a JavaScript approach to MVC. You have a model, a view, and a view model is how you get the model to the view.
Now moving onto working with a list in Knockout.
How hard is it to work with Knockout? Apparently, Googles Per Hour are 6-8 when complex. The only caveat is that it perhaps doesn’t scale well.
Now moving onto Backbone. To use it you need to include jQuery, Underscore, and Backbone — and that must be the order. The compiler is in Underscore.
You have to make sure you bind the model to the view in order to get the changes to occur.
“Is anyone confused? I’m confused.” I AM! JavaScript is the language of warlocks.
Moving really fast here. We’re already onto working with lists and/or collections of models and using them in views.
Janella @fakeamerican3m
Googles per hour. Legit metric. #wdcnz
The general feedback from Twitter is that Rob is totally killing it with this talk.
“Nothing is showing up because I can’t spell.” It’s not an error so nothing is thrown. As is common with Backbone, simply nothing shows up if something goes wrong.
A comparison from Backbone to Knockout. If we are using the legit metric, GPH is at 25-30. The difference here is that it scales well. A lot of pain for a lot of benefit it seems.
Now onto Angular!
Using Scope as a tool within Angular. It’s a way to be a moving bucket of information between the model and view.
When using Angular, you want to work in a modular way.
Moving things around in Angular is horrible. GPH was at 10-20. The documentation for Angular is terrible, The code is written in a freehand way in a terrible fashion. Even the comments say the code in the documentation is wrong. Go to Stack Overflow if you want real help.
As a .NET developer, I always find JavaScript and its frameworks intimidating. But it’s definitely interesting to see an approach to using MVC in this way.
When you get over the initial shock, a route handler is actually really useful.
A lot of chuckles about the reopenClass method being “really obvious”.
You have to use Ember objects if you want to use change tracking. But there’s a lot of frustration involved in this. Rob even had a wah on Skype with the co-founder of Discourse because he found it so frustrating.
Sorry for now examples of code. The slides are moving at the kind of pace you expect from actually coding it, rather than something that should be considered a tutorial.
Twitter feedback doesn’t seem so keen on Ember. Apparently it took four hours to come up with the demo. The GPH was literally infinite. Every time you Google for an answer, you have to look for a date to see if it’s still relevant — that’s how much they change the API.
And that’s Rob done!
Garran Means
Garran will talking about how to build your templates from the ground up in JavaScript.
“HTML does not belong in your JavaScript.” It’s really easy to mess everything up if you do this, especially if you aren’t the one writing the HTML.
The alternative is doing a bunch of DOM manipulation, and you don’t really want to do that just because of the overhead.
However, you can’t avoid the DOM. You need to accept changes from users and reflect them. That’s the point of JavaScript after all.
Assumption: JS does not belong in your HTML. There are ways to get around this, though. Modular templates are a good way to do so, for example.
Apologies if the blogging for this is terrible. She’s moving very fast and there’s definitely an expectation of prerequisite familiarity with the subject matter.
Asking a question to the audience about whether there is a problem with the code. Silence. It seems I’m not the only one that’s unfamiliar with Node.js.
“There’s an idea that if you use framework templates, you don’t have to worry about anything . . . but at some point you are going to have to go back and work out what they were thinking. You might get it out of the box, but you still need to understand it.” (Paraphrased.)
The obvious use of Node when it comes to templates is for manual labour.
Node is a really good tool for building JS because it is JS. But you don’t want to let the client have all the fun. Why not use templates on the server? Mustache (sic) is brought up as an example. “You should use JavaScript on the server if you can.”
Partials (compile time partials) are your frenemies. They are templates within your templates.
Building templates ourselves. They should be simple to use.
Glad to know I’m not the only one that’s totally and utterly lost. If you don’t know JavaScript, then this talk is like listening to Mandarin. It’s moving really fast and definitely expects you to be familiar with the subject matter.
And finished. I feel like I was hit by a hurricane.
That’s WDCNZ 2013! Owen is up on stage now giving a shoutout to the team involved.
––– the Live blog post is all above this line keep refreshing for more! –––
The post Live blogging at WDCNZ 2013 appeared first on Xero Blog.
