PHP

 

Screenshot from 2015-06-09 18:51:28

I can’t believe I was about to take the time to contribute another negative article to the Internet about PHP.  Instead of spending any more time on it, I’ll just leave this here.

I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make itcompletely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

–> PHP: a fractal of bad design

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