Lollipop Sticks

 

This is how I know I’ve been in the software business for far too long.

A box of lollipop sticks arrived this morning. 100 count. We bought them for my son’s birthday. They cost $3.06.

I’ve been thinking about these lollipop sticks the whole day. Actually, I’ve been thinking about the business of lollipop sticks, the company that makes them, and the people who own the company that makes them.

There’s no point to it, really. It’s just that after running a software company for almost a decade, the daily mechanics of other types of businesses fascinate me. The more unlike a software company a business is, the more it intrigues me.

What goes on through the mind of a lollipop stick maker?

How many lollipop sticks does she have to sell to stop worrying for the month?

Is she concerned with innovation? How do you make a better lollipop stick? Would making them better affect their price?

Why $3.06? How much does it cost her to make 100 lollipop sticks? What if the answer is $3.00, and her entire profit margin is comprised of the remaining 6 pennies?

It’s intriguing. But it wouldn’t be funny. Not for a person who spends the better part of a year making a piece of software before offering it for sale at under a dollar, taking home $0.70 cents per sale after costs. I would imagine it doesn’t take the lollipop stick maker the better part of the year to make 100 lollipop sticks.

Would she laugh at me and the way I run my business?

Does she put any thought into marketing? What kind of ideas are tossed around to get more people to buy more lollipop sticks?

Is she from a long line of lollipop stick makers, or did she just stumble into the business?

Is she passionate about making lollipop sticks? Does she need to be? Is this kind of sentiment about products an absurd notion in her business?

… and when she pulls out her mobile phone, and uses my software, does she wonder about who is behind those bits?

Did localizing our mobile app improve our sale numbers?

On January 23rd, we released a localized (translated) version of one of our apps. And what an impact it had on the sale numbers! Here’s the chart.

What? You don’t see the difference?

Me neither.

At least we wasted a few days of what otherwise may have been productive work.

We’re so not cool, all we do is get shit done.

Another article describing the reasoning behind a choice of tech for a new project.

Another article where PHP isn’t even mentioned.

Personally, I’m thrilled that Ruby is now mature enough that the community no longer needs to bother with the pretense of being the coolest kid on the block. That means the rest of us who just like to Get Shit Done can roll up our sleeves and focus on the mission of building stuff with our peers rather than frantically running around trying to suss out the next shiny thing.

Well. I guess if Ruby has reached the point where it’s so not cool that it’s only for people who get shit done, us PHP developers must be the most productive programmers in the world!

Ethan eating his first piece of cantaloupe.

A new podcast about bootstrapping a software company.

In 2011, Gavin Bowman and I started What Now?, a podcast about surviving as a mobile-app developer. That podcast saw us through ups and downs (mostly downs), but more importantly, it has always presented the gritty reality of what it’s like to try to make a living making and selling iOS, Android, and BlackBerry apps.

Today, I’d like to announce a new podcast – Bootstrapped. I co-host this new show with Ian Landsman, founder of Userscape, creator of the popular helpdesk product, Helpspot, and the upcoming Snappy.

Bootstrapped will focus on the business side of bootstrapping a software company – everything from cash flow, to hiring employees, to opening an office space. On the technical side, as Antair moves closer to launching Uberdeck, and Userscape moves closer to launching Snappy, the show will focus on building and running a web app.

Going back to the desktop with RSS

With the upcoming demise of Google Reader, people have been busy evaluating various alternatives.

All of them, as I see it, online.

Well, I’m going back to … basics? Back to the desktop anyway. Back to the days when NetNewsWire was the shit (it wasn’t that long ago, really).

My choice is Vienna. It’s simple. It’s functional. It’s prettier than Google Reader (not saying much). And it’s all I need.

“But what if you want to read your news when you’re away from your machine?”

Well. For one, my machines, for the past decade, have all been laptops, and two, I really can’t recall ever desperately needing to check my RSS feeds while “standing in line at the bank”, or “driving my car”.

Programming Language Popularity Chart

Came across this today. It’s a programming language popularity chart, compiled by taking the number of Stack Overflow tags for the given language, and the number of lines changed on GitHub.

A few interesting things here.

First, hats-off to C, huh? For a language that was created in the late 60s/early 70s, to still be in the top 10, is a testament to brilliance of simplicity in design. But, of course, ya’ll already knew that, and everyone already thinks C is awesome.

Scarier yet, FORTRAN is still up there. That’s even older (1957!)

It just goes to show you that regardless of people jumping on whatever the latest hotness is, technology never dies out as quickly as one might expect.

C++ is up there. No surprise.

Ruby is up there as well. We all know why.

Objective C is up there only due to Apple. I doubt it would make it out of the bottom quarter if it wasn’t for iOS (sorry, OS X Cocoa developers, but you know it’s true).

Java’s up there. I’m tempted to say it’s because of Android, but really, Java is just an unholy Juggernaut Uber-Beast, and we haven’t found a big enough bullet yet.

Javascript’s up there because we have no choice … for now.

… and, PHP is up there to show you that no-matter how much shit you throw at something, pragmatism will always beat out ideology.

A quick way to view your Android app’s SQLite database during development.

Often, when writing Android apps that store data in an SQLite database, I need to view the contents of that database to see if data was stored properly, etc.

With my current project, the schema needs to be fairly complex, and, at one point, I had to check up on what the database contained every few seconds.

To make things easier, I chained together a few things with duct tape, chewing gum, and adb. I do my Android dev on a Mac, but you shouldn’t have much trouble adapting this little automation to other platforms.

Download Navicat Lite. I’m not sure if Navicat still offers this download directly, but you can still find copies of it floating around the web. If you have a copy of Navicat Premium, that should work as well.

When installed, Navicat should associate itself as the default app to handle .sqlite files.

Create a new shell script file, say, opendb.sh, with the following contents:

#!/bin/bash
adb pull /data/data/com.company.app/databases/appdbname ~/Desktop/mydbname.sqlite
open ~/Desktop/mydbname.sqlite

Replace com.company.app, with the package name of your Android app.

Replace appdbname with the name of your SQLite database.

It would make things easier if your adb binary is in your PATH. If it isn’t, use the full path to adb in the script.

Your Android simulator should already be running, or your device already connected, for the adb pull to work.

Run chmod +x opendb.sh to make the script executable.

With that done, now, every time you need to take a quick look at the contents of the SQLite database for your app, just run this script. The database file will be pulled from the device/simulator, and automatically opened with Navicat.

If you make mobile apps for a living, check out Uberdeck. It’s a service we started to allow mobile app developers to make more money from their apps, and to prevent negative reviews.