One example, where an animation gets annoying is github. They sport a slide animation when going back and forward while browsing the code.

I found this annoying in general, but it became unacceptable once I started using Safari on Lion OS when browsing github repos.

As you know Safari already has a sliding animation when going backward or forward in the browser using the two finger gesture on the trackpad.

With the added github animation, you see two sliding animations right after each other.

Turns out a simple bookmarklet can help.

Since github is using jQuery, turning off all jQuery animations does the trick.

Unfortunately WordPress keeps expanding bookmarklet urls to, so you’ll have to follow these steps in order to install it:

• Copy the code snippet below
• create a new bookmark, name it something like StopFx
• edit the bookmark and paste the copied text into the URL/Address field.

javascript:(function(){jQuery.fx.off=true;})();

Once you arrive at a github repo invoke the bookmarklet and enjoy distraction free source code browsing.

Of course this will work  for any website with annoying jQuery animations,

In case you are interested in creating your own Bookmarklets, you can find more information here.

As a final note, in order to edit bookmarks in Safari, you have to select “Show All Bookmarks” from the “Bookmarks” folder. I am adding this, because that was not at all obvious to me.

These plugins just give you some keywords about the language in question, but cannot really give you information about the object you are currently dealing with because they never evluate the code that created it.

Realistically since JavaScript is a dynamic language, it would be hard for any tool to give proper support without actually running parts of your code. Fortunately we have repls for that. It’s the same idea as Small talk (except in that case the repl is built into the IDE).

Usually when trying to figure things out, run some code in the repl and now it can tell you all kinds of information about objects that were created up to that point. This also includes all exports of modules – which is very useful.

Unfortunately up until now it was a multi step process to source my code in the repl in order to play with it.

I read this post, which explains, how to set up a screen in some unix terminal and then send some text over the created socket. The author also implemented a Vim plugin called slime.vim. I forked it and added some CoffeeScript specific feature which I will explain.

Finally we can send code snippets from Vim directly to the repl without any cut and pasting overhead.

It is actually quite simple to set these things up.

• Install slime.vim into your vim plugins folder
• Open a terminal window and start a named screen e.g. “screen -S coffee”
• Start a repl inside that screen e.g. coffee for a CoffeeScript repl
• Open vim, select some code snippet in visual mode and press Ctrl-c twice
• At the prompt give the screen name e.g. coffee and accept the given window name
• The selected code should have been sent to the repl and you can now inspect the created objects

That’s it!

Unfortunately the coffee repl is not quite as nice as the node repl (especially when it comes to inspect functions and properties of an object), which is why I extended the plugin a bit.

If you press Ctrl-C Ctrl-S after selecting a CoffeeScript code snippet, it will be compiled into JavaScript before it is sent to the screen. This means you can directly send your CoffeeScript code to a node repl and inspect it things in there.

I have yet to figure out how to send a <Tab> signal over in order to trigger completion from inside Vim, so anyone with an idea, please comment!

This post evaluates a new approach of how to wire our code together while staying decoupled. The reader should keep in mind, that the author has not tried this approach in a larger size project and as with any design pattern there may be problems that only become apparent when used in a real world scenario.

Why another pattern?

There has been a recent interest in writing code in a more functional style – not only because it is more elegant and fun. Yet most common patterns that are used to wire the code together lend themselves very well to a pure object oriented paradigm.

After reading this post, I was convinced that it is time to re-evaluate how we are doing things when it comes to managing our dependencies, which currently is very Noun/object centric.

It is on us to leverage the opportunities that the current languages and libraries offer in order to improve the architecture of our applications.

What is the pattern all about?

I will focus on the possibilities that open up once we use a language that allows passing functions around the same way that we are used to with objects. As a result we can decrease coupling even more than is possible with traditional Dependency Injection.

I also want to point the reader to a post by my colleague Daniel Moore, who explored and implemented a similar pattern with streams using MEF and Rx.

I will give two examples on how to implement this verb centric pattern. One example will be using CoffeScript. The other one will be in C# paired with MEF.

From here on after I will refer to objects and dependencies as nouns and to functions as verbs.

I don’t want to call anyone

Let’s say I have some controller that needs to send a message entered by the user. There will be someone in my arsenal of nouns that knows how to do that, so I will inject the Emailer or IEmailer or something along those lines.

Then I can tell the emailer to send messages via:

emailer.Send(msg)

Now let’s assume that I need to receive a confirmation message. Well, I just tell the emailer to give it to me:

reply = emailer.Receive()

All good right? But do I really need to know who is taking care of things? Not really.
All I would have to know is what verb to use in order to get a certain thing done:

sendMessage(msg)
reply = receiveMessage()

What’s wrong with Dependency Injection?

What if we change responsibilities later. Let’s say we still send messages via email, but now receive them directly from the server. At this point I have to change all the code that tells the emailer to receive the message. I would probably inject me a server and change the message receiving calls to something like:

reply = server.Receive()

Not a big deal you think? What if I have to change it in 10 places and don’t forget, since I follow good practices and am writing tests for my code, I now also need to change who does what in my test setup.
Lets remind ourselves of a principle that the authors of Code Complete elaborate on in chapter 7.5. It goes something like this:

If I have a record with 20 fields on it and a method, that only uses 3 of them, I should pass the 3 fields in as parameters instead of passing the entire record.

It makes sense. The less anyone knows about anyone else, the least coupled they are, so we shouldn’t spread more knowledge about how things are arranged than necessary.

Facebook is the best example of what happens when we don’t follow this advice. Since they so very successfully spread the knowledge about who is related to whom, we are now somehow coupled to almost anyone in the world.

This is not desirable for software systems though.

To summarize:

Knowledge containment makes for better decoupling and this applies to everything needed by a part of a system.

Dependency Injection does not adhere to this though when it comes to telling a system how to do things. Instead we inject the entire dependency that happens to have the verb we need. All the system wanted was to know how to do things, but instead we told it who knows how to do it as well.

As a result dependency injection spreads more information than necessary and that is what’s wrong with it.

What do I need to know?

In the above example, I needed to know what verb to use when sending a message and that I have to give it a message to send. If I wanted to receive a message, I had to know the appropriate verb for that and that I’m expecting a message to be returned to me. This boils down to the following generalization which maps perfectly to our examples:

output(s)     verb   input(s)
              sendMessage(msg)
reply     =   receiveMessage()

The CoffeeScript Example

As explained in a previous post, I decided to re-implement the node-chat example in CoffeeScript in a BDD manner.

Once I had it all working using dependency injection, I decided to use verbs instead and see how it works out.

Using Dependency Injection

Originally the chat server init function looked like this:

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

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

 qs = fake.qs or require "querystring"
 url = fake.url or require "url"

 process = fake.process or global.process

As you can see I allow the tests to fake certain dependencies. If a faked dependency  was not present – e.g. when used in production, the appropriate node module was used.
In my tests, I injected the fakes like this:

  server_stub =
    gets: {}
    get: (id, callback) -> @gets[id]= callback; undefined
    listens_on: {}
    listen: (port, host) -> @listens_on= { port: port, host: host }

  @server_stub= server_stub
  @router_stub=
    getServer: -> server_stub
    staticHandler: (file) ->

  process_stub =
    memoryUsage: -> rss: mem_rss_stub
    env:
      PORT: port_stub

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

The bootstrapper was rather simple, as it had to inject nothing, since the real modules where to be used in this case.

chat_server = require "./server"
chat_server.init()

Routing calls like

server.get req, res { ... }

were spread throughout the chat server.

Using Verbs

As a proof of concept I refactored the chat server to use verbs where possible and thus have it know the least about where anything is coming from and how the world is arranged.
The chat server now learns from the injected config how to do things, but is not made aware of who is responsible for doing them.

exports.init = (config) ->

  throw "Need to pass in config object that has required verbs like log, route, etc." unless config?

  # States 
  env          =  config.env

  # Verbs
  memoryUsage  =  ()            -> config.memoryUsage()

  log          =  (msg)         -> config.log msg
  route_static =  (file)        -> config.route_static file
  route        =  (req, res)    -> config.route req, res
  listen       =  (port, host)  -> config.listen port, host

  # Modules
  qs           =  require "querystring"
  url          =  require "url"

As you can see, there is still one noun that is passed (env), but this is only used in order to query the state of the environment.
I formatted the code in the Verbs section in a way that clearly shows what verbs are used and what their inputs are. Anyone who needs to initialize the chat server can thus easily see what it needs to know. You can think of it as a config section.

In my tests I can easily set things up since now I just have to pass in certain functions instead of having to build up fakes.

  @listens_on= {}
  routes = {}

  @server_get= (method, req = { }) ->
    res = @res_stub
    routes["/#{method}"] req, res
    res

  @sut= require("./../server")
  @sut.init
    route_static: (file) ->
    route: (id, callback) -> routes[id]= callback; undefined
    listen: (port, host) => @listens_on= port: port, host: host
    log:  (msg) -> # don't clutter up the test output
    memoryUsage: -> rss: mem_rss_stub
    env: PORT: port_stub

The calls to server.get req, res { ... } were replaced with route req, res { ... } calls and thus no knowledge of there even being a server is spread throughout the code anymore.
The bootstrapper takes on the responsibility of figuring out who does what in order to properly initialize the chat server.

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

chat_server = require "./server"

chat_server.init

  # Nouns
  env:            process.env

  # Verbs
  memoryUsage:    process.memoryUsage
  log:            sys.puts
  route_static:   router.staticHandler
  route:          server.get
  listen:         server.listen

I also formatted it in a way that makes it read like a config section.
This is the only place where the knowledge of how things are arranged lives and thus changing things around later becomes easy.

Verbs are Aspect Oriented Programming friendly

When injecting verbs as described I have much more control about how things are getting done, which allows me to quickly add/remove aspects concerning certain actions.
Lets say I want to log what routing calls the chat server registers, but I don’t want to touch my router code.
All I have to do is introduce a more verbose routing function, which logs information and then calls the original one and then pass that into init. Here is an abbreviated example:

verbose_route = (req, res) ->
  console.log "Routing request: ", req
  server.get req, res

chat_server.init
   [...]
  # Verbs
  route:          verbose_route
   [...]

Although this is a very simple example, it should give you an idea of how powerful this approach is and how much it simplifies extending your application.

Verbs and C# using MEF

I created a sample application that shows how to implement the same pattern in C# using MEF.

The main worker in the application is the runner:

[Export]
public class Runner
{
    private readonly Action<string> _print;
    private readonly Func<string> _read;
    private readonly Action<int> _shutDown;

    [ImportingConstructor]
    public Runner(
        [Import(Verbs.Print)] Action<string> print,
        [Import(Verbs.Read)] Func<string> read,
        [Import(Verbs.Shutdown)] Action<int> shutDown)
    {
        _print = print;
        _read = read;
        _shutDown = shutDown;
    }

    public void Run()
    {
        PrintStartupInfo();

        InteractWithUser();

        _shutDown(0);
    }

    private void InteractWithUser()
    {
        _print("Please enter your name: ");

        var name = _read();

        _print("Hello " + name);
        _print("Please press enter to shut down");

         _read();
    }

    private void PrintStartupInfo()
    {
        _print("The super verbs application has started.");
    }
}

As you can see it gets the verbs injected as single parameters instead of via a config.The Import statements are telling MEF how to resolve the injected verbs (in case you need to read up on how this works head on over here).

But where are these verbs actually coming from? Well the Runner doesn’t know nor is he supposed to. To tell you the truth, it doesn’t matter. We just need to make sure, that someone is exporting them, so that MEF can resolve them.

It so happens, that we have a UserInterface that knows how to read and write:

public class UserInterface
{
    [Export(Verbs.Print)]
    public void Print(string message)
    {
        Console.WriteLine(message);
    }

    [Export(Verbs.Read)]
    public string Read()
    {
        return Console.ReadLine();
    }
}

and the ApplicationManager knows how to shut down the application:

public class ApplicationManager
{
    private readonly Action<string> _print;

    [ImportingConstructor]
    public ApplicationManager([Import(Verbs.Print)] Action<string> print)
    {
        _print = print;
    }

    [Export(Verbs.Shutdown)]
    public void ShutDownApplication(int code)
    {
        _print("Shutting down ....");
        Environment.Exit(code);
    }
}

The Export statements use the same identifiers as the Import statements of the Runner. This allows MEF to hook everything together.
I could simply inline the strings for these identifiers, but want to avoid introducing bugs due to typos.
Therefore I created constant identifiers in a Verbs class.

public static class Verbs
{
    public const string Print = "Verbs.Print";
    public const string Read = "Verbs.Read";
    public const string Shutdown = "Verbs.Shutdown";
}

Finally we need to tell MEF to wire things up. We do this in the Program.

public class Program
{
    private CompositionContainer _container;

    public static void Main(string[] args)
    {
        var p = new Program();
        p.Run();
    }

    public void Run()
    {
        Compose();

        var runner = _container.GetExport<Runner>().Value;
        runner.Run();
    }

    private void Compose()
    {
        var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
        _container = new CompositionContainer(catalog);
        _container.ComposeParts(this);
    }
}

We create a container in the Compose() method in order to make MEF lookup all of the exports in our assembly. Then we resolve the Runner at which point MEF injects all of our exported Verbs.
The full example is available here on the master branch.

Adding another Printer

In order to demonstrate how extensible our little application is, lets assume we want to add a Debugger that sends a timestamped version of the message to the output window whenever someone prints it.
At the same time we want to keep printing to the console.
We can do this without changing a single line of code inside our Runner – I promise!

We need to introduce a method that when called, will aggregate and then invoke every method that claims to know how to print (via the appropriate Export). We will use MEF’s ImportMany feature to accomplish this task.
For simplicity lets just slap this method onto the ApplicationManager – we can always move it later since no one will be aware of where it lives.

public class ApplicationManager
{
    private readonly IEnumerable<Action<string>> _printToMany;

    [ImportingConstructor]
    public ApplicationManager(
        [ImportMany(Verbs.CompositePrint, AllowRecomposition = true)]
        IEnumerable<Action<string>> printToMany)
    {
        _printToMany = printToMany;
    }

    [Export(Verbs.Shutdown)]
    public void ShutDownApplication(int code)
    {
        ApplicationPrint("Shutting down ....");
        Environment.Exit(code);
    }

    [Export(Verbs.Print)]
    public void ApplicationPrint(string msg)
    {
        foreach (var print in _printToMany)
        {
            print(msg);
        }
    }
}

It now exports its ApplicationPrint method under the Verbs.Print identifier that the Runner knows about. When invoked, it finds all print methods that where exported under the new Verbs.CompositePrint identifier and invokes them one after the other.
Since it exports itself under the same identifier that the UserInterface used to export its Print method previously, it ends up replacing it.

There are two things left to do:

First we need to update the print method in our UserInterface to export it self as the Verbs.CompositePrint (this is an extra verb we add to our Verbs class).

public class UserInterface
{
    [Export(Verbs.CompositePrint)]
    public void Print(string message)
    {
        Console.WriteLine(message);
    }

    [Export(Verbs.Read)]
    public string Read()
    {
        return Console.ReadLine();
    }
}

Secondly we now introduce the Debugger that will export a print method with the same identifier.

public class Debugger
{
    [Export(Verbs.CompositePrint)]
    public void Print(string message)
    {
        Debug.WriteLine(DateTime.Now + " - " + message);
    }
}

As a result whenever the Runner prints a message it will end up calling the ApplicationPrint method which in turn calls the print methods on the UserInterface and the Debugger with the passed message. As promised, the Runner didn’t change and is totally oblivious to the new way that things are done now.

This version of the application is available here on the multiprint branch

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.

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. 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

I’m also very interested in the libraries that make a lot of things like cross browser issues easier. So a lot of times when I see a site I like, I’m wondering, what libraries it is using under the hood. I wanted a faster way to determine this than ‘view page source’.
So this became my first little JavaScript task.

I went to jsFiddle to spike how it could be done (unfortunately I couldn’t use jQuery here, since then I would have needed to reference it and it would obviously have obscured the results).

After a few attempts I had my little JavaScript function ready. Since I couldn’t rely on any map function, it is using a lot of for loops and is not too pretty, but some people may find it useful:

 1 (function showLoadedLibs() {
 2 
 3     var names = ['jquery', 'mootools', 'backbone', 'prototype', 'yui', 'simpleyui', 'glow', 'dojo', 'modernizr', 'processing', 'ext-core', 'raphael', 'right'];
 4     var scripts = document.getElementsByTagName("script");
 5     var loadedScriptNames = "";
 6     for (var i = 0; i < scripts.length; i++) {
 7         var src = scripts[i].src;
 8         for (var n = 0; n < names.length; n++) {
 9             var lib = new RegExp(names[n] + '[^/]*[.]js').exec(src);
10             if (lib) {
11                 loadedScriptNames += " " + lib + ",";
12             }
13         }
14     }
15     alert("\nLoaded libraries: " + loadedScriptNames.substr(0, loadedScriptNames.length - 1) + "\n\nLooked for: " + names);
16 
17 }());

In order to use it as a bookmarklet, I went to the Bookmarklet Crunchinator to ‘ crunch’ the above code.

The result looks like this:

javascript:(function(){(function showLoadedLibs(){var names=['jquery','mootools','backbone','prototype','yui','simpleyui','glow','dojo','modernizr','processing','ext-core','raphael','right'];var scripts=document.getElementsByTagName("script");var loadedScriptNames="";for(var i=0;i<scripts.length;i++){src=scripts[i].src;for(var n=0;n<names.length;n++){var lib=new RegExp(names[n]+'[^/]*[.]js').exec(src);if(lib){loadedScriptNames+=" "+lib+",";}}}alert("\nLoaded libraries: "+loadedScriptNames.substr(0,loadedScriptNames.length-1)+"\n\nLooked for: "+names);}());})();

Finally, I added it to my bookmark bar – the above ‘crunched’ code becomes the Url of the bookmark.

All I have to do now is click this bookmark and am informed about known libraries that are loaded on the page I am currently on.

• 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.

My first idea was to have something like cd… and depending on the number of dots go up to the nth parent. Still, I’d have to count how many directories up my target is.

A colleague of mine had a better idea:

It would indeed be dandy to have such a function, so I invested some time and came up with the below implementation.

<#
    .Synopsis
        Sets location to the first parent directory that whose name starts with the given target dir.
    .Description
        Searches upwards to the root drive.
        If target dir is not found, a message is emitted to the console
    .Example
        cd c:\user\joeshmoe\Documents
        C:\user\joeshmoe\Documents>
        Set-LocationTo us
        C:\user>
#>            

function Set-LocationTo {
    param(  [parameter(Mandatory = $true)]
         [ValidateNotNullOrEmpty()]
            [string] $targetDir)            

    $dirs = (pwd).Path.Split('\')
    for($i = $dirs.Length - 1; $i -ge 0; $i--) {
        if ($dirs[$i].ToLower().StartsWith($targetDir.ToLower())) {
            $targetIndex = $i
            break
        }
    }
    if($targetIndex -eq 0) {
        Write-Host "Unable to resolve $targetDir"
        return
    }            

    $targetPath = ''
    for($i = 0; $i -le $targetIndex; $i++) {
       $targetPath += $dirs[$i] + '\'
    }            

    Set-Location $targetPath
}            

Set-Alias -Name cdto -Value Set-LocationTo

If you are sourcing this Set-Location.ps1 from within a module, make sure to export aliases as well e.g.:

Export-ModuleMember -Function * -Alias *

otherwise ‘cdto’ won’t be available.

I got very tired of manually ignoring “bin”, “obj” folders and various files (e.g. _Resharper*) when using Svn.

So I looked for a better solution –  something similar to Git’s .gitignore.

Reading up on some svn documentation resulted in the below function that will look for ignore definitions (similar to .gitignore) in a given .svnignore file and apply these to all folders recursively.

$psd = Split-Path (Get-Variable MyInvocation).Value.MyCommand.Path            

function Ignore-Svn {
    param(  [parameter(Mandatory = $true)]
      [ValidateNotNullOrEmpty()]
            $path,
            $svnIgnoreFile = "$psd\.svnignore",
            [switch] $recurse)            

    $fullPath = (Resolve-Path $path)
    if($recurse) { $recFlag = "-R" }
 svn propset svn:ignore $fullPath -F $svnIgnoreFile $recFlag
}

*.obj

*.exe

*.html

*.exp

*.pdb

*.user

*.aps

*.pch

*.vspscc

*_i.c

*_p.c

*.ncb

*.suo

*.tlb

*.tlh

*.bak

*.cache

*.ilk

*.log

*.htm

*.zip

*.sdf

*.opensdf

*.lib

*.sbr

*.msi

*.exe

*.orig

*.db

_ReSharper.*

Release

Debug

bin

obj

_UpgradeReport_Files

function Add-Svn {
 svn st | %{ if ($_ -match "\?\s+(.*)") { svn add $matches[1] } }
}