UrbaTic

Repost

2008-12-31T13:02:00.005+01:00

Ce blog était presque mort, mais il va revivre. J'avais mis sous forme de brouillons quelques articles que je vais publier dans les prochains jours. De plus, ayant légèrement changé de fonction au boulot, mes prochains billets seront principalement sur le sujet des données. Et là, il y a pas mal à partager...

Dans tous les cas, je vous souhaite de joyeuses fêtes et une excellente année 2009!

Closures en Java .vs. macros en Lisp

2007-08-29T17:43:00.000+02:00

InfoQ m'a fourni un bon article de synthèse sur les Closures en Java. Pour ma part, je relie le concept de closures (en java) au concept de macro au sens de Lisp (c'est à dire à créer des fonctions de manipulations de fonctions).

Java est en train de combler son retard sur la prédiction de Paul Graham (ou bien était-ce Phillip Greenspun ou encore Richard Gabriel) comme quoi tout language suffisamment évolué ne sera qu'une variation ou dialecte de Lisp.

Complexité du SI et SIP

2007-08-29T13:22:00.000+02:00

Roger Sessions poste quelques articles intéressants, même si je ne suis souvent pas d'accord avec ses prises de position. Récemment, j'ai reçu par sa "mailing list" un renvoi sur sa méthodologie SIP. Cet article est intéressant car il traite de la complexité du SI et de l'architecture comme moyen de maîtrise de cette complexité.

Roger donne la définition de la complexité d'un système comme étant le nombre total d'état que peut prendre un système. Ma vision de la complexité est proche mais différente et sera exposée dans un futur billet.

Néanmoins, ce qui est intéressant est l'explication basée sur des fondements mathématiques pourquoi sa méthodologie SIP (pour Simple Iterative Partioning) est un moyen de réduire cette complexité. Mais en fait ce qui est amusant est que son explication est fausse.

En effet, le nombre d'état total de 2 sous-systèmes indépendants n'est pas la somme de 2 sous-systèmes, mais bien le produit. Par exemple: soit 2 dés à jouer. Chaque dé peut être dans un de ses 6 états. Le nombre total d'états est de 36 et non pas 12.

La complexité du système total n'a pas changé : que j'ai 2 dés ou un dé à 36 faces, le problème est le même. Par contre, le fait de savoir partitionner en 2 entités indépendantes permet une meilleure maîtrise de cette complexité, car il permet de réfléchir sur un sous-domaine autonome.

Toute la difficulté est le découpage en entités indépendantes... Ce que propose Roger est un partitionnement sur la dépendance réflexive entre fonctions. Le risque que je vois est l'oubli assez facile des données dans ce périmètre qui peut mener à un partitionnement différent.

XML trop lourd

2007-03-24T12:24:00.000+01:00

Thibault Ducray (ex-collègue) a écrit il ya quelques temps un article exprimant son point de vue sur le bon et le mauvais XML. Cet article est intéressant, mais pour ma part, le problème de taille du XML, sa verbosité, ne nécessite pas d'inviter un nouveau langage simplifié déclaratif.

Aujourd'hui, le problème principal dans le traitement de l'information n'est pas ni le stockage (un disque dur de 500 Gigaoctets vaut moins de 150€), ni le temps de traitement (processeurs > 2000 Mhz, processeur multicoeurs, etc...), mais les entrées-sorties. Pour résoudre la verbosité d'XML qui est donc un problème pour les échanges, il suffit de le compresser et décompresser à la volée avec par exemples des algorithmes sans perte type Lempel-Ziv et autres.

La bonne nouvelle est que ceux-ci (zip, gzip) sont directement supportés par tous les OS et même les échanges HTTP. Le coût de compression/décompression par le CPU reste négligeable par rapport au cout de transfert I/O, particulièrement à partir/vers le réseau.

Il est d'ailleurs souvent "gratuit", car sinon le CPU est de toute façon bloqué en attente des I/O. C'est moins vrai sur les serveurs, mais ce surcoût est largement compensé par le hardware et la loi de Moore.

Le principal défaut d'XML est qu'il ne sait véritablement transmettre de l'information que sous forme d'arbre. Dans la plupart des cas, il est donc nécessaire de transformer l'information métier en une projection arborescente forcément réductrice.

YABAEA - Yet Another Blog About Enterprise Architecture

2006-11-11T10:27:00.000+01:00

C'est décidé, je me lance. Après avoir beaucoup hésité, je me retrouve dans la BlogSphère. L'idée de ce blog est de partager idées et concepts sur un de mes domaines actuels de prédilection, qui se cache derrière les buzzwords comme :

soa, urbanisme, eda, enterprise architecture, eai, architecture du SI...

Le sujet est vaste, nouveau et certes ni normalisé, ni encore moins fossilisé.

PS: Pourquoi UrbaTic? Urba pour Urbanisme, Tic pour Technologies de l'information et de la communication