Viewing entries in

4 weeks of Forge, Hammer and Anvil

It's been 4 weeks since I officially took over Hammer, Forge and Anvil, so I thought I'd write up some notes on the experience, things I've learned and encountered along the way.

The beauty of this acquisition was that there were already a fairly healthy bunch of users already using the platform, and some of them were also paying for the service. Before I set about writing a single line of code, I wanted to learn as much as possible as I could about how people were using the products, so I did a few things:

Communicating With Customers

By setting up Hootsuite to manage the Social Accounts

Each of the products has its own twitter account - @getforge @hammerformac @anvilformac. Along with my own personal twitter account and the new Twitter account I created for Beach (since Beach replaced my old service company Double Digital), this is setting up to be a Social Media Management pain in butt.

We don't employ anyone to manage our own social media full time, so it means we typically do our own social media pretty poorly. With Forge, there's a number of ways to communicate with our customers, but with Hammer and Anvil, it's much more difficult as we don't know who they are.

So, Twitter is a very important channel, until I can establish Forge as the main platform for all of our customers to use with whichever Beach product they are using.

Using Hootsuite at least gives me a fighting chance to keep on top of @replies and mentions, support requests and product feedback.

It was particularly useful when Forge went down a few times, to relay important platform status information and therefore limit the customer support requests that would inevitably come in.


Getting to Know Our Customers

By installing Intercom into Forge

One of my favourite products, one I've used on all of my products since way back in 2012, is Intercom. The first thing I did on Forge was install it and start talking to customers directly. I made sure I was on hand to respond quickly and thoroughly to all users of the service, to really understand what they thought of Forge and what their concerns were. 


The main support requests I received related to Deployments getting stuck. Sometimes this happens and users would just see the endless spinner syndrome - not a great experience. Most of the time, it's due to something fairly innocuous in the uploaded archive, but also the deployment just fails sometimes and can easily be fixed with an intervention on the technical support side.

Forge is actually doing quite a bit of work behind the scenes whilst the site is deploying, and it's great that this is invisible to users most of the time, but when things do go wrong, it's also really important to provide enough information to be useful in understanding what's gone wrong and how it can be fixed. Watch out for some improvements coming in that area soon, including some slightly more elegant logging and console tools.



Understanding Our Value

By creating a survey on Typeform

I issued a very simple customer survey via one of my favourite products of the moment, Typeform. This gave me a very impactful way to understand the challenge ahead of me. I wasn't really sure how existing customers felt about our products right now and I felt I needed some insight to better approach the future.

The feedback from customers was very consistent. There was a genuine love of the products, the design and simplicity of how the products went about their business. It's shown me just how important it will be to keep this guiding principal as I start to evolve the products.

There was, understandably, an overall tone of frustration. People were on the cusp of giving up all hope that these products would still be alive in the days or weeks to come. So, I was met with some scepticism, but genuine optimism at someone new stepping up and taking these products over. People really loved Hammer, and I think, would really like to love it again. 


Championing Our Customers

By creating a customer showcase

There are some super smart, incredibly creative people people using our products to do amazing things and that makes me so proud. I'm a big fan of championing customers, making them the stars of the show.

My first step was to reach out to those I'd identified and invite those who felt they related to the idea, to showcase their profiles on the Forge website. It was fascinating to understand how they use and love our products in their daily workflow, some relying on all three - Hammer, Forge and Anvil, whereas others really only relying on just one product. That's fine, but it's crucial in my eyes that everyone is celebrated for the great work they do and to inspire others.

The first 4 went up last week and I'm build out applications from many more customers, all of whom I'm incredibly envious of their talents.

I'll be publishing more in depth interviews and profiles on each of them very soon on the Forge blog, which will be the main resource for updates and news about each of our products.


Working on the Roadmaps

By creating public roadmaps on Trello

I've always been a fan of bringing ideas out into the open and sharing in how those ideas evolve and get implemented into products. So, it was a no-brainer for me to firstly establish the principal of public roadmaps for these products. Trello is my go to choice, since I already use it daily for managing internal product development tasks.

The feedback I received from the Customer Survey and from directly talking to people through Intercom, all goes into these boards, starting with the one for Forge.


Users and Customers are free to add ideas, comment and vote on others which helps me to understand demand and prioritise our workflow. It always takes a bit of time for people to get into the habit of contributing directly here, but is an area I really hope will build out organically as we gather momentum.

In August I'll be releasing the Hammer roadmap for people to contribute and stay informed on the progress.


Learning About Our Business

 Using Stripe, Chart Mogul and App Figures

We use Stripe for processing payments on Forge. For Hammer, we rely on the Mac App Store.

Both of these services are very well served by some supporting services that provide a way of looking at the data to get a better understanding of the nature of your business, instead of purely looking at timeline transactional data, but looking in terms of your key metrics.

Until I figure out what our "2000 Users" killer metric is, I'm really interested in understanding how new customers find our products (funnel), which product they choose to buy (pricing model) and how long they stay for (churn).

Screen Shot 2015-07-20 at 13.24.16.png


I found that Chart Mogul is a great service for making the most of Stripe data, though I also quite like the native Stripe apps. Chart Mogul provides information in relation to churn rates, and when I get deeper into this, I'm sure will provide much more value still.

The App Store data via iTunes Connect is typically crappy, so I'm using AppFigures for tracking the performance of Hammer. Despite the obvious frustration since stagnating the development, people are still downloading the tool and still love it. So, I'm really hopeful that when I get into the next version development, we can re-establish the trust and passion for Hammer that it once showed such promise for.

Through this initial research, I made some quick decisions on evolving our pricing model. I felt that the free version was too generous and creating too much of a comfortable zone for new users to exist in. Instead of the 5GB limit, I reduced it to 1GB. 

The $10 plan, I felt was also not driving enough value to prompt people to take that big step of putting their hands in their pockets to pay for the service, so I doubled the number of sites that can be created from 5 to 10.

I didn't think there was then enough of a significant difference in value from the basic plan to the paid plan, so I took a big step to remove the limit on sites entirely - you can create unlimited sites with custom domain for $50 per month.

A big feature of each of the paid plans is the Customer Support. It was never something that was really part of the feature set, but hopefully I've made a successful attempt to establish my intention to ensure that we really focus on supporting our customers, through all of the tools that we have available.


Tackling the Crooks

Using Intercom and Rack::Attack to block the crims.

All of a sudden, Forge went down. Panic. Was it something I did? I'm still figuring my around the stack, did I botch up the CDN settings? Did I knock out an EC2 instance? Arrghhh.

Turns out, no.

As I was getting to learn about the Forge user base, I discovered that there were around 100 accounts registered on the platform with Nigerian locales. On deeper inspection, it turns out that many of these accounts were using Forge to create suspected phishing sites and Amazon weren't thrilled about it.

Once I figured this out, I went through and removed offending accounts, sites and established some rules for new user signups to prevent this type of thing happening again. 

One way is simply to monitor the new account registration activity, this is time consuming, but a very important exercise to understand how people are using Forge. Intercom is a great tool for this, particularly when I have it setup to fire notifications into a dedicated Slack channel.

The other way is to maintain an active blacklist of IP addresses, using Rack::Attack.

I have a feeling this wont be the last we see of this issue, the virtues of a free account service, but we will monitor and do our best to prevent breaches of our terms of service.


So, that's an overview of some the main aspects of what we've been working on the past few weeks - I wont bore you with the drudgery of actually managing a transition of tech from one party to another.

I'm very excited that we're now starting to pick up the challenges of some of the Forge roadmap, from stabilising and updating the underlying technology, improving performance of existing critical features and starting some new shiny things too.

Why Forge, Hammer and Anvil?

Today is a great day and I am very happy.

I quietly announced that my company,, has acquired three small products: Hammer for Mac, Forge and Anvil, from the guys at Riot.

A few thoughts on Hammer

Back in 2012, Hammer was born with a flurry of excitement. Back from the initial commit by Elliott to the Hammer server-side repo on June 10 2012, up to the announcement pretty much bang on 6 months later that the app was flying

People loved Hammer. It was a breath of fresh air for Mac-touting front end dev's everywhere.

I know this sentiment very well. I wasn't the first user of Hammer - in fact after signing up for the initial BETA, I didn't quite understand what it was for until I really got stuck into the first release.

It was a REVELATION to me

I wrote this guide to Hammer back in September 2013.

Since then, I haven't done anything static that didn't involve Hammer.

  • I prototyped new UI concepts for Currys / PC World
  • I used it to build Brand Swatches and Style Guides for Breast Cancer Campaign
  • I prototyped early static screens and clickable prototypes for Nourish Care
  • I built and ran value proposition experiments and lead generation for Ferticentro
  • I built product websites for Nuwe, HealthHackers, Nutribu, Beach, Double Digital
  • I used it during Hackathons
  • I converted many themeforest themes into Hammer templates just so I could use them without drowning in long HTML files...
  • I converted the Startup Framework into Hammer templates

2 years after Hammer's first release, I'm still an active customer and user of the product. But the world of Developer Tools moves so fast. We've seen the rise of javascript libraries and frameworks, from Backbone to Ember to Angular to React and Mithril. We've all been struggling to keep up, to place our bets on what will stick and what will fall by the wayside. 

In this time, we've seen other tools with similar promise to Hammer rise in popularity as the products have continued to adapt as the development technologies we use have evolved. Codekit, LiveReload, PreProc, CactusCrunch and Koala to name a few. [Editor: See additional notes at the bottom of the article]

I've tried them all in this time, but there's something about Hammer that keeps me coming back.

But, it seemed something was not right with Hammer, the updates stopped coming. New releases were not made. All was quiet. Meanwhile...

A few thoughts on Forge

Having been a Hammer user since early 2013, when I found out about the new service from Riot, called Forge, I was keen to dive in. In October 2013, when Forge opened its doors, I was right there to give it a try.

I had been having a torrid time with basic hosting, using Fasthosts VPS. It had caused me no end of bother, considering I didn't really want to be doing hosting in the first place, but when you're running client projects, it's something you end up just doing to avoid the inevitable hand holding of a client-managed hosting setup.

So, as soon as Forge came out, I moved a number of my simpler static sites straight over. That wasn't before I'd also wrestled with Amazon S3 for static site hosting, and found updating S3 buckets, configuring permissions and Route53 settings to be a pig of a job for something that should be so straightforward.

That's exactly what Forge was. Dead, dead simple. Drag, drop and forget.

I remember getting so pee'd off with the whole thing, I even ran a couple of demo sites straight out of a public Dropbox folder, I mean, jeez - so when Forge released Dropbox (and Github) integration, I was like "...are these guys reading my freakin' mind?"

Forge is like a bit of a secret weapon for me. In a way, I never really wanted to tell people about it, like they would discover my kryptonite or something. I've hosted everything from coming soon pages, to single page web sites all the way up to a rather nice React app with integration on Forge. It's not as "static" as you might think.

I always thought to myself, I'd love to have some products like these, Forge and Hammer are just awesome - amazingly well executed, beautifully designed, simple propositions which really do have an impact on the way developers work.

Since Forge was released, we've seen a number of other static site hosting services, none more significant than Github's own pages service. Then there's Divshot, BitBalloon, Roots, Netlify, Site44, Paperplane and Brace (acquired by Squarespace)

Once again, as I could tell that Forge was not progressing at the velocity that I had hoped, I tried all of these services, but somehow, kept finding my way back to Forge.

A few thoughts on Nuwe and Me

I am CTO and co-founder of a startup, named Nuwe, which we founded in 2014. I have a small tech company, a bit like Riot, called Beach and we specialise in web and mobile app development, mainly focussed on products.

At Nuwe, we are building a developer platform which provides a Platform as a Service for people making new mHealth apps and services. I love ideas with real Social Capital.

We were recently accelerated by Startup Bootcamp, as part of the Barcelona IoT and Data Cohort of 2015.

I come from a rich background of experience in running large and small projects, from PHP-based web apps, e-commerce and CMS builds to more recently, the last few years focussing mainly on Ruby (rails), Node.js and native iOS projects. I'm a developer, product manager, team leader, entrepreneur.

I have 2 small boys, 2 basset hounds and a very understanding wife.

With Nuwe, we've been helping 20 or so companies to build their mHealth apps with significant cost and time savings, during our closed BETA phase. What I've seen in this process up close, is that although the technologies we use to build products vary massively (a huge challenge for us being truly platform agnostic), that the real problem and barrier to growth comes with the understanding and application of the skills required to build and iterate on new ideas from the ground up. Those aren't technical challenges. They are a mindset barrier.

I've seen, first hand, the tendency to assume too much, to believe our own instincts and write feature requirement after feature requirement - often forgetting the real people who you want to buy the product and drowning behind the desk in the belief that what we're building is the right thing, the thing that people want. I've seen it with startups, indie developers and with large multinational corporates.

A big challenge for the creators of new Health services, apps and services in general for that matter, is in obtaining and practising better product development processes and that starts even before we even lay down one line of code on our product.

One of the best parts of the accelerator process for us, was to disconnect from the need to build software and reconnect with our audience. We designed, tested and iterated our value proposition over and again until we found something that resonated - in language, tone, style and structure. 

Doing that somehow free'd us to build later, faster and in a more targeted way. All we needed was a website, a view of the problem and way to communicate the solutions we had in mind.

Through all this, I knew we needed to help educate our customers to maximise the use of our platform and that we'd need to invest in the content and the tools to provide this.

The Convergence of Pathways

It was a chance conversation between myself and Elliott over twitter, since I knew of his move a while back to Dropbox, to ask him what his plans were for Forge, in particular, when we started talking about the future of these products.

Within a few hours we were talking about a deal that would see me take over the on going management of Forge.

And within a couple of weeks, we'd struck a deal for me to take over the ownership of Forge, Hammer and Anvil.

You see, Elliott and I have similar visions for the products they originally created. Elliott still has unfinished business for sure and so I was delighted when both he and Hector agreed to stay close to the products as key advisors and to share in any future success as the original creators.

There's a number of things that need to be addressed quickly, in my mind as a customer of the products and I'm sure you'll agree with those.

There's many routes that these products could take, and I'm sure we'll become more divided on those ideas as we progress, since the landscape is evolving all the time.

One things is for certain, these products don't deserve to end up on the crap pile. They're too damn good, too damn valuable and have too much bloody potential as yet unfulfilled.

My Simple Manifesto

I think that it would be rather premature to tell you what I plan to do, so it might make more sense to outline what I believe in.

Customer Service is Top Priority
One of the things I want Forge to be known for is Amazing Customer Service. It's going to be hard, we're a very small team to start with, but I see the potential for this product and I will do everything I can to make sure the service you receive kicks the cr*p out of the larger, less personal and more sales-driven companies. The service will be personal and the best way to reach us is via the new Intercom tool in your Forge admin area. Look out for this...


Openness, Transparency and Collaboration
I'm going to bring openness and transparency to the roadmap, I want all of our Customers to have a say in the way that Forge takes shape.

Build and Enable Great Products
I believe in Products. And whilst Forge itself is a product, the customers using Forge are also building and promoting their own products. So I think Forge is a tool for creating better products and better businesses and this will guide what we do with Forge.

Simplicity Is Beautiful
I love simplicity. And that's why I love Forge and Hammer, it really was the easiest way to host and build my websites. Even so, some things are still not as simple as they could be and there's lots of things I'd like to add. Remembering this value will be crucial.

Social Capital is Really Important
I like working on things that provide an amount of Social Capital. If you're in Education or you're building products for Health, then I'd especially love to hear from you to see how we can help you further.

I'd love to hear your thoughts on any of the products, ideas you've been mulling over and waiting for over the past couple of years and your own visions of the future.

Follow Forge on Twitter

Follow Hammer on Twitter

Follow Anvil on Twitter



Edit: Thanks to @TheLoneCuber and Bryan Jones (@bdkjones) from Codekit for pointing out the potential for interpreting the article in a way that I hadn't intended.

It seems it could have been read that I was suggesting Hammer was the first tool of its kind in the market - that wasn't the intention. I was merely trying to make the point that since Hammer was released, other apps have continued to evolve and establish a place in the market and Hammer has not evolved at the same pace over recent months.

To clarify, and as both had pointed out, Codekit (thanks to Bryan's exhaustive and often entertaining public release notes) actually went live into Public Beta in November 2011 and according to the project's repo, Hammer's first commit wasn't until summer 2012.






Today's christmas festivities were celebrated in the form of a bit of hacktastic skullduggery, in the form of an overdue get together of Bournemouth's finest coders, hosted by our friends at RedWeb.

I decided, given the festive season, to take some time to get acquainted with SpriteKit and build out the game idea that I had been conceptualising with my little 3 year old son Rudi.

The game, a Disney Cars inspired shoot em up, where Rudi, the games main protagonist, gets to fire his warchest of cars toys at the oncoming Tyger (Rudi's one year old brother). The premise of the game, to provide a virtualised outlet for Rudi to satisfy his insatiable urge to throw things, whilst teaching him the appropriateness of his actions in real world and virtual settings.

I set the game scene up quickly, based on a fairly generic xcode SpriteKit game template and the very entry level tutorial from Ray Wenderlich.

The main customisations I made, aside from the graphical components, were features driven by requests from my son.

1. "Daddy, can I throw different Cars?" 

The initial game setup just had a single projectile type, the obvious Lightning McQueen. So one of the first orders of business, was to create a full armoury of projectiles, of our favourite Cars characters.  First request was for Professor Z, and not content for long, I added 9 different options. 

I setup a UIVIew container, and placed the UIButton outlets inside it. I created a UIButton *menuButton which would have a background image that reflected the currently selected image. When the menuButton is pressed the weapon drawer will toggle open and closed.

2. Unlocking Weapons

It would be all too boring to just put all the projectile types in the tray from the start. Instead, I setup a simple game mechanic that involved unlocking the projectile types when a certain number of hits had been achieved. Whenever 

projectile:(SKSpriteNode *)projectile didCollideWithMonster:(SKSpriteNode *)monster

is called, the int pointsCounter is incremented and the score label text updated. We also save the score to the NSUserDefaults.

- (void)projectile:(SKSpriteNode *)projectile didCollideWithMonster:(SKSpriteNode *)monster {

[projectile removeFromParent];
[monster removeFromParent];
if (updateLabel == NO) {
updateLabel = YES;
[self updateUserDefaults];
[self loadProjectiles];

3. "Daddy, can I move myself?"

I enabled Core Motion, to access the accelerometer to enable using the tilt of the device to move the Rudi character up and down, whilst firing at the on coming baddies.

I found this tutorial to be quite helpful here:

What next?

There's still much to do before the game will be accepted by its harshest critic. Some of the next things will be:

  • Fix some bugs with current physicsBody affecting the Player node.
  • Use SKParticleEmitter to create collision explosions, projectile trails, and smoke.
  • Create levels
  • Give projectiles different properties and behaviours.
  • Parallax for background scene to provide some depth

Thanks to the internet for providing the images and other such assets.

Why Do We Need Apple?

Why Do We Need Apple?

Why we need Apple?

It’s no secret that I’m an avid Apple fan and user-  Apple Ipad, Apple Ipod, Macbook Air and Iphone. I have never been a fan of any other system such as Android, Windows etc, I find them too cluttery and a bit all over the place. My first smartphone was a Samsung Omnia and it was awful. The windows system, then, was in no way as good as the simple Ios from Apples 3G model. So I can safely say I couldn't be happier about Apple’s latest announcements. Why? Because what Apple does affects us all.

There’s a tendency in the tech world- and especially as it relates to mobile OS-es to believe that the tech giants operate independently from each other. Apple makes its products, Google makes its operating system and any overlap is copying at best, and theft at worst. This view fails to take into account a lot of the complexities of how tech operates.

Apple Has the Scale to Reach Millions of Users

Perhaps, the biggest reason that Apple matters is it's distribution scale. Apple isn't the only one who puts good ideas into their products. But making a good phone doesn't matter much if you can’t put it into the hands of the people who want it. Some features (like NFC payments) only really catch on if a lot of people are using them. Apple is one of the few who can put phones into millions of hands.

When Apple launched the Iphone 5s last year, it initially launched in 11 countries, reaching a total of 50 countries by November 1st. This is possible due to the massive infrastructure that Apple has devoted to its one product line.  According to reports, Foxconn- one of Apple’s biggest suppliers- is able to crank out 500k Iphone's per day. Thats a 24-hour work cycle (bogged down with human rights violation problems. Not that this is unique to Foxconn or Apple), but for context, at that capacity, Apple could make 45 million Iphone's in 90 days. One quarter.

Compare this to a recent up and comer: Motorola. After Google purchased Motorola, it made a huge sweeping overhaul to its management team and cranked out a product that, while not impressing spec geeks, was still more than good enough for most people. Allegedly, it sold 500,000 in 90-days. Even if those sales numbers are inaccurate, though, Motorola itself claimed it's Texas facility-home of the customised Moto maker handsets- could only make 100,000 handsets per week. For context, for a 90-day period that would be roughly 1.28 million units. Thats still about 43.72 million units behind Apple. Motorola pioneered customisable hardware which could have shaken up the mobile industry, but because it couldn’t  deliver that to more than one country at launch, almost no one noticed.

Samsung is the closest non-Apple products to have the same scale. In Q2 2013, Samsung pushed 71 million smartphones, compared to Apple’s 31.2 million over the same time frame. Not all of those are flagships but the fact remains that Samsung is the only Android manufacturer that can compete in this arena.

To push a new type of consumer tech, you need consumers to actually use it. Unlike fan favourites such as HTC or Motorola, if Apple wants to make a device popular, it has the means to do so. Retailers need a reason to upgrade their systems to support NFC payments. Apple can give them 45 million new reasons every quarter. No matter how much their fans like them, HTC and Motorola can’t do that.

Apple Has the Cool Factor to Gain Mindshare

Whether you call it high quality hardware or reality distortion field, the fact is that Apple makes products that millions of people really love. Not everyone, but enough. Enough people, at the very least, to nudge consumer mindshare into a direction Apple chooses. Like wearing a computer on your wrist.

We saw this happen to a certain extent with voice commands. Despite Google now being just as good as (and sometimes better) Siri, the latter is the one that became a brand unto itself. Voice command jokes maybe useless, but they give, what is otherwise just a smartphone feature, personality. Simply put, no one’s asking whether or not some day we will have meaningful relationships with Google.

Does this mean Apple is the only one making cool features? Definitely not. But fashion matters in tech. Arguably, Google Glass’s biggest failure from what I have seen personally and read isn’t the tech, or its practicality, or even its oddly invasive camera. It’s that Glass simply just looks silly. Maybe it shouldn't be. People wear glasses in their every day to day life. But when you attach a bright orange camera to someone's eyeball, it puts people off. Coolness matters and, for the time being, Apple is still pretty damn cool.

Wearables is another big area where coolness is going to matter. Smart watches have been around since before the pebble, but they still have the perception of being very silly. There are no guarantees in tech, but Apple may just be able to make the smart watch cool. The category certainly needs the push, and after the announcement of the Apple watch, they might have gotten it. Not only will it become more socially acceptable to wear them, but Android users will probably have more (good) models to choose from if it catches on.

Apple’s monopoly on cool isn't totally absolute, of course. Google’s software design has arguably become much, much cooler in recent years. Bigger phones have become cool enough for Apple to follow suit. But Apple does still have a lot of cool collateral in its coffers. More importantly, as stated before, it has the manufacturing capacity to back it up. Quite frankly, despite pushing the same number of units, Samsung doesn’t have the same fashionable factor. This puts Apple in  a unique position, particularly in terms of appealing to a key, influential demographic.

Gold Iphone 6

Apple Has a Wealthier Target Demographic.

Apple products aren’t necessarily overpriced. They’re just expensive. The same goes for the price of a good quality laptop from a different manufacturer.

The difference with Apple is that “expensive” is the only price point they reach. There’s no budget iPad for £200. The cheapest Mac you can get is £899. The lowest price for a laptop is £749. The new Apple Watch will cost around £250 for the smaller screen watch, which is nearly twice the cost of the early Android wear devices. For any other company, this would be suicide. In fact, for Samsung's smart watch, it sort of was.

There’s nothing inherently wrong with this approach, but it means that Apple necessarily excludes poorer demographics (and countries). The Moto G is sold in foreign markets where a £600 phone is prohibitively expensive. In fact, arguably, Android was only able to get to where it is today because it’s able to cater to more than one price point or type of market.

“Android is popular because it is cheap, not because it is good.”

With exclusionary prices, though, comes status symbols. And status symbols, by their nature, are more often owned by the wealthy. Money shouldn’t necessarily buy influence, but it often does. Businesses with cash to spend will invest in technology they think is worthwhile.

Countries with more money will determine what devices will become more popular. That is why the US and China are important first launch markets, while Haiti doesn't come up too often in conversations about mass market appeal. It’s callous, it’s insensitive, it marginalises some groups, and it’s true. People who sell things need to find people with money to buy things in order to survive. And Apple, by its very nature, appeals to people and businesses with more money.


Competition Matters, and Apple Is the Biggest we Have

None of these factors are exclusive to Apple. However, the just-right combination is pretty rare. This means  that, even if you don’t use a single Apple product, the company probably has some influence over the technology that you use. Android wear, as an example, might be an excellent product. But without a company like Apple to make wearables fashionable, it’s not entirely certain if they would catch on. They’ve certainly struggled so far.

Not to mention, there’s other little competition. Without Apple, the entire Android world might get over run by Samsung (arguably already has). Without Apple, there’s almost nothing competing with Windows. Without Apple, the “who’s better than who” discussion will die out almost entirely. Even if you hate Apple, that rivalry drives us to do more.

That type of competition will always drive companies to out-do and borrow from one another. It’s possible that Android wouldn’t have worked on Project Better if not for Apples smoothness, in the same way that Apple might not have made its own notification shade following Androids lead. One lends itself to the other. It’s the circle of competition, and we’ll all benefit from it.

Of course, no one’s saying Apple’s the only one that drives competition or the only one who comes up with the ideas. But it does popularise many of them. No one is giving credit solely to Apple for inventing all technology. Just because Apple prefers a walled-garden approach to tech, though, doesn’t mean it actually lives in one. 




Links to Resources

















How to format ISO 8601 Date Format in iOS

So, it turns out NSDateFormatter, a formidable class for converting and manipulating date formats in iOS development, met its match with the ISO8601 date format that I was getting from a rails based API. Or at least, that's what I found. So here's how I coped with it:

The json:

"start_date": " "2014-10-26T21:00:00.000+00:00"

Turns out, NSDateFormatter can't parse this.

I did quite a bit of digging around and in the end, my friend and mentor @HunterBridges pointed me in the direction of this nifty little library on GitHub

It even has a nice little xkcd comic in the README, so definitely work checking out, just for that.

I downloaded and extracted just the header and implementation files "ISO8601DateFormatter" and included them in my model class. 

#import "ISO8601DateFormatter.h"

Then, in the implementation where I was initialising my model instance from the API response dictionary:


NSString *datestr = [result objectForKeyNotNull:@"start_at"];
NSLog(@"Date String: %@", datestr);
ISO8601DateFormatter *dateFormat = [[ISO8601DateFormatter alloc] init];
NSDate *date = [dateFormat dateFromString:datestr];
NSLog(@"Formatted Date String: %@", [dateFormat stringFromDate:date]);


Note "objectForKeyNotNull:" method is a convenience method for making sure the result doesn't contain a null value.

So, I grab the original date format from the web service response and save it as an NSString.

I then alloc and init the new ISO8601 class as dateFormat variable. Then I create a new NSDate object and call dateFromString on my dateFormat variable, passing it the original dateStr variable as a parameter.

And that's it. Later on, I create a normal NSDateFormatter to parse the new date object and get just the time in HH-mm format, which is what I actually wanted for the app feature I was building.





If Snapchat and Tinder weren't evil || Lumpy - iOS App (part 2)

Then they'd probably do something like this....

A while ago, I wrote a post about a particular product hypothesis I had. I won't regurgitate the underlying rationale and background research, but needless to say, I think it's compelling enough. Since that time I've been pretty full-on building my startup Nuwe & consulting at Nourishcare.

But, a couple of incidents recently brought back to my attention this concept and I've decided to flesh it out a bit more. Today peoples, we're fighting cancer. And broken bones. And probably other things, but let's stay humble for the time being.

A few weeks ago, we were on a family holiday to Center Parcs. Near the end of the holiday, my 3 year old son, Rudi, fell off a coffee table and hurt his arm. It was clearly painful, and despite continuing to cycle and swim, he was also clearly carrying his arm in a way as to relieve the pain. When we got home, we took him to the doctor, who assessed and prodded and poked and, reticent to x-ray a 3 year old, advised us to monitor the situation. My wife and I asked each other 10's of times, whether we should take him for an x-ray, it clearly wasn't right. We asked each other, we asked other members of the family. We asked and asked and asked.

A few days later, we decided to take Rudi to A&E, and it turned out, he had a broken collar bone!

A week later, my wife went on a spa day with her girlfirends. Much to my amusement, she came hobbling home, having slipped getting into the jacuzzi and couldn't walk. A few days later and her ankle was purple. Again, the questions started - should I get it checked out? is it broken? 

How often must this happen? How often must this be needed but the person doesn't have anyone to ask? These are questions that tickle my interest.

What have Snapchat & Tinder Got To Do With This?

Does a day go by without seeing some rip-off of a snapchat or tinder type feature, UI approach or app clone? Well, don't expect anything different from me. Let's get all popular culture and ask ourselves "WHAT IF"?

What if, Tinder's amazingly engaging and simple gesture based UI could be put to use for more promising purposes?

What if, Snapchat's ephemeral messaging system that is popularly used for kids sharing naked photos of each other could be used to encourage sharing of sensitive visual information - such as photos of suspect moles, skin blemishes, lumps, bruises, potential broken bones - things we want to share, should share, but can't?

How does it work?

1. User takes a photo of a suspect skin blemish, mole, bruise, lump - something that's concerning them and they just want to invite feedback from family, friends, or the general public.

2. User selects the people they want to receive a very simple binary response - yes/no -which aims to answer the question "should I get it checked out?"

3. The responder receives the message into the person inbox, and is notified via push notification and if not responded after an amount of time, receives an email to their inbox.

4. The responder selects the message, which loads the message details. This contains the image "card" ala Tinder. The message will be visible for 15 seconds, encouraging the recipient to respond with their "gut" reaction and not to dwell / risk dropout and non-response.

5. The message will self-destruct after the timer runs out, and the message will no longer be visible to the recipient. Attempts to take screenshots using the camera will trigger the view to close before screenshot is taken.

6. The user can then embellish their response with additional notes and comments - personal experiences, words of encouragement, advice etc.

7. The user is notified when responses are received, and can view a summary of the responses on the message detail view, helping them to decide what action to take next.

8. Users can configure their settings to ensure their images are also deleted from the server, or retained on the server for their own personal future use and also for the benefits of research and visual recognition and machine learning for predictive diagnosis of skin conditions and injuries.

Take a photo or video

Select the recipients

Recipients received requests to their inbox

Time to Vote - who does it look?

See the results

Next Steps...

Next we have to validate this concept with our target audience, and for that we need to start to hypothesis who that will be, how to reach them, what they might pay (if they will) for the service, how much they'll cost to reach and a billion other questions...

10 Tips for Building Wireframes

10 Tips for Building Wireframes

I have been learning to create low and high fidelity wireframes for both mobile and web devices. There are a variety of different tools you can use to create these wireframes like Illustrator, Photoshop and Sketch ( only available on Mac ). I have been using Sketch 3 to wireframe as its a simple combination of both illustrator and photoshop. 

More and more designers are using vectors for wire framing. The following tips will help you make the most of your wire framing experience. 

Wire framing is about working rapidly and iterating quickly. The aim is not to create attractive interfaces; your number one priority is to design information and experience. 

Below are 10 tips that i believe to be important when designing wire frames. 

1.  Start Sketching

Sketch them first with pencil and paper for a quick sanity check. This should take about 30 seconds and opens up the possibility of getting early feedback. This can save a lot of time and money. The feedback gained through peer review or, best of all, from some early and informal user testing (you may need to spend a little more than 30 seconds on sketches if they're for user tests). 

2. Go Monochrome

Wireframes make clear the hierarchy on a web page; they visually demonstrate the order in which users should process the available information. If you want users to process the headline before hitting the "buy now" button, the headline needs to "trump" the button by demanding more attention.

This visual hierarchy can be defined in a number of ways. We could use size to make the headline more impactful, we could use positioning (by placing it before the button). We could use colour, contrast and a range of other things, but doing so in a wireframe only makes things more confusing.

By removing colour from the equation, the visual relationship defined by position, size and (if you want to go the extra step) contrast, is much cleaner.

We're not building pretty, pixel perfect UI kits here. Stick to a limited range of greys, then use color just for labels and notes. 

3. Don't forget the goals of the page 

Keep the goals of the page in mind when designing a wireframe. Focus on driving action. Organise the information into hierarchy that serves the goal of the page. 

4. Pick Your End Point

Prior to commencement, work out who will be consuming the wireframes, how they'll consume and what what level of fidelity is required. Remember that theres a relationship between the level of fidelity and type of feedback. Will quick paper sketches suffice or will they need to be fully interactive with accurate dimensions? Keep in mind: the less precise the wireframes are, the more liberty and creativity a designer is going to take with them. On the other hand, if you think they look perfect designers may feel inhibited and merely "colour in" the wireframes, preventing the design process from really getting going. 

5. Keep the rest of the team informed

Wire frames are not just for the client. All members of the web team should provide feedback on them, buying into the process at an early stage.


6. Use common elements

When designing a set of pages, use tools that allow you to make multiple changes to all common page elements at once. Moreover, as you're creating the wireframes, look out for design patterns that repeat. Leveraging these is key to gaining efficiency and consistency. 

7. Consider the content

If your wireframe aren't sketches then be realistic about the amount of content that will be added to the page. This holds true also for number (and length) of links and navigation. If practical use accurate sized fonts, images and consider what will happen when more text then ideal is added. Nothing on the web should be etched in stone, so ask if the design will flow as required. 

8. Draw on your experience

You do not need skills in design or development. All anyone needs is experience in using web apps or websites. Of course the more experience the better but you don’t need to understand relational databases to wireframe.

9. Keep it clean

If a particular page requires two text boxes and a button then it should have just that, no more, no less.

10. Get feedback 

I have learnt not to be afraid to test your wireframes with a couple of informal user tests. Grab people from around the office and ask them to find various bits of information or explain what they think the function of the certain elements is. 














10 Best Practice Tips for User Onboarding to a Mobile Application.

10 Best Practice Tips for User Onboarding to a Mobile Application.

1.The Goal.

The main goal is to accommodate your user and to get them using your product, ASAP. It’s highly important to make a fantastic first impression and to then carefully familiarize your users with the product so that they come back.


2. Communication is key.

You don’t want to talk their ear off but you want to be as charming as possible. Simply: Tell the user what they need to know. In as few words as possible, make them like you, being as witty or delightful as you can while doing it. It is also important to make sure you type in the correct formality for your members.


3. Welcome them properly.

It doesn't feel great spending so much time filling out registration and membership forms to then only walk in through the door with every single staff member acting as if you don’t exist.


A major part of the on boarding process is making a new member feel welcome. You want to be able to thank them for taking the time to join your product instead of just sending the invite to the junk box. If you haven’t set up a welcome email, then make one. It doesn't need to be long.


4. Making it easy.

This is where you will lose sign ups. Life is complicated enough as it is and if you do not make your sign up simple, you will be losing customers. Take some time to figure out what you actually want to know from your customers- the bare basics.


5.  Save them time.

Nobody, including ourselves, like being asked to fill out questionnaires or registration forms by people in the streets. You’re in a rush, you have to go to the doctor with your headphones in.  I’ve used all the excuses in the world not to stop to be asked to fill out a questionnaire. We don’t have a lot of spare time. We value our information and don’t necessarily feel comfortable sharing a lot of information right from the start.



Social log-in is a great time saver that is appreciated by a vast majority of consumers. You’re going to have some people who do not want to use this option, but you can offer a different mode for them. Pinterest is a great example of this. They have an option for a social log-in, or you can create a direct account. Do the same thing for your visitors.

The on boarding process should be warm in tone, fun and offer additional guidance if necessary. For example, if you've got a video available on how to make the most of their experience, this information should be included both in the email you send out and in their welcome  page.

6.  Creating a compelling CTA.

No matter what market you’re in, chances are you are facing some stiff competition out there. What can you do to make signing up for your customer a “must”? Take a step back and distil what it is that makes you unique into no more than 2 sentences. Your tagline should be placed in a prominent spot on your landing page.

7. Making Referrals.


The best way to make an influential person shout about your company? Start including friend referencing on your boarding process.  A fantastic example of this is Facebook. When you sign up and are getting your profile ready, you have the option of inviting friends/existing contacts.

There is nothing more influential than a customer who is totally excited about what you have to offer and wants to be the first person to share it with friends.

The added benefit of a referral goes back to your growth funnel. It takes a lot of people pouring into the funnel to keep it full so why not let your customers help you keep it full.

8. Don’t break the flow.

Designers usually strive to get the users into a state of “flow” in which a person performing an activity is fully immersed in a feeling of focus, full involvement in the process of the activity. There are many tools to help designers make this happen that can also be implemented into the design of your on boarding process.


One of the main requirements is to be as unobtrusive as possible. For example, don’t surprise your users with unexpected pop ups and messages. The best way to prepare the user is show them what steps are coming up and what they have left. For a fluid experience, context is important.



9. On boarding is a relationship and is ongoing.

Relationships are built on trust so don’t mislead your users and make it easy for them to trust you. Your users are new and are figuring out there way around your product. You need to nurture the relationship between yourself and them to keep the relationship going. Engage your users in a natural yet friendly way. You should spend time very early on in the on boarding process getting to know your users and what their needs are. This could be sending me them a personalized note to each individual right after the moment of email verification.10. Ease them in gently. People, including myself hate it when you visit a page or an application where it’s so busy and over complex, it makes me want to stay away. This isn't to say that you should not do something personal and fascinating.  What you don’t want to do is overwhelm the new users on their first visits to your application.There some examples of pages and apps where all the white space is full of content. Colours, images and words. It can all be a bit too much for a new user to handle. With some effort, the experience can be elegant and informative without over stimulating the user. Short tips and pop up notifications are a good way to guide new users through the appropriate steps. Be sure to show them one at a time. Tell them directly what they need to know and when they need to know it. Don’t make them remember too much as they will forget it. Instead, use reminders.Overall, on boarding new users should be a fun and creative experience to help develop your product. There are hundreds of tools out there to help you optimize your product. Experiment with different tools and features to your advantage.



Sources and Further Reading



Factual & Rails || Grabbing UPC Product Data

We're heads down creating the next significant iteration of Nutribu, our nutrition tracking app. It's nearly ready, and we're dead excited.

Nutribu is being re-imagined to make tracking what you eat, still a very manual process which is unavoidable despite the numerous tech gimmicks you may have seen to help automate the process. So, we're focussing making it simple, fun and dead easy to find what you're eating and capture it in order that you can track your nutrition against your goals.

One area that users really wanted, and isn't really a new feature as it's often touted as one of the best features of apps like MyFitnessPal, is the ability to scan a UPC product barcode and instantly return the product complete with nutritional information. I can tell you now, the new Nutribu will have that too. Yay!!!

Actually, now I'll show you how to implement such a feature into your own app, starting with the server side component of fetching and storing product information from a service like Factual.

Before you do anything, head over to Factual and grab an API key and secret.

1. There's a Gem for that, of course.

gem 'factual-api'

2. Write tests.

Note: We use VCR to optimise the testing of HTTP interactions.

require 'spec_helper'

describe V1::ProductsController do
  include_context "signed up user"
  include_context "api token authentication"
  describe "show" do
    let(:product) { "Stone Crop Body Lotion", brand: "Eminence", upc: "608866337447") }
    def get_product
      VCR.use_cassette('factualapi') do
        get "/v1/products/#{product.upc}.json", nil, token_auth
    it "returns status 200" do
      expect(response.status).to eq(200)

    it "contains the product info" do
      body = JSON.parse(response.body)
      expect(body["name"]).to eq(
    context "product does not exists in in-house db" do
      it "create a new product in db" do

3. Generate Products Model

$rails g model Product name brand weight:integer upc

class CreateProducts < ActiveRecord::Migration
  def change
    create_table :products do |t|
      t.string :name
      t.string :brand
      t.integer :weight
      t.string :upc

4. Generate a Model for Product Image

$rails g model Image image:attachment product:references
class Image < ActiveRecord::Migration
  def change
    create_table :images do |t|
      t.references :product
      t.attachment :image

5. Update Routes.rb


resources :products


6. Product Model and Validations


class Product < ActiveRecord::Base
  validates_presence_of :name
  validates_presence_of :upc
  validates_uniqueness_of :upc
  has_many :images

7. Image Model & Validations

This one is somewhat more involved. We use Paperclip

#todo include explanation for this.


class Image < ActiveRecord::Base
  has_attached_file :image
  belongs_to :product
  validates_attachment_content_type :image, :content_type => /\Aimage/
  def file_from_url(url)
    self.image = download_remote_file(url)
  def download_remote_file(url)
    # OpenURI extends to handle URLs as files
    io = open(url)
    # overrides Paperclip::Upfile#original_filename;
    # we are creating a singleton method on specific object ('io')
    def io.original_filename
    io.original_filename.blank? ? nil : io

8. The Product Controller

# Update an existing user's profile.
# Requires a valid API token.
class V1::ProductsController < V1::BaseController

  before_action :authenticate

  def show
    result = FetchProduct.perform({upc: params[:id]})
    if result.success?
      render json: result.product
      render json: {error: {message: result.message}}, status: result.status


9. The FetchProduct Interactor

We use Interactors to add a layer of abstraction between our models and controllers - especially useful when performing complex interactions in a single request.

Basically, how we want this to work, is to initially check our own database to see if the product already exists, if not route the request to Factual to get the data, return and store it in our db, so the next request can just fetch it from our local store.

app / interactors / fetch_product.rb

class FetchProduct
  require 'factual'
  include Interactor
  attr_reader :status
  attr_reader :product
  def perform
    product = Product.find_by_upc(context[:upc])
    if product.present?
      @status = :found
      context[:product] = product
      # could not find this product in our db, find it on factual db
      factual =['FACTUAL_KEY'], ENV['FACTUAL_SECRET'])
      raw_data = factual.table("products-cpg").filters("upc" => upc).last
      # this should be put in a worker, then what will we return for the first time? not_found?
      if raw_data.present?
        # create product from raw data
        product = Product.create({name: raw_data["product_name"], brand: raw_data["brand"], upc: raw_data["upc"]})
        raw_data["image_urls"].each do |url|
          image = product.images.create()
        @product = product
        @status = :found
      else! message: "could not find product info"
        @status = :not_found

iOS8 - What's got me excited? Notifications.

Push and local notifications came on leaps and bounds in iOS7, to the extent that they're no longer really annoying* and in fact, have been verging on being quite useful when used intelligently within the overall experience of a mobile app.

Notifications displayed on my lock screen are, by some stretch, the most frequently visible real time notifications that I receive in the course of my day. So, when Apple officially declared iOS8 and it's myriad of updates yesterday, it was the evolution of the notifications, part of the iOS UIKit library, that caught my attention.

At both NuWe and Nourish Care, we've been looking closely at the opportunities for using notifications to improve the overall user experience, simplify the ways that users interact with our apps starting even before they've gone through the rigmarole of actually unlocking the screen, finding the icon, opening the app and logging in before they get to do what it was they wanted to do in the first place.

Some technologies offer considerable promise, such as the iBeacon protocol for adding real world context to user actions.

But notifications were really missing some additional, albeit simple, but important features to make them really useful without the need for things like iBeacon. And yesterday, goddamit, I think they got it.

Apple talked about 2 primary enhancements to provide Interactive Notifications:

  • Inline Comments - for example, responding to a text message inline within the notification.
  • Inline Actions - for example, offering user some inline buttons which, when tapped, will open the app and provide some context with which to customise the experience.

Let's have a look at them a little more closely:

Image from Yahoo Tech

Image from Yahoo Tech

I can't currently see within the apple documentation where this specific type of interaction resides, and if indeed it is available outside of the message app for use with 3rd party apps - I really hope it is. I can think of a number of great use cases for taking the input and parsing the string to create a very streamlined user experience for manual tracking activities. Even better, the option to use the voice control as well.

I presume it must reside somewhere within the UIKit library, if you spot it, let me know :)


Image from Techcrunch

Image from Techcrunch

Actionable Notifications, found in the UIUserNotificationAction class reference give us additional options to setup buttons that the user can tap straight from the notification.

We can set an action, optionally require user authentication, and we can use different UI patterns based on whether the action is likely to be destructive (such as deleting some data) as a result of the interaction. The default is non-destructive, set it in the property.

@property(nonatomic, assign, getter=isDestructive) BOOL destructive

You can also configure whether the action will load the app to the foreground, or simply process the action in the background, using these constants:

typedef enum UIUserNotificationActivationMode : NSUInteger {
} UIUserNotificationActivationMode;

Oh my frickin' God, this is awesome!

*some developers still abuse them and make them annoying, I can think of a few examples...

Lumpy - iOS App Concept (Part 1)

The Background:

My initial, unqualified view was that there is a problem related to people's perception of the risks of some kinds of cancers, in particular skin cancer, from my own anecdotal experience. It didn't take very long to find an article reinforcing this viewpoint.

All cancers can be fatal if not detected or treated properly, but a new poll has revealed that people worry less about skin cancer because they don’t think it’s as bad or as serious.

Some 53% are less concerned about getting skin cancer than other forms of the disease and 18% think it can be easily avoided, the survey of 5,000 people for theBritish Skin Foundation found.

Almost four in 10 (38%) do not realise that skin cancer can lead to death, while 56% do not know that malignant melanoma - the most deadly form of skin cancer - can spread to other parts of the body such as the liver and brain.

Dermatological surgeon Dr Bav Shergill said: “Skin cancer kills seven people in the UK every day and rates of malignant melanoma continue to rise faster than any other type of common cancer.

”In fact, there are more cases of skin cancer diagnosed each year than any other form of cancer in the UK. However, this research shows that people are often underestimating how serious the disease can be and the lasting impact it can leave on lives.”

My second view was that I suspected that there would be a significant proportion of the population that

a) Didn't check themselves regularly for lumps, check their moles and other less-well-known risk areas for signals of problems.

b) If they did find something not quite right, the chance of them seeking professional medical advice were slim and that the rates for the population would be low.

Only around a third (36%) of people polled admitted checking their skin or moles for changes that can indicate skin cancer, while 35% say they did not know what they were looking for.

Just a quarter (25%) would get a mole checked by their GP straight away if they noticed a change, while 8% would wait for it to get noticeably worse.

More than a third (34%) were unaware that skin cancer can appear on any part of the body - including under nails and the soles of feet - while 18% were unaware that people of all skin types and colours can get skin cancer.

ASIDE: The research was from the British Skin Foundation and was only published by the HuffPo.


Product Hypothesis

My initial thinking was that an app could work to break down some of these barriers in a number of ways.

How would it work?

A user will register in the app and login.

The user will be able to add their friends as contacts from the list of users.

The user can capture a photo or video of the problem area.

The image is stored locally on the users device.

The user can send the image or video to a selection of their friends list as they see fit.

A friend will receive a notification that they have received a message from the user.

The friend will view the message containing a photo or video.

The viewing of the photo/video is time limited.

The friend will be invited to provide a form of simple feedback to the user "Check it" or "Look's Fine" (or something to that extent).

The image or video is removed from the Friend's inbox

If sent to multiple people, after the final friend has viewed the image, the image is destroyed on the server, unless...

The user opts in to a program for Lumpy to keep images and meta information (votes from friends), but remove the relationship between the image and the person, for the purposes of research (another post on that to come..).

How will this help? 

1. As a way to seek external advice about an area of concern, with minimal friction / commitment and maximum privacy protection.

2. Using social / peer pressure for follow up actions.

3. To learn from the images, using machine learning techniques, as a predictor for risk areas from photographic samples.


Designing the App

Initially, I'm going to start with primarily standard iOS7 UI components and gradually customise them and add more complex UI functionalities. Here goes....


Raspberry Pi || Sending POST requests to a web service with python

Yesterday I spent a few hours getting acquainted with my Raspberry Pi.

The mission, was to simply setup the Pi, create a simple script to write some output, to a text file. Then, to create a cron job to process that script every few minutes. After that, I would get acquainted with Python modules, firstly by getting the current time and outputting that to the log.

Finally, constructing a POST request to a 3rd party web service to send that timestamp to.

What we did:

Using Python version 2.7.3rc2 on a Raspberry Pi, running Raspian distribution of Linux.

We first got a simple python script writing to a text file, getting the current time using the python Time module and appending it to the file contents. 

import time

f = open('/path/to/folder/test/log', 'a')
# current_time = time.asctime( time.localtime(time.time()) )
current_time = time.strftime('%I:%M%p %Z on %b %d, %Y')
f.write(current_time + '\n')


Then we created a cron script to run on boot of the Pi and then every 2 minutes, to run the python script. 

$ sudo crontab -e
# m h  dom mon dow   command
*/2 * * * * python /path/to/folder/test/
@reboot python /path/to/folder/test/

From there, we constructed a POST request to the nourish staging (old) Notes endpoint, firstly via the Python shell (IDLE) which comes with the Raspian distribution of Linux. 

Key here was the use of two further Python modules: urllib and urllib2 

import time
import urllib
import urllib2

url = ""

current_time = time.strftime('%I:%M%p %Z on %b %d, %Y')
date = current_time
post_data_dictionary = {'log[person_id]':12, 'log[user_id]':67, 'log[text]':current_time}
post_data_encoded = urllib.urlencode(post_data_dictionary)
request_object = urllib2.Request(url, post_data_encoded)
response = urllib2.urlopen(request_object)
html_string =

f = open('/path/to/file/test/log', 'a')
f.write(html_string + '\n')

Note that in Python 3, urllib2 has been merged into urllib, so no need to declare both in that case. 

I then updated the cron to process this file and refactored the script a bit. 

Authentication just passes the auth token as a param, so need to improve there. 

Next step is to get the actual data via an analogue to digital converter, and interface to the Pi, via SPI. We want to end up with a self contained RJ45 which interfaces directly to a pressure sensor for bed or chair interactions. 

We also need to change the location that this data is sent to, either the existing mongodb or some other suitable data storage, which can then be interrogated and queried at will by a caffeine fuelled CEO. 

Reigniting an Old Flame || Fuelr

When I was 18 (I think, it was such a frickin' long time ago), I used to sit in office buildings for 12 hours straight, working site security to pay for my university fees (well, beer money). I was fascinated by the idea of offering prescribed physical activity for people with chronic conditions, and for the prevention of disease in at-risk populations. 

I had completed a module in my sports studies degree, on this very subject. The NHS had not long released the framework for quality assurance, for the prescription of exercise and exercise referral schemes.

I used to write business plan after business plan, how I would construct a company to offer such services. I would talk to GPs and practise managers. I would do cashflow forecasts and P&Ls. I would research the equipment needs, and create startup cost budgets. 

Then I did nothing about it. Until now. 14 years later.

Not only am I now working on a next-generation Social Care platform, which is all about re-enablement and self-management of conditions, but I'm also working on a health and wellness platform for tracking and improving your overall wellbeing, by improving your knowledge and behaviour through the use of smart technologies and connected devices. I am now positioned to build something that does what I wanted, only a decade ago.

But, this is not the same plan - such has been the journey and has lead me back to this point. My education, in particular over the past 4 - 5 years, has armed me with what I was missing back then.

- Technical skills and the ability to execute.

- The mental processes that force me to ship a product

- Confirmation that my passion for this space is unyielding.

- Knowledge of a global market opportunity, enabled through technology, for distribution and scaleable business models.

The original idea was nice. But it wasn't scaleable. It was a lifestyle business idea, like a hairdressers, or an activity centre owner, or a restaurant owner.

I was in San Francisco 2 years ago, when I saw the idea, realised, working and gaining traction. A US startup called Wello had pulled together nascent real time video streaming protocols, such as webRTC, and modern web application development techniques, to offer a marketplace for exercise professionals.


Go to the site, and you can take part in pilates, yoga, circuits, cross-training, strength training... you name it. Delivered by real experts, in real time, at any time, wherever you or they are.

Now, this really appeals to me, both conceptually and technically.

So, this thread of posts is going to follow my exploration into building a very similar service offering, with I think, some key differentiators. We'll tackle the main technical concepts, including:

  • Building a web services / API using Ruby on Rails
  • Building a native iOS application, specifically for iPad
  • Using webRTC and the different options available to make this easier
  • Creating an admin area for the business
  • Creating the web application front end views




Smoothee Steady cam| Review

Smoothee Steady cam| Review

Nowadays there's definitely no shortage of gadgets and gizmos you can purchase for your Iphone. My new favourite is the Steadicam Smoothee from Tiffen. I recently upgraded to the Iphone 5s from an Iphone 4 and was totally amazed with the difference in quality and wanted to complement it's video capability. 

OK, I should be perfectly honest with you all right now, the Steadicam Smoothee is priced at around $149.00 and it wont give you quite the same results you might see on television or the movies, but if you take time and the effort to learn how to use it, you will improve your Iphone videos and it will give you some nice, steady video. If your using this outdoors, ideally you don't want any wind. 

The stabilizer works on a system of weights and balances with your camera. These balance adjustments are critical to making it work and do take some time to calibrate. The Steadicam Smoothee is relatively easy to adjust to especially since the camera is so light. It's so much easier than trying to adjust to a heavy video camera with multiple weights. 

Tiffen's website refers to it being based on the same technology as their rigs in which are used for movies and television which cost upto $60,000. In theory they are correct and with some practice you can achieve some really nice smooth results. But with alot of practice, you can get much better results. 

It's really a matter of how much extra effort you want to add to your Iphone productions, as this product is not going to fit into your pocket or purse it removes the spontaneity you have shooting video with your mobile phone. You need to plan ahead. 

So to get started is very simple, just take out the phone case and slide your Iphone into the mount, If you have a case on your phone you will have to take it off as it is a very snug, but easy fit. Now its a matter of calibrating the IPhone and Steadicam Smoothee with two separate knobs; Tilt forward and back, left and right, it should take around 5 minutes to get balanced. 

Maintaining the steadiness of the camera from moving side to side, does not take some practice. You can control with the hand grip which uses a gimbal mechanism to keep the camera in a more of a floating state to give your video a smooth 'gliding' feel as you move around and follow your chosen subject. 

You can use your thumb and finger with a light touch to keep the camera from moving left or right if there is a breeze. 



Actually one of the hardest problems with one of these devices, including the much more expensive ones, is when you shoot while walking backwards as your subject is walking towards you. This part is difficult if your anything like me, (incredibly clumsy), unless you have eyes in the back of your head. I most definitely keep walking into things situated behind me. 

You will need to practice and become proficient at this skill because if you are only following someone walking forward your only going to film their back. 

The Steadicam Smoothee or another gadget like an external microphone, is going to take planning and extra work to improve your video. It all depends which type of shooter you are with your IPhone video because it is possible to get some very nice, smooth and floaty video while moving with your phone. 

Ive tried chasing the dogs around the house, taking a tour of the house, walking along the promenade, floating up from behind a wall. Ive tried it out in a typical situation where I was moving while shooting. Of course, this resulted in me stumbling into something while walking backwards. 

Do remember that if your on an important video shoot and your using your phone to film, do turn it onto Airplane mode as you dont it going off and missing the important moment. 

Overall, the Steadicam Smoothee did improve the footage quality and give it a more professional look. It takes some to calibrate and to learn to fly the camera. The equipment is top quality and works, it feels great in the hands of the user, it's the operator that needs to take some to get the results he's after. 





For more information and to purchase a Steadicam Smoothee, Please visit:





Using Omniauth Facebook Profile Image with Carrierwave in Rails 4

Using Omniauth Facebook Profile Image with Carrierwave in Rails 4

I'm currently learning Ruby on Rails, as a 2014 resolution and I'm really pleased with my progress so far under the Bloc Curriculum. I will write more about the general learning experience, but this post is somewhat specific.

In my first full demo app, which I've lovingly branded - a reddit clone complete with users, topics, posts, user roles & capabilities, voting, favouriting, etc. etc. The User Authentication part is handled by a popular gem, Devise.

Whilst Devise is excellent at a lot of things, it is also quite problematic in a number of ways, most of which I have not yet experienced. I look forward to rolling my own Auth functionality in future projects.

I have added the Carrierwave gem with the MiniMagic gem to support a User avatar upload feature. This all works very nicely using the internal system.

But, then I added Facebook connect for user signups, via the Omniauth gem and wanted grab the Facebook User Profile Image from the Facebook hash.

I tried a few options, overly complicated as usual, including:

Original method without profile image for Facebook in user.rb


mount_uploader :avatar, AvatarUploader
def self.find_for_facebook_oauth(auth, signed_in_resource=nil)
user = User.where(:provider => auth.provider, :uid => auth.uid).first
unless user
pass = Devise.friendly_token[0,20]
user =,
 provider: auth.provider,
 uid: auth.uid,
 password: pass,
 password_confirmation: pass


Added Avatar to the arguments. Didn't work.


mount_uploader :avatar, AvatarUploader
def self.find_for_facebook_oauth(auth, signed_in_resource=nil)
user = User.where(:provider => auth.provider, :uid => auth.uid).first
unless user
pass = Devise.friendly_token[0,20]
user =,
 provider: auth.provider,
 uid: auth.uid,
 password: pass,
 password_confirmation: pass


Then changed from using the method magic (which may or may not always work) to retrieve the image from the Facebook Hash, to explicitly selecting from the Hash which is much more reliable, so I'm told...


mount_uploader :avatar, AvatarUploader
def self.find_for_facebook_oauth(auth, signed_in_resource=nil)
user = User.where(:provider => auth.provider, :uid => auth.uid).first
unless user
pass = Devise.friendly_token[0,20]
user =,
 provider: auth.provider,
 uid: auth.uid,
 avatar: auth[:info][:image],
 password: pass,
 password_confirmation: pass


Then, realising that this is just passing us an image url, which still isn't quite sufficient, we need to open the url first before uploading. So trying:


mount_uploader :avatar, AvatarUploader
def self.find_for_facebook_oauth(auth, signed_in_resource=nil)
user = User.where(:provider => auth.provider, :uid => auth.uid).first
unless user
pass = Devise.friendly_token[0,20]
user =,
 provider: auth.provider,
 uid: auth.uid,
 avatar: open(auth[:info][:image]),
 password: pass,
 password_confirmation: pass


But, that's a bit of a dirty hack, and nonetheless, also didn't work. So, when all else fails, the lesson here is Go Back to the Documentation.

With a little more searching, the solution was actually very straightforward. By providing the remote_avatar_url key, which has some baked in magic for unpacking the url ready for your app to display the image.


mount_uploader :avatar, AvatarUploader
def self.find_for_facebook_oauth(auth, signed_in_resource=nil)
user = User.where(:provider => auth.provider, :uid => auth.uid).first
unless user
pass = Devise.friendly_token[0,20]
user =,
 provider: auth.provider,
 uid: auth.uid,
 remote_avatar_url: auth[:info][:image],
 password: pass,
 password_confirmation: pass




Tools I Use: Hammer for Mac

Tools I Use: Hammer for Mac

Caution: Non-Mac Users, this is not for you - sadly. 

The guys at Riot have really helped me out over the past few months with their product Hammer for Mac

Hammer for Mac makes creating static websites, well actually, really good hearty fun. 

The Product

Download Hammer for Mac from the Apple Store and get started straight away, by creating a new project from scratch or by using one of Hammer's small collection of project templates.

Read the full Hammer documentation (they're pretty short and easy to digest), and I'll just give you my favourite bits of the product, which I've come to rely on. 


Screen Shot 2013-09-17 at 16.52.29.png

Includes - I now take great delight in segmenting my HTML into nice and tidy snippets via the HFM @include feature, without needing to run MAMP and use PHP as I used to.


SASS and Coffeescript auto compiler - The HFM build process automatically processes my .scss and .coffee files into .css and .js. If you're not familiar with either of these technologies, you should dig in. Coffeescript use is still a bit contentious, but SASS is a no-brainer. 


Screen Shot 2013-09-17 at 16.52.36.png

Javascript & Stylesheet includes - Clever paths that will rummage around in your file directory and automatically find and load your javascript and css files regardless of where you put them. A huge time saver. 

Screen Shot 2013-09-17 at 16.52.24.png

Clever Paths - Image files and other such assets are now always (super)relative, regardless of which folder you put them in or if you move them. HFM will find those pesky assets and load 'em into the page in a snip.

Screen Shot 2013-09-17 at 16.52.17.png

Placeholder Images - when you're desperate to eat lunch and you want to crack out a template, the placeholder shortcut will quickly jazz up your page content with correctly sized image placeholders. You'll be ordering a beer and burger 30 minutes before anyone else with this baby.

Screen Shot 2013-09-17 at 17.04.25.png

HFM is now on version 1.6 and the most recent updates to the software seem to have really focussed on performance - general processing speed and caching in particular. 

There's a few features within the software which I've really also come to love within the workflow.

The optimize toggle switch, which on request will compress and minify your code. 

 The Export archive link - just because it's easy and simple.

and most significantly for rapid publishing and sharing of work in progress, is the Publish Build function, which uploads your site to HFM's AWS servers with a short url to share with teammates, colleagues and clients. Hammr provides their own wrapper to the page for navigation and access to core site files, which is nice.


I met up with the guys from Riot around 18 months ago, when HFM was still in closed BETA. 

I was really impressed with Elliot and the team's focus on this product and how they've taken the "Mac-centric" approach to product development. I appreciate their style and business model and I really hope that HFM continues to grow and become adopted by front end web developers and designers around the world. 

Fidgetstick - Under New Management

As you may recall, I sun-setted my social network for adventurous people, Fidgetstick, after a few years of trying to figure out how to build a business out of a verticalised social network.

The lessons were plentiful, the mistakes were hilariously obvious, the product was crap, the intent was genuine, the execution sadly lacking.

Mobile technology was nascent, social platforms were not so widely adopted. Timing was wrong. I didn't have the technical, design or product skills I have now. I didn't truly connect with the market.

But I have some unfinished business, and to address that I realised that someone else would need to continue my mission - their mission, with some help and guidance. 

I'm pleased to say that someone will be my younger brother Ben


He's a young, passionate adventure sports enthusiast - kayaker, climber, activity instructor, long boarder. He's a little illiterate (excuse his text speak, I will knock it out of him). Mostly, he's passionate, honest and determined and for me that's good enough. Everything else can be learned.

Ben inherits an existing community of 12,000+ adventurous people that are on Facebook and will reignite the activity around curation and distribution of the best adventure-sports related content from around the web, topical discussion and leverage the power of community to return value to its members - through exclusive offers, discounts, prizes etc. that community members will delight in.

As Ben gathers insights from his own experience and from interactions with the community, we'll start to plan what the next version of Fidgetstick should become... 

A community hub?
A store?
A micro-site?
A tool?
An information repository?
A media sharing site?
A product?
An app?

Right now, we're not guessing. But we are hoping that by restarting the conversation, getting excited about the outdoors, being adventurous, pushing the boundaries, scaring ourselves, trying new things with new people, we'll figure out what challenges lie ahead. and how technical solutions can help.

If you have any thoughts, tweet @fidgetstick  or 'like' the facebook page and join the conversation.


Nutribu - a simple, social language for Nutrition

Nutrition and the broader health tech industry is HOT right now. 

MyFitnessPal raised £18m in VC money from Accel and others
Fitbit Raises $43 Million From Qualcomm Ventures, SAP Ventures, And SoftBank Capital
Jawbone Acquires BodyMedia For Over $100 Million To Give It An Edge In Wearable Health Tracking

And that is just great. Because you may recall, that I have a bit of an interest in this area. From my tinkering and slight addiction to my Nike Fuel band, tracking my activity on a daily basis and monitoring against my goals - to the extent that I built my own little Fuel Band dashboard which you can see here.

But really, my interest in the space goes much further. You may recall this post, from back in March, where we took the Nutribu API and our nifty little iOS app Feedo to the Launch Festival in San Francisco. 

Since March, the team have been hard at work figuring out how best to go to market. We've been around the garden, in the pond, over the fence, back into the house and back to the garden again. We've talked about, mocked up, spec'd out and subsequently parked a number of different applications.

We've talked enterprise apps. 

We've talked API-only models.

We've talked consumer apps. 

We've talked products for SME's.

But, through this process one thing has really proven out. A lean approach to product development, a constant and relentless testing of hypotheses, fast decisions and challenging of specification to achieve the MVP (minimum viable product). 

Our founder and CEO Sergio Mottola has really grown in his role as an entrepreneur, particularly within the technology / software domain. His relentless pursuit of an ideal, a proposition to the marketplace to simplify and socialise nutrition to the extent that normal people understand it, to the extent that they actually talk about it openly and even compete to be "better" in the context of what they eat. 

And that's a very key point, which took me a little while to understand. The key is not to be better at eating more or less. It's not about eating less calories or any other single measure or macro-nutrient. 

It's about 1) understanding your personal nutritional requirements and 2) about being the best at eating the most balanced diet you can according to those needs. 

You see, the Guideline Daily Amounts that you see all over products are frankly nonsense. They're based on a standard profile of person who is not you. This is drummed home to me, when you look at a box of cereal, which is what my little boy of 2 eats, and the GDA's are based on a 35 year old! 

So, we resolved to build an application that would help people to understand their personal nutritional needs and easily, quickly track their consumption and performance over time with simple, clear measurements.  

Testing the Nutribu app sharing via Instagram

Testing the Nutribu app sharing via Instagram

These measurements become objects of conversation and interest among peers, as we compete to build the most nutritionally balanced versions of our dishes and over the course of a day, week, month, year or lifetime, be more balanced and conscious of what we're eating. They are visual, social and engaging - not overly complex, scientific or boring as we see right now. 

So, as we prepare to launch the Nutribu app in the next couple of months, it's clear that we're in the right space, that interest is high, capital is available and at the end of the day, when we ask ourselves "should this exist in the world and does it make a positive difference" we can confidently answer "yes". And that's a pretty damn good place to be.


Learning Ruby on Rails Development - My Progress

Learning Ruby on Rails Development - My Progress

As I took the very easy decision (albeit painful, lonely and stressful at times) to create Braindu I also undertook to learn some new technical skills.

Braindu is a complex web application that uses a number of cutting edge web application development technologies, which I've discussed briefly before.

On the server side, the platform is built using the now popular and impressive Ruby on Rails platform. My development team are extremely experienced Rails developers, but for this project, I wanted to get stuck in myself and learn to code Rails apps from scratch.

I've talked before about how I'm sudo-addicted to online learning platforms, such as Code School, Codecademy, Treehouse &

But alas, with everything you have to take in, everything you come across from tutorials, courses, videos, documents, articles, e-books, plugins, gemfiles, extensions, frameworks, libraries... it opens you up to a whole world of information that you need to navigate, store, manage, curate and constantly refer to on a regular basis as you advance your practical knowledge and experience with a framework like Rails - it's a frickin' nightmare.

How I Learn Ruby on Rails with Braindu

How I Learn Ruby on Rails with Braindu

Fortunately for me I've got Braindu. The product that is encouraging me to learn Rails is also the app that is helping me to learn rails (and many other companion technologies, such as SASS, HAML, SVG, CoffeeScript) and now I cannot live without it.

Now I know I have a slight conflict of interest, but seriously, my learning process has been transformed.

And with Braindu, I can share with you my collection of resources - a live and organic repository of information relating to my mission to hold my own at developing web applications and software. Amazing considering that I couldn't even build a website but 4 years ago.

Sit back and Browse with the Read View.

Sit back and Browse with the Read View.

I've got a long way to go to be able to have at least a modicum of technical credibility among the experts that I work with every day, but the ability to get closer to the technical team's challenges through better technical skill development and knowledge is already paying dividends.

Right, back to a brief coffee break and a dabble with the Evernote API via the new Codecademy API pathways. How I've changed.

Glass: I'm Eating This - Google Glass has me excited

Glass: I'm Eating This - Google Glass has me excited

I just watched Google Glass developer advocate Timothy Jordan's 50 minute long presentation from SXSW, where he publicly presented the Google Glass Project, some interesting use-cases and a first look at the Mirror API.

The whole platform feels sleek, elegant and simple. The API is similarly so, where the interaction and information transactions are small, timely and impactful snippets that augment what you are doing right now and otherwise, get the hell out of the way.

Design for Glass - The Glass design is unique and fundamentally different than existing mobile platforms. It's important to build and test specifically for Glass to create a great service.
Don't get in the way - Services should be there when you want them and out of the way when you don't. They should never take precedence over what else the user may be doing.
Keep it timely - Glass is most effective when in-the-moment and up-to-date. User requests should be handled immediately and information should always be fresh.
Avoid the unexpected - Giving users unexpected and unpleasant functionality is bad on any platform, but particularly bad on Glass given how close it is to the user's senses.

I've been working on a fascinating project with Nutribu, a startup looking to transform how we interact with the complex and boring world of nutrition into a fun, social and competitive experience.

Google Glass could be the answer to how we may capture real-time transactions, like eating a meal, in an unobtrusive or overly clunky way - a problem which currently exists with web and mobile nutrition diaries and calorie counters.

Instead, Glass potentially offers all sorts of mechanics to make nutrition, eating consciously and with access to relevant information about our consumption a fun, data-driven and socially interactive experience.

It also gets me thinking about we access our personal information repositories, with services like my very own Braindu, so that our data is available to us in an actionable, real-time mechanic. I'm very excited to try out the API and build Mirror API-based services.

You can see my Braindu chart on the subject of Google Glass here with links, videos, images and notes that I expect will grow over time.