A Tasty Pixel » Posts

The Business Side of Technomading: Our Automated Business Model has Died a Death and that’s OK

I kicked off our new blog series on the business side of technomading with a tongue-in-cheek self-deprecating little ditty on the evolution of our business. To summarise, for all you late-comers (you know who you are) we started out with the grand and slightly naive plan of creating an automated iPhone app business (the apps sell themselves, you see) which has graduated into what we have now – the very sobering realisation that without concerted and continuous marketing, updates, and customer support any app, no matter how shit-hot, will be lost in the noisy black gaping void of a hole that is the iPhone App Store. Accordingly, we are working our little butts off. I wrapped up the post with the (hopefully) tantalising teaser that in this post, we’ll explain why we really don’t mind all that much.

###Meaningful Work

We’ve been reading Malcolm Gladwell’s book “Outliers”. In it, he recounts the story of a typical Jewish immigrant couple, the Borgenichts, in New York in the 1880s who bootstrapped their own garment manufacturing business:

“When Borgenicht came home at night to his children, he may have been tired and poor and overwhelmed, but he was alive. He was his own boss. He was responsible for his own decisions and direction. His work was complex: it engaged his mind and imagination. And in his work, there was a relationship between effort and reward: the longer he and Regina stayed up at night sewing aprons, the more money they made the next day on the streets.

Those three things – autonomy, complexity, and connection between effort and reward – are, most people agree, the three qualities that work has to have if it is to be satisfying. It is not how much money we make that ultimately makes us happy between nine and five. It’s whether our work fulfils us… Work that fulfils those three criteria is meaningful… Hard work is a prison sentence only if it does not have meaning”.

The work we are doing on A Tasty Pixel has those three qualities, but I would also add a fourth dimension — we are pouring our everything into a product we believe in and can be proud of. Our app, The Cartographer, was built because we needed it as travellers and we’ve found it immensely useful on our travels. More than that, it has been crafted into an artisan iPhone app with an exquisite design. It is feasible, as an entrepreneur, that you could be doing work that has Gladwell’s three characteristics of meaningful work whilst working on a product which holds no inherent meaning for you. I can’t imagine that would be particularly captivating for long.

###On Automated Income

Our dream of an automated income began after reading Tim Ferriss’ book “The 4-Hour Work Week”. One of the assumptions the book is founded upon is that:

“…for most people, somewhere between six and seven billion of them, the perfect job is the one that takes the least time. The vast majority of people will never find a job that can be an unending source of fulfilment, so that is not the goal here; to free time and automate income is”.

This clearly doesn’t apply to us. Sometimes when we’re travelling, Mike pines for programming. He’ll quite happily tap away on his lappy until 3 in the morning and then lie in bed for another hour, brain buzzing away at the problem at hand.

Obviously, marketing and operations management is not my dream job but as least I’ve still got Gladwell’s three tenets of meaningful work going for me, and that’s a lot. Of course, I’m still in mourning for my creative endeavours and grieved a little bit last night after the realisation that I’m going to have to work full-time on A Tasty Pixel for the next month until launch, maybe longer. As the darkly comic universe would have it I’m feeling super inspired lately, I have several paintings in the works and I’m really excited about them all as well as some newly learnt techniques I want to give a whirl but they’ll have to wait. Presumably my marketing and operational duties will become more manageable once we’ve built up some momentum. If not, our voyage of discovery will continue, possibly into the realm of outsourcing or streamlining my duties. In the meantime, I’m learning invaluable entrepreneurial skills.

So that, my friends, is a little insight into why the transmogrification of our automated business model into a what-the-hell-kind-of-a-frenzied-time-guzzling-monster-with-no-end-in-sight-business-have-we-created is really not so very bad.

I’d like to introduce Katherine, my partner, and A Tasty Pixel’s operations and marketing manager (or some similar title that means she does all the work that isn’t hammering out code). She’s started a blog series on the goings-on at ATP, and I thought it was time we posted it here.

It occurred to me the other day that we should be blogging about our software development business, A Tasty Pixel — our hopes for it, our progress, our setbacks. Is it madness that this only occurred to me 15 months into our technomading lifestyle?!

At the moment our business is absolutely all-consuming. Five months ago we decided to stop travelling for a bit to get some work done and we’ve still got another 2 solid months ahead of us before launch.

In this time we’ve watched our project evolve, branch off into unexpected territory, and have adjusted our goals accordingly. It seems obvious, now that I’ve thought of it, that we should be documenting this thing that’s taking up so much of our time and energy and plays such a vitally important role in our lives. It’s an amazing (for us) thing that we’re doing and I want to record it for providence. I also want to take time to reflect on what we’re doing. That’s something I’ve really appreciated about travel blogging – the perspective it provides. I think blogging about our business will make me appreciate our accomplishments, assess our decisions and progress and hopefully, if we’re very, very lucky, reach out and connect with like-minded entrepreneurial souls who we can share this experience with.

But first, to get our gentle viewers up to speed, some back-story:

Iterations of A Tasty Pixel

Before leaving Australia we read Tim Ferriss’ book the “4 Hour Work Week” and were rather captivated by the idea of “automation” or as we’ve come to call it, “passive income” – basically you sell a product and automate as much as you can so you don’t have to spend more than a day a week on it. This lead to the grand idea that Mike would make iPhone apps – which of course you only need to make once – then sell it forever and ever for wads of cash on the iPhone App Store…

And thusly we progressed:

Goal: Mike does what he loves and we have a comfortable passive income once x amount of apps are out on the App Store. (Technically, the first iteration of A Tasty Pixel was Mike making apps in his “spare time” ahem whilst completing his PhD before we left Australia.)
Business Model: Mike makes stuff he wishes existed and puts it on the App Store and waits for the money to roll in.
Goal: Unchanged

Business Model: As above, plus after some prodding from Katherine, Mike dabbles in marketing.
Goal: Unchanged

Business Model: Mike makes stuff he wishes existed and Katherine is promoted to “Operations and Marketing Manager” once we both realise that if Mike runs every aspect of the business himself he may be able to release an app within the next decade or so.
Goal: Mike does what he loves. Delusions of a passive income are, at the very least postponed, after Katherine’s realisation that without concerted and continuous marketing, updates, and customer support any app, no matter how shit hot, will be lost in the noisy black gaping void of a hole that is the iPhone App Store.

Business Model: Work our little butts off.

I don’t know if you can tell from the above business models, but neither Mike nor I have any education or experience in business. We’re both what I believe many people (comprised mostly of my extended working-class family) would call “over-educated” (3 degrees, 1 honours, and 99.9% of a PhD between us).

Alas, despite all those many years of book learnin’ not a snippet was dedicated to the exchange of goods and/or services for monies. Luckily, I have a degree in psychology so apparently I know how to manipulate people into parting with their money — at least that’s what my psych lecturers told us when they mentioned that a whole lot of psych graduates use their powers for evil and go into marketing. I remember shuddering at the thought, and now here I am — not that I’m complaining! I’m one of those strange people who takes an exorbitant amount of pleasure in organising. As a kid I had borderline OCD tendencies and they serve me well today.

So, where we’re at right now is the realisation that in order for our business to be successful we either need to do a crapload of work or pay somebody else to do it (we both take far too much pride in our work to have any love for the idea of outsourcing, however), with no end-date in sight. When and how we are we going to find the time to travel Europe in our motorhome again? We have no idea but I’m hoping once this iPhone app that we have poured our everything into is out in the big wide world things will balance out and we’ll be able to focus on A Tasty Pixel, travel, and I’ll be able to get back to my passion – art and design and creating my own little creative business.

I think the next blog post will be about why, despite the death of our “automated” business model, we really don’t mind very much.

Keeping content active with popular posts widget and regular rotation

Vlad Bailescu’s WordPress Stats Helper plugin is useful for showing a list of top blog posts in one’s sidebar, but it can have the tendency to artificially elevate posts in a feedback cycle of awesomeness.

What you want is to rotate the posts around to give other popular posts some exposure. I’ve made some minor adjustments to Vlad’s plugin to add the option for random rotation.

Grab the modified version here: wordpresscom-stats-helper-random.zip

You’ll want to unzip this in your wp-plugins folder, disable the old plugin, then activate this one. See the new settings in the widgets section of your WordPress admin — I recommend a random pool size that’s twice the number of posts to display, but you can tweak the settings to your liking.

Avoid the clobber: Nest your network activity indicator updates

On the iPhone, when you are doing anything that uses the network, you’re supposed to let the user know something’s going on, via -[UIApplication setNetworkActivityIndicatorVisible:]. This takes a boolean.

That’s all well and good, but if you have more than one object in your app that may do things with the network simultaneously, you’re going to clobber yourself.

A nice and easy solution: Maintain an activity counter and create a category on UIApplication to maintain it, and show or hide the indicator as appropriate. Then, whenever you start doing something with the network:

[[UIApplication sharedApplication] showNetworkActivityIndicator];

…And when you’re done:

[[UIApplication sharedApplication] hideNetworkActivityIndicator];

Here’s a category that’ll do it:

Getting Data out of the iPhone while Debugging

Here’s a utility I whipped up quickly to save out a file from a hex string, as from [NSData description] — kinda a reverse hexdump.

While doing some debugging, I realised I needed to visualise an intermediate UIImage from the iPhone’s camera. Not being able to use the simulator, and thus be able to write to a file easily, this was my solution: po UIImageJPEGRepresentation(photo, 0.8) to print out the data as a hex string, then copied it to the clipboard, saved it as a text file, and used an NSScanner to scan in each int, fix the endianness and write it out as a file.

Insane? Maybe, but it did the trick.

Easy Delayed Messaging using NSProxy and NSInvocation

Sometimes it’s necessary to perform an action some time in the future, whether it’s disabling a button for a certain time interval after it’s pressed, performing an animation after a short wait, or triggering a reload of some data.

NSTimer is great for that purpose, as well as repeatedly performing actions, but it’s most convenient utility method, scheduledTimerWithTimeInterval:target:selector:userInfo:repeats: only takes one ‘id‘ argument. Using the NSInvocation equivalent, scheduledTimerWithTimeInterval:invocation:repeats: requires creating and setting up the NSInvocation itself, which is always verbose and a pain.

NSProxy is a wonderful little construct that lets us interact with it like we were talking to the original object. I first learned how it works from a post by Shaun Wexler which shows an easier way to send a message on the main thread, by using the NSInvocation given via the NSProxy’s forwardInvocation: method. The same technique can be used to easily create a configured NSTimer.

So, instead of some awful thing like this:

NSInvocation *i = [NSInvocation invocationWithMethodSignature:[mapView methodSignatureForSelector:@selector(selectAnnotation:animated:)]];
[i setTarget:mapView];
MKAnnotation *annotation = view.annotation;
[i setArgument:&amp;annotation atIndex:3];
BOOL flag=YES;
[i setArgument:&amp;flag atIndex:4];
[NSTimer scheduledTimerWithTimeInterval:0.5 invocation:i repeats:NO];

We can do this:

[(MKMapView*)[TPTimerProxy scheduledTimerProxyWithTarget:mapView timeInterval:0.5 repeats:NO] selectAnnotation:view.annotation animated:YES];

Here’s the juice:

Playing audio in time using Remote IO

I got an email today with a question about how to handle playback of audio in time, synchronised with a clock. My ‘musical notepad’ app Loopy does this, and I thought I’d briefly explain how.

Any app that makes use of the Remote IO audio unit framework (which is generally necessary for the kind of responsiveness required in a realtime musical app) provides audio to the hardware via a callback, which is periodically called when the hardware is ready for more.

The trick here is to provide the right chunk of samples in this callback for the current time position.

Loopy achieves this by:

1. Keeping track of where in the timeline we are at the time the callback is called

This is easily accomplished by keeping a record of the time the clock was started, subtracting this from the current time, and possibly performing a modulus with the tempo. For example:

(now - startTime) % timePerBar gives the number of time units into the current bar (lets call it timeIntoBar).
timeIntoBar / (timePerBar/beatsPerBar) gives the number of beats into the current bar, and
timeIntoBar % (timePerBar/beatsPerBar) gives us the time into the current beat.

2. Determining first if we should be playing audio at this time, and if so, which samples should be playing

This involves first converting our time units from step 1 into samples. For instance, you can convert microseconds to samples by dividing your time by 1000000/yourSampleRate. Aside: Of course, you can convert back from samples to time by multiplying instead of dividing.

Next, in the case of Loopy’s metronome, for example, we test for whether samplesIntoBeat < sound.lengthInSamples. If so, that means we should be playing audio. If the sound was a loop, of course, we could be always playing.

The offset into the sound, in samples, is just samplesIntoBeat, in the case of the simple metronome. In the case of a loop, you probably will be more interested in the number of samples into your loop — so instead of determining (now - startTime) % timePerBar, you may be interested in (now - startTime) % timePerLoop.

So, we want to return the requested number of samples starting from this offset into the sample array representing our audio.

3. Returning smooth audio in time

Note that if you just go returning any old set of samples, willy-nilly, you're going to get nasty clicks and pops from discontinuities you get by not matching the start of your next buffer to the last one.

To ensure smoothness, Loopy keeps track of the offset of the last samples we returned, and just return the immediately following bunch of samples — unless we're more than some threshold number of samples out of time, in which case we'll suffer the pop in order to stay synchronised. Actually, you can even generally avoid the pop if you smoothly blend buffers over a short time, removing any discontinuity.

Final words

The example above was a relatively trivial one, for a metronome sound. For longer audio that may span multiple bars, you'll probably want to perform a modulus by the length of your audio clip, possibly quantised to your time signature, and possibly using a per-loop time base, so you can start the loop at any point in your timeline and have it begin from the start. This is something Loopy doesn't currently do — Loopy will keep your loops synchronised so when you start a loop playing, it'll play whatever part corresponds to the current timeline, not from the start of the loop. Maybe it'll be an option in the future?

I wrote a little about the timing of loops in my second article on Loopy's implementation.

iPhone debugging tip: Breaking on exceptions and reading their content

Just a quick one: This may be obvious to many devs, but it’s worth noting. One common and useful debugging technique is breaking on exceptions, so that you can see exactly where in your app’s flow a breakpoint occurs.

This can be done by adding -[NSException raise] and objc_exception_throw to your breakpoints list.

Once an exception happens, you can then check out the exception itself to see what went wrong. The approach varies between platforms. If you’re in the simulator (or any Mac OS X app running on Intel), the exception will be stored in the $eax register. Take a look by typing:

po $eax

If you’re on the iPhone, it’ll be $r0, so:

po $r0