Category Archives: coding for christ

Kingdom Code BUILD ’17 – Christian Hackathon weekend

KCBuild_Banner

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!

challenges_screenshot_smaller

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].appspot.com 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:

security:
  - 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.

KCBuild_Banner

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

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) {
return;
}

// 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
return;
}

// 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];
return;
}

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];
}
}
}

Conclusion

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.

Conclusion

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!

KingdomCode1

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 => "git@github.com:andygeers/bypass-ios.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 => "git@github.com:andygeers/bypass-ios.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 Hubbub.co.uk. 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.
ga_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.

Conclusion

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

apostrophe
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 https://api.heroku.com/apps/<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?

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 PrayerMate.net, 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 = Medjool::Parser.new({: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?

My Undigital Sabbath

I’ve been increasingly aware recently that I’m fast becoming a serious information addict – constantly refreshing tech news sites and Facebook and whatever else it is in search of a nugget of news to give me the next brief high. Tim Challies talks about this in his great new book “The Next Story“, quoting an interview with a psychiatrist called Dr. Edward Hallowell about so-called Attention Deficit Trait:

“It’s a condition induced by modern life, in which you’ve become so busy attending to so many inputs and outputs that you become increasingly distracted, irritable, impulsive, restless, and over the long term, underachieving.”

All this has had a knock-on effect for my relationship with God as well – without doubt I find it harder to concentrate on anything for very long these days, which includes Bible reading and prayer. Deciding I could ignore the problem no longer, this weekend I decided to have a kind of digital detox – I thought I’d try going internet & laptop free for 24 hours from sundown on Saturday night, possibly with the intention of making this a weekly experience.

It turned out to be a really valuable time. It was at once easier than I expected and harder than I expected. Easier than expected, because I certainly didn’t feel I was missing out on anything important – certainly nothing that couldn’t wait until Sunday evening. But harder than I expected, because with nothing else planned instead I found myself really bored. I find reading anything for more than about a chapter pretty hard these days, so that didn’t pass much of the time. I went for a jog, which was certainly a good thing, but again, didn’t exactly take long.

I ended up being so bored that I cleaned the bathroom – something long overdue. There’s probably an important lesson there. How often do I end up using Google Reader as a way to put off doing the jobs I ought to be doing instead?

So will I repeat the exercise next weekend? Almost certainly. I might relax the requirements a little and allow the laptop, but with wi-fi turned off – there were several moments where I thought it would be good to use the time to write something, which wasn’t very practical without the laptop. But overall it felt like a really positive experience, and definitely was good for my spiritual health.

Lessons Learnt From My iPhone Development Sprint

Intro

What with Easter and a certain wedding here in the UK we’ve had a lot of Bank Holidays lately, so I had the opportunity to escape to my parents’ home in the Gloucestershire countryside for about 10 days. I decided I wanted to make the most of the time to develop an iPhone app that I’ve been thinking about recently. Last night at 11pm I submitted a binary of that app to Apple for approval – it’s called “PrayerMate” and it’s designed to help you organise your prayer life. In this post I want to write up some of my experiences and what I’ve learnt from it all.

Before I go any further, I should explain that I have a very poor track record of actually shipping anything. It’s taken me many years to catch on to the huge chasm that exists between “knowing Objective-C” and “raking in the profits from a successful app that is actually available for purchase on the app store and that people enjoy using and want to recommend to their friends”. You’d have thought it would be obvious that those two things are not the same, and yet I think a lot of us probably fall into the trap of thinking that “I theoretically know what would be involved in making something” is conceptually identical to having actually gone ahead and done it.

Recognising this about myself up front, I realised I was going to have to take special measures to make sure that this didn’t end up as yet another half-baked piece of code festering on my hard drive because finishing it off proved too much like hard work. Which leads to my first point: planning

The Planning Stage

Long before the holiday began I tried to plan out what I would and wouldn’t do during those 10 days. The product I had in mind was really well suited to a short development sprint, since the Minimum Viable Product was extremely simple, yet the scope for adding extra features over the long haul is vast. I made myself a list of all of the features I could think of, and was absolutely ruthless about what would make the cut for version 1.0. And I mean ruthless – initially I hadn’t even planned to allow people to delete prayer points once they’d added them to the database. This paid off in spades later in the development process, when it quickly became apparent that even the simplest feature has acres of hidden complexity lurking beneath the surface. Admittedly I ended up adding one or two of those features that I initially rejected later on, once I felt confident that they wouldn’t make shipwreck of the whole enterprise, and that whilst perhaps not essential they were nonetheless pretty important.

Having made my list of features, it broke down nicely into about four key areas, so I made myself a schedule for how I would use the 10 days. It worked out like so:

Thursday 21st (travelling): UI Design
Friday 22nd (Good Friday): Basic navigation
Saturday 23rd: Manage categories
Sunday 24th (Easter): DAY OFF
Monday 25th: Manage subjects
Tuesday 26th: Prayer mode
Wednesday 27th: In-app payment upgrade
Thursday 28th: Testing, bug-fixing
Friday 29th (Royal Wedding): Icon design, screenshots, writing blurb

I made sure I knew which days were going to be taken up with other stuff like Royal Wedding celebrations and so on, and deliberately scheduled a lighter workload for them. You’ll also notice I planned to have a full day off on Easter Sunday, the benefits of which I’ll talk about later on.

With hindsight, making this schedule was probably one of the most important factors in my success. I’ve spoken previously of the crippling effect of uncertainty in my life, and having this schedule meant that I always knew what I was supposed to be working on at any given point in time. It helped that it was more or less realistic – the first few days I finished nice and early and was then able to take the evening off to spend time with my parents, and one or two days I was still coding away at 10:30pm trying to get something finished when I’d much rather have been heading to bed – but by and large I was able to stick to that schedule right until the end, and it was a huge help.

Clearing the Stones

I deliberately didn’t start on the project in earnest before heading to my parents’, but for the week or so leading up to it I did try to clear the ground a bit so that I could get off to a running start. I knew that I wanted to base the project off one of the samples that Apple provides, so I made sure that was compiling and running properly on my iPod Touch. Perhaps that all sounds a bit meaningless and insignificant, but it had been a significant mental barrier to my starting earlier – I’d formerly tried to get that particular sample running and had broken it with some changes I’d made and didn’t really understand why it wasn’t working properly. I wan’t to make sure my first day of my sprint wasn’t going to be wasted faffing about stuff that I didn’t really care about.

Designing the User Interface

Again, because of the crippling effect of uncertainty, I knew that an important first step was going to be to mock up the user interface. If I didn’t know what I was supposed to be coding then there was no way on earth I was going to succeed in getting on with it. So whilst I was on the train from London Paddington to Kemble I fired up Balsamiq Mockups on my MacBook and worked out what the workflow was going to be. Nothing very fancy or very complicated – but I would have spent the rest of the week floundering if I hadn’t done this first.

iPhoneUI.png

Coding a Fake App

Over the next few days I then had to get on with the coding. The first day I created all of my view controllers, populating all of the tables with hardcoded data and allowing the user to navigate between it all. This worked out really well over the rest of the week – it meant that it felt like a working app right from the start, and every little bit of code I added could be seen in action as soon as it was written. It was basically a case of eliminating friction later in the week – there was none of the hassle, however small, of creating new classes and so on, because it was all there ready and waiting on day one.

Where Would I Be Without Stack Overflow?

I have to say, I would have been utterly lost without Stack Overflow. I must have used it about half a dozen times a day – it seemed like every time I Googled a problem I was having, somebody had already asked a question about it on Stack Overflow and there was already a bunch of awesome answers explaining how to solve the problem. In a few rare cases where a question didn’t already exist, I got some excellent answers promptly. Kudos to Jeff Atwood and the rest of the team involved in developing such an awesome site and community – in my experience it really works.

The Value of a Day Off

As I mentioned previously, I planned right from the start to have a complete day off on Easter Sunday, and get away from the computer as far as possible. Partly that’s because I think that’s the way God’s designed us – he set the pattern of working hard for six days and then having a day off himself, and who are we to work harder than God? But my experience bears out the wisdom of that. Quite apart from feeling more refreshed off the back of it, it meant that by Monday morning I was chomping at the bit to get back to work – I literally couldn’t wait to get on with it. Speaking for myself, if I work flat out without a break I’m rarely doing my best work, and usually end up wasting so much time that I would have been better off taking a day off anyway, so I don’t think you lose anything by trying to be a hero.

In a similar vein, I also made a point of going for a walk for about an hour every afternoon. I got through a lot of 5by5 podcasts during the week! The one day I failed to do that, my eyes were throbbing by the end of the day and I seriously regretted it. I should have listened to my mother – there’s no substitute for eating well and getting good exercise!

The “It’s Mostly Done Phase”

I found that by far and away the hardest phase of development was that penultimate day I scheduled in – “testing and bug-fixing”. I quickly realised that this is were 90% of my failed projects come to die. The product feels finished, although admittedly I had a list of about a dozen little niggles that needed fixing before I could launch. And, of course, being me, there was about a dozen other little niggles that I kind of knew about but hadn’t bothered to write down on my list.

This is where the schedule really broke down. Suddenly I was back in the land of uncertainty – which of those things should I tackle next? How am I going to solve that really hard-sounding one? Aghgh! It only makes matters worse that so many of them seem quite simple – all the more reason not to bother tackling them, since “I can always do that later, it’ll only take a minute”.

In the end I just had to bite the bullet, choose the hardest problem and crack on with it. I often find that once you actually start on something, it’s not nearly as bad as you think. Beginning is often the most difficult step.

Kicking It Out The Door

Once the holiday was over, I put the app to bed for a week whilst I got on with real life. I did show it to a few friends during that time and got a bit of user feedback, but I didn’t do any coding at all. I decided that if I was going to get this thing finished, I just needed to set myself a deadline and say that I was going to submit it to Apple no matter how many little niggles remained unfixed. Yesterday was clear in my diary, so I decided I’d just have to get as much done as I could and then live with the consequences for the rest. That turns out to be a really helpful motivator!

Even so, it amazed me how much courage it seemed to take to go ahead and submit the app. “How can I be sure if I’ve done enough testing?” “What if they find some really obvious bug right off the bat?” Well, you know what – it’s free to submit it, and you can always resubmit it later if they find something! It was a tremendous relief to finally get the thing submitted (even if it did require a complete reinstall of Xcode to overcome an annoying Java error – thanks again Stack Overflow!) and now I just have to work frantically on all of the marketing material whilst I wait to hear the result.

Conclusion

Overall, I’m so glad I decided to get on and make PrayerMate. I feel like I learnt loads about myself and why I find things hard and what I can do to help myself. And hopefully I’ve made a useful app that people will get some genuine benefit from as well. Here are my top five lessons:

  1. Clarify what you’re supposed to be doing at any given moment as much as possible
  2. Never believe the lie that something is “almost finished” until it is actually finished
  3. A very simple app that is finished is a lot more useful to people than a “fully featured” app that isn’t available for purchase
  4. Know when to stop working as well as when to get on with it
  5. You can get an awful lot done without the commitments on your time of “normal life”!

Be sure to watch out for PrayerMate in an App Store near you in the coming weeks!

How to Install PythonMagick on Mac OS X

I’ve been having a bit of a headache trying to install PythonMagick (the Python bindings for ImageMagick) on Mac OS X Snow Leopard, so having eventually had a modicum of success I thought I’d post my adventures here.

Problems Building From Source

But first, let me outline the problems I was having. Initially I tried building ImageMagick from source. That meant first downloading and installing Boost, which again I tried doing from source (1.46.1). When it became time to install the Boost::Python module, I tried following the instructions in the documentation:

$ cd libs/python/example/quickstart/
$ bjam toolset=darwin --verbose-test test

However, I’d find it would get so far and then just hang – I left it for about 24 hours with no progress. If I hit Ctrl-C and then tried again, it just sits there saying this:

...patience...
...patience...
...found 1603 targets...
...updating 8 targets...

Problems Using MacPorts

Since I couldn’t get very far that route, I decided to try the MacPorts approach, which makes installing these kinds of things very straightforward.

Again, first I had to try and install Boost, with the Python module enabled:

$ sudo port install boost +python26

So far, so good! That installed the package “boost @1.46.1_0+python26″. Next was to install ImageMagick:

$ sudo port install ImageMagick

Again, nice and smooth! That installed “ImageMagick @6.6.8-1_0+q16″. Now came the hard part: building PythonMagick. I used v0.9.3 since that seemed the latest version compatible with Python 2.x. The first step is to configure it. Reading around it became clear that I needed to specify the MacPorts include and library directories, like so:

$ ./configure --prefix=/opt/local CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib

But no matter what I tried, I kept getting the message “checking whether the Boost::Python library is available… no”. Eventually I figured out that you can get more information by reading the config.log file. I was getting all sorts of error messages like this:

configure:14953: checking whether the Boost::Python library is available
configure:14983: g++ -c -g -O2 -I/opt/local/include conftest.cpp >&5
In file included from /opt/local/include/boost/python/detail/prefix.hpp:13,
from /opt/local/include/boost/python/module.hpp:8,
from conftest.cpp:23:
/opt/local/include/boost/python/detail/wrap_python.hpp:50:23: error: pyconfig.h: No such file or directory
/opt/local/include/boost/python/detail/wrap_python.hpp:75:24: error: patchlevel.h: No such file or directory
/opt/local/include/boost/python/detail/wrap_python.hpp:78:2: error: #error Python 2.2 or higher is required for this version of Boost.Python.
/opt/local/include/boost/python/detail/wrap_python.hpp:142:21: error: Python.h: No such file or directory

These pyconfig.h and Python.h files and so on are usually installed with the Python development package, but supposedly MacPorts just installs everything all together under /opt/local/include/python2.6, so I wondered what was going on. But somebody put me on to a good way to find out where MacPorts has put stuff:

$ port contents python26 | grep pyconfig.h

That revealed that the include files were being installed in /opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6. So let’s try the configure again with that new information:

$ ./configure --prefix=/opt/local CPPFLAGS="-I/opt/local/include -I/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6" LDFLAGS=-L/opt/local/lib

Success! All seems to have worked this time – it picked up Boost::Python and no more errors showed up (I have secretly skipped a step where I installed the MacPorts python_select package to make sure that it was definitely using Python 2.6, but hopefully you can figure that one out on your own).

Building PythonMagick

But alas, not so easy. Next I had to actually compile the thing. And of course, it failed:

$ make
_Image.cpp: In function 'void Export_pyste_src_Image()':
_Image.cpp:89: error: address of overloaded function with no contextual type information
_Image.cpp:90: error: address of overloaded function with no contextual type information
_Image.cpp:97: error: address of overloaded function with no contextual type information
_Image.cpp:114: error: address of overloaded function with no contextual type information
... and many more such errors ...

It would seem that the ImageMagick API has changed a little, but thankfully the PythonMagick guys have patched that in the latest version. So I had to download PythonMagick 0.9.5 and copy the following files from it into the ‘pythonmagick_src’ directory of 0.9.3:

  • _Image.cpp
  • _DrawableDashArray.cpp
  • _DrawableMiterLimit.cpp
  • _DrawableViewbox.cpp
  • _Geometry.cpp

Installing PythonMagick

With that done, it then compiled quite nicely. So I run ‘sudo make install’, but then when I actually try and load it into Python, I get this error:

>>> import PythonMagick
Traceback (most recent call last):
File "", line 1, in 
File "PythonMagick/__init__.py", line 1, in 
import _PythonMagick
ImportError: No module named _PythonMagick

Hmm… So close! Yet so far away. Okay, well maybe I should just try adding the path where the module is installed to my Python path:

>>> import sys
>>> sys.path.append('/opt/local/lib/python2.6/site-packages')
>>> import PythonMagick
Fatal Python error: Interpreter not initialized (version mismatch?)
Abort trap

D’oh! Well, a quick look at the crash log revealed that it was now trying to use the version of the Boost libraries that I’d manually installed from source from ‘/usr/local/lib’ (rather than the MacPorts version in /opt/local/lib) so I deleted the unwanted versions and tried again. Then I got this error:

>>> import PythonMagick
Traceback (most recent call last):
File "", line 1, in 
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/PythonMagick/__init__.py", line 1, in 
import _PythonMagick
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/PythonMagick/_PythonMagick.so, 2): Library not loaded: libboost_python.dylib
Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/PythonMagick/_PythonMagick.so
Reason: image not found

Well that one’s obvious: I needed to add the MacPorts directory to my library path:

$ export LD_LIBRARY_PATH=/opt/local/lib
$ export DYLD_LIBRARY_PATH=/opt/local/lib

That gets me a little further:

>>> import PythonMagick
Traceback (most recent call last):
File "", line 1, in 
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/PythonMagick/__init__.py", line 1, in 
import _PythonMagick
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/PythonMagick/_PythonMagick.so, 2): Symbol not found: __cg_jpeg_resync_to_restart
Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
Expected in: /opt/local/lib/libjpeg.8.dylib
in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO

A bit of searching on Google eventually turned up this page that involves an egregious hack relying on case-insensitivity in Mac OS X:

sudo ln -sf
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib /opt/local/lib/libpng.dylib
sudo ln -sf
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib /opt/local/lib/libtiff.dylib
sudo ln -sf
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib /opt/local/lib/libjpeg.dylib

Still…. it seems to work, and I can now import PythonMagick into Python! Now I just need to test it.