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


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 previous 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

(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.

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.

Edit: behold Part 2.

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.