Despite the best efforts of modern spam filters, we all still receive spam once in a while. When I see a spam email pop up in my main inbox, I often wonder what magic the spammer has discovered that allowed them to bypass Gmail’s spam filtering. (Often times, this translates into me being much more suspicious of a spam email than usual, as it must be “more advanced” in some way to have landed in my inbox.)

Just this past week, I received one such email. It had no subject, no body, was addressed to no one, but was cc’d to myself and 29 other Peters.

(The “…” box provided by Gmail did not expand or collapse any content when clicked.)

A side note on the recipients - it looks like the other unlucky email addresses either contained the string “peter” in the local part or the domain part. Interestingly, some of the recipients’ addresses did not contain the string “peter,” but visiting

Google’s DeepDream neural net image processing library is a stunning application of advanced technology. If you haven’t heard of it, DeepDream uses an image recognition system in reverse - instead of trying to identify which objects are in a photo, it accentuates what it sees, producing extremely trippy visuals:

While DeepDream is cool, it’s also notoriously difficult to set up, as it was built by researchers with exceedingly complex software tools. Shortly after its launch, Matthew Ogle and myself decided to put together a web interface - http://deepdre.am to make the process simpler.

The site itself is pretty trivial - one page, with three options and one upload button. The fun part wasn’t the visual design or the user experience, but rather the scalable backend services that adapt the system to varying amounts of load without costing much more than a fancy coffee each month.

This past June, I graduated from the University of Waterloo’s Software Engineering program. After 5 long and difficult years, I’m extremely proud to say that I’m a Waterloo grad, and very proud of my accomplishments and experiences at the school. Somewhat surprisingly, myself and most of my classmates were able to graduate from a top-tier engineering school with zero debt. (I know this might sound like a sales pitch - stick with me here.)

Waterloo is home to the world’s largest cooperative education programs — meaning that every engineering student is required to take at least 5 internships over the course of their degree. Most take six. This lengthens the duration of the course to five years, and forces us into odd schedules where we alternate between four months of work and four months of school. We get no summer breaks.

One of the most important parts of Waterloo’s co-op program is

For this year’s holiday party at The Working Group, I helped build something special to spice up the party - a live, music-synced slideshow of the evening, powered by a nearby photo booth. Take a photo with your friends and loved ones, then see it show up on the big screen seconds later.

 The Hardware

To take the photos, we mounted a Canon Rebel T2i with an [Eye-Fi card](www.eye.fi) on a tripod in front of a great backdrop. A generous serving of props was provided for people to play with, and the room was well lit.

Also significant - the photo booth had a glass wall on one side, making it easy for partygoers to notice the fun to be had inside, while still allowing for a little bit of separation from the cacophony outside.

Finally, to allow partygoers to trigger their photos themselves without needing someone behind the camera, Brian Gilham and I built a huge, industrial-looking

Nearly a year ago, I launched forever.fm - a free online radio station that seamlessly beat matches its songs together into a never-ending stream. At launch, it was hugely popular - with hundreds of thousands of people tuning in. In the months since its initial spike of popularity, I’ve had a chance to revisit the app and rebuild it from the ground up for increased stability and quality.

(Grab the free iOS and Android apps to listen to forever.fm on the go.)

Initially, Forever.fm was a single-process Python app, written with the same framework I had built for my other popular web app, The Wub Machine. While this worked as a proof of concept, there were a number of issues with this model.

• Single monolithic apps are very difficult to scale. In my case, Forever.fm’s monolithic Python process had to service web requests and generate the audio to send to its listeners. This task is

Early in my academic career at the University of Waterloo, I was fortunate enough to land a co-op placement at The Working Group. Back then, the team was just over a dozen people. We were taking on our first mobile projects, and were starting to outgrow our old office at the Burroughes building – where we still had musical jam sessions with the partners every couple weeks. I learned more and had more fun in that four-month placement than I thought possible.

That was two years ago. In February 2013, I founded a software company that creates music apps that anybody can use. So far, our portfolio of products includes The Wub Machine, an automatic music remixing app, and Forever.fm, an app that creates an infinite DJ mix of the hottest songs on SoundCloud. These two apps have proven popular, and have already reached more than 1,000,000 people across the world. However, their development

Let’s go back to the good old days of writing web applications in PHP for a paragraph or two. When running PHP under Apache or nginx, every HTTP request resulted in a clean interpreter with completely new state. Developers had to explicitly ask for state to be shared - through the $_SESSION global, by persisting state on disk, or by saving state to some backing data store. This made developing applications amazingly simple. A PHP page was something like a pure function, producing consistent, predictable output based on the state of the underlying data store.

Now, consider this little bit of Python code:

class PatternRemixer(Remixer):
    _samplecache = {}

    def remix(song):
        # do some stuff
        for key in song:
            if key not in self._samplecache:
                self._samplecache[key] = self.render_audio()
            self.output(self._samplecache[key])

Any

Pipelines are an extremely useful (and surprisingly underused) architectural pattern in modern software engineering. The concept of using pipes and filters to control the flow of data through software has been around since the 1970s, when the first Unix shells were created. If you’ve ever used the pipe (“|”) character in a terminal emulator, you’ve made use of the pipe-and-filter idiom. Take the following example:

cat /usr/share/dict/words |     # Read in the system's dictionary.
grep purple |                   # Find words containing 'purple'
awk '{print length($1), $1}' |  # Count the letters in each word
sort -n |                       # Sort lines ("${length} ${word}")
tail -n 1 |                     # Take the last line of the input
cut -d " " -f 2 |               # Take the second part of each line
cowsay -f tux                   # Put the resulting word into Tux's mouth

When

The modern trend of providing an API for everything is wonderful. With minimal effort, any developer with an internet connection can programmatically access a wealth of data and powerful functionality. Without APIs, many hackathons wouldn’t exist, and many new developers would languish in frustration instead of participating in the best part of software development - building fun stuff.

However, all of this convenience comes at a cost. Often, that cost is literal, if an API provider decides to charge for access. This is the entire business model of many companies, and there are now even companies that provide API-monetization-as-a-service. This has created a kind of purely digital marketplace, by literally allowing people to buy access to data and functions. (This is a Good Thing™, as it encourages competition and variety in the API market, and reduces time-to-ship for many developers.)