Top Ten 2011 Albums

2011-12-28T22:45:00-05:00

Anyone who is even a little bit serious about their music listening habits puts together a top whatever list around this time of the year. I have been doing this every year since graduating college and passing it around to friends and family. This year I decided to take vacation between the Christmas and New Year holidays and I have used some of that extra time to put together this article rather than a simple ten line list.

Disclaimer: The album names in my list are links to each album's digital download page at Amazon. This is primarily part of my ploy to get filthy rich via associate referral purchase kickbacks. It also gives you a way listen to all of these records from within your browser (perhaps while you read this article?!). Most of them weigh in at $5.00 per DRM-free album, which is really great for your record collection, but not so great for my get rich quick scheme.

Having said that, you can hop straight to my list or continue reading the minutiae of my album selection process.

Empirical Evidence and Subjective Taste

As an engineer, an album lover, and an ex-college radio disc jockey, I approach my list creation process in a specific manner.

Warning: software and music nerd content ahead! You can skip ahead to the list if either makes you itch.

The most interesting approach to creating my list is probably using the custom software that I have written to analyze my album listening habits year by year. When I was in college and using iTunes, it let me rate individual tracks on a ★★★★★ scale. I developed a bit of track rating OCD, and throughout my years with iTunes I have come to revere my library's XML meta-data file. Today it is around 56MB of XML data describing more than 2700 albums.

A feature that I have always found lacking in iTunes is the sense of an album as a listening unit. When I was in college, the burgeoning portable media player market was changing popular culture's listening habits to become even more track-oriented rather than album-oriented. To this day, I remain an album lover despite the increasingly amazing listening technology that I slip into my pocket each morning. I collect and actively listen to vinyl. Similarly, I collect and consume digital media in album-sized chunks. An album is the unit of creative work that I believe good artists strive to produce. In my opinion, part of respectfully enjoying an artist's work is listening to an album in its entirety. Shuffle be damned. /rant

Saddened by iTunes' lack of album ratings and album listening statistics, I wrote an application to analyze my iTunes XML meta-data file and report my listening habits in an album-centric manner. The output of this application is a list of albums by year which can be interactively sorted by the following criteria.

Overall Album Rating = aggregate track rating / number of tracks
Real Time Spent Listening To Album in hours:minutes:seconds
Album Play Count = aggregate track play count / number of tracks

I use these different views into my listening habits for the year to form an empirical list of albums that I clearly liked either because I rated them highly or spent a lot of my time listening to them. In my head I weigh these aspects differently from year to year depending on how many albums were released that I listened to, and how much time I had spent listening to music.

After forming my initial list of around twenty or so albums in this manner I begin to rank and prune based on subjective and experiential listening criteria like:

What season of year was the album released?
What was the weather like when I first listened to it?
Where was I when I first listened to it?
What was I doing?
What kind of mood was I in?
How could it affect my current mood?
Did I see the artist perform this album live?

... and so forth. I will try to describe these factors as I describe each album in my final list.

Kris's Top Ten Albums of 2011

10. David Comes To Life

Fucked Up

A hardcore punk rock opera. Say that a few times to yourself. Then take 78 minutes and give it a listen because it's amazing. In a year when I feel like most records that I liked were on the shorter end of the spectrum (less than 40 minutes long), David Comes To Life brought it for nearly twice as long. Extra kudos for writing and performing a rock opera that just doesn't suck.

9. Tell Me

Jessica Lea Mayfield

I've liked Jessica Lea Mayfield since her previous full length, With Blasphemy So Heartfelt. I saw her perform at Johnny Brenda's during that tour and I was absolutely blown away with her performance. Tell Me is another great record from a young woman (she's 22 now) with a big voice set against a backdrop of loose guitars and some difficult subject matter. I really love the mood of this album.

8. Moody, Standard And Poor

Obits

Rick Froberg would have to play the pots and pans for me to question whether or not I dig what he's producing. Moody, Standand, and Poor is twelve three-ish minute long tracks of excellent quality rock 'n' roll that stirs an, "I'm an American, and I like rock 'n' roll, damnit!" attitude within me. Which is a great attitude to have, I believe. I was lucky enough to share a beer with Rick and John Reis at the old Khyber after a Night Marchers show years ago and I can say that they were both really cool rock gods.

7. Bon Iver, Bon Iver

Bon Iver

Everyone loved this album, right? I did too. It is a great example of an album as a work of art and not just a collection of tracks. I rarely begin listening to this record if I know that I don't have time to finish it in a single sitting. At just under forty minutes that's not hard to do, which is perhaps another reason I like it.

6. Zonoscope

Cut Copy

I liked In Ghost Colours but I didn't think it was a really great album as a whole. Zonoscope is a great album. The collection of longer (4 - 6 minute) tracks culminating in the 15 minute outro works really well. As a fan of ambient and experimental/electronic noise the last track is a particular treat for me and I got a lot of good work done while listening to this record during the past year.

5. Arabia Mountain

Black Lips

This album is a lot of fun. If you haven't seen the Black Lips play live some of this album's energy might be lost on you. They really are fantastic on stage. Arabia Mountain brings the familiar southern lo-fi punk sound of the band together with an accessible sense of melody that will be pleasantly bouncing around in your head after the first listen.

4. Tao Of The Dead

...And You Will Know Us By The Trail Of Dead

Just like David Comes To Life is a rock opera that doesn't suck, Tao Of The Dead is a concept record that doesn't suck. The last few albums from Trail of Dead have been advancing Conrad's delivery of steampunk artwork and lyrical style, which is either something you dig or do not dig. I happen to dig it and I think that this record expresses the genre in a compelling and entertaining manner. It also gets bonus points for being another big record in a year full of shorter records. Sixteen movements in D and F, and a solid prog rock revival in line with Yes and Genesis records of the past.

3. Hurry Up, We're Dreaming

M83

For me, this is one of those records released in Autumn that will end up feeling more like a record released the following Spring when I look back at it. It's a long and upbeat album and doesn't seem to fit the shorter, colder days of Winter. Despite that feeling, it has very quickly ran up my "time spent listening to" and "album rating" lists. I loved Saturdays = Youth and was lucky enough to see M83 perform that album in an intimate setting. I'm looking forward to seeing them visit the sold out Union Transfer in May, 2012 and fill that large space with this equally large album.

2. Knife Man

Andrew Jackson Jihad

For years Andrew Jackson Jihad, This Bike Is A Pipe Bomb, and Ghost Mice have defined folk punk for me. This album is a bit of a departure from their previous works in that there is a good amount of electrified instrumentation and more of a studio production feel to it. It's closer to The Body, The Blood, The Machine than Can't Maintain and it totally works. With track titles like Zombie by the Cranberries by Andrew Jackson Jihad and lyrics like, "I hate whiny fucking songs like this, but I can't afford a therapist... sorry guys, here's a solo... [queue guitar solo]" it's hard to not enjoy this album, even if you have never heard of folk punk.

1. Helplessness Blues

Fleet Foxes

I didn't enjoy Fleet Foxes self-titled first LP, though it seemed everyone else did. To be honest, I still don't really love it all that much. When I first played Helplessness Blues my opinion of the band immediately changed. The pervasive feeling of a rich, rural environment instantly appealed to my mind's eye and I can conjure vivid pictures of spaces and situations which Robin Pecknold describes. The swelling strings and vocal harmonies sweep me away. This is the kind of record that I will put on, sit down, relax and simply enjoy. I also had the pleasure of seeing them perform at the Tower Theatre from an excellent seat and it was an awesome experience. It can be difficult to recreate such an elaborate mood at a live venue but they pulled it off spectacularly thus cementing Helplessness Blues as my favorite record of 2011.

TextMate, TextMate 2...

2011-10-04T10:40:00-04:00

There has been a lot of chatter regarding a promised release of TextMate 2 this year (2011) or before Christmas (presumably 2011) and Allan Odgaard's questionable promise that TextMate 2 would be a free upgrade to existing TextMate customers. The fact remains that if you purchased a license for TextMate and then spent a few hours to get to know it, you probably loved it. I did, and I do.

The promise of a TextMate 2 upgrade was nice but after the vaporware dramedy that ensued in the years following the announcement it seemed irrational to expect it to be realized. Many people complained. Many people remained highly satisfied with the powerful features and relative stability of TextMate. Others jumped ship to explore alternative text editors.

Until very recently I fell into the highly satisfied TextMate user camp. I wasn't too interested in current developments in the text editor world. To me, TextMate 2 was a shiny thing off in the hazy distance. It was possibly even a solution looking for a problem. Its delayed release was a better source of laughs than disappointment.

TextMate met my needs day and and day out. The mailing list was helpful, and the sporadic option-click Check for updates minor fixes from Allan addressed most issues that I would encounter. The good parts greatly outweighed the bad parts.

Then, one day I got bored, and I discovered Sublime Text 2...

How to Set the Chrome Console Font

2011-08-18T19:24:00-04:00

Lately I've become a bigger fan of the Google Chrome dev channel. The WebKit Web Inspector hasn't quite stolen my heart but I can no longer claim total fidelity to FireBug and its swarms. After spending more and more time in Chrome's console I have developed a mean squint, though. The default console font is just too small for my liking. What can I say? I like big fonts, and I cannot lie.

"There must be a setting somewhere in Chrome to modify the font in the console," I thought to myself. I checked basic settings at chrome://settings. Nothing. I checked advanced settings at chrome://settings/advanced. Nope. I looked through experimental settings at chrome://flags. Nada. After an hour or so of hacking around I discovered a solution that seems to work.

Open the Web Inspector

Right click in any web page → Inspect Element

Undock the Web Inspector into a separate window

If the Web Inspector opens as a portion of the main Chrome window, it is docked and you'll need to undock it. Click the button at the lower left of the Web Inspector to do this.

Inspect the Inspector

A little meta-inspection will help reveal the CSS rules that are responsible for styling the console. The trick at this point is that Right click → Inspect Element is not available to open up the Inspector Inspector. With the first Inspector window undocked and focused, use the key binding for opening the Inspector to open a second Inspector window. On OS X, that key binding is ⌥⌘I. On Windows and Linux, it is Ctrl-Alt-I.

This Inspector Inspector can be used to learn more about the structure and styling behind the Inspector itself. In particular, I was interested in overriding the following CSS rules.

``` css

/* Keep .platform-mac to make the rule more specific than the general one above. */
body.platform-mac.platform-mac-snowleopard .monospace,
body.platform-mac.platform-mac-snowleopard .source-code {
    font-size: 11px !important;
    font-family: Menlo, monospace;
}

```

Squinting... 11px, there's the problem!

Override the styling in Custom.css

It is possible to edit devTools.css right there in the Inspector Inspector and that is a great way to test out live styling changes, as it is on any web page. The problem with this technique is that those changes will not persist. The solution is to place them in a Custom.css file located in the Chrome User Data Directory.

Once you have located your Custom.css file and you have dropped in all of your custom rules, you're done! Those changes will persist and every time that you open up the Inspector you will see your custom styles applied!

In Summary

I have focused on changing the font-family and font-size in this article but you can override anything you'd like with the correct CSS selectors. A good effort could even solarize the Web Inspector Console.

If you are interested, my Custom.css is available on github. I have chosen to bump up the font size to avoid squinting and prefer Consolas over Menlo for more enjoyable web development.

A Decade With Dvorak

2011-08-05T18:09:00-04:00

We are committed to [the qwerty keyboard], even though it was designed to satisfy constraints that no longer apply, was based on a style of typing no longer used, and is difficult to learn.
Donald A. NormanThe Design of Everyday Things

I developed an interest in the Dvorak keyboard something like ten years ago now. The exact date that I decided to go cold turkey on qwerty is fuzzy at this point, but an article entitled, "Roughly Nine Or Ten Years With Dvorak," just didn't have the same ring to it. So here I am, ten years later, still annoying my friends and colleagues when I forget to swap their software key mappings back to qwerty when I'm finished borrowing their computers.

This article addresses my experience with the Dvorak keyboard over the course of the last ten years. It does not aim to convince you that one keyboard is better than another. This is the story of my journey as qwerty keyboard user toward Dvorak keyboard curiosity, competency, and expertise.

The Curiosity

College has the reputation of being a great place to experiment. New surroundings, new friends, new freedoms, and new software key mappings are all factors in a young co-ed's formative collegiate experience.

Coincidentally, an assigned reading in a UI class that I was taking at the time was Donald A. Norman's, The Design of Everyday Things. This fascinating book would become pivotal for me as I began to notice and critique elements of design in our world. I credit it with heightening my awareness of the things surrounding me everyday, and in how I interact with those things.

The Design of Everyday Things also served as my introduction to the Dvorak keyboard. How did it peak my interest? Norman's case history made me think about the origin of the keyboard sitting right there in front of me.

The typewriter has a fascinating history. As a machine, it is a compelling engineering solution to a problem faced by all societies with written language. It has evolved from what are now nearly unrecognizable mechanical forms to the familiar skeuomorphic touch screens that many of us walk around with in our pockets every day.

The problems that the typewriter set out to solve remain similar to those which modern keyboards face. No one would consider the computers before us today to be typewriters in the classical sense of the word, but we expect much of the same from each device. We press keys and characters appear. Why has the typewriter evolved radically as a machine, yet its interface has remained comparatively consistent?

Arriving at this question probably had more influence on furthering my investigation of the Dvorak keyboard than did anything else I had come across during my research.

Constraints

Specifically, the constraints that Norman is referring to are the inherent bounds of mechanical typewriters as machines. Jamming typebars, advancing the printer ribbon, returning the carriage and advancing the line at the end of the current line are all facets of mechanical challenges that typewriters must solve. Computer keyboards need not concern themselves with such things.

By lifting these mechanical constraints from a keyboard designer's shoulders, what solution would he or she arrive at? This was one of the questions that the creators of the Dvorak keyboard set out to answer with their research and another question which truly interested me.

Typing Style

Upon first introduction to a keyboard, most people extend an index finger or two and after scanning the rows of keys in front of them, begin slowly poking away. "Hunting and pecking" is clearly the most obvious and natural typing "style" for new users. Chances are good that you may know at least one person who is not new to a keyboard yet still uses or even prefers this method.

Touch typing, typically performed with all ten digits while not needing to search for keys visually, is much more efficient than hunting and pecking. It does require that you know that keyboard through practice, though.

If you don't know any keyboard, there is little difference in typing speed among a qwerty keyboard, an alphabetic keyboard, and even a random arrangement of keys.
Donald A. NormanThe Design of Everyday Things

The interesting thing regarding touch typing is that it was conceived of sometime after the invention of the qwerty keyboard. The qwerty layout was created sometime during the 1870s by Christopher Latham Sholes. The following article is from the New York Times and was published on August 2^nd, 1888.

TYPEWRITERS CONTEST FOR A PRIZE.

A speed contest for typewriters, open to all operators using any machine having upper and lower case, under the auspices of the Metropolitan Stenographers' Association, was held last night at the rooms of the association, 208 West Twenty-first-street. Of many operators who had entered only four contestants - two ladies and two gentlemen - appeared. The matter written was dictated by a reader selected by the association. The time allowed to each writer was five consecutive minutes, deductions being made for errors.

The first prize of $25 was won by F. E. McGurrin, who wrote 479 words, Miss May S. Orr following with 476 words, and Miss M. C. Grant with 469 words. At the conclusion of the contest Mr. McGurrin gave an exhibition of writing blindfolded, making the extraordinary record of 101 words to the minute.

(Scan and text source.)

The last sentence in that article is very interesting. It is the earliest mention of touch typing that I could find. The apparent air of astonishment lends credibility to it being reported as a then (ca. 1888) recent phenomenon. It is unlikely that the qwerty keyboard was developed with touch typing in mind. Short of stenotype and chorded keyboard input styles, touch typing is one of the most efficient styles of keyboard typing.

Does this mean that qwerty can't succeed as a touch typing keyboard? Probably not. There are most likely millions of people happily and efficiently touch typing all day long on qwerty keyboards; nevertheless, this question led me to yet another.

Is a keyboard designed after the invention and widespread adoption of touch typing a better keyboard?

My Experiences After Ten Years

I've outlined how I originally discovered the Dvorak keyboard, and some of the reasons that it intrigued me. I can't pretend to be a keyboard efficiency expert, and in this article I'm not attempting to reignite the qwerty vs. Dvorak debate. There are many resources which make the claim that the Dvorak keyboard improves typing speed. Popular search engines return well over 100,000 results for the phrase, "qwerty vs. dvorak". It's easy to read all about the debate, if you'd like to.

Debate aside, I would like to express that after switching to the Dvorak keyboard ten years ago, I still love using it. Here's what I've learned.

For me, the Dvorak keyboard is more comfortable.

It's been a long time, but I can remember how sore my wrists would be after a long day in front of the qwerty keyboard. Ever since I began using the Dvorak keyboard I have not experienced a single day of wrist or hand pain related to keyboard interaction. For me, that's the most dramatic and resounding cheer that can be made regarding the Dvorak keyboard. As a professional software engineer I spend a large portion of my day typing. Freeing myself of chronic or even occasional pain is not about efficiency as much as it is about quality of life.

This is the first response I give to people who want to know why I don't use "their" keyboard.

I am more effective typing on a Dvorak keyboard.

I did endure qwerty touch typing lessons when I was young and in middle school. I had had little keyboard experience before then and I was firmly planted in the qwerty hunting and pecking camp of typing style. It wasn't until college that I began to spend significant amounts of time in front of a keyboard. Subsequently, I had relatively poor qwerty typing skills and plenty of bad habits.

Dropping qwerty altogether and focusing on Dvorak allowed me to focus on learning to touch type on an easy to learn keyboard. The process also instilled in me a satisfactory feeling of knowing that I was making an investment in myself and my upcoming profession. If I could improve my typing efficiency whilst lowering my chances of suffering repetitive strain injuries throughout my career then the sooner the better.

Additionally, I didn't have to unlearn my poor qwerty habits to learn Dvorak. The slate was clean, and beside the chore of memorizing the new layout, I saw all upside in my Dvorak endeavor.

Using a Dvorak keyboard can be inconvenient.

As is true often times for folks in the minority, simply being different can be a challenge. Until only recently when I began a new job, I had never met another colleague who used the Dvorak keyboard. That meant that if I needed to use someone else's keyboard, I either had to fall back onto my less than mediocre qwerty skills or swap the software key mapping in their OS. All popular operating systems support the Dvorak keyboard so in practice this is rarely a difficult process, but it can still serve as a point of confusion if I get up and forget to swap their key map back to qwerty.

Very few things are as entertaining to a Dvorak keyboard user than watching a colleague struggle with the mysterious effect of their clearly labeled keyboard producing incorrect characters, save for a and m. Sadistic, I know. Satisfying, nonetheless.

If a friend or colleague needs to borrow my keyboard, they are faced with a similar dilemma. Personally, I wouldn't trade these inconveniences for the improved comfort and efficiency that I have experienced throughout my years as a Dvorak keyboard user. It's a great way to keep people off of your machine, too!

Typing on the Dvorak keyboard is fun.

This is clearly subjective, but I think that the Dvorak keyboard is just more fun to use. I find that the fingers of both of my hands naturally settle into a pleasant rhythm. Each hands' fingers drum comfortably outside-in from pinky to index in an alternating left, right, left, right pattern. Rarely do I feel like my fingers stray from the home row, and when they do they are never straining to reach for the desired key.

The Dvorak keyboard makes me feel like I'm playing a musical instrument.

At first I had to practice, but now I simply play all day long, riffing and jamming effortlessly as I develop software or write prose.

The Dvorak keyboard has made me faster at typing.

Disclaimer: I was a lousy qwerty keyboard user prior to switching to the Dvorak keyboard.

I experienced a tangible typing speed increase as a direct result of teaching myself to touch type. This really had very little to do with the Dvorak keyboard and very much to do with focused determination to achieve that goal. Perhaps some of the claims surrounding the ease of learning the Dvorak keyboard were to thank, I don't know for certain.

Additionally, as a software engineer, I find little value in actually being able to type really, really fast. As a friend and colleague once created stickers proclaiming, Typing is not the bottleneck. I find all of the arguments regarding perceived or actual WPM increases to be inconsequential.

The last time I couldn't get code written as quickly as I could dream it up I was, well, dreaming.

In Summary

There is a lot of data out there regarding the qwerty, Dvorak and other keyboards. The qwerty vs. Dvorak debate gets particular attention in nooks of the Internet where geeks congregate. A majority of the English speaking world is using the qwerty keyboard in styles ranging from slow and ineffective hunting and pecking to fast and efficient touch typing.

Ten years after deciding to become a part of the minority and learn to use the Dvorak keyboard I am still very happy as an engineer and a keyboard user in general. My wrists and forearms are comfortable, my accuracy and speed are improved, and I continue to have a lot of fun each time I sit down to type.

Reference & Further Reading

Dear Family, One Year Later

2011-08-02T21:20:00-04:00

Recapitulation

Nearly one year ago, I addressed my family and friends regarding a career decision that I was about to make. A lot of thought went into my decision and the choice to share some underlying details with them publicly. I put a lot of value in my family and friends' input regarding all big decisions in my life.

Countless hours were spent then wrestling with point and counterpoint offered both internally and interactively while I tried to reign in emotions and remain objective. It was a difficult and stressful process. Naturally, I'm a very analytical thinker and I take pride in making informed, rational decisions. I challenged my pragmatism a year ago by deciding to jump into the relative unknown to see what kinds of opportunities I could make for myself.

Today, I revisit that process as I prepare to make another big decision.

Lessons Learned

Technically

Without going into too much detail, for the last year I have spent a good portion of my time and energy as a software craftsman within in a small, seed stage startup. I was the fifth employee hired and the third engineer at the time. As things evolved, we hired a fourth engineer to help fill a devops role. The IT operations requirements of that position meant that our company essentially operated with three excellent engineers creating our application and another great engineer supporting its infrastructure.

As one-third of a team responsible for software design and implementation of a brand new product, I learned a great amount. My passion for developing software which delivers an outstanding user experience meant that I naturally settled into the lead role on all of our client side code. I write naturally settled but I don't mean to underplay the challenge that this responsibility afforded me.

It was the first time I had faced such a large undertaking as the sole resource and the de-facto guru. It was exactly the challenge and opportunity that I had been seeking by making the kind of change that I had made. Arming myself with new tools, new techniques and a new understanding of what it meant to learn by loving what you do, I believe that I met and exceeded expectations set out by my team, myself and our users.

Non-technically

When I approached the startup world last year, I didn't know a whole lot about it. Looking back on it now, it is obvious that I didn't even know what questions to ask of myself or others regarding the opportunity in front of me. Over the course of the last year I've stumbled into or sought out a lot of those questions by living life on the inside of a seed stage startup. I feel like I could have prepared myself better for the decision that I had faced then but sometimes the only way to learn what you don't know is through first hand experience.

What in particular did I learn outside of the technical arena?

I need to see and understand a comprehensive business plan.

Not seeking out, consuming and believing in this document was probably my biggest and most obvious startup rookie move. I totally failed here.

I need to be able to clearly express a product vision to others.

If I can't explain what it is that I'm so passionately working on to my friends, family and peers clearly and concisely then there's a pretty good chance that it will fail. I'm sure that there are exceptions to this but I feel like it's a fairly good indicator for me, at least on a gut check level. To put it another way, I shouldn't need to be in the Empire State Building to finish my elevator pitch.

Branding matters.

Yes, there are probably some examples of successful startups with goofy names, boring colors and lame logos. To me, branding is about attracting great people to use your product and subsequently establishing trust with those users. If I'm not attracted to it myself, I find it very difficult to be the kind of advocate that a young product requires to build a trusting user base.

Marketing matters.

This was a lesson that I expected to learn. However, I think that I had underestimated the powerful combination of brand and marketing in a seed stage startup. There's a great difference between deciding to wait to market an unfinished, feature incomplete product, and not having a product vision and brand that's actually marketable until that's possible.

Compensation matters.

Here's another no-brainer, but I had never experienced a situation like this before. In an inherently volatile environment, when it gets hot and dry in the valley of death, a mirage isn't going to save you. Without a meaningful sense of ownership, or market-rate compensation, my motivation plummeted and a sense of rational discontentment skyrocketed within me.

I attempted to resolve this internally but was rebuffed. That interaction left me even less committed to a product that I didn't believe in when it really needed fanatical devotion and unwavering confidence in its eventual success to have a chance at succeeding.

In Summary

Technically, I learned a lot. Non-technically, I learned a lot. In both areas, I believe that I learned techniques, skills, and lessons that I could not have without this experience. I've grown a tremendous amount over the course of the last twelve months both professionally and personally and that has been ultimately rewarding.

Moving Forward

Reflecting on and summarizing lessons learned is always a great exercise. Exercise is great, but as Kenny Powers once said, "I play real sports... not tryin' to be the best at exercisin'." So, what have I done with all this exercise?

I've taken the last few months to play real sports on a field covering my personal and professional goals, near and long term, with all of my skills in top form. A lot of doors have opened for me as a result of that hard work and execution. At the risk of sounding narcissistic, I was nearly overwhelmed with the many great directions that I could choose to head in.

If last year I jumped into the unknown, this year I'm strolling confidently into a situation where fantastically bright folks have already found a tremendous amount of success. In just a couple of weeks, I'll start my new role as an engineer at Monetate, and I'm absolutely excited!

At Monetate I'll have the opportunity to make a big, positive impact on an already outstanding engineering culture and reach a large, diverse customer base which already trusts the Monetate product and brand. I'll be growing along with the company as it grows and expands its reach and develops more great solutions for satisfied customers.

After meeting with the Monetate leadership I developed a respect for their experiences and qualities as leaders that I can learn from and love working with. I was able to comprehend the company's vision and witness first hand a brand, product and marketing that established, happy customers trust. I will be happily compensated and enjoying some important and unique benefits while taking pride in my work, growing my skills and developing a tangible sense of ownership. I can't wait to get started!

In Summary, Part Deux

The last year has been an amazing journey for me in many ways. I feel like I've experienced great successes and disappointments and grown from both outcomes. Looking back on myself a year ago, the differences are easy to recognize. As easily recognized are the similarities; I love my family and friends, and I'm excited for the future I'm making for myself, and the opportunities I hope to create for my family.

A Piece of Cakefile

2011-05-02T00:00:00-04:00

Simplifying Large CoffeeScript Project Builds With Cake

Introduction

In my last post I described some methods for test-driving CoffeeScript development. If you caught the buzz, by now you may have a sprawling CoffeeScript codebase that is quickly outgrowing a simple

``` sh

coffee --watch --compile

```

command for production compilation and deployment... you're ready for a slice of Cake!

The Ingredients

node.js
Node Package Manager (npm)
My sample project at github, to play along at home if you'd like

You'll want to build and install node from its latest at github. Then install npm and CoffeeScript:

``` sh

$ curl http://npmjs.org/install.sh | sh
$ npm install coffee-script -g

```

Now you're ready to enjoy some Cake with your Coffee!

Note: npm just turned 1.0 and the -g flag tells npm to install CoffeeScript globally, so it is available across your projects and system. You can read more about it on the node blog post.

A Taste of Cake

In addition to being a logical progression of the classic make and rake build system names, cake borrows some familiar concepts from those systems. A Cakefile defines tasks that cake can perform, written in essentially a tiny CoffeeScript DSL.

That means that all of CoffeeScript's lovely syntax is available for use. Additionally, since cake depends on node, you have all of the power of node's API and libraries at your finger tips. That's kind of a big deal.

Organizing a CoffeeScript Project

Since I like test-driven development, I have some general project organization patterns that I like to follow. Here's a simple example:

Cakefile
/production
    /coffee-script
        intro.coffee
        MyGreatClass.coffee
        outro.coffee
    /js
/test
    /coffee-script
        MyGreatClassSpec.coffee
    /js

Note the implied ordering of the production CoffeeScript files. Logically, the contents of intro.coffee should precede MyGreatClass.coffee and outro.coffee should wrap things up. My goal is to generate a single production JavaScript file from those three CoffeeScript files, concatenated in that order before compilation. CoffeeScript's creator, Jeremy Ashkenas, has a great little example of how to do this, which I'll expand on.

CoffeeScript has a -j [FILE] command line switch that lets you easily concatenate file names in order into a single, FILE.coffee. However, if we're reading a directory asynchronously in node, even if our *.coffee files are explicitly named to fall into proper order, there is no guarantee that they will be returned in that order.

If you notice tasks or file reads occurring in a seemingly random order, this asynchronous behavior is most likely the culprit. Of course, there are methods to enforce specific ordering of events that I'll discuss below.

Cakefile Setup

In order to guarantee the proper ordering of our application's component files, we need to establish an array of those file names, iterate over them and concatenate each file's contents. To give you an idea of how I currently like to set up my Cakefile, here's what I'd call the preamble, the portion before I define any tasks.

``` coffeescript

fs     = require 'fs'
{exec} = require 'child_process'
util   = require 'util'

prodSrcCoffeeDir     = 'production/src/coffee-script'
testSrcCoffeeDir     = 'test/src/coffee-script'

prodTargetJsDir      = 'production/src/js'
testTargetJsDir      = 'test/src/js'

prodTargetFileName   = 'app'
prodTargetCoffeeFile = "#{prodSrcCoffeeDir}/#{prodTargetFileName}.coffee"
prodTargetJsFile     = "#{prodTargetJsDir}/#{prodTargetFileName}.js"

prodCoffeeOpts = "--bare --output #{prodTargetJsDir} --compile #{prodTargetCoffeeFile}"
testCoffeeOpts = "--output #{testTargetJsDir}"

prodCoffeeFiles = [
    'intro'
    'core'
    'outro'
]

```

Like any node application, I require a few modules first. Then I simply assign a few values for project-specific directory layout, coffee options for test and production code, and finally the aforementioned array of CoffeeScript files I'd like concatenated in a particular order. Now let's take a look at a task that concatenates and builds our production CoffeeScript.

Cakefile Build Task

``` coffeescript

task 'build', 'Build a single JavaScript file from prod files', ->
    util.log "Building #{prodTargetJsFile}"
    appContents = new Array remaining = prodCoffeeFiles.length
    util.log "Appending #{prodCoffeeFiles.length} files to #{prodTargetCoffeeFile}"

    for file, index in prodCoffeeFiles then do (file, index) ->
        fs.readFile "#{prodSrcCoffeeDir}/#{file}.coffee"
                  , 'utf8'
                  , (err, fileContents) ->
            util.log err if err

            appContents[index] = fileContents
            util.log "[#{index + 1}] #{file}.coffee"
            process() if --remaining is 0

    process = ->
        fs.writeFile prodTargetCoffeeFile
                   , appContents.join('\n\n')
                   , 'utf8'
                   , (err) ->
            util.log err if err

            exec "coffee #{prodCoffeeOpts}", (err, stdout, stderr) ->
                util.log err if err
                message = "Compiled #{prodTargetJsFile}"
                util.log message
                fs.unlink prodTargetCoffeeFile, (err) -> util.log err if err

```

I won't step through this code as it's pretty easy to follow. I shamelessly lifted a few patterns from Jeremy's Wiki and they have served my projects well. What you should take away from this task is that to guarantee small component concatenation order in a large CoffeeScript project, you'll need to specify that ordering in your Cakefile. It is not sufficient to hand node a directory which will ls or dir your project files in the correct order and expect them to be arranged and built that way!

For ease of development, the last task we'll take a look at is a simple cake watch task that will look for changes to our individual CoffeeScript files and invoke our cake build task when it sees them. This is the task that makes developing your project in CoffeeScript extra pleasant.

Cakefile Watch Task

``` coffeescript

task 'watch', 'Watch prod source files and build changes', ->
    util.log "Watching for changes in #{prodSrcCoffeeDir}"

    for file in prodCoffeeFiles then do (file) ->
        fs.watchFile "#{prodSrcCoffeeDir}/#{file}.coffee", (curr, prev) ->
            if +curr.mtime isnt +prev.mtime
                util.log "Saw change in #{prodSrcCoffeeDir}/#{file}.coffee"
                invoke 'build'

```

Again, this is pretty simple CoffeeScript to follow. We're making use of node's watchFile fs method to look for changes to all *.coffee files in our production source directory. When modification times differ, we are invoking the build task outlined above. With this task, you can fire up your command line and execute:

``` sh

cake watch

```

in your project's root (where your Cakefile should be!) and go on your way happily hacking CoffeeScript all day long.

A Piece of...

cake, even with the simplest Cakefile tasks, can help you organize and streamline your CoffeeScript workflow. I have tried to illustrate how cake can help bring order to your growing CoffeeScript project in a sensible and lightweight manner. A half hour spent writing a Cakefile and tweaking your project structure can mean a big return on time and effort as your project matures.

There isn't a whole lot of documentation available detailing writing even simple Cakefile tasks at the moment and I hope I've helped to fill that gap a bit with this post. If you'd like to explore more in-depth examples I'd suggest cruising github for successful CoffeeScript projects and studying their Cakefiles. There's also the brief annotated cake source that can help shed some light onto this build system.

With the power of node's API and the clarity of CoffeeScript's syntax, you've got another great excuse to love cake.

Sample Skeleton CoffeeScript & Cake Project

I've updated my earlier skeleton project for beginning JasmineBDD and CoffeeScript with some of the cake tasks and ideas described in this post. Feel free to take a look, clone/fork/etc., try it out and enjoy! My project is available on github.

P.S. - Other Cakefile Task Ideas

Integrate task success/failure messages with a local notification system (i.e. Growl). My example project illustrates this.
Create a task to minify/obfuscate your production JavaScript output. I use uglify.js in my example.
Roll your favorite JavaScript test framework into a task that executes as part of your watch task for a mini-CIT loop while you work.

Flavored Coffee

2011-01-04T00:00:00-05:00

Test Driving Client-side Development with Jasmine & CoffeeScript

Introduction

As the development of our new cloud based Social CRM system has progressed we have watched the amount of JavaScript in our repository grow. Much of this code is jQuery or jQueryUI and is entirely related to the presentation layer. There are various methods and tools for automated user-interface testing available to modern web application developers but they can feel very heavyweight.

For logic in our JavaScript code we wanted a fast and lightweight framework that can make our client-side testing as painless and enjoyable as possible. That's a tall order, and one that required a couple ingredients to achieve.

The Ingredients: CoffeeScript & Jasmine

CoffeeScript: "It's just JavaScript"

CoffeeScript's golden rule should be reason enough for skeptics to give it a shot. After a few minutes hacking some CoffeeScript and a short compilation later you'll have nicely formatted, easily debuggable, pure JavaScript. You can even throw a --watch switch on the coffee compiler so that your .coffee files are compiled into .js files as you save them, automatically.

A few things to enjoy about CoffeeScript

Significant whitespace means less {}, optional ;, improved readability and help fending off other code smells. It also means that you can clearly define more complex objects.

e.g.,

``` coffeescript

myObject =
    property: 'value'
    nestedObject:
        anotherProperty: 'anotherValue'

```

Operators which help eliminate typical JavaScript operator confusion like is, isnt and of
New Operators like ?: (Elvis!) and in
List comprehensions
Default values for function arguments
Simple class definitions- never type "prototype" again, unless you're into that kind of thing
String variable interpolation
Support for a REPL
JavaScript Lint compliant generated code

It is also worth noting that CoffeeScript is never required to be packaged, deployed or run on the client-side, however. There is never any run-time interpretation of CoffeeScript.

The expense of CoffeeScript

An extra installation step
An extra compilation step
If you choose to version compiled JavaScript, redundant files in your code repository

CoffeeScript: "It's just JavaScript."

This bears repeating because it really is the most important aspect of CoffeeScript! It means that it can be used with any existing JavaScript library. We've chosen a behavior-driven development (BDD) framework like Jasmine to make our lives easier in this case.

As a general rule, wherever you can write JavaScript, you can (more) easily write CoffeeScript!

Jasmine

Jasmine is a JavaScript testing framework that lifts great features from some other well-known and established frameworks like ScrewUnit and RSpec. It's lightweight and can be run headless in your favorite continuous integration server. Jasmine supports testing asyncronous code and has extensible reporters for custom test reports to fit your needs.

The syntax Jasmine offers is relatively simple and readable, too. But like many other robust JavaScript frameworks, multiple and nested function callbacks are the rule, not the exception. If you begin to test-drive some jQuery code you'll soon find yourself neck deep in )}; anonymous function callback hell.

Mixing in CoffeeScript's pleasant syntactical and semantic improvements can help pull us out of it.

CoffeeScript & Jasmine Taste Great Together!

First, let's take a look at a simple and small Jasmine spec written in CoffeeScript.

``` coffeescript

it 'should perform some basic arithmetic and logical operations', ->
    expect(2 + 2).toEqual 4
    expect(2 / 2).not.toEqual 4
    expect(true).toBeTruthy()
    expect([0, 1, 2]).toContain 1
    expect(['a', 'b', 'c']).not.toContain 1

```

That is very readable but it's mostly Jasmine that's responsible for that fact in this simple case, not CoffeeScript. Next we will take a look at a slightly more involved Jasmine suite aimed at testing some jQuery code to see the power CoffeeScript adds to our recipe.

Let's test-drive a bit of jQuery that updates the background color of a div on a click event. Our Jasmine suite with a single spec might look like this:

``` coffeescript

describe 'my-div', ->
    it 'should have a red background color when clicked', ->
        red = 'rgb(255, 0, 0)'
        myDiv = $('<div>').attr('id', 'my-div')
        $('body').append myDiv
        expect(myDiv.css('background-color')).not.toEqual red
        myDiv.click()
        expect(myDiv.css('background-color')).toEqual red

```

Against which we might write this passing jQuery CoffeeScript code:

``` coffeescript

$(document).ready -> $('#my-div').live 'click', -> $(this).css('background-color', 'red')

```

(Note: we're binding with the live event handler attachment in this short example because we're appending the div in our spec- after document.ready() has fired.)

Without CoffeeScript our jQuery code would look something like this:

``` javascript

$(document).ready(function() {
    $('#my-div').live('click', function() {
        return $(this).css('background-color', 'red');
    });
});

```

Not bad, but it certainly lacks the elegance and readability that our CoffeeScript one-liner has!

Now let's say we'd like to add a form with a named set of radio button inputs which update a span with the value of the selection to our div.

Our test code now becomes:

``` coffeescript

describe 'my-div', ->
    myDiv = $('<div>').attr('id', 'my-div')

    beforeEach -> $('body').append myDiv
    afterEach -> myDiv.remove()

    it 'should have a red background color when clicked', ->
        red = 'rgb(255, 0, 0)'
        expect(myDiv.css('background-color')).not.toEqual red

        myDiv.click()
        expect(myDiv.css('background-color')).toEqual red

    describe 'my-form', ->
        it 'should update selected size on radio button click', ->
            selectedSize = $('<span>').attr('id', 'selected-size')

            myDiv.append $('<form>')
                .attr('id', 'my-form')
                .append($('<input>')
                    .attr('id', 'small')
                    .attr('name', 'size')
                    .attr('type', 'radio')
                    .val('small'))
                .append($('<input>')
                    .attr('id', 'large')
                    .attr('name', 'size')
                    .attr('type', 'radio')
                    .val('large'))
                .append selectedSize

            expect($('#selected-size').text()).toEqual ''

            $('#small').click()
            expect(selectedSize.text()).toEqual 'small'

            $('#large').click()
            expect(selectedSize.text()).toEqual 'large'

```

We've refactored our DOM manipulations to beforeEach and afterEach blocks and wrapped a spec regarding #my-form only in its own nested suite. This might seem like overkill for a single spec, and it probably is, but when you start writing many specs it really cleans up the test report readability. Clean test reports make it easier to recognize and fix broken tests faster and easier, which is what test-driving is all about.

Finally, our production code under test bloats to the following:

``` coffeescript

$(document).ready ->
    $('#my-div').live 'click', -> $(this).css 'background-color', 'red'

    $('input[name="size"]', '#my-div').live 'click', ->
        $('#selected-size').text $(this).val()

```

Not bad! This was a very simple example, but I hope it clearly illustrates the potential that the combination of CoffeeScript and Jasmine have for reducing client-side testing overhead.

Enjoy!

CoffeeScript brings to the table an improved, clear syntax and some powerful semantic features over JavaScript all while remaining, "just JavaScript." Jasmine offers an elegant behavior-driven development domain-specific language for testing and the extensibility to support your working environment. Adding one to the other is very easy, and the result is just too good to deny!

Dear Family, This Is What I Do

2010-08-25T10:36:00-04:00

This post is for my mom, dad, & sister, and any other family or friends that find their way here. I have recently changed jobs, and my immediate family have all asked me, "why?" as well as, "what are you going to be doing?" In this short post, I will answer those questions.

What do you do?

I will begin with what I am. I am a software craftsman. You could call me a software engineer, a computer scientist, a developer or a coder. But I prefer software craftsman. It sounds funny, but it expresses my passion and my respect for my chosen industry and my fellow craftsmen. After all, engineers are obsessed with accuracy and attention to detail. Feel free to call me whatever you'd like to your friends and our extended family. Not being nerdy engineers, you are absolved of nerdy semantic obligations. What is it that I do, then?

All computers, and some humans, understand at least one programming language. Most computers, and some humans, understand multiple programming languages. There are many, many programming languages. If a computer and a human understand the same language they can speak to each other and do great things (aside from singing 99 Bottles of Beer). I intend to do great things! Previously, I have worked to do great things in the public and private sectors and in the defense and healthcare industries.

Why are you making a change?

Change is good. I will grow from this change. I'm moving to a new industry, finding a new way of working, and discovering a lot of new technology.
I'm hungry for some risk, and I'm in a good position to take one. Professionally, personally, and financially I believe I'm making the correct decision for me, right now.

What are you going to be doing?

As I mentioned earlier, great things! I will continue to write software but now I will be focused on providing solutions in the world of customer relationship management (CRM) and software as a service (SaaS).
Learning about the world of software start up companies and venture capital.
Finding out more about myself by defining a new way to work, in a new environment, with new technology and new people.

That's it! Well, there's plenty more to it of course, but these are essentially my CliffsNotes edition. If you click through the links I've posted throughout this synopsis you can dig deeper and get more technical details on what I'll be doing on my new adventure!

Thank you, and I love you!

How An Engineer Designs a Logo

2010-07-25T20:36:00-04:00

Let me start by saying that I don't have a formal design background. I have a couple of degrees from an engineering university and I think I can generally recognize good design.

My sister, Jacqui, does have a formal design background and recently graduated from Parsons The New School for Design (with Top Honors!). I attended her graduation ceremony in May and she now has a job on Madison Avenue in NYC. My grandfather worked on Madison Avenue for many years as a graphic artist as well. I, however, have never worked on Madison Avenue or earned a design degree. I'm hoping I have the art gene.

That should be enough of a disclaimer. The bottom line? I've got this website, and it needed a logo... Who you gonna call?

OK, so I didn't call the Ghostbusters, that's absurd. What I did do was think about some aspects of software engineering that I love. And then I called my sister and a few other capable, trained, and experienced design friends for help critiquing my own designs.

A critical part of being a great software engineer, or a great engineer in any discipline, is attention to detail. Following the spirit of software craftsmanship, I was in search of a professional design which expressed my attention to detail and passion for quality. After considering many details surrounding the writing of software (significant whitespace syntax, the Model M keyboard, recursive acronyms, etc.) I settled on perhaps an even more minute detail: font porn.

I've been happily developing using Consolas or Inconsolata and nothing else for many years now. In fact, installing either font is one of the first things I do on a new machine that I will be doing any amount of coding on. Monospaced font porn, along with the numeronym which served as the basis of my thinking while naming my site, would prove to be my design inspirations.

If you've read this far and haven't determined it for yourself yet- yes, I am a genuine nerd. OK, let's design a logo!

First things first. I needed some tools. From some recent experience designing a couple of iPhone apps, I knew that I wanted to work with vector art so my design could be scaled to fit any size requirements I may have in the future. A colleague of mine had been talking up Inkscape so I decide to give it a shot. I ended up really digging it after spending around an hour or so familiarizing myself with its UI and pen tool.

Next, I wanted to decide on a color scheme so I could experiment with color while assembling my ideas. A little poking around on the web turned up Color Scheme Designer which I found to be both fun and intuitive. I settled on an analogous green scheme, mostly because two of my bicycles are shades of green.

Colors picked out, I was ready to launch Inkscape and iterate on some ideas.

My first concept centered around explaining my site name explicitly. I liked the concept, but its realization was not something that I was happy with. Certainly a design that was so much more wide than tall wouldn't work well in many situations. Thinking of iPhone app icons, favicons, and other little badges that now litter the web from Digg, Twitter, etc., I set off in pursuit of a more square layout.

The second idea, where I introduced the brackets, was driven by a desire to express the numeronym idea in a more compact manner. It succeeded in doing so but would not scale down well at all. Liking this new concept a bit, I decided to produce some more iterations in Inkscape.

In v0, I took a very symmetric and mathematical approach and made the K and the E exactly the same width. Visually, that ended up looking a bit strange, so I slowly progressed toward column 3 where both characters became more slender, although they were both still the same width, exactly.

Rows b & c were never really candidates, in my opinion, but I extrapolated the design in row a just to make sure something cool didn't pop out at me while I was refining that concept. If I had a larger format, I really liked row b. But on a web site with smaller, low resolution graphics, it just wasn't promising.

After getting some feedback from folks with real design chops, I picked v0a1 and v0a2 to move forward with.

The v1 sheet started to look very refined and I was happy with where my earlier direction had taken me. Using Consolas, a numeronym, and a couple of common programming syntax characters {} [] led me to v1b2. I felt like this particular version was visually well-balanced and clean.

v2 - final

Tweaking the spacing and alignment while working with Inkscape's pen tool at a very high zoom level produced v2, in which I also played around with some simple color options. Once I was happy with the balance of positive and negative space in the black and white version, I decided on v2a1 as my final revision.

The end result is that I now have a distinctive logo that I'm very pleased with. It expresses my attention to detail and passion for technology in a stylishly cryptic manner. With any luck, it is also the result of my pursuit of good design.