Venceréis pero no convenceréis

Hatred and violence are bad. I am almost ashamed to write such a naive self-evidence, but recent events in Second Life show that evidence is not the same for everybody. Thanksfully this is only virtual, which must be why such levels can be reached, but still I cannot help thinking about "The Battle For Spain", the excellent book by Anthony Beevor about the spanish civil war : it has already been for real. And it was ugly.

An interesting part, among many, is the description of a speech by Miguel de Inamuno in Salamanca. He adresses the fascists, but maybe we all can learn something :

Venceréis, porque tenéis sobrada fuerza bruta. Pero no convenceréis. Para convencer hay que persuadir. Y para persuadir necesitaríais algo que os falta : razón y derecho en la lucha.
Miguel de Unamuno, october 12, 1936

You will succeed, because you have enough brute force. But you will not convince. In order to convince it is necessary to persuade, and to persuade you will need something that you lack : reason and right in the struggle.

The whole speech, replaced in its original context, is extremely interesting and can be found in this Wikipedia article. It is also a lesson of courage in troubled times.

SQL Server 2005 Compact Edition released

I have been playing around with SQLite, which is quite effective and impressive. There is even an ADO .NET Provider that embeds in the same assembly the native SQLite API, so that your single dependency is a 538Ko assembly for a fully functional self-contained database. For all this, you will not get support for distributed transactions though. That seems fair, but no exception is raised when you try to enlist a SQLite connection into such a transaction (unlike the MS Access OLE DB ADO .NET Provider for instance).

Microsoft have just released their own version of an embeddable database. It could have been called SQL Server Everywhere Edition, but eventually we have SQL Server Compact Edition. Obviously, its main benefit is the compatibility with other SQL Server versions (especially the SQL syntax). There are even tools to "easily" synchronize your data with plain server hosted databases.

Beware though : if you install the SDK, you will also have to install the desktop client (or else you are very likely to get an error stating that the sqlceme30.dll file is missing...). And deployment does not come free : a private file-based deployment means to copy 8 files (including the ADO .NET provider), amounting to 1.6Mo.

The ADO .NET Provider documentation itself is rather scarce (mainly a redirection to the standard SQL Server Provider documentation). So the main thing is that distributed transactions are not supported, which is OK. Another thing is that the SqlCeCommandBuilder class does not support named parameters (the protected GetParameterName(string) method throws an exception). That is usually not a problem unless you use this hack. Oh yeah, and the SqlCeConnection.GetSchema methods are not supported (throw an exception) as well...

Back (?) To Business

As a new year resolution, I have freely decided to commit myself into blogging about software development. So let me start slowly and write about source code organization.

The usual way to organize source code for a new project is to create a directory and have your IDE create your solution and your project in it (VS2005 vocabulary, mutatis mutandis for other IDEs/languages). Hopefully, you will stick with it, but more realistically you will have to add new projects for your libraries, executables, installers. You will also have to share resources, files and other scripts between projects. You will start to hack your own project again and again in order to add new resources until it becomes a total mess. You are starting to "lose" (and then duplicate) files (especially resources, like images). Unused files are forgotten and left, only adding to the confusion. This pattern is described for a single developer, but it is even easier and faster to get there with many developers.

Another way would be to have rules (remind me to blog about rules in general) to keep your files consistently organized. Here is my template organization, which is obviously only worth what it is :

Here the folder hierarchy description :

• Work : the root folder. It may contain general files like ReadMe.txt...
  • bin : the actual released software (libraries and/or executables and/or installers).
  • doc : the user documentation folder. Contains all the documentation on how to use the pieces of software located in bin.
  • lib : the external dependencies (e.g. libraries) needed for the project.
  • src : the source code folder. At this level, one can find all the project solutions and other build scripts.
    • doc : the developer documentation folder. Contains diagrams, DSLs, generated documentation...
    • lib : the internal dependencies. For instance, I would put the NUnit libraries there.
    • misc : the files that could possibly not find a home elsewhere. I would have a Sample.snk file (holds a signature key) there.
    • NUnit : unit tests projects.
    • SampleProject1 : a sub-project would fit in there.
    • SampleProject2 : another sub-project would fit in there.

This pattern can be refined as necessary (e.g. doxygen scripts are in src\doc\doxygen, build tools in src\misc\Tools...). This hierarchy also helps enforce the way the software is released. More on that later...