Category: Taking note

As ready as I’m going to be

Tomorrow is the first day in my new role at the Mozilla Foundation, and I’m getting the new job nerves and excitement now.

Between wrapping up at WWF, preparing for Christmas, house hunting, and finishing off my next study assignment (a screenplay involving time-travel and a bus), I’ve been squeezing in a little bit of prep for the new job too.

This post is basically a note about some of the things I’ve been looking at in the last couple of weeks.

I thought it would be useful to jump through various bits of tech used in a number of MoFo projects, some of which I’d been wanting to play with anyway. This is not deep learning by any means, but it’s enough hands-on experience to speed up some things in the future.

I setup a little node.js app locally and had a look at Express. That’s all very nice, and I liked the basic app structures. Working with a package manager is a lovely part of the workflow, even if it sometimes feels a bit too magic to be real. I also had a look at MongoDB, Mongoose and MERS as a potential data model/store solution for another little app thing I want to build at some point. I didn’t take this far, but got the basic data model working over the MERS API.

I’d used Git a little bit already, but wanted a better grasp of the process for contributing ‘nicely’ to bigger projects (where you’re not also talking directly to the other people involved). Reading the Pro Git book was great for that, and a lighter read than I expected. It falls into the ‘why didn’t I do that months ago?’ category.

Sysadmin-esque work is one of my weak points so the next project was more of a stretch. I setup an Amazon EC2 instance and installed a copy of Graphite. The documentation for Graphite is on the sparse side for people who don’t know their way around a Linux command prompt well, but that probably taught me more than if I’d just been following a series of commands from a tutorial. I think I’ll be spending a lot more time on the metrics end of Graphite, so getting a grasp of the underlying architecture will hopefully help.

Then, for the last couple of days I’ve been working through Data Analysis With Open Source Tools at a slightly superficial level (i.e. skipping some of the Maths), but it’s been a good warm-up for the work ahead.

And that’s it for now.

I’m really looking forward to meeting many new people, problems and possibilities in 2014.

Happy New Year!

Took my son to an "Alien Invasion" exhibition and got to play a little Space Invaders
Took my son to an “Alien Invasion” exhibition and got to play a few minutes of Space Invaders

My First #Mozfest

Mozfest 2013I have an hour free this morning, so wanted to quickly write up my thoughts on Mozfest before my memory fades too much. This will be a rough, but f*** it, ship it as they say at Mozfest.

I bought a Mozfest ticket in July with next to no expectations and just a little hope that meeting some new people might trigger some new ideas. It’s fair to say that this was a massive under-prediction on my part.

A couple of months later, with about a month to go until Mozfest, my boss (@ade) mentioned some sessions that might be interesting for WWF and my work in fundraising. A couple of introductory emails and a Skype call later and I’d put my name down for a yet-to-be-confirmed session called ‘Pass the App’.

We were going to use a new tool called Appmaker to build a donation app in a three hour session. At this point in time Appmaker didn’t do a lot. It was pre the version that would be called pre-alpha. I looked at Appmaker for a few minutes and worried I’d just agreed to waste the first quarter of Mozfest.

I had some time off and a couple of weeks went by. With two weeks to go, I wanted to get setup with Appmaker in a dev environment before the day so I didn’t waste people’s time with silly questions about configuration when we could be building things. Work was a bit crazier than usual and another week went by before I finally sat down to look at some code.

It was quite astounding how much Appmaker had evolved in those few weeks. The team working on this are incredible. From thinking the morning would be wasted, it now looked like a tool with enough components that with a little imagination you could hook up all sorts of awesome apps. My goal was to add some kind of payment to that.

The components in Appmaker are built with HTML, CSS and JavaScript and looking at a few examples I was happy I could build something by copying and adapting the work that’s already been done. But getting a development environment setup to work with these technologies I know pretty well required diving into a number of technologies that were completely new to me.

The deadline and motivation drove me through some of the initial hurdles and learning, and jumping into the IRC room for Appmaker I received great help and support from the team. I was worried about hassling them for their time while they were busy getting ready for Mozfest, but I was welcomed very warmly. It was a really great experience working with new people.

I guess the lesson here is: If you try and make something new, you cannot help but learn something new. And also that deadlines are amazing, as we’ve discussed before.

There were ten tracks at Mozfest, and at any given time I wanted to be in about eight of them. After the Saturday morning Pass the App session I was planning to alternate between the Open Data and Privacy tracks for lots of interesting things, but it didn’t work out that way. I didn’t actually make it to any other sessions. I got hooked into (and hooked on) making things in our scramble to build a working Pass the App demo, which we did. Here’s a link to the write up. I won’t re-tell that story. I got to work with kind and intelligent people making something valuable and learning a tonne. You can’t ask for more than that from any conference-esque event.

My hour of free time is up now, so I’m going to ship this despite the vast amount of things I was grateful for and wanted to talk about.

And I’ll say a quick hi to the people from the pass the app session,

And the many other lovely people I got to meet for the first time.

Something I wrote for Engaging Networks

A few weeks ago I received a marketing email from the Engaging Networks team quoting some stats about the possible improvements to website conversion rates that can be achieved with A/B testing.

I was caught off guard (but pretty chuffed) when I realised I was being quoted my own case study from a presentation I had given a couple of years earlier.

I sent a quick reply to the email and was delighted to find it was sent from a real address with a real person at the other end reading the replies (@Rachel_shares).

This turned into a nice discussion about conversion rate testing, and somehow I agreed to write a guest blog post. Which, with some helpful editing from Rachel has now been posted on the Engaging Networks blog.

I thought I should share the link with all two of my readers on this blog, just in case you’re not also reading the EN blog 🙂

The real story behind WWF’s fundraising split test success:
http://www.engagingnetworks.net/uk/blog/wwf-split-testing

Concept Game – Simple Evolutionary Model

I’ve spent enough time on this now to submit it, even if it’s still a bit rough around the edges. I’ve included a bit of a write up below. This demo will run best in Chrome or Opera. Click to play.

I’ve built a simple ‘game’ called Digital Husbandry. It’s more of a time killer as it doesn’t have any serious game mechanics, but there is a visual reward to keep the user engaged.

It’s based on the idea of simulating progressive evolution through selective breeding. Much as generations of farmers have done with livestock. The player brings together critters on the screen based on visual qualities that appeal to them, and produces offspring that drive the overall appearance of the group closer to those qualities selected by the player. The ‘critters’ die when they reach the ‘deadzone’ at the bottom of the screen, freeing up space for new critters in the population. So choosing which critters to sacrifice is as important as choosing which ones to breed.

The critters are recursively drawn from a simplified ‘genetic’ code. This allows the game to have millions of possible variations of critters, and the longer you play, the more varied the critters will appear.

I ‘composed’ some music in http://www.beepbox.co (which is a hugely fun distraction from fixing bugs in code). The music gets more layered and complex in line with the number of critters in the population. The audio tracks aren’t perfectly synced, but I’m happy enough with the effect for now.

NOTE: I ran into problems publishing the sketch with audio and I’ve run out of time to do any more work on this, so I’ve had to submit this version without sound.

A quick review of the Coursera Creative Programming Course, and using Processing for this kind work:

  • It was nice to write some code that isn’t about capturing web form data or sanitizing user input!
  • The format of the course, and the challenge I set myself were a good way to revise some of the classic programming concepts I don’t actually have to use much these days
  • I was jumping between Java and JavaScript quite a bit – which is a good study exercise, especially when porting code from one to the other. My basic Java knowledge is rustier than I thought, but I got there in the end.
  • Processing isn’t quite right (yet) to take a project like this and polish it into a publishable product (which is partly why I haven’t worried too much about the finer details of this ‘game’)
  • Processing is excellent for teaching creative programming
  • It was a shame to loose the sound, I had a slightly mental retro game tune going by the end. This was the base tune, which built in complexity with each additional critter.
  • I wouldn’t want to put this project through a code review! But it does the job for this assignment.

 

Drawn: Multi-armed Bandit Experiments

I read this really interesting article on multi-armed bandit experiments the other day, and while I enjoyed the graphs and the stats, I got distracted wondering what a multi-armed bandit experiment would actually look like? So I had a go at drawing one last night.

Multi-armed Bandit Experiments
Getting a little practice with my wacom tablet.

On getting agile with Google @App_engine

In the course of just 48 hours I deployed six separate upgrades to Done by When, mostly thanks to Google App Engine.

These weren’t major changes, but they were distinct pieces of work driven by user feedback and an analysis of the system/user stats.

I was shipping early, and shipping often and had quietly moved into a working agile methodology.

This is a huge change from working on projects with a six month lead time, a massive spec, a big launch and then maybe an upgrade to version two a year down the line if you’re lucky; which is the sad story of too many web projects.

It’s only now, when I stop to reflect on this change in working practice that I realised how much of this is due to Google App Engine’s one-click deploy. You develop locally, set a new app version number, hit deploy, get a test URL on your production server while your current version is still live and flick the switch when you’re ready to upgrade proper. When you combine this with unit testing and regression testing you can confidently make an improvement to one part of the system and put the whole thing live in a matter of minutes without downtime or fear of breaking things.

In the worst case scenario where something breaks, you can switch to an earlier version of your app with another click.

There are no more checklists and complex processes to work through for every upgrade. Just test, improve, repeat.

If you’re not working with App Engine, then spending a little bit of time now smoothing out your deployment process will quickly pay itself back.

The easier you make deployment, the easier you make maintenance. The easier you make maintenance, the easier you make development.

On the future of publising, today

I’ve had a couple of interactions with non-traditional publishing of traditional books in the last week, so thought I’d make a note of them as a way to digest the experience.

First, I wanted to learn Backbone.js, as it (or something like it) will likely be the basis of front-end web based software interaction for the next few years at least. My usual method for learning a new web technology/language/process is a to get a decent book with functional examples and read it quickly cover to cover. This is how I survey the landscape; like taking a helicopter ride over a national park before setting out to explore it on foot. The real learning happens on foot, but it’s useful to know where the lakes, rivers and mountains are before you head into the jungle.

You know you’re exploring the edge of current tech when the only book on the subject listed on Amazon won’t be published for another four months. So I dug around the Internet and came across a long and decent looking article ‘Developing Backbone.js Applications‘.

Using Instapaper, with one click on my bookmarks bar, and one click in my Instapaper account page I had the web-page converted into a Kindle friendly .MOBI formatted file. I emailed that to my secret Kindle email address and within a few seconds I was ready to start reading this article in book format on a screen designed specifically for this kind of job.

The process of getting this article to my Kindle is so easy that I didn’t actually spend any time reading the article before deciding if the effort was worthwhile. So when I started reading, I was pleasantly surprised with what I found. This ‘article’ was in fact a book; the very same book that won’t be published in a traditional format and available on Amazon for another four months. It’s shared under a Creative Commons license on the source code repository and social coding website, GitHub. An environment where if I find errors in the book, I can edit the text directly and post the update back to the original author, and if my changes are accepted, my contribution is attributed precisely to my GitHub account.

The second example was The Moneyless Manifesto, also shared freely online under a Creative Commons license. In this case the online version of the book has been split into chapters and subsections so it’s not quite a single click to get the book into Instapaper. Not one to be deterred, or to miss a chance to learn something, I knocked up a Python script to fetch each of the pages, pick out the relevant content and stitch this together as a single web page. Which I then sent through Instapaper and on to my Kindle, and my wife’s Kindle.

All of the above is perfectly legit. This isn’t like people who download music illegally, but it’s a challenge to publishers all the same. Most end users won’t be writing Python scripts to format online books in such a convenient way, or using Instapaper as a document converter, but in time more and more will and all of the processes will get easier.

The two publishers involved here are embracing the new world, but that doesn’t make it easy for them. I’m only a couple of chapters in, but The Moneyless Manifesto is full of interesting and challenging questions, and may have some ideas related to this future publishing conundrum.

The best online page turning book/magazine

I’ve seen a lot a shiny, fancy and useless online page turner book things, and typically hate them for their reliance on flash, the difficulty of reading them and the fact that we’re combining the worst of digital and non-digital technologies mainly to impress the people responsible for publishing the content rather than the people who are meant to read it.

This one was great though:

http://opim.wharton.upenn.edu/~ulrich/designbook.html

The key difference being the link on the left: “Download the MOBI file directly”.

I can flick through the book as I would at a shop, get a feel for the content, and then if it’s worth it, email the file straight to my Kindle for a proper reading experience.

That’s more like it now.