Filezilla and the trash

Filezilla took a lot of time lately after I gave the command to delete a local file or directory. Like ten seconds before the file or directory was deleted. That is really unacceptably slow, so I fired up sysinternals procmon to see what was happening.

Filezilla turned out to be browsing through my trash stuff before deleting the file which I requested to be deleted. There were really a lot of items in the trash, so it is obvious why Filezilla became so slow. I emptied the trash and Filezilla was happy again.

Less obvious is: why is Filezilla browsing through my trashed items? Or is it a system "feature" for which Filezilla cannot be blamed?

One of the advantage of open source libraries

Today I once again experienced one of the great advantages of using open source libraries over using its closed source equivalents.

For our core library, we make use of several open source components, Nini being one of them. In our case Nini is used to read and write INI files.

Recently we discovered that a problem in one of our product had to do with this library. The library simply "ate" characters behind a double quote if the double quote was part of the setting.

[Blocks]
Block1 = Something, "Some caption", 1

The output would be:

Assert.AreEqual("Something, ", getValue("/Blocks/Block1"));

After discovering the Nini library was the cause, we decided we should investigate if we could solve the problem ourselves by creating a patch, since the library is open source. So we downloaded the code and opened it in Visual Studio. After some browsing through the code however, we quickly found a workaround: set the ConsumeAllKeyText property true on the IniReader instance.

With a closed source library, problems like this are as likely to occur as with open source products. The huge advantage of using open source in this case is obvious. If you're using a closed source product, you can only hope and pray for support in case of problems. With open source libraries, you can take things into your own hand.

Git: my personal MS SQL server data time machine

I had to solve a bug that was caused by inconsistent state, persisted in MS SQL server. The bug could be reproduced. But it did cost some effort and you had to start over again once the bug had manifested itself to reproduce it again.

Git to the rescue. The solution was simple: with a few git commands, I created my own MS SQL server time machine. I added the raw SQL data to a Git repository, and now I can not only go back and forward, but I can also create branches, to mimic specific situations. I can now reproduce the bug, do my analysis, revert, reproduce again, etc. Very nice!

Here's a description of how to do this.

• Stop sql server (via SQL management studio or using services.msc)
• Go to C:\program files\Microsoft SQL Server\MSSQL.1
• Right-click on the folder "MSSQL" and choose "git bash here"
• git init
• git add .
• git commit -a
• Enter a nice comment (with vi: press i, enter your comment, press escape, press :wq)
• Create a branch for the data that is needed for this bug and switch to this branch: git checkout -b newbranchname. In my case: git checkout -b bug-1577
• Start sql server again

Now I made the changes to get to the situation where I could reproduce the bug. To save this state, do the following.

• Stop sql server
• Go back to the git bash on C:\program files\Microsoft SQL Server\MSSQL.1\MSSQL
• git status if you are a control freak (or just curious)
• git add . if you like the newly added logs and traces
• git commit -a with appropriate comment
• Restart sql server

Now you can go ahead and test the data or bug. If you want to restore the situation, just do the following:

• Stop sql server
• git checkout -f = undo all local modifications
• Start sql server

These last steps can be automated with a simple batch file:

net stop mssqlserver
git checkout -f
net start mssqlserver

There is a downside. It costs a lot of diskspace because SQL server seems to change each and every database every time. So each commit will add the entire data directory to git again. You can avoid this by comitting only invidual files. But, on the other hand, your time is probably more costly than disk space.

Once you get to know Git, you can't do without it any more.

Map a checkbox to an action parameter in ASP.NET MVC

Mapping a checkbox to an action parameter in ASP.NET MVC is not trivial. At least I did not find trivial solution.

To get it working, use the following code:

<input type="checkbox" name="SomeName" id="SomeName"/>
<script type="text/javascript">
  $('#SomeName').click(function() {
    $(this).attr('value', $(this).attr('checked'));
  });
</script>

You Will Be In Trouble

In one of the companies I worked, we used to have a Duct Tape Programmer named Richard. Richard didn't belong to the development department, but released "tools" for internal use in the company. He shipped fast, as expected from a Duct Tape programmer, and people seemed happy with the products.

But after the first quick release, the disadvantages of the Duct Tape Programmer soon became obvious. Richard never could release a second version of the product because he had no time left to spend and was always occupied with a very urgent next project. The tools he released were always a preview and buggy.

He did sometimes ask the development department for advice on this or that. But it always ended in an argument about "why do it in such a complicated way", and he hacked the tool together with some very nasty anti-patterns.

One of the last projects Richard did was a project to make some data available from the source code control system to another system to keep track of client wishes. After some very busy weeks, he finally delivered the product. And it worked, it did actually make the data available to the other application.

A few days later, I talked with him about the project. He complained that it had been very hard to make the tool, since the SQL tables the SCC system used were so complicated. I asked him the obvious questions: doesn't the SCC system have an API to talk to? What if a new version of the SCC system involves a change in the SQL schema? Yes, there was an API, but it was "very hard to use" and a new version "will probably not change the SQL schema, why should it?"

It is another bad example of taking a shortcut by which You Will Be In Trouble. Not in the short run, because the tool works with the current version. But eventually, You Will Be In Trouble. Fortunately for the company, Richard doesn't work there anymore. There will be another tools expert to clean up the mess.