Category Archives: Projects

Gathering stats and Herding Cats

Naga IT Services
Filed under: Industry, Projects, Talk notes

On Thursday 5th February, I gave a short talk at the Cape Town Scrum Users Group about RailsBridge.

gathering-stats-and-herding-cats

My slides are up on Speakerdeck. I talked about RailsBridge itself (the upstream organisation and how our Cape Town chapter came to be) and the Cape Town team’s focus on Continuous Improvement. I talked about the various methods we’ve used to gather feedback (and how successful or not they were), what feedback received, and what we did with it (lots of things!).

I’ll be giving a remixed version of this talk at the Cape Town Ruby Brigade in March, where I’ll focus more on the Ruby and Rails bits, and the curriculum.

(Yes, me doing all this Ruby stuff is slightly odd, since where I work now (Praekelt Fuondation) is a Python shop. Vumi, for example, is all Python. ¯\_(ツ)_/¯ )

Rape Crisis CTFEDs Hackathon: the seconding

Naga IT Services
Filed under: Projects

A few weeks ago, the Cape Town Front-end Developer meetup group for our second Rape Crisis Cape Town Trust hackathon. Although it went better than the last one, there is still lots for us to learn about the shape and structure of hackathons, and about how we can best help organisations like RCCTT.

What went well

The Style Guide is progressing nicely. We’ve got a Grunt set up to generate the style guide and get things moving along quickly, and we’re making good progress with it. We’re sort of aiming for a bit of a Style Guide driven development approach.

Even though it was after the hackathon, we managed to squeeze in some time to update the mobile Theme for the site to add some basic colours and branding to make it look a little more like the desktop site. This is temporary (it will fall away once the new, shiny, responsive is ready), but we think it was a useful short term solution, and didn’t take too long to do.

Using GitHub issues is still sort of working. Having a To Do list that you can grab things from, or assign things to people on is very handy.

What didn’t go well

Set up. Again. Even though most of us had the bits and pieces we needed on our machines (MySQL, PHP, something to run a local web server), we hit a few speed bumps when trying to run the site locally. For next time we need to be more on the ball about being ready: we need to be clear that everyone must have a copy of the site up and running on their machine before arriving on the day. The flip side to that is that set up problems are often easier to fix with someone helping, so leaving it to the day is tempting if you get stuck during the process. The other part of this is that we left it to the last minute. We’re all busy at our day jobs, and Saturday was there before we knew it.

We also got sidetracked by another problem on the live site. This is usual developer behaviour, and rightly so: when something is wrong on production, anyone who can help drops what they’re doing and tries to help fix the problem. There was odd behaviour from a particular WordPress Plugin on the live site: the Page Peel Plugin. The version of WordPress on the live site was updated, and that caused the Plugin to throw an error, which in turn stopped the widgets from registering. The widgets are basically all the little blocks that aren’t main content. For this site, that meant the homepage looked really broken! It was not a happy hour or so.

What to do differently next time

I really like how Zurb run their Wired events (their yearly 24 hour hackathon-like thing to help non-profits). Their recent post about it, Mobilizing Nonprofits Through Design Thinking, is inspiring, and has helped solidify some of the things we were thinking about from our recent experience.

We think we’d like to have a dedicated Project Manager for the day. That might be one of us developers stepping away from the keyboard for the day, or we could rope in one of our PM or Scrum Master friends from work. Having someone to keep us going and steer a bit would be really helpful.

On a related point, we’d also like someone from RCCTT there for the day to help guide decisions. It might also be interesting for them to see how this works, and what the hackathon actually entails. We would also be able to sneak in some content work with them. Another thing that’s on the back burner is a Content Strategy exercise for the site: having a RCCTT staff member on the team would mean that we could look at doing little bursts of that on the day.

Rape Crisis Hackathon

Naga IT Services
Filed under: Industry, Projects, Workshops

Some Front-end developers coding

Last Saturday, a handful of people from the Cape Town Front-end Developer meetup group got together to hack on the WordPress-based site for local NGO Rape Crisis Cape Town Trust. We ran into some pretty major stumbling blocks, and we didn’t get nearly as much done as we hoped. We did learn a lot, though, and we’re hoping do another hackathon soon to really get some improvements to the site done.

What went well

We set up a git repository and hosted it on GitHub. This let us take advantage of the team workflow features like Pull Requests that are really helpful when a group of people are working on different feature of the same code base.

A list of the GitHub issues

After some fiddling with sticky notes and felt tip pens, in true developer style, we started using GitHub issues to track the things we wanted to do. This worked well, and let us pick up tasks that fit our mix of skills.

The format of the hackathon felt right: one day, lots of coffee, pizza for lunch, and a mix of developers. We’ll probably repeat that format for the next one.

What didn’t go so well

We didn’t do any preparation work before the hackathon. Our goal, broadly speaking, was to take the site’s existing Theme and make improvements and adjustments to it to bring it more inline with the Mobile First Responsive principles that we strive for in our code. When we started digging into the code of the current WordPress Theme, Headway, it started to become clear that that would be difficult to do, especially in the one day that we had.

Nope packages installing

Headway is designed to be used by people who don’t want to see the code: it offers a drag and drop, visual editor, approach to building the site. Being developers, that was the opposite of what we wanted!

After a lot of discussion, we decided that the best course of action would be to build a new Theme from scratch, including a solid workflow using the JavaScript task runner Grunt, and a Front-end Style Guide. We decided this was out of scope for the day, but that it would make a great project for the next one. We decided to see what we could do to the existing Theme during the rest of the day.

What we’d do differently next time

We spent a fair amount of time figuring out what we wanted to do, and how we were going to do it. Our biggest failure was that we spent a large amount of time poking at the Theme confirming that we couldn’t do what we wanted to.

We could have avoided this time sink by having a few of us doing a bit of prep work in advance. We’ll try and do this for the next one: it would make sense for us to set up an issue list and tasks to be done before the workshop so that we could concentrate on the doing rather than just the planning.

Quantified Self

Naga IT Services
Filed under: Process, Productivity, Projects

I like numbers. Maths was always one of my favourite subjects, and I went on to do Maths with Maths (and more Maths) at university. Part of the appeal is measurement, because it can lead to insights and optimisation. Things like Nicholas Felton’s amazing annual reports fascinate me. This led me towards Quantified Self, and it sounded like something interesting, and like something I wanted to do.

For quite a long time I used Daytum. It’s pretty easy to enter data, and its output options are simple and appealing. The entering of the data was a little too time-intensive, though. To get the most value out of it, you need to track a lot of things, which means investing a lot of time.

So I dropped Daytum and used Moves for a while, but found it a bit limited. I took the (monetary) plunge and acquired a FitBit (The One, since it seemed the smallest and least dorky). In the end, it was much like Daytum, though. It track some things easily, but most of the data was fairly long-form manual entry, and it gets dull after a while.

Reporter

When Mr Felton released Reporter the other day, I decided to give the whole QS thing another go. The thing that interested me the most was Reporter’s approach to gathering data: short, randomly timed bursts, with simple answers. Logging every single thing that happens might give you some deep insights, but it’s a pain to do.

I’m also finding that I don’t mind being interrupted by it. I’ve turned off just about all notifications on my phone, except for personal, just for me, ones like Twitter Direct Messages. I found myself spending too long playing with my phone, and wanted to remove some of the temptations to pick it up. Reporter somehow goes under my radar for, though.

I’m intrigued to see if I stick with this, and what extra little questions I’ll add myself. I’m not quite sure what I want to track, but I suspect a pattern will emerge after using the app for a while: blank spots that I want to fill, or things I’m recording that I actually don’t care about.