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.

Wednesday, 21 December 2016

How to Mac

A while ago I made the switch from iOS to Android and now I find myself needing to make a similar transition - this time from Ubuntu to OSX. I've been using Ubuntu for development for around twelve years and like most developers I use a lot of keyboard shortcuts so to say this new world is scary and unfamiliar is more than an understatement. As before I'm writing this for myself in the future if I have to go through this again, and anyone else who has to do this so you know you're not alone.

Getting started

Out of the box nothing was too painful. Sure, the keys are in the wrong place but that is something I'll get used to eventually. I was shown how to put the mouse scroll the correct way up so that helped with moving around (it's in System Preferences -> Trackpad) and since to start with life was all about Chrome and simple text editing it didn't hurt too much. Except for the loss of function keys and the missing delete key (fn+backspace). Sigh. Still, the hardware is genuinely lovely and I'm very impressed with the battery life. As I type this I've been working all day from the battery and I'm still seeing 41% charge. Now; my Linux laptop has seen some serious miles but I don't remember it ever doing this well. Plus it's really nice having the operating system work 100% including hibernating, sleeping and all the other bits and pieces. That has been getting much better on Linux over the years but if I'm honest it's just nowhere near as good as I'm seeing here.

First shot at some real work

So then I had to start installing tools and getting things set up for actual web development. First up, Chrome. Gone are the days of hitting F12 to bring in the developer tools or a two button shortcut to view page source. Now I have to some weird contortion exercise for the tools and I have to include the command key to view source. Maybe it gets lonely and sad if it isn't pressed often enough? Anyway, my brain will remap this eventually so it's not the end of the world. 

Bring forth the command line

At the suggestion of literally everyone I immediately abandoned the default terminal in favour of installing iTerm2. That involved installing a package manager and a plugin for the package manager. This is weird territory for someone who is used to apt being an integral part of the operating system, but I was still impressed by the screen and battery life so I rode that happy wave a bit longer. First I needed some other odds and ends and eventually a friendly Mac user at work gave me some commands and I typed them in and Things Started Working (because when did just typing in commands blindly ever hurt?). I'm impressed with his wizardly powers, but I'm well aware that one day I'll need to do this again and I may be in serious trouble.

Command history suggests "we" did something like:
  1. install xcode to get gcc
  2. install homebrew: /usr/bin/ruby -e "$(curl -fsSL"
  3. install cask: brew tap caskroom/homebrew-cask
  4. install iterm2: brew install iterm2
Well, if my memory has failed me it's a problem for future me. In the meantime I have a package manager and now an exciting terminal which is all the wrong colours, but that's hardly the Mac's fault. A few tweaks and I'll be up and ... wait, why is the window split in half? 

What do the buttons do?

The terminal is where the keyboard shortcuts really started to hurt. A combination of some of the shortcuts being different, an entirely new modifier key to contend with and my brain attempting to use CMD instead of CTRL except now apparently not all the time produced many, many frustrating mistypes and resulted in a couple of hours rebinding keys. It's now better - not as good as the default terminal in Ubuntu, but very usable and at least iTerm2 lets me save my profile for future use so I don't have to go through that again. 

I also discovered that OSX uses slightly different environment files to Ubuntu so I had to source my bashrc file from bash_profile to get that read properly. Apparently age-old Mac users keep build scripts so a new machine is just configured for them while they make tea. 

At least git works, right?

Yup - no problems here. Well, until I attempted tab completion at which point I was told that I actually needed to install something to make it work, which in turn needed me to reinstall git via homebrew.

  1. brew install git
  2. brew install bash-completion
  3. git config --global push.default simple
That last is, of course, not a Mac specific requirement and shouldn't be needed since git 2.0 but I don't trust default behaviour since Code Vanished back in my last place of work and mild panic ensued. If you don't know what it does you should probably be doing it.

Installing SublimeText 3

I had already realised I wasn't going to be able to directly copy my old Sublime config to this machine as I had a whole new button to work around. Still, I assumed installation would be straightforward then I could spend some time remapping keys until I was more or less happy. I also wanted to be able to use the subl command on the command line to open files like in the old days, but this was proving difficult so I had to call in help (from a different helpful Mac user as I was already feeling like a moron at this stage). The look of horror he gave me when he saw how I was running Sublime told me I had done something wrong. Again.

It turns out that running a downloaded dmg file runs from a mounted volume. I needed to drag my running application to the Applications option in the file browser and then the Mac did some more exciting magic things and everything was fine. Right, not going to forget that one in a hurry.

Where are my windows?

One of the other things I really miss from Ubuntu-land is the way it handles multiple desktops. Maximising a window in OSX puts it into a full screen mode which moves it to its own desktop and makes it difficult to move around if you're used to ALT CMD+Tabbing around. There is a way around this - it turns out that if you hold ALT and click the maximise button you get the old "make big" behaviour and ALT+Green toggles back again.

If you want a keyboard shortcut (and you do) you need to install Spectacle (brew cask install spectacle) then you can maximise (not fullscreen) with CMD+ALT+f. To go back to normal size you can use CMD+ALT+z (thanks to yet another friendly Mac user for that one).

Fortunately, the CMD+` shortcut to move between windows of the same type still works, although harder to use with the § ` key moving to pastures new.

Is it working now?

I think so - or at least it nearly. RVM installation didn't bring up any nasty surprises and seems to be working perfectly. On the other hand, Finder is extremely odd. If, like me, you're used to moving around files with the arrow keys then hitting enter to open them, you might be surprised to discover that enter in fact lets you rename the selected file. If, like me, you then go hunting for the alternate shortcut you may struggle to find it unless (unlike me) you think to try CMD+Down which for some reason will do what you want. I had to ask. Now you don't have to.

These are the reports of my adventures so far. I may do a follow-up when I have to do battle with virtualisation if it proves tricksy (which is likely because, to be fair, it's hardly trivial on any platform) or if anything else thrilling comes up. After quite a few hours playing with this system I'm in a position where it is doing a fair impression of vanilla Linux. Albeit with the keys in the wrong places.

I hope this helps someone. Happy Christmas.

Monday, 14 November 2016

The first day

It occurs to me that, having been working at the University of Bath forever, I have experienced very few first days. For obvious reasons I've been thinking about working environments a lot recently, along with expectations from both employers and employees. The less-than-insightful thought being that the world would be much better if there was less fear. I wonder how many people would make positive changes in their lives, such as moving job, if it wasn't for fear. I know that I'm scared to be moving. Scared that the new place will reject me, scared that I wont be able to do the new job, scared that I wont like my new colleagues. None of these have any basis in reality. There hasn't been anything to suggest the new place will be anything but lovely and although the work will be different I'm definitely up for the challenge - plus they interviewed me and decided I am capable and they should know better than me at this stage.

So really my fear is based on the loss of my old job (which was full of lovely, talented people and a great environment) in the face of an unknown future. But moving on has been the right decision. It has allowed me to advance my career and re-evaluate my professional worth - both of which are Good Things for anyone to do. In turn, the university is going to have to face questions about how it employs developers - questions it can (understandably) avoid while it has people in post - also a Good Thing for the industry as a whole.

If movement is good, why isn't there more of it? That brings me back to fear and for the moment the first day. I know that one way or another I'll be uncomfortable on my first day and that is mostly due to my history of first days. I'm expecting the next one to be better and I'm looking forward to being involved in making them better for others when I'm the experienced one.

My first first day

My first job was as a lifeguard in a place which shall remain unspecified. Memories from that day involve arriving around 5.30am (eugh) and pretty much immediately being sent to set up some giant trampolines on my own. I later discovered that there are supposed to be six trained people involved in setting these things up. Fortunately I was rescued by some more experienced colleagues.

My second first day

My second job was at Unilever. It was a great job but day one was a mess. I was sent to the other side of the country, where nobody knew who I was or why I was there. I ended up interviewing people about a project I knew nothing about all the while wondering when I was going to wake up from the crazy dream.

My third first day

This was the first day working on the University of Bath Helpdesk, although the strongest memory was of the interview. I'd been sitting with a friend (who already worked there) fixing a laptop for him. The supervisor came over, saw what I had done and asked if I wanted to cover the next free shift. I was thrown straight into the action, with a small amount of shadowing an experienced colleague to show me how things worked.

I actually remember very little of this day so it must have been pretty smooth overall.

My fourth first day

My first day as a developer. I was shown to a small office which was about big enough for one and a half people. I was the half. Over the next few days I managed to cannibalise a working computer from various contacts around the university, including some flatscreen monitors from the dawn of time (the desk wasn't big enough for the more common CRT monitors). I managed to borrow a chair from a generous colleague in another office (he had two) then I was shown around the various systems on which I would be working - of which I understood exactly nothing.

Oh and the office let in the rain.

Not that I'm knocking this job. As I'll write about in another post I feel incredibly lucky to have had this opportunity!

No real conclusion here. I suppose the direction I'm heading is that if we want to improve our industry we want to encourage people to be the best they can be, which will likely mean enabling people to move around easily. One problem to overcome is the fear of moving and one of the things to fix there is the inevitably-scary first day. Each environment is different, but some basics (meeting people, first day activities, desk, computer, access) are going to be consistent and we really should have this nailed as an industry by now. So much of fear is the unknown - simply sending out a basic itinerary of the first day should help quell that.

Sunday, 30 October 2016

The rambling story of how I became a developer - part 1

Just recently I've had the privilege of advising a few amateur developers on how to step into the world of professional development. I find this a difficult question but since working with and helping encourage those new to this world is very important and something I hope to be doing a lot more of in the near future I thought it best to get some thoughts in order.

How did I get there?

First things first - I can't claim to be any kind of career expert. My own tale has been a combination of providence and hard work, not particularly shrewd choices as I've progressed - at least not deliberately.

My first IT job was a summer spent as a business analyst, working through a huge data manipulation job and providing the technical expertise to the project manager. This wasn't why I was hired - I was supposed to be doing some kind of data entry as a holiday job - but by a series of coincidences I ended up talking to everyone who the project affected and accidentally doing some in-depth user analysis which led me to ask lots of questions about the best way to move forward. In my first job I learned the importance of the end users.

Next up, I spent a year in user support on a help desk, helping look after a campus full of computers. Again, lots of opportunities to talk to the end users and hear their difficulties and frustrations. This sort of experience is really important for someone who wants to be a good developer. Being able to create great code is important, but if you don't understand the people who will be using your product you will only ever be able to create to the specifications provided by others and that will limit your ability to be effective and put a ceiling on your career.

The help desk also gave me my first proper chance to effect change on my working environment. We had many processes which needed to be more efficient and I was fortunate that the people around me (and particularly my manager) were open to experiment and change. This is understood with the benefit of hindsight and experience - at the time I just had an idea, had a bit of a chat with my manager and gave it a go. Looking back I'm honestly surprised they gave me as much freedom as they did. Being able to critically analyse and successfully question the status quo is an important skill for anyone working in a team and especially in the rapidly-changing world of development.

The first summary

So far I think the key points (other than the rather obvious "make the most of your opportunities") are:

  • get involved with the end users
  • question the world around you

It's never too early in your career to ask "is this the right thing to do?" - it will probably be the most important question you learn. Of course, the other vital part of this skill is being able to ask without annoying and alienating your colleagues. While sometimes it is important to challenge authority or speak truth to power, or whatever the phrase is at the moment it is rarely a good idea to directly butt heads with people higher up the food chain. In a good working environment, questions and discussions should be encouraged (if you're finding you can't ever ask "why" then you're working in the wrong place) but you need to know how to approach such a conversation and when to back out.

Basically, soft skills matter.

More at some point.