WDCNZ Web Dev conference, Wellington: Part 1

3 October 2014, by

WDCNZ is in its fourth year. It’s a smallish conference (by London standards) with only 1 or 2 speakers on at any given time but the speakers were passionate and the atmosphere was great, and I came away even more excited and inspired than I usually do from the big boys JAX and QCon. Videos of the talks are available here. IMG_20140731_085721

Recurring themes

I don’t think any of these were planned but the themes that kept popping up throughout the day were

  • Build things in small pieces. Be they components, modules, packages or plugins, you should architecture your things in a way that allows bits to be easily added and replaced. In javascript (the language of the moment), this is made easy by NPM, requireJS and commonJS. Microservices weren’t actually mentioned, but they’re very popular at the moment and another example of the same philosophy.
  • Everyone is using Node.JS. In a city of .NET and Java, almost every speaker was using Node either for their job, their side projects, their robots, or in some cases just for their slides. Browserify means node modules can work on the browser too, so “javascript” means “node” now.
  • Get some hardware, build something awesome and program it. This was made to look easier than you might think. Get some random lights or motors, connect them to an Arduino, glue on a Rasberry Pi to provide a wifi link and/or web interface, and the rest is just code. We saw programmable jewellery, nodebots, door opening devices, etc etc.

How not to be an expert

Jen Myers (@antiheroine) kicked us off with a talk about what it means to be an expert, and how we probably shouldn’t pay too much attention to it. Instead we be willing to just jump in, and keep the attitude of a beginner for our whole careers.

  • You don’t need “special powers” or anything else to be an expert, or a developer – anyone can learn
  • “Unlearning our expectations” is often harder than the actual learning: a lot of the time people need to get out of their own way and drop their ideas of what they can and can’t do in order to achieve new things
  • An “anti-expert” is someone who is always learning (instead of claiming to have all the knowledge already)
  • Jen challenged us to go away and try something new, be it the flying trapeeze, fire breathing or learning a new language (she didn’t specify whether she meant Spanish or Ruby). Fortunately the next talk provided inspiration in this regard…

Javascript, robots and me

Sarah Hui (@sehsarah) took us through her journey from seeing a conference talk about building a robot to actually completing her own. In particular as a javascript dev she was inspired by the fact that you can program a robot with JS.

  • At first, obviously, nothing happened. Where do you find the time? Where do you even start?
  • “Start with something shit” – just make any old crap then you’ll be over the first barrier and away. This applies to art, writing, anything really, but also hardware. Get an LED and make it flash.
  • Longer term though you need a vision to work towards. Sarah decided she wanted something she could drive around, wirelessly, controlled via a browser, with a camera on board.
  • Other than getting stuck a few times, she really made it look rather simple
    • Some Node.js code, using libraries to do all the hard work
    • A pre-built tank robot kit
    • Glue on a raspberry pi and an extra battery pack to power it (this involved some fiddling to connect the usb port to some batteries) to run a node.js web server on the pi, connected to an iphone’s wifi hotspot (or other local wifi)
    • …. and that’s it?
  • Some useful things to look at:
    • johnny-five, the NPM library which lets node talk to arduinos and other hardware
    • Arduino
    • Raspberry PI
    • Mind Kits – ready made kits for driveable tanks and other bits, based on arduinos. Like an arduino on catapillar tracks.

On Front End Modularity

Mark Dalgliesh (@MarkDalgleish) talked to us about his experiences building and enhancing Bespoke.js, a platform for building presentations. A sort of open source, javascript powerpoint (only better, obviously). His message is to avoid creating a monolith style product by instead creating an ecosystem which others can contribute to easily, in this case by creating a plugin system, and generators to help people get started.

  • He deliberately wanted the core thing to have minimal features (it actually now only has three, because he removed two recently) but a plugin architecture which lets you pick and choose which features you want to use, and write your own.
  • Plugins are just node modules,
  • and in fact, plugins are just functions
  • Small modules!
    • Are easy to view the source of, to understand. No big scary black boxes here
    • Can be your experiments: no need to change and release experimental changes to core code
    • Bugs are minimized if each module is small and does one thing an an obvious, transparent way
    • And bugs are generally reported to the right place/project/person – much less wasted time
  • He wrote a Yeoman generator to make it easy for people to bootstrap bespoke.js presentations (this sounds a bit like using rails to bootstrap a web server)
    • Learning from this success, he wrote a generator to make it easy for people to bootstrap their custom bespoke.js plugins!
    • You should consider writing a generator for any tool you make
  • He chose Jade as a templating language (I’ve been using this recently too as it happens, it’s quite nice)
  • Having CSS in your JS module is ok – it’s ok to mix languages. After all, you have html templates in your production JS right? So don’t be afraid to ship CSS in a node module or whatever.
    • Concentrate on separating your concerns, not necessarily your languages or technologies.
    • In fact some node modules are ONLY CSS.
    • And, with browserify, you can use your node packages on the front end too.
  • When he got to writing themes for presentations
    • He realised a theme is a collection of features, or a plugin made of other plugins (apparently)
    • BUT we are familiar with the flat plugin structure from jquery, and early grunt. Something different is required: a sort of nested tree of plugins I think, but this bit of the talk passed me by a bit
    • Grunt actually had to change their plugin system for this reason, but they failed to change their API, unfortunately
    • Obviously, Mark also wrote a Yeoman generator to generate themes

Much more to come…

Tags: ,

Categories: Technical


Leave a Reply

* Mandatory fields

× seven = 7

Submit Comment