As I usually do after wrapping up a long-term consulting project, I recently took a long break from work to level-up my programming skills. On my list of technologies to muck around with were Angular 2, TypeScript, and RxJS.

I like to have a small, fun project to hack on when I’m learning a new framework or programming language. This time I decided to combine my love for music production and the web platform to build a rudimentary sampler in the web browser.

A sampler is a musical instrument that allows a musician to load audio recordings into memory and play them back using a bank of pressure-sensitive pads or a MIDI controller. These recordings can be simple percussive sounds—such as snare drums, kicks, hi-hats, etc.—or sections of existing songs. Once they’ve been loaded into the sampler, these recordings—or samples—can be rearranged to create entirely new songs. For example, here’s a video of a musician creating a hip-hop beat using audio samples from several sources on an Akai MPC2000 XL:

While most genres of music make use of samplers in one way or another, their use is especially prevalent in hip-hop and the myriad sub-genres of EDM.

Before Moore’s Law turned the personal computer into a full-featured music production studio, artists composed their tracks using hardware samplers such as Akai’s legendary MPC or Ensoniq’s SP1200. Modern day artists are more likely to use software samplers running on their laptops or even iPads over bulky pieces of hardware.

In this series of tutorials, we’ll build exactly that: a software sampler that runs inside your web browser. Once we’re done, our sampler will be able to load audio samples, change their playback rates and volumes, apply simple effects to them, and play them back in response to events from a MIDI controller or a computer keyboard.

We’ll use Angular 2 as our web framework, the WebAudio API to process and play back audio, and the WebMIDI API to talk to our MIDI controller.

To begin with, let’s go over a few Angular 2 and WebAudio fundamentals.

Set up an Angular 2 Project

If you have no prior experience with Angular 2, I would recommend that you at least read the official Angular quickstart and setup guide before moving forward with this tutorial.

Done? You should have ended up with a simple Hello World type app backed by a build system that automatically recompiles your code and reloads the browser every time a file is modified. Hang on to this code, we’ll build our sampler on top of it.

At this point, you might want to go into styles.css and nuke the contents.

Play a Sound with the WebAudio API

The WebAudio API lets you play, synthesize, manipulate, and monitor audio in the browser with an incredible amount of precision and control. Instead of going into the theory behind the API, I’m going to take a code-first approach and explain parts of the API as we use them to build our sampler.

To begin with, let’s look at the simplest use case for WebAudio: loading an audio file from a URL and playing it back.

In this tutorial we’ll load a single sample from a URL and play it back when a button is clicked.

Create an AudioContext

Open app.component.ts from the quickstart in your text editor. It should look like this:

import { Component } from '@angular/core';

@Component({
    selector: 'my-app',
    template: `<h1>Hello {{name}}</h1>`,
})

export class AppComponent  { name = 'Angular'; }

In order to do anything at all with the WebAudio API, we must create a new instance of AudioContext. We’ll talk about what AudioContext does in a bit. For now, just follow along.

Let’s create the AudioContext right after Angular has finished initializing our AppComponent.

import { Component, OnInit } from '@angular/core';

@Component({
    selector: 'my-app',
    template: ``,
})
export class AppComponent implements OnInit  {
    private audioContext: AudioContext;
    ngOnInit() {
        this.audioContext = new AudioContext();
    }
}

In the code above, our AppComponent implements the OnInit interface, which defines a single method: ngOnInit(). This is a lifecycle hook that is invoked after the component has been initialized and all of its inputs and output bindings (more on these later) are live.

ngOnInit() is a great place to create our AudioContext. In the code above, we declare a property called audioContext on AppComponent and initialize it inside ngOnInit().

Initializing an AudioContext is simple: we call new AudioContext() and we’re on our way.

Lifecycle what?

From the moment it’s created to the moment it’s destroyed, each Angular 2 component has a lifecycle that’s managed by the framework itself. For each stage in its lifecycle, a component can implement a method called a lifecycle hook that gives it a chance to implement custom behavior during that stage. For a full list of lifecycle hooks that Angular invokes, read the chapter on lifecycle hooks in the documentation.

Why did we initialize audioContext inside ngOnInit() when we could have done it inside AppComponent’s constructor? A component’s input and output bindings are undefined at the time its constructor is called. If your initialization code depends on the values of these bindings, it will fail if you put it inside the constructor. By the time ngOnInit() is called, all the input and output bindings have been checked for modifications once and are ready for use.

Our simple example doesn’t declare any bindings on AppComponent so it doesn’t matter where we put our initialization code, but putting it in ngOnInit is good practice and you should get used to doing it early on.

Fetch Audio Data from a URL

Even though Angular comes with its own HTTP library located in the angular2/http module, we’re not going to use it for this tutorial. As of this writing, the library does not support loading data into ArrayBuffers without resorting to ugly hacks.

If you’re reading this in the future and the Angular team has added support for ArrayBuffers to the HTTP library, leave a comment on this article or write to me at contact@ankursethi.in and I will update this section. For now, we’ll use a simple fetch() to download our audio sample.

Let’s add a new method to AppComponent:

fetchSample(): Promise<AudioBuffer> {
    return fetch('samples/snare.wav')
        .then(response => response.arrayBuffer())
        .then(buffer => {
            return new Promise((resolve, reject) => {
                this.audioContext.decodeAudioData(
                    buffer,
                    resolve,
                    reject
                );
            })
        });
}

We begin by fetching the audio sample from a URL using fetch(). Then, we call arrayBuffer() on the response object to read the response data into a new ArrayBuffer. We now have a reference to a buffer containing binary audio data stored in snare.wav. However, .wav is not an audio format that the WebAudio API understands. In fact, the only format the WebAudio API understands is linear PCM. Before we can play our file, we must somehow turn it into linear PCM. But how?

We use the decodeAudioData() method on our AudioContext to decode the data and create a new AudioBuffer object. This object contains the PCM data we’re looking for. In the end, our fetchSample() method returns a Promise that resolves with the AudioBuffer.

Let’s load the sample when our component is initialized. At the same time, let’s add a play button to the web page. It’s a good idea to disable the play button while the sample is loading.

Change the component’s template so it looks like this:

`<button [disabled]='loadingSample'>play</button>`

The [disabled]='loadingSample' syntax is a form of one-way data binding called property binding. This code binds the disabled property of the play button to the value of loadingSample on our AppComponent instance. The direction of data flow is from the component class to the template, i.e, any change to the loadingSample property inside the component instance will reflect in the template, but not the other way round.

Now add the loadingSample property to AppComponent. Also add an additional property called audioBuffer to store a reference to our decoded audio data.

export class AppComponent  implements OnInit {
    private audioContext: AudioContext;
    private loadingSample: boolean = false;
    private audioBuffer: AudioBuffer;

    ngOnInit() {
        this.audioContext = new AudioContext();
    }

    fetchSample(): Promise<AudioBuffer> {
        return fetch('samples/snare.wav')
            .then(response => response.arrayBuffer())
            .then(buffer => {
                return new Promise((resolve, reject) => {
                    this.audioContext.decodeAudioData(
                        buffer,
                        resolve,
                        reject
                    );
                })
            });
    }
}

Finally, call fetchSample() inside ngOnInit():

ngOnInit() {
    this.audioContext = new AudioContext();

    this.loadingSample = true;
    this.fetchSample()
        .then(audioBuffer => {
            this.loadingSample = false;
            this.audioBuffer = audioBuffer;
        })
        .catch(error => throw error);
}

We’re ready to play our sample!

Play a Sample

Add a new method to the component:

playSample() {
    let bufferSource = this.audioContext.createBufferSource();
    bufferSource.buffer = this.audioBuffer;
    bufferSource.connect(this.audioContext.destination);
    bufferSource.start(0);
}

We start out by creating a new instance of AudioBufferSourceNode and setting its buffer property to the audioBuffer we created in the previous section. An instance of AudioBufferSourceNode represents a source of audio in the PCM format stored inside an AudioBuffer.

Next, we connect bufferSource to the destination of our audioContext. More on this in the next section.

Finally, we tell the bufferSource to play the audio stored in audioBuffer immediately by calling bufferSource.start(0).

That’s it. The only thing we need to do now is to call our playSample() method when the play button is clicked. But first, let’s take a step back and talk about the WebAudio API.

Audio Contexts and Audio Nodes in the WebAudio API

All audio operations in the WebAudio API happen inside an AudioContext, an object representing a graph of audio processing nodes. Each audio processing node in this graph is responsible for performing a single operation on the audio signal that flows through it. The API defines nodes for generating audio signals, controlling volume, adding effects, splitting stereo channels, analyzing audio frequency and amplitude, etc. In code, these audio processing nodes are represented by objects that implement the AudioNode interface.

Our journey through the audio processing graph begins at an audio source node, a type of audio node that represents a source of audio. We’ve already seen one type of audio source node in this tutorial: the AudioBufferSourceNode.

The signal from an audio source node can be piped into an instance of an AudioDestinationNode using AudioNode’s connect() method. In playSample(), we pipe the output of our AudioBufferSourceNode to the destination property of our AudioContext. This property is an instance of an audio destination node that represents the computer’s currently selected audio output device. The audio processing graph created by playSample() looks like this:

This is the simplest audio processing graph possible, consisting of only a source of audio and a destination. In reality, we’re not limited to just two audio nodes per audio context. Before our audio signals exits the graph at an audio destination node, it could pass through a number of audio effect nodes or analyzer nodes that change the nature of the audio signal in significant ways.

Here’s an example of a more complex audio graph:

As we add more features to our sampler, we’ll talk about the different kinds of audio nodes available to us and use them to construct more complex audio graphs. For now, this is all you need to know to start using the WebAudio API.

With that out of the way, let’s move on and add a click handler to our play button so we can finally hear our audio sample.

Add a Button with a Click Handler

Modify the AppComponent template to look like this:

`<button (click)='onClick()'
         [disabled]='loadingSample'>play</button>`

Then, add a new method to AppComponent:

onClick() {
    this.playSample();
}

The (click)='onClick()' syntax is a form of one way binding called event binding. It’s used to declare an expression that is executed in the scope of the component when an event occurs in its view. In this case, we call the onClick() method on AppComponent when our button is clicked.

Refresh your browser and click the play button. Congratulations, you’ve just loaded and played an audio file using the WebAudio API!

Adjust Playback Speed

Adjusting the playback speed of the audio sample is a simple matter of changing bufferSource’s playbackRate property. Let’s add a private variable to our component:

private playbackRate: number = 1.0;

Add a range input to the template:

<div>
  <button (click)='onClick()'
          [disabled]='loadingSample'>play</button>
</div>
<div>
  <input type='range'
         min='0.01'
         max='5.0'
         step='0.01'
         [(ngModel)]='playbackRate'>
</div>

Since the ngModel directive is part of Angular’s FormsModule, we need to inject it into our application. At the top of app.module.ts, add:

import { FormsModule } from '@angular/forms';

Then, edit the imports section of the configuration passed to the NgModule decorator so that it includes FormsModule:

imports: [ BrowserModule, FormsModule ]

So far in this tutorial we’ve worked with two kinds of bindings: event bindings and property bindings. Both of these are forms of one-way binding.

The [(ngModel)]='playbackRate' syntax in the code above is a form of two-way binding. Here, we’re telling Angular to update the value of our component’s playbackRate property whenever the user moves the range input, and to update the value reflected by the range input whenever the user changes the component’s playbackRate property. ngModel is a built-in Angular directive that makes this possible.

Finally, change the playSample() code so it sets the playback rate of bufferSource before playing the sample:

playSample() {
    let bufferSource = this.audioContext.createBufferSource();
    bufferSource.buffer = this.audioBuffer;
    bufferSource.playbackRate.value = this.playbackRate;
    bufferSource.connect(this.audioContext.destination);
    bufferSource.start(0);
}

Now try moving the playback rate slider and clicking the play button.

Adjust Playback Volume

To control the playback volume of our sample, we’ll add an audio processing node called GainNode between the AudioBufferSourceNode and the destination of our AudioContext. After we’re done, our audio processing graph will look like this:

GainNode can be used to boost or attenuate the audio signal that passes through it. A gain of 1.0 means no change in the audio signal. A gain greater than 1.0 means the signal will be boosted (often causing unwanted distortions in the signal), and a gain of less than 1.0 means the signal will be attenuated.

First, add a property called gain to the component:

private gain: number = 1.0;

Next, add another slider to the template and bind its value to gain:

<div>
  <button (click)='onClick()'
          [disabled]='loadingSample'>play</button>
</div>
<div>
  <label for='playbackRate'>Playback rate:</label>
  <input type='range'
         id='playbackRate'
         min='0.01'
         max='5.0'
         step='0.01'
         [(ngModel)]='playbackRate'>
</div>
<div>
  <label for='gain'>Volume:</label>
  <input type='range'
         id='gain'
         min='0.01'
         max='5.0'
         step='0.01'
         [(ngModel)]='gain'>
</div>

It’s a good idea to add labels to the gain and playbackRate sliders so we know which one is which.

Finally, modify the audio graph in playSample():

playSample() {
    let bufferSource = this.audioContext.createBufferSource();
    bufferSource.buffer = this.audioBuffer;
    bufferSource.playbackRate.value = this.playbackRate;

    let gainNode = this.audioContext.createGain();
    gainNode.gain.value = this.gain;

    bufferSource.connect(gainNode);
    gainNode.connect(this.audioContext.destination);

    bufferSource.start(0);
}

Now try moving the volume slider and clicking the play button.

Next Steps

In addition to the basics of the WebAudio API, this tutorial covered lifecycle hooks, event bindings, property bindings, and two-way bindings in Angular 2.

In the next tutorial, we’ll learn how to trigger our sample using a MIDI controller or computer keyboard.

The Essence of Camphor is a collection of short stories by Naiyer Masud, considered one of the foremost Urdu short-story writers in India. This collection contains English translations of ten of his stories.

This is not the sort of book I would have picked up on my own. It was Pratul who urged me to read it, comparing Masud’s style to that of Haruki Murakami. While Masud and Murakami write about completely different people in completely different cultural contexts, I feel Pratul’s comparison is not entirely inapt. There are many parallels between the works of the two writers, which is not surprising considering both of them are strongly influenced by Kafka.

Masud’s stories are surreal and dreamlike, and as one would expect, they don’t conform to traditional narrative structures. Many of them are told in a stream of consciousness style by narrators who appear to be reminiscing about their early years. Themes of childhood and family life in old India are prominent throughout. Someone on Goodreads called them “mood stories”—stories with the sole purpose of evoking a sense of time and place, or I suppose the lack thereof. In other words, Kafkaesque. Some of them are vaguely terrifying (Obscure Domains of Fear and Desire, The Woman in Black), others are sorrowful (The Essence of Camphor, Nosh Daru), all of them are beautiful. Masud captures the sights, sounds and smells of old Lucknow in such vivid detail that you almost start reminiscing about the good old days yourself.

Beautiful as they are, these stories are also inscrutable. I rarely read the introduction to a book before reading the book itself, but I’m glad I broke my rule this time. Muhammad Umar Memom—who wrote the introduction and translated some of the stories—has this to say about Masud’s work:

[…] reading Masud’s stories evoked the sensation of being thrown headlong into a self-referential circularity.

Which I interpret to mean: don’t think too hard kids, just enjoy the ride. And what a ride it is.

To be honest, I often felt frustrated with this collection. I would not recommend reading it from beginning to end in one sitting. This is a book best consumed slowly, over a span of many weeks. Despite my frustration, some of these stories have left a deep impression on my mind.

If you enjoy Murakami and/or Kafka, I’d highly recommend picking up a copy of The Essence of Camphor. If you’re not into surrealism, keep away.

The hardest thing to do after finishing a book is deciding which one you want to read next. Things become harder still when you and your roommates collectively own hundreds of books, most of which have been on your to-read list for years. And if you own an e-reader with even more books on it—you see where I’m going with this, right?

This is why I have made a reading list for this year, and it looks something like this:

• The Essence of Camphor by Naiyer Masud
• Shantaram by Gregory David Roberts
• Ready Player One by Ernest Cline
• Sea of Poppies by Amitav Ghosh
• River of Smoke by Amitav Ghosh
• The Shadow Lines by Amitav Ghosh
• In the Miso Soup by Ryu Murakami
• Coin Locker Babies by Ryu Murakami
• Almost Transparent Blue Popular Hits of the Showa Era by Ryu Murakami
• Siddhartha by Herman Hesse
• Flowers for Algernon by Daniel Keyes
• Oryx and Crake by Margaret Atwood
• The Year of the Flood by Margaret Atwood
• MaddAddam by Margaret Atwood
• The Handmaid’s Tale by Margaret Atwood
• The Left Hand of Darkness by Ursula K. Le Guin
• The Dispossessed by Ursula K. Le Guin
• Ghostwritten by David Mitchell
• number9dream by David Mitchell
• One Flew Over the Cuckoo’s Nest by Ken Kesey
• Something Happened by Joseph Heller
• The Spy Who Came in from the Cold by John Le Carré
• Tinker Tailor Soldier Spy by John Le Carré
• The Honourable Schoolboy by John Le Carré
• Smiley’s People by John Le Carré

Update: Since I couldn’t find an electronic version of Ryu Murakami’s Almost Transparent Blue, and the physical version was too expensive in India, I decided to replace it with Popular Hits of the Showa Era.

The Good

• Moved to Bangalore. Probably the best decision I’ve made in the last five years. When I moved here, I told myself I’d stay for at most one year. Now it’s starting to look like I’ll be here for a while.

• Started cycling. This is Bangalore rubbing off on me.

• Passed all my college exams.

• Started working full time.

The Bad

• Can’t think of anything, really. Minor existential crises don’t count. 2013 was a suspiciously good year.

The Ugly

• Picked up wrist and back injuries because of bad posture while working on the computer. The injuries are minor, but they inhibit my ability to work for long periods of time. I’ve made several lifestyle changes to combat these, and they’re slowly paying off. Still, the road to recovery is long and fraught with many setbacks.

The Highlights

• Best book read: a close tie between Cloud Atlas and Speaker for the Dead.
• Best musician discovered: Janelle Monáe.
• Favorite albums of the year: Good Kid m.A.A.d City, Doris.
• Favorite new software: PyCharm, Pinboard.in, Google Keep.

Unlockments Achieved

• Streamlined my web development and deployment workflow. I’ve started using Vagrant and Ansible a lot, and unit tests have become an integral part of my work.
• Read (slightly) more than I did in 2012. I read fifteen books in 2013, but fell short of my goal of twenty-five.
• Started exercising.
• Moved to Bangalore.

What Next?

There were several goals that I couldn’t achieve in 2013. I’d like to tackle them again this year.

• Release one or two useful webapps into the wild. (If possible, monetize these.)
• Start keeping track of how I spend my time.
• Start keeping track of the movies I watch, the books I read and the music I listen to.
• Read more. Twenty-five books, at least.
• Super secret goal.

Besides these leftover goals from last year, I have some new goals for this year.

• Manage my time better.
• Start contributing to an open source project.
• Write more. Technical blog posts, book reviews, music reviews, private journals, fiction, whatever.
• Learn about machine learning and statistics. Perhaps a MOOC is the best way to do this.

Have a happy new year, folks. Make it one worth remembering!

Spin.js is a tiny JavaScript library that helps you create beautiful loading spinners on every web browser up from IE6. It is highly customizable, fast, and has zero dependencies. I’m using it in my AngularJS application to display loading spinners inside my ng-views while my REST API responds with the data the view needs to render itself.

I add a viewLoading boolean to the $scope of each controller that talks to the REST API. The initial value of viewLoading is true.

angular.module('MyApplication')
  .controller('MakesTonsOfAPICalls', function($scope) {
    $scope.viewLoading = true;
  });

After all the API calls complete successfully, I set viewLoading to false.

angular.module('MyApplication')
  .controller('MakesTonsOfAPICalls', function($scope, MyLargeModel) {
    $scope.viewLoading = true;

    // Grab all MyLargeModel objects.
    MyLargeModel.get({}, function(result) {
      // Do something with the result.
      $scope.viewLoading = false;
    });
  });

If I have to make multiple calls, I use the $q service to create a promise for each of them. Each promise is resolved or rejected depending on the status code that the API call returns. I then use $q.all() to call a function when all of the promises have been resolved. This function sets viewLoading to false. I will talk more about $q in another post, but here is a rather simplistic example for now:

$q.all([promise1, promise2 ... promiseN]).then(function(data) {
  $scope.viewLoading = false;
});

I want the loading spinner to be displayed for as long as viewLoading is true, and be replaced by the actual view content as soon as viewLoading becomes false. I use a directive to do this. This is what the markup looks like:

<div ng-controller="MakesTonsOfAPICalls">
  <div my-loading-spinner="viewLoading">
    <!-- actual view content goes here. -->
  </div>
</div>

And this is what the directive looks like:

angular.module('MyApplication')
  .directive('myLoadingSpinner', function() {
    return {
      restrict: 'A',
      replace: true,
      transclude: true,
      scope: {
        loading: '=myLoadingSpinner'
      },
      templateUrl: 'directives/templates/loading.html',
      link: function(scope, element, attrs) {
        var spinner = new Spinner().spin();
        var loadingContainer = element.find('.my-loading-spinner-container')[0];
        loadingContainer.appendChild(spinner.el);
      }
    };
  });

For this to work correctly, the Spin.js code has to be loaded before the directive code.

The directive is restricted to attributes only and replaces the original content on the page with the content from my template. I set transclude to true so I can re-insert the original content back into the page later. If you look back at the HTML for the view, you will find that the value of the myLoadingSpinner attribute is viewLoading. When Angular encounters our markup, it will create a two-way binding between the loading variable in the directive’s scope and the viewLoading variable in the parent controller’s scope. If you find this confusing, you may want to read about directives on the AngularJS website.

Before I explain the link function, take a look at the directive’s template:

<div>
  <div ng-show="loading" class="my-loading-spinner-container"></div>
  <div ng-hide="loading" ng-transclude></div>
</div>

The markup is simple enough. The div with class my-loading-spinner-container is displayed when loading is true, and hidden if it is false. The second div is hidden if loading is true, and displayed if it is false. The second div also uses ng-transclude to re-include into the page the original content that was replaced by our directive.

Finally, the link function creates a new loading spinner, finds the div with the class my-loading-spinner-container, and puts the spinner inside the div. Hence, the spinner is displayed as long as loading is true, and the actual content is shown when it becomes false, which is exactly what we want.

I am currently working on a single page web application written with AngularJS that communicates with a REST API written with Django and Tastypie. Since I run both the client and the server locally on my machine, every HTTP request that my AngularJS application makes receives a response from the REST API in tens of milliseconds. This is not ideal.

In the real world, Internet connections have latencies that range anywhere from a few hundred milliseconds to tens of seconds. To give my user a smooth experience even on a slow internet connection, I need to ensure that she receives appropriate feedback whenever she performs an action that requires a round-trip to the server. For example, when she navigates to a view that requires a large amount of data to be fetched from the server, my application needs to display a loading spinner of some sort on the screen to indicate progress. I cannot have the UI be completely blank for the time it takes my API to respond to the HTTP request.

Unfortunately, if I run the application locally, it becomes impossible for me to test my progress indicators. The request-response cycle completes so quickly that they are replaced by the actual content within a split second.

After searching the Internet in vain for a solution that would let me simulate a “real” Internet connection from within my browser, I wrote a Django middleware that uses time.sleep() to delay each HTTP response that my application returns by 0 to 4 seconds.

import random
import time

class SlowPony(object):
    def process_response(self, request, response):
        time.sleep(random.randint(0, 4))
        return response

Then I added this middleware to my MIDDLEWARE_CLASSES:

MIDDLEWARE_CLASSES = (
    # ...
    'my_application.middleware.SlowPony',
)

I don’t like this solution. For one, this does not cause any of the requests to time out, which happens frequently on mobile Internet connections. It’s better than nothing, though.

I find it surprising and disappointing that neither Firefox nor Chrome let me simulate slow Internet connections via their developer tools. Fast, reliable, low-latency Internet connections are a rarity, especially since a large and growing number of people browse the web using mobile Internet. This situation is unlikely to change for several years in the future, and tools to test our web applications in such scenarios are either incomplete or non-existent.

GameDev.net recently published a four-part series on writing cross-platform build systems with CMake. The series first covers the very basics of CMake, followed by a tutorial on how to add unit-tests to your codebase using googlemock. Parts 1, 2, 3, 4.

(Edit: with the release of CMake 2.8.11, a fifth part was recently added.)

I consider myself lucky that I don’t have to work with C++ code very often. It’s not that I dislike the language, it’s just that I dislike working with build systems. All build systems are terrible and, much worse, poorly documented. I can never figure out how to accomplish the simplest of tasks with any of them. CMake happens to be the least bad of all build systems I’ve had the profound displeasure of having used, and this series of tutorials is the best I’ve encountered on the use of CMake.

Bob Nystrom’s two-part blog post about iteration in programming languages includes perhaps the clearest explanation of coroutines I have read so far. It begins with an exploration of how iteration is implemented in mainstream programming languages, and goes on to talk about internal and external iterators, the yield statement in C# and Python, the callstack, coroutines in Ruby (or fibers, as Ruby likes to call them) and why iteration is another way of thinking about concurrency.

Read Iteration Inside and Out and Iteration Inside and Out, Part 2.

If you use Tastypie with Django’s timezone support turned on (i.e, you have USE_TZ = True in your settings.py), you will notice that Tastypie helpfully converts all dates and times in your resources to the timezone specified in your TIME_ZONE setting before returning them. If you care about internationalization, this is not the behavior you want. Tastypie encodes dates and times in the ISO8601 format by default. These dates and times have no timezone information attached to them, which means that the consumers of your API will have no idea how to correctly display them or convert them to other timezones.

This is what ISO8601 datetimes look like:

{
    "end_time": "2013-04-01T06:32:06",
    "start_time": "2013-04-01T00:30:00"
}

Both those datetimes are in the Asia/Kolkata (UTC+5:30) timezone. How can I tell? I can’t. Unless I look in my settings.py. Not cool.

There are two solutions to this problem. First, you could add this line to your settings.py:

TASTYPIE_DATETIME_FORMATTING = 'rfc-2822'

This will cause Tastypie to format dates and times using the format specified in RFC2822. Your dates and times will now include timezone information:

{
    "end_time": "Mon, 1 Apr 2013 12:02:06 +0530",
    "start_time": "Mon, 1 Apr 2013 06:00:00 +0530"
}

The second solution, which is the solution I prefer, is simpler: use UTC everywhere on the server and let your API consumers deal with timezone conversions. Set your TIME_ZONE to "UTC" and sleep easy.

If your API consumer is a web application, I highly recommend using Moment.js for all date and time operations.

Year 2011. Lines of elisp in .emacs: 145. Lines of configuration in .vim: 115.

Year 2013. Lines of configuration in .vim: 0. Lines of JSON in Sublime Text configuration: 0.

This is so much better.