Salvatore Iovene

After all the dust raised again by Microsoft about Linux and the Open Source community allegedly committing patent infringements (235 this time, they were 228 in 2004), I really feel the need to spend a few words about the matter, or then, a few images.

It looks like the jealous Redmond’s zealots, avidly fighting to protect the uniqueness of their work (sarcasm intended), didn’t realize that they have been playing copycat for a long time, reinventing the wheel and doing a bad job at it. Do the following screenshots tell you anything?

Search page

Search results

Image search

News search

Maps search

Get new articles via email

Related posts:

• Leaving closed protocols behind
• Benefits of a weekend offline
• Architecture of patching semantic versus logical content
• Please drop SVN
• Please stop talking about iPhone clones

When writing source code, indenting is very important. Having a neat and clean programming style, let alone a precise and uniform one, is probably one of the most important keys when attaching example source code with a job application. I was myself asked to show some of my source code in my last two interviews. Nobody ever asked me to show any running program that I had made, though. Wonder why? A lot can be understood about the author just by glancing quickly at some source code.

Indenting makes the source code easier to read for us human beings, whereas the compiler doesn’t really care (except for some languages, where indentation applies as a syntax element). Even if you’re not a programmer, you can see the differences here:

Compiler friendly

Badly indented

Properly indented

There is, I guess, no question that the last one, labelled as “Properly indented”, is the most readable. Problem arise, though, when people start wondering what they should use as indenting character. Some prefer TABs, other prefer blank spaces. A TAB, the key on the left of the Q of most Qwerty keyboards, is a single character that a text editor can represent whatever way it wants. This is usually customizable by the user, of course, so she can decide that a TAB will be shown as 8 spaces, or 4, or 2.

You can hear all the time someone claiming, in turn, that TABs are evil or that spaces are evil, but the truth is that none is wrong, as long as you can indent.

I’ll use, as an example, a piece of source code taken from the ext3 module of the Linux kernel. The Linux programming guidelines recommend using TABs for indenting, and that they should be 8 spaces wide. Let’s have a look at some code.

8-space TAB

4-space TAB

2-space TAB

As you can see, the original intent of the author, was to have the variable names aligned. But that alignment gets screwed up as soon as a reader has a different space-size for her TABs. What’s wrong there? Let’s use a very useful Vim tip: the :set list command.

:set list

This way, we can actually see the TABs, as “>——-”. Of course there will be less dashes if part of the TAB area is occupied by some text. So, can you see what’s wrong with that? The author of that source code is using TABs not only for indenting, but also for aligning! That way his alignment gets messed up when somebody uses a different TAB size. The solution of this problem is to simply just use what ever you want for indenting, but use spaces for aligning. Indenting must only be that left margin that you give to some lines, but it’s not to be confused with alignment. If the author of that source code had used TABs at the beginning of the lines, but just blank spaces between the type and the name of the variables, his code would be as he meant it whatever indenting style one’s editor would use.

So, in the end, it doesn’t matter whether you use TABs or space, for indenting, as long as you use just spaces for aligning.

Useful Vim/Emacs tip

I like spaces, and add the following to the end of all of my source files:

/*
Local Variables:
mode:c++
c-basic-offset:2
c-file-offsets:((innamespace . 0)(inline-open . 0)(case-label . +))
c-tabs-mode:nil
End:
*/
// vim: filetype=cpp:expandtab:shiftwidth=2:tabstop=8:softtabstop=2

This way, if the reader uses Vim or Emacs (and maybe also gedit), her settings will be temporarily overridden by mine, so, if she’s going to change my code, there are little chances that she’ll mess up my indenting.

The :set line options I use are the following:

set listchars=tab:>-,eol:$,trail:.,extends:#

It helps me to also spot trailing spaces. I recommend everybody to use the :set list, as it will prevent you to accidentally mess up other’s indentation.

Get new articles via email

Related posts:

• 10 advice to write good code

After claiming that most programmers just can’t program, and actually addressing most of the problems to the lack of passion of people who decide to start a career as a programmer, I would also like to express my point of view on a tightly related subject: what can be done to improve the situation? The problem that I was trying to bring up in the spotlights, is that a lot of people just start (or wish to start) a career in the IT for no particular reasons. Those are the ones who don’t love and don’t loathe programming, and they just see it as something that pays their bills. Well, maybe the first question that I should address, actually is: why is this bad? Sure there are so many jobs which don’t require passion at all, and people just do them because a job is just a job, and don’t really care. In my opinion, being a programmer is different.

There are many people, especially the ones who sit high in the hierarchy of a company, who see programmers as the last and least important step of a ladder. They often think that programming is quite of an automated and repetitive task, and it could basically be done by anyone, with just a little training. Unsurprisingly, this seems to be the opinion of most common people, who ignore what programming really is. I wouldn’t want to discriminate among different types of programming, or different programming languages, but it’s obvious to me that programming, to some extent, actually can become an automated an repetitive task. That’s quite the minority of cases, though, so I will simply ignore them, and focus on the rest.

As anybody who’s a programmer knows, programming is a highly creative task, that requires good imagination and great problem solving skills. Everybody else might just see it as “typing stuff on a computer”, and believe me, there’s a whole lot of educated people who think that programming is a monkey matter. Hence the term “code monkey”. This term has historically been abused a lot, by even programmers themselves. A “code monkey” is said to perform a programming task so easy that even a monkey could do, as the image suggests. There are two truths about this phenomenon: first of all, luckily, programming requires far more skills than it’s usually believed; secondly, and sadly, the majority of people just ignore it.

The problem with lousy programmer is kind of similar to a medal: it’s double faced. You could actually call it a dog trying to bite its own tail: as programming is believed to be an easier and easier task, more programmers are needed; as more and more programmers are needed, more people will jump on the field; as more and more people try to become programmers, the lousier the average quality of programmers gets. Unfortunately, what average non-programming people miss to understand is that although it doesn’t really take a hard training to become a lousy programmer, it takes a damn hard one to excel in the art of programming. Moreover, most people just lack the innate logic mechanisms that make you a potential programmers. Such mechanisms are developed in your mind when you’re very young, and it’s quite rare to develop them after your twenty-somethings. With this, though, I’m not denying that there are a lot of people who actually do develop those mechanisms in advanced age. I’m just trying to think of the big numbers, here.

So, getting to the point, what went wrong and how can it be fixed? I don’t think it would be wise to say that what’s wrong is that there’s too much need of programmers, ergo the average quality was inevitably doomed to lower and lower over the time. I rather think that the problem is with education. Of course I can’t speak for all the universities and colleges in the world, but I can at least try and speak for the one I’ve known personally, or through people who have studied there. It seems that, as more and more people apply to Computer Science or related departments, the easier it gets to get in (sorry for the pun), and to get through with it, i.e. to graduate.

I know this happens most likely in any other faculties, but seeing that there are people who have been studying CS for three or more years, and still can’t get through the most simple concepts, just doesn’t seem right to me. Yesterday night, I was sitting in an IRC channel about the C programming language, when somebody joined in and asked:

“I just started studying structures in C, and I don’t get them. Can anyone explain to me what’s the use for them?”

Ok, I don’t really think there’s anything wrong in not getting the point of C structures right away, but after a little chatting, it turned out that the guy was in his second year of Computer Science, and this was the second time he took the C class. Still that wouldn’t be a reason of hatred, of course (not that I have any hatred), but after another small while it turned out that the guy didn’t like programming at all, but he just got himself into it because he applied to CS since he liked to “fiddle around with computers”.

What’s really needed, in my opinion, is a harder and less tolerant educational system, that would be more selective, rather than pushing everyone forward. People that find out to be really not made for it, should just give up and move their focus on something less.

I’m actually very well aware that a lot of programming work, nowadays, is not really rocket science, still this doesn’t mean that it should be done by completely unqualified people. If what Jeff Atwood says in his post about programmers who can’t program is true, and that is that 199 out of 200 applicants (not programmers, applicants) can’t write any code whatsoever, than it obviously means that something is wrong. Looking at the numbers provided by Joel Spolsky, it looks like a lot of these basically incompetent people are going to end up working on an actual programming job, and maybe their code will end up on The Daily WTF (Paula, are you there?).

Unfortunately, the education is not the only one to blame. No matter how much education will improve, there will always be unqualified people who are going to apply for jobs that require a lot of skills, and in the end the odds will help them, so they’ll manage to get a job as a programmer. Is it so bad, considering that it’s most likely not going to be any critical position, and the only ones that will be damaged will be the owners of the company that hired them? Well, the point is that this is not true. There’s someone else who gets damaged, in this scenario. I’m talking about the community out there, the good programmers, who find themselves competing with newbies who’re happy to earn peanuts. The salaries keep going down, and customers are not able to distinguish a good job from a good one.

In a comment on the previous post of mine about this subject, Hoowie Goodell really gets a great point with this paragraph:

“There has been a great effort to industrialize programming, too. Again, there are many good features, and it’s a field I’m interested in. Building a large program requires a structured approach. Language design, libraries, programming frameworks and IDEs can and should incorporate as much existing human knowledge as possible — computer science, domain knowledge, solid pre-written code and human interface principles. (Check out Thomas Greene’s “Cognitive Dimensions of Notations” for some of the latter — I think of how programming tools fail to use them on a daily basis!)”

In a way, this suggests that the whole system is not ready yet, as it’s indeed years and years behind several other engineering fields, and that’s a good reason, probably, to explain why it’s so easy to fail at being a good programmer. Let’s just try to get some insightful inspection points, in order to build better generation of programmers:

1. Better education.

   The whole higher educational system should be improved in several way. Worldwide. Nowadays, it looks to me that in many countries graduation is just a direct consequence of applying to an University. Unfortunately, this kind of problem must be addressed on a country-basis, to properly identify the specific issues, but still the options that I would like to consider are worth mentioning. It all comes down to a single point: there should be less tolerance towards people that don’t learn. The thresholds for succeeding in a course should be raised to greater difficulty. Current models of testing should be seriously revised, so to ensure that students that really didn’t understand the subject are not going to make it.

2. Better tools.

   Are we trying to make programming just like a building-chain or are we not? If we are, as it seems nowadays, then the tools are not ready yet to second our intentions. Programming is too error prone and too time-consuming.

3. Better process.

   Software process that doesn’t conform to some standards, say ISO-9000 (sorry if it’s inappropriate, I’m not an expert on this kind of standards), shouldn’t be allowed to sell. Quality insurance committees should be taken more seriously as being part of the process. This might be against all principles of liberalism, I know, as bad software, you may say, will not sell anyway. I know many bad software that did sell well, for greatly different reasons than its (non) good quality.

4. Better judgment when hiring.

   I’m not going to try to teach you how to run your company, nor how to hire your crew. But sometimes really crazy thing happen (again, is Paula around?). A very interesting post by Joel Spolsky (I’m sorry, I can’t find it anymore: does anybody know the link?) talks about only hiring “A”-people, where “A” means top class. If you’re ever hiring a “B”-person, he’s quite likely to hire a “C”-person, someday. After that, it’s chaos. I recommend anyone not to lower their canons of perfections. Here’s another great article by Joel, about hiring good developers, I recommend it.

Concluding, improving the quality of programmers seems really to be a tough issue, and the whole thing depends on so many factors that tracking a precise problem is impossible. Cultural and technical difficulties arise all the time, and getting clues is hard. I’ve tried to get around the problem and give some insightful opinions: what do you people think?

Get new articles via email

Related posts:

• Why most programmers are lousy
• How to write robust code
• (Web) Standards actually do matter a lot
• Please drop SVN
• Common mistakes when approaching OO design - Class dependencies

I’ve been in the IT field long enough to get to know many programmers, both experienced and just wannabies. During this time, I’ve realized that most of them are just bad programmers, simply said. I find myself agreeing with a brilliant post by Jeff Atwood, which alleges that programmers can’t program. What are the reasons for this? Many. Probably, IMHO, the main fault has to be addressed to the lousy education that people receive. But then again, the ability of giving education remains directly proportional to the ability of getting it, and where I see people complaining about low quality of education in University, I also see students with no interest in learning. Let’s see some of the reasons why programmers can’t really program.

1. Young people study Computer Science just because it’s a trend. It sounds almost unbelievable to me, but I must admit it’s mostly true. The vast majority of my old University mates just applied to the Computer Science department because… well: everybody was doing so. They followed the rest of the sheep.
2. Young people study Computer Science because they wouldn’t know what else to do. That’s really another strong source of applications to Computer Science. A lot of young people in their teenage years just don’t know what they want to do as grownups. Computer Science still seems to be a good career opportunity, so they just go for it.
3. Young people study Computer Science because they think it’s a sure way of getting a job. 10-something years ago there was a big boom, and if you just knew some HTML, were thought to be a computer guru. These types of belief mark a deep footprint on popular sayings, hence the wave of people applying to Computer Science just because they can work, is still there.
4. Many of today’s programmers, were doing nothing else than surfing the net or using Word till last year. Especially in small and vertical based markets, improvisation just rules. People learn something, and literally throw themselves on the field. Drawbacks for quality of their work are simply inevitable. This is not only a group of illiterate people that just jumped in to catch the big wave (what big wave, nowadays?), but people with no passion whatsoever. In other words, I don’t think it’s possible, nowadays, to become a great programmer if you didn’t start getting some interest in the field when you were very young, say about 10 years old (with the due exceptions, of course).
5. Many of today’s Computer Science students have no interest whatsoever in what they’re forcefully studying. Just put together the previous items in this list and what do you get? A bunch of people who just don’t care, who want to get their piece of paper (the degree) as soon as possible, and have absolutely no passion in what they learn. That’s the worst. I strongly believe that programming is not just a job like many others, but you need passion to get best at it.
6. A lot of programmers just don’t like to program. This goes for 100% of my ex University mates! Think of that: 100%. Of course it’s not the whole world but it makes a small statistics.
7. A lot of programmers just don’t get it. Not even the easy things. I was asked, few weeks ago, by a friend of mine who’s been studying Computer Science for now 4 years, what the difference is between a private and protected method in Java. Apparently reading the books isn’t enough anymore, nowadays. Another guy asked me: “I’ve studied pointers in C, and I think I understood them. Still I can’t find any use for them… are they really used at all?”.
8. Basically all of the programmers, or wannabe programmers, mentioned above, are miles away from the technical community. These people will totally ignore the existence of:
   • Slashdot and similar
   • RSS
   • Usenet
   • IRC (“Is that like MSN?”)
   • SVN and similar

As you can see, a really strong point, in my opinion, is the lack of care and passion for the subject of programming itself. Lousy programmers are bound to program to take a wage home; good ones are bound to program for the sake of programming itself. Or course you can do that but still miss to be a good programmer, but all falls down to numbers.

Get new articles via email

Related posts:

• How to improve the quality of programmers
• Steve Ballmer on the iPhone: pathetic
• How to write robust code
• 5 SVN best practices

I’ve been having quite a lot of trouble, lately, configuring irssi to work well with UTF-8. Irssi’s documentation was quite incomplete, on the matter, or discouraging, and there wasn’t much on the Internet, so, after figuring out what the way is, I’ll share it here.

First of all, you’ve got to make sure that your system is configured for UTF-8 locales:

bash-3.1$ locale
LANG=en_GB.utf8
LANGUAGE=en_GB.utf8
LC_CTYPE="en_GB.utf8"
LC_NUMERIC="en_GB.utf8"
LC_TIME="en_GB.utf8"
LC_COLLATE="en_GB.utf8"
LC_MONETARY="en_GB.utf8"
LC_MESSAGES="en_GB.utf8"
LC_PAPER="en_GB.utf8"
LC_NAME="en_GB.utf8"
LC_ADDRESS="en_GB.utf8"
LC_TELEPHONE="en_GB.utf8"
LC_MEASUREMENT="en_GB.utf8"
LC_IDENTIFICATION="en_GB.utf8"
LC_ALL=en_GB.utf8

If the output of the locale doesn’t look like that, you want to reconfigure your locales. On Debian, wha you have do is:

sudo dpkg-reconfigure locales

Here’s some screenies of what to expect:

Generating locales (this might take a while)...
  en_GB.ISO-8859-1... done
  en_GB.ISO-8859-15... done
  en_GB.UTF-8... done
  en_US.ISO-8859-1... done
  en_US.ISO-8859-15... done
  en_US.UTF-8... done
Generation complete.

Perfect, now that our system is configured for UTF-8, we want to configure our terminal emulator. If you’re using xterm, you can invoke it with the -u8 switch, or just do uxterm, and that’s all that’s needed. If you’re using the gnome-terminal, go to the Terminal menu, then choose Set Character Encoding and then UTF-8. If UTF-8 doesn’t appear in the list, you may want to try to logout and login again. While you’re at it, in the GDM login manager, go to the Language option and choose UTF-8 there too, so that it will be default.

Now let’s take care of GNU/Screen. In order to enable UTF-8, all you have to do is launch it with the -U switch:

screen -U -S irc

irc is just the name I want to assign to that screen session. Notice that if you want to switch a living screen session to UTF-8, you could do it for each window, using the command CTRL-a : utf8 on.

Once your GNU/Screen is configured for UTF-8, you have to finally set up your irssi client. This was, for me, the tricky part, since the documentation is a bit unclear, and I didn’t realize that my irssi wasn’t built with recode support. To make sure that your irssi is, fire it up and give the command

/recode

If you get something like

Target                         Character set

then everything is alright, otherwise, if you get a No such command error, you will have to reinstall irssi with recode support.

Irssi UTF-8 support is made so that you are able to recode to different charsets, depending on the server or channel you’re chatting in. First let’s set up some general options:

/set term_charset UTF-8
/set recode_autodetect_utf8 ON
/set recode_fallback UTF-8
/set recode ON
/set recode_out_default_charset UTF-8
/set recode_transliterate ON

These options will be the default, unless overridden for specific servers or channels. What do they mean?

• term_charset: this is the character set of your terminal emulator
• recode_autodetect_utf8: irssi will recognize UTF-8 input automatically and treat it consequentially
• recode_fallback: when we get some non-UTF-8 text from a chat peer, the text should be converted to this character set
• recode: this enables the whole recode thing
• recode_out_default_charset: this is very important: this is the default charset that you send out, unless differently specified by a server/channel rule (we will see that shortly)
• recode_transliterate: this enables transliteration of the closest match: i.e. if someone sends you a character that’s not in your charset, it will be transliterate to the closest possible one, or with a question mark, if none found

Now, you probably need different recodes on different channels, because you may speak different languages on different channels. For example, I send out UTF-8 when typing on English speaking channels, and ISO-8859-1 or ISO-8859-15 when typing on Finnish or Italian speaking channels, so people on the other end will always get my characters right.

You need to add rules with the /recode command:

/recode add ircnet/foo ISO-8859-15
/recode add ircnet/bar ISO-8859-1
/recode add freenode/gee ISO-8859-1

Those command will make you “speak” ISO-8859-15 on #foo on IRCNet, and ISO-8859-1 on #bar and #gee in freenode. Everywhere else you will “speak” UTF-8.

And this is what we get: here I’m typing (er… I’m copy-pasting from Wikipedia) some text:

If you connect via SSH to a remote machine, where you run irssi inside screen, all you have to do is to set both systems to use UTF-8, as explained in the beginning of this article, and then set the terminal of the machine from which you SSH, to use UTF-8, as explained earlier.

Get new articles via email

Related posts:

• Benefits of a weekend offline
• Dear Steve Jobs, give me an SSH iPhone
• Darcs - The source code management system of the future?

There has been some fuss generated by Jeff Atwood (who is a Windows developer, which is bad, and a Visual Basic one, which is worse), who seems, in my humble opinion, to be giving partial information around, as closed in his Windows-only world as he appears to be. In a recent article of his, Jeff makes a basic comparison between the ZIP and RAR compression systems. Unfortunately, most Windows people completely ignore that there’s something much better out there, that has been floating in the *nix world for quite a long time now. I’m talking about the powerful combination of tar and bzip2.

Let’s get to the facts right away. To experiment around, I’ve used a directory containing the source code of the Linux kernel, then I built that kernel, so that the size of the directory would be pretty big, and we would have both text files and binary files.

Here’s the size of the original directory:

$ du -sh /usr/src/linux-2.6.18.3
539M    linux-2.6.18.3

This is what happens with ZIP:

$ time zip -r ~/linux /usr/src/linux-2.6.18.3
...
real    2m35.917s
user    0m32.486s
sys     0m6.024s

$ ls -gGh ~/linux.zip
-rw-r--r-- 1 141M 2007-02-24 01:04 /home/siovene/linux.zip

Fine, 141Mb in 2 minutes and 35 seconds. Let’s try RAR:

$ time ./rar_static a ~/linux.rar /usr/src/linux-2.6.18.3
...
real    5m8.715s
user    2m14.012s
sys     0m12.473s

$ ls -gGh ~/linux.rar -lh
-rw-r--r-- 1 132M 2007-02-24 01:26 /home/siovene/linux.rar

Ouch! Double time and just a slightly better compression! Let’s try TAR and BZIP2:

$ time tar cv linux-2.6.18.3 | bzip2 > ~/linux.tar.bz2
...
real    4m22.265s
user    2m38.134s
sys     0m5.608s

$ ls -gGh ~/linux.tar.bz2
-rw-r--r-- 1 90M 2007-02-24 01:09 /home/siovene/linux.tar.bz2

Not too faster than RAR (but using two programs communicating through a pipe, so some overhead), but much more efficient! The compressed file is only 90Mb starting from an original uncompressed of 539Mb

Let’s summarize the data:

Method
Time
Size


zip
2m35s
141Mb


rar
5m08s
132Mb


tar.bz2
4m22s
90Mb

In conclusion, you should use the best tools, interdependently from their popularity, and remember that there is so much more than what you can see from your Windows-user-perspective.

Get new articles via email

Related posts:

• 10 advice to write good code
• Please stop talking about iPhone clones
• Win32 odyssey: who needs documentation?
• (Web) Standards actually do matter a lot

Inspired by a certain patch that hit a darcs repository to which I concur, I would like to talk about one thing that developers don’t seem to get very often, when using revision control systems: the structure of your files in the repository should have nothing to do with the logical units that make your patches, or with the comment of your patches themselves.

Yesterday, I saw this patch hit the repository: “Adding Cloth.h to the repo“. The patch was adding an empty file, named Cloth.h. What’s wrong with this? A couple of things:

1. The patch adds no logical value unit to the repository, but merely a technical value, i.e. an information about the content of the repository itself, which is, then, absolutely redundant, as you could retrieve that information in a separate (and more proper way), which of course depends on the revision control system you are using. Indeed it was just a technical information. Furthermore, the fact that the file was added, would have been there and obvious also without having to dedicate a single patch to it.
2. The comment (”Adding Cloth.h to the repo“), once again, doesn’t make any logical sense of its own, as adds an information that was already available using the revision control system tools.

What is a better way to do that? A patch named “Preliminary support to clothes“, which would add the file Cloth.h with its content, even if not yet functional, makes perfect sense. It means that you’re adding some logical value to the repository, and the value that you’re adding has nothing to do with the way that value is represented (the file Cloth.h), or that it’s being actually added to a repository.

In other words, the form and content of patches should not only represent single units of implicit logical value, as discussed earlier, but should have no awareness whatsoever of being part of a revision control system, or being uploaded to repositories, contains file, or even being patches at all!

Read more versioning tips here.

Get new articles via email

Related posts:

• Please drop SVN
• Who wants to talk about patent infringement?
• TABs vs Spaces. The end of the debate.
• 5 SVN best practices
• Please stop talking about iPhone clones

I can read, basically every other day, some website going nuts about some iPhone clone. Just few minutes ago I read about the nVidia GoForce 6100, and googling for “iPhone clone” really confirms the fuss. Well, the truth is that the iPhone actually is the one coming late, possibly the cloner, rather than the cloned.

I’m not working at Apple Inc., but, being a software developer and happening to have also worked for a while in the development process of a high tech device, I know, as many others, that the process that leads to the birth of a complicated gadget like the iPhone, takes years.

Digg.com has gone completely crazy about the subject. A Google Search about that subject on Digg, returns 5520 results.

Given that Apple Inc. will release the iPhone only next Fall, and that there are many devices already out there, which have been yelled at as mere “clones” (absolutely disrespectfully, IMHO), how can you people abuse the term so much? I’m assuming that nothing really serious leaked from Apple, so the competitors didn’t just rush to make their own touch screen phones. The truth is that the technology started to be ready, and the market started to be ready too, at the same time. Some people missed the opportunity and couldn’t even accept it, some other realized the chance and went for it.

I hope that the abuse of the word “clone” will cease to exist, and that, from now on, everybody will just talk about “another touch screen phone”.

Here’s a photo-list of alleged “iPhone clones” so far.

Samsung’s Ultra Smart F700	Asus Aura
Meizu M8	LG KE850

Get new articles via email

Related posts:

• Steve Ballmer on the iPhone: pathetic
• Dear Steve Jobs, give me an SSH iPhone
• Fixing NVIDIA driver after a xserver-xorg-core upgrade in Debian and Ubuntu
• Benefits of a weekend offline
• Useless fuss about ZIP and RAR

SVN might be stable, it might be mature, it might be successful, and it might be the winning source control system of the moment. There’s always a big risk of resulting unpopular, when criticizing something that actually did find its way to success, but I have to say that SVN sounds terribly antique sometimes.

I have already given a brief introduction to the Darcs source control system, and I would like here to talk about a very strong point it’s got against SVN.

Just yesterday, at work, I needed to commit certain modification to SVN. As I examined the diff of my local copy with:

svn diff

I realized that one of the file also contained some other modifications that I didn’t want to commit. After using Darcs for several months, I was suddenly hit by the shocking truth: SVN doesn’t allow interactive and partial patches, which Darcs names hunks.

What do you do in that case? Provided that there are people who actually abuse the Save as… function of their editor by saving multiple copies of the same file according to the logical patch they contain (which I find absolutely horrible), the quickest way I could find was to:

1. Making a diff: svn diff > logical_patch_1.diff
2. Edit the diff manually, until I had two files, which represented the two logical diffs
3. Revert the pristine: svn -R revert .
4. Apply the first diff: patch -p0 < logical_patch_1.diff
5. Commit: svn commit
6. Apply the second diff: patch -p0 < logical_patch_2.diff
7. Commit: svn commit

With Darcs, all you have to do is issue the darcs record command (which records your changes):

1. Record: darcs record -m "First logical patch (fixes bug 1234)"
2. Answer “yes” to the first hunk, and “no” to the second.
3. Record again: darcs record -m "Second logical patch (fixes bug 5555)"
4. Answer “yes” to the only hunk

Can you see the difference? It’s not just about the number of operations needed, but the quality of them, and the fact that Darcs is perfectly oriented to this kind of flexibility. Please consider switching to Darcs for your projects and work, as it’s a mature and better system.

Get new articles via email

Related posts:

• 5 SVN best practices

For some time, in the last months, I have been using, both for work and leisure purposes, the ACE library. ACE is a very powerful, useful and portable framework, oriented to networking, but that can be used for abstracting nearly any system dependent task. In my case, I’m using it for two client-server architecture projects, one of which is the MMORPG I’m working on.

ACE has had, for me, a pretty nasty learning curve: at first there are some good tutorial, and plenty of examples and test in the installation directory, but after a while you are probably going to need to purchase the books, to master it. I really can’t blame the author(s) for that, as ACE is an impressive (I mean it) work, and deserves some revenue.

Using ACE for my projects has turn out into an incredibly useful outcome: I do all my development on GNU/Linux machines (Debian Sarge at work, and Debian Unstable at home), but the code I write needs to be ported to the Win32 platform as well. I’m no Windows programmer, and no Windows user, and there are other people in my company who take care of integration with Win32 systems. After writing my client/server project for about two months, it started to get usable, and we decided to port it to Win32, and, to some extent, we were expecting some trouble in porting to Win32 an application that went on for two months and was made of roughly 10 thousands lines of code. The project is a server process plus a dynamic library communicating with it, that a UI client can use. Well, the porting to Win32 took no more than half an hour, and just a few changes needed to be made. Of course, during the development, I’ve been caring of not using any system dependent code, but the facts that it took so little to port, was simply amazing.

The ACE library has provided for me lots of platform independent things: a way to manage sockets and TCP connections, a way to manage loading of external programs, a way to manage threads (and related mutexes or locks), a way to manage logging, a way to manage tracing, and many more.

You can check this address for some good ACE tutorials, especially regarding the client/server communication. In my cases, I’ve gone for an approach orientated to a system that would handle one client connection in a dedicated thread. Thanks to ACE, this has been very easy and controllable. By controllable, I mean that I’m quite sure that the code I’ve produced, to that regard, is practically bug free. ACE helps you very well in taking care of all the errors and reacting accordingly. Due to the vast number of platforms ACE supports, it lacks exception handling, which can be considered a bad point, although necessary. To some extent, though, ACE can support exception handling, even if, for portability and integrity reasons, it’s advisable to let it go and rather use the classic return value checking approach. Nothing will anyway impede you in creating your own exception handling layer on top of your classes which manage ACE.

ACE is really strongly Object Oriented, which makes it perfectly suitable for large (but well engineered) projects. Needless to say, that ACE is not advised for very simple projects, unless you just want to take advantage of the system abstraction it provides. For larger projects, instead, you’d better be very careful and plan in advance. If you don’t know the system very well, you might end up making some wrong choices and wasting time. To this concern, I advise to read the books.

ACE is also very useful when it comes to logging, as it provides some really simple but powerful macros that can be used in debug mode, and that will produce no code at all if disabled. You can check this website for an introduction to the ACE logging facilities.

I will end this short article with a list of pros and cons about ACE, as I’ve found out during my experiences.

Pros

• Very portable.
• Very powerful.
• Good initial learning curve.
• Huge list of features.
• Many examples.
• Great mailing list support (even though they remind to reading the books too often).

Cons

• API are not very well documented.
• You need to purchase the books to master it.
• No free binary releases.

What I advice it for
Any large project that need to manage networking and multithreading.

Get new articles via email

Related posts:

• Common mistakes when approaching OO design