CoffeeScript in Sublime Text on Windows

I work on both Ubuntu and Windows, and just recently switched to the Sublime Text 2 editor, which is a nice cross between TextMate and vim, and runs cross platform.  Everything runs as expected on Ubuntu, not so much on Windows.  Here’s what you need to do to get CoffeeScript highlighting and building:

1. Install Node using the new Windows installer.  This also installs npm.
2. Open a cmd window
3. Install CoffeeScript as you would normally: npm install -g coffee-script
4. Reboot - all should be loaded into your PATH variable correctly
5. For highlighting, git clone jashkenas’ coffee-script-tmbundle from GitHub into C:\Users<User>\AppData\Roaming\Sublime Text 2\Packages\CoffeeScript
6. At this point the building doesn’t work.  Open up the build file: C:\Users<User>\AppData\Roaming\Sublime Text 2\Packages\CoffeeScript\Commands\CoffeeScript.sublime-build and have it look like the following:

{

  "shell" : true,
   "cmd": ["coffee","-c","$file"],
  "file_regex": "^(...*?):([0-9]*):?([0-9]*)",
  "selector": "source.coffee"

}

Essentially you need to remove the “path” variable that’s there and add in the “shell” variable set to true so it runs from cmd.exe.

Knockout.js

I just finished my first non-trivial web app that leverages Knockout, a framework that helps you build better javascript front-end applications.  While Knockout isn’t nearly as popular as Backbone.js is, I think it serves a different purpose, even though they’re typically lumped together.  There’s a great set of answers on Backbone vs Knockout on StackOverflow about this, but the fact that a post like that exists proves the point.

For me, I picked it because:

• I only wanted to add functionality to a single page of my application, rather than build an entire single-page app.
• The data-bind attributes are a little ugly, but expressive at least.  So I think it’s easy to read the HTML and understand what’s going on without even really looking at the javascript.
• Accomplishing most things in Knockout requires less code than Backbone.

I wanted to improve the performance of a search page.  Essentially the functionality allows users to search for products from a number of vendors based on the location of that vendor.  So, for example, “Show me all instructors offering tennis lessons in the Boston area.”  The results page would then be broken down by instructor, and a list of their offerings in that category.

Here’s what I implemented in Knockout:

• Search results load on demand via jQuery json calls to the server.
• I aggressively cache data using local storage. In this case I used store.js from Marcus Westin to simplify browser compatibility.
• With the caching, I intercept updates to the UI by hooking into the Knockout subscribe and only loading data via ajax that isn’t already in the cache.
• Local storage also saves the current state of the page if you’ve already saved items in your cart.  We don’t have a need to save cart information on the server, so local storage made sense.  If you clear your cart, it will also clear the cache next time you visit the page to make sure you get the most updated data.
• Data is submitted via a hidden form field, similar to what Steven Sanderson lays out in his post.
• All written in CoffeeScript, of course.

Two things worth pointing out that helped me:

1. First, Ryan Niemeyer’s blog Knock Me Out has a great set of posts on Knockout.  Start with 10 things to know about KnockoutJS on day one, but explore from there.
2. Second, surprisingly enough was reading the Knockout source code on Github.  I think javascript is incredibly hard to follow because of it’s prototype nature, but this helped me figure out some additional things that just aren’t covered in the Knockout documentation.

In Support of Code Reviews

Ok, its tough not to laugh at this post from Ayende. He’s going through the process of trying to hire someone for his team, and asks those who apply to complete some simple programming tasks. I’m sure he’s glad he does.

But how did this happen?  How did someone write code this bad?

Let’s make some assumptions.  I think Ayende wouldn’t have wasted this person’s time as well as his own if the person didn’t pass at least an initial resume review.  That means they probably have a base level set of experience:

• The developer probably has some degree in a computer-related field.  Maybe a B.S. in Computer Science.  Maybe even a higher degree.
• I don’t believe he’s hiring at the entry level, so this developer has probably worked at least a couple years as programmer in a paying position.
• Applying for a .NET/C# job here means this person feels most comfortable in that language.

This should give them every opportunity to become a valuable contributor as a programmer.

From looking at the code, however, we can tell they really only know:

• In ASP.NET Webforms you can bind an event to a button click.
• How to pass a hard coded sql query to a database connection and get query results back.
• That wrapping your code in a try/catch block keeps your code from crashing with an ugly error message - especially if you don’t bother writing the “catch” part.

In other words, just enough to squeeze by if no one ever looks at your code.

Compile this application and put it up for your (non-technical) manager or client to review and everything works fine.  No one tells you it’s bad, so the next time you have to build something similar, you do the same thing again.  It’s all you know. Without code reviews, I imagine a developer could go years thinking they’re building up their resume, only to be disappointed the first time someone actually does dive deep into their work.

Now, this might be a blatant example, but there are more subtle ones everyday.  If you’re a programmer, do yourself a favor find a coding buddy if you haven’t already.

Visual Studio buttons for Mercurial

I prefer using the command line myself, but as a shortcut, via Rob at TekPub, here is a great way to use Mercurial through Visual Studio without cumbersome plugins:

1. Install TortoiseHG
2. Open Visual Studio
3. Click Tools -> External Tools…
4. Click Add
5. Create each one of the items below:

Title: HG Workbench
Command: C:\Program Files\TortoiseHg\thgw.exe
Initial Directory: $(SolutionDir)

Title: HG Add Remove
Command: C:\Program Files\TortoiseHg\hg.exe
Arguments: addremove —similarity 100
Initial Directory: $(SolutionDir)
Check the box to Use Output window

Title: HG Commit
Command: C:\Program Files\TortoiseHg\hg.exe
Arguments: commit -m “”
Initial Directory: $(SolutionDir)
Check the box to Prompt for Arguments

Title: HG Pull / Update
Command: C:\Program Files\TortoiseHg\hg.exe
Arguments: pull -u
Initial Directory: $(SolutionDir)
Check the box to Use Output window

Title: HG Push
Command: C:\Program Files\TortoiseHg\hg.exe
Arguments: push
Initial Directory: $(SolutionDir)
Check the box to Use Output window

Then, you’ll see these items show up in your Tools menu.  To take this a step further and add clickable buttons to the Visual Studio toolbar, do the following:

1. Right-click on the Visual Studio menu bar area, and click “Customize” at the bottom
2. Under the Toolbars tab, click “New…”
3. Add a new item titled “Mercurial”
4. Click over to the “Commands” tab
5. Select the “Toolbar” radio button
6. Select your new “Mercurial” toolbar from the dropdown
7. Click “Add Command”
8. Add each of the External Commands (one by one unfortunately)

There you go! You should now see a new toolbar with your icons.  Once you have the project loaded, you can click any of those buttons to provide shortcuts to the Mercurial commands as if you were doing it at a command prompt in the root of the Solution folder.

Screenshots below:

New project for A Wider Circle

This is the first in a series of posts on an application I’m developing in collaboration with my good friend Kevin Vess for A Wider Circle, a non-profit based in Washington, DC.  He’s doing the graphic design and front-end work, including all the javascript/jQuery goodness, and I’m focusing on the backend.  The application we’re building is a web-based dashboard/CRM that will manage the day to day of their operation. We’ve open sourced the code and posted to a public repository on BitBucket.

As of this post, the current changeset is c0c20f1cb422.

This post covers some high level architecture decisions so you can get a better feeling for the parts involved:

• .NET Framework 4.0
• ASP.NET MVC 3
• Entity Framework CodeFirst (included in EF 4.1 as of this post)
• SQL Server 2008 for the production database
• Eventually SQL CE 4.0 for the development database and possibly Session storage
• NLog for logging functionality
• Ninject for dependency injection, including Ninject.Web.MVC
• NUnit for unit testing
• Moq for mocking in unit tests
• ValueInjecter for mapping of domain entities to viewmodels

For convenience both for myself and anyone using the code, all of the external dependencies have been placed in a /libs folder off the root of the project.

The requirements for this project have come from the personal involvement Matt Hodgson has had with the group and the work he’s been doing there.  We have a PowerPoint document with some preliminary requirements.  Enough to give us an overview of what the system should do, and further refinement will come as we tackle each section.  I’ve also spent a bit of time with them, and therefore have a good feeling for how they run things.  More posts coming to break down each of the sections and features.

Also, we’ll be keeping the BitBucket wiki up to date here:

https://bitbucket.org/michaelcox/awc/wiki/Home