Uncategorized

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
tools

Investigating “git log” without mouse

As I’m a huge fun of doing the job using keyboard only, I’ve got addicted to VsVim, vim mode using CapsLock, then git console. Unfortunately there were still some actions that were “uncomfortable” like for example investigating “git log“. In order to copy a part of previous commit message or commit id I had to use both mouse and keyboard. Finally I have figured out that the solution is really simple: pipe the result to vim:

git log | vim --noplugin -

- is to tell vim to read from stdin
--noplugin is used to speed up load time and reset some strange behaviour, but you can live without it I think

As it’s not very short, best to have it as console alias:

doskey gl=git log | vim --noplugin -

Here you have some demo:

gif_im_color_dither_16_20a833df54

My journey to figure it out was not that straightforward, as I thought it should be some feature/plugin to my terminal (ConEmu at home, Console2 at work) – nothing found. Then I tried to use VIM as terminal (using ConqueTerm) but not everything worked there (i.e. Yeoman) and finally git commit opened “vim” inside of console in vim … “Vimception” ]:-)>

Finally we can use the same trick in several other places like
git branch – copy branch name for further use in git checkout
git status – copy file name to add/reset/checkout changes
and more…

tools, Uncategorized

Challenge accepted: starting ‘logcmd’ – a console logs browser

I know that I was not blogging for a while. The only cheap excuse that comes to my mind is having a second job of begin father of two evils angels. I tried hard several times but stuck without publishing. Because of that I realized that I really need some actuation. And then Maciej Aniserowicz came with his “Daj sie poznac 2016” initiative (or maybe I just got tired of the idea that I will stay inproductive, and keep wathing movies every evening till my children go to university).
I was fighting for a long with the same cheap excuse, but won, and joined 10 mins before the registration was to be closed.

The rule is to blog about some pet project, so here is mine: logcmd. It will be a simple tool to read application logs (from file, console and more) and then search, filter, browse. The idea was born out of the need some time ago, when I searched for some online log4net log browser, because I wanted to filter NHibernate queries from the logfile.
As the subject is not very demanding, I decided to add two cool features on top of that. First, it will be done without Visual Studio but in VIM + OmniSharp (soon I’ll try to explain why, who knows, maybe there will be some live-coding video). Second, the tool itself will also be done as a console application. Why? Because of many reasons:
* console seems to be much closer to developer than another Visual-Log-Studio,
* console application can be easily integrated with tmux/tmux-like plugins or used for automation
* console is more portable than desktop
* I fell in love with the way git interacts with the user in command-line
* I don’t like desktop programming. All the desktop applications that I did in the past just seemed ugly to me.

Did I think about other projects? Sure, but there were some ambitious ones, that would probably die unfinished. There was also JavaScript game “Battlecity” and some Commodore 64 project. Who knows, maybe I’ll get back to them in the interim.

When talking about pet projects, I always have one picture in the back of my mind:

pet-project