First steps to success!

I was thinking, how come I have no completed hobby projects? I couldn't find a reason, so I concluded that perhaps I'm too stupid to complete anything. Then I open Visual Studio again and started thinking what other features I might need in my utility library... Then it struck me! I haven't completed anything, because none of my hobby projects had requirements or design documents (which, IMHO, is the same thing)! So, I decided, that I will never write a single line of code, without having requirements or design documentation written.

I was very happy and excited, but then I've come to another problem. What document format to use for the documentation? Being an inch smarter than I was five minutes ago, I decided to gather the requirements for the document format, and then try to find one that matches as many as possible of those requirements. So, I fired up my good friend Notepad++ and started typing...

Here are the most important requirements:

• Version control system friendly or in other words - it must be a text based format, I must be able to diff two versions of the document and so on.
• If the format isn't easily editable by hand - it must have at least one free editor. Note that WYSIWYG editor is not required.
  
• IT must be easy to separate content from presentation.
  
• The format must support embeddable elements (and they must be easily editable/replaceable):
  • Tables;
  • Images;
  • Diagrams (this one is optional, because I can embed images).
    

I immediately knew, that what I'm describing is HTML (or XHTML). After some googling, I also found DocBook, and some more XML-based formats. I liked none of them! XML is a horrible language to edit by hand (you have to remember to close the tags, you have to replace some characters with their codes etc.)

Then, while reading something about DocBook, I saw LaTeX being mentioned. I looked at it... And I couldn't believe I wasn't using it already! It's my kind of way to create documents. I mean, how often can you tell someone, that you're compiling your documents? :)

And besides, LaTeX meets all of my requirements. Text based, free editors (any text editor, or something more WYSIWYG-ish like LyX or TeXnic can be used), content separation from the presentation is probably the main philosofy of all TeX formats, through some external packages LaTeX let's you embed almost anything.

So now, I have MiKTeX, and I'm experimenting with document classes and packages. I will probably create my own classes, because I want to have the common look and feel.

If you're a programmer like me - have a look at LaTeX! It's brilliant!

Subversion and Vault (again)

Ok, the two readers that I have might think I'm crazy or something. But I'm starting to dislike Vault again. I know, I know... This time, it's the "Add solution to Vault" thing that got me on the edge.

In subversion, if you need to add a new project or a solution - you simply check-out the directory that will contain this project or solution. You copy the directory of the project or solution in there with all of it's sub-directories. You do a few svn add -N commands and a few svn propset or svn porpedit commands (to set the correct svn:ignore's and, possibly, other properties - like mime-type etc.) and then you commit the changes. That's it!

In Vault, however, this is much easier. Ahem. You just start the Vault client... You wait for the client to start... For about 2 minutes... You right click on the directory that will contain the project and choose Add Files/Folders, now you just navigate to the right directory, select it, select the right files and click on the OK button. Now, you wait... Wait and pray, because 90% of the times, Vault will fail with some very unclear error message...

So, the task of importing one solution with a few projects into the repository - the task that would take no more than 5 minutes on subversion - it takes 2 to 4 hours on Vault... Well, if I had to do this again on Vault, I wouldn't even bother to do it this way. Now I know, that the best method is by creating a fresh solution in Visual Studio, importing that empty solution into Vault, and then just adding projects and files into it. I wish I knew this before, though.

I don't know... How many more times does Vault have to disappoint me and my colleagues, before we will switch to subversion?

Python 3.0 is finally out!

Finally, we have Python 3.0! I wonder, when will the IronPython catch up with the changes...

Btw, I was looking at NSIS the other day and I started wondering - why aren't there any install systems, that would use python as their scripting languages? I mean, this would give the power of python for the install script (classes, functions, standard library) and it would still be able to generate a native executable file (py2exe anyone?) - the setup program. Also, python is portable - it shouldn't be hard to port this kind of install system to other platforms!

Apology: SourceGear Vault isn't as hopeless as I was picturing it

Better late than never, right?

Anyway, Paul Roub from SourceGear commented my post about the changes at work. Also, they have released new version of Vault with some speed improvements. So, now I don't have any major complaints about it. The one feature that I would absolutely love in Vault is if the files were not versioned separately, like in Subversion.

Anyway, I was wrong. Sorry. ;)

Colleagues programmers

We're working!

NOTE: I made this photo with my new Sony Ericsson W660i phone, and I was testing the feature that lets you post the photos to the blog. It all works nice!

Changes at Work

Apparently, one of my colleagues, told my boss (again, not that boss) about my last two blog entries (Rant: Open source is not secure and The Joel Test). So now, there are undergoing changes. WOOT!

I was asked to write a document describing advantages of Subversion versus Vault. It makes perfect sense - I think I'm the guy who knows the most about Subversion in this company. Heck, I even have some ongoing spare time projects, involving Subversion, Python and hooks :P. However, after I updated my rant, I really started leaning towards Perforce, instead of Subversion. So, I think I'm going to get Perforce, and evaluate it locally on my computer (it has some options for free evaluation - see licensing page for more info). I guess I'll write more than just one document... ;)

Oh, I think I should be fair and mention something in Vault's defense - I'm not as angry on it as I was yesterday... Although, what I wrote about it is still true - I'm kind of getting used to it. Yeah, it slows me down, but at least I already figured out how to perform the most basic tasks. Anyway, I still think that lock-less version control method is much better, so I'm not giving up my hopes to use Subversion or Perforce at work.

I'll post updates about our score on The Joel Test as soon as it changes. :)

The Joel Test

Ok, so I started writing about my Job and I can't stop now. :)

I decided, to evaluate the company I work for with The Joel Test. I'll try to explain my answers to all questions and maybe I will make some conclusions. So, let's start it already!

The Joel Test as it appears on the Joel on Software:

The Joel Test

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

Let's answer those questions one by one.

Do you use source control?
Yes, we do. The source control we use isn't the best in the world, but we do use it.

Can you make a build in one step?
No, we don't. We have a lot of projects in our repository, and all of those projects get updated from time to time. Building the project, usually, involves getting one of the developers to get the latest copy of the source, and building it manually in Visual Studio. If necessary - version numbers must be updated manually. Packaging must be handled manually. Basically, we don't have any official build process - each developer does it however he likes it.

Do you make daily builds?
No, we don't. We should, though. There are people who use the projects we develop. Currently, we have to e-mail updated versions of the applications. If we'd make nightly builds - we could as well make those available for the people who use the projects. So, they'd be always using the latest versions, and we wouldn't have to worry about sending the projects to them.

Do you have a bug database?
No, we don't. This one, actually, frustrates me. The common practice, is to report bugs via e-mail to the developers responsible for the project. I don't think I have to explain, why e-mail based issue tracking is bad.

Do you fix bugs before writing new code?
Yes, we do. If we wouldn't fix bugs before writing new code - we wouldn't be able to make money. We actually rely on our projects being bug free. So yeah, we do fix bugs, before we write new code.

Do you have an up-to-date schedule?
No, we don't. But we are trying to change this. In general, we don't have any schedules. It's kind of hard to make schedules for old projects, but for the new projects - we sometimes write schedules.

Do you have a spec?
Yes, we do. I don't have anything to add - we have specs.

Do programmers have quiet working conditions?
No, we don't. This isn't very annoying to me, because I work at home. Sometimes I do go to work to the office, however. When I do - it's not really quiet. All developers sit in one office, together with the administrator and the boss (not that boss).

Do you use the best tools money can buy?
Yes and No. See my previous post about not using the best version control system.

Do you have testers?
Sort of? I don't know if I can call them testers. They're actually the only users of our applications, and it's not in they're job descriptions to test the applications. But they do the tests, they report issues... Kinda like testers... I guess, they are testers, then.

Do new candidates write code during their interview?
No, they don't. When I had my interview - I didn't have to write any code at all. I don't think there were changes in the hiring process since then. I could say something in defense, however. We don't really need them to write code, because we never hire unknown people - all of the developers hired so far were friends of someone who was already working for the company. You won't even get asked to come to an interview, otherwise. So, the company already knows, that the guy is capable of writing code.

Do you do hallway usability testing?
No, we don't. But it's not really needed. Our company is the only user of the applications that our company makes. Because of that, we don't really need the hallway testing.

So, what's the score? We have 3 yes'es, 2 sort of's and 7 no's. Our score is 3. According to Joel:

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.

Something, obviously, has to be done. I hope my boss will see this... ;)

Rant: Open Source is not secure

If you don't know, I have a job. Now, my boss has problems with open source software. He says, that because it's source is available - everyone knows how to hack it. In other words - my boss thinks, that all open source software has security issues.

Normally, I couldn't care less, what my boss thinks about it. However, due to his trust issues, programmers have productivity issues. Imagine that? Well, let me explain...

Currently, the best version control system in the world is Subversion. It's an open source version control system. As explained in the Subversion Book - Subversion uses the copy-modify-merge model. It's a great model, because there are no locked files, ever! Sure, you sometimes need to manually merge your changes, but that doesn't happen very often. Even when it does happen - there are wonderful tools to help you, like TortoiseMerge (part of TortoiseSVN). So it's not really a time waster.

Now, as I said - Subversion is open source. My boss doesn't like it, obviously. He thinks, that if we'd use it - someone could hack into our code repository. So, the boss is forcing us to use SourceGear Vault. Now, the problem with it is that it uses the lock-modify-unlock model. The problem with this model, especially in our case, is that it locks every file automatically, when you start editing it. Now, that operation, usually, takes from 10 to 20 seconds. Imagine that - you open a file, you just want to add a few lines of code, you navigate to the right place, hit ENTER to start adding new code and Visual Studio hangs for about 12 seconds... And that happens each time you open a new file to edit. It isn't the only problem with Vault, but it certainly is the most annoying one. Another issue, worth mentioning, is that Vault's documentation is very incomplete and doesn't cover some important topics.

Now, what do I do? How do I convince my boss, that open source can be just as safe as closed source, commercial projects? I though about that and frankly - I have no idea...

Maybe I should show him the testimonials on Subversion project page. I should also, tell him about the certified Subversion binaries, available from CollabNet. Pointing him to Subversion Access Control from WANdisco, might also help.

I don't know, I guess, the moral of my post is this: if you have a software company, be careful with your opinion, don't be religious about anything - it might be the one biggest thing slowing down your developers.

Edit: I forgot to write about the other - closed source alternative to Subversion that is just as nice (or so I've heard). I'm talking about Perforce. From what I have found on the web - Perforce might even be a better than Subversion on some aspects. My boss should like it, because it's not open source. Well, if I fail to convince my boss to switch to Subversion, I'll suggest Perforce.

Software Release: Inkscape 0.46

Few days ago, Inkscape 0.46 was released. I used the older 0.45.1 release and I really liked it. But right now, I'll share my thoughts on the new release. So, here they are:

1. The very first thing I noticed was the new icons. Yes, it's not really an important improvement, but it surely looks good.
2. Second thing I noticed, was the dockable tool windows. I think this is one very important improvement - you can't get lost in the zillions of open tool windows anymore.
3. Third thing was the new drawing tools, here are the ones that got my attention:
   
   • 3D Box - well, I don't make three-dimensional illustrations, so it's not really important to me, but it surely is cool!
   • Paint Bucket - now that's the tool I really like, because I won't have to make those paths by hand, anymore.
   • Tweak - tweak tool is also very nice, it speeds up the work, when you need to tweak more than one path at the same time.
4. There is a huge amount of other improvements, that I will not cover here. I'll just point you to the Release Notes, that explain them all.
   

Unfortunately, I also have to mention one bug that I found after playing with Inkscape's new release for 10 minutes. I wanted to add some text to my illustration, and then I wanted to change the font - that didn't work. I don't really know why this is happening, but on my machine - the only way to change the font is to change it manually in SVG file. Other than that - I really love the new Inkscape.

Once again, open source community has done a really great job. Don't wait - grab the new Inkscape 0.46 and enjoy the power of vector graphics! ;)

I have a Job now!

Again, I have to apologize for the silence. It's becoming a habit, or something...

I have a good reason this time. I have Job! It is my dream job, really. I'll get to make desktop applications in C#. Sure, it'd be more interesting to make games, but I can't really complain - they gave me Visual Studio 2008 Professional, so I won't be struggling with the limitations of Express Editions. :P

So, in my last post, I promised you something about subversion, python and other open source projects. Well, this time, I'll have to promise you something about C#. ;)

The Silence

Sorry for the long silent period. There were a lot of stuff in my life going on and I didn't have time to post updates.

Hopefully, I'll be more active from now on. I still plan to make the god damn wizard (no, I didn't have time for it either). But before I do that, I will, most likely, post a few articles about subversion post/pre commit hooks, python and maybe some other open-source projects, that got my attention lately.

Software Release: Visual Studio 2008

Yes! Finally, Visual Studio 2008 was released. I have to admit, that I downloaded Visual Studio 2008 Express Editions as soon as I found out about them. So from now on - it is the IDE of my choice.

I didn't have much time to test it yet, but I already noticed a significant performance increase. I'm not really sure if it is the performance increase. Visual Studio 2005, even with the performance fix wasn't performing that well. So, if you are still hesitating - don't! Get the new version and enjoy it!

There is one catch with the official Visual C++ 2008 Express Edition release, though. In the FAQ it says that there are no restrictions on the express editions - you can create commercial applications free of charge. However, the Windows SDK version express editions install on your system is 6.0A release. Now, this is very odd, because 6.0A is the pre-release version. As a general rule with all Microsoft products' pre-release versions - they are only meant for personal-use and testing purposes. So it is actually a mystery to me. I tried asking on Windows SDK forum about this, and I was advised to get the version of SDK that isn't marked as pre-release, so I'm passing this advice to everyone! You should really get the Windows SDK 6.0 release just to be on the safe path.

And now, let's return to our own business. I started a series of articles about making a wizard for the Visual C++ 2005 Express Edition. Now, I don't use that version anymore. However, from what I know already about the Visual C++ 2008 Express Edition I can say, that I will be making the same kind of wizard for the new release. Note, that both editions are very similar, and wizard developed for 2008 will probably work with 2005 release as well (you'll just have to change a few strings in a few files). So, if you were waiting for that series of articles to finish - don't worry! I'll finish it! ;)

Software Update: Visual Studio 2005 Performance Fix

Ah. This is one of the nicest things Microsoft could have done! If you used Visual C++ 2005 (or any earlier version of it) with large solutions and projects - then you definitely know, that sometimes IntelliSense would often slow down things. Sometimes the slow down would be so big, that you'd have to turn off IntelliSense to be able to work on your project.

I haven't tested this fix yet, but I think it's going to be good! :)
And here are the links:
Microsoft's knowledge base article about the issue,
The actual fix download page,
A very nice VC++ Team Blog article giving more detailed explanation of the changes.

Note, that you will have to sign in to your passport account before you get access to the download page.

And once again - thank you Microsoft! :)

Customization: Custom Visual C++ Wizard - Part II

In the previous part of the series, I explained what I don't like about the default VC++ Project wizard. I also defined how those things should be fixed. So, by now, we have some requirements defined for our final wizard project. Let's continue planning our wizard.

So, what kind of projects we will be making with this wizard? Well, the most basic option should be there to simply create the Solution. When creating solution, it should also create directory for the source code, and add the common headers there. Now, we are facing the first problem. Visual C++ Express Edition doesn't support Solution Directories (or solution files), which means, that we either have to create a dummy project that would contain those headers, or we will not see those files in Solution Explorer window. Personally, I prefer the first option. So, our empty solution will not really be an empty solution - it will have a dummy project (I'll call it "Solution Project") and this project will contain a few header files.

What else? Well, as I mentioned in the first part - I like to have all my projects as a set of libraries, so the next obvious project type we'd want to generate is a Library. There are a three kinds of libraries I will want to generate. The only difference in those three will be the output file it generates. Now, if you remember the first part - I said I want four configurations (Debug Static, Debug Shared, Release Static and Release Shared). Basically, each configuration name describes perfectly, which C/C++ runtime the configuration will link to. I hope I don't have to explain, why linking to the same version of runtime is important across all projects in the solution... So, the three library kinds will be: Static Library, Shared Library and Mixed Library. You are probably wondering what the heck are those. Well, let me explain. In Static Library project, all four configurations will generate a static library (LIB file). In Shared Library project all configurations will generate a shared library (DLL file). In Mixed Library project, however, the both Static configurations will generate static, and the Shared configurations - shared library. In addition, when creating a Library project, I might want to create a Unit Test project for it too. Now, I know that not everyone likes to write unit tests, but I do, so I'll need this option.

Finally, the last kind of project is an Application. I can think of two application types - Console Application and Windows Application. I think those are obvious.

So what else can we plan? In the first part, I described what the directory structure should look like, but I didn't discuss naming issues. You see, when creating directories or naming files - there are a few things to be careful with. There are all kinds of special characters that you can not use in those names. Also, it is a bad idea in general to use paths with spaces in projects. So, whatever I enter as a project or solution name - it might not be possible to use them as the directory names and solution/project file names. So, the wizard could generate safe names for us. It could generate them, but it could also let us edit those names just in case we want that. Also, if I'm creating a library called "PM's Standard Library" I don't really want to include headers from that library by prefixing "pm_s_standard_library/". So, we will also need an abbreviated solution/project name.

Having discussed all that, I think it's time to start designing the pages of our wizard. However, that's the thing we will talk about in the next part of this article series. Stay tuned! ;)

Customization: Custom Visual C++ Wizard - Part I

As I told you earlier - I am using Microsoft Visual C++ 2005 Express Edition. Unfortunately, this version of Visual C++ has some limitations. One such limitation, is that you can not design custom project (or item) wizards with it and for it. However, a creative person such as me or you, might still figure out the way...

Yes, that is true. I know how to add wizards. I will try to make one such custom wizard and in the process of making it - I will post articles about what I'm doing.

So. What is the first thing you should do, when making a wizard? Personally, when I figured out how wizards work - I started making one. Planning is for pussies, right? Wrong! Plan every single thing in your wizard. It is very frustrating, when you have to start over and over again.

Ok, so let's start from the list of annoying things in the default (console project) wizard. Here is my list:

1. The default Debug and Release configurations.
2. Default settings in those Debug and Release configurations.
3. Solution and project directory structure.
4. Default generated code.

I'd be interested to see your lists (it might give me ideas), so please - feel free to leave a comment. Thanks! Now, let's proceed.

Here are the explanations of each item on my list:

1. I always break down my projects into small libraries. When I start developing those libraries - I never know if I'll want static library (LIB) or shared library (DLL). Also, I don't know which run-times I'll want to use in my final application (they can also be static and shared). So, it would be great if I could have a project with both. It means, that I want to start with four configurations: Debug Static, Debug Shared, Release Static and Release Shared. It doesn't really matter what kind of project I'm making - I always want these configurations.
2. Now, when I'm writing my code - I always set the warning level to the max (level 4). Whenever I create a project with the default project wizard - I spend 15 minutes or so going through Project settings. That is wrong! I want the wizard to set the correct values for me, so that I can create a project and start coding!
3. This is the tricky one. By default, Visual Studio solutions and projects have this directory structure:
   [solution] - top level solution directory;
   • [config] - each solution configuration gets it's own output directory;
   • [project] - project directory;
     • [config] - each project configuration gets it's own intermediate directory;
     • [project].vcproj - project file;
     • *.cpp, *.h, *.rc and so on - source files are all in this directory as well;
   • [solution].sln - solution file.
   Am I the only one concerned about the fact that intermediate files are placed in the subdirectory of the source code directory? I mean, when you hit "Clean Solution" - VC++ never cleans all of the files. There is always something left in that directory. So if you want to create a source code package (for whatever purposes), you have to manually delete those files. And the binaries? They are placed in separate directories in the top-level solution directory. Let's summarize. Here's how I imagine the perfect solution directory structure:
   [solution] - top level solution directory;
   • bin - executables (EXE and DLL files);
   • lib - libraries (all LIB files - DLL export libraries and static libraries);
   • src - source directory;
     • [solution] - top level source directory (so that we can have includes like this: "[solution]/[project]/[file].h");
       • [project] - project directory;
         • [project].vcproj - project file;
         • *.cpp, *.h, *.rc and so on - source files are all in this directory as well;
       • *.h - some common configuration headers;
   • tmp - intermediate files;
     • [config] - each project configuration gets it's own directory;
       • [project] - each project gets it's own intermediate directory;
   • [solution].sln - solution file.
4. Seriously, is there anyone who uses that default code? I talked to a few coders I know - they all say that they always check "Empty project"! The code is just wrong. It could be so much more useful. Anyway, we will make a wizard that will add a lot of useful code for us (it will be preprocessor macros, mostly).

So. I have defined what I don't like about the default wizard and I've defined how those things should be fixed (how they will work in my own custom wizard). This is it for today. The second part of the article series will follow shortly.

Something Obvious: Learn Your Tools

Yes! Learn your tools. It's amazing how many wannabe programmers who are just starting aren't really willing to learn their tools. Now, by tools I mean tools like compiler. Usually, if the compiler gives them a warning - they would rather learn how to disable that warning, instead of learning how to fix the code so that the compiler wouldn't give the warning anymore.

Let's say you are driving the car. Suddenly, on the cars panel, one of the lights starts flashing. You look at the light - it's flashing because you're out of gas. Now, what do you do? Do you disable the light so that it doesn't annoy you anymore, or do you fill the gas-tank?

Same with programming. All compilers, these days, are pretty smart. They're pretty good at detecting smelly code. And when they do detect such code - they issue a warning. Now, compiler doesn't do that only to annoy you. It does that because it actually wants to help you! Compiler is your friend!

The Tools: Documentation generator

The tools I've discussed so far have obvious use for every developer. This one, however is something different. Most programmers do not use any source code documentation generators. Heck, I started using one only a few weeks ago! I like it so far.

So, what tools should you consider, when you're developing applications with C++? Well, the first one I thought of was doxygen. It is probably the most popular tool in the world. Most of the open source libraries use it. You want my own opinion? Well, it sure can parse C++ code, though it generates some stupid warnings occasionally. The actual documentation comments are ugly. I mean, really, writing commands like \ref or $ref is ugly. If you're reading The Code, and not The Documentation - the comments are very cryptic and hard to read. Another thing I should mention is that I really don't like that doxygen doesn't let you customize the look of generated documentation. I would really love if it would let me fully customize the generated output (by supplying my own templates for class, function, member, template class and so on).

Another tool I've found was Natural Docs. Now, the first thing I want to say is that the documentation comments are great! It doesn't have any commands or tags. When you look at the source code - it just look like normal comments. However, the tool isn't perfect either. Its' support for C++ language is far from perfect. On the web site, it says that the update in this area is planned, though. So, when they implement full support for C++ language - this tool will become the best tool. But right now it's barely usable. Also, just as doxygen, Natural Docs doesn't let you customize the generated output. Oh, and the supported output formats are fewer.

There were some other tools I've looked at. Some of them look nice, some of them are awful, but none of them deserve a separate paragraph in this blog-post. Anyway, here's is the list of tools worth mentioning:

• Doxygen
• Natural Docs
  
• HeaderDoc
• ROBODoc

There aren't that many tools that generate documentation from source code...

So, what is my final word? I choose Doxygen. I will be keeping an eye on Natural Docs, but for now, I choose Doxygen.

The Tools: Text and Source Code Editor

Although IDE is the main tool to edit the source code, in some cases, you might need a good text editor too. Sometimes you just need to edit some text files (readme, license or something else), in some cases, you might even want to edit the source code without firing the IDE - a good text editor with syntax highlight is very handy in such situations.

Everyone could simply get away with Microsoft Notepad, although it's crappy if we talk about source code editing. The best free editor I've used so far is Notepad++. It isn't all that great all by itself, but it has some plug-ins that turn it into a very good source code editor. Namely, the Function List, TextFX and Light Explorer plug-ins are great!

The Tools: Version Control System

Version Control System (VCS) is a must for every computer programmer, even if he's not working in a team. It is important for a coder, because coding and experimenting are inseparable sisters. Sometimes, experiments fail and you have to (or at least - you want to) go back to where you were three days ago. Usually, in such situations, a coder would get really frustrated because he doesn't have any backups. However, if you are using VCS - you all of your backups. You jest check the log, figure out which revision do you need, and then you can easily roll back to that revision. I don't think I have to explain why it is a must when you're working in a team...

So, what is the VCS of my choice? It's Subversion (SVN) + TortoiseSVN. Yes, I have heard about Perforce, and it is probably very good (because there was a lot of people who suggested it on various forums). However, Perforce is not free (you have to buy the commercial Perforce license if you want more than 2 users or 5 workstations) - although I'm working alone, some people might join me in the future. Also, I don't really want to limit myself to open source projects - I might want to release some closed source projects as well. So, I just use the most popular free tool on earth.

Well, actually, I didn't really choose SVN - I already had it my computer (because of some open source projects in which I participate), so I'm really familiar with it and I don't really want to install anything else.

One thing to note. If you're worried that your computer might die one day - you can make backups of your SVN repositories. Personally, I make one backup each week - I actually sleep better that way.

The Tools: Integrated Development Environment

Integrated Development Environment (IDE) is probably the most important tool. It's the tool that you use to accomplish many things:

• Managing the projects.
• Managing build settings for your projects and individual files.
• Code writing.
• Building.
  
• Debugging.

So, what IDE do I choose? I choose Microsoft Visual C++ 2005 Express Edition. Why you ask? Well, first of all - it's the best free IDE for my platform. I only code on Windows (though, I always think about portability while coding). I do not use the .NET features (C++/CLI), but it still is the best tool. It takes a little time to set it up (I have to manually download the Platform SDK and DirectX SDK) but I think it's worth it.

Before Microsoft released this great edition for free - I was using all sorts of other IDEs and compilers and was never happy about them. The thing is - whatever IDE you are using - it must not get in the way. It must be intuitive to use. Other IDEs couldn't give me that. So, most of the times, I was using the free Microsoft Visual C++ 2003 .NET compiler (can't find the link anymore) and I was writing makefiles by hand (that's right!). But when the free 2005 Express Edition came out - I pick it up very fast, because it was very intuitive. I didn't have to spend hours struggling to figure out how to properly configure everything - it just worked right after I installed it.

As a last note, I'd like to point out, that although Microsoft Visual C++ 2005 Express Edition is stripped version (you can't use plugins), but it still has some extensibility features. One of them is that you can use the custom project wizards, and the other is that you can extend it with some external tools that it can run in the build process. If you think that these two are minor features that no one is using - you are wrong. After I experimented a little with them - I developed my own custom project wizards and I added some third party tools into the build process (the one I use the most is the UPX tool to compress my release binaries and I can configure it just as I configure the C++ compiler settings - in project properties).