Month: November 2014

For whatever reason, Amazon deemed me worthy of receiving an Echo last week. After laying down my $99 and a quick, overnight shipment, it was on my doorstep Friday afternoon. And now, after giving it a whirl for thirty-six hours, I thought I’d write up my initial observations.

First of all, it’s bigger than I expected. When I first got it, I initially didn’t like the form factor, thinking I’d instead prefer something shorter and wider more like a speaker. But now that I’ve positioned it in a few different places in my kitchen, the skinnier, taller design makes sense. In a space constrained layout, Echo takes up very little surface area on my kitchen counter.

Setup was extremely simple. Just plug the Echo into power and then “download” the Amazon Echo app. I put “download” in quotes because that’s the phrasing Amazon uses in the setup material. But the app isn’t actually a native app from the App Store. It’s a mobile web app they encourage you to add to your home screen.

The mobile app walks you through connecting your Echo to wifi and your Amazon account in just a few minutes. After watching a three minute intro video, the device was ready for my first command. But more on that in a minute.

First I want to say that their mobile web app, while not bad, is one of those mobile apps that makes native app developers groan. Rather than being a responsive design that would work on any screen size, it’s specifically built for mobile. That includes a hamburger menu for accessing a side drawer of settings. It tries so hard to look like a native app, I just wish they had taken the time to build one if that’s what they’re aiming for. But, I do get why they went web app. It’s the fastest way to get one codebase on every platform. Maybe once Echo is more than a beta project, they’ll build a proper native controller.

While I would obviously prefer a native app, suffering through their web app isn’t a huge deal. The only real issue is since it runs in Mobile Safari, you’re required to be logged into your Amazon account. Not a big deal for me, but it is for my wife who is normally signed into her Amazon account, and therefore can’t access the Echo app. The solution? She simply just doesn’t use the app. A shame.

My first command was, predictably, “Alexa, what’s the weather tomorrow?” Echo thought for a second, it’s ring of lights glowing, and then promptly answered with a full forecast for the next day.

My wife and I have probably issued fifty or so commands over the last day and a half, and the response times after each question are completely on par with what I expect from Siri or Google Now.

The “always on” nature feels like a game changer – the natural progression of all these competing information services. Already, after just a day of use, it felt natural and seamless in a way that Siri never has. Without really thinking, I automatically said “Alexa, set a timer for 3 minutes” when making my morning coffee.

My wife laughed at the original Echo introduction video earlier this month. She was completely skeptical after such a bad experience with Siri the last few years. But, again, the seamlessness of it won her over. She’s issued more commands than I have.

How about voice recognition? Echo is able to hear and understand me speaking at a completely normal volume from an adjacent room and around a corner. A slightly louder, projecting voice was sufficient 40 feet away through an open doorway. The device is able to hear the wake-word “Alexa” very easily, even while the device itself is playing music. It pauses the music once it hears its name and waits for the rest of your command.

One difference between Echo and Siri is Apple’s assistant is much more conversational. There are times when Echo will answer a purposely non-answerable question with a fun reply, but not as often or with near as much breadth as Siri. Part of that, of course, is that Apple has had a few years and vastly more user interaction to tune Siri’s personality. It also might simply be due to Amazon purposefully not making Echo as human as Siri pretends to be.

When playing music at low volumes, Echo isn’t nearly as crisp and audible as my kitchen Sonos speaker. It sounds fine, but not great, at louder volumes. But with a sleeping baby in our house, low volumes are a must, and Echo just sounds muddled when listening to what I know are good audio recordings.

As luck would have it, earlier this year I uploaded all of my iTunes library into Amazon Music so it would be streamable on my Sonos. (Sonos famously doesn’t play nice with the Apple ecosystem.) Having 80 gigs of mp3s living in the cloud and available on Echo with a simple voice command is awesome.

I’m an Amazon Prime member, so, in theory, I have access to their “million song” library, but I haven’t tapped into that yet since my personal collection is so readily available. I have no idea how Amazon’s streaming library compares with Rdio or Spotify.

All of this music integration really just makes me yearn for a voice-controlled Sonos. With their speakers already situated throughout my house, it seems so natural for them to pivot into a full-on tech company capable of responding to my voice. Or at least partner with Google (Now) or Microsoft (Cortana) to make their tech available to an army of passionate Sonos users.

They other pipe dream Echo opens up is the possibility of an open API and/or official way to shuttle my reminder and shopping list data out of Amazon’s ecosystem and into whatever apps I happen to use for that type of data. It would also be amazing if one day Amazon enables developers via AWS to tap into their speech recognition and processing platform. Imagine if Amazon allowed you to stream voice audio to AWS, and they’d do the speech recognition and then further break down the input into verbs, actions, and nouns that could trigger webhooks within your infrastructure.

Anyway, I’m getting ahead of myself.

For $199 is Echo worth the price? Maybe. If you already have a Sonos in the room, possibly not. But for the Prime member price of $99, it was a no-brainer impulse buy that I’m very much enjoying.

I hate using the word “quit”. Because it’s not quitting. It’s not even “giving up”.

Today, the prolific Manton Reece wrote a blog post announcing that he is sunsetting his Twitter apps. This, after a recent announcement that Twitter’s (amazing!) new fully searchable tweet archives won’t be made available to third-party developers.

Twitter’s fully-searchable index is an announcement I’ve been waiting on for years. Back when I worked at Yahoo!, I co-created Sideline, a cross-platform desktop client for searching Twitter. A year later, after Sideline was sunsetted, I rebuilt it as a native Mac desktop app called Incoming!. Both Sideline and Incoming! were fantastic ways for discovering what’s currently happening on Twitter and for following the latest trends – whether that be an Egyptian uprising or whatever the hell latest trouble Justin Bieber is into.

But those apps were always crippled by the lack of history in Twitter’s search API.

If Twitter hadn’t already turned into such a giant dick towards third-party devs, their full-search announcement would have filled me with technical amazement and hope at the amazing apps that could be built on top of such a corpus. Sadly, I knew it was too good to be true, and sure enough, a link from Marco sealed the deal.

It’s only a matter of time until all third-party apps are either pushed out of business or users leave for features we simply can’t compete with.

As I said at the top of this post, Manton isn’t quitting. He’s one of the most thoughtful developers I’ve ever had the pleasure of speaking with. He, like many of us, is simply recognizing when a window of opportunity has closed shut. I applaud him for the care with which he’s shutting down Tweet Library and Watermark.

Not to jump on his bandwagon, but I’ve also decided to remove Incoming! from the Mac App Store. It’s ability to dive into breaking news and social trends by aggregating tweets never caught on the way I had hoped. I kept it alive for the last few years hoping that, eventually, we’d get access to Twitter’s entire history. But now that we know that isn’t going to happen, I see no reason in keeping it alive.

Incoming! will of course continue working for users who already have a copy. I plan on making a free version available later this year on my archives page for anyone who still has a use for it.

Back in July, for reasons outlined in these two posts, I wrote about the financials of my indie Mac software business. With the year coming to a close, and with the prodding of a few friends, I thought I’d share where the money from my total yearly sales actually goes.

First, the big numbers.

If you read my original post on the topic, you’ll know that in 2013 my software grossed $58,093 in total sales. Since that’s the last complete year of sales data I have, we’ll start with that number. Where does the money go?

Immediately off the top is the commission I pay FastSpring for handling all of my e-commerce. FastSpring charges 8.9% per transaction. That’s quite high compared to a payment processor like Stripe (who I used to use exclusively), but FastSpring offers benefits beyond simply credit card processing that make them worth the extra cost.

So, $58,093 minus 8.9% leaves $53,600.

What are the costs of running my business? I do my best to run a lean ship, but here’s what I’m paying out each month…

• Grasshopper for a virtual 800 number – $288/year
• Hockey for beta testing and crash symbolication – $120/year
• Adobe Photoshop – $120/year
• Rackspace – One legacy server that I need to move to Linode – $216/year
• Linode – My primary web server plus two proxy servers that run Lift Off – $600/year
• DigitalOcean – One server where I host my GitLab installation – $240/year
• Pingdom – Server monitoring – $108/year
• Amazon Web Services – Static files stored in S3 – $48/year
• MaxCDN – CDN for my web server – $70/year
• Mailchimp – Mailing lists – $100/year (I pay-as-I-go rather than a monthly plan since I’m an infrequent sender.)
• Domain names – $250/year
• SSL certificates – $100/year
• Apple Mac and iOS developer programs – $200/year

That’s everything that’s in my spreadsheet and off the top of my head. Like any business, there are other incidentals throughout the year, but that’s most of them. Grand total?

$2,460

That brings our total down to $51,140.

Finally, taxes. I put aside 30% of every paycheck. Which leaves us with with $35,798 or 62% of what we started with.

My main goal for the new year is to finally grow up and get an actual accountant rather than handling everything myself with TurboTax. I know there are tax and payroll strategies I’m not taking advantage of that could save me real money.

A few months ago I wrote about how I’ve spent my software career constantly building new ideas and putting them out into the world to see what sticks. It’s scary as hell to release a new product into the world – never knowing how it will be received. But that’s the modus operandi for how I’ve built up the moderate amount of indie success I’ve had.

A short while after that blog post, I wrote about how I use constraints – particularly time constraints – to keep myself motivated and moving forward. Boxing yourself into a fixed amount of time can often have a magical effect on your productivity.

So, two weeks ago, I took both of those ideas and applied them towards building a new product called Shutterbox. It’s an app I’ve wanted for myself for a long time. I keep all of my photos stored in Dropbox, and despite searching the App Store, I’ve never found a good way to browse my Dropbox photos on my iOS devices.

I knew in the back of my mind that I wanted to build an app to do this myself, but between work and my other commitments, I wasn’t ready to jump all-in on building an app. So, to test the waters and see if the idea was even viable, I decided to give myself twelve hours over the course of four nights to build a prototype.

There’s so much open source software available for iOS these days, it’s truly incredible how quickly you can build a functional app just by piecing together components from around the web. Thanks to a few key open source libraries, I was easily able to get a working prototype completed within my twelve hours.

I installed the app on my wife’s phone, and she immediately took to browsing our large collection of family photos.

After that, I made the decision to go all-in and spend another twelve hours adding a few remaining features and polishing the app into a shippable state.

I’m thrilled to say that Shutterbox has been approved by Apple and is now available in the App Store for free.

If you keep your photo library stored in Dropbox, I encourage you to give Shutterbox a try. I think you’ll love it.

After reading my last post about my OmniFocus setup, Evan Lovely asked

Could you talk more about your Routines? What’s in there? Does anything repeat? Do you set defer or due dates on them?

He’s referring to a Single-Action List I have inside my “Personal” folder called “Routines”. Inside this project are actions and checklists that repeat on a regular basis. Here’s a list of the current actions in the project…

• Weekly Review – Every Monday morning I’m prompted to do a standard GTD review of all my ongoing projects in OmniFocus.
• Reconcile credit card – We have a credit card that we use entirely in place of our debit cards that gives us a flat percentage back on everything we buy. We use it to pay for everything we can and at the end of the year we usually have around $700 in cash rewards we can claim as a holiday bonus. Every Monday morning I completely pay off the previous week’s charges so we never carry a balance.
• Tag keeper photos – As explained in my photography book, once a week I look through all of the photos my wife and I have taken and use Finder tags to call out any “keeper” photos we may want to put into a book later.
• Sort photos into albums – Nearly the same as the previous item, but in this case I’m extracting out any photos that belong in their own dedicated album.
• Take belly photo – While my wife was pregnant, this reminded us to take one of those cheesy profile belly shots each week.
• Weigh-in – I’m overweight and trying to do something about it. I weigh myself to track my progress at the same time every week.
• Sort scanned documents – I run a paperless home office. This reminds me to sort through any recently scanned documents and file them into the appropriate folders in Dropbox.
• Check that Backblaze backups are working – I manage the backups for all of mine and my extended family’s Macs. I sign into Backblaze once a week to make sure everybody’s backups are still in order.
• Sign into backup email account – Once a month I sign into the secret Gmail account I use as a recovery account for all of my significant online services. I due this to make sure Gmail knows the account is active and won’t accidentally suspend it.

There are more items in my “Routines” project, but that’s a good sample of what’s in there.

I use it as a dumping ground for all the periodic checkins I have to do to keep my other trusted systems running smoothly. OmniFocus is the central hub that reminds me to keep all of the other systems in my life on track.

Actions that have a hard due date such as my weigh-in and taking my wife’s photo, have a defer and due date on the same day that repeats weekly.

Items that need to be done on a regular basis, but don’t have a strict due date (like sorting my photos) have a repeating defer date. Using a defer date is key as that tells OmniFocus to not bug me about it again until a set time after I’ve actually completed the task.

So, thoughts? How are you dealing with repeating tasks and items that need to happen regularly?

In my previous post about how I use OmniFocus, I made reference to an on-hold project template called “New App Release”. Anytime I release an update to one of my Mac apps, I follow this checklist. In case it’s useful to other developers, here’s what it contains…

1. Verify build with Deploymate – this scans my Xcode project and compares all of my API calls against my build target warning me about any deprecated, missing, or private API calls.
2. Increment version number in Info.plist.
3. Tag the release in git.
4. Publish the git tag.
5. Archive the project in Xcode and export a [Developer ID].(https://developer.apple.com/developer-id/) signed build to the Desktop.
6. Verify Gatekeeper and code signing is correct by running spctl -a -v App.app.
7. Zip the exported app binary.
8. Write release notes and upload the new build’s zip file to your hosting provider of choice.
9. Do whatever you need to do to make a new release happen in Sparkle.
10. Do a test update in the old version of the app.
11. Do a test download of the new version from your website.
12. Upload the dSYM file generated by Xcode’s Archive step to Hockey or whatever crash symbolication service you use.

Thanks to Tony Arnold for prompting me to post this checklist.

The best Evernote realization I ever had was to create an Evernote notebook called “@Inbox” and make it your Default Notebook. (The @ in front of the name ensures it will be sorted to the top of your notebook list.)

From then on, you can quickly save notes and web pages into your Inbox notebook and move on with your work without interrupting your flow.

Then, when and only when you have time, you can review everything in your @Inbox and sort each note into a more appropriate notebook. That doesn’t mean you can’t have a catch-all “My Notebook”, it just means new notes don’t end up in there, un-processed by default.