I took the opportunity to record the process (with my friend’s assistance) of taking payments from a student’s perspective.

What followed was the single easiest payment process I’ve ever been through.

1. Setup and Send a Paylink

GoCardless Paylinks are without a doubt the most awesome invention in the world of online payments right now.

I choose how much the link charges and how often the person visiting it should be charged (VERY flexible but in my case this was just ‘once’).

I also have the option to set a ‘redirect’ link. I imagine as a company this would most likely be a ‘thankyou’ page, however I know my friend has a love of pugs so I’m going to personalize mine and send her to an amusing pug-related youtube video I think she’ll enjoy.

I dropped my friend the paylink via a facebook message but the beauty of paylinks is that I could have put this anywhere and send it to any number of people, in an email, a text, a direct message on twitter, pretty much anywhere you can stick text or a link. I could have printed it out and sent it via letter if I wanted (although this might have been a little inefficient).

2. Friend Pays

At this point my friend was able to enter their bank details and pay me via the link. I asked them to screenshot all the steps in the process and they sent back two images. One was this:

And the next was this:

Needless to say, she found getting redirected to the youtube clip hilarious :)

Note: There was also the login screen I think since this was their first GoCardless payment but you could almost argue that since they didn’t even mention it it must have been super easy

3. Rolling in $$$

At this point I received an email letting me know I’d been paid:

I could also see the payment on my GoCardless Overview and in my list of payments:

Conclusion

That’s literally it. I do lose 1% of my transaction up to £2 in commission but it’s way less than their competitors and for a process this awesome, it’s a no brainer.

I highly recommend you check it out, maybe you could use it to settle a few I.O.Us, collect the rent or split the heating bill this winter? If you’re a small business, you probably have even more to gain by giving it a look since their API is incredible.

I often wish I could use Travis CI for my projects but usually the repositories are private and so I’m forced to find an alternative (see my previous post on ci).

This time however, my project is fully public and so I wanted to make use of Travis and also get those nice build messages you often see on github like this:

I had a bit of a trial and error first experience with Travis CI so I wanted to note down here how to do it for future projects.

1. Add .travis.yml in the root of your project

This will be used by travis-ci when building your project and defines what to test against.

For my digest email project (a command line ruby gem) it looks like this:

1
2
3
4

language: ruby
rvm:
  - 1.9.3
  - 1.8.7

Mine simply says to test against Ruby 1.9.3 and 1.8.7 but there are a lot more configuration options available depending on what kind of application you’re testing. See here for more info.

2. Depend on the rake gem

Travis CI uses rake to run your tests so you need to require it in your Gemfile. If you want you can only put it in the test group.

1
2
3

group :test do
  gem 'rake'
end

3. Make sure your Rakefile has a default task

Travis CI will attempt to run rake to execute your tests. You need to ensure you have a default task which will run all the tests you wish to execute.

My Rake file for the digest-email gem looks like this:

1
2
3
4
5
6

require "bundler/gem_tasks"
require 'rspec/core/rake_task'

RSpec::Core::RakeTask.new

task :default => :spec

Push this all to your project and you’re ready to link Travis to your repository.

4. Ask Travis to test your repository

1. Visit https://travis-ci.org/ and sign in with github
2. Visit https://travis-ci.org/profile/YOUR_GITHUB_USERNAME

3. Switch on testing for your repo by finding it and flicking the switch. You may need to sync with your github account if the repository doesn’t appear.Also, only public repositories will be visible.

4. Visit https://travis-ci.org/YOUR_GITHUB_USERNAME/GITHUB_REPO_NAME You’ll see the current build status. You’ll notice that travis has yet to run any tests. This will update whenever you push your code to github.

5. The icing on the cake - build status images

This is really simple, in your github readme, simply add the following snippet onto your title, like this (if using markdown):

1

# DigestEmail [![Build Status](https://travis-ci.org/PeterHamilton/digest-email.png)](https://travis-ci.org/PeterHamilton/digest-email)

For other README formats or to show build statuses for specific branches see here

One of the things I made extensive use of in Gmail was consolidating all my email accounts through one main account. From that main account I could receive and send email as any one of many aliases.

However in Mail.app, when I signed in with my Google credentials, I could only send mail from the main account. Disaster.

However while fiddling around I discovered this nifty secret in Mail.app settings where you can enter multiple email addresses in one box.

Completely confused as to why this isn’t publicized, I guess it probably only works if you can successfully send mail from them all through the same SMTP server so isn’t a standard user feature. Great for Gmail Aliases though!

1. Open Mail’s preferences: Mail > Preferences
2. Select your gmail account in the left sidebar
3. Click the ‘Account Information’ tab
4. Add all aliases in the “Email Address” field, separated by commas
5. Exit Preferences
6. Compose new email and select an alias from the Dropdown
7. Make a cup of tea and set your sights on Inbox Zero.

The library was Backbone.Validation and fter looking for a wrapper-gem and coming up empty handed, I decided to create my own. What follows is a walkthrough of the steps I took in order to create the gem backbone-validation-rails to wrap this library up so I could add it to my assets pipeline.

1. Creating the Gem Framework

Bundler is capable of initializing a new gem framework for you very easily.

1
2
3
4
5
6
7
8
9

bundle gem backbone-validation-rails
  create  backbone-validation-rails/Gemfile
  create  backbone-validation-rails/Rakefile
  create  backbone-validation-rails/LICENSE.txt
  create  backbone-validation-rails/README.md
  create  backbone-validation-rails/.gitignore
  create  backbone-validation-rails/backbone-validation-rails.gemspec
  create  backbone-validation-rails/lib/backbone-validation-rails.rb
  create  backbone-validation-rails/lib/backbone-validation-rails/version.rb

It creates a bunch of files and folders (which I cover later) and a README with some TODOs/blank sections and contribution guidelines).

2. Managing Versions

Since the backbone.validation gem will simply be a wrapper for the actual backbone.validation javascript library, we will make the version of the gem track the version of the library.

This is done by modifying lib/backbone-validation-rails/version.rb

1
2
3
4
5
6
7

module Backbone
  module Validation
    module Rails
      VERSION = "0.6.2"
    end
  end
end

3. Adding the Engine

Bundler has helpfully created a new module for our gem, however we need to use a Rails engine. It’s an empty class but it means that the resources for the gem (namely our JS library file) will be included.

If you have used dashes in your gem name, it will assume a modular structure and create a new nested module for each section.

1
2
3
4
5
6
7
8
9
10

require "backbone-validation-rails/version"

module Backbone
  module Validation
    module Rails
      class Engine < ::Rails::Engine
      end
    end
  end
end

4. Including the Assets

Download the files (css/js library) you’re wrapping and if given the option, choose the full (non-minified) version.

The reason I say this is that I included the minified version of backbone.validation in my gem originally and have since regretted it. I would prefer to have readability in development (console/inspector etc) and rely on minification in production using something like Uglifier.

I put the files in vendor/ since they’re externally maintained. This isn’t necessary, I just feel it’s a nice logical structure.

I then nest the folders in the same way as my app. For example, I put backbone.validation.js in vendor/assets/javascripts

1
2

mkdir -p vendor/assets/javascript
curl https://raw.github.com/thedersen/backbone.validation/master/dist/backbone-validation.js -o vendor/assets/javascripts/backbone-validation.js

5. Filling in the Gemspec

The file backbone-validation-rails.gemspec has a number of TODOs left in it. Description, Summary etc.

Fill these in, describing your new wrapper gem. For an example, see the one for backbone-validation-rails here

It’s also worth replacing the default file includes line:

1

gem.files = `git ls-files`.split($/)

with

1

gem.files = Dir["{lib,vendor}/**/*"] + [LIST, OF, OTHER, FILES, TO, INCLUDE]

I had seen this before in other gemspecs and personally feel it’s is a bit nicer than relying on git to grab your includes, especially for something simple like this.

6. Releasing to RubyGems

You’re going to want to push your code to github (for hosting and community love) and ruby gems (for easy distribution). To release your code to rubygems just run:

1

rake release

Note: In order to push to rubygems you will require an account and the first time you release a gem you will be asked to provide your credentials. From then on an api key is stored in ~/.gem/credentials

You can then visit RubyGems and look at your new gem up there for the world to see!

1. Style a div to have a solid background and imagine an image there
2. Create images which are the right size by hand and stuff them in the source ‘temporarily’
3. Host common image sizes somewhere else, like Amazon S3

The methods are messy, time consuming and quite frankly, crap.

Enter placekitten.

An AWESOME site which can serve you an image of a kitten at any resolution you want. Just provide a width and height in the url like so:

1

http://placekitten.com/650/200

BAM, perfectly sized kittens.

It even transpires that there is a Ruby gem for this on github - PlaceKitten

Using this in a rails app is then as simple as adding gem 'placekitten' to your gem file and then adding the following in your view:

1
2

# Insert an 800x600px kitten image
image_tag(Placekitten.kitten_for(800, 600))

I found it nice to have a simple helper function for this:

1
2
3
4
5
6

require 'place_kitten'

# Inserts an image of a kitten with the specified WxH
def kitten_image(width, height)
  image_tag(Placekitten.kitten_for(width, height))
end

As a team we decided that some form of continuous integration was needed and so I set about in search of a solution. We just needed something simple so we could start making use of CI straight away and get the hang of integrating it into our workflow.

I looked at a few potential solutions and have outlined a brief summary of my findings.

Option 1 - Travis CI

Travis CI seems like a fantastic CI system and I’ve seen it all over various repositories and projects so it was my first port of call.

Unfortunately it transpires that Travis CI doesn’t currently support private repositories and given the nature of the project, it can’t be hosted in a public repo just yet.

Apparently you can sign up for early-access to Travis CI at beta.travis-ci.com but it doesn’t appear ready yet.

Option 2 - Roll your own

Another option I considered was a ‘roll-you-own’ approach. Surely it couldn’t be complicated to set up a local virtual machine or even a server in the cloud. This could then repeatedly pull in changes from the git repository and re-run test and integration suites. If anything failed, I could simply have it email/text/notify me.

It sounds simple, but as I discovered, I had grossly oversimplified the process. Whilst this method theoretically worked for this particular project, it would get very complicated when people started branching to work on features etc. I still wanted the other team members to be able to take advantage of the test suites which we were writing, even if they weren’t on the master branch (without too much code-fu).

Option 3 - Circle CI

Similar to Travis CI, Circle CI is currently in beta and so is offering the ability to sign up private repositories on their system for free.

After a very basic setup linking the code repository and their continuous integration system, we were off! A nice clean list of commits (on all branches) and the consequent status of the build/test suite.

There were a few hiccups and it feels much less polished and feature-filled than Travis CI but the functionality is there and it works. On top of this, on the odd occasion we have had questions or issues, the team has been fantastic and taken our feedback on board. The one issue we did have (some failed auto-pulls of my git repo) was fixed within a matter of hours and didn’t really slow us down at all.

Summary

Out of the selection of options above and the few others I looked over, the easiest to integrate with (for this project right now) was Circle CI.

However, if this was an open source community project, I would choose Travis CI hands down. It just seems more mature and also has the weight of the open source community behind a lot of additional plugins and features which.

That’s the idea behind my move to Octopress.

Instead of trying (and failing) to maintain a comprehensive record of 100 different things. I have decided to come up with a small list of things I come across daily which would be worth putting online for reference, information or amusement.

The plan is to back-date some of this to bring my blog up to date with some of the things I have done and forgotten to write about.

So far on my list of topics to cover I have:

1. Useful Code Snippets - So I don’t have to scour the net and my internet history to find that little chunk of code.

2. Tools - There are so many tools and apps which I have set up on my machine. Useful ones should be reviewed or at least mentioned

3. New Languages - It seems almost Every day I experiment with something new and I think it would be good to write down the results, however brief

4. Events - I do a lot of hackathons and should really do writeups afterward outlining what I or my team built

Octopress allows me to type my blog post in a nice simple editor using Markdown syntax on my local machine.

The entire process then fits into a normal development workflow. Create, commit, push. Simple.

Due to the combination of a high workload and my incredible studiousness, I am taking a break from this blog. I really should at least try and pass my exams…

Many tales of development related endeavours are piled up and are waiting to be typed and shared but they will have to wait for another day.

That’s it. For now…

I probably should have blogged about this when it happened but in standard fashion this is a very delayed post.

So, recently some amazing people nominated me for a .net magazine ‘Young Developer of the Year’ award (Thanks guys!). That in itself was pretty awesome, but I have now also been shortlisted as one of the top 10!

If you haven’t had a look at the shortlists for the various categories yet, I highly recommend you do, there is a seriously high concentration of talented companies and individuals up there and I encourage you to vote in as many categories as you can (follow the link below).

I would really appreciate your support in this if you could give it, it means a lot to know people are rooting for you and I would like to say a huge thanks to the many people who I know have already voted for me. That said, if you haven’t voted and feel like you can lend me your support that would be awesome!

If you feel I deserve it, I would grateful if you could Vote For Me

I just met up with our development team for the project we submitted for the Google Interactivism Award! Now that we have won said award and are being given money to develop the project further we thought it was about time we actually did something and got cracking!

So today Myself, Kushal, Florian and Simon all met up to try and verbally work our way through the planning stage of the project. It all went pretty well and we now have a name, domain, dev plan and I think we would all agree an increased level of enthusiasm for this!

In case you hadn’t realised, the idea changed slightly from our original idea when we submitted to Google and now instead of tracking waiting room times, we are showing people the nearest A & E or clinic along with the current waiting time. We are now calling the project e-mergency!

I am pasting a copy of our development slides below for those who are interested

We meet again in a little over a week for our first development sprint so check back here for updates!

Anyway, today I received some very exciting news! But first some background.

After the interactivism hackday I attended a while ago, team NHS TimeTag got together and had a rethink through our idea. Eventually we ended with a slightly different take on the original idea of NHS waiting times in clinics. We have instead decided to target the waiting times in NHS emergency departments. We aim to do this initially using an online service, with a freely available API which could eventually support a mobile app.

The first thing you will be thinking will undoubtedly be the thing which also came into my head during the brainstorming session which was “The last thing on your mind in an emergency will be to check the internet…” Totally true, but that’s not the situation our idea is targeted at.

Instead, imagine you sustain an injury such as a sprained ankle, but decide to sleep on it and see if it gets better overnight on its own (like all good manly men do…). In the morning your foot resembles a footBALL and you decide that regardless of how manly you may feel, for the good of your health you should probably go to A&E and get it seen to.

Enter our interactivism project. Enabling you to locate the nearest and/or least busy A&E department. The benefits of this are twofold:

1. You get seen faster and more efficiently, meaning you’re happy and your foot stops doing an admirable impression of a basketball.

2. A&E departments don’t get overrun with people all coming to them when there might be a perfectly good empty clinic down the road who could deal with your injury, thus relieving the pressure on them.

Now you know all about what we have planned, I am literally bouncing up and down to say: WE WON AN INTERACTIVISM AWARD! So excited, proud of our team and ridiculously eager to get started! Other than the above rough outline, I’m not going to go into specifics yet, we need to meet up as a team for beer and celebrations and eventually maybe even some planning… Needless to say watch this space!

For those who have been paying attention on twitter recently to all things #accessibility and #interactivism related, last weekend LBi Offices were home to the first Google Interactivism event, a student developer accessibility hack weekend organised by Simpl and FutureGov. People from many backgrounds turned up to hack together cool new ideas including accessibility experts, student developers, Gransnet-ers and guys from Google who were there help and mentor us all through it.

I am aware that this has already been covered by some of the organisers of the event and you can find the other write-ups at some of the links below:

• FutureGov – Check out yours truly front and centre
• Lucy Hughes
• thinkpublic

Also, you can see some fab comments from the gransnet members who were in my team (1st three at that link). I know all the gransnetters were amazing but I would like to say a special thanks to ours who even got involved in some coding (of a sort) at one point!

I also highly recommend you check out the Interactivism Flickr Page for loads of pictures from the event. Note the excessively large number of post-its and diagrams everywhere. It was epic.

So, anyway, not sure quite what to expect, I put my name down for the event and turned up on their doorstep at 9am Friday morning, laptop in hand. Seemed like a good turn out but later it became apparent that quite a few people hadn’t turned up, mostly students, this caused quite a few issues when trying to distribute people between all the great ideas but it was definitely their loss!

The talk was started with some info from Andrew Eland at Google and Dominic Campbell from FutureGov on what the weekend was all about and how it would work. We then had a talk from Mike Bradley, a lecturer in Product Design at Middlesex University who had some great points and good things to consider when designing our products regarding user experience. This was followed up by an absolutely brilliant presentation by Peter Oakley, otherwise known as geriatric1927 what can I say, go watch his videos, the man is a genius and an inspiration. We were treated to this gem, I guarantee anyone who has tried to teach their grandparents to use a computer (and of course the grandparents themselves) will appreciate it:

Next up were the people with a plan, these were the guys who had the big ideas on which the rest of us were about to be let loose. Around this point I was getting pretty excited and working out which project to actually choose was definitely proving a challenge.

I eventually chose to work on an NHS Appointment Timetable Board application which would let people know if their appointment was running behind before they set off for a delayed appointment (unknown to them) 4 hours too early. I thought this was great and so pretty much went straight over to join Kate who had pitched the idea. Initially we had quite a few people who obviously agreed with me as we soon had a good group of professionals, gransnet-ers and student developers all itching to pitch in.

Unfortunately, the no-show students (seriously, you missed out!) meant that some teams were very thin on the ground developer/designer-wise and so we quickly lost half our members to other teams, bit sad but it was the fairest thing to do I guess.

We got straight down to it, discussing ideas while a flurry of buzzword and key-phrase post-its flew onto the table from Leisa

Pretty soon we had come up with some good stuff, mostly revolving around text-based messaging for communication with the system to ensure we included people who didn’t have access to a computer or a smartphone. Our idea began to take shape and we gradually got it to a point where we were happy with the features we had come up with.

It was time to code!

This the bit which most excited me, but then I was there as a student developer and the planning stage is never as cool as seeing something being built, no matter how many sticky notes are involved…

For those less technically minded, please look away now.

We decided to go for a Ruby On Rails app because it is my favourite web development framework right now and Florian and Alex (who actually later got stolen by another team – sad times!), the other student developers on our team were willing to give it a go. Lucky me!

We had a shedload of issues setting up our environment on Farouk’s (Our Googler) Macbook Pro due to a load of Snow Leopard Ruby SQlite issues which I had resolved before but couldn’t remember for the life of me how (hence why this blog is now here…)

Like all initial Rails apps it was basic, up and running (as far as models and general underlying structure was concerned) in a matter of minutes. Over next the two days Florian did some cool stuff with Geokit to allow the system to detect the nearest hospital to you (on the web version) and I worked on finding a good Ruby API for sending and receiving text messages – probably a whole blog post in the next few days as it was quite interesting (unless you don’t like that kind of thing, in which case you shouldn’t be reading this bit).

I was personally not looking forward to generating the fixtures and test data for our system, which we would need in order to test everything but luckily our amazing gransnet members pitched in and helped out by typing it all out in the correct format. Yes you heard me, our grannies were CODING. Came up with some brilliant sample data and think they secretly had a lot of fun coming up with pun-influenced doctor and patient names.

We used HAML for our templating language and SASS for a nice programmer-friendly way of generating our CSS files which sped up the design implementation side of things quite nicely.

Code haters, you can read again now, back to pictures and non-geek friendly things…

We called it a night at 10pm (/got kicked out), but me and Florian met up again back at Uni to code late into the night. I had personally prepared in advance:

The next day we met up (my blood-redbull content sitting at dangerous levels..) to mash what we had done code wise with the designs Joe had come up with.

Florain, Me and Joe – our Design Guru

I would try and describe the designs but instead I will just show you what the finished thing looked like:

Cool huh?

To round off the end of the second day, we had a presentation from each team. Ours was prepared by Joe and Kate. Kate did an excellent presentation and I did a quick technical run through, but we had to miss off some of our best features due to time constraints as is often the case.

I noticed this image (see below) in the simpl writeup and thought I should give a shout out to our awesome gransnet members (that’s them in the photo), from those smiles it must have obviously been me and Kate up front! They were true grannies and when they weren’t doing interviews for the filming of the event or coming up with user interface ideas they were helping us out and reminding us to eat “because it doesn’t do you any good on your plate”. You were FAB.

Our awesome gransnet members.

Finally there was the big prize presentation. The main prize went to EZPZ Browser – a simplified stripped down web browser to help people who have never used the internet before to get online. A really interesting concept and had I not been determined to develop something web based I would probably have liked to help out on this. The gransnet prize (voted by gransnet members) was Spotted – an app to share likes, dislikes, photos and experiences relating to disability access. Two very worthy winners!

The winning idea-creators got new Nexus-S phones (Jealous!), with the rest of their team getting ipod shuffles or Android models. Everyone else got free google bits and bobs with quite a few t-shirts given out (Rather pleased with mine and my laptop is sporting a Google transfer sticker this very minute – automatically raises the IQ y’know…).

All in all a pretty awesome weekend! When I was asked on monday what I did at the weekend, I was actually able to say “I sat on my computer for two days living off pizza, beer, curry and coke” without feeling the least bit guilty!

Thanks to all involved and I look forward to seeing you at the next event.

Can’t wait!