Detecting the operating system in Vim

Ok, so I'm using Vim sometimes: good cross platform editor, and I'm used to the funky way it works. For those who haven't used Vi-style editors, they're "modal". This basically means that you have modes (duh! :) ):
- 1 mode for writing stuff - when you press keys and they appear in your document
- 1 mode for sending commands - when you press keys and you usually destroy stuff :D
You switch between them using Escape.

Anyway, I have this configuration file I'm using, and I'd like to change some option, to make Vim use a certain directory. Of course I don't want hard coded paths, I want it to use a environment variable.
Problem is - on Windows it's %USERPROFILE% (accessible in Vim using $USERPROFILE), on Loonix it's $HOME.

I still hadn't found a reliable method to detect the OS in Vim (and there's no function as far as I can see). Google didn't return anything relevant either...

Luckily there was a script which had nice method to detect the OS, and from it I got the method. Basically Vim has some "features" built in which you can check. So it comes down to this:

if has ('win32') || has ('win64')
    set backupdir=$USERPROFILE/.vim,C:/Tmp,C:/Temp
else
    set backupdir=$HOME/.vim,/tmp
endif

You can use :help feature-list or :he feat to get the complete list (there are lots more options than just OS ;) ).

Gaming

I'll take a break from the not-yet-started-Continuous-Integration thread to talk about one of my other pastimes. Gaming (video games, to be more precise).

I'll try to make a parallel between gaming and religion: they're both something which you believe. Blasphemous, isn't it? :)
Basically, if you play video games and you talk to other people which play too, it's all good. If you talk about games with people who don't play video games, you'll never be able to persuade them that games are worthwhile.
Same thing in religion: you either believe in God, or you don't. If you believe and you talk to other believers, it's all clear. If you talk to a non-believer, he'll never understand all the fuss.

Just give it up, if you want to make converts, go for the children! (yet another parallel :) ).



Ok, enough theory, back to the real world. The game I'm playing right now is called Defense of the Ancients Allstars (aka DotA). Multiplayer game, 2 teams of 5. You pick special units called heroes and try to work together with the other guys to destroy the enemy buildings (actually 1 building which is deep within their base).

Here's one of my favourite loading screens (they change it every major version):


This is the first post of a "gaming" series, focused on the kind of games I like - mostly strategic games, with a bit of action packed in (DotA, Starcraft for example).

Continuous Integration, and why it hurts

Let's say I'm working for a big company, we can call it X. Main task - try to implement Continuous Integration on existing projects which don't have it and try to improve those that do, but are having problems using it.

Ok, so let's start things with the obligatory link: Continuous Integration (courtesy of Wikipedia).

So, the theory goes like this (best case scenario, of course):
1. P.M. Boss finds out what needs to be done
2. P.M Boss writes a specification for it (or maybe J. Developer writes the spec)
3. J. Developer write some tests which describe basically what the application needs to do
4a. J. Developer writes the code that actually does stuff
4b. and he makes sure that the tests don't fail
5. J. Jr., trying to fix a bug in the initial implementation or to add new features writes new code and makes sure that the new code doesn't make tests fail!

Steps 1 and 4a are what happens in every programming task. Somebody finds out what needs to be done, someone does it. Business as usual.

However, for programming, where you have lots and lots of complex interactions the rest of the steps are highly recommended.

Step 2 usually means that you need program/product/project manager or an analyst to write the specs, step 3 means that you need testers or you need to allocate some time for testing to each of the developers.

So you already found a problem of Continuous Integration - testing. For each test written, someone could have code that actually did stuff that customers wanted and paid. However, luckily for me, this is not my domain of expertise (although I'm trying to learn about it too :) ).

And the second problem is automation. Sounds easy, should be easy, since all the people involved in the project are programmers, so they know everything there is to know about automation, right? Well... not really :)

In the next episode, we'll talk about Continuous Integration in the Java world, Part I - tools.

Content is king

Then why I am here?

Honestly, I don't know. I heard somewhere that you have to be a good writer to have influence in this world, and I tend to agree. So here, presumably, I'll be training my writing skills.

First of all, some information about me:
- nerd (cornerstone)
- European
- computer geek (technically I guess this is a subspecies of nerd)

So, for future visitors, what you'll find here will be: articles about computers - technology (operating systems, programming, various configuration stuff I find interesting), gaming and social issues I find interesting.

We'll see as times passes what happens :)