And Then There Was CoffeeScript

Posted by & filed under Uncategorized.

First and foremost, let me say that I love me some JavaScript. It’s the first language that ever truly made me excited to tinker. I could just whip open a browser, and all of the glory of controlling web pages was mine. This became a passionate, uncontrollable obsession which led me to pursue a career and a lifetime as a web developer.

I find writing JavaScript to be extremely fun, even though it does take a bit to get over the learning curve of the “this” gotchas and global variable mess. Still, I never really saw myself learning an entirely different syntax to accomplish the same things I had already been doing. This changed when I stepped into the world of Python and saw the happiness that a little bit of syntactic sugar can bring into your life. Once I was introduced to list comprehensions, for example, I began to question myself every time I wrote a classic for-loop to build an array.

CoffeeScript allows me to keep the little language that I love so dearly, but adds a layer of awesomeness on top that can only be known through trying it. I swore I wouldn’t make the switch, but now that I have, I feel a bit like I take a step backward when I’m forced to write plain-jane JS at work. As far as code reduction, I’ve seen about a 30-40% drop in lines of code in my side projects, and that alone is worth the switch. I’ve had a taste of the Coffee, and I must say it’s good.

Knee deep in my own API

Posted by & filed under Web Dev Journal.

I walked in to some New Relic errors today that needed to be squashed. Got to love it when it’s a Monday and there’s already bugs a’ brewin! The bugs were trivial, involving mostly some fat-fingered variables and such. The majority of my day was spent cleaning up the service I’ve been working on in the back end of our site for the past month or so. Without getting into gory detail, I have been tasked to build an API for our company that manages all of the user interaction between our website and our email client. We run a fairly complex email marketing campaign that requires careful attention to things like unsubscribes, deletes, etc. Although, most modern email clients today provide some sort of GUI to manage these things, we wanted the flexibility of having the same historical data stored locally.

Even though our main site is powered by Django, we decided that since the “middleman” service would be more api oriented, that we didn’t want to be locked into the Django architecture. It was (at least we thought) a totally valid decision. The “middleman” is powered by Python, Tornado, and SQLAlchemy. I love working with new technologies and I’ve learned a lot about Python and Tornado throughout the process, but a lot of my bugs come from having to jump in and out of two different coding paradigms every 10 minutes. Moral of the story : Keep your technologies consistent across boxes if you can. When your home has a foundation, piecing it apart can be detrimental even if you think you’re doing a good thing.