Command line: VIM

Why am I moving from Visual Studio to VIM?

As I mentioned in my previous post I want to use VIM instead of Visual Studio to work on my logcmd project. This would be a kind of an experiment, but I do have some fair reasons behind that decision. Why do I think VIM is a good alternative to Visual Studio?

It encourages automation

If you’ve ever worked in VIM, you know, that the most important & personal thing is _vimrc file. It’s not that all the keybindings and plugins are already there. You have to create them, customize, sometimes create scripts that boosts your development, and you do it all the time. The other things you need to run directly from console. And obviously you do not retype all the kilobytes of commands all the time. After the second try you want to automate it and have a script that works for you. Although it may sound prehistoric to some of you, it has a lot of long-term benefits. You don’t have to teach new people (or even your future “you”) how to validate JavaScript, do merging/branching, compile LESS, deploy to DEV server, upgrade release notes etc. This way you also get stronger in command line scripting.

It cures bad habits of debugging

All the people praise VS for astonishing debuggig features. It’s all true, but I think overused almost all the time. I know it allows to solve the most hardcore and unexpected behaviour that you could imagine, but on the other hand it’s like using excel for simple arithmetic. I experienced it on my own. Do you remeber one of the following:

  • running the application to check some business logic (writing unit test would take too much time (sic!))
  • fixing some hard issue after hours of debugging and forget how to debug again
  • wishing you could debug your application on PROD?

This all is because of relying on Visual Studio “debugger”. Other people not so tightly coupled with debugger invented better approach decades ago. It’s LOGGING. I’m always amazed how people solve their problems with RaspberryPi or Linux problems on discussion boards – it’s always clear after sending the logfile. Having a good habit of logging also works on “debugging” production.

It has better performace

It’s all about automation and the keyboard. Have you ever seen a hacking movie where they open “My computer -> My documents -> my hacking -> Visual Hacking studio -> create new project”? Or drag and drop viruses from “My downloads”. It’s because mouse is slower than keyboard (unless you participate in Quake 3 Arena world championship). Of course it’s slower if you started with mouse, but give it some time. You can self-check how much faster it is to use vim’s “ci(” instead of searching the starting parenthesis, selecting the text with mouse, finding the closing parenthesis and pressing BACKSPACE.
It’s also a better performance of the editor itself. Visual Studio is slow, but how can an application that takes a couple of GB on disk be fast all the time? On the contrary VIM is pretty leighweigh and blazing fast (unless you install everything you find on Github).

It’s more universal

VIM is everywhere, not only C, C++, C#, Java, JavaScript, Go, Haskel and friends. And VIM is there for years (VI released in 1976). It’s important if you hesitate about the future of Microsoft, or feel bored of .NET (or burnt).

It has the spark of extravagance

Have you seen Rob Ashton coding? Have you seen other people’s faces during that? But, that’s mixture of freak and performance.

It’s raw in a positive way

You think programming is not only about writing the code fast? It’s mainly about reading, right? Then even better, because VIM is raw. There are no codelens, different toolbars/toolboxes, variety of windows, resharper rainbow of tips and tricks. You can focus on code only.

Changing your environment is good

It opens up your mind, it’s like being polyglot programmer. In case of programming languages, if you knew C# only, you would solve each and every problem using classes. Same with environment/IDE. It’s obvious for us that using Visual Studio debugger we can set the next statement there and back. I believe other environments also has such obvious things that we are not aware of.

In the end I’d like to share some video of VIM coding in action.

Advertisements
Programming (back-end)

Debugging NSpec with VisualStudio/Resharper – simple trick

NSpec is purely awesome, although coming with little painful disadvantage – debugging. The default approach (DebuggerShim.cs) is weak because forces me to always navigate to a separate file and change some code. Authors of this great library claim in the documentation that they already work on “fully integrated support”, but it’s not there yet. Fortunately you can apply one simple trick to make it work far better.

1. Get Nspec: install-package nspec

2. Get NUnit (in version referenced by NSpec): install-package nunit -Version 2.5.7.10213

3. Go to DebuggerShim.cs file and change it to look like that:

nspec - DebuggerShim.cs

And that’s it! You can go back to your specs and be delighted by the “unit test” icon beside your spec class.

NSpec - test result

…and test runner:

NSpec - Run spec

What has happened?

DebuggerShim was a tool (nunit TestFixture) that run some given specification. By renaming it to “nspec” class it’s become a wrapper for all specifications. For NSpec it doesn’t matter because it doesn’t care about NUnit attributes nor abstract classes. If it’s in the same namespace as other specifications, then we do not have to change anything and Resharper starts to detect it as NUnit test fixture (as it derives from our custom “nspec” test fixture).

Advantages:

  • Simple – no need to install any plugin/adapter
  • Unobtrusive – no need to change existing specifications
  • Easy to update – if NSpec gets fully integrated debugging support, then just delete custom abstract nspec wrapper
  • Additionaly as a test output we see specification generated by NSpec runner

Disadvantages:

  • It runs the whole specification, it’s not possible to debug single context. This is particularly painful in case of big (and slow) UI testing scenarios. In that case I try to split them into several more specific scenarios.

You can download the test sample here: https://github.com/chrisseroka/Blog.NSpec.Debugging

Programming (back-end)

.NET types can have spaces. And not only spaces.

No, you cannot write code like that:

clr-art2

At the same time there is no new C# 9.0 nor C# One that allow to write such code. But there is a namespace called System.Reflection.Emit containing TypeBuilder that can generate valid CLR types. Here’s a sample code that you can use, to put some more life into your Employee entity:
clr-art

I don’t suggest to start writing code like that, but have it in mind while playing with reflection on some external libraries (I guess there would be a problem when serializing such object to XML).

Programming (front-end)

Unit testing JavaScript in VisualStudio with ReSharper

imageCurrently a huge number of projects is driven by TDD. There are tests of Services, Repositories, Domain objects etc. The attitude to these kind of practices changed and now it’s nothing exciting but our bread and butter. Moreover the architecture of current Web Applications changed as well. In average we spend more than 50% of our time developing front-end side of the app (JavaScript etc) but having in mind, that TDD is only applicable to back-end code. As a ReSharper user I’ll show how easy it is to set up a proper solution with another level of unit testing.

 

Test application

Let’s imagine that we are doing a web application supporting front-end developers. Among all the functionalities we have a simple reusable module to recalculate color values: RGB/HEX.

1

Separation of Concerns is one of the most important things while doing TDD, that’s why I chose “KnockoutJS” as the framework connecting our view with the logic. Architecture of such application is very simple. At the moment we don’t even have any “back-end” code, but still can do TDD.

2

The first test

Let’s pick out the ColorCalculator as the target. This is a “class” that is responsible for calculating color values between RGB and HEX.

Thank to Resharper 6+ we have JavaScript test runner provided out of the box. We can write JavaScript tests with two frameworks: QUnit (TDD style) and Jasmine (BDD style). Here I chose QUnit but you can see version with Jasmine in my next post: Unit testing JavaScript in VisualStudio with ReSharper – improvements. Because these two framework are supported by default, we don’t even have to download/reference any additional libraries. This is how our basic test will look like:

3

Immediately after closing the test() function resharper will add “Run test” button on the left. In case of QUnit Resharper will run the test in the default browser using QUnit default template, showing the result as it is:

4

Test result is also shown normally in ReSharper “Unit Test Sessions” window.

Extracting test project

Of course it’s not the best choice to have tests shipped with production code. For most of modules for back-end code we have dedicated “.Test” project. Now let’s extract such a separate project for JavaScript test code.

First add a new project to the current solution. The project type should be “Empty Web Application”  (in contrary to normal unit test project when we add “Class library”). Then you can add your test files to the project. You also need to reference the tested code. To do it, add existing script files as “links”:

6

This is the drawback of our solution. Whole reference tree needs to be reproduced . But it’s not that bad, we don’t change the reference tree that often but instead we have all the code in one place and it’s checked during the build time. Complete test solution should look like that:

11

Next you need to do a little trick to copy referenced files to the solution. To do it “Edit project file” and add the following code to the end of the test project:

9

I hope in the next releases of Visual Studio such behaviour will be applied automatically.

Finally modify a little the test code adding a reference to the code under testing (/// expression):

10

And that’s it! – after adding some tests and implementing the functionality correctly you can right click the solution, click “Run all tests” and be sure that everything is correct!

UPDATE: There is also better and simpler approach to reference production code. I write about it here: Unit testing JavaScript in VisualStudio with ReSharper – improvements

Debugging the tests

Wiseman said: “If you need to debug unit test then something is wrong with it’s unitness.”

PS: If it’s really needed you can debug it in browser as you normally debug JavaScript code.

Switching to PhantomJS

If you don’t want to run the tests in browser you can run it with headless PhantomJS runner (also by default supported by ReSharper). Go to “Resharper –> Options –> Unit testing –> JavaScript Tests” and change the “Run test with” option:

13

You need to specify the path to PhantomJS that can be downloaded from here.

Further reading

I write also about some improvements in this area (Test framework, Mocking, Referencing production code) and integrating JavaScript unit testing with our build server:
Unit testing JavaScript in VisualStudio with ReSharper – improvements
Unit testing JavaScript with VisualStudio and Resharper – running on buildserver + code coverage using Chutzpah

Download and play

You can download the whole solution here: FrontEndTools.zip

There’s still a lot to do – you can add tests to the ColorBoxViewModel and test “toRgb” function that is far more interesting.
Happy testing!