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 build (4)


Lokad.Translate v1.0 released (and best wishes for 2010)

A few weeks ago, I have been discussing the idea of continuous localization. In summary, the whole point is to do for localization (either websites or webapps) what is done by the continuous integration server.

Obviously, the translation itself should be done by professional translators, as automated translation tools are still light years away from the required quality.

Beyond this aspect, nearly all the mundane steps involved in localization works can be automated.

This project has taken the shape of an open-source contribution codenamed Lokad.Translate. This webapp is based on ASP.NET MVC / C# / NHibernate and targets Windows Azure.

This first release comes as a single-tenant app. We are hosting our own instance at but if you want start using Lokad.Translate, you will need to setup your own.

Considering that Lokad.Translate is using both a WebRole and a WorkerRole (plus a 1Gb SQL Azure instance too), hosting Lokad.Translate on Azure should cost a bit less than $200 / month (see the Windows Azure pricing for the details).

Obviously, that's a pretty steep pricing for a small webapp. It's not surprising that Make it less expensive to run my very small service on Azure comes as the No1 community most-voted feature.

Yet, I think the situation will improve within 2010. Many cloud hosting providers such as RackSpace are already featuring small VMs that would be vastly sufficient for a single tenant version of Lokad.Translate. Considering that Microsoft will be offering similar VMs at some point, it would already drop the price around $30.

If we add also that CPU pricing isn't going to stay stuck at $0.12 forever, the hosting price of Lokad.Translate is likely to drop significantly within 2010.

Obviously, the most efficient way to cut the hosting costs would be to turn Lokad.Translate into a multi-tenant webapp. Depending on community feedback, we might consider going that road later on.

The next milestone for Lokad.Translate will be to add support for RESX files in order to support not only website localization, but webapp localization as well.


Securing CruiseControl.Net integration server

CruiseControl.NET is a great open source tool for continuous integration (CI). Yet, the default settings are quite permissive, and unless you're working on an open source project as well, you might prefer restrict the accesses to your sole team. I have found that securing CruiseControl.Net while keeping a developer-friendly environment is not such an easy task. This post is a summary of the various steps needed to secure your CI server. It should work against CCNET 1.2 and 1.3.

Create a dedicated Windows User for CCNET

There is (probably) no reason for your integration process to run as a administrator on your CI server. Running the CI as an administrator is just asking for more trouble if something goes wrong in the build process. First create a dedicated Windows account, I suggest to name it integration for the sake of simplicity. Then, From Start » Administrative Tools » Services, you can change the properties of the running services named CruiseControl.Net server, in the Log On tab. Just define the newly created account to be used for the CCNET service. You will also probably need to grant some Windows directory permission on root integration directory.

Restrict CCNET remoting access to localhost

Unless you're having a farm of build servers with a webserver dedicated to reporting the various build statuses, the CCNET remoting endpoint should not be remotely accessible (yet, that's the default CCNET settings). This behavior can be adjusted by changing the ccnet.exe.config file. Replace the line <channel ref="tcp" port="21234" > with <channel ref="tcp" port="21234" rejectRemoteRequests="true" >. Now, only a local CCNET dashboard instance is able to connect to the CCNET remoting endpoint.

Restrict CCNET Dashboard access to logged users

By default, no access restrictions are put on the CCNET Dashboard. The most simple way of restricting the access to the dashboard panel is to add a windows authentication layer within the ASP.NET application. You can add the following lines to the webdashboard\web.config configuration file to do that:

<authentication mode="Windows" />
  <deny users="?" />
  <allow users="*" />

Re-opening the CCTray status

CCTray does not support any kind of authentication, thus both Remoting and Via Web Dashboard connection methods will fail now that we have purposely put access restrictions. The trick consists in changing again the webdashboard\web.config to allow anonymous access to XmlServerReport.aspx with

<location path="XmlServerReport.aspx">
      <allow users="?" />

Then, configure CCTray with Via CruiseControl.Net Dashboard to connect to the URL http://myserver/XmlServerReport.aspx. Note that your build statuses (i.e. "Success" or "Failure") will be publicly available to anybody, yet it's not an issue to disclose such a limited information.


Continous migration in software development

New (and soon to be deprecated) technologies are just flowing in the Software industry. Some people pointed out that you can't stop improving your product just to keep the pace with the release flow (that's the fire and motion theory). Yet, being an ISV, your options are quite limited. You have to rely on the latest (yet stable) technologies in order to maintain a highly competitive productivity.

Rewriting from scratch your application to support the latest Foo.NET release is a bad idea; no question asked. Yet, it must be taken into account that

  • getting people interested (worse, training them) on deprecated technologies (let's say Classic ASP) is both hard and depressing.

  • not beneficing from the latest tools means lower productivity. Ex: Classic ASP => ASP.Net 1.1 => ASP.Net 2.0, each new version being a huge time-saver compared to the previous one). has been existing for less than a year and, we have already performed quite a lot of migrations.

  • SQL Server 2000 => SQL Server 2005

  • ASP.Net website => ASP.Net web application

  • No AJAX => ATLAS (betas) => ASP.Net AJAX Extensions

  • NAnt => MsBuild (when the MsBuild Community Tasks have been released)

  • VS 2005 Setup Project => WiX 2.0

  • Command Line => PowerShell (for our command-line tools)

  • IE6 => IE7 and FF1.5 => FF2.0 (for javascripts and CSS)

Among the next planned migrations

  • Visual Studio 2005 => Orcas

  • WiX 2.0 => WiX 3.0

  • Inline SQL in C# => LINQ

  • NDoc => SandCastle

  • NuSoap => PHP5 Web Services

  • osCommerce 2.2 => osC 3.0 (currently alpha) => osC 3.1 (for the plugin framework)

Our processes at Lokad involve continuous migrations toward new technologies. Upgrading take time and efforts, yet this process seems quite necessary to maintain optimal development conditions.


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.