Ceci dit, il était donc temps de commencer à nous atteler à la tâche proprement dites de coder, et d'initier ainsi le cercle des itérations.
Nous n'avions pas encore choisis la technologie,et il a fallut donc cette semaine se poser cette question cruciale. La seule chose que nous savions était que l'IHM serait essentiellement en web vu le besoin de pouvoir accéder n'importe où à l'application.
Personnellement, ma réflexion s'est accès sur deux grands points:
  • la facilité d'accueillir un modèle du domaine riche de sens, complètement isolé des autres couches et indépendant/ignorant de toute considération technique
  • le prix
En ce qui concerne la facilité, pour donner un exemple je dirai que C++ ne permet pas du tout ça. Pour avoir pratiqué l'animal pendant deux ans, je sais que j'ai passé plus de temps à débugguer ou me prendre la tête pour des considérations purement liées au langage ou au compilateur. Je trouve ça avec le recul assez inadmissible. Je veux pouvoir me concentrer sur le métier que je tente de représenter et exclusivement sur ça. Il faut donc une technologie qui abstrait les détails bas niveaux. Clairement on pense tout de suite à Java ou .NET. Tout deux sont accompagnés d'un garbage collector puissant qui permet de s'abstraire de la gestion de la mémoire; et tout deux ne sont pas compilés directement en langage machine, ce qui évite donc des considérations sur le système cible.
Donc nous voici donc devant le débat vieux comme .net, à savoir Java vs .NET. Java avec J2EE, et .NET avec son approche par défaut, l'un comme l'autre n'encourage ni ne permettent l'utilisation d'un modèle de domaine riche de sens comme nous voulons le mettre en place(pour java, ce n'est pas moi qui le dit, mais Evans et Fowler).
en .NET, il est facile de sortir de la voie royale est de faire un montage plus propre (sujet largement discuté dans ce blog finalement), par contre je connais Java et les frameworks qui tournent autour essentiellement par réputation. Heureusement pour nous, le groupe que nous avons monté contient des javaistes qui nous ont confirmés que le modèle complexe et lourd prônè de base par J2EE est largement contournable.
Bref, nous nous retrouvons à égalité en ce qui concerne mon premier critère, avec peut être un léger avantage pour .NET qui me semble plus facile à mettre en place.

Bon sur le 2ème critère, le prix, évidemment vous vous en doutez, Java arrive en tête. D'accord, il existe Mono sous linux pour pouvoir éviter le cout d'une licence xp et/ou 2k3. Le problème est que Mono Develop, IDE tentant de remplacer Visual Studio sous Linux, est pour le moment très bancal.
Microsoft fait depuis quelques temps des efforts sur les prix. Windows 2K3 à 300$, Visual Studio en version express; sql server en version express également. Cependant sur du plus long terme, nous ne pourrons plus nous contenter d'une version express de Visual Studio ou de SqlServer, il nous faudra sans doute une licence plus conséquente que la WebEdition de 2K3, bref nous nous engageons pour l'avenir sur des dépenses un peu trop conséquentes et qui mangeraient nos marges dans un hypothétique début d'exercice.
Donc pour toutes ces raisons, Java est la technologie retenue pour le projet.
L'anecdote cocasse finalement de ce débat, est que les javaistes d'entre nous voulaient du .NET, et les .Netiens eux voulaient du Java.

Bon nous n'avons cependant pas fait le tour. Il nous reste à choisir le SGBD, si nous n'utilisons pas une base objet; il nous faut également choisir parmi la jungle de serveurs et de frameworks existant dans le monde java ce que nous allons utiliser. Enfin je pense nous nous orientons vers du Sping/Hibernate pour la technique. Pour les serveurs, je n'en sais rien pour le moment.

A signaler aussi que SVN s'est imposé sans réel concurrence comme étant notre solution de contrôle de code source.
MAJ: j'ai oublié de signaler aussi qu'il nous reste à choisir le serveur d'intégration continue, et que pour les test unitaires JUnit s'est également imposé.