Semantic Versioning

Another "found" on the depths of the Internet that I want to leave here for future reference:

http://semver.org

It describes rules for versioning that can be applied to almost anything in software.

A Jewel: MKLINK

Here I am, late to the party - Microsoft launched mklink back in Vista days, but somehow I managed to miss the fireworks. There must have been fireworks, man! MKLINK will save your so many times now that you know it exists, that you will wonder just how you made it before.

The real thing about MKLINK is not MKLINK itself - it's just a command-line utility to create file system links. But: file system links! That is the deal. You see folks, I have some *nix background. During college I worked on that OS a number of times, and later on I was part of some projects that had back-ends hosted in a fine Red Hat rig. In any case, I always missed two things about *nix. The first one was the command line shell (bash) along with all the command line utilities and the second one is file system links.

"Just what are file system links?” you may be asking. Links resemble Windows shortcuts. In fact, it works very similarly to them, but there is a large difference inside: Intel. Oh, wait, that’s not it. With file system links, you can create entries in the file system that point to other entries that are already there.

There you go, the most obtuse definition I have ever written. Let us try again. When you create a link, you point that link to something. The operating system then creates a "fake" file on the system that actually is just another path to access that file. To any application and, in fact, even in the Windows Explorer, they pretty much like the file they are pointing to. And yeah, you can do that with folders as well.

Just one more thing to consider when talking about links: they can be either hard links or symbolic links.

With symbolic links, you essentially get the same thing as shortcuts. The link points to the actual record which points to the file. This means that if you change something like access permissions for the first file, it will affect the link. Symbolic links can also get "broken", in case you delete the original file that points to the disk.

Symbolic Links

With hard links, there are no differences between the original entry and the link entry (see picture). The operating system effectively duplicates the record that points to the file on the disk, which results in you having two files that are actually the same (the file is removed only after you delete both entries). Hard links are more powerful but have lot of restrictions; you cannot hard link to a directory, and you cannot have hard link between drives.

Hard Links

Ufs! I hope I made some sense. In any case, if you still don't get it, check the Wikipedia entry. For now, let's focus on MKLINK. 

SCENARIOS

There are many cases where you might want to use links. I will use a complex scenario, but one that bugged me for a while.

I once worked on a project in which my team was building a .NET application. The application was build in many layers, and the team decided it was best to have distinct solutions for stuff like back-end or front-end code. So we had at least three solutions that produced different DLLs that where necessary to actually run the application. That may have made managing multiple work streams easier, but it was hell to get stuff to compile -- we had to get a number of DLLs out of the Debug or Release folders and then copy then over to the same location, and then start the application.

Of course, we automated the copy process as part of the build process, but that was not perfect: for instance, if I made a "clean" in the solution, the DLLs wouldn't be erased from the "common folder" where we copied everything.

This let to infrequent but worrisome problems, for instance, the COPY command could fail and then the application would be ran with out-of-date DLLs. It also meant a copy step after build, one that got steadily slower as the application grew.

We could have used links to solve at least part of those problems. All I had to do was to make a small script that, whenever activated, would clean the "common folder" and then create there a symbolic link pointing to the DLL in the Debug folder of each solution. This step did not had to occur at each compilation, as the symbolic links would always point to the new file. If I cleaned the solution, all DLLs in the Debug or Release folder would be erased and the links would be broken, so I wouldn't be able to run the application with outdated DLLs.

Another interesting scenario is sharing a file between two applications: maybe it is a large, read-only file, like a picture or even a library or executable. Instead of having the duplicate residing in your machine, using twice the space, you can use MKLINK to create a hard link, which will result in two files that use the data on the disk, saving the space.

One final example: Let us say that you want to synchronize your folders using a tool such as Dropbox, but pains you to have all your neatly organized files stashed in the same, outlandish folder, like C:\Dropbox. With symbolic links, you can organize a directory tree in the Dropbox root folder and then create a bunch of “symlinks” to those folders in your computer, like this:

"C:\Users\bruno.brant\Project Data" à "C:\Dropbox\ProjectData"

"C:\Users\bruno.brant\Desktop\Downloaded Applications" à "C:\Dropbox\Downloads"

Notice that the name of the links is not necessarily the same name as the folder it points to.

This goes a long way into getting stuff organized. Double clicking any of those folders will take you to the Dropbox folder and it will be completely transparent to your applications.

SYNTAX AND USE

The tool syntax can be recovered simply by typing mklink /? in your oldie CMD, like this:

C:\> mklink /?

Creates a symbolic link.

MKLINK [[/D] | [/H] | [/J]] Link Target

        /D      Creates a directory symbolic link.  Default is a file

                symbolic link.

        /H      Creates a hard link instead of a symbolic link.

        /J      Creates a Directory Junction.

        Link    specifies the new symbolic link name.

        Target  specifies the path (relative or absolute) that the new link

                refers to.

Let's say you want to create a new link that implements the mapping I talked about in the final example above, pointing from my downloaded applications folder to Dropbox. All I'd do is:

C:\> mklink /D "Users\bruno.brant\Project Data" "C:\Dropbox\ProjectData"

This simple command will result in a new folder in your Users directory which, when opened, always shows you the exact content in the dropbox folder.

RESTRICTIONS

There are a few restrictions to links, as there should, considering they are not really files.

You cannot use hard links to points to directories. As I said before, hard links are "duplicates" of files, and the main idea is that you get two different entries which points to the same location in the disk. However, directories do not point to places in the disk, they only point to files. If I duplicate a directory, what happens if one creates a file one of the directories? The duplicate would have to be updated, but then this means a relationship between the two... which is exactly what symbolic links are!

You cannot use hard links to point to a file in another partition or unit. The reason is that if the file entry belongs to one partition, its data have to be in that partition. It would be illogic to expect that a file in unit C is actually stored in unit D or a removable drive. However, you can use symbolic links for that, since Windows already expect that symbolic files do not represent actual files but point to them, in a fashion.

Thinking About Your Products As Solutions

The post by Dan Shipper about a talk he had with 37signals' visionary Jason Fried was one of the best reads I've had in blogs recently. One could (but shouldn't) summarize it as "stop thinking about products and start thinking about solutions".

The first thing that you need to find out is what job your product does.

This is something I learned a long time ago and has been in my mind more frequently theses days. I first heard of this concept in a class back in 2002. A professor asked us about McDonald's business. "Sell food" or "sell hamburgers" were most of the answers. "You're wrong", he told us. He said, "McDonald's sell us a full solution package". McDonald's specialty is a solution for parents. You take you kids there and buy a Happy Meal, which includes enough, tasty food to get them satisfied. They also get a toy that will entertain them for a few hours and, on some stores, get to play in giant toys outside.

Dan Shipper talks about how customers are always switching to your product from something else. In some cases, it's another product. But when there isn't a competitor product involved, they are switching from a process or even something entirely different.

That means one of two things: either you don’t understand your product, or no one wants what you’re selling. Every product has competitors. Sometimes they’re other products and sometimes they’re human processes.

I for one will try to keep all those ideas in mind when designing my next project. What are people switching from? What is the real goal of my product? What value does it actually brings to the user? Those are all important question that all of us need to answer very early in the designing process.

5 Tips for Presenting to Executives

I think this presentation is good value even if you are not presenting to executives, as it covers how to build a presentation that delivers the message fast. Just to give you all a glance:

Nice insights, huh? It's really worth reading.

5 Tips for Presenting to Executives from speakingppt

Changing the AudioScrobbler Password Through Registry

So my Winamp's AudioScrobbler plugin (legacy) stops working. The reason: I changed my password in Last.fm but didn't update the plugin settings. Which would be simple, if the plugin didn't crashed Winamp whenever I try to open the configuration screen.

So, after my memory worked and told me that the reason was actually the password, and after I searched the net for a new plugin version that wouldn't crash and found nothing, I decided to change the password by myself. 

First I looked at the Winamp's plugin folder (Winamp\Plugins) for a configuration file. I was pretty sure the file had to be there, after all, you deploy plugins in Winamp by simply coping the DLL to that folder. And I know some AudioScrobbler files are there - I fumbled with it's cache once back in 2007. However, besides the cache and a log, I couldn't find any files.

Next stop: Windows registry. A quick find for "AudioScrobbler" did the trick, and there it was, a key named "password"... which, my wits told me, ought to contain my password! Fortunately, I remembered the old password: key was hashed and I needed to find which algorithm was used. So I tested a few, producing hashes from my old password: SHA-1, SHA-2, MD5... bang! The key was hashed with MD5. Easy enough.

All I did then was produce a MD5 hash of the new password and replace it in the key. After firing up Winamp, I checked the log to make sure the connection was working again and that's it. 

P.S.: I shared this story just to show how we can use our programming knowledge to solve problems without programming and because it was a long time since I last did some dirt trick like this, so I felt a little proud of myself.

P.P.S.: Also, the website linked to above has the source code for a previous version of the plugin. Maybe, if I find the time, I'll update it so it doesn't crashes in Windows 7 x64 and post it in GitHub. I don't know how many people still uses this plugin (or even Winamp for that matter) but I love it and want to share it.