5 Reasons Front-End Developers’ Lives Are Shorter

Photo Credit: Chris Fleming

The greater the applied stress range, the shorter the life. –somewhere on wikipedia

Maybe it isn’t a proven scientific fact, but it is common knowledge that front-end developers deals with way more stress than back-end devs do.  These people, working with CSS, HTML, JavaScript and all that is contained in a web page are becoming increasingly jealous of their back-end counterparts’ quality of life.  Here are the top 5 reasons why:

Compile time (or lack of)

This an outstanding source of stress.  When you burst out a big chunk of code, you guys hit F5 and see the result, right?  Not working? Get back to work.  Now.

Back-end developers can always rely on compile time (or more contemporarily, build time) to relax a bit.  They can soothingly peek at their EVE online character skill training queue, answer a couple of tweets, or practice their vi kung fu.

Source code management

In my experience, front-end devs aren’t at ease with SCM (subversion, Git, etc).  That means when there’s a fire, a hard drive failure or a giant dinosaur spits fire on your laptop, you lose everything.  Sure, there’s a copy on the server, but that’s not how you do things (and what if the dinosaur also ate the server?).  Lots of time lost here, lots of stress.

Web standards

Web standards are a good thing.  But web standards, as they are advertised right now, are a real joke: you still rely on browser maker’s willingness on implementing them.  You still have a lot of tweaks, hacks, and duplicated code to craft.

Standards for back-end programming (JEE, SOAP, SQL, to name a few) are well defined, and mandatory.  The developer can lean on them and blame the product company which failed to implement them correctly (and get congratulated for it because you earned your company free support time).

Have you ever tried calling Microsoft, and open a support ticket for that unsupported CSS thing in IE?

The look

Even the worst snippet of C++ code, if it works, isn’t judged by anyone.  Why?  Nobody understands it. Nobody gets to see the actual code, it’s all 1s and 0s.

On the other hand, you front-end guys have to deal with the judging eyes of everyone in the company.  You have to take all the “Meh. I still don’t like that turquoise” … even if it ‘s the best darn piece of code you ever wrote!  You literarily get stripped of all your intrinsic self-worth.

View source

What if you were in a crowd (a big one, think Tahrir square), and someone removed all your clothes.  Nobody would like that, unless you’re sexually deviant.  That’s what happens when some guy does a right-click -> view source on your code.  Guilt, doubt, fear.


I fear for you guys.  Really.  I could suggest a couple of COBOL books, or Java certification classes, but if you already have a couple of years of experience behind you, I guess it’s a little bit too late.  What might help is if you try yoga, tai-chi, or as a last resort you could try the essential works of Yanni.


Back-end developer.

A Boilerplate for HTML5 Awesome

Photo Credit: Ara Pehlivanian

At SXSW 2009, Paul Irish showed me his initial work on HTML5 Boilerplate and asked if it was something I would be interested in contributing to. It was a no-brainer to say yes. I was thinking about creating something similar myself (as I’m sure you were too!) We quickly ramped up production and released it to the wild about three weeks ago.

HTML5 Boilerplate is a compilation of best practices that would help any web developer get started on their code. It also catches some of the stuff developers usually miss when in a hurry to meet deadlines (e.g. print and mobile styles, making sure www and www-less domains redirect correctly, getting servers to serve the right content types for new or relatively unknown file formats and having a backup for jQuery in case the CDNed jQuery fails).

I heartily recommend that everyone delete some of the things that may not be applicable to their production environment, like if you don’t write unit tests, you may not want to use the unit test suite. You’re allowed to pick and choose!

Boilerplate is made up of snippets from all over! And they’re all documented! Here are some of the goodies you’ll find:

  • Use of the new HTML5 elements without worrying about cross-browser compatibility.
  • Optimal caching and compression rules for better webpage performance.
  • Mobile browser optimizations.
  • Build a better experience for all users with feature detection.
  • A ready-to-use unit test suite.

It was great fun to work on this project because we had to think several times before including or deleting a snippet. We had to rationalize the existence of each. I also spent hours testing on several mobile browsers to check how the default mobile styles were rendered.

We aren’t done yet though, Paul is working to get a build script going which would automate some of the recommended performance best practices. Others have pitched in with WordPress and Compass ports. I makes me very happy to see so many people rallying behind it and contributing!

So, go have fun with Boilerplate. I bet you’ll have a brilliant insight or two, so feel free to fork and tinker with it!

FYI, the project is in the public domain, so you really can do whatever the hell you want with it :)

Humor Through Comments

Photo Credit: Anders Rune Jensen

Over the years, sale I’ve developed some rather strange code commenting habits. While many of my comments have become second nature as I code, troche every time I join a new team they raise some questions. For the most part they are intended to be both humorous and informative, and but many have evolved over the years into inside jokes that require some explaining.

It All Started with Bananas and Idiots

My penchant for humorous code interjections started at one of my first programming jobs. The team worked with a few tools that threw warnings when functions and classes weren’t commented. So, we used the age old practice of adding the following comment:

//Banana banana banana

It kept our coding tools from throwing warnings and it was easy to find when we got around to commenting our code. Not long after learning the banana technique, a fellow programmer added a comment referring to ID10t errors. Unfortunately for the programmer, the client actually looked at the source code and was not fond of being called an idiot. These 2 experiences led me to create my personal rules of humorous code commenting.

The Rules of Humorous Commenting

  1. All comments should be useful, even humorous ones. Adding funny but useful comments is a simple way to lighten the mood. Adding useless comments will just annoy your fellow developers.
  2. You never know who will look at the code, so keep the comments clean. More Monty Python; less George Carlin.
  3. Save the funny comments for compiled code. Inside jokes are great, but you don’t need to push tons of technology humor on your users.

Now that you know the rules, here are some examples of comments that I use on a regular basis.

// Mostly Harmless
Used for code that might appear to be a security risk at first glance. A good way to let your fellow devs know that the code is secure.
// Abandon hope all ye who enter here
A notice that the following legacy code will probably take you days to figure out.
// I Call Shenanigans
Denotes code that is in place to prevent injection, xsrf attacks or other security trickery.
// You are here
Reminds me where I left off in a particular code file. Very useful when pulled into a random meeting or leaving something un-finished before the weekend.
// He who breaks the build shall pay a penance of donuts
Placed at the top of the main file or index file to remind devs what happens when they make me stay late to clean-up.

This is a Joke Right?

In reality, introducing some humor into your comments can have several benefits. It not only helps lighten the mood a bit; it also creates an atmosphere that encourages commenting your code. Finally, having a few inside jokes can help bring your team together, so get out there and have fun commenting your code.

Web Development with Curiosity

Web Development is a strange field. This is where, to use a weary metaphor, 1 + 2 will equal 3 today and 5 in six months (or other values based on which browser implements what). The specifications that browsers standardize on are in rapid and heavy development today, and browsers outdo each other in the race to implement the specifications as quickly as possible. This means that, unlike in other fields, self-learning is mandatory.

What I find perplexing is how often we outsource this learning to others. Many developers do not use certain standards because well-known experts have not expressed an opinion on it. Sometimes, unstable features find popularity because experts have explicitly endorsed them.

More troubling is that very few people take the time to read what the specifications say. Even Google ranks Sitepoint’s Reference, and W3Schools’ website higher than the actual standards when searching for CSS/HTML properties (and for a beginner, it is hard to know that the former two websites have nothing to do with the official standards body.)

Browser vendors too have a vested interest which is not immediately obvious to us. Vendors introduce vendor-prefixes for their own benefit and a few of these prefixes get into the specifications. But many of us are not aware of which vendor-prefixes have been implemented because they feature in drafts of upcoming standards and which exist because they fulfill something unique for that browser. This sometimes leads to frustration with browsers that do not implement the popular vendor-prefixes of another browser.

There are several outcomes as a result of this:

  • Unstable/undesirable features get used quickly, leaving browsers with backward compatibility issues.
  • We are not aware of the full impact of our choices on our web development environment in the race to use the latest and greatest.
  • Useful features of standards remain unnoticed for a long time, because very few developers hear about them.
  • It takes a long time for the common feature requests among web developers to bubble up to the Standards body, as they are unaware they can raise suggestions to the W3C.
  • Websites become harder to maintain because choosing to use specifications that have inconsistent implementations among browsers leads to more work (or sometimes such choices can make content inaccessible).
  • Web developers develop superstitions about browser vendors and web standards that are hard to alter (e.g. the poor opinion about Internet Explorer means, even when IE attempts to do something well, the IE team receives brickbats).
  • Browser vendors seem compelled to implement similar features as that of the competition because some web developers find it interesting, not because they are useful.

I think, given the pace of development of standards, web developers need to be more curious: investigate, and learn about standards to make it easier to apply and contribute to them (Ben Schwarz talks about it too in his presentation Take back the web). There are many ways to do it. The following have always worked for me:

  1. Code, code, code. There is no substitute for practice. Instead of trusting someone else to test a standard, do it yourself. Check if it works within the restrictions you have or the environment your website needs to work on. Some features are implemented such that they slow down the rendering of a page, and if your website requires high performance they will not be appropriate. Some only work with some special caveats. Know the caveats as there are very few free public resources mentioning them.
  2. Review upcoming standards. Not all properties are supported consistently across browsers. We should find the limitations, as well as equivalent substitutes for browsers that do not support them.
  3. Refer to the guidelines from W3C. It helps to actually read helpful documents the W3C has published for web developers (e.g. HTML: The Markup Language and HTML5 (Edition for Web Authors)), and ask the experts about content that is not clear. Most of them are happy to help (provided you show that you have done your homework and ask specific questions). Remember, the intent of any implementation is lost while reading a “simplified” version of it. For CSS, individual browser documentations are also useful.
  4. Subscribe to the W3C mailing lists. Browser representatives and people who implement the W3C specifications talk about edge-cases and debate on specifications here. In particular, www-style and public-html-comments are two lists where you can comment on the CSS or HTML specs respectively.
  5. Learn to love the bug-tracking systems for browsers. If a standard behaves inconsistently despite following the specification, you should check Bug trackers for Mozilla, Webkit, Chrome, and IE 9 to see if it is a known bug (IE has also released IE Standards Support Documents, that details IE support for various web standards).
  6. Read what other people are learning about. Paul Irish has a list of 200 front-end development feeds to subscribe to. If this gets in the way, cull the blogs you follow.
  7. Interact with other web developers. Go to your local Web Design meet-ups and do not feel afraid of asking questions that you think sound stupid, because, if you had that doubt, it is highly probable that someone else had that question too.
  8. Always ask why. Why is there border-radius? Why do we need HTML5 form elements? Why Canvas? Knowing what caused standards bodies to approve property/element is useful as it gives an insight into where they are most useful, how they can affect your web development process and what to look out for.

We are at the edge of yet another big push to what it means to develop with web standards. Instead of waiting for other people to tell us what is best and what is not, I think it is important we do that for ourselves. Be curious, be free!

How Ableton left the back door open

Introducing Ableton and Control

Ableton Live is a loop-based software music sequencer and DAW for Mac OS and Windows by Ableton. The operator works with many forms of audio, ampoule instruction, and and programming. Audio data  such as *.wav, *.aif(f), *.mp3 files. Instructions via MIDI and Max (and Max for Live), and APIs (Application Programming Interface) for various types of communication.

The graphical user interface is logical, offering grid type organization and a timeline. Each of which can operate independently or in unison. In the past few years, Ableton has gained maturity as a platform and has become recognized as an interface that plays well with others. Some of the contemporary programs that operate in conjunction with Ableton include Reason, Serato, Traktor, Max, plus MIDI and beyond.


“Controllerism is the art and practice of using musical software controllers (e.g. MIDI, OSC, Joystick, etc.) to build upon, mix, scratch, remix, effect, modify, or otherwise create music, usually by a Digital DJ or “Controllerist”. (wikipedia)

Ableton Live is a controller(-ism) heavy application communicating via MIDI bi-directionally to provide both control and visual feedback (such as turning LEDs on and off relative to the current state of the GUI).   Ableton Live (version 8) introduced a new level of native control with the Akai APC40 and soon after the Launchpad by  Novation.

Both of these devices allow for absolute and relative mapping of control for audio and functions inside the Ableton environment.  These products mark the introduction of consumer level relative mapping as a element of native control (via API) in Ableton. To understand relative mapping it is important to understand how it compares to absolute mapping.

A Dichotomy of Control :  Absolute versus Relative

Mapping is how you define the relationship of a controller, often hardware, to software such as Ableton.

It is common to find hardware and software are mapped in an absolute or static fashion.  Using a piano as an example, the keys are the controller and they are absolutely mapped to the notes.  There are 88 buttons/keys triggering 88 sound/notes allowing you to access all of the sounds in the piano.

In the above image all of the notes would be accessed because we are using 1 button/key for each note in the piano system.

With relative control we still have 88 sounds/notes on our piano but only 14 buttons/keys.  To access all of the notes we need to introduce the concept of a focus (area) and navigation. We dedicate 12 buttons/keys to playing notes in our focus area. The 2 other buttons/keys are used to navigate the focus area to the left and right putting the notes available in the focus area where button/key #1 always triggers the sound/note directly below. The sound/note changes as the focus area moves. The next 2 images show the same piano buttons/keys under our focus area where we move to the left and right to gain access to more  notes.

The above image shows us our focus area (the bright spot) over the keys while the next image shows the position of the focus area after it is moved (navigated) to the left a few notes on the piano.

It would be rather difficult to play some Mozart with only 12 notes accessible at one time, but this very helpful in Ableton where hundreds of clips of audio are ready but only 10 or 15 may need to be used at any given point.

Take a look at this  video on YouTube demonstrating the APC40’s interaction with Ableton.  There is a red box on the computer screen showing what clips are in focus and directly correspond to the buttons on the controller. This is a relative map representing Ableton information that the operator puts in focus through methods navigating the “red box”.


Relative control, the ring, or the “Red Box” is the game changer.  Suddenly an Ableton performer can quickly and easily work with huge canvas of audio data. An entire evening’s program (or even a life’s worth of music production) can be contained in an Ableton set and performed using this type of relative control and navigation.

This mapping and navigation introduced new ideas, modes of expression, and organizational patterns.  There was one problem: access to this advanced control was pretty fuzzy as only the APC40 communicated at this level (on the Python.org site this API implementation if referred to as “experimental”). It was not looking good when you consider that the Akai APC40 and the Launchpad were explicitly a collaboration between the closed Ableton system  and Akai / Novation.

Or so we thought

In May of 2009, the APC40 is released and opened the doors to new ideas in performance and audio control.  The APC40 and Launchpad quickly gained a de facto status as controllers in various circles of music production and performance.  These controllers are fundamentally solid and easy to manage via a plug and play environment.

Personally, I got bored using my APC40 and 6 months later I purchased a Livid OHM64. Fast and slick, the OHM64 was low latency, infinitely programmable, and exactly what I needed. But no red box.

With a fancy new OHM64 delivered to my doorstep I soon began to miss the red box. Buyer’s remorse, possibly, but missing this element led to new and exciting possibilities elsewhere in Ableton.

Moving on with my work it was May 2010 when the folks over at Max4Live.info released the script to interface the OHM64 to Ableton with the “Red Box”, relative mapping capabilities with navigation.

Control via the API was now in the process of being mapped and documented.


Ableton is a smart company and provides access to this control and navigation by means of a folder called “MIDI Remote Scripts”.  This script folder is an Ableton API written for Python scripts that is slowly getting cracked open despite having no access to debugging scripts in Ableton.

So we celebrate as the resources grow yielding tutorials, documentation, forums, code, and hacks.  For many electronic musicians, music producers, DJs, and Ableton artists this is a very exciting time.  Stoke the fire of excitement even further as “The Bridge” should release soon making the line between DJ and other electronic music  freshly blurred.


The exact thinking behind Ableton leaving the door open to advanced control via a Python API is not totally clear.  For those interested, start your journey at the Python site where there is an Ableton listing. Regardless of the exact reason, thanks guys! The controller-ism genre is growing rapidly as large and small companies are supplying the market with new controllers, quality ideas, and the knowledge necessary to introduce a new type of instrument and professional. The luthier of electronic music control is rising where custom solutions, made to order control, and experimental variations are available.

Ableton as a program added mass to the controller idea for just showing up. Now they left the door to the Python API open allowing things to get crazy.

Enjoy the ride and don’t forget about all the hard work that preceded our glorious mastery of audio and technology. More to come and thank you.

You Don’t Know Mobile

Photo Credit: John Resig

John Resig isn’t your average developer. He created the jQuery JavaScript library. He’s a former evangelist at Mozilla Corporation and currently a tools developer there. He travels and speaks regularly and he’s an author currently working on his second book, “Secrets of the JavaScript Ninja.”

I recently had a conversation with John about the work he’s doing in the mobile space. Here’s that conversation for your listening pleasure:

Download the mp3 or ogg.

We Value Your Privacy

They say truth is stranger than fiction.

One afternoon at a now defunct payment processing company, while moving my coding fingers as quickly as possible, the programmers’ farm erupted in exclamations of “check your mail!” and gasps of terror.

An email had been sent to everyone in the department. It contained an attachment that clearly laid out our main (private) database schema in a much more clear manner than anyone had ever managed to document internally.

The mail’s body read like a ransom note. I don’t remember the exact words, but the gist was “Your web application is full of holes. I’ve exploited your code, and I’ve attached proof in the form of a schema diagram. If you don’t send me £50,000, I will start exploiting your customers.” It went on to give detailed instructions on how to pay our new extortionist friend.

We knew the problems were there. SQL injection as far back as CVS could remember. Most of us wanted to plug the holes, but we were never given the opportunity to do so. We attempted to take the opportunity a few times, but were unsuccessful in convincing management that a “trivial” problem like SQL injection could ever be more than an inconvenience.

As soon as this horrifying realization set in, we low-on-the-corporate-hierarchy-programmers gathered together and started forming a plan for how we’d crush these problems. We’d fix the low-hanging fruit first, and then we’d systematically go through the rest of the code to rid ourselves of this plague, once and for all. A back-of-napkin plan was in place within 15 minutes, and we dutifully started a commit storm of heroic measures to save the company.

By then, the news had trickled up to the CEO. We expected him to be livid, but we all knew there was no time to worry. We’d called our families and cleared our social calendars. It was time to pull an all-nighter; maybe two.

There was no yelling. No immediate firings. No faux-motivation speeches. Instead, the CEO (who normally had a short fuse) feigned tranquility and gathered the entire audience of the aforementioned email together for a short but simple talk.

“I understand you’ve all received a disconcerting email regarding the security of our systems. I want you to know that this situation is under control, and it requires no action on your part. Go back to your normal duties. None of you are to ever speak of this outside of this room. If you are caught doing so, you will be terminated immediately. The NDA you’ve all signed will see to easy termination, should it become necessary.”

No one ever asked for my help in wiring £50,000 to Russia, and that was the last any of us heard of this particular problem. If the company hadn’t flopped a year later (presumably due to unrelated circumstances), I’d expect those security holes to still be in play.


I am a person. I am interested in technology. I have a website at http://csarven.ca/. I know the person at http://tobyinkster.co.uk/#i.

We rely on a shared agreement of the vocabulary above i.e., what it means to be a type of thing, to have an interest, a website, and knowing some other thing that’s a person. It allows us to have an absolute frame of reference to things in order to make sense of our world.

This framework is pretty close to how we explain our world to machines.

Enter Resource Description Framework (RDF).

RDF is a general-purpose language for representing information in the Web. Uniform Resource Identifier (URI)s provide a generic way to identify the things we talk about, as well as for the relationship between them, at different sources. The relationships are conveyed using precise vocabularies. We can reuse, create, or mix any vocabulary to make statements about things. The Hypertext Transfer Protocol (HTTP) is used as the retrieval mechanism.

For example, “the thing at this URI is a type of person” can be stated like this in RDF, using the Friend of a Friend (FOAF) vocabulary:

<div about="http://csarven.ca/#i" typeof="foaf:Person"/>

Not only does this let any entity to make a statement about something else, all sorts of data can be discovered and used in various ways. By creating structured statements about our world and linking to global data, we essentially create a scalable Web of Data.

Hence, semantically Linked Data leads the Web to its full potential.