CoffeeScript, day 1

Day 1 of learning CoffeeScript.

I won’t lie. After I’ve spent about 30 minutes so far reading up on the documentation for CoffeeScript and my head is starting to spin.

I’m trying to decode some of the syntactic sugar that CoffeeScript provides, but even one liners are tripping me up right now:

really means:

and what’s more confusing is that there is even shorthand for this where somehow:

means this:

I know that there’s going to be a lot of getting used to, but so far this is just making my head dizzy.

What I like:

String interpolation

The way I think about string interpolation is string concatenation done easier (or maybe done right? does syntactic sugar mean that it’s more right?). I suspect as I learn CoffeeScript more, there are going to be more of these “that’s cool” moments.

whose JavaScript equivalent is:


Wow…that’s neat. When used as an argument in a function it basically is an array of values. What makes it cool is that you can surround it with variables and it’ll just slurp up all the other arguments and put it into an array.

two three four

It’s like it splats together variables into an array.

sublime text editor

My favorite text editor/IDE is Sublime Text Editor.  Its full power is realized when you use Package Control. The text editor is fast, the packages yield a lot of great functionality in an IDE, and best yet, writing your own packages is relatively easy.

Yes, the text editor is not free, but it is cross-platform: Mac, Windows, and Linux, and the licensing is generously attached to the user, not the machine. That means that if you buy a license, it can be used on any of your machines.

Package recommendations:
HTMLTidy – reformat HTML using Tidy
jQuery – jQuery auto-completions
Markdown Preview – Markdown renderer to see MD in your text editor
Nodejs – node.js auto-completions
SublimeCodeIntel – fuzzy logic code completion
SublimeLinter – lint your code on the fly – my fork discussed below
Theme – Soda – alternative theme for sublime
Tomorrow Color Scheme – alternative color scheme for sublime

SublimeLinter – wilco42 fork
SublimeLinter is a fantastic real-time code linter that will lint your code as you type, but if you are writing JavaScript code, you have to pick the default linting engine. Available engines are: jshint, jslint, and gjslint. jshint and jslint are similar enough that you can just pick one of those, but there are significant differences between the gjslint and jshint engines where running one or the other won’t catch all of your violations.

My fork adds a new engine which runs both jshint and gjslint. It’s a relatively simple change which calls both engines externally and applies the result in-editor. If you feel like you want to run both linters in your IDE, give it a whirl.

biting the bullet: learning coffeescript

I have been fighting this for as long as I can.  I have never understood why so many people are raving about CoffeeScript, but there are so many companies that have made the leap, rave about it, and never look back.  That’s great and all but the idea of writing in a scripting language that compiles to JavaScript seems ludicrous.  Why not just write your JavaScript cleanly?  Why abstract JavaScript with some other scripting language?

The problem is with more and more companies releasing open source frameworks written in CoffeeScript, it makes it hard to use their work, stay current with their updates, and possibly contribute back to them without using it.  So, after months and months of denial, I’ve decided that I have to suck it up and learn CoffeeScript.  I am skeptical about the whole thing, but I’m going to commit to the project fully and write a node app with CoffeeScript.

adventures of a front end developer

Lately, I’ve been playing with a lot of cool, shiny toys and I thought that it might be about time to document my journey as a front end developer.  The landscape of a front end developer has changed dramatically over the last couple of years with exciting new technologies which has propelled the web from a collection of web pages to full blown apps.

I have the good fortune of working at a company which has embraced open source and is willing to explore and experiment with the latest technologies.  But as an early adopter, one gets to navigate the uncharted territories of use cases that other people didn’t cook up with them open sourced the latest and greatest framework/widget/platform/whiz-bangy thing.

But first, some background:  I started as a LAMP developer many, many years ago, before PHP was even en vogue.  I was mostly a generalist learning just enough to accomplish the task at hand.  System administration, Ops, DNS, Apache httpd, Apache httpd tuning, lighttpd/nginx/thttpd, haproxy…the list just goes on and on.  It was only recently that I started to shift my focus and attention to front end development.  I am, by far, still quite the novice, but I have a voracious appetite for all things client-side these days and I wanted to document my journey.

Many back end developers (and I was one of them) looked down on front end development.  It’s just a bunch of HTML and CSS with some JavaScript, right?  It’s tedious work, but not hard work, right?  Who wants to bother with that?  And worse yet, who actually thinks that this is its own discipline?  These are all beliefs I naively held until the fateful day that I made the leap from a back end developer to the front end developer.

It has been a wild ride so far, but it is the most fun that I’ve had in years.