Category Archives: Software

On Writing Successful Fart Apps


Last Thursday, Apple held an event where they announced a few things, including a refresh of the Macbook Pro line that killed all of the good ports and added a touch bar to replace the function key row. I was actually in a meeting during the announcement but I had heard of the touch bar through a story about a leak. Someone on Twitter put a bounty of $5 on the first fart app for the touch bar and a friend retweeted it to me.

If you know me, you know that I like writing stupid apps and basically making a mockery of the Silicon Valley trope of “making the world a better place.” Specifically, the fart app genre appeals to me as a way to subvert the app ecosystem and make it a little more dumb and weird. The tech industry in particular takes itself way too seriously. In a way, I’m emulating my Computer Science hero Monzy, who created projects like “Pantscam” and  a program that morphed people’s faces into butts (which I can’t find the archive of at the moment), all while being a successful nerdcore rapper. While the things he made were somewhat stupid, you can’t deny that the technology was actually pretty cool.

Writing fart apps is also a great way to learn about a particular platform. If “hello world” is the simplest app that you can write in a language, a fart app is the simplest non-trivial app you can write, since it touches the UI, the file system and whatever mechanism there is for playing an audio file. In the past I wrote some fart apps for Google Glass and the Apple Watch, which were small enough projects that I didn’t get bored and abandon them, plus I learned something in the process.

So anyway, on Thursday I got home from work and installed Xcode 8.1 on my computer. I ended up needing to get another update for macOS Sierra to get the simulated Touch Bar to show up as well. I looked at some sample code, figured out what I needed to do to write the app and finished in maybe an hour or two. It was a good exercise to get reacquainted with macOS development after I stalled on a project I started a few years ago. I pushed the repo to Github, made a demo video and took a screenshot and sent some tweets to the Twitter user who requested the app. I also sent it to some other Twitter users who made similar requests, not expecting anyone to write a fart app less than 12 hours after the hardware for it was announced.

On Friday, I posted the Github repo to an iOS developer community on Slack. That’s pretty much all the “promotion” I did. At some point that day, someone posted the project on Product Hunt (good call!) and it kinda just sat there. I went out of town during the weekend but I noticed someone had written a story about the project on Cult of Mac. I figured that would be the apex of my touch bar fart app’s story. At some point during the weekend though, I got a tweet that the Product Hunt entry hit 100 upvotes. Then a few more stories were written today and my project was even mentioned in NatashaTheRobot’s Swift newsletter. I’m guessing that today will be the real apex of this fart app and it’ll slowly be forgotten like my other fart apps before it.

So what have I learned from this and previous fart apps? One is that some people take themselves way too seriously to enjoy a good fart app. For example, this person:

First, I’m not a kid. My job title has senior in it which must mean something! Also, I have a day job and writing fart apps (a.k.a. learning stuff) is my hobby. Finally, thanks to this hard-hitting piece of journalism, we see that even fart app writers can eventually move on to greater ambitions.

There’s also this killjoy from Product Hunt:

While I can understand the sentiment that there could be better tech things happening, I also don’t think it’s realistic to see a new Snapchat or Twitter released every single day. Friday was a slow day, so a fart app won! And is it just the subject matter that makes the project immature and pathetic? Like, would a British PM Soundboard be any more appropriate?

Bottom line is that this project only took a couple hours out of my free time, which I would’ve probably spent playing a JSRPG anyway. I suppose you could argue that the nonexistence of my app would’ve caused fewer people to waste time discussing it, but I can’t really control how other people spend their time.

One cool thing that’s come out of this project is that someone has already forked it and made a soundboard project out of it. This is sort of the whole point of writing an open source fart app: establish a codebase that people can check out, learn from, and maybe even extend into their own thing. I knew from the start that my app wasn’t going to make it into an App Store. I do believe that the Github repo was the first (public at least) to reference the NSTouchBar class.

Finally, if you are reading this blog post thinking: “hey, I’d like to be known for making a fart app instead of one of many other useful contributions I’ve made to this planet!” then here are some tips! First off, you need to actually be the first to market on the fart app scene as interest will surely wane as the second, third, fourth, etc fart apps written for the technology are released. Unless you add something really cool, like actual fart smells in addition to sounds, then you probably wanna rush your fart app to market. Second, you’ll need to market your app with some kind of video. When building for cutting edge hardware like the touch bar (which no one has yet) or Google Glass (which literally no one bought),  you can assume that no one will have the hardware or be interested in installing your app, so just make a video! In my experience it helps if you mumble a lot. Finally, share your code by making it available on Github and attach a generous license to it. I used the MIT license but put the wrong year because I copy-pasted it from another app. But I guess my mistake was relatable because more than one person commented on that commit! Your app won’t be worth anything anyway, so you might as well share it.

I hope this post has helped explain my motivations for making a touch bar fart app. Partly it’s to prove that I could, and partly make a cool $0.03 on the video ads.

P.S. Apple, if you are reading this, please do not ban me from WWDC over this. I promise to write some software using one of your new frameworks for non-fart applications!

Thoughts on Spotify

I was lucky enough to get an early invite to Spotify last week thanks to my high Klout score (I honestly think anyone with a pulse got an invite) and I’ve been playing around with it for a few days. Here’s my thoughts on the service thus far.

One thing I’ve noticed is that I’m using Spotify for listening to stuff that I don’t already have in my library. This is sort of weird because I recently switched to an SSD and none of my music is actually in my library. Yet I use Spotify for listening to stuff that’s not on my external hard drive (which I almost never have plugged in). I think this behavior might be due to the fact that Spotify is making me a fat kid in a candy store (but for music). I want to keep searching to test Spotify’s limits and see how much music it really has. So far it’s been doing really well.

Specifically, I have been using Spotify mostly to listen to music that was popular when I was in middle school (this was like, 14 years ago). This music is stuff that I’m either too embarrassed to have on my hard drive, or I simply never had. Yet it’s totally great for nostalgia’s sake. I’ve been listening to No Doubt, Toni Braxton, Weezer, Mariah Carey, etc. Stuff that brings me back to that era. It’s pretty cool.

One workflow that Spotify has replaced for me is the awkward one of going to YouTube and looking for a video of a song I want to hear. I don’t know how many times I’ve had to go to YouTube and searched for something like “Head Over Heels” by Tears For Fears just to listen to a song (it’s just a static image of the album cover). It’s much, much quicker just to search in Spotify and get super instant gratification.

Comparisons to the new hot startup, Turntable, are pretty much impossible to avoid. Turntable is really fun for interacting with people (and music discovery), but sometimes you just want to listen to what you want to listen to (and not wait for other DJs before your song comes on). I think the two services have very different use cases, and each works well for its intended use.

One thing Spotify could work on is music discovery. It’s kind of ridiculous the only music it pushes are the top albums, artists and songs. All the stuff on this list are top 20 bullshit that I really have no interest in listening to (just ignore the top 20 “bullshit” from the 90’s that I just admitted to listening to). In this day and age, it’s ridiculous for a music service to not include some kind of recommendation engine or radio feature. Browsing music on the service by genre, year or anything besides search is impossible. In terms of features, Spotify is actually kind of disappointing.

Despite the obvious shortcomings, I have a lot of high hopes for Spotify. It’s a really nice example of how consumers can enjoy getting stuff from “the cloud” without making it too complicated. I hope that it continues to improve, especially in the music discovery and browsing categories.

♥s Threadless for iPad Release!

About a week ago I thought about working some more on ♥s Threadless, my fan made iPhone app. I originally designed it for the small iOS devices like the iPhone and iPod touch, and figured I would do the proper iPad version later. I got the itch, so I got to work figuring out what an app on the bigger screen would look like.

I knew that I wanted a grid-y layout as opposed to the list-y one of the iPhone/iPod, which was partly the reason why I hadn’t done the iPad version yet. Lists on iOS are easy because they’re given to you for free. Grids are a whole other beast. Luckily, I ran into a framework (AQGridView) on GitHub that does grid layouts in a tableview-y sort of paradigm. The framework was still a little beta (or alpha) as I had to go in and change a few things that were crashing, but it did succeed in making my job a lot easier overall. I’d like to try contributing to that code to improve it, but I guess that’s another post altogether.

After getting the grid stuff working, I decided to use a modal pop up view to display the images and sharing options all in one view. Since the iPad has much more screen real estate, it’s easy to design things without running into space issues. You don’t, however, want to just stick a billion buttons in because you can. I think this design does a good job of showing enough stuff to the user, but not too much stuff too soon.

I still have some bugs to fix, mainly with memory management due to the grid view stuff. If you have any suggestions, feel free to comment on this blog!

Hopefully the iPad app continues the mission of the iPhone app, which is to provide a really easy and fun way to browse and share awesome Threadless designs! I may have been an early iPad doubter, but I really believe that it’s a great device for consuming content. Even on my iPad 1, the designs and colors just pop on the app. At least I think so. But you don’t have to take my word for it!

Get the app if you don’t have it already!

Automatic Checkins in Google Latitude

It looks like Google has updated their Latitude app with checkins, including automatic notifications and checkins (and checkouts).

When I developed Checkmate, there wasn’t really a standard design for the auto-checkin behavior. Some users have mentioned that the app might work better by sending notification to check in, more like reminders. I’ve leaned towards fully automated checkins, myself.

Google seems to be taking a hybrid approach, which is pretty interesting. You get a notification the first time you arrive somewhere (probably only for places you’ve checked into before), and then an option to automatically check in after that.

I might end up building some kind of hybrid (or a simple option in settings) system in Checkmate to see if that works better in general. I wonder how Google is mitigating the cost of GPS usage in its Latitude app. I always figured that the thing keeping auto-checkin out of official apps is the fact that they run the battery down pretty hard.

Instascriber: Automagically Add Content to Instapaper

I just “announced” a little web app that I’ve been developing off and on called “Instascriber.” It’s basically a tool to help you populate your Instapaper reading list with stuff using an RSS Feed subscription model. If you use Instapaper a lot and use it to keep track of your reading list, you might want to automatically add new items, say from the New York Times Book section, into your Instapaper reading list. If you already know you’d like to read the content on Instapaper, it’s a pain to manually add each thing you want to read.

With Instascriber, you can just set the feed you’d like to subscribe to. Instascriber will periodically check the feed for new items and add it to your Instapaper reading list automatically in the background. That’s it. Boom!

For now, I’m considering the web app to be in beta. So let me know if you find bugs or anything.