Introduction to Mobile Advertising

Many in the mobile industry see advertising as a dirty word, something to be avoided, a necessary evil – at best. This view is, perhaps, driven by the fact that the most successful games don’t have advertising – Minecraft, Clash of Clans, and lately Candy Crush Saga.  Of course it’s easy to promote life without ads when you’re making $2.4 million in revenues daily.

dr-evil

I’d argue this view is mistaken.  Advertising when done well can add a significant percentage onto a developer’s bottom line.  The most famous example of integrating ads seamlessly with your product is, of course, Google – who now earn massive profits from returning ads along with search results.  Why can’t the rest of us integrate ads in a way that enhances or at least doesn’t alienate users and players?

Many people still associate mobile advertising with cheap Banner Badgering.  However, the mobile ad industry is evolving at an extremely rapid pace, there are now all kinds of affiliate, interstitial, video, offer walls, to take into consideration.  Developers have reported that when done well ads are adding $500-$3000 onto their daily revenues – a figure not to be sneezed at.

To that end I put together a presentation for the team at Tsumanga Studios, where I work.  To introduce some of the terminology and options that are available to games and app developers, I hope you find it useful.

Best Practice

Of the current crop of top games, take a look at Gameloft’s Minion Rush – the way they have integrated ads is very clever, rewarding users with tiny amounts of currency in exchange for watching an ad.  Similarly Disney’s Monsters University have integrated an offer wall in a way that doesn’t spoil the game at all for those uninterested in ads (note this is a paid for app).

Placing interstitial ads at appropriate points, ie at the end of a level (like Fruit Ninja) or rewarding the player for watching ads should not destroy the user experience, and may help your app break even faster.  At the very least, you should use ad networks to cross promote your other content.

Conclusion

The mobile app and game space is still pioneer country.  No one knows anything.  There are plenty people doing well with and without ads, but you need to make up your own mind and run your own experiments.  There are a number of competing business models out there, clearly if you can get your game or app right vast profits can be made.  That, however, is not an easy task.  Until you get it right, perhaps, ads can help?

Entrepreneurial Spark – Life’s a pitch

This week I completed Entrepreneurial Spark’s  Acceler-8 TM Start-up Bootcamp.  Note the trademark.  The trademark implies a confidence, an unwavering certainty, that the program will be successful, globally recognised and copied.  A useful metaphor then, for Jim Duffy, and the E-Spark’s team’s, entrepreneurial mindset.

Entrepreneurial Spark’s proposition is a deceptively simple one.  Teach Scottish start-up business founders to:

  1. Think and act “entrepreneurially”.
  2. Teach them how to pitch their business

There’s much more on offer than that.  There’s support, advice, networking, access to individuals like Sir Tom Hunter, and Lord Willie Haughey, there’s free office space, everything you need to bootstrap a business.  But it always comes back to entrepreneurship, the pitch and the individual.  Get that right, they say, and success will naturally follow.

I’ve been involved with E-Spark for around 10 months now.  As a natural cynic and know-it-all I was happy to take Jim’s free office space, I grudgingly attended network events, inwardly cringing as people stumbled through their pitches, but slowly, something started to change – I got it.  Not overnight, not immediately, but I started to see the point.  I saw the change in people and their businesses.  I got what E-Spark were doing.

King of the Pitches

At E-Spark there is an unrelenting focus on pitching – the Elevator Pitch, the 3 minute pitch, the 10 minute pitch, pitch it and they will come, you get the idea.  But of all of them, the Elevator Pitch is King.

Initially I railed against the idea that you could boil a business, any business, certainly not our business into a 60 second sound-bite.  But the power of the pitch, it’s evil genius, is to force you to strip out all the fluff and identify and focus on the core central pillar of your business.

The exercise may make you realise that you don’t have a core, what you thought was important isn’t, it’ll make you understand what makes your business tick and what numbers are important, it will make you realise a dozen things.  But through constant refinement you get to that core central pillar.  Congratulations, you know your business – everything else will flow from there.

A fine line between confidence and hubris

If there’s a criticism to be levelled at E-Spark it’s that it may lure the unwary into the belief that a slick pitch, and a confident demeanor is enough to get by.  By forcing people out of their comfort zone and to be competitive, there’s a danger that from the outside looking in it appears like an extended episode of the Apprentice.

There’s been a number of occasions when I wished someone had thought before opening their gob, or acted with a bit more humility.  One particularly unedifying moment, during Bootcamp, had 3 people scrambling for a tenner.  Which led to a spate of people trying to outshine and be noticed more than others.

Confidence and knowing your business are key, but arrogance and showing off will make you look like a fool in front experienced business people.

Frequent reference to the Founder’s Dilemma – a Hobson’s Choice of Cash versus King was presented as the only possible reasons for starting a business.  I’d argue both are side-effects of success, and believing-in and selling-others-on your vision.

In the long-run, however, these are minor criticisms regarding what is a truly revolutionary concept and program.  In fairness you’re encouraged to question and disagree with what is being presented.  Additionally the program includes checks and balances in the form of the formidable enablers – who provide advice and guidance to keep you focussed and on track.

Winning

E-Spark has been inspired by, and modelled on Boston’s Babson College and the  Mass Challenge program where businesses pitch for a prize fund of $1million.  Incredibly, in less than 18 months the E-Spark team have managed to set-up a similar sized pot of cash and competition in Scotland know as the Edge fund.

This summer 16 out of 18 winners, of which we were one :-), had come through the E-Spark program.  E-Spark businesses have created more than 50 new jobs, since the program started.  Irrefutable evidence that the program works, and is making a real difference to the Start-Up scene and the economy of Scotland.

Anyone who is thinking of starting a business is Scotland would be crazy not to join the program.  The support, the energy, the network and the enthusiasm of all involved will get your business soaring.  There’s a mantra that is frequently seen and heard in the office that sums it all up.  If you’re starting a business in Scotland – GoDo at E-Spark.

Startups – The Importance of Momentum

I’ve been working in my present job in a mobile games studio for about 6 months.  It’s been pretty intense, but we just shipped our first game.  I produced it, I’ve got my name in the credits, and it got 500 downloads within 24 hours of being launched, so I’m very pleased, and I expect things to only get better 🙂  Not bad for a bunch of guys with limited experience in the gaming industry.

I wanted to blog some thoughts about lessons I’ve drawn as we’ve gone along, before the nervous breakdown hits.  First up – The Importance of Momentum.

Shark dive, UnderWater World

What it felt like on my first day

The technology industry attracts a lot of smart people, which can be pretty intimidating when you’re starting out.  How can we compete with EA, how can we compete with Microsoft, but you can – as long as you keep moving quickly and get your products into the marketplace.

Here’s the top 10 ways and rationale for acting like a shark, and keeping on swimming:

1.  Stick to the Plan – At least once a day one of the team will say “Stick to the Plan”.  You can only move fast if you have a good idea of where you’re heading.  Plans need enough detail so you can spot when things are starting to wobble.  When things are moving at 90 miles per hour, as they do in a startup, there are all sorts of variables that will be thrown at you.  If you have a plan you can easily say No – we’re sticking to the plan.

2.  React – The corollary to Stick to the Plan is – don’t always stick to the plan.  Over time you’ll inevitably be presented with evidence that your plan isn’t working.  Feature X is bogged down, Team Member Y is struggling with task Z etc etc.  React to this evidence and change your plan, make a new better plan and hit the accelerator again.

3.  There’s a fine line between order and chaos – The corollary to the corollary is being sensible enough to hit the brakes and drive within your limits (to push the metaphor).  Don’t change everything at once, prioritise problems and learn to live with uncertainty.

4.  You ain’t going to get it right first time – Most startups will probably have 3 years, or less, to demonstrate they can make money, so the earlier you can get some traction in the marketplace the better.  Spending 2 years in development, is a big risk, much better to ship 4-6 products or significant updates in that time (see the MVP).

5.  If in doubt, keep it simple – When faced with a choice, the safest bet is to go for the simplest solution.  If you’re wrong at least you’ll find out sooner, and in my experience simplest is best 9 times out of 10.  Large estimates and complex solutions have red flags all over them. (see YAGNI)

6.  Shipping teaches tough lessons – A feature we spent a number of weeks developing was rejected by Apple.  If we hadn’t shipped early we’d have wasted additional man-hours on a feature that we had to remove.

7.  Perfect is the enemy of good-enough – It’s comforting to gold-plate features, nail another bug, spend another few days in QA, optimise a bit more.  But if your product is good-enough, ship it, then react to real-world data, rather than second guess.  We went live with 20 known issues, but they were all issues we could live with.  If no-one downloads it, you’re much better to know after 3 months, rather than 6, as you could have spent the previous 3 months doing something different.

8.  Play to your strengths – It’s important to recognise where the strengths and weaknesses of your team lie.  Over time what you thought was a strength may prove to be a weakness, so change your plan.  Where you have gaps, either hire, or better, partner and use freelance resource until you can demonstrate you have the need/resource for a full time employee.

 9.  Don’t wish for what you don’t have – Don’t waste time on toying with the latest fads.  If you have a team of PHP programmers just write PHP as much as you might wish for a team of hipster Rubyists (see play to your strengths).

10.  My rushed site got 30,000 views – One of the first things we did was launch a website which we’d be the first to admit isn’t going to win any design awards.  However, we’re working on an updated design that addresses some of the original’s shortcomings.  In the time version 1’s been live we got 30,000 visitors and 3000 sign-ups, a 10% conversion rate that gave us some confidence we had a market.  If we’d waited until everything was addressed we wouldn’t have the confidence or the numbers (see perfect is the enemy of good enough).

10.1 Investors like momentum – If you can show your investors something tangible that they can see and play with, their confidence and happiness will increase (and you WANT happy/confident investors).  They can’t take a burndown chart to the bank.

So in summary, ship early, be agile in the truest sense, and keep moving.

HOWTO Install Python3, pip3 & Tornado on Mac

I recently needed to install Python3 on my Mac.  While the bearded Linux masses just seem to know this stuff, or it’s already part of their distro, in Mac-Land by default we’re stuck on Python 2.7.2 and guidance is lacking.

So to save people doing the digging I had to do, here’s a quick HOWTO on installing Python3 on your Mac.  I like understanding who things work, so this post also details where things are installed.

Install Latest Python 3

Download the lastest Python3 installer (v3.3.0 at time of writing) take care you get the version appropriate for your OSX version:

Download Python3 here

Follow the on-screen instructions, Python3 should be successfully installed into /Library/Frameworks/Python.framework/Versions/3.3 the installer will also create symlinks for python3 in /usr/local/bin – which makes python3 available from the command line.

Check it works

From the command line type:


python3

You should see the following:

Install pip3

Like all good languages Python has a package manager.  Python’s is called pip.  Pip can be used to install packages into the Python framework so they can be used in your programs.

Something that is not at all obvious to the uninitiated is that to use pip  with Python3, you need to compile run the various install scripts against Python3, otherwise everything just installs in the Python 2.7 directory (this is the voice of bitter experience speaking).

To work with pip3 we need to first install distribute_setup.py.  As far I understand it, distribute_setup.py parses the setup.py script in the python package and ensure everything is compatible with Python3 (correct me if I’m wrong Python community 🙂

Download and run the script as follows, you’ll need to use sudo on mac, as the script will need privs to write into /Library dir


curl -O http://python-distribute.org/distribute_setup.py
sudo python3 distribute_setup.py

Now you should be able to install pip, again you’ll need to run the script with python3 (not sure if sudo is definitely required this time)


curl -O https://raw.github.com/pypa/pip/master/contrib/get-pip.py
sudo python3 get-pip.py

pip should successfully installed.  Now you might be thinking you’re home and dry, however, if you type pip on the command line you’ll probably get Command not found, you’re going to have to alter your Path variable to make pip3 available.  So add the following line to your .bash_profile:

Restart you terminal and check if it’s working by doing, the following, and checking that (Python 3.3) is appended at the end.


pip --version

If you have an older version of pip installed you should still be able to use it by entering pip-2.7

Install Tornado webserver using pip3

So now we can give our new pip a testdrive by installing the Tornado web server.  Again on mac we appear to need to use sudo, otherwise strange errors occur:


sudo pip install tornado

You should see tornado being installed successfully into Python3’s site_packages dir /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages

So now we can use Python3 to run our Tornado hello world app, and see it running in the browser

So we can run our hello-world.py using Python3 and we should see it running successfully in the browser at http://localhost:8888

Good luck

5 lessons from 3 years at a start-up

Some thoughts in no particular order after 3 years at a start-up

Have a plan – sounds obvious but a weakness of agile is that it can give rise to the illusion that there’s a plan.  However, in reality planning is emergent as the iterations and stories float by.  Emergent planning means that the team can drift or can become distracted, or it’s hard to turn down non-core projects because you can’t point to a strategy or project delivery.  Plans can be flexible and tested in the MVP style, and changed when they are proved not to be working – but there’s no excuse not to have one.

Then ensure everyone is signed up to the plan.  Even in a small team it’s easy for factions and agendas to emerge.  Getting everyone pulling in the same direction is non-trivial

Sales and marketing are waaay more important than devs admit/realise
– Make time to support sales and marketing efforts.  Devs love to scoff at sales people with their suits, lines in BS and vague promises.  But the hard fact is there are very few successful products that have gained market share on technical superiority alone, and the chances are your team is not producing one of them.  You need to think long and hard about your sales and marketing approach.

Only today did I read in the Sunday Times that the publishers of Grand Theft Auto hired Max Clifford to create a media shit-storm regarding the moral failings of the game.  Resulting, of course, in millions of additional sales.

Avoid non-core projects at all costs – Pressure for sales may mean you’re tempted to take on side projects, or do free work in exchange for some kind of marketing exposure. DON’T!!  DON’T EVEN THINK ABOUT IT!!

My experience was that this was a huge distraction and money-pit and time waster and just a generally bad idea that should be pushed back against at all costs.  If you’re tempted and think you can manage it – trust me it will still be a distraction.  If you’re still tempted time-box the work hard and ensure all stakeholders understand that there’s a maximum amount of time you can afford.

Don’t white-label and abstract features until at least 2 customers ask for them – This is basically a rewording of YAGNI – it’s tempting to assume all customers will want feature X or Y.  However, until you have hard evidence that multiple customers want the same feature, try to avoid wasting time abstracting them.  This sounds simple but is very difficult to police and make hard/fast decisions about without getting devs backs up – kanban boards etc can help here to demonstrate to the team how these tasks can add time and cost to the project.

Invest in your team – This doesn’t just mean salaries, this mean listening to your employees.  If you notice the team doing a lot of overtime, do something about it.  Encourage R&D, make sure they have some “slack” time, pay for them to attend conferences, encourage them to blog, take them out for dinner.  Encourage experimentation with new technologies.  Let them do flexi-time, homeworking.

Things like this make a job enjoyable, and mean your team aren’t scouring the job ads.

So in conclusion, as usual, we can say the golden rule is that there are no golden rules, no doubt success can be achieved by ignoring all of the above, but these stuck out to me over the last few years.

See also:

The SDK business is dead – It’s a commodity market now.

SQL Azure – Disaster Recovery

In this post I look at how to set up some tooling to help implement a Disaster Recovery plan for your SQL Azure database.

Fundamentals

The key to any successful DR plan is that it has to be a fire and forget process.  If your DR process involves any manual components – ie Bob from infrastructure needs to push a button at 3pm on Wednesdays, you can guarantee that when disaster strikes you’ll discover Bob hasn’t pushed the button since February.

Thus you want to make sure everything is automated, and you want to hear about it if anything goes wrong.

It’s worth pointing out that every SQL Azure instance is mirrored twice, therefore it is highly unlikely you’re going to suffer an actual outage or data loss from unexpected downtime.  So what we’re doing here is creating a backup in-case someone inadvertently deletes the Customers table.  Of course it never hurts to have a backup under your pillow (so to speak) if it’s going to help you get to sleep at night.

Tooling

Tools you will need:

Exporting your SQL Azure DB

The first thing we’re going to do is to export your SQL Azure DB to a blob file.  The blob file can be used to import your backup into a new DB in the event of disaster.

  • If you haven’t already got one, create a new Azure Storage account.  It’s a good idea to create this in a different location from your SQL Azure DB, so in the event of a catastropic data-centre melt-down your backup will be located far away.  Eg if your database is in North-Europe setup your Storage Account in East-Asia.
  • Now fire-up Azure Storage Explorer and connect to your new storage account.  Create a new private container for sticking the backups in.  If you don’t create a container you can’t actually save anything into your storage account

  • Now we can configure Azure Import Export Client to download your DB into your newly created storage account.  This is a command line util which is ideal for automating but for now we’ll just run manually.  Run the following, editing for your specific account details:

  • Important – Make sure you the BLOBURL argument correctly specifies your container name, ie -BLOBURL http://iainsbackups.blob.core.windows.net/dbbackups/MyDb_120820.bacpac
  • If all has gone well you want to see something like below.  Note – this command simply kicks off the backup process it may take some time before your backup file is complete, you can actually monitor the backup jobs on the portal if you want.

Importing your SQL Azure DB

A DR plan is of little use if you don’t test your backup, so we want to ensure that our backup file can actually be used to create a rescue DB from.  So lets import our .bacpac file to see if we can recreate our DB and connect our app to it.

  • We basically reverse the process.  This time create a new empty SQL Azure DB
  • Now we can configure Azure Import Export Service to import our .bacpac file as follows:

  • If it works as expected we should see

  • Now you want to connect your app to your DB to ensure it works as expected.

Automating your backups

Now we’ve proven we can export and import our db we want to make sure the process happens automatically so we can forget about it.  The easiest way of doing that is to create a simple powershell script that runs the above commands for us, and then schedule it on the task manager.

Here’s a basic script that will run the Import/Export service for us, you can tailor as you see fit.  Note that I’m creating a timestamped backup file so we should get a new file every day

Now we have the script we can call it from the task scheduler, I created a Basic Task to run every night at 23:30, to call our script we can just run powershell from the schedular, as so:

Important – You will have to set your powershell executionpolicy to Remotesigned or the script won’t run when called.

Next Steps

So that’s it we’re backing up our Azure DB and storing in Blob storage all for the cost of a few pennies.  Next we might want to create a more sophisticated script/program that would email us in event of failure, or tidy up old backups – I’ll leave it up to you 🙂

Useful Links

http://msdn.microsoft.com/en-us/library/windowsazure/383f0cb9-0647-4e67-985d-e88369ef0508

Easy database migrations with C# and FluentMigrator

Database migrations are an increasingly common pattern for managing and automating the creation of your projects database schemas. Typically each migration has 3 elements:

  • A Unique Id – each new migration is given a numeric identifier higher than the previous one.
  • An UP component – describing the table / row / column / key – you want to create
  • A DOWN component – which exactly reverses the change you’re are making in the UP component.

Thus by running each of the migrations in order you can go from an empty database, to the schema required by your project, or if an error occurs you can simply roll back any number of migrations to get to a known stable state.

But why?

The advantages of this approach may not be immediately obvious, but I’d say the main advantages are:

  • No seperate SQL scripts, db exports etc.  All database migrations are contained within the project and can be reviewed and managed by the team – No DBA Required.
  • Easy deployment onto as many servers as required – most medium to large projects will have a number of environments, minimally dev, test and live.  By creating DB migrations it’s simple to keep each of these environments in synch.
  • As the project grows, database migrations can be created as required, meaning you can easily rollout new changes to live projects.
  • Easy rollback – if you rollout a patch containing a migration, you can instantly roll it back without discovering you don’t have rollback scripts.
  • Roll outs to the live db are usually possible with no downtime

Introducing FluentMigrator

FluentMigrator is a package that allows you to create “fluent” migrations within Visual Studio.  The easiest thing to do is just to demo a migration:

You can see that the migration is decorated with a number in this case 3.  You can see the UP migration creates the UserRoles table and a number of Foreign Keys.  You should also see that the DOWN migration reverses this change, deleting the keys then deleting the table itself.

Thus if a problem occurs during the creation of this table, FluentMigrator can rollback the migration, as described in your DOWN migration.

Running the migrations

Migrations on their own are of little value if you can’t run them against a target database.  FluentMigrator integrates with both MSBuild and Nant, meaning you can run migrations as part of your build process. What’s nice about this is that you can only run in DB changes if all your unit tests etc pass, and if you have a more sophisticated build script you can control which db migrations are rolled out onto different environments.

Readers of my blog will be familiar with my love of Nant and my Nuget package Nant.Builder.  So it won’t come as a great surprise to find out I’ve added a FluentMigrator target into my Nant.Builder scripts.

You can set up the appropriate values in Nant.xml, you can see a working sample in the Nant.Builder.Sample this uses sqlite (note it will only run on 64bit windows).

Best Practice

As far as best practice goes, as I demonstrate in the sample project I’d advise:

  • Keep all the migration classes in a separate project
  • Number the migration classes in line with their migration number ie Mig012_CreateTableX – makes it easier to manage them once you have a few migrations.

Here’s a snap of our migrations on one of our large projects, as you can see after iteration 18 it occurs to us to start creating folders per iteration, allowing to keep things a bit more ordered:

Conclusions

Fluentmigrator takes a lot of the pain out of managing your database schema over multiple environments.  If there’s a negative it’s that the project is a little bit flakey on environments other than Sqlserver, I’ve tried it on SqlserverCe and Sqlite and it’s not worked or only worked after poking at the code for a while.

On the positive side the project is being actively maintained and updated, I had a minor update accepted and committed within a few days of posting it.  So download it and get involved.