Sunday, 25 June 2017

Hanging up my abacus - part 1

After three years as treasurer of St Swithin's church, Bath I have handed in my spreadsheets and passed the mantle to another. This also marks the end of six years as a member of the PCC - the council which oversees the church and acts as its trustees. It has been a very significant part of my life for more than half a decade, so I thought it worth looking back at the lessons I learned along the way.

I was made treasurer for two reasons. Firstly; people think I can do numbers. Secondly; there was nobody else. My first (and slightly flippant) question was "so how much money do we actually have?". As it turned out, attempting to rigorously answer that question in detail was the basis for the entire financial strategy for three years.

Lesson 1: Asking (then answering) the simple questions is a good thing


That first question was far too obvious to be useful, and yet proved to be absolutely key. Obviously it can be rephrased to something more sophisticated ("do we have a clear picture of the current financial position?") but honestly there's not much point. I spent a lot of time carving this question up in a variety of different ways in an attempt to understand the nuances and that was a great exercise to help map out the problem space.

The important lesson here was accepting that, despite this being a complicated role, asking simple questions was a valid way of approaching it - those simple questions had a lot of value.

And that leads to...

Lesson 2: Helping others understand the answers is a vital skill


As soon as I had to take a proper interest in the church's finance I had some basic questions. Of course, if I was asking those questions it was logical to assume that others would be asking them to me in my role as Guardian of All Money. And lo, they did.

Between frequent reports to the PCC and annual reports to the congregation at the general meeting I had to learn how to take a complex financial position and explain it in sufficient detail to a roomful of people who all wanted me to say "it's all fine" and then stop talking.

The key to this was in the narrative. If a talk is structured so it follows a logical, coherent thread then it is far easier to follow. There needs to be enough detail to engage people and back up the story, but not so much as to drown it. Given the nature of the subject (numbers - few people love numbers) then patterns need to be explained, and their significance highlighted.

I presented the financial position three times at annual general meetings and each year got extremely positive feedback along the lines of "at last I understand the finances!" so I think I did something right here.

There were a few lessons along the way. Accepting that other people actually did care about the same things I did; knowing the audience well enough to present the right information; and accepting that that audience really appreciated clear communication with enough detail to actually understand it.

Lesson 3: The power!!! AHAHAHAHAHAAHA!!!


The role treasurer is potentially very powerful. I had all the information about the finances and I drafted the budgets. Between those, I could heavily influence every financial decision made in the church - and most decisions have a financial component. That meant I could change church policy and promote my favourite projects by allocating money and it would be a challenge for anyone to question me as I was the one with all the knowledge.

To be clear - this is a situation I worked very hard to avoid. It was especially true for us - we had a year without a vicar during my term which gave even more scope for abuse of power.

The problem is, the roots are in the control of information - specifically the other members of the PCC and leadership not knowing the finances in enough detail and, despite what I just put in Lesson 2, most simply didn't want this information.

There is a point here about duty of care. A church is a charity and the PCC members are trustees, which means they have a legal responsibility for the finances - a duty they can't properly perform without clear information. It's not a duty that is always made clear and that is why there is a tendency to let the treasurer just get on with it, which is where we came in.

It is a different problem from the last one. That was about answering questions clearly. This is about encouraging the questions to be asked in the first place and that is a cultural shift - a fairly major one in our case. I ended up having to change the way we thought about initiatives and projects in concept - getting costings and financial thinking in from the start to help weigh up the relative merits (rather than deciding on a priority then working out whether we could afford something) and coupling that with changing the book-keeping processes to allow easily-produced monthly financial updates.

There is a lot I can write about the techniques I used here, but the important lesson is that there are some things people have to know, whether they want to or not. In that case it's important to make the knowing as simple as possible - ideally ingrained into process in such a way they pick up the information as they go with no extra effort on their part.

Lesson 4: Having a vision


These three points all link into transparency and communication - being very clear about what one is doing and ensuring people understand why. About three months into my time as a treasurer I wrote a vision for what I wanted to achieve and it could easily be summarised as "make it easy to get information" and "make sure it's not embarrassing if people do".

This document was primarily for myself, so I could get my thoughts in order before moving forward. It proved incredibly useful as something to which I could later refer in order to judge whether things were developing in the right way. It's not exactly insightful, but this was the first time I had written a long-term vision and the lesson for me was how useful it turned out to be. I also learned the difference between strategy and vision and how important both are, but also how to consider them separately.

None of this has touched on the other people involved, but this is getting long so I'm going to split it into two. More soon.

Tuesday, 30 May 2017

Motivation

Every year I write a post about the various non-work creative things I've done to fill my time making stuff and learning new skills. I started doing this because I needed to remind myself I actually do this, and I have a tendency to forget quite how much. However, there are definitely times when the opposite is true and I spend a week or longer fixing broken things and watching videos on YouTube and after a stint of that it can get quite hard to motivate myself back into some kind of creative action.

It doesn't help that, according to the Belbin personality tests, I'm a "completer-finisher" which means I like to fix errors, polish products and - most significantly - actually finish things. I have noticed a tendency both at home and at work to leave a package of work unstarted in favour of completing something in progress which, while often a good thing, sometimes means something which is easy to put off is left alone for quite some time before I feel I've got the time to "do it properly". At work this is usually broken by some kind of deadline. At home, where there are very few deadlines, this is a great way of saying that I can be really bad at starting things. This has all been exacerbated in the last six months or so due to being generally exhausted because of moving jobs and cities.

This very post is a great example. I've been putting off writing it all weekend and here I find myself writing on a train - something I usually avoid like the plague as I jealously guard this time for reading. Yet, I have promised myself that I will write at least one blog post per month and I've very aware that if I don't get this one done today I will likely miss May.

So, some kind of deadline (even a self-imposed one) clearly works for me so I'm going to state some projects with deadlines in the hope it will kick my motivation back to life. I generally need something technology-based and something writing-based on the go at once so I can pick and choose as the mood takes me. Here we go:

University RPG

This is a comedy RPG, being written from the ground up and full of HE in-jokes. I'd like to have something ready for playtesting by the end of June and ideally have run a first session by the end of July.

Players Without Number RPG

A solution to the impossibility of organising five players to a regular game when two have children, one lives in another city and another has an international sword-fighting career to juggle. Have lots of players and swap them in as needed. I'm going to write a post about this my other blog (which is also a good excuse to kick it off again). I'd like a session and a post done by the end of August.

Year in Pictures on AWS

Every month I have to mark up fifteen blocks of YAML and crop their corresponding pictures for my Year in Pictures site. It would be nice if I could automate as much of this as possible and I may as well gain some hands-on AWS experience along the way. I'm going to aim to collect the July pictures using the first version of the new thing.

I think that'll do for the moment. One thing I've learnt about time management is to make sure there aren't too many things in progress at once else nothing gets done. Let's see if making a proper decision to do these things to a deadline makes me get on with them. Now I'm going to read for the rest of this train journey and not think about giving myself SMART objectives for my spare time...

Sunday, 9 April 2017

How to Mac - part 2

Well, I'm still making use of a Mac. Four months in I'm starting to get used to the keyboard and some of the oddities (good and bad - I still hate the behaviour of this window management). Time to write some more docs for future-me should I ever have to configure one of these systems again.

Clipboard management


I made the switch to using a clipboard manager years ago and frankly now can't comprehend life without one. I found loads of them on the Mac - mostly expensive and part of much larger packages which I don't need.

The one I settled on is called Flycut. It will only work on text (and will occasionally foul up copying images with a keyboard shortcut) but it works really well for my simple use case and is easily installed via homebrew:

brew cask install Caskroom/cask/flycut

Services


Installing services such as Postgres or Elastic Search via homebrew often writes them into the startup sequence. Sadly, these days I am not coding enough to need these all the time and available RAM is precious so I went looking for an easy way to change what is run when. It seems an easy way to do this is homebrew services, which is easily installed via the homebrew interface and lets me edit the startup sequence and run the services directly without them starting next time I boot the machine. This last command requires a very recent version. Docs on the end of the link, above.

Bash and completion


I took a brief foray into Z shell and found it different enough to bash to irritate me. Given time I think I could configure it to be something I really like, but after some time and rage trying to configure the prompt I decided that I don't have the patience for that at the moment.

The motivator here was improving bash autocompletion - especially for git and homebrew. It turns out the version of bash shipped with OSX is ancient so the first stop was upgrading that via homebrew which then meant changing the bash-completion package (written for bash 3) over to bash-completion2 (which is for bash 4). Next I discovered that both git and homebrew ship with their own completion config which just needed to be parsed when the shell starts.

And thus the fun began.

Homebrew bash autocomplete configuration is hidden in /usr/local/etc/bash_completion.d instead of the more usual /etc/bash_completion.d. I needed to encourage it to parse the contents of this directory instead - which proved surprisingly difficult. In the end I had to add this to ~/.bash_profile:

for bcfile in `brew --prefix`/etc/bash_completion.d/* ; do
  . $bcfile
done

(copied from this Stack Overflow answer because of lazy).

As far as I can tell, bash is supposed to read the contents of the bash_completion.d directory automatically but because homebrew moves it the paths need fixing. There is almost certainly a better way of doing this, but by this point I was bored of this problem and decided to accept something that worked. Then write about it.

I also found I needed to create an empty file at /usr/local/etc/bash_completion because this line was complaining:

[ -f /usr/local/etc/bash_completion ] && . /usr/local/etc/bash_completion

I probably could remove the line, but I had Fear of removing such a standard line of config and ending up breaking something else in the future. Again, probably not the best solution.

And that's it for the moment. Like last time this is mostly my own documentation so I can reproduce these steps in the future written here on the off-chance it is useful to someone else. I certainly don't recommend any of the bash config stuff as the best way of doing things. Think of these notes as a diary, recording my reluctant exploration of MacWorld. End disclaimers...

Saturday, 25 March 2017

Why I like using Monzo

About six weeks ago I was sent a Monzo card, in all its lurid orange/pink (coral!) glory. As a pre-paid cash card it shouldn't be too exciting, but it comes with some great bonus extras within the application.

Give me the monies


Sending and receiving money between friends is incredibly easy. It is like the PayPal network, but with a superior UI and no fees. Admittedly, it cheats a bit here as PayPal is fee-free if your money is within their network already and that is the only way to work with Monzo.

Track my cash


The application does a great job of giving you the basic information you need up front (balance, spend for the day) and sorting your spending into groups so you can see with horror quite how much you're spending on eating out. You can access this information by month, but more importantly you this is all available via a simple API.

My data


The API is where the fun starts. I'm not going to apologise for liking data and graphs and it's really nice to be able to start plotting my finances in different ways to get to grips with the patterns to my spending (and remember how to do data manipulation and visualisation).

Scales redacted :-)
So far I've been plotting my balance per day so I can see if there are any trends. I want to start looking at the breakdown of spending area by week and month (the app UI only gives per month). Once that is done I'll start thinking about what other questions I've got...

If you want to have a look you can get the code from Github.

Thursday, 16 February 2017

I can't review your site - I can't see it

Oh, this article looks interesting. It might solve my problem. I'll have a quick re.. NO I DON'T WANT TO SUBSCRIBE TO YOUR EMAIL UPDATES. Has anyone ever actually engaged with a website overlay, beyond searching for the tiny "close" button in annoyance? They are all over the place so there must be a good reason for them to exist. Maybe if we look closely at some of the steps required to make a successful one we'll start to understand.

Spoiler warning: we wont. Overlays are inherently terrible.

Making a successful overlay #1 - the timing


The overlay needs to appear before your victim leaves the site, so it needs to be quick. Never mind that "quick" roughly corresponds with the amount of time someone who is genuinely engaging with your site takes to orientate themselves and settle in to proper reading. In order to catch those people leaving quickly because they don't care anyway you're going to have to annoy your real visitors. Omelettes, eggs and all that.

Making a successful overlay #2 - make it intrusive


You're trying to catch the attention of your victim and what is more attention-grabbing than the entire screen being replaced by the action you want them to perform? Maybe it should flash too. Make sure they are under no illusions - your only interest in them is harvesting a review or an email address. Any content on the site is strictly secondary.

Making a successful overlay #3 - make it alien and hard to close


We don't use javascript alert popups these days because they are so easy to block and everyone has the location of the close button hardwired into their brain. However with an HTML overlay you can avoid this problem so your victim doesn't miss the information that is so crucial you have to interrupt their browsing. And it is, after all, all about you. So why run the risk they can easily dismiss your overlay? Why use established design patterns to put the close button somewhere obvious? Make sure it's carefully hidden and don't even think of adding a keyboard shortcut to kill it. That would be madness. The "escape" key has much better things to be doing.

Making a successful overlay #4 - make sure it is in the wrong place in your visitor's journey


You can't possibly wait until your victim has finished reading the page before asking their opinion or for them to sign up. They might leave at the end, having learned whatever they wanted, possibly even happy - and all without ever giving you their email address. The horror. Never mind that five seconds into a visit nobody has a useful comment beyond "the overlays annoy me" and that putting them right at the start of the visit means your overlay cannot possibly do the job it is supposed to do. Annoyance is valuable feedback so it should be gathered as early as possible.

Make sure you're considering these crucial four points next time you want to really annoy the poor souls who find your site!

Saturday, 21 January 2017

Continuous Delivery with Codeship

Nobody needs to be sold the virtues of automated deployment in a professional environment any more. I've found personal projects a bit different though. Generally these do not deploy as often and are for fun and I'm sorry to say that, for me, the idea of maintaining a Jenkins server doesn't really fit into the latter category. Still, as I wrote about a bit in a previous post, I appreciate the value of simple, consistent deployment and so I write scripts then run them by hand as a happy medium between rigorous process and focusing my spare time on the things that make me happy.

Over the last few years continuous delivery as a service has become a thing which (in theory) means I should should be able to take my deployment scripts and have them run automatically when I push something to a master branch in git and all without having to run my own software. I tried this with Codeship in its early days and something went horribly wrong, requiring me to completely wipe my website and restore from backups. This somewhat killed my enthusiasm for trying again.

To be fair to Codeship, this seems to be a very unusual experience. Most people I know sing its praises - both its capabilities and ease of use. Clearly I did something stupid somewhere and so when I decided to have another look at using a service I went back to give it another go.

The product has moved on significantly since I last visited, however it is still pretty straightforward. More importantly, this time I got it to work and didn't destroy anything in the process. So, with my extremely minor requirements in mind, I had to:

  • Set it up to run my tests (just bundle install for me)
  • Set up run my deploy script (one line to trigger the mina script)

Then just test via an empty commit to master and I was done:
git commit -m "Empty commit to test deployment" --allow-empty

This is pretty much the experience I wanted the first time around. Who knows what I did wrong. Some very minor gotchas:

  • You need to run bundle install in the test section to ensure you have your deployment dependencies in the later steps, even if you don't have any tests to run (remember kids, always write tests...)
  • If your deployment scripts involve connecting to a server somewhere you're going to need your project SSH key which isn't the easiest thing to find

And that's pretty much it.

So why did I look at this again? Aside from it being one fewer task to do by hand when doing any proper work, I can now make minor changes on the go via the Github web interface and not need a properly set up environment to deploy them. More importantly, I can also give access to non-developers to edit content in that same web interface and it will automatically push without my needing to do anything. This is great as now what was a static website suddenly has a content management system attached to it.

I can also finally join the "Codeship is great" bandwagon. Sorry I'm late.

Friday, 30 December 2016

The year that was, 2016

Well, I think most people would agree that 2016 sucked. I'll certainly be glad to see the back of it. Aside from the various events we all know about, it's also the year I lost two members of my family. Focusing on the positives though, I have moved jobs and reconnected with a lot of friends many of whom I've not been in contact with for many years. The point of this annual post is to remind myself of things I do to flex my creative muscles and prove to myself that I don't just spent my time watching videos on YouTube and playing Gauntlet.


And I went back to doing some serious exercise and started playing a lot of board games again, not to mention the time spent acting as the Treasurer (and member of the PCC) of my church.

Resolution count: 2/10 - appalling.

I spent a lot of time on technical things and photography this year at the cost of writing. Next year I want to step up the writing and draw some more maps.