Category Archives: coding for christ

My journey as a Christian software developer

For as long as I can remember, I’ve always had two great loves: Jesus, and computers. My journey has been one of learning how to combine those two great loves, culminating in the creation of the PrayerMate app, which now helps over 30,000 active users every month to pray, and the founding of the UK charity Discipleship Tech to support that mission.

Since I was about five years old, I’ve always known I wanted to be a software developer (except we called them “computer programmers” in those days). I quickly learnt to start copying the code out of BBC Micro Magazines that my Dad would then spend countless hours patiently correcting for me – it was thrilling to see various games and things come to life! Danger Dog (shown below) was the one I most vividly remember – probably a terrible game in retrospect but seeing how these simple lines of text could turn into this incredibly complex experience was mind-blowing to a seven year old!

Eventually my Dad bought me a subscription to Let’s Compute! magazine – a magazine aimed at teaching children how to code. Probably no surprises in retrospect that it went bust after just twelve issues – but it was enough to get me hooked.

Let's Compute!

I also have my Dad to thank for showing me from the offset how my Christian faith and my love for computers could be combined. He created a series of computer animated films based on various Bible stories, titled Bible Story Graphics, starting with Zacchaeus Meets Jesus, and including the Christmas Story. They were something of a labour of love for my Dad, roping in the entire family in different ways (lots of us contributed voices, and my teenaged sister wrote the music for them). They ended up being published by the Bible Society.

Full time Christian ministry?

As a student in Cambridge, my faith, which had always been an important part of my life, really began to grow as I received so much clear Bible teaching, both through involvement in the CICCU and at St Andrew the Great church. It was then that I first felt the desire to do something where I could be directly serving God, and ended up doing a church apprenticeship down in Fowey, Cornwall. It was an incredible year where I learnt so much about myself and about Jesus (not to mention falling in love with Cornwall!) but at the end it was unanimously agreed that I should go and find a job as a software developer for a while, rather than immediately exploring full-time church ministry.

Thus began a long period of wrestling – I absolutely loved being a software developer, working first at a large newspaper company, then a VFX movie company, a small Christian charity and finally at a food delivery company. But at the same time I could never quite shake off this feeling that I wanted to do something more directly gospel-focussed. That was part of the reason I worked a four day week for a lot of my early career as I tried (unsuccessfully, at the time) to create an Old Testament adventure game.

It was at the Christian charity that I had the opportunity to explore how my two “callings” might connect more deeply, studying part time on the Cornhill Training Course in London. As well as being where I met my wonderful wife, that was when I first created the PrayerMate app (which was incredibly simple by comparison in those days – see the video below!) I was playing around with my first ever iPad and it seemed to me that it would be the perfect format for reading people’s missionary prayer letters – rather than them sitting unread in my email inbox, I imagined some kind of automatic prayer list which could suggest who to pray for each day, but then also show me their latest prayer updates so that I could know how to pray for them as well. It took me about 7 years to get to the point where PrayerMate could do that but the idea was born!

I ended up continuing as a software developer for another four and a half years at the startup Hubbub, for which I am so thankful. The people I met and the skills I learnt were such a blessing to me, and PrayerMate would certainly never have become what it is today were it not for that experience.

Making the leap to full-time Christian software development

By the time PrayerMate had reached its first 100,000 downloads, it was becoming increasingly clear that it deserved a lot more of my time and attention than I was able to give to it as a side-project alongside a full time job at Hubbub. And yet with a wife and a growing family there was no obvious way that I could afford to just give up the day job and focus on PrayerMate (if you become a millionaire by running a prayer app then I’m fairly sure you’re doing it wrong). Elise and I prayed about it and talked about it on and off for a good year or so, before eventually on a date night we did a bit of a back-of-the-napkin calculation and came up with a plan whereby perhaps we could afford to take the plunge. I went to my boss and said “something has to change” – fully intending to hand in my notice.

Unfortunately for me, my sense of loyalty got the better of me. Hubbub was at a crucial stage of trying to fund-raise, and with such a small development team with no formal senior developer, they asked me if I was willing to stay on for an extra few months until the fund-raising was complete. They had two offers on the table that they were deciding between, and it seemed like it should all be finalised fairly soon. It felt like the right thing to do, and I agreed.

But the next week, the only developer who had been on the team longer than I had went ahead and handed in his notice. At the time that made me chuckle. Then, before he had completed his one month notice period, the remaining backend developer handed in his notice. I wasn’t chuckling any more. I will be honest, that felt like a real punch in the gut. I remember firing out some kind of email asking people to pray for my faith in that moment. I was left asking “God, what are you doing??” – had I been a complete chump to agree to stay when seemingly nobody else felt any such sense of loyalty? As the only remaining backend developer it felt like even the snatches of unpaid leave I’d been permitted to take each month to work on PrayerMate might be taken away from me.

But it didn’t take long to find the answer to my question. Before that second developer had completed his notice period, the whole team was summoned in to the meeting room. “We’re about to find out which of the offers they’ve decided to accept!”, I thought to myself. Instead, we were informed that not just one but both deals had fallen through at the eleventh hour, and at such short notice there was no alternative but to make the entire company redundant (which, I should add, is a credit to the honesty and integrity of the leadership, who wanted to do everything right rather than leaving people out of pocket or continue working when there was no means to pay them their due).

The news brought with it such a wave of conflicted emotions. On the one hand, it was utterly heartbreaking – all of us had poured so much of our heart and soul into that company, and for those of us who used Hubbub for our weekly shopping, we loved it so much! It was such a stressful time for everybody as people scrambled to work out what was next, and over the following months we ended up saying goodbye to wave after wave (with so many different people on different notice periods, it felt like there was a new leaving party every other week!)

The Hubbub team family
The Hubbub team family

But of course, for me, on the other hand came this great sense of relief, that finally here was my opportunity to walk away without any sense of guilt – and what’s more, with a very welcome redundancy payment in the bank by way of seed funding.

When I told the PrayerMate community that I was stepping out and trying it full time, the response was overwhelming. I will be eternally grateful for the generosity of so many who stepped up and donated and prayed and generally encouraged me in my new mission. When I started I had enough funds for me to do it for about six months – and four years later, here I am still doing it, and having had a second developer full time for two of those years as well! God is so good and it has been an amazing journey. It has enabled PrayerMate to grow closer to that original vision of the app I hoped it might be, and as it approaches its 10 year anniversary it’s been downloaded getting on for half a million times and supports over 1.6 million prayers every single month which I find just mind-blowing – just think what God is doing in response to all of those prayers!

What’s also exciting is that PrayerMate itself is just the beginning. We’ve recently launched the Redeeming Time app to help people reset their relationship with their phone, and turn some of those spare minutes that might have been frittered away on social media to instead feed on God’s word. In the new year we’ll be launching a new “Easter Experience” project for school kids in partnership with UK charity CrossTeach, and I’ve also finally gone back to my roots to explore again the idea of a Bible-based mobile game.


Join me on my journey

If you’ve made it this far, perhaps something of what I’ve said has struck a chord. The reality is that it’s actually been throughout that whole journey that I’ve been using my software skills to serve Jesus, not just the last few years – whether it was at the newspaper company, the VFX company, at Hubbub or when working for a Christian charity. There isn’t some sharp dividing line between “serving Jesus” and “writing code”. And yet, for me, there has been no greater privilege than getting to work full time directly using my skills to serve the gospel as I work on PrayerMate and other similar projects. It’s one of the things that makes Kingdom Code BUILD so fun every year!

If you are a follower of Jesus, I hope that you will be encouraged to continue serving him with your gifts and talents wherever you find yourself.

God has been so faithful to me through all of this, and I am excited about what lies ahead (currently, for me, a Bible Overview mobile game experience). I would love you to pray for me and the Discipleship Tech team in the coming year! You can subscribe to the email newsletter here to stay informed.

How I learned to love Swift as an Objective-C developer

Having been coding in Objective-C for getting on for a decade now, I’d viewed Swift as something of a minor irritation – yet another new thing to have to learn. I’d dabbled in it on occasion when trying to develop new features for PrayerMate – but given very limited available time, I’d often find the overheads of having to struggle with an unknown language far outweighed any potential benefits and I reverted back to Objective-C.

With the advent of SwiftUI last summer it was clear that the tide was turning, and I made a resolve to write all new code in Swift wherever possible, and actually discovered that it wasn’t quite so bad as previous experiences had led me to believe. I’m not able to use SwiftUI yet in PrayerMate because I still support back to iOS 10, but it was increasingly obvious that Objective-C’s days were numbered. In fact, as far as I’m concerned, the real motivation for adopting Swift has not been Apple at all, but Stack Overflow – increasingly the answers there are all related to Swift, with fewer and fewer providing Objective-C alternatives.

But then over the autumn I started developing a new hobby app (still mostly under wraps) and since it was just for fun I decided to go all out and do it 100% Swift, using SwiftUI and lots of other things that I wasn’t able to explore with PrayerMate. And I have grown to not only tolerate Swift, but to LOVE it. Coding in Objective-C feels positively stone aged now by comparison.

Here are the three features I discovered that helped me to learn to love Swift:

1. Type inference

I’m not a very good one for reading the manual, but with a background in C++ I’d previously assumed that you had to explicitly state the type of each of your variables in Swift. I’d been writing code like this:

let a : Int = 5

What a pain! And totally unnecessary. Swift does all the hard work for you:

let a = 5 // : Int is inferred
let b = [[1,2,3],[4,5,6]] // [[Int]] is inferred

2. Guard statements

Previously my experience with using Swift and UIKit was a complete swamp of optionals and having to explicitly use “!” everywhere and just hating it. Discovering “guard” statements and the ability to turn an optional in to a non-optional then has been a revelation:

if ((view != nil) && (view!.frame.size.height > 5)) {

can instead become:

guard let v = view else { return }
if (v.frame.size.height > 5) {

3. Functional programming features

Combining the two features above, and it then becomes insanely easy to write the kind of functional code that I’m used to writing as a Ruby developer:

let b = { doSomethingCleverWith($0) }
let b = myArray.compactMap { $0 > 5 ? otherFunc($0) : nil }

…only it’s better than Ruby because the compiler checks in advance that your transformations are actually doing what you expect them to by type checking the results for you.


There’s more that I could have said, but all in all I’m really glad to have gone all out on Swift for this new project, and it has given me an appreciation for this language that was not at all my experience previously. If you’ve now already taken the plunge, give it a try!

BUILD 2018 – Christian hackathon weekend


The Kingdom Code “BUILD” weekend is back for 2018 – 24 hours to form teams and work on projects inspired by our Christian faith. This year we have two amazing partner organisations who have set some fantastic challenges:

1. Bible Society: How can digital tools help increase appetite for and engagement with the Bible in the 21st century?


2. Stewardship: How can we use technology to inspire and enable greater generosity in the Christian community?


Get your tickets today!

Kingdom Code BUILD ’17 – Christian Hackathon weekend


For the third year running, Kingdom Code UK will be hosting a hackathon weekend for Christians in the world of technology – an opportunity for Christian coders, designers, project managers, tech entrepreneurs and general enthusiasts to gather for 48 hours to build new technologies inspired by our Christian faith.

This year we’re hugely privileged to be partnering with two excellent Christian charities: Christians Against Poverty and Home For Good. They’ve each set a challenge (below) and hopefully it will be a fantastic weekend!


Not convinced it’s for you? Read my post from last year: Why YOU should attend the hackathon (and some bad reasons not to).

With a month still to go we’ve already got 50 signed up but we’re praying for 100. Book your ticket TODAY!

How to encrypt a Google Firebase Realtime Database

The problem: protecting sensitive user data in Firebase Realtime Database

For a while now I’ve been working on implementing user accounts in the PrayerMate app so that users can sync their private data to the cloud and share it between their different devices. Think of PrayerMate as being like an Evernote equivalent but specifically focussed on recording different prayer needs – some of them ones of a highly personal nature either about yourself or about close friends that you’re praying for.

Ever since Google announced their revamped version of Firebase a year ago I’ve been in love with it as a platform – the Firebase Realtime Database in particular makes authenticating users and syncing their data to the cloud as easy as pie. But there’s one big drawback: anybody with admin credentials for the Firebase project can browse all of that private user data at will. Equally, Google’s infrastructure is pretty rock solid in terms of security (I went to a presentation about it at the recent Google Cloud Next conference in London – and it is seriously cool stuff) but the consequences of a hacker getting hold of all of that user data doesn’t even bear thinking about.

That’s why I’ve been looking for a solution that allows users to still sync all of their data between their devices via Firebase, but whilst preventing me as the developer (or anybody else who somehow got hold of a data dump) from reading that data. At the same time, I wanted to do it in a way that meant a user who lost their phone wasn’t completely locked out of all of their data for all time – even people with just a single device are frequently asking me to implement sync as a backup mechanism.

Thankfully Google’s own infrastructure provides some really cool tools that made solving this surprisingly easy – and since even people within Google / Firebase themselves didn’t seem overly aware of what was on offer, I thought it was worth blogging about my experiences.

Step 1: A cross-platform encryption/decryption solution – RNCryptor

My first day of this project was spent looking for an encryption/decryption library that met the following requirements:

  • Data could be decrypted across both iOS and Android phones
  • Production ready / stable
  • Actively maintained
  • Actually secure
  • Performant (fast encryption / decryption)

Considering the year is 2017 this was a remarkably difficult exercise. Almost every library I came across had huge warnings either on the iOS version or the Android version saying “The library on the other platform uses really insecure defaults which I had to incorporate for compatibility purposes”, or it hadn’t been touched in four years, or it had a gazillion issues logged against it.

I eventually settled on RNCryptor-objc / RNCryptorNative. When I last looked at RNCryptor a few years back the only option on Android was JNCryptor which was ridiculously slow (multiple seconds per operation) and which I now notice is covered in warnings saying “Do not use on Android”.

Step 2: Securely synced encryption keys using Google Cloud KMS

With RNCryptor implemented on both platforms, that just left the little issue of how to actually sync the user’s encryption key between their devices. A naive solution would be to store that key within the Firebase database itself – that would at least prevent me from accidentally reading people’s private data (at least nothing would be stored in plain text) but would still make it trivial for anybody with access to the Firebase data to decrypt anything they wanted to.

At Google Cloud Next I came across the Google Cloud Key Management Service, and could immediately tell there was some potential here. The Google Cloud KMS lets you create encryption keys which can then be used to encrypt and decrypt data. My first assumption was that I’d generate a key for every user, but for PrayerMate’s 25,000 monthly active users that would quickly reach at least $1,500 every single month. After a chat with some of the very helpful Google Developer Advocates I quickly realised that wasn’t what I needed at all – just a single KMS key could be used to encrypt and decrypt a user’s data encryption key (DEK).

In the end what I came up with was to build a super-simple authentication service in the Google App Engine Flexible Environment. When a user first logs in to PrayerMate, the auth service generates them a new DEK which it gives to them, as well as encrypting it in KMS for storage in Firebase. When the user logs in to their second device, the auth service takes the encrypted key from Firebase and again uses KMS to decrypt it for the user to store in their device’s local keychain (where it is again stored in encrypted form).

Importantly, the KMS key belongs to a different Google account to the Firebase database, so no one user (e.g. me) has permission to both read the data AND decrypt it. A hacker would need to compromise both accounts to access the unencrypted data.

Step 3: Authentication of Firebase users via Google Cloud Endpoints

Where things get REALLY cool, however, is with the introduction of Google Cloud Endpoints in to the mix. This is basically a proxy layer that sits between your user and your backend, but which, crucially, understands the concept of Firebase authenticated users and can validate those logins and tell your backend who somebody is.

This means that each time we generate a new DEK for a user we can encrypt it along with their user ID, so that when somebody comes along later requesting to decrypt a particular DEK the backend can verify if it actually belongs to them.

On the whole, the documentation for Google Cloud Endpoints is pretty good, and if you persevere long enough you can probably figure out how to get it working. I got stuck on a couple of points: firstly, I got myself in a muddle about what to put in the endpoints_api_service section of app.yaml and how it related to the host property of openapi.yaml. There are so many different deployment combinations that the Endpoints documentation struggles to make it very clear – but if you are deploying to the flexible app engine you just use the same [PROJECT_ID] form in both places, and your endpoints_api_service.config_id is just what you get given when you deploy your proxy configuration using gcloud service-management deploy openapi.yaml (usually something like “2017-01-01r0”).

The second place where I got really stuck for a while is how to actually enable Firebase authentication on the backend. The Endpoints documentation talked about a X-Endpoint-API-UserInfo header but for the life of me I could not get it to be injected at all. Eventually, I discovered the missing instruction from the documentation (and hopefully they’ll soon accept my request to fix that): after you have added your firebase entry to the securityDefinitions section of openapi.yaml you then ALSO need to actually use that security definition by adding a section like this:

  - firebase: []

Update: I have now open-sourced the code for my backend service as firebase-keysafe. Contributions would be welcome if you spot room for improvement.

Fancy working for PrayerMate?
Android Developer Wanted

If solving interesting problems like this sounds like your cup of tea, all in the aid of helping the world to pray more, then you should know that I’m currently on the look out for a full time Android developer – ideally based in London – either on a short-term contract or more permanent. I’m looking for somebody who is fully committed to the aims of a Christian prayer app like PrayerMate and who is able to be more than just a code-monkey following a tightly defined spec but instead is able to partner in helping build the best possible prayer platform to mobilise the Christian church to pray. If that sounds like you then please get in touch!

Why YOU should attend the Kingdom Code Hackathon (and some bad reasons NOT to)

hackathon For 2017 Indigitious are helping organise simultaneous #Hack weekends around the globe – Christian hackathon events where technologists will gather together to work on projects inspired by their Christian faith. This includes the Kingdom Code BUILD weekend in London. But chatting to a few people, I realise there’s lots of people out there who had prematurely dismissed the idea of attending because they decided it wasn’t for them – what a shame! So I just wanted to spend a bit of time going through some of the reasons why you should come along – and then try to debunk a few of the bad reasons you might have for not coming.

Reason to come #1: Because you can see the potential of technology

Love it or loathe it, technology is all around us, and it’s not going away any time soon. In the last 10 years, the amount of time young people spend on their mobile phones has tripled to almost 28 hours a week. We could decry this as a blight on our society, but we could also recognise the huge potential in this to harness technology and use it as a tool to help reach people with the gospel and grow disciples of Christ.

It could be that you have a specific idea of a way to do this – perhaps an app or a website that you would like to see built. Then come to the hackathon and pitch your idea! Or maybe you don’t have an idea, but you would love to support others who do – either with your dev/design skills or just with your raw enthusiasm – come! The ideal hackathon team has a real mix of skills – including people who are simply “a bit like the people who might end up using the final product”, even if they don’t feel they have the skills to actually “build” it.

Reason to come #2: Because you want to use your gifts for God

For some people, you have very specific skills that are relatively rare in the church: maybe you can code, or you are a designer or a product manager. No matter where you are in your journey of developing those gifts, a hackathon is a great opportunity to channel them into building something that is specifically kingdom-oriented. It won’t be that every single project is explicitly “Christian” – but all of them will be reflecting the Christian values and worldviews of the teams who build them, and it will help you to see how the person God has made you to be can make a difference in the world.

Some of the projects will just be a “proof of concept”, some will just be a chance to tinker with an interesting new technology (or one that’s new to you). But we also hope and pray that for a few of the projects, this will be the birth of something that will go on to have a genuine and lasting impact for eternity. If that’s not enough to get you excited then I don’t know what else to say!

Reason to come #3: You’ll learn loads

If you’ve ever tried “pair programming” you’ll know how much you can learn by working closely with another person, no matter how experienced you already are. A hackathon is a great way to hone your skills and collaborate with others and pick up new ideas. I have many fond memories of last year getting to peek into the work that other teams were doing, or answer the odd question about a niggly iOS bug or obscure syntax error. We had quite a few students who came last year and I think they’d all testify to the fact that it was a great learning opportunity for them – I know it certainly was for me! I had the opportunity to be challenged to think differently about my project by people with a different breadth of experience to me, and I know that I personally grew through it.

Reason to come #4: You’ll build some great relationships

In my experience, the best friendships are born out of working side-by-side with people towards a common aim. Sounds like the perfect description of a hackathon! You’ll meet all sorts of like-minded people from across the country (and across the world!) and through the process of working together on a project you’ll get to know each other and build some great relationships.

Reason to come #5: It’s a lot of fun

Last but by no means least, hackathons are just a lot of fun. Last year’s event had such an amazing atmosphere to it, of the body of Christ collaborating together to build some amazing things. Everybody was there to help everybody else, there was excitement for what we were doing, fantastic food, great coffee, an awesome venue, and generally it’s hard to imagine you could be doing anything else more fun than this with your weekend.

Bad reason not to come #1: “I can’t code!”

Irrelevant. As we’ve already said, the ideal hackathon team has a real mix of skills – and anyway, the actual ‘coding’ part of the weekend is probably relatively small, in some ways. The weekend starts with the “ideation” stage, as people pitch their ideas and teams are formed. But then there’ll be plenty of planning and designing and working out what this thing that you’re trying to build actually is. The enthusiasm of people who might one day become end users of the product is just as valuable as the raw coding or design.

Related to this is the “I can’t code very well!” excuse. That’s exactly why you should come – so that you can learn from others more experienced than yourself. You’ll get to see how real software is built from the idea stage right through to completion and then presenting it to others. Awesome.

Bad reason not to come #2: “I don’t have an idea!”

This is a particularly bad reason for not coming. Generally speaking, hackathons take place in teams. There were a few people last year who worked on their own (either for all or part of the weekend), but the majority were part of teams of 6-8. So even the people who did have an idea didn’t all get to actually tackle that idea over the weekend – and there was certainly plenty of room for people who didn’t have an idea of their own but just wanted to help build somebody else’s.

Bad reason not to come #3: “I couldn’t possibly stay awake all weekend!”

No, of course not! I think this is a common misconception of a hackathon weekend, that you’re expected to forego sleep for the entire weekend. Last year we did have maybe two people who pulled all-nighters (possibly even an all-weekender) but they were definitely the exception rather than the norm. Sheer enthusiasm and a desire to make progress possibly meant some people slept rather less than normal (we have a dark/quiet area set aside for sleeping bags etc) but most people know themselves well enough to recognise that they will do their best work if they’ve actually had some sleep.

Bad reason not to come #4: “I haven’t got a ticket!”

Well until midday on Thursday 19th October 2017 it’s still not too late to remedy this – in London at least! Get your ticket RIGHT NOW.


XCode 7 freezing whilst tooltips appear over project navigator

I’ve been having an extremely frustrating experience developing PrayerMate within XCode 7 recently, where the whole editor would just freeze for 30 seconds at a time. It seemed to work fine as long as I stayed within one file, but as soon as I needed to switch to another file, I’d have to wait again. Sometimes I’d see tooltips flash up over various filenames in my project navigator, ones that perhaps the mouse had glanced over half a minute earlier.

Clearly this is a bug in XCode (and an infuriating one at that!) but the workaround was remarkably simple and fixed the problem completely: make the project navigator pane ever so slightly wider, until none of your longer filenames get truncated with “…”.

800 Christian developers and designers in one global hackathon


This past weekend, 800 or so Christian developers, designers, entrepreneurs and technology fans gathered in 13 separate cities around the world for the Code for the Kingdom global hackathon.

Here in London we had about 120 or so folks gathered, and 18 separate projects – both ones aimed at helping Christians in their walk with God, and ones aimed at serving the wider world:

  • Flee! – a low-touch accountability app that pings you appropriate Bible verses when it spots you typing inappropriate web URLs
  • My refuge – “AirBnB for refugees”
  • Let’s pray for… – a prototype for a fantastic social prayer app, that I really hope comes to life soon!
  • Homely – a service to help people give financial aid to homeless people
  • B40 – helping teens pray intensively for breakthrough over 40 days
  • Adventure – an evangelistic Christmas treasure hunt
  • Tearfund Disaster Response – a practical tool to help responses to emergency situations
  • Peri – find the Christians that live and work nearby
  • Biybl – “Bible In Your Best Language”, a simple tool to help international visitors to your church follow the Bible readings
  • SeedBox – Digital Asset Management for church sermon videos / audio etc
  • LazyWorship – automatically display the correct verse/chorus on your projector as the software identifies the audio
  • Good News – a place to champion the good things that happen
  • Mentorship – a place for younger Christians to find people to mentor them, and vice versa
  • Where’s the meaning? – helping businesses avoid ambiguity in communication
  • Power of prayer – a simple SMS based service to help people pray
  • Worship helper – a quick way for band members to communicate key signature, tempo, etc
  • Verse of the day – Microsoft Band app to give you a verse each day
  • PrayerMate – simplifying and overhauling my prayer app

It was a brilliantly encouraging weekend, so fantastic to see people collaborating together to build genuinely useful things. The food was great, the fellowship was great, the projects were great.

Here’s a video that Dan Rackham put together to give you a flavour of our London event:

Bring on Code for the Kingdom 2016!

Developers and designers serving God with their gifts

“Whatever you do, whether in word or code, do it all in the name of the Lord Jesus, giving thanks to God the Father through him” (Colossians 3:17, sort of)

When I was working on my Bible-teaching computer game, this was the verse I used to put at the top of all of my source code files. Obviously I’m playing a bit fast and loose with the translation, but I think the intent is valid. All of us as Christians have been entrusted with certain gifts that God calls us to use in his service. For some of us that’s making a really good cup of tea to encourage the congregation on a Sunday morning and to make fellowship possible. For others it’s the remarkable gift of administration – that incredible ability to make things happen, that sounds really boring on paper but which those of us who lack it are immensely thankful for. For yet others its a deep understanding of electrical hardware like amplifiers and microphones and the ability to make sure that the speaker is loud enough but that the band is not too loud. Whatever our gifts, God calls us to use them to the glory of Christ. And not just in church – we can serve God with those gifts by enthusiastically serving others in the workplace too, or in our communities. The important thing is that we use those gifts, with the glory of God in mind.

For some gifts it’s easier than others to see how they can be used for explicitly Christian ends. Software development is one which sometimes seems harder. In our culture, software developers are like wizards. They have an incredible ability to make magic happen – to conjure up reality from mere ideas with the power of language. They have a “secret knowledge” beyond the understanding of outsiders that has a tendency to inspire awe. To a fault, many software developers know that they have the power to change the world – sometimes more so that is actually the case (sorry Facebook – you’re not going to bring about world peace, however many billion users you manage to sign up). But yet we often lack confidence that this is true when it comes to the growth of God’s kingdom and the spread of the gospel.

For many many organisations, which includes Christian ones such as charities and church plants just as much as for dot com startups and internet delivery businesses, the single most limiting factor is the technology resource – having the right person or people in place to design and develop something that can make a spark of an idea into a living and breathing product (or even just to support admin staff struggling with a too-simplistic database). If only Christians with gifts as developers and designers appreciated how precious their gifts could be in God’s service, I think we’d see some pretty incredible things happen. Last autumn I had the privilege of meeting Gerald Hinson who gave up a successful job at Microsoft to follow God’s call and build David vs Goliath, an incredibly fun and engaging retelling of the classic Bible story for iOS and Android. I found his story really inspiring – he’d never done anything like it before, but he saw a need, saw how God had given him the talents and the connections and the passion to make it possible, and he made it happen, despite all the challenges and an awful lot of hard work along the way.

From the 2nd-4th October this year, I’ll be participating in a “Christian hackathon” in London organised as part of a global Code for the Kingdom weekend. The big prayer is to get together a hundred or so developers, designers and tech entrepreneurs to dream big dreams, meet like-minded people and hopefully give birth to a diverse bunch of projects geared at meeting various needs of the church and the world for the glory of God. It’s a pretty big risk that the organising team and the sponsors are taking on – they’ve hired an incredible venue (the Impact Hub Westminster) and there’s no guarantees – but they trust in a big God and they know that he loves it when people desire to serve him with their gifts. So will you join us? And will you help spread the word and tell people and cajole people and pester people until they sign up? Early bird prices are only available for another few days until 31st August – but even then they’re not expensive for what you get.

“From everyone who has been given much, much will be demanded; and from the one who has been entrusted with much, much more will be asked” (Luke 12:48)
How will you use your gifts?

Adding Coach Marks to an iOS App with DDCoachMarks

For years I’ve wanted to have an in-app tutorial in my PrayerMate app that would use what are known in the UX business as “coachmarks” – a kind of guided tour of the basic functionality of the app whenever it is first installed. Prompted by a colleague, I finally decided to give it a go recently, and settled on using Darin Doria’s DDCoachMarks library for iOS (I also had to implement this on Android using a different library). Here’s the results:

I had to make a few little tweaks to the library so that it would handle long captions in its bubbles and so on. That left two main challenges: handling rotations, and handling scrolling.

Handling rotations

If a user rotates their device half way through a tutorial, DDCoachmarks kind of freaks out. This is understandable, since we’ve defined all of our bubbles in screen co-ordinates, and those co-ordinates completely change when a device rotates. I solved it by making my DDCoachMarksViewDelegate monitor for device orientation change events. Just before my [coachMarksView start] call I added this:

// Start listening for rotation events
[[UIDevice currentDevice] beginGeneratingDeviceOrientationNotifications];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(deviceOrientationDidChange:) name:UIDeviceOrientationDidChangeNotification object:nil];

[coachMarksView start];

Then I handle those events like so:

- (void)deviceOrientationDidChange:(NSNotification *)notification {

//Obtaining the current device orientation
UIDeviceOrientation orientation = [[UIDevice currentDevice] orientation];

//Ignoring specific orientations
if (orientation == UIDeviceOrientationFaceUp || orientation == UIDeviceOrientationFaceDown || orientation == UIDeviceOrientationUnknown) {

// We need to allow a slight pause before running handler to make sure rotation has been processed by the view hierarchy
[self performSelectorOnMainThread:@selector(handleDeviceOrientationChange:) withObject:self.currentCoachMarksView waitUntilDone:NO];

- (void)handleDeviceOrientationChange:(DDCoachMarksView*)coachMarksView {

// Begin the whole coach marks process again from the beginning, rebuilding the coachmarks with updated co-ordinates
coachMarksView.coachMarks = [self coachMarksAfterRotation:coachMarksView];
[coachMarksView start];

Of course you also then need to stop listening for rotation events after the coachmarks are finished:

- (void)coachMarksViewWillCleanup:(DDCoachMarksView *)coachMarksView {
// Stop listening for orientation changes
[[UIDevice currentDevice] endGeneratingDeviceOrientationNotifications];
[[NSNotificationCenter defaultCenter] removeObserver:self name:UIDeviceOrientationDidChangeNotification object:nil];

Handling scrolling

The bigger headache was that some of my coach marks were related to UI elements that were off the bottom of the screen, requiring me to scroll to bring them into view.

To handle this, I have a delegate callback each time a new coachmark is shown:

- (void)coachMarksView:(DDCoachMarksView*)coachMarksView willNavigateToIndex:(NSUInteger)index {
// This is app-specific code to look up the UIScrollView that's currently being looked at
UIScrollView* scrollView = [self.rootViewController currentScrollView];
if (scrollView == nil) {
// No scrolling possible

// Look up the details of the coach mark that's about to be displayed
NSDictionary* coachMark = [coachMarksView.coachMarks objectAtIndex:index];

// I added some extra info to my coachmarks dictionary to indicate which coachmarks might require scrolling
if ([coachMark objectForKey:@"scrollView"] == nil) {
// No scrolling required - so always scroll back up to the top
[scrollView setContentOffset:CGPointZero animated:YES];

CGRect markRect = [[coachMark objectForKey:@"rect"] CGRectValue];

// Modify coachmarks according to scroll offset
CGRect modifiedRect = CGRectMake(markRect.origin.x, markRect.origin.y - scrollView.contentOffset.y, markRect.size.width, markRect.size.height);

// See if the coachmark is offscreen or not
if (!CGRectContainsRect([self visibleRectForCoachMarks:coachMarksView], modifiedRect)) {
if (scrollView != nil) {
// Scroll until it's in view //
// Convert from screen co-ordinates into the co-ordinate system of the UIScrollView
CGRect markInScrollView = [self.rootViewController.view convertRect:markRect fromView:self.rootViewController.navigationController.view];
markInScrollView = [scrollView convertRect:markInScrollView fromView:self.rootViewController.view];

// Record the current scroll position
CGPoint originalOffset = scrollView.contentOffset;

// Then scroll without animation to work out how far we need to scroll
[scrollView scrollRectToVisible:markInScrollView animated:NO];

// Modify coachmarks rectangle by scrollView offset
markRect.origin.y -= scrollView.contentOffset.y;
markRect.origin.x -= scrollView.contentOffset.x;

// Update the coachmarks array
NSMutableArray *newCoachmarks = [coachMarksView.coachMarks mutableCopy];
NSMutableDictionary* mutable = [coachMark mutableCopy];
[mutable setObject:[NSValue valueWithCGRect:markRect] forKey:@"rect"];

[newCoachmarks setObject:mutable atIndexedSubscript:index];
coachMarksView.coachMarks = newCoachmarks;

// Now put the UIScrollView back where it started and ANIMATE it into position - this is just so that it looks nicer
scrollView.contentOffset = originalOffset;
[scrollView scrollRectToVisible:markInScrollView animated:YES];


And there we have it! Beautiful coachmarks and a user who knows exactly how your app works as though you were right there next to them explaining it all.

Many thanks to Darin Doria for his hard work on this handy little iOS library.

Is technology morally neutral?

Last year I did a talk on “How should Christians engage with technology?“, largely based upon Tim Challies’ excellent book “The Next Story“. A year down the line, I’ve been asked to give this talk again, and in preparation I decided to read another book that I’d been recommended, John Dyer’s From the Garden to the City – and I have to say, I think this is one of the best books I have read in a long, long time.

Dyer’s conclusions are very similar to those reached by Tim Challies, but his book has really helped add depth to my understanding of this topic – I’m really thankful to God for the gifts he’s given to both of these men in understanding both his word and his world!

Is how we use our technology all that matters?

Last year I said this:

“technology by itself is what we might call “amoral” – that is, it is neither overwhelmingly good nor inherently evil. Like lots of things in this world it’s something with great power for good but which is also deeply affected by the fall. What’s important is how we use that technology – what we use it to do, and what we allow it to do to us.”

Reading “From the Garden to the City” really sharpens this idea up. Dyer uses the example of a shovel: of course a shovel is amoral, neither overwhelmingly good nor inherently evil. You can use it in all sorts of different ways – to dig wells in remote villages, or to hide the body of the person who you’ve just hit over the head with it. You have a great responsibility to use your shovel in a constructive rather than a destructive way. But don’t underestimate the extent to which the shovel will change you in the process – completely independently of whether you use it for good or for evil. Dyer says this:

“stop for a moment more and look down, turning our palms towards our eyes; we’ll see that our hands, too, have been changed by the shovel. They will be rubbed raw, exposing the first sign of the blisters that are sure to develop while we sleep.”

Technological Determinism vs Instrumentalism

If we simply say that how we use our technology is what matters, then that would be to fall into the trap of what Dyer calls “instrumentalism” – technology is merely an instrument in our hands, and all that counts is what we do with it. This other end of this spectrum would be “technological determinism” – the idea that “technology is an unstoppable power that has become the driving force in society. Whilst instrumentalism claims that technology is completely inert and has no operative power in culture, determinism makes the opposite argument, saying that technology operates completely independently of human choices.”

Dyer encourages us to chart a middle way between these two extremes, and to recognise that “people are free to choose how they will use their tools, but that the tools themselves are oriented toward a particular set of uses that will emerge when a large number of people use them” “A person is free to use a phone as a paperweight, doorstop, or hammer, but people will tend to use phones to accomplish what they were designed to do– communicate with people”. Determinism says that all of America’s guns are the reason their murder rate is so high, whilst instrumentalism declares that “Guns don’t kill people, people do”. I think Dyer is trying to say that whilst it’s true that guns themselves don’t kill people, they do have a certain in-built natural tendency. “Whatever our beliefs about guns in society, we must acknowledge that a home with a gun is a different place than one without a gun. When we bring a gun into a home, we also bring with it a set of cultural practices… such as keeping it locked away, never pointing it at anyone, and only touching the trigger when you are ready to fire. Even if the gun is never taken out of its case, the presence of a gun commands a different way of life than a life without guns.”

God uses technology too

Dyer gives several examples from the Bible of God making use of the innate values of particular technologies. In a particularly fascinating chapter, he talks about the first tablets in the Bible – not iPads, but literal stone tablets, when God gave Moses the law on Mount Sinai. He points out that at the time Israel was in the wilderness, “alphabetical writing was still a bleeding edge technology”. He goes on to say that “people could only afford to write down what was of the highest importance to them… This meant that when people invoked the words ‘It is written,’ they were appealing to the authority of the medium. After all, it wouldn’t be written if it weren’t important… God was giving the world his final, authoritative, and unchanging Law. And he chose a technological medium that reinforced those values.”

By literally setting the law in stone, God was telling Israel something important: that his word would stand forever, and was to be passed down from generation to generation.

How to be a responsible technology user

My conclusions from last year still stand:

“My goal here is to encourage us all just to be a little more thinking in our attitude to technology – not to reject it outright, nor to embrace it unquestioningly. Instead, to try to see beyond the superficial and to think a bit more about how it affects us, and why we feel about it the way we do.”

If all technologies have their own built-in tendencies and values, then thinking through what they are likely to do to us becomes extremely important. In what seemed to me like possibly the most crucial sentence of his entire book, Dyer writes this:

“Instead of living our lives according to the values of new technology, [Albert] Borgmann urges us to determine what our values are first and attempt to use our tools in service of those values.”

I said last time that the mobile phone was invented to keep businessmen in contact with the office at all times, so it shouldn’t surprise us if one of the effects of a mobile phone is that suddenly we find ourselves connected to the office at all times. But realising this in advance helps us to be prepared – and to decide if we really want this to be the case. Now we are free to make choices – to turn it to silent at the dinner table or when we meet our friend for coffee, allowing our own values to control our technology and not the other way around.

A story of technology

“From the Garden to the City” constructs it’s argument through the Biblical story from Genesis through to Revelation, under the heading of four ‘R’s: Reflection, Rebellion, Redemption and Restoration.

Reflection is the world of Genesis 1+2, as human beings are made in the image of their Creator, reflecting his character – they are in turn little creators themselves. Dyer says “Steve Jobs, Michael Dell and Bill Gates don’t claim to be Christians, but their products reflect the creativity of God as well as the longings of the human heart.”

Rebellion is what happens in Genesis 3 in the fall, as humanity turns its back on God. We see such an example of the fall working its way out in technology, distorted and used against God, in the cross of Christ: “Jesus and his father would have been ‘doing technology’ when they used tools to transform pieces of wood into something useful” “In another strange irony, the technology with which Jesus worked– wood and nails– was the technology on which he died– a cross. Jesus could have been executed using any number of more ‘natural’ means, but in God’s great plan the way he died was decidedly technological.”

Redemption is what happened at the cross – though humans were using wood and nails in rebellion against their Creator, God in his wisdom was using this very act of rebellion to redeem the world and make a way for us to be brought back into relationship with him. God has often used technology in this process – e.g. Noah’s ark, which is one of the very earliest examples of technology in the Bible.

Finally, Restoration – looking forward to the New Creation that God promises to bring in. Dyer points out that the New Creation is described not as a garden – a return to Eden – but as a city, “full of human creations like buildings, roads and trumpets”. There we will relate both to God and each other without mediation – no more flickering screens or priests going between us.

I found this framework really helpful in thinking about technology from a Biblical perspective – it helps guard us against a shallow approach that simply embraces technology wholeheartedly or rejecting it outright.


Dyer closes his book with various recommendations about how to engage with our technologies – and I don’t want to steal his thunder by repeating them all here. Buy his book and read them – they’re really helpful! Ultimately it comes down to actually thinking through the impact our technologies are having on us, and as we said before “determine what our values are first and attempt to use our tools in service of those values”.

Should I leave my dead end job, even if it means leaving my church too?

Somebody emailed me recently with a very important question, and I thought other people might benefit from an answer, so with permission I’m posting (a slightly paraphrased version of) the email here:

“I am currently in the midst of making a difficult decision. I think my current job isn’t really helping my career anymore. The work is boring and not very exciting. The way the company does software development just isn’t right.

The problem is that as a Christian I am part of a church in area which has really helped me grow in college and in my first year of work. If I quit this job, I might not be able to find another suitable job in the vicinity and would have to move state. I struggle with this because it feels like I’m not placing God first in my life, but at the same time I don’t think it would be helpful to remain at this job.”

Firstly, let me start by saying that I relate to this problem 100%. I know firsthand how demoralising it can be to work in a job where you feel like you are stagnating – and how this can sap all your energy in a way that affects far more than just the 9-5 that you’re actually in the office. I also know the internal struggle of wanting to put God first, and not wanting to let your career drive decisions about church rather than the other way around. This can sometimes be made even worse by the amount of guilt that well-meaning Christian friends can lay on your shoulders as they encourage you to stick in your current situation no matter what.

But secondly, let me encourage you to listen to your conscience on this one. Though it may well be right to seek a change in your circumstances (and we’ll come to that in a bit), you definitely do want to approach this in a way that seeks God’s will first, and leaving a good church should always be something that we treat very seriously and with great reluctance. This isn’t something that we need to do with a heavy heart, but a path we can embrace with joy: as Jesus said “seek first the kingdom of God and his righteousness, and all these things [that God knows you need] will be added to you” (Matthew 6:33). The way of the cross often means sacrifices in the here and now – and it often will look like foolishness to the watching world, but no matter what you miss out on in this life, if it’s for the sake of obeying God, then you will not regret it in the life to come. In once sense, so what if your career languishes in the duldrums because you chose instead to commit to your church family? When Jesus returns, “those who are first will be last and the last will be first” – and all the value systems of our culture will be overthrown. I once turned down my dream job making computer games because it would have meant leaving my church and moving cities, and though it’s probably completely changed the course of my life, I don’t regret it one bit.

Thirdly though, I’m pretty sure that God doesn’t want us to be miserable just for the sake of it. Yes, he’s more concerned with our holiness than he is with our happiness, but often we’ll be much more able to serve him with enthusiasm if we’re joyful and excited about life than if we’re feeling drained and burnt out. I’d suggest seeing what work you can find in your local area that would allow you to stick at your current church – even if it’s not necessarily your dream job, you might find that just having a bit of a change helps you feel like you’re growing and learning something. And in the mean time, I’d fight to find joy and thankfulness in your current role. Make a list of the things you can be thankful for about your current job – the fact that it does allow you to be part of a great church, and conversations you’ve been able to have with colleagues about your faith, the income it’s provided, the contributions you’ve been able to make to the business and so on. Being able to choose our jobs is a luxury that has not been available to most people throughout history.

The book I’ve found really helpful in times like this is Kevin DeYoung’s “Just Do Something“. We often spend so much time fretting about “what is God’s will for my life?” and trying to find exactly the right job to choose, exactly the right path. Ultimately, God has revealed very clearly what his will is: “For this is the will of God, your sanctification” (1 Thessalonians 4:3) – he wants us to be holy. Pretty much anything else is up to us to choose – using the wisdom and the brain that he has given us.

I can’t tell you exactly what to do, but I would strongly encourage you to find a way to stick at your current church if you can, whilst also trying to find ways to restore the joy that you’ve lost. Maybe it means finding fulfilment in some more extra-curricular software development activities – getting stuck into an Open Source project, launching your own mobile app or web service, whatever it is that helps you feel like you’re growing (and which in turn will open up more doors for taking another job as it’s all stuff you can show on your resume). Whatever you do, if you do decide you need to move state, be doubly sure that there’s a faithful, Bible-teaching church in the area you move to before you apply for a job there.

And keep praying about it! God will lead you where he wants you if you keep trusting it to him.

STEP Scripture Tools

A few hundred yards from where I lived as a student lies Tyndale House, “a Christian community dedicated to researching all the primary evidence relevant to the study of the Bible”. They have some fantastic people based there doing all kinds of important Biblical scholarship, and more recently they have also birthed STEP: Scripture Tools for Every Person. The vision of STEP is “to equip churches in every country with the tools to study the Bible in its original languages from the best that Cambridge and international scholars have to offer” – in other words, it makes world-class Biblical scholarship and tools available completely free of charge, in a way that can be a blessing to the worldwide church.

“STEP is for everyone interested in the Bible, from those just starting to read it to those who want to dig deeper. Typing a few letters into a single box enables readers to pick a language, a Bible translation, a passage, a subject, or a word. It will work out whether readers want to find all the passages where a word or subject occurs, or if they just want to read a passage.”

They’ve just released a brand new v2.0 which looks absolutely fantastic, and you can read their press release here. I’m sure that the STEP project will be a huge blessing to many – so do spread the word!

I’ve known one of the developers, Chris Burrell, for a number of years now, and I know he’d love to hear from any Christian developers out there looking for a project to volunteer on! You can read more about opportunities to help here.

Kingdom Code: Christians In Tech London Meetup

As London Technology Week kicked off on Monday, it was thrilling to see a room at the Impact Hub Westminster packed with 60 Christians from the world of technology – developers, designers, tech entrepreneurs, data geeks, IT administrators and basically just all kinds of fascinating people united by a desire to see God glorified in and through technology. I co-organised it with Rupert Edwards, CEO of Lepton, and he described one of the central themes of the evenings as being about creating a space for “divine serendipity”. One of the exciting things about the evening was that we had absolutely no idea who was going to show up (when I organised it I thought we might get 20 people – perhaps 30 at a push!) and so we worked hard to try and create ways for people to figure out who else was there and what we had in common, and how we could help and encourage one another. And what a fantastic range of folks there was! It included representatives from all sorts of fantastic Christian organisations like Scripture Union, Wycliffe Bible Translators UK and the Good Book Company, as well as the creator of the Manga Jesus – and thrilling to see that over half the room was from outside the M25, including one guy who’d heroically travelled all the way from Northern Ireland to be there!


I opened the evening by saying there was one particular Bible verse that God had put on my heart as I thought about the event: Matthew 9:38. Jesus has just been out proclaiming the gospel of the kingdom. When he saw the crowds, he had compassion for them, “because they were harassed and helpless, like sheep without a shepherd”. Then he turns to his disciples, and says this:

“The harvest is plentiful, but the labourers are few; therefore pray earnestly to the Lord of the harvest to send out labourers into his harvest.”

We live in a world that is so lost and confused when it comes to God – and nowhere is that more obvious than on the internet! But what an incredible opportunity our modern technology gives us to get the gospel out there, and what a great responsibility we have to make the most of our gifts and our skills to use them to further the work of God’s kingdom. It was great to hear from some of the “founders” there at the event of some of the ways they were hoping to see technology used for God’s glory – but I hope also that even those who don’t think of themselves as “makers” could find encouragement to live our their lives for the glory of God in the roles in which he has put them.

I for one had a really enjoyable evening, enjoyed seeing some old friends and meeting some new ones too, and I look forward to seeing what God is able to do with the connections that were forged. We have a follow-up event planned for Monday 13th October.

Using submodules in Cocoapods sourced from Git

I’ve been banging my head against a brick wall for a few hours now on this, so I thought I’d post this for the benefit of anybody else searching:

If you are using the wonderful Cocoapods in an iOS project you’re developing, and you make one of your Pods load directly from a Git repository (perhaps GitHub) then there’s a little gotcha to be aware of: if the Podspec includes :submodules => true in the source section then it is necessary to manually add that to your Podfile too.

In my case, I’m hacking on my own version of the Bypass-ios Pod, so I had tried adding this line to my Podfile:
pod 'Bypass', :git => ""

However, that was missing a few files from a submodule, causing compile errors like this:
'element.h' file not found

It feels a bit cumbersome, but instead it is necessary to write the Podfile like this:
pod 'Bypass', :git => "", :submodules => true

Announcement: Christian Developers & Designers Meetup

For a while I’ve been planning on organising a meetup for Christians in software / IT and graphic designers. If you’d be interested, join the mailing list and I’ll let you know as details firm up.

The basic idea is this: it’ll be a week night in early June, and not on a Wednesday. It’ll be in London somewhere at the Impact Hub Westminster.

Update: we now have a date, Monday 16th June, a venue, and a page on Eventbrite, so sign up there.

Who am I?

I’m a Christian software developer, behind the PrayerMate app. By day I work for Also involved in organising is Rupert Edwards, CEO of Lepton, the Christian generosity app.

Reporting how many people performed a particular event in Google Analytics

Almost every website on the planet implements Google Analytics to help understand their traffic, and now a fair few mobile apps use it too. At its most basic it tracks the number of visitors/users and page views, but it can also be used to track specific “events” too, things like adding stuff to your basket or pressing a particular button, so that you can get a better understanding of how people are engaging with your product.

It turns out that there’s one incredibly important stat which (as far as I can tell) is ridiculously hard to get hold of: how many unique people performed a particular event?

“Unique Events”: What it is, and what it isn’t

When you look at an events report in Google Analytics, you see two headline stats: Total events and Unique events.

The “Total events” is pretty obvious: the total number of times anybody has performed that event during the given time frame. The “unique events” however, is rather more confusing. As the help text explains, this is the number of unique sessions in which this event was performed. So if I log onto the website and add five products to my basket, that only counts as one unique event. If I come back tomorrow and add some more, that counts as a second “unique event”.

That confused me. For a long time I was labouring under the misunderstanding that it was the total number of users who had performed that event, so it always confused me that it came out higher than I was expecting.

Counting unique users

So if that’s not what “unique events” means, then how do I found out how many unique users have performed that event? As far as I can tell, the answer is depressingly complicated. The best way I’ve managed to find is to create a custom segment that segments the set of users based on whether or not they’ve performed that event. Then Google Analytics can tell me how many users are in my segment during the given timeframe.

Custom Segments

Custom segments are created by pressing the big down arrow button at the top of any given page. You can then create an advanced custom segment based on two conditions: the event action and (optionally) the event label (see picture above). This lets you create a segment based on having performed a particular action with the given label (if you want to see just people who have added one particular product, use the label, if you just want to see total people performing that event you can leave the label out). Then Google Analytics will tell you the number of people in that segment.

If you know of a quicker way to find out this information, I’d love to hear it!

Adding cloud functionality to an Android app

It’s often said that Apple don’t do cloud services as well as Google, and one very clear example of this can be seen in the Android SDK. Right from API Version 1 Android has supported something called “Sync Adapters“. They’re a little convoluted to set up, but basically Android provides an abstract framework straight out of the box for adding any kind of background network sync behaviour you need to your app. It handles calling your sync task at suitable times, for optimum battery usage, and makes sure it all runs nicely in a background thread. All you need to do then is define the behaviour each time the sync is performed.

The step by step instructions here are pretty thorough in talking you through what you need to do. I got stuck at just a couple of points:

  1. Firstly, they provide incomplete code in step 3 for their CreateSyncAccount method. I had assumed that if addAccountExplicitly failed then that was a fatal error, so was returning a null account. In fact, you can ignore this error completely and still return the new account object you’ve created.
  2. In the final step, running your adapter, it would appear from what I’ve experienced and what I’m reading on StackOverflow that the documentation everywhere is completely lying to you, and you do in fact need to turn setSyncAutomatically ON even to use addPeriodicSync. What’s more, addPeriodicSync takes an interval in seconds not in milliseconds like the example code would suggest.
  3. Finally, the example code passes a null extras bundle to addPeriodicSync, but this will in fact cause an exception. So make sure you pass in a bundle, even if it’s completely empty.

Despite these initial hickups, Sync Adapters have given me a real headstart in adding online feed subscriptions to the Android version of PrayerMate, so consider me impressed.

Update: Big gotcha – setting the frequency

It’s worth being aware that if configured naively, your SyncAdapter could be run arbitrarily frequently, i.e. multiple times per minute, effectively constantly running in the background and draining the battery. You are therefore strongly advised to make sure your onPerformSync method sets the delayUntil property. Just be aware that the documentation on this is completely misleading – if you look at the source code to how the SyncManager works, delayUntil isn’t “the number of seconds to wait before running again” at all – it’s the absolute timestamp when it should next run. So don’t set syncResult.delayUntil = 60*10 to make it wait for ten minutes, instead set syncResult.delayUntil = (System.currentTimeMillis()/1000) + 60*10.

Android Compatibility: a Primer for iOS Developers

I’ve been developing iOS apps since the end of 2010, so have only ever seen the world of Android from a distance. Where I’m from, you hear a lot of talk about the problem of fragmentation on Android. Whereas the adoption stats for new versions of iOS are pretty impressive (apparently iOS7 hit 33% iOS market share in just 24 hours, and 58% after one week) the situation on Android looks very different, with the second most popular Android version remaining Gingerbread, released in 2010.

With my iOS hat on, when PrayerMate launched on Android earlier this year, I assumed it would be far too much hassle for one independent developer working in his spare time to take on this fragmentation issue, so I decided to support only Honeycomb upwards – a major OS update which introduced some significant new changes to the core Android UI.

But what they don’t tell you over in iOS developer world is that the Android ecosystem provides some pretty impressive tools to make supporting older Android versions really easy. Let me give you a quick overview of just three reasons why adding support for older phones isn’t nearly as hard as you might imagine:

1. Compatibility-aware compiler

When you set up your Android project (I use Eclipse) you specify the minimum version your app supports. Out of the box, the compiler knows exactly which API level each feature was introduced at, and will throw a compiler error if you try to use functions that are too modern for the versions you claim to support. If you use conditional statements to alter behaviour by Android version, then you can use attributes in your code to say what API level a given function is designed to run against, to disable these compiler errors on just those bits of code. It also warns about deprecated APIs so that you can use more modern alternatives where appropriate.

This makes the situation so much easier than the native state-of-affairs on iOS. It wouldn’t surprise me if there was some way to figure out how to make XCode throw such compatibility errors, but out of the box you get no warning whatsoever if you use functions introduced in an iOS version later than the minimum one you hope to support, and the only way to discover this is through thorough testing and waiting for the crashes to happen (which needless to say is not very scalable!)

2. Compatibility support libraries

Another seriously impressive feature of the Android SDK is the compatibility support libraries. In many situations, where a new API has been introduced, the SDK then goes and adds an alternative implementation that conforms to the same method signatures but which ports the new functionality back so that it also works on older OS versions. This avoids the need to have lots and lots of conditional branches running separate codepaths on separate Android versions, and instead means you can just write one lot of code that works everywhere.

3. ActionBarSherlock

Ok, so this one isn’t native to the Android SDK (although a very similar library is) but there’s a great open source project out there called ActionBarSherlock which lets you add the “action bar” UI paradigm introduced in Honeycomb even when running on older Android versions. It requires a minimal amount of setup, and works almost identically to the real action bar. So, again, rather than having to invent two separate user interfaces depending on the Android version, you can have the same functionality running everywhere.


In conclusion, the Android fragmentation problem doesn’t seem nearly so scary to me as it once did. I managed to get PrayerMate to support Android versions all the way back to Froyo (v2.2) in a single (pretty relaxed) weekend, and because of support from the compiler I can be pretty confident of not having missed anything.

How an ancient story from the Old Testament still affects software development today

Want to make a computer programmer groan? Just ask them to explain “unicode” to you and watch what happens, as all of the joy drains out of their face in an instant.

It turns out that an ancient story from one of the very earliest chapters of the Old Testament still casts a shadow over software development in the 21st Century. Which story? The account of the Tower of Babel and God’s subsequent judgement on the world – a judgement which still makes itself felt these many thousands of years later.

In the days of Noah, God recognised that the intentions of man’s heart was “only evil all the time”, and so he made a fresh start of the world, beginning again with just Noah and his family. Yet the human capacity for evil was undiminished, and it’s not long before we see the human race trying to exert their independence from God: “Come, let us build ourselves a city and a tower with its top in the heavens, and let us make a name for ourselves, lest we be dispersed over the face of the whole earth.”

In one of those verses that proves what a sense of humour God has, we read that whilst they were busy trying to build the tallest tower imaginable, reaching to the very heavens, God still found it necessary to “come down” to get a closer look at the city and the tower, which the children of man had built.

“And the Lord said, ‘Behold, they are one people, and they have all one language, and this is only the beginning of what they will do. And nothing that they propose to do will now be impossible for them.'”

It was a period of unprecedented harmony for the human race, but how did they choose to use that spirit of co-operation? To rebel against God and try to throw off his shackles, making a name for themselves. Even then, God loved us too much to leave us to this rebellion, and so he proposed a judgement fitting the crime:

“‘Come, let us go down and there confuse their language, so that they may not understand one another’s speech.’ So the Lord dispersed them from there over the face of all the earth, and they left off building the city. Therefore its name was called Babel, because there the Lord confused the language of all the earth.”

Whilst their great intention was to prevent themselves being dispersed across the face of the earth, God did the very thing that they were afraid of and caused them to divide and spread out across the earth. He muddled their languages so that the unity they had previously enjoyed was destroyed, and in its place there was misunderstanding and gobbledegook.

And that, my friends, is why software developers today still have problems making their programs handle foreign characters properly. It’s not simply that computers can’t agree on what language to speak – in many ways, English is the common tongue of most software. It’s that even when there IS agreement on the language, computers can’t even decide quite how to represent that language. As Joel on Software explains in his excellent little introduction to Unicode:

“In Unicode, a letter maps to something called a code point which is still just a theoretical concept. How that code point is represented in memory or on disk is a whole nuther story.”

The humble apostrophe causes no end of problems in even otherwise very straightforward English documents, if you use the curly kind rather than the straight line variety, since depending on the character encoding you use to save your document its codepoint could be presented in all manner of different ways: ISO-8859-1, UTF-8, UTF-16, big-endian, little-endian, blah blah blah. When you start getting in to languages with lots of accented characters like French, or even whole different alphabets such as Chinese, then it starts to get completely unmanageable unless you understand what you’re doing. And even when you understand what you’re doing, chances are you’re having to interact with libraries and services which DON’T understand what they’re doing, or which decide to handle things in an ever so slightly different manner.

So God’s curse on the sinful intentions of our hearts is still making itself felt even today. It can add all sorts of overhead when trying to get software based on different platforms to talk to each other. We’ve come a long long way from where we were a few years ago, but even so it can still cause much banging-ones-head-against-a-wall.

And so we cry, “Come, Lord Jesus!”

Handling Character Sets in the Dropbox API for Android

This all feels slightly ridiculous, but getting iOS apps and Android apps to talk to each other via Dropbox is complicated considerably by the issue of Unicode and Character Sets. For anybody who hadn’t realised – computer science is plagued by the effects of the fall, and the legacy of the Tower of Babel is keenly felt. Computers simply can’t agree on how to talk to each other, they can’t even agree on how to speak French – some computers representing characters in a character encoding like UTF8 that uses one byte per letter unless more are needed, and others encoding in UTF16 that uses two bytes per letter unless more are needed.

It would appear that the iOS Dropbox API is saving files out in UTF16 (at least in my app!) whereas Java (and therefore the Android Dropbox API) naturally reads things in UTF8, causing problems!

It feels like total overkill, but in the end I discovered this handy little Java library that can guess what character encoding has been used for a given string: juniversalchardet

Online Reviews, Jesus Style

What Would Jesus Do when it comes to leaving online reviews on the App Store or Google Play? What does the Bible have to teach us about how to review apps in an Internet age? It turns out, quite a bit!

I think the clearest bit of teaching on the subject comes from Matthew 18:15-17:

“If your brother sins against you, go and tell him his fault, between you and him alone. If he listens to you, you have gained your brother. But if he does not listen, take one or two others along with you, that every charge may be established by the evidence of two or three witnesses. If he refuses to listen to them, tell it to the church. And if he refuses to listen even to the church, let him be to you as a Gentile and a tax collector.”

Ok, so I’m stretching it a little. But notice that in disputes (particularly between believers) Jesus describes a clear process of escalation:

  1. Start by telling the person who has offended you in private. This is just good manners. It’s easy to take offence at someone, but there’s a good chance that they weren’t acting maliciously or with evil intent – and raising the matter privately avoids unnecessarily trashing their reputation and giving them a chance to repent.
  2. If that fails, bring in a couple of others. Sometimes our hearts are stubborn, and it takes a little social pressure to make us see the situation clearly. This still allows for the situation to be dealt with privately and without airing the dirty laundry in public, but helps show the seriousness of what’s going on.
  3. Finally, if and only if there is still unrepentance, get the whole church family involved. If even the whole body of Christ can’t help this person see what’s wrong, then there’s something really wrong.

So how would Jesus review? Here’s what I reckon:

  1. He’d begin by raising any issues privately with the developer. If it’s a bug in an app, then the best way to help the developer fix it is to get in touch and give helpful background such as your operating system version and the exact steps you went through. A 1-star app review isn’t the right place to report bugs.
  2. If reporting the issue fails to produce any response, he’d probably try to discover if it’s a widespread issue, to help the developer see the seriousness of the issue. Maybe he’d tweet or post on Facebook – “anybody else had this issue?” Most app developers are super busy with all sorts of competing priorities, and bugs that are affecting several people are much more likely to get attention than one-offs that are hard to reproduce.
  3. If the bugs persisted, then he might politely warn others in a review. Sometimes in good conscience you want to leave a negative review of a product, to warn others not to waste their money on something that doesn’t work. But you can still be polite about it! “I wanted to love this product, great concept, but sadly, after long conversations, the developer was unable to resolve some serious flaws”

Some examples of a really bad review:

  • 1 star – no explanation. Not even an “I hated it!”. This serves nobody – the developer has no idea how to improve her product, and other potential customers can’t tell whether they’ll hate it too for the same reasons. I’d suggest that this is pretty lazy.
  • 1 star – “the app crashed on launch, sort it out, waster!”. If this was the only review left on an app, this might be within the realms of the useful to other potential customers, but (apart from being pretty rude!) it’s very unlikely to actually help you get the app fixed, since the developer has no information to go on. If it’s the only such review amongst hundreds of very positive reviews, then it’s not even all that useful to other users since it’s probably a fairly specific issue that relates to your particular setup (as an aside, I might gently request that if you’re running a beta version of iOS then you should please refrain from leaving reviews about app crashes)

There are some cases where a negative review is appropriate, but I think one should always aim to be courteous, and remember that the person at the other end is a real human being who probably works hard and isn’t deliberately setting out to create rubbish apps:

  • Make a clear distinction between the app in general and specific updates / issues. Every app has its catastrophic update that goes disastrously wrong. This is inevitable from time to time. But I’ve also seen excellent reviews in such situations, along the lines of “This is one of my favourite apps but this particular version has serious issues”

What do you think? How do you think Jesus would review apps?

How to run a Heroku rake task via the API

For various reasons I was looking for a way to make a Heroku app run a rake task on another Heroku app. I looked into using the excellent Heroku API to achieve this, but couldn’t find any documentation on the subject. After a little bit of playing around, I discovered that you can achieve it by making a POST HTTP request like so:

curl -n -X POST<your-heroku-app>/ps \
-H "Accept: application/json" \
-H "Authorization: $TUTORIAL_KEY" \
-d "command=rake my_rake_task"

(see here for details on how to build the $TUTORIAL_KEY variable)

How should Christians engage with technology?

Update: This is really old and there’s a more recent follow-up post that goes with it

Computer keyboard

The other weekend I went to speak at a men’s breakfast at St. Luke’s Wimbledon Park on the topic of “how should Christians engage with technology?” It’s something I’ve been wanting to put together a talk on ever since my time studying on the Cornhill Training Course and working as their IT guy, a period of my life which gave me plenty of time to think about how theology and technology interact (this was also when I first developed the PrayerMate app).

I think this is a topic which Christians ought to be encouraged to think about a lot more than we do, because it’s something that’s both really important and all too easy not to think about all that hard. For that reason, here are my notes from my talk.

The fact is that technology is absolutely everywhere. Even if you think you’re a luddite who’s hopeless with technology, there’s a chance that you own a pair of glasses – well, that’s technology. There’s a very good chance that you use electric lighting to stay up beyond sundown – that’s certainly technology. Even if you go to bed at 5pm in the winter, you’re certain to have read a book or two in your lifetime (though frankly, if you’re going to bed at 5pm, I don’t know where you find the time!) The humble book employs an enormous amount of technology – from the paper it’s printed on, to the printing press used to copy it (perhaps one of the most revolutionary pieces of technology ever invented), to the alphabet itself, which believe it or not hasn’t always existed and once upon a time somebody sat down and invented.

“Technology” is basically anything that is created by human beings to help us reach beyond what we would be able to do without it – whether that’s just doing an old thing more efficiently, or whether it’s doing something that was entirely impossible before. Technology is all around us, and it’s so deeply woven into the very fabric of our lives that we barely even notice it’s there. That’s precisely why it’s so important that we do take time out to consider it from a Christian perspective – because the technology we use always changes us.

There’s masses and masses I could say on the topic, but I’m going to basically address three areas: technology is not morally neutral; technology changes how we think; and some practical thoughts on using technology.

Technology is not morally neutral

When it comes to technology, it’s very easy to respond in one of two ways:

  • There’s the approach that just rejects all new technology outright – we don’t like the change it represents, so we reject it en masse as evil. It took me years and years before I got my first mobile phone, and in the mean time I stubbornly rejected it.
  • The other common response is that we embrace it wholeheartedly as an unambiguously positive force for good. The culture around us often portrays all technological progress as a step forwards – newer is always better, and just because something can be done, then that something should be done.

But if we look at what the Bible has to say, then I think we can say that both of these approaches are lacking. Have a look at Genesis 1:27-27:

“So God created mankind in his own image, in the image of God he created them; male and female he created them. God blessed them and said to them, ‘Be fruitful and increase in number; fill the earth and subdue it. Rule over the fish of the sea and the birds in the sky and over every living creature that moves on the ground.'”

So we see that God is a creator – he makes things. And one of the pinnacles of his creation is that he creates men and women, and he creates us in his image, so that we too will be creators who in turn like to make things. As we master the world around us and bring our ingenuity to bear on the problems that we face, we’re actually reflecting something of the image of God, and that’s a good thing and a right thing. It’s part of how we’re going to fulfill that creation mandate that God gave to Adam and Eve, to “fill the earth and subdue it” and rule over it.

So our ability to create technology is a good and a positive thing that reflects something of the image of God. But we also need to recognise that we live the other side of Genesis 3: in Genesis 3 we see humanity rejecting God’s good purpose for our lives, and in judgement God puts a curse on his creation.

“Cursed is the ground because of you; through painful toil you will eat food from it all the days of your life” (Genesis 3:17)

So things are now distorted and warped. The creation order is turned upside down, the things we created to help us master the creation now try to master us. It’s a few chapters later that we get the first clear example of technology in the Bible, in the hands of one of the murderer Cain’s descendants, “who forged all kinds of tools out of bronze and iron” – it’s not loads clear, so don’t attach too much weight to it, but it’s not presented as entirely positive. Then you get the first major building project in the history of humanity in the form of the Tower of Babel, which again is not exactly portrayed in an overwhelmingly positive light. There it’s an example of technology being used to exert independence from God – making a name for ourselves apart from our relationship to God.

So the basic principle which we need to establish when thinking about technology is this: technology by itself is what we might call “amoral” – that is, it is neither overwhelmingly good nor inherently evil. Like lots of things in this world it’s something with great power for good but which is also deeply affected by the fall. What’s important is how we use that technology – what we use it to do, and what we allow it to do to us.

Technology is neither overwhelmingly good nor inherently evil – it’s how we USE it that counts.

Some of the benefits of technology are easy to spot – maybe it’s an app like PrayerMate that can help you in your prayer life, maybe it’s a Facebook message to a struggling friend that gives them the encouragement they need to keep going, maybe it’s just the way that electric lighting and central heating helps our midweek Bible studies go better, or the way that the printing press has enabled the Bible to be distributed far and wide and put into the hands of ordinary people. Technology has enabled some wonderful things.

But technology can also very easily become an idol in our lives. Most of what I have to say here is really inspired by Tim Challies’ book “The Next Story” (which you should all go out and read immediately), and he says this:

“Though the devices and tools we create are inherently amoral, at the same time we would be foolish to believe that they are morally neutral. The things we create to assist us in overcoming the consequences of the curse also seek to dominate us, drawing our hearts away from God rather than drawing us toward him in dependence and faith.”

Anything created has the potential to become an idol in our lives – something that we put our trust in instead of God. And technology has perhaps a greater-than-average risk of being turned into an idol because it is so powerful in extending our abilities and what we’re able to achieve – it promises to help make us a little more like God, and overcome our finiteness and weakness. And that’s something we need to be aware of and pray against. It can be that the technology is an idol in itself (the latest iDols from Apple, perhaps?) or they can enable other idols, such as my pride, as I project an image of living the most remarkable life imaginable on Facebook, or lust, in the form of Internet pornography and so on.

My goal here is to encourage us all just to be a little more thinking in our attitude to technology – not to reject it outright, nor to embrace it unquestioningly. Instead, to try to see beyond the superficial and to think a bit more about how it affects us, and why we feel about it the way we do.

Technology changes how we think

It’s really important to recognise that our technology has the power to radically alter how we perceive and think about the world around us. If you’ve ever read Neil Postman’s book “Amusing Ourselves to Death“, he argues that the advent of television completely revolutionised how we engaged with everything from politics to education (had the internet been invented at the time he was writing, I’m sure he’d have said his hypothesis was even more true of that). Because of the television, we’ve become a very visual culture. Postman talks about how important it is these days for politicians to look the part if they’re to get elected, because so much is decided by the public watching them on telly. He asks how many of the great leaders of the past would still have been elected if they were to run for office today?

So, technology can change how we think. How many of you have ever made a decision about what to wear or what to do, because you’ve been thinking “how will this look on Facebook?” Or maybe that’s just me!

Let’s briefly consider just two examples of ways that technology changes how we think. Even if you don’t think these are relevant to you, they’re sure to be relevant to your children or the people that we’re trying to reach in our churches.

1. Technology means we’ve redefined community

In the old days, your community was defined by your physical geography – where you lived – and primarily that usually meant your family who you shared a house with. So if you wanted to contact somebody, you’d call the family telephone, or you’d write a letter to the family address. Now it’s shifted from our geography to being much more about the individual, and our preferences – so our community can be a virtual one defined by common interests. You email me as an individual, you send me a text message as an individual – and it’s all completely cut off from my geographical context, my family context.

So does that mean I should throw away my mobile phone, close my GMail account and refuse to communicate with anybody except by snail mail? Of course not! Apart from anything else, it’s probably too late for that! But being conscious of the way that our technology has changed us, we can be armed to think about how this might have a knock on effect for our godliness, how we relate to God and to one another. There’s no doubt that this is one of the reasons why as a culture we increasingly find church so hard work these days, because very often we don’t have a whole lot in common with the other people we go to church with, we’re not that bothered about our local community, and it all feels a little bit too much like hard work. We’re going to need to go back to our Bibles to figure out why we should bother with church, and how to persuade the next generation to bother with church in a world where meeting together physically in one place is increasingly less interesting. Communication is increasingly about “mediated” contact these days – it’s much less daunting to send a text message or an email to somebody that they can read at their leisure than it is to look them in the eye and give them my full attention and require their full attention in response. Going to church is such an alien concept in a world of mediated contact!

2. Technology means we’ve redefined truth

I don’t know if you’ve ever tried anything on Wikipedia before – but there are very strict guidelines that determine what you’re allowed to say on Wikipedia. It’s all based around the concept of “consensus” – everything you write has to have a citation from another source, everything has to be backed up by somebody else who agrees with you. They explicitly say that it’s not a place for original ideas or new thinking.

Or if it’s not about consensus, it’s all about “relevance”. As sites like Google and Facebook have to deal with larger and larger volumes of information, they’re getting more and more sophisticated in filtering things out so that they only show you what they think you’ll consider “relevant”. You’ll see more and more content from the friends that it thinks you engage with and less and less content from the friends that it’s decided you’re not really that interested in, and it’s all very self-reinforcing.

Both of these ways of defining the truth – consensus and relevance – have problems for the Christian, because we believe in revelation. Biblical truth often clashes with consensus, and doesn’t necessarily seem all that relevant to an outsider who’s thinking superficially. But it’s the ultimate truth, and it’s supremely relevant because it’s about our eternal future – if only we have the ears to hear.

Obviously there’s loads more we could say on that topic – plenty of further examples of ways in which our technology changes how we think. But in summary: be on your guard! Don’t engage with technology unthinkingly and expect to come away unchanged.

Some practical thoughts on using technology

Really I just want to talk about one thing under this heading, and that’s distraction. Our technology these days increasingly leads to distraction. If we allow it to, our technology can really begin to own us, with all of the beeps and buzzes and notifications that constantly vie for our attention and drag us away from the real interactions with the people right in front of us.

As a result of all this distraction, we’re less and less able to concentrate for long periods of time, we find ourselves less and less able to do something simple like just sitting and reading a book. It can even get to the point where we find ourselves feeling quite anxious and fidgety if we have to sit with our own thoughts and nothing to distract us. It can draw us away from the people we’re face-to-face with, and be a disaster for our working productivity.

Our hearts long for that little beep, so we feel like we need to leave the volume turned up. But the reality is that the world will still go on if our emails go unread for 30 minutes, and we’d be much better off if we just turned the notifications off and instead just checked in every once and a while.

All this can be a real issue for habits of personal devotion like having quiet times where we spend quality time in God’s word and praying. So many times I’ve been trying to read the Bible, only to find myself checking my phone or my iPad because some idea has occurred to me part way through, and before I know it I’ve completely forgotten what I was looking at.

I think if we’re going to be serious about putting God first in our lives, we have to be pretty radical with our technology.

For myself, it’s a real discipline of trying to make sure that my Bible reading is the first thing I do in the morning, rather than checking my email. It just feels to me like it says a lot about my own priorities that I’m more excited to know if anybody around the world has sent me a nugget of novelty in my inbox, than I am to hear from the Creator of the Universe who has some eternal truth to share with me – and trying to make sure I hold off checking my email until I’ve listened to what he has to say just feels like the right thing to try and do. Apart from anything else, often I’ve only got about 3 minutes of peace and quiet before the baby wakes up, and if I use it to check Facebook then the quiet time may never happen!

Coupled with the short attention span, we have less and less need to exercise our memories, as we become more and more reliant on Google to give us the answers. We don’t know how to memorise scripture any more, because we know we can just look it up on Bible Gateway instead. How much the poorer are we for it?

So let me urge you: keep reading your Bibles, keep reading good Christian books, and why not try to memorise the occasional Bible passage?

Questions to ask our technology

I am aware that this was a bit of a whirlwind tour, with lots left out. However, I hope there’s been something there that was vaguely useful, and some fuel for further thought on the subject.

To close, let me leave you with some questions from Tim Challies that we should ask of any technology. You’ve heard of the discipline of talking to yourself – well here’s some ways you can talk to your mobile phone instead:

Medjool: Ruby Date Parsing With Context

The Date.parse method in Ruby on Rails is a really useful little function. Yes, it probably comes with huge overheads, and no, obviously you wouldn’t want to be using it in performance-critical code. But every now and again it’s really ace.

Except for one thing: you can’t provide it with any context whatsoever. “Tuesday” always means next Tuesday, no matter what. “1st” always means 1st of the current month, come what may.

When building the “Quick Import” feature of, I needed a little more flexibility than that. The goal was to allow churches to copy & paste their prayer points from their weekly notice sheet, and for the site to just “know” what each date meant. So, for example, if you’ve just parsed a prayer point for “Tuesday”, odds are that when you come across a prayer point for a “Wednesday”, that almost certainly means the day after the Tuesday that you just processed. Date.parse can’t cope with that. That’s why I built Medjool – all the simplicity and flexibility of Date.parse, just with a little more context.

p ={:now => "2013-09-31".to_date})
p.parse("1st") => 1st October 2013
p.parse("3rd") => 3rd October 2013
p.parse("1st") => 1st November 2013
p.parse("Wednesday") => Wednesday 6th November 2013

I looked into doing this with Chronic, but Chronic is really geared towards Time processing rather than simply Date processing. It also seems pretty buggy when it comes to dates, and gives different results depending on the exact input date format. Medjool, by contrast, ALWAYS delegates parsing to Date.parse, it just then sometimes plays around with the result it gets back to make sure it’s after the previously parsed date, if there was any ambiguity.

A startup that believes in something

Almost a year ago now, I took what felt at the time like a big risk by accepting a job as a web developer at Hubbub, a delivery company with a difference currently based in London. I’m not generally a big fan of risk, and pretty much by definition, when you take a job at a startup you’re not entirely sure if they’re going to sink or swim. That, combined with the horror stories you hear about people burning themselves out working all hours of the day and night for startups, meant that I was a little uncertain whether this was exactly the adventure I wished to embark upon just as I was getting married.

But ten months later, I can honestly say I am so glad I took that chance. There’s all sorts of reasons that Hubbub give you about why it’s an awesome place to work – the free lunches sourced from some really unique shops, the generous staff discount, and not to mention the year’s supply of free bacon you get as a recruitment bonus.

Above all, however, I think there’s one key attribute of Hubbub’s culture that really makes it stand out – it’s a company that really believes in something. The driving force behind Hubbub’s very existence is the belief that local independent shops make our communities a  better place. As the government sets up the Future High Streets Forum, it’s clearly not just us who recognise it either. The local butcher, baker and candlestick maker – they add a richness and a vibrancy to community life that a big, faceless, corporate conglomerate like Tesco could never offer. But the sad reality is that they’re under enormous pressure in today’s economic climate, and Hubbub gives them a real boost by allowing them to pool their resources and extend their reach to people who would love to get there in person if they could, but for whatever reason find it more convenient to do their shopping online.

I’ve worked for companies before where the only thing that ultimately mattered was squeezing every possible penny from our visitors to our site, even if it made their experience worse in the process. I’ve worked for companies where we had a lot of fun doing cool stuff, but which at the end of the day hardly made much of a lasting dent in the universe. There’s something so much more satisfying about going to work and knowing that you’re contributing towards a larger picture, helping make people’s lives a little better and serving a loftier goal than mere profit alone.

As a Christian, and especially as one in the middle of reading Every Good Endeavour by Tim Keller, I know that saving the local high street isn’t the ultimate goal in life. However hard we fight, there will come a day when the high street is gone forever – because I believe this world itself won’t be around for ever either. But as the original job ad that first attracted me to Hubbub stated, a business that helps save the local high street sure beats working for another social cat coupon website.

Our work really matters. We spend a huge proportion of our lives at work. Wouldn’t you much rather devote that time and energy contributing towards something that made the world a little better in the process?

Did I mention that Hubbub is hiring?