Softwire Blog


David Simons on “When it’s right to be wrong”


24 February 2015, by

At a recent SoftCon talk, David Simons explains how there’s a trade off between speed and accuracy in algorithms, and what this means from a computing perspective.

See his talk here:

WDCNZ Web Dev conference, Wellington: Part 3


16 October 2014, by

At last, the long-awaited final part of my WCDNZ experience, following part 1 and part 2

Building Your Own Tools

The highlight of the day was James Halliday (@substack), creator of browserify and other things, giving us a whirlwind talk and demo live from his laptop. Unfortunately it went so blisteringly fast I didn’t take many notes, so I’m not really going to do it any sort of justice here at all.

The theme was about writing tools which work together nicely. There were two main arenas discussed: the command line, and node. We started with a general note: don’t be afraid to write your own tools, but you should probably first check that there isn’t already just such a tool out there.

  • First example: examining pull requests from github
    • James gets a lot of pull requests
    • Tip: if you add .patch to the end of the URL of a github pull request, you get a patch that works with git-am
    • git-am is a git tool which was apparently made by Linus Torvalds for his own personal use – so the tradition of building one’s own command line tools is an illustrious one
    • You can use the pipe to send the patch to git am, either by using curl to get the patch, or copying it from a browser and using xclip, maybe something like
      • $ xclip -o | git am
    • So here we have useful command line tools that you can chain up using the pipe, and even swap tools in and out depending whether input is from the web (curl) or clipboard
  • James then showed us some command line tools of his own, along similar lines, which provided the various parts of a time tracking mechanism. I can’t remember much detail but I think it went something like this
    • There was a tool that generated some JSON for one timesheet entry
    • There was a tool that accepted this json did something else with it
    • There was a tool that took a bunch of these timesheet entries and saved a timesheet file, or something
    • Another tool took the same input but emailed a timesheet
    • One tool took lots of timesheet entries and combined them according to task code
    • … or something. Anyway all these tools ate and returned json and so could all be piped together in different combinations depending what you wanted to do
  • A pattern emerges: each tool is very small and does one thing well, and they share a common input/output
  • Finally we turned to some of James’ tools on NPM: browserify (bundles up node server modules into modules that will run in a browser), tape (a node test harness) and some pieces of accountdown (user management and authentication). I don’t remember enough detail to say much useful about this, but I thoroughly enjoyed it.
    • We had a great demo where browserify and tape were used together to great effect on the command line
      • One interesting takeaway is that tape outputs in a language called TAP, which makes it compatible with various testing tools (like testling) and swappable with other test harnesses (nodeunit has a TAP reporter plugin)
    • Similarly, the node demo where some of the accountdown functionality was built incrementally from scratch went pretty fast but the gist was to isolate little bits of functionality, e.g. creating a user, authenticating a user, into their own node modules.
  • Some choice quotes:
    • If you’re going to build your own tools, please please test them. That way you can convince other people that they work.
    • I use my own test harness [tape]. Everyone should write their own test harness, but if you like you can use mine, it’s pretty good.
    • The people who know what they’re doing can make a little module that encapsulates that knowledge, then everyone can benefit.

Miscellaneous Tips

  • Check out the persistent in-memory key-value store levelDB – it’s easy and unlike some other in-memory DBs, it’s very fast.
  • If you have a project with some usage examples, you can bootstrap tests for that project by copying all the examples into a new “tests” folder and converting them into tests.

Further reading

Writing Better CSS

Toni Barret (@toni_b) tells us that good CSS is:

  • Maintainable
  • Understandable
  • Well-planned

In particular, good CSS need not be highly optimised for performance. How to do it:

  • Plan
    • Decide which browsers you will support
      • And decide what “support” actually means. For example you may have different levels of support: “full”, “mainly works”, “functional but not pretty”, “only if time”
    • Decide on a set of standards
      • For example, don’t nest more than three layers is a good rule to have. Doing so often leads to bad selectors…
      • …where a “bad selector” is one which is reliant on the html structure, too specific, and/or not reusable.
    • Decide which tools you will use and set them up from the start
      • Concatenation, minification, pre-compilers, etc etc
      • You don’t want to retro-fit this stuff later on if you don’t have to
  • Use Comments
    • Don’t avoid commenting CSS: you comment your code when you need to, and yet people rarely comment CSS.
    • In particular that big Table of Contents comment at the top (that comes with bootstrap and other libraries) is very useful: if you are using it then make sure you take the time to maintain it
  • Divide and group you CSS logically into files and sections
    • avoid the common everything-is-appended-to-the-bottom-of-main.css problem
    • and avoid the each-developer-has-their-own-css-section-with-different-styles problem
  • Use a “pattern library
    • Exactly what this means went a bit over my head, but checkout http://pea.rs/ for an example, and I think it also provides a way to bootstrap your own pattern library
    • In a bit team or a big/long project, this will make development easier and lead to a more consistent style

Further reading:

That’s it!

WDCNZ Lanyard

WDCNZ Web Dev conference, Wellington: Part 2


9 October 2014, by

A round up of some more of the talks from WDCNZ

Coder Decoder

Katie Miller (@CodeMiller) explained some of the mysteries of functional programming using pictures of cartoon snails. I won’t be able to define them here any better than wikipedia will do for you, but below are the ideas she demonstrated. Haskell was the language of choice, not because it’s particularly better than any other functional language, but because it’s just so canon.

  • Referential Transparency
  • Higher Order Functions
  • Currying
  • Closure
  • Functors
  • Monads

Yes, Prime Minister

A bit like something out of Flight of the Conchords, The PM John Key casually popped in over lunch (totally unscheduled) and gave a talk about tech needing to be at the centre of the government, and how he played golf with Obama once.John Key

The Panel: A Technical Education

A panel of speakers debated the state of computer science education, why kids aren’t interested in programming, and why students aren’t being prepared for a career in web dev. I don’t think very much of interest came out of it, other than Tanya Grey’s (@Tanya) experience that if high school students actually get the chance to try out some coding, they will always be interested in finding out more (every single time, apparently).

Sara Chipps claimed that because there is no degree course in web development, we all must be self-taught, which I think is only partially true because while self-education is a big part of working in tech (see the first talk in the previous post), it’s also true of every other career (except maybe academia and law) that you didn’t learn your trade at uni directly, your first employer taught you.

Tanya also pointed out that high schools are full of teachers without a computer science background doing their best to teach a syllabus that is starting to include more and more IT, and your local teachers would probably appreciate some help from pro coders like you in the way of backup such as being available on email to help them answer some of the more difficult questions from students. So, particularly if you have a child in school, why not get in touch and offer your services?

AngularJS Powered By SilverStripe

AngularJS is a front end framework which looks quite similar to Knockout to my eye, and can make it much quicker and easier to build web pages that change dynamically based on your data. James Pluck (@PapaBear) likes it. SilverStripe is an open source CMS and web framework in PHP that reduces the amount of boring boilerplate you have to write. That’s it really.

Building Your Passion With Hardware

Sara Chipps (@SaraJChipps) rounded things off by talking about how she started a programmable jewellery company as a means to try to get young girls interested in programming. Her reasoning was that she didn’t get into programming because someone told her it was cool, but because she needed to to solve a problem she had (when she was 12 she was maintaining some sort of BBS chat room website that she used to find friends). So she’s giving young women a problem that they need to code to solve.

This is an example of how it’s achievable to get stuck into hardware and make something interesting, and also of how it’s possible with a little time, money and effort to kick off a business in some new field that you don’t know much about.

Things that might be of further interest

  • Spark – like a tiny arduino, I think
  • www.instructables.com – a load of DIY hardware (and other) recipes to follow

One more part still to come…

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…

BrisTech


13 November 2013, by

A bunch of us from the Bristol office went to the second BrisTech, a new tech meet up in Bristol. As well as free beer and pizza there were a couple of talks, including one by our very own Tim Perry.

The first talk was on cross platform mobile development, from HTML 5 based frameworks to solutions like Adobe Air. The talk was very good, and centred on Property Cross an example application implemented in a variety of frameworks. In essence these save time, but there is still effort in making the apps behave as you’d expect from the platform. On top of that supporting Windows Phone is generally far more difficult as it both has worse support amongst the frameworks, but also making the apps feel native requires a totally different design.

As a bonus the speaker Colin Eberhardt did a second, short presentation “What’s Wrong With Green“, about the startling lack of green in App Store screen shots, and other useful results of data mining Apple.

Tim’s talk was on modular JavaScript, in particular the benefits of RequireJS for websites and CommonJS if you happen to be writing JavaScript in a non-browser context. It’s well worth a watch, as ever Tim is a highly engaging speaker.

 

SoftCon – Softwire’s first in-house conference


26 March 2013, by

Softwire recently held our first in-house software developer conference – “SoftCon”.

The idea of SoftCon was to hold a small conference, with talks on a variety of topics, given by Softwire employees for other employees.

Talks spanned a good variety of topics. Richard opened proceedings with a keynote speech on the inner workings of the classic Playstation game “Micro Machines” (the game is a firm favourite here still, some 16 years after its release!)

Rich talks about Micro Machines

From there we split into two tracks. Rupert told us about how to make use of a graphics cards for massively parallel programming (GPGPU), which was interesting as it’s not something that really comes up in our day jobs!

Other highlights included:

  • Gareth giving a great talk about architecture, and how to design systems that are maintainable and robust – something we already pride ourselves on doing well, but of course there’s always room for improvement.
  • Tim showing us the basics of CouchDB, a NOSQL database.
  • A demonstration of the latest web technologies from Harry, using SignalR and Knockout.js to create a voting application that updates in real-time.

The last session of the day was a discussion panel, hosted by Zoe, with a general topic of quality and testing. We had several of our speakers from earlier join in to give their opinions on the topic which resulted in some lively and interesting discussion points.

Testing panel

We ended, as tradition dictates, with pizza.

Overall it was a great success and we hope to see it come back next year, bigger and better!

Softwire Sponsors WebDevConf


8 October 2012, by

In celebration of opening our new Bristol office this summer, Softwire are proud to be a local sponsor for WebDevConf, a leading conference on website development held annually in Bristol and this year on Friday 19th October.  If you’re going along do try and find Ric Hill (who heads up our Bristol office) to say hello – he’ll be there all day keeping up with some of the latest ideas in our industry.