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 (15)


Improved "Run external program" through environment variables

Dynacom is a Canadian accounting software that provides an add-on development framework named Synergy. We have started to work on an integration of the Lokad Desktop Sales Forecasting with Dynacom. This post might interest developers who want to integrate together several windows applications (we are considering Dynacom here, but the process would be quite similar for another application).

Basically, Dynacom provides build-in custom action Run external program; yet, this action has a huge drawback: it requires either your application to be part of the PATH on the client machine or it requires to provide an absolute file location (which is likely to vary from one machine to another). A lazy approach would consist in letting the user manually enter the application path; but this approach is likely to be a huge pain for the average user who may not be familiar with the location and the content of the Program Files directory.

Thus I have decided to create a Windows Environment Variable dedicated to Lokad Desktop Sales Forecasting. In the Windows Installer XML packaging script, I have added the following lines

<Environment Id="LokadDesktopPathVariable"

to get a new LOKAD_DESKTOP_PATH environment variable to be created at install-time (see Sourceforge for the full WiX script). Note that [INSTALLLOCATION] is a variable name; it might be different in your WiX script.

Then, in Dynacom, we retrieve the content of the LOKAD_DESKTOP_PATH environment variable though an Execute script action. The following VB-Script code illustrates how it is done.

Sub Main()
Set wshShell = CreateObject("WScript.Shell")
lokadPath = wshShell.ExpandEnvironmentStrings("%LOKAD_DESKTOP_PATH%")
lokadPath = lokadPath & "Lokad.Windows.SalesForecasting.exe"

' HACK: triple-quotes are actually needed to support path with spaces.
wshShell.Run """" & lokadPath & """"
End Sub

At the end, the Dynacom user will get an integration that is both straightforward and robust.


The quest of the fail-proof hosted service

There isn't many 100% reliable hosting providers; yet when I buy an hosted subscription plan, I expect no less than a 100% uptime services.

So far, I have discovered only two fail-proof hosting services

  • blog hosting, not a single issue for more than 3 months of service.

  • Subversion hosting, not a single issue for almost 1 year of service.

Such a quality of services is truly worth to be mentioned and praised.


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.