Building Software That Scales

53646549

It’s been a long time since I’ve posted here.  I’ve been really busy in general, but I’m excited to publish this post (I actually forced myself to publish this post).

Over the past few weeks, since I returned from vacation, I’ve been working on building a backend that scales.  I’m building an Android podcast app, PrēmoFM.  My podcast app needs a backend parsing infrastructure that scales to parse hundreds of thousands of podcast XML files constantly.  As I type this, I’m about to unleash hundreds of thousands of podcast channels onto my beta users.  Up to this point, they’ve only had access to 75, which mostly consisted of my favorite podcasts.  That number will be increasing to north of 200,000.  I’m ecstatic about this because these are the first pieces of software that I built that operates at this scale.

In order to provide a good user experience to PrēmoFM users, I need to be able to parse at least 5,000 podcasts per minute.  On the surface, this would allow me to run through the entire catalog one time in 40 minutes.  I’ve made several architectural decisions that allow me to achieve this.  I’ve built highly multi-threaded Java apps that serve a single purpose:

  • HTTP XML data retrievers
  • XML Parsers
  • Push message senders

Each portion of the chain has it owns challenges and constraints, so I needed to build apps that were focused in their function.  This also allows me to spin up instances of each app to keep my XML parsing pipeline saturated and operating at peak performance, which is exactly what I did.  Secondarily, I’m able to iterate and update each component separately.  I can only imagine the frustration if I had one Java app that did the retrieval, XML parsing, and push message sending.  I’m still doing to a bit of testing before I move everything up to my production VPSes (virtual private servers), but I’ve already blew past my baseline goal of 5,000 podcasts per minute and am peaking around 12,000+ (Update 5/25/2015 @ 1AM – deployed to DigitalOcean – peaking at 27,000 channels per min, bonkers, to me anyway), which is at least two orders of magnitude increase from where I was a week ago.  In fact, things are moving so fast, I’m going to have to significantly cut down on the logging or it’ll begin eating up all of the available hard drive space.

I’ll provide more detail on my backend architecture in the future, when I have time to document.  For right now, I’m marching towards release.

Are you an Android user?  Sign up for the beta at Prēmo.FM

Podcasts for Android Developers

I listen to a bunch of podcasts, but there are a core few that make me better at what I love doing, writing Android apps.  Here are some of podcasts I listen to that are tailored to Android developers.  I more or less take at least one thing away that makes me a better Android developer or makes my current project, PrēmoFM, better.

Queue the Xzibit meme…

xlq56e

Android Developer Backstage

adb

Link -> androidbackstage.blogspot.com

Android Developer Backstage (ADB? <— well played) is a podcast hosted by engineers who work on Android at Google.  Chet Haase leads the podcast.  They’ll often have guests on from other teams within Google, such as the tools team, Google Play Services, Android Wear, and many more.  There’s nothing like getting tips on Android development from those building the operating system and tools.

Fragmented

fragmented-logo

Link -> fragmentedpodcast.com

Fragmented is a recently launched podcast, hosted by Donn Felker & Kaushik Gopal.  These two often provide tips, tricks, and tools tons of Android developers would benefit from exploring, such as tools for unit testing, emulator alternatives, new libraries, etc.  The latest episode (Episode 3) includes a guest developer from Trello, Dan Lew, who offers some knowledge using RxJava on Android.

Autocomplete

AutoCompleteCoverArt

Link -> autocomplete.fm

Autocomplete has a similar feel to Fragmented.  The hosts, Jay Ohms, Jordan Beck, and Michael Novak, are all Android developers who have written apps.  I know them from their work on the beautifully designed RSS app, Press.  They tend to dive into relevant Android / Android development topics of the time.  They haven’t released an episode in a few months, but their backlog is still very relevant.

A Parable on Iteration

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Amazing.

-> Art and Fear via Stratechery

Use ints instead of enums on Android

Romain Guy, an Android framework engineer, gave a great talk at Devoxx on building Android apps in a memory conscious fashion.  See the link at the end of the post for the entire slide deck.

One thing always stood out to me, using int variables instead of enums.  As great as Java enums are (self documenting, type safety, etc), the following slide convinced me not to use them unless I really needed to.

Screenshot from 2015-03-04 19:11:44

 

It may seem like a trivial amount, but 1) that’s an order of magnitude smaller when you use int variables instead of enums and 2) a couple thousand bytes here and there in aggregate can lead to substantial savings.  Those memory savings matter, especially on lower end devices.

-> Android Memories