How to work with dates and times in Swift, part one

by Joey deVilla on January 26, 2015

i just want to use dates

swift kickIf you’re just getting started with date and time programming in Swift, chances are that you probably did some Googling, found NSDate and its companion classes in Apple’s documentation and promptly got confused. Let me reassure you that it isn’t your fault. Apple’s Date and Time Programming Guide isn’t set up in the most helpful way, and its examples are in Objective-C, which can throw you off if you’re not familiar with its [instance method] calling syntax.

If you’re coming to Swift from JavaScript, which makes do with a single object type called Date, the idea of having this set of classes just to handle dates and times looks like overkill:

cocoa date time class chart

Click the chart to see it at full size.

This is the first article in a short series on programming dates and times in Swift. It’ll help you make sense of working with NSDate and its companion classes.

What is UTC? (or: “It’s 5 o’clock somewhere!”)

what time is it right now

People who like to drink are fond of saying “Well, it’s five o’clock somewhere!“, and it’s my favorite way of illustrating that what time it is depends on where you are. It’s why we have UTC — Coordinated Universal Time — the “One True Time” on which every other time zone is based. UTC replaced GMT (Greenwich Meridian Time, the time as observed at the Royal Observatory in Greenwich, London), and it doesn’t change for daylight savings. By having this standard, we eliminate the confusion that comes up when discussing times.

While most places have some names to refer to time zones in everyday conversation — such as Pacific, Mountain, Central, and Eastern in North America — the clearest way to indicate time zones is to express them as negative or positive offsets from UTC. For example, the North American time zone known as “Eastern” is 5 hours behind UTC, so it’s expressed as UTC-05:00. There are certain time zones where the offset isn’t whole hours, such as Newfoundland’s, which is UTC-03:30, and Nepal’s, which for some reason is UTC+05:45.

NSDate: Cocoa standard time

When you want to represent a date or time in Cocoa, you do so with an instance of the NSDate class. Here’s a nice, simple description of what NSDate is:


When you’re measuring time, you need a reference point. The Gregorian calendar — the one that I’m 99.999999% sure that you’re using right now — uses what is said to be the year of the birth of Christ as its reference point. Your age uses the date of your birth as a reference point. A time trial race uses the time at the start of the race as its reference point.

NSDate‘s reference point is the start of the third millennium: January 1, 2001 at midnight UTC. It stores time as an NSTimeInterval, a 64-bit floating point value representing a number of seconds. Negative values represent a number seconds before January 1, 2001, 00:00 UTC, and positive values represent a number seconds after that time. According to Apple’s documentation, this representation of time “yields sub-millisecond precision over a range of 10,000 years”, which means that an NSDate instance can represent any point in time from about 3000 BC/BCE to 7000 AD/CE.

Here are 4 historical dates, as seen from NSDate‘s perspective:

historical dates nsdate style

There are some consequences to the fact that NSDate treats time as an offset of seconds:

  • All NSDate values refer to both a date and a time. If you want to use an NSDate to store a date only, you ignore the time portion, and vice versa.
  • NSDate has no concept of time zones or any time unit other than seconds. That means you can’t ask it what year, month, day, hour, or minute correspond to the time it’s storing. As far as it’s concerned, there are no calendars; you work with NSDate‘s representation of time, when it’s time to display a date, time, or both, you format it to use the calendar and time zone that’s appropriate for the user.

There’s a method to this madness: it allows us to use and store dates and times in a way that’s independent of calendar systems, time zones, languages, and date formats. As I write this, it’s the year 2015 in the Gregorian calendar, but the Buddhist calendar says it’s 2558, and if you go by the Hebrew Calendar, it’s 5775. I may say it’s 9:45 a.m. as I write this in Tampa, but if you’re in California, it’s 6:45, and if you’re a soldier, you might call it 14:45 Zulu Time. I call the current month January, but you might call it Enero or Janvier. It’s all the same as far as NSDate is concerned, which makes it incredibly flexible.

Creating NSDates without any helper classes: now is easy, other dates ain’t so pretty

Let’s create some NSDates right now. Fire up Xcode, open a new playground, and enter the following code so that it looks like this:

You should see results in the sidebar that look similar to this:

playground 1

If you create an NSDate without any parameters, you get an instance representing the date and time at the moment it was created. That’s what we’ve done by creating the instance named now.

Note that in the sidebar beside line 5, where we created now, the result displayed in the sidebar is Jan 19, 2015, 8:52 AM. While the internal representation of the current time is a 64-bit floating point value, Xcode’s doing us a favor by representing it in a more readable format and using the local time zone. It’s doing this by making use of a date formatter, which we’ll cover later.

In line 6, we’re using the println function to display the default string representation of an NSDate, which is a completely numeric one. It’s more readable than a 64-bit floating point value, but it might not be in the format or time zone (or even the calendar system) that you want. Once again, this output comes courtesy of a date formatter.

Finally, in line 7, we use the timeIntervalSinceReferenceDate property to display now‘s internal representation of the date and time it’s storing: about 443 million seconds after January 1, 2001 at midnight UTC.

Let’s create the dates from the Historical dates, NSDate style picture above. Enter or paste the highlighted code below so that your playground looks like this:

In the sidebar, you should see nicely-formatted dates beside the NSDates you created.

NSDate has four initializers for creating specified dates and times:

Initializer Description
init(timeIntervalSinceReferenceDate:) Create an NSDate instance representing a time specified by a number of seconds before or after January 1, 2001 00:00 UTC.
init(timeIntervalSinceNow:) Create an NSDate instance representing a time specified by a number of seconds before or after the current date and time.
init(timeIntervalSince1970:) Create an NSDate instance representing a time specified by a number of seconds before or after January 1, 1970 00:00 UTC. This method exists not because Apple’s founders were California hippies nostalgic for the era of their youth, but for compatibility with Unix time.
init(timeInterval:sinceDate:) Create an NSDate instance representing a time specified by a number of seconds before or after a given NSDate.

You’ve probably noticed that none of these initializers lets you create an NSDate by giving it something convenient like a year, month, day, time zone and so on. Luckily, there are classes that will help us do this.

Creating NSDates with the help of NSCalendar and NSDateComponents

If you’re like most people, you’d probably much rather initialize a date object using a day, month, year, and time instead of some number of seconds before and after midnight on January 1, 1970, January 1, 2001, or any other arbitrary date. For this, we’ll need a couple of additional classes:

nscalendar and nsdatecomponents

First, there’s the NSCalendar class, which among other things, gives us a context for converting NSDate‘s “seconds before or after the third millennium” measurements into a familiar time system with years, months, days, hours, and minutes, and it accounts for time zones as well. Most of the time, the date and time system will be the Gregorian calendar, but iOS also lets you choose from 15 other calendar systems, including Hebrew and Buddhist.

Next, there’s the NSDateComponents class, which is an assembly of properties that make up a date, such as year, month, date, hour, minute, second, and so on. An NSDateComponents instance can be used to represent either:

  • A specific point in time, or
  • a duration of time.

To create an NSDate by specifying things like a year, month, day, and time, we’ll do the following:

  • Create an NSCalendar instance pointing to the user’s calendar
  • Specify a date using an NSDateComponents instance
  • Create the NSDate by passing the NSDateComponents instance to NSCalendar‘s dateFromComponents instance method

nsdatecomponents to nsdate

Let’s go back to our playground and create our first historical date: that of Alexander Graham Bell’s first phone call. We know it took place on March 10, 1876. While we don’t know the exact time it happened, we do know that it happened in North America’s Eastern time zone, as opposed to something like Kiritimati, a.k.a. Christmas Island. That place is 19 hours ahead and would’ve resulted in historians recording that day as March 11th rather than the 10th.

Enter or paste the highlighted code below so that your playground looks like this:

Any calendar, regardless of its time zone, to turn date components into dates using its calendar system. If you specify a time zone in the date components, it will take that time zone into account; if you don’t specify one, the date will be created using the calendar’s time zone. We created an instance of the user’s calendar, which incorporates the user’s local and time zone settings, because it’ll be useful later when we want to go in the opposite direction and convert dates into date components.

Note that after setting the year, month, and day properties of firstLandPhoneCallComponents, we set the timeZone component using the preferred initializer, init(name:), which lets you specify a time zone by any of the standard string identifiers listed in the tz database of time zones. I could’ve used one of the city names such as America/New_York (or for those of you familiar with Canada, America/Toronto, America/MontrealAmerica/Atikokan, or America/Pangnirtung) to specify the Eastern time zone. It’s far clearer — especially to people not from the U.S. — to use the time zone names that begin with US or Canada, such as US/Eastern, US/Central, US/Mountain, and US/Pacific rather than city names.

Once we’ve set up the date components, we use the calendar’s dateFromComponents instance method to convert them into a date. I’m in the US/Eastern time zone, the same one as the one specified in the date components, so the result in the sidebar beside this line of code shows as “Mar 10, 1876, 12:00 AM” (we didn’t specify a time in the date components, so the resulting date has the default time of 00:00). The date displayed in the sidebar uses your system settings, which may be different from mine.

Let’s enter the other three historic dates. Enter or paste the highlighted code below so that your playground looks like this:

Note that we used different time zones for the “Stevenotes”. Both took place at the same time, 10:00 a.m. Pacific, but we set the time for the iPhone announcement as 1:00 p.m. US/Eastern, and the time for the iPad announcement as 10:00 a.m. US/Pacific. Both results in the sidebar appear at the same time; on my machine, they appear as Jan 27, 2010, 1:00 PM.

dateFromComponents works with what you give it

Suppose we want to create a date just by specifying that it’s 11:00 a.m. on the first Saturday of March 2015 in the US/Eastern time zone. Here’s how it’s done:

NSDateComponentsweekday property lets you specify a weekday numerically. In Cocoa’s Gregorian calendar, the first day is Sunday, and is represented by the value 1. Monday is represented by 2, Tuesday is represented by 3, all the way to Saturday, which is represented by 7.

The weekdayOrdinal property lets you specify which specified weekday of the month. By setting weekday to 7, we’re specifying a Saturday; by then setting weekdayOrdinal to 1, we’re specifying the first Saturday of the month.

Here’s another example, where we get the date for the Thursday on the 18th week of 2015:

The other way around: getting NSDateComponents from NSDates

Right now, your playground should look like this, with a number of dates being created from date components:

Now it’s time to go the other way around, and extract date components from those dates. Once again, it’s the calendar that provides the method for making the conversion.

To extract NSDateComponents from an NSDate, we’ll do the following:

  • Create NSCalendar instances, if needed
  • Specify a set of date components using NSCalendarUnit bitmasks
  • Create the NSDateComponents by passing the NSDate instance to NSCalendar‘s components instance method

nsdate to nsdatecomponents

We already have a calendar instance: userCalendar, which is associated with the user’s time zone. If we use it to extract date components from a given date, the dates and times will be interpreted in the context of its time zone.

Let’s create two more calendars with two different time zones:

  • The US/Pacific time zone (UTC-08:00)
  • The Japan time zone (UTC+09:00)

Here’s what the code looks like:

Extracting all the possible date components from a date can be computationally costly, so NSCalendar‘s components instance method requires you to build a bitmask specifying the components you want to extract by ORing together NSCalendarUnit values. We want to extract these components from our dates:

  • year
  • month
  • day
  • hour
  • minute
  • weekday
  • weekdayOrdinal

Here’s the code:

Now that we’ve done that, we can start extracting date components:

In your playground’s sidebar, you should see results similar to those listed in the table below:

Component My user calendar Pacific calendar Japan calendar
year 2007 2007 2007
month 1 1 1
day 9 9 10
hour 13 10 3
minute 0 0 0
weekday 3 3 4
weekdayOrdinal 2 2 2

As you can see, January 9, 2007 at 10:00 a.m. in the US/Pacific time zone is January 9, 2007 at 1:00 p.m. in my time zone (US/Eastern) and January 10, 2007 at 3:00 a.m. in Japan. In the US, that date was the second Tuesday in January 2007; in Japan, it was the second Wednesday.

Turning dates into strings (and vice versa) with NSDateFormatter

nsdate - nsdateformatter - stringJust as you use an calendar to convert date components into dates and vice versa, you use a date formatter — an instance of the NSDateFormatter — to do the conversions.

Formatting date strings for the user

If you need to display a date as text for the user, it’s best if you use Cocoa’s built-in date styles. These are a set of predefined styles for formatting dates and times based on the user’s preferred settings. These styles, which are all values of the NSDateFormatterStyle enumeration, come in a selection of lengths — short, medium, long, and full — and using them is the preferred way to create date strings for the user to read.

Add the following code to your playground:

Here’s how the various date and time formatter styles get rendered:

If dateStyle and timeStyle are both set to… the date formatter’s output looks like…
ShortStyle 1/27/10, 1:00 PM
MediumStyle Jan 27, 2010, 1:00:00 PM
LongStyle January 27, 2010 at 1:00:00 PM EST
FullStyle Wednesday, January 27, 2010 at 1:00:00 PM Eastern Standard Time

What’s up with NoStyle? It’s there so you can limit the resulting string so that it shows only the date or only the time.

NSDateFormatter has a timeZone property so that you can ensure that the date string reflects a specific time zone:

Formatting date strings for other computers

As I wrote earlier, if you’re formatting dates for the user, it’s strongly recommended that you use NSDateFormatter‘s dateStyle and timeStyle properties, which will format dates and times according to the user’s settings. However, if you need to need your date strings to be in a specific format (for an API, for example), you can provide NSDateFormatter with a format string:

While you can browse through Appendix F of the Unicode Technical Standard #35 to look at all the date format specifiers supported by NSDateFormatter, you might find it easier to use the table below. It shows a number of format strings applied to the iPhone announcement date (January 9, 2007 at 10:00 a.m. Pacific):

Format string Result
'Year: 'y' Month: 'M' Day: 'd Year: 2007 Month: 1 Day: 9
MM/dd/yy 01/09/07
MMM dd, yyyy Jan 09, 2007
E MMM dd, yyyy Tue Jan 09, 2007
EEEE, MMMM dd, yyyy' at 'h:mm a. Tuesday, January 09, 2007 at 10:00 AM.
EEEE, MMMM dd, yyyy' at 'h:mm a zzzz. Tuesday, January 09, 2007 at 10:00 AM Pacific Standard Time.

Turning strings into dates

If you specify a date format string, you can use NSDateFormatter to take a string following that format to turn it into an NSDate. For example:

Tying it all together

If you’ve made it to this point in the article, this chart should now make sense:

cocoa date time class chart

Once again, click the chart to see it at full size.

You should now be able to:

  • Create dates “from scratch” (that is, create them using an offset of a number of  seconds from the start of the third millennium)
  • Create dates from date components (that is, from numbers representing a day, month, and year)
  • Convert between dates and date components
  • Convert dates into string representations and string representations of dates into dates

In the next article in this series, we’ll look at date calculations and some handy functions that let you harness Swift’s expressive power and make working with dates easier.


weather app

Whether you’re new to iOS programming or a long-timer, is a valuable resource for the iOS developer. They regularly publish tutorials, tips, tricks and other goodies that you’d be crazy to do without if you’re serious about writing apps for iDevices. In addition to articles on the site, they go deeper with their books, which are excellent. recently published an article titled AFNetworking Crash Course, which covers how to write networking apps using AFNetworking, a library created by the folks at Gowalla that simplifies iOS network programming. In this tutorial, you build a weather app that uses AFNetworking to get its data from the World Weather Online service. Check it out; AFNetworking’s useful, and the tutorial’s pretty nice.

In order to reach the widest possible audience, the tutorial was written for iOS 5 and earlier versions of Xcode. If you’re developing with the current version of Xcode and for iOS 6 (which accounted for 83% of all iOS traffic in North America in February), you might want to make a few changes to the code in the tutorial. I’ve listed the changes below:

Use Modern Array Notation

Here’s the old way to get at the element of an array whose index is theIndex in Objective-C:

It’s a little clunky, and as I wrote in an earlier article, Objective-C’s New NSNumber, NSArray and NSDictionary Syntaxes Mean Less “Yak Shaving” for iOS and OS X Developers, there’s a much nicer way to do it:

In AFNetworking Crash Course, where you see code like this:

change it to this:

Use Modern Dictionary Notation

Here’s the old way to get at the item in a dictionary whose key is theKey:

Again: it’s clunky. Also again, in my earlier article, I showed the modern way to access dictionary items:

Setting items for a dictionary used to be like this:

Now, it’s like this:

So, in the places where you see code like:

change it to:

…and where you see code like:

change it to:

Update the Deprecated Location Manager Delegate Method

If you use the code as-is with iOS 6, you’ll get an error message that looks like this:

Deprecated in iOS 6.0
Tells the delegate that a new location value is available. (Deprecated in iOS 6.0. Use locationManager:didUpdateLocations: instead.)

Instead of using the deprecated locationManager:didUpdateToLocation:fromLocation: method, use the current locationManager:didUpdateLocations: method instead:


Your Faithful Scribes are Working Away at Fixing the Docs

by Joey deVilla on December 13, 2011

Woodcutting of a scribe working on a text, with the thought bubble "WTF?"

This is just a quick update to let you know that yes, we know that the Shopify developer documentation needs work. There’s a fair bit of information there, but it could stand some improvement. There’s some missing information, it could be organized better, there are parts of it that are confusing and there need to be examples in languages and frameworks other than Ruby and Rails.

This update is also here to let you know that we’re actively working on it, bit by bit, every day. As I write this, David Underwood and are are working on a wholesale reorganization of the developer sections of the wiki and clear writeups of all the API resources, including explanations of the parameters they expect and the attributes they return as well as how they relate to other resources and what effects they have on shops. We’re also working on more example code, in more languages.

If you’ve got comments, questions and suggestions about the docs or what we’re doing with them, please let us know — feel free to leave a comment or drop me a line.

This article also appears in the Shopify Technology Blog.


ClearFit’s Looking for a Rails Developer

by Joey deVilla on November 8, 2011

Clearfit [hearts] Rails, GitHub and Amazon Web Services

My friend Robert Nishimura’s looking for a Rails developer for his company, ClearFit, which is based in uptown Toronto. He sent me some details about the position he’s trying to fill; I’ve posted them below.

If you’ve got the skills and if the position sounds interesting to you, you should drop him a line at!

Company Information

ClearFit is changing the way small businesses hire. Most people know that ‘fit’ is the most desirable attribute for employees and employers — that intangible sense that can’t be found in a resume and is difficult to glean from a job interview. It’s a huge problem — employers spend billions every year on staffing in Canada alone.

Most small business owners don’t know where to even start when hiring a new employee. Ask around for referrals, “pay and pray” with a job board or deal with an avalanche of resumes from Craigslist? 

We have built the system that some describe as “an eHarmony for jobs”. We have over 2500 registered employers and tens of thousands of registered career seekers which barely scratches the surface of a multi-billion dollar market. All this and we just completed our first round of investment so we are poised for stellar growth.

We are located in the Yonge/Eglinton neighbourhood, strategically situated between 3 Starbucks and 3 minutes from Bulldog Coffee. We’re also upstairs from Copacabana Brazilian BBQ.

Skills & Requirements


  • Minimum 2 years experience coding in Ruby on Rails
  • Minimum 2 years experience with HTML/CSS
  • Experience with Javascript (Prototype, JQuery)
  • Experience with Postgres SQL
  • Experience with Ubuntu/Nginx
  • Experience with GitHub

Bonus points:

  • Experience with Amazon EC2
  • Experience integrating with other web apps
  • Photoshop and front-end web development skillz
  • iOS development experience

What ClearFit Offers

  • Salary between $80K and $100K based on experience
  • Snacks and drinks in our kitchen
  • Wicked awesome coffee from our new Nespresso machine
  • 15 days paid vacation per year
  • Full group benefit plan which includes vision, dental

If this sounds like something you’re interested in, contact Robert Nishimura directly at

{ 1 comment }

Three Months of CoffeeScript

by Joey deVilla on November 7, 2011


Guest Post by Kamil Tusznio!

Kamil’s a developer at Shopify and has been working in our developer room just off the main “bullpen” that I like to refer to as “The Batcave”. That’s where the team working on the Batman.js framework have been working their magic. Kamil asked if he could post an article on the blog about his experiences with CoffeeScript and I was only too happy to oblige.


Since joining the Shopify team in early August, I have been working on Batman.js, a single-page app micro-framework written purely in CoffeeScript. I won’t go into too much detail about what CoffeeScript is, because I want to focus on what it allows me to do.

Batman.js has received some flack for its use of CoffeeScript, and more than one tweet has asked why we didn’t call the framework I feel the criticism is misguided, because CoffeeScript allows you to more quickly write correct code, while still adhering to the many best practices for writing JavaScript.

An Example

A simple example is iteration over an object. The JavaScript would go something like this:

Meanwhile, the CoffeeScript looks like this:

Notice the absence of var, hasOwnProperty, and needing to assign value. And best of all, no semi-colons! Some argue that this adds a layer of indirection to the code, which it does, but I’m writing less code, resulting in fewer opportunities to make mistakes. To me, that is a big win.


Another criticism levelled against CoffeeScript is that debugging becomes harder. You’re writing .coffee files that compile down to .js files. Most of the time, you won’t bother to look at the .js files. You’ll just ship them out, and you won’t see them until a bug report comes in, at which point you’ll be stumped by the compiled JavaScript running in the browser, because you’ve never looked at it.

Wait, what? What happened to testing your code? CoffeeScript is no excuse for not testing, and to test, you run the .js files in your browser, which just about forces you to examine the compiled JavaScript.

(Note that it’s possible to embed text/coffeescript scripts in modern browsers, but this is not advisable for production environments since the browser is then responsible for compilation, which slows down your page. So ship the .js.)

And how unreadable is that compiled JavaScript? Let’s take a look. Here’s the compiled version of the CoffeeScript example from above:

Admittedly, this is a simple example. But, after having worked with some pretty complex CoffeeScript, I can honestly say that once you become familiar (which doesn’t take long), there aren’t any real surprises. Notice also the added optimizations you get for free: local variables are collected under one var statement, and hasOwnProperty is called via the prototype.

For more complex examples of CoffeeScript, look no further than the Batman source.


I’m always worried when I come across tools that add a level of indirection to my workflow, but CoffeeScript has not been bad in this respect. The only added step to getting code shipped out is running the coffee command to watch for changes in my .coffee files:

We keep both the .coffee and .js files under git, so nothing gets lost. And since you still have .js files kicking around, any setup you have to minify your JavaScript shouldn’t need to change.


After three months of writing CoffeeScript, I can hands-down say that it’s a huge productivity booster. It helps you write more elegant and succinct code that is less susceptible to JavaScript gotchas.

Further Reading

This article also appears in the Shopify Technology Blog.


Salmagundi for Monday, August 22, 2011

by Joey deVilla on August 22, 2011

Welcome to another Salmagundi — a selection of some interesting techie stuff on the web!

In his article Your Code is My Hell, all-round Ruby/Rails guru Avdi Grimm warns Ruby and Rails developers about a creeping exceptionalism that has been rearing its ugly head as of late. Many Ruby/Rails developers seem to be under the impression that simply because Ruby and Rails do a lot to make programming easier, they can simply ignore things like good coding, good object design, design patterns and the SOLID principles and all those other practices and disciplines that good coders follow and exercise. Ruby’s a great programming language and Rails is a great web development framework (and I’m quite glad to return to them), but they’re not a free pass to code carelessly!

Nick Quaranto from Thoughtbot explains why he loves CoffeeScript, by way of the movie 300, in CoffeeScript: Spartan JavaScript. “Writing JavaScript properly, and in an OO manner, requires you to be verbose,” writes Quaranto. “What I like best is that CoffeeScript is simply…spartan.” He covers the good as well as the bad (but it’s mostly good). If you’d like to try it out, visit the CoffeeScript site to get started.

Here’s another one from Avdi Grimm (he’s got lots of good suggestions — you should check his blog regularly if you’re a Ruby/Rails developer): The Procedure/Function Block Convention in Ruby. He’s got a clever idea for when to use “curly bracket” blocks (he suggests to use the for functional blocks) and when to use “do…end” blocks (he says to use them for procedural ones.

And finally, if you use Git, you’ll want to read Benjamin Sandofsky’s article, Understanding the Git Workflow. “If you’re fighting Git’s defaults,” he writes, “ask yourself why.” He suggests that your workflow should be:

  1. Create a private branch off a public branch.
  2. Regularly commit your work to this private branch.
  3. Once your code is perfect, clean up its history.
  4. Merge the cleaned-up branch back into the public branch.

This article also appears in the Shopify Technology Blog.


It’s Whyday!

by Joey deVilla on August 19, 2011

A hand-drawn copy of a comic panel from why’s (poignant) guide to Ruby on a traffic light in Austin, Texas.

It’s August 19th, which in some circles is known as Whyday. If you’re not familiar with what this day’s about or where its name comes from, you might want to read our earlier article, Whyday is Friday. I like to think of this day as a reminder to bring a sense of whimsy, sharing, fun and wonder to your work, whether it’s programming or anything else.

Jessica Allen tweeted the photo above: an expense report in the spirit of Whyday.

Roger von Oech, who wrote one of my favourite books — A Whack on the Side of the Headmentioned Whyday in a tweet today!

I must tip my hat to the appropriately-surnamed Josep M. Bach, whose Whyday contribution is Niki, “the first stable, documented version of Niki, a ruby DSL to write songs”. Programming and music — what could be more fitting?

_why’s cartoon foxes are everywhere. This stencilled graffito was found by Janet Swisher in Barcelona, which I believe is quite far from where _why lives.

Wyatt Greene, on this blog Techiferous, is celebrating Whyday with an article about programming archetypes featuring _why-esque comic illustrations. Nicely done!

Andrew Lenards, who leads “a team of developers working on a larger scientific application” is encouraging his developers to celebrate Whyday. Well done, sir!

Andrei Volkov tweeted: “I just MUST use #whyday to promote my translation of Why’s Poignant Guide to Ruby into Russian.” Keep at it, Andrei, and…spaceeba!

The RubyLearning blog is celebrating WhyDay by announcing the 8th batch of their “Ruby with Shoes” course. Shoes is a great little Ruby GUI toolkit that _why whipped up, and there’s nothing that makes learning a new programming language fun like the immediate satisfaction and feedback of a desktop app.

Gogol is a game that’s written in Ruby, minimalist and brain-teasing. This is right up _why’s alley.

As for me, I’m doing my bit to spread the word about Whyday, working on a few ideas to help people get better at programming and ecommerce (which includes making more videos like this one), mixing music with coding with the assistance of my trusty travelling accordion as well as relearning all the Ruby I’ve forgotten over the past couple of years working at the Empire and sharing what I learn along the way.

I feel incredibly fortunate to be at Shopify (I’ve been with the company a shade more than three months), away from the Fortune 50 corporate world and back in the land of startups, programming languages like Ruby and CoffeeScript, and where whimsy and the willingness to take chances and try new things is greatly appreciated. It’s been a wild and crazy year for me both personally and professionally, and it’s only increased my appreciation for bringing the spirit and sense of fun to my work in the same way that _why did. I hope Whyday does the same for you.

Happy Whyday, and happy hacking!

(If you’re doing or did something interesting for Whyday, drop me a line and I’ll mention you and your activity in an upcoming blog post!)

This article also appears in the Shopify Technology Blog.