I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)


Entries in software (13)


VPS for continuous integration

Continuous integration is a cornerstone of our development processes at Lokad. We are currently relying on CruiseControl.Net to support continuous integration.

Several months ago, I did ask on various web forums if any company would sell hosting packages that would natively include CruiseControl.Net. The only answer that I did get was Get yourself a $300 PC and use it as your continuous integration server. I was totally unsatisfied with such answers because the maintenance costs associated with the management of an additional machine are terrible. Indeed, if you assume that your time is worth $50/hour (which is already quite a low estimate if you are a moderately skilled developer); then, this additional machine will cost you more than $200/month assuming only 1h of maintenance per week (which is also a very low estimate).

At this level, it becomes clearly profitable to go for a rented cheap dedicated server ($100/month). Yet, the idea of paying that much for a server that would be used at 5% of its capacity was not entirely satisfying. Thus, we have finally chosen to go for a Virtual Private Server (VPS) that are available at much cheaper rates ($30/month).

Bottom line: VPS is really the way to go for continuous integration involving small to midsize software projects.


Weird consequences of full transaction logs

Let say that you have an ASP.Net 2.0 web application running on top of MSSQL Server 2005. Guess what happen if you database transaction log get full? Well, you will get a large amount of weird side effects, most of them seeming totally unrelated to the saturation of the transaction log.

Among the problems that I have encountered

  • The web services of your website start to send totally misleading error messages like authentication failed.

  • You can not login through web form into your ASP.Net application any more. You will not get any error message, but the login control just tells you that your password is wrong.

  • You look at your error logs (like ELMAH), but nothing gets recorded.

  • You decide to go through the "recover password" (because you're still no suspecting the transaction logs), but actually it fails and no email is sent.

For the note, the following SQL question clears your transaction logs


A few tips for source code versioning (do not drive your co-workers mad)

Source control management (SCM) is a technical matter as well as a good practice matter. Here is a small list of tips that I have found quite useful in practice.

A good commit is like a good paper:

  • It starts with an evocative title. Ok, there is no title in SCM but there are comments provided while committing. If your SCM comment is not clear, then how do you expect your co-workers to keep track of what you are doing? A good title takes time and so does a good SCM comment. Do not rush your commit omitting the SCM comment.

  • It has a clear self-contained content and focus. If you start working on many different files, you may end-up with a large commit covering many unrelated aspect of your software. Such a commit is hard to read for your coworkers because there is no focus. A lot of things are going on but nobody can really tell what did change and what did not.

  • It goes right to the point: Insignificant elements are left outside the scope of the article. Do not commit a file if the changes have no purpose whatsoever. Such situations arise easily when you've just added or removed a few blank lines.

  • The SCM comment is your title, eventually your headline, but it's definitively not the content of your paper. In particular, do not use the SCM comment to raise questions or ideas. Those elements must be handled directly in body of your commit, i.e. the committed files themselves. The SCM comments will be quickly lost in the SCM history, but the ideas/suggestions must stay until implemented or discarded.


Finally, I am going to be a theology teacher

According to Jeff Atwood (Coding Horror), software development is a religion. Wow, frankly I hope not, because I am quite ignorant when it comes to theological matters. A major issue with human/social studies and practices is that it is so hard to get close to anything that would be considered as scientific knowledge and not pure erratic opinions. Yet, it's not because it's hard to produce science that it isn't worth trying.

The recipe of scientific knowledge production includes a very fundamental ingredient: reproducibility. If somebody else can't, providing enough time and efforts, reproduce what you have observed then there is no hope to produce any science. For software development, the current situation is quite troublesome. Indeed, the pace of change in software development is totally dwarfing the speed of scientific production. By the time, a scientist would be able to produce a rigorous scientific analysis of software development (5 to 10 years), the software world itself would have changed so much that the study, at the time it gets published, would be already totally obsolete.

The second factor that complicates the production of knowledge is that software engineering actors do have very strong interests to defend biased positions. Science involves publishing both positive but also negative results (see the Journal of Negative Results - Ecology and Evolutionary Biology for example). Do you think that Microsoft, Google or [insert here your favorite IT company] are really going to publish anytime soon reports explaining how and why they failed miserably while developing some particular products? From a marketing viewpoint, you need to appear brilliant no matter how bad (or good) things might be in the office.


The unteachable parts of software engineering

Having the responsibility to handle the software engineering course at the ENS in spring 2007, I have started to think about the desirable qualities that make the difference between an average developer and a brilliant one. Indeed, I can't think of a better goal for this course but to actually try to develop such qualities.

What makes a "good" software developer?

It's an obvious fact that many qualities and skills are required to make a good developer. Smart and Get things done are often cited as the top criterions to decide whether a candidate should be recruited or not.

... a passionate curiosity for software related matter ...

I would complete those two criterions with a third one that I consider to be no less important: a passionate curiosity for software-related matters. Most well-known antipatterns such as programming by permutation, golden hammering, re-inventing the wheel, ... are caused by a lack of curiosity. There is far too much to know of the subject of software engineering to trust any particular school diploma (or certification) to be sufficient to produce even a "passable" developer.

Additionally, the software world is fast-paced. Hardware and software get obsolete alike. Development methods evolve. Better tools are released continuously. The sheer (intellectual) complexity of those evolutions is beyond what a single individual can possibly handle. Curiosity when leveraged through teamwork is a strong driver to actually maintain the development practices and tools as close as possible to a state-of-the-art level.

Finally, on the long run, I do not see how it is possible to stay motivated (and therefore productive) if there is no eager interest in mastering this constant flow of evolutions.

How to train such a developer?

I have listed smart, get things done and passionate curiosity as being the top qualities for a software engineer. But this list is more than troublesome for a teacher: it's not even clear whether any of those qualities can be actually taught

Concerning the first criterion, i.e. smart, I have simply surrendered all "academic" ambitions. The course schedule is far too short; beside I have the chance of having ENS students who are already very smart (though entrance exams have already filtered out students who were not so smart). Yet, the course can them the opportunity to apply their intelligence to a large variety of fuzzy problems that are inherent to software development.

The second criterion get things done is probably the most actionable element of the three. The French education system (highly selective and highly individualistic) usually produces people that are relatively weak against this criterion, the ENS students being no exception (quite the opposite in fact). I have planned to incorporate a student software project within the course mostly to push student develop a get things done mentality .

As for the first criterion, I haven't much ambition to actually transmit a passionate curiosity the students. In this respect, my first ambition will be to avoid the issue that usually plagues software engineering courses: an overwhelming boredom. I do not think it is really possible to create curiosity ex-nihilo if people have no interest beforehand. But, assuming that students are at least somehow interested (well, if not, it's going to be tough for the students and me alike), an "expand your horizons" strategy for the course might give them materials to apply and develop their curiosities.

There are two kinds of students: those who are too weak to be taught anything and those who are so strong that the teacher is totally unnecessary.

Bottom-line: out of three main qualities to make a good developer, the ambitions associated with the software engineering course I am thinking of are pretty weak. Well, considering the importance of the subject, I still believe it's a worthy attempt (stay tuned, more on later posts ... )