Sublime Text Editor and CoffeeScript

If you use Sublime Text Editor, there are a couple of nice plugins that will help you along your journey.
sublime-better-coffeescript is a fork of the original Sublime CoffeeScript plugin. It provides you “syntax highlighting and checking, commands, shortcuts, snippets, watched compilation and more.”

sublime coffeescript

Watched compilation
Most of the features, you take for granted, but the interesting feature for me is the watched compilation. This means that if you save a CoffeeScript file, it will automatically compile it to JavaScript for you. This has been pretty handy when you start learning CoffeeScript.

Just write some CoffeeScript, save it, and check out what JavaScript is compiled. It sheds some insight on the syntax when you are just starting to learn CoffeeScript.

CoffeeScript, day 2

Day 2 of learning CoffeeScript. It’s a short day today, but I learned a couple of things.

The Good

Same name key-value pairs in defining JSON

When you are defining JSON, there is some shorthand available to you when the name of the key is the same name as the variable for the value of the key.

is the equivalent to:

The Bad

Soaks

My initial reaction to soaks is…ugh. Syntactic sugar is one thing, this just feels like it can be easily abused or make the code harder to read. So what is a soak?

A soak is a special case of the existential operator.
For example:

This code means, set a equal to b (if b exists), else set it to c.

A soak is a chainable existential operator where as far as i can tell whitespace also matters. Suppose you want to set a equal to the name property of b if it exists, else set it to c. In JavaScript, something like that would look like:

but if you use soaks, you can shorten it to:

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:

Splats

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.

Output:
one
two three four
five

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.