Archive for category Vim

How to make node.js, CoffeeScript and Jasmine play nice with Vim

In order to see how much fun it could be to develop a web application BDD style, I decided to re-implement the node-chat sample application.

I started by implementing the chat server which runs on node.js, so making my chat server run on node.js as well was an easy decision. Why I used CoffeeScript over just Javascript  and Jasmine for testing will be explained below.

Although I will blog about the resulting implementation and specs separately, the impatient can go here to have look.

CoffeeScript

Everyone loves nice and quiet and for a lot of people that extends to their work environment; ergo we don’t like noisy code.

I believe in the idea of cleanly formatted code to make it more readable and that these clues are enough for a parser to deduce what I am trying to say. Curly braces make code less readable IMO and are not really necessary.

CoffeeScript takes this to heart.

It is a language that generates Javascript code. The generated code is as readable as Javascript allows, but at least I don’t have to look at it all day.

It borrows ideas from a number of languages and combines the best of each into a super succinct and expressive language. Ruby developers will feel right at home and some things like list comprehensions are reminiscent of Haskell.

Like Haskell and Python, CoffeeScript is whitespace sensitive and thus doesn’t need any extra information about the code structure aka noise.

CoffeeScript and Vim

In order to quickly compile and then run my coffee scripts with node, I looked for nice Vim integration and found it here.

Although the site explains how to use it, I will point out the usage scenarios that I found most important.

Auto-Compilation

Setup Vim to auto-compile coffee files when they are saved via:

  autocmd BufWritePost *.coffee silent CoffeeMake! -b | cwindow

This is super useful as now I can save my file and run it right after via node.

If there are any compilation errors, they will be shown in a separate window, which disappears only after the errors were resolved and the file is saved again.

Leave off the “!” in order to have the cursor jump to the line of the error automatically.

Coffee-Compile

This feature is probably most important, if you are like me new to both CoffeScript and Javascript.

It allows compiling the entire Vim buffer or the selected text only and shows the resulting Javascript right inside Vim.

I used it a lot when I wasn’t sure if the CoffeeScript would do what I expected and to just get an idea of what it would look like in Javascript.

It is so easy to select a few lines of code, run CoffeCompile and watch and learn as the screenshot shows.

Jasmine

Jasmine is a BDD framework for Javascript, which means you can author your tests in CoffeeScript as well of course. In order to test code running in node.js, you will need jasmine-node. Install it via

npm install -g jasmine-node

For my project I placed my specification files inside the /spec folder and could immediately run them via

jasmine-node spec

Well almost at least. The site warns:

your specifications must have ‘spec’ in the filename or jasmine-node won’t find them!

My file was called server_specs.js (after the CoffeScript compile step) and Jasmine still didn’t find it. Turns out that renaming it to server_spec.js did the trick.

So be aware:

In order for Jasmine to find your specification files they need to end with spec.js.

Why I didn’t use vows

This is a good time to mention that I gave vows a try first because it seemed to be so very much in vo(w)gue.

It’s strong point for some and weak point for others – like me, is, that it runs all tests in parallel.

This is surely a good idea, but makes re-using things like stubs very hard, especially if you use a lot of child contexts like me. Tests start to affect each other in weird ways and it is very hard to keep them separate. As far as I understand, anything that is to be truly isolated needs to be returned by the “topic” and this becomes a nuisance once you have a lot of things that are affected by setting up a context.

I dabbled with it for a few hours until I decided the hoops I had to jump through weren’t worth it – after all if I wanted to jump through hoops in order to test my code, I could just stick with static languages, right?

I found that I wasn’t the only one who feels that way. When I looked around for alternatives, I found this on the nodeunit site:

While running tests in parallel seems like a good idea for speeding up your test suite, in practice I’ve found it means writing much more complicated tests. Because of node’s module cache, running tests in parallel means mocking and stubbing is pretty much impossible.

I also think that running tests in parallel is more important if you are dealing with long running integration tests. IMO in that case it is better to separate these from the faster running unit tests and run them only once a day or so.

Jasmine and Vim

Although it could be perfectly sufficient to just save you file after you made some change and then switch to the terminal in order to run the tests, it definitely gets in the way of the red – green – refactor workflow.

I prefer to just have to hit one shortcut key in order to save/compile the code and run my tests. This allows me to keep my focus on what I am trying to accomplish.

You can certainly run jasmine-node from inside Vim like with a simple command, but with mixed results:

The weird looking numbers are color codes sent to the terminal which the simple Vim terminal interprets in its own ways.

Turns out that jasmine-node, although it sports a --colors option, turns colors on for you even if you don’t specify it. Fortunately there is a way to turn the colors off explicitly:

That’s better!

The only thing left to do is to hook saving all files and running tests up  to a shortcut by adding the following to our .vimrc: (first line ensures our leader key is a comma)

 let mapleader=","
  map <leader>m :wa \|! jasmine-node spec --noColor <CR>

In this case hitting ,m will save all my open files and then run my tests.

Clean Test Output

In order to keep my test result output from being cluttered up with log messages and such, I replaces node’s sys that is normally obtained via sys = require "sys", with a stub that does nothing when sys.puts is called.

Just to give an idea of how simple this is here is a quick example:

1. When creating the system under test, we inject the dependencies we want to stub – including sys

  @sut.init
    router: @router_stub
    sys: { puts: (msg) ->  } # stop sys.puts from cluttering up the test output
    process: process_stub

2. The system under test then uses the injected dependencies if present or the real ones otherwise

server.init = (fake = { }) ->

  sys = fake.sys or require "sys"
  router = fake.router or require("./lib/node-router")
  server = router.getServer()

  process = fake.process orglobal.process

More details will be explained in a later post.

,

3 Comments

Reading Source Code on iPad with Vim syntax highlighting

The best way to learn new languages/technologies is to read some good sample source code.

Incidentally there is an abundance of source code, but only so little time. I thought it would be nice to read some on my iPad while I’m on the train. Of course it would be even better if I could have it syntax colored.

Fortunately as I mentioned in my previous post, there is an easy command in Vim to convert any text to html, including the colors.

:TOhtml

does the trick.

So here is what you need to do:

  1.  Get yourself an iPad reader that supports html – I use GoodReader
  2.  Convert the source code you would like to read into html using your Vim editor and save it to a file
  3.  Upload the saved html file to your iPad reader (ideally using something quick and convenient like GoodReader’s WiFi transfer)

1 Comment

How to make your code samples in your blogs look like they look in Vim

Four simple Steps

  1. Open the code sample in your favorite editor (that would be vim)
  2. Execute :TOhtml (this generates a complete html file including a <style> section that contains the needed CSS and a <body> section that contains the HTMLversion of your code)
  3. Copy the generated CSS into the CSS file of your blog (in wordpress you’d get there via Appearance/Edit CSS)
  4. Include the generated HTML body in your blog

I haven’t tried this, but alternatively you could just copy the entire html (including the <style>) into your blog and thus combine steps 3 and 4.

The disadvantage of that approach is that in this case you’d have to include the CSS part in every blog that has a code sample.

If you don’t want to upgrade

In case you don’t want to pay the $15/year for the Custom CSS upgrade, scrap steps 3 and 4 and instead do the following in order to inline the CSS.

  1. Copy the code generated in step 2 from above to the clipboard
  2. Go to http://premailer.dialect.ca/
  3. Select Paste HTML as the source
  4. Paste your code into the text field
  5. In the Options check everything except  Don’t remove <style> and <link> elements
  6. Hit Submit and copy the HTML results
  7. Include the copied HTML in your blog

2 Comments

Automatically loading Vim files from Dropbox folder

I have been a happy Dropbox user for a while now. I try to link whatever possible to it like:

  • Visual Studio settings
  • PowerShell modules
  • Resharper mounted live template file

Until today I was still copying my vimfiles back and forth though.

So I finally took the time to investigate how to point the vim runtimepath to a folder of my choice.

Turns out there are two ways to do this:

  1. Point the vim runtime path to a folder in your dropbox
  2. Create a link from your local vimfiles folder to the vimfiles folder in your dropbox

Point the vim runtime path to a folder in your dropbox

In this case vim itself (‘:help runtimepath’) was more helpful than stackoverflow and google.

This stackoverflow answer maybe useful to others, but in my case I never could get the printf() statemtent to work and I also would like to start vim without specifying the path every time.

As I said, the help helped (npi) and after a bit of experimentation I came up with this solution.

I added

set runtimepath=~/Dropbox/Settings/vimfiles,$VIM,$VIMRUNTIME

to my .vimrc file.

Note that for Windows the dropbox folder is called ‘My Dropbox’ and therefore you need to escape the space like so:

set runtimepath=~/Dropboxes/Gmail/My\ Dropbox/Settings/vimfiles,$VIM,$VIMRUNTIME

Now I could remove my .vim folder (vimfiles on Windows ) from my HOME directory and am picking up all my plugins, syntax highlighters, etc.  directly from the given vimfiles folder inside my Dropbox.

Only the .vimrc file has to stay were it is and will have to be synchronized among my computers since something has to do the pointing.

Create a link from your usual vimfiles folder to the vimfiles folder in your dropbox

I found a great explanation on how to do this on different operating systems.

Here is an example on how to do this on Windows:

  1. Make sure that all your vimfiles have been copied to your Dropbox folder.
  2. Remove the vimfiles in you HOME directory.
  3. Launch cmd.exe and use mklink to create a link from ~/vimfiles to the vimfiles in your dropbox e.g.:
    mklink /D "c:\Users\yourusername\vimfiles" "C:\Users\yourusername\My Dropbox\Settings\vimfiles"
  4. Optionally do the same for your .vimrc file (I actually link it to a window specific one, because I use a different font for each OS):
    mklink "c:\Users\yourusername\.vimrc" "C:\Users\yourusername\My Dropbox\Settings\.vimrc_windows"

    In this case you need to make sure to not directly edit the local .vimrc as this will overwrite the link you created. Instead edit the .vimrc inside your Dropbox folder.

Both solutions allow me to extend my vim, for all my machines in one shot.

1 Comment

%d bloggers like this: