Programming

If you're a developer in the Montreal area or looking for a career-building excuse to visit Montreal in the early summer, when it's at its best, you'll want to sign up for HackMTL, the Montreal hackfest where you have just a day to use the APIs from these companies to build something cool:

• Shopify (of course!)
• Atomic Reach
• CakeMail
• Context.io
• Freshbooks
• Primus
• Rdio
• SendGrid
• Status.net
• STL
• STM
• TinEye
• Wajam
• YellowAPI

It's a great opportunity to test your skills, meet your colleagues and even win prizes!

This particular hackfest -- the second one held by HackDays in Montreal -- has a theme: LOCAL + SOCIAL. The HackDays organizers have picked the APIs that you can choose from, which run the gamut from email to search to music to transit to shopping, for a purpose: to get you to develop apps that are local in flavor (useful and relevant to people in Montreal) and social by design (fostering communication and interaction between its users).

HackMTL will take place on Saturday, June 9th from 9:00 a.m. to 8:00 p.m. at Cosette HQ (2100 Drummond). We'll post more details about it as we get closer to the big day, but if you want to register, do it now!

Today, May 4th 2012, is the International Day Against DRM. As DefectiveByDesign.org notes, DRM has largely been defeated in the world of music, but it remains a problem in the world of ebooks.

A number of publishers have curtailed your rights by rigging their ebooks so that you can't do what you can with a dead-tree book: you can't freely lend, borrow, resell or donate them. Some DRM systems even firmly tie them to a specific reading device; buying a new device means buying those same ebooks all over again!

Among the things you can do today are:

• Pledge to take action on May 4th
• Put up a banner or widget for Day Against DRM (or make your own!)
• Share a link to this page on your social networks
• Start your own event for May 4th
• Read a long article by Katherine Noyes over at PCWorld, entitled It's Time to Give Digital [Restrictions] Management the Boot.

There are also a couple of Day Against DRM deals you might want to check out, including:

• Michael Hartl's Ruby on Rails Tutorial. From Friday, May 4th to Saturday, May 5th, 2012 at 3 p.m. Eastern (GMT -4) or noon Pacific (GMT - 7), use the coupon code IH8DRM to get 50% off any Ruby on Rails Tutorial product. This is by far my favorite Rails tutorial (and yes, it's 100% DRM-free). If you've been meaning to learn Rails 3.2, you don't want to miss this!
• 50% off all No Starch Press ebooks today only. Use the coupon code NODRM to get this deal. And yes, their books are DRM-free.
• 50% off all O'Reilly ebooks and videos today only. From now until midnight Pacific (GMT - 7), use the coupon code DRMFREE to get 'em at half price.

Artwork based on a Creative Commons photo by John R. Southern. Click here to see the original.

HackTO is a hackathon taking place in Toronto this Saturday, April 14th, in which developers will be challenged to come up with and implement an application that takes one or more of the sponsors' APIs and does something interesting, useful or cool -- all in the space of a few hours. The APIs that you'll be able to use at HackTO include:

Shopify will be there! Developer Relations guy David Underwood and Yours Truly, Platform Evangelist Joey deVilla, will be there to walk you through the Shopify API should you make the really excellent decision to include it in your project.

Here's the schedule for Saturday:

There are prizes! HackTO will offer three prizes to the apps deemed by our panel of judges to be the best:

• First prize: $2,000
• Second prize: $1,500
• Third prize: $500

We (Dan, Ryan, and myself) launched a small page called "I have a business idea". Check it out, if you haven't already — especially in Chrome or Firefox or Safari. Assuming you have JavaScript turned on (as most of you do), you should see some fun animations as you scroll down the page.

I have to admit that the animations that I had in my head were of a much grander scale but there was a time crunch: the site from design to implementation needed to be pulled off in two days. So how did we do it?

The design idea was to have our man-of-the-hour, Skip, put on the various hats that he'll need to wear to get a new business off the ground. Where do you even begin when you have an idea? We broke it down into a few steps with some helpful links along the way.

The steps were thought of as slides, like a Powerpoint presentation, but clearly better. As the user scrolls from slide to slide, Skip transitions from role to role.

Deciding what slide we're on

The first thing to figure out was what slide the viewer was looking at. This was the easiest part. All slides are the same height and are the same distance apart. We look for the window scroll event and then divide that by the height of a slide (plus its margin).

var slideSize = 700;
var scrollTop = $(document).scrollTop() + 100;
var newSlide = Math.round(scrollTop / slideSize);

The 100 that is being added is the margin at the very top of the page. Now that we know what the current slide is in view, we can change the state of the page and change the state of that slide.

First up is the subtle (or maybe not so subtle) background colour change to match the current slide.

document.body.style.backgroundColor = slides.eq(currentSlide)
    .children('.slide-content')
    .css('background-color');

We used jQuery to handle the heavy lifting. The slides variable is an array of all our slides. We grab the current slide and then grab the background colour from the slide content. That gets applied to the body. Just like that, the carpet now matches the drapes.

Handling the slide transitions

The next step in setting slide state was handling transitions. A slide comes in from the top or from the bottom. The animations should be different to reflect the different movement. Each slide has three states: the current (or default state), the before state, and the after state.

As we transition the slides, we set the state on those by changing an attribute:

if (oldSlide > currentSlide) {
    oldSlideContent.attr('data-state', 'is-after');
} else {
    oldSlideContent.attr('data-state', 'is-before');
}

currentSlideContent.attr('data-state', 'is-current');

If the old slide is below (or after) the current slide then it's set to "is-after". If it's above then it's set to "is-before". The current slide is aptly set to "is-current".

Slide CSS

Each slide is then made up of a number of components. If you look at the CSS, it's a little messy but you can see the different components of each slide.

#s4-1 { ... }
#s4-2 { ... }
#s4-3 { ... }

Each of those defines the current (or default) state of each slide. For browsers that don't have JavaScript turned on or don't support CSS transitions and animations, it'll just be the normal static slides. For everybody else, we set the before and after states.

.slide-content[data-state=is-after] #s4-3 { top: 400px; }
.slide-content[data-state=is-before] #s4-3 { top: -200px; }

CSS Transitions do the heavy lifting for us. As we set the state, the browser sees that the top value has changed and transitions that property smoothly over a brief period of time.

Since I knew I was going to be animating a lot of stuff on the page, I just transitioned ALL the things!

* {
    -webkit-transition: all 1s;
    -moz-transition: all 1s;
    -ms-transition: all 1s;
    -o-transition: all 1s;
    transition: all 1s;
}

Animations

We added a few small animations along the way, like the flying money on the last slide. Something fun along the way. First, we defined the keyframes of our animation.

@-moz-keyframes float {
    0% { -moz-transform: rotate(0deg) translate(0,0); }
    30% { -moz-transform: rotate(-20deg) translate(10px,10px); }
    70% { -moz-transform: rotate(20deg) translate(-10px,10px); }
    100% { -moz-transform: rotate(0deg) translate(0,0); }
}

In this case, the floating money moves the element at different points in the timeline. It rotates and shifts (or translates) the element from its current position.

With the animation keyframes defined, the animation needs to be applied to an element.

#s9-3 {
    -moz-animation: float 8s infinite linear;
}

The animation is done over 8 seconds to create a nice soft effect and loops infinitely. To have each dollar bill float at a different frequency, we just changed the animation length.

#s9-4 {
    -moz-animation: float 10s infinite linear;
}

Browser Compatibility

We used a bunch of cutting edge CSS to do this and as a result, we added all the vendor prefixes for the major browsers out there. For browsers that don't support it, it should still show the default state of the slides.

Tools

In a way, building this felt like doing animations in Adobe Flash. Elements were laid out on a canvas and then keyframes were defined for each of the elements that we wanted to animate. There are a number of tools, like Adobe Edge, that allow you to create these types of animations in a graphical way without necessarily needing to get your hands dirty with code.

My previous post RESTful thinking considered harmful caused quite a bit of discussion yesterday. Unfortunately, many people seem to have missed the point I was trying to make. This is likely my own fault for focusing too much on the implementation, instead of the thinking process of developers that I was actually trying to discuss. For this reason, I would like to clarify some points.

• My post was not intended as an arguments against REST. I don't claim to be a REST expert, and I don't really care about REST semantics.
• I am also not claiming that it is impossible to get the design right using REST principles in Rails.

So what was the point I was trying to make?

• Rails actively encourages the REST = CRUD design pattern, and all tutorials, screencasts, and documentation out there focuses on designing RESTful applications this way.
• However, REST requires developers to realize that stuff like "publishing a blog post" is a resource, which is far from intuitive. This causes many new Rails developers to abuse the update action.
• Abusing update makes your application lose valuable data. This is irrevocable damage.
• Getting REST wrong may make your API less intuitive to use, but this can always be fixed in v2.
• Getting a working application that properly supports your process should be your end goal, having it adhere to REST principles is just a means to get there.
• All the focus on RESTful design and discussion about REST semantics makes new developers think this is actually more important and messes with them getting their priorities straight.

In the end, having a properly working application that doesn't lose data is more important than getting a proper RESTful API. Preferably, you want to have both, but you should always start with the former.

Improving the status quo

In the end, what I want to achieve is educating developers, not changing the way Rails implements REST. Rails conventions, generators, screencasts, and tutorials are all part of how we educate new Rails developers.

• Rails should ship with a state machine implementation, and a generator to create a model based on it. Thinking "publishing a blog post" is a transaction in a state machine is a lot more intuitive.
• Tutorials, screencasts, and documentation should focus on using it to design your application. This would lead to to better designed application with less bugs and security issues.
• You can always wrap your state machine in a RESTful API if you wish. But this should always come as step 2.

Hopefully this clarifies a bit better what I was trying to bring across.

It has been interesting and at times amusing to watch the last couple of intense debates in the Rails community. Of particular interest to me are the two topics that relate to RESTful design that ended up on the Rails blog itself: using the PATCH HTTP method for updates and protecting attribute mass-assignment in the controller vs. in the model.

REST and CRUD

These discussions are interesting because they are both about the update part of the CRUD model. PATCH deals with updates directly, and most problems with mass-assignment occur with updates, not with creation of resources.

In the Rails world, RESTful design and the CRUD interface are closely intertwined: the best illustration for this is that the resource generator generates a controller with all the CRUD actions in place (read is renamed to show, and delete is renamed to destroy). Also, there is the DHH RailsConf '06 keynote linking CRUD to RESTful design.

Why do we link those two concepts? Certainly not because this link was included in the original Roy Fielding dissertation on the RESTful paradigm. It is probably related to the fact that the CRUD actions match so nicely on the SQL statements in relational databases that most web applications are built on (SELECT, INSERT, UPDATE and DELETE) on the one hand, and on the HTTP methods that are used to access the web application on the other hand. So CRUD seems a logical link between the two.

But do the CRUD actions match nicely on the HTTP methods? DELETE is obvious, and the link between GET and read is also straightforward. Linking POST and create already takes a bit more imagination, but the link between PUT and update is not that clear at all. This is why PATCH was added to the HTTP spec and where the whole PUT/PATCH debate came from.

Updates are not created equal

In the relational world of the database, UPDATE is just an operator that is part of set theory. In the world of publishing hypermedia resources that is HTTP, PUT is just a way to replace a resource on a given URL; PATCH was added later to patch up an existing resource in an application-specific way.

But was it an update in the web application world? It turns out that it is not so clear cut. Most web application are built to support processes: it is an OLTP system. A clear example of an OLTP system supporting a process is an e-commerce application. In an OLTP system, there is two kinds of data: master data of the objects that play a role within the context of your application (e.g. customer and product) and process-describing data, the raison d'être of your application (e.g., an order in the e-commerce example).

For master data, the semantics of an update are clear: the customer has a new address, or a products description gets rewritten [1]. For process-related data it is not so clear cut: the process isn't so much updated, the state of the process is changed due to an event: a transaction. An example would be the customer paying the order.

In this case, a database UPDATE is used to make the data reflect the new reality due to this transaction. The usage of an UPDATE statement actually is an implementation detail, and you can easily do that otherwise. For instance, the event of paying for an order could just as well be stored as a new record INSERTed into the order_payments table. Even better would be to implement the process as a state machine, two concepts that are closely linked, and to store the transactions so you can later analyze the process.

Transactional design in a RESTful world

RESTful thinking for processes therefore causes more harm than it does good. The RESTful thinker may design both the payment of an order and the shipping of an order both as updates, using the HTTP PATCH method:

    PATCH /orders/42 # with { order: { paid: true  } }
    PATCH /orders/42 # with { order: { shipped: true } }

Isn't that a nice DRY design? Only one controller action is needed, just one code path to handle both cases!

But should your application in the first place be true to RESTful design principles, or true to the principles of the process it supports? I think the latter, so giving the different transactions different URIs is better:

    POST /orders/42/pay
    POST /orders/42/ship

This is not only clearer, it also allows you to authorize and validate those transactions separately. Both transactions affect the data differently, and potentially the person that is allowed to administer the payment of the order may not be the same as the person shipping it.

Some notes on implementation and security

When implementing a process, every possible transaction should have a corresponding method in the process model. This method can specify exactly what data is going to be updated, and can easily make sure that no other will be updated unintentionally.

In turn, the controller should call this method on the model. Using update_attributes from your controller directly should be avoided: it is too easy to forget appropriate protection for mass-assignment, especially if multiple transactions in the process update different fields of the model. This also sheds some light in the protecting from mass-assignment debate: protection is not so much part of the controller or the model, but should be part of the transaction.

Again, using a state machine to model the process makes following this following these principles almost a given, making your code more secure and bug free.

Improving Rails

Finally, can we improve Rails to reflect these ideas and make it more secure? Here are my proposals:

• Do not generate an update action that relies on calling update_attributes when running the resource generator. This way it won't be there if it doesn't need to be reducing the possibility of a security problem.
• Ship with a state machine implementation by default, and a generator for a state machine-backed process model. Be opinionated!

These changes would point Rails developers into the right direction when designing their application, resulting in better, more secure applications.

[1] You may even want to model changes to master data as transactions, to make your system fully auditable and to make it easy to return to a previous value, e.g. to roll back a malicious update to the ssh_key field in the users table.

A big thanks to Camilo Lopez, Jesse Storimer, John Duff and Aaron Olson for reading and commenting on drafts of this article.

Update: apparently many people missed to point I was trying to make. Please read the followup post in which I try to clarify my point.

Octocat looks a little lost. I snapped this photo of a guy wearing a giant Octocat head while posing for photos on Austin's 6th Street during South by Southwest 2012.

There are still many developers out there who seem a bit uncomfortable with Git and GitHub. If you're one of them, these tips and tutorials mights help you learn and have fun along the way.

Githug: "Git your game on!" is this project's motto, and it's an accurate description. It's a game where your objective is to get to the next level, and the way to do that is to use git commands.

Git Immersion: A guided tour created by the people at EdgeCase. It's "learning by doing"; as the site explains, it's inspired by the premise that to know a thing is to do it.

The Git Community Book: An online, collaboratively-written book creating by members of the Git community. A pretty thorough book on Git that's also kept up-to-date. You should bookmark this one.

Mark Dominus' Git Habits: Mark's a serious long-timer on the 'net: he's been hacking on Perl since forever, founded  Kibology (anyone remember that?) and wrote Higher-Order Perl. He's sharing the way he uses Git, and it's probably a good idea to steal a few tricks from him.

Getting the Hang of GitHub: Once you've gotten good with Git, the next step is to get good with GitHub, the hosted Git service, which lets you  share your Git-versioned projects.

Let's Suck at GitHub Together: My friend and fellow BarCamp Tour member Chris Coyier (the guy behind CSS-Tricks) has a great screencast on learning GitHub.

[ This article also appears in Global Nerdy. ]

After Shit Silicon Valley Says comes Shit Programmers Say. There’s a swear word at the end, so if you’re at an office that doesn’t tolerate salty language, make like the programmers in the video and switch to headphones!

Thanks to Andy Baio at Waxy.org for the find!

[ This article also appears in Global Nerdy. ]

If you watched the WAT video that I pointed to in this earlier post, you saw some really counterintuitive behaviour from JavaScript and probably laughed and facepalmed at the same time.

A Stack Overflow user going by the handle of Ventero has taken it upon himself/herself to explain each of those JavaScript oddities, by way of pointing to the ECMA-262 standard. If you were scratching your head trying to figure out why those JavaScript statements were full of WAT, your answers are there!

[ This article also appears in Global Nerdy. ]

The Urban Dictionary definition of "wat" is "the only proper response to something that makes absolutely no sense". The concept of wat is covered a little more completely on its page in Know Your Meme.

"Wat" is also the title of a funny demo of Ruby and JavaScript oddities presented by Gary Bernhardt at CodeMash 2012, a rather unlikely tech conference -- it takes place in Sandusky, Ohio, in Ohio's largest indoor waterpark. (If you just said "wat" right now, you've used the word correctly.)

In the video, you see this classic wat bit about undefined variables and assignment in Ruby:

You'll also marvel at the way JavaScript treats (array + array) vs. (array + object) vs. (object + array) vs. (object + object):

Watch the video, and wait for that final slide, which is pure, hilarious wat!

[ This article also appears in Global Nerdy. ]