Je pars aujourd’hui en vacances jusqu’à après mi-août. Je serai donc un rien moins présent :-). Je laisse les commentaires ouverts, je suis un fou. J’y jetterai peut-être un œil de temps en temps depuis un cyber-café.
À bientôt.
Après mon billet au sujet de l’immobilier en France qui m’a fait découvrir L’ACDE de Marc Touati, je me suis abonné au fil RSS de ce site. Améliorer mes connaissances générales concernant l’économie, la finance sans non plus vouloir (pour le moment) aller jusqu’à passer un MBA m’intéresse. Être par exemple en mesure de mieux comprendre les notions de croissance, d’inflation, d’impacts sur l’emploi me paraît très utile pour gérer ses choix, sa vie, ses investissements etc.
Ce soir, j’ai vu qu’une conférence sur l’économie donnée récemment à Paris par Marc Touati était en ligne. Ça me rappelle un tout petit peu mes cours d’éco en seconde, auxquels à l’époque je n’accordais évidemment que peu d’intérêt…
Très instructif. Le slide V.4 reparle notamment de la bulle immobilière.
UPDATE : Comme le dit Géraud dans les commentaires, les vidéos en caméra cachée dans les agences de Toulouse viennent d’être postées.
Géraud m’a fourni des liens très intéressants au sujet de l’état de l’immobilier en France.
Pour commencer, une interview de l’économiste Marc Touati :
Marc Touati évoque la bulle immobilière, part
1
envoyé par jmpoure
En résumé, il prévoit notamment une baisse de l’immobilier de 10 à 15% dans les 2 ans à venir. Optimiste, il ne croit pas au scénario catastrophe d’un Krach.
Moins formel, mais tout aussi édifiant : Jean-Michel Pouré fait depuis quelques temps le tour des agences immobilières de France pour voir la réalité de terrain. En gros, il débarque dans des agences et demande à vendre son bien aux prix actuels. Il se voit expliquer qu’aux prix actuels, ça ne partira pas forcément aussi vite qu’il l’espère…
Exemple à Carpentras :
Carpentras, part 3 : baisse d’activité de
50%
envoyé par jmpoure
Si j’ai bien compris, des caméras cachées auraient été récemment faites à Toulouse. On devrait bientôt pouvoir les visionner…
Nous utilisons encore Struts 1 actuellement. Ce n’est normalement qu’une question de temps avant de passer à autre chose. Nous sommes sûrs de ne plus l’utiliser à terme. Nous connaissons donc notre source, mais pas encore la cible. Voici les nombreuses solutions qui s’offrent à nous :
Toutefois, je ne suis pas très chaud pour .Net ou Flex ou toute technologie qui nous contraigne forcément à passer par les WS pour accéder à nos services (développés en Java). Je suis réticent à devoir obligatoirement passer par une couche WS alors que nous pourrions garder du java de bout en bout, et ainsi économiser le marshalling/unmarshalling incessant qui va avec les WS, sans parler du problème de l’identification du graphe d’objets à sérialiser pour le renvoyer. Quoi qu’on en dise, utiliser systématiquement des WS n’est pas neutre et amène de nombreuses questions qu’on ne se pose jamais sinon (hein Séb…).
Donc, pour revenir au sujet, nous ne sommes pas encore fixés sur notre future couche présentation (ou plutôt nos futures couches de présentation). Pour le moment, nous avons donc décidé de continuer à fonctionner tant bien que mal Struts 1.x avec la version 2 du socle technique que nous sortons.
Or, la différence fondamentale entre notre version 1 et notre version 2 est que nous avons supprimé une “transformation” systématique entre deux couches. Auparavant, en effet, nos entités persistantes de couche DAO étaient systématiquement transformés en objet de couche service. Entre les deux couches, nous avions systématisé un bidouillage destiné à régler le problème que nous avons dans la couche Web dans la gestion des multiplicités 0..1.
Avec Struts 1, si vous demandez par exemple le prénom d’un client null, vous n’aurez pas quelque chose de null, mais une exception. La question a été discutée il y a déjà un moment sur la liste de Struts et posée sur le tracker de Struts en février 2001 (quand je vous disais que ça faisait un moment), et Craig Mc Clanahan d’expliquer que le principe était que si vous vouliez afficher le prénom d’un client, eh bien il fallait protéger le code pour n’afficher le prénom que si le client est non null :
[XML]
<logic:present name="beanname" property="client">
<bean:write property="client.prenom"/>
</logic:present>
Si dans l’exemple ci-dessus, on met un champ de saisie à la place du <bean:write />, on est dans une impasse : certes, il n’y aura pas de plantage, mais il devient alors impossible de saisir le prénom du client puisque le textfield n’apparaîtra même pas…
Si votre objectif est de créer le client seulement si l’utilisateur a saisi des données (exemple : le formbean en cours gère un objet Facture qui a une multiplicité 0..1 vers un objet client), vous êtes obligé de créer dans votre FormBean un objet destiné à recevoir ces données. Le problème qui survient alors, c’est que si vous voulez conserver des objets “propres”^[1]^, vous devez ensuite vérifier l’instance de Client pour la remettre à null ou l’associer manuellement (si pas encore fait) à la Facture avant de transmettre la Facture à la couche service pour mettre à jour. Ouf…
La longueur de l’explication ci-dessus par rapport à la complexité de ce qu’il faut gérer me paraît parler d’elle-même. Et le code qu’il faut écrire pour gérer ce cas est toujours le même… :
Dans Struts 2, le premier point est géré différemment : la demande de “a.b” si a est null renvoie simplement null. Par contre, le deuxième point est toujours à gérer manuellement et plantera si on cherche à valoriser a.b.
Une étape a déjà été franchie, pourquoi ne pas aller plus loin ?
Pourquoi ne pas instancier automatiquement a s’il est null lorsqu’on cherche à valoriser a.b ? La question se pose d’autant que nous ne sommes pas les seuls à nous être posés la question : ce patch apportait déjà les modifications nécessaires aux commons-beanutils (utilisé par Struts, c’est cette bibliothèque qui impose le comportement de lever une exception si une propriété imbriquée est demandée à l’intérieur d’un objet null)…
Une autre solution (sans patch, cette fois) intermédiaire a été proposée pour la partie “get” : mettre en place un handler externe pour gérer le cas des propriétés imbriquées (nested properties) dans un conteneur null. Cette solution est un intermédiaire intéressant parce qu’elle est très courte à implémenter et permet de faciler renvoyer null ou de lancer une autre exception dans le cas en question.
Cette deuxième solution ne gère toutefois que le cas get. Peut-être le même principe serait-il utilisable pour le “set”. Cela permettrait de même de positionner une sorte de NestedSetterHandler qui pourrait s’occuper d’instancier les propriétés intermédiaires si besoin. Avec un fonctionnement de ce type, on pourrait même envisager de définir un handler qui serait observable afin de gérer à la fois l’instanciation “dynamique” et de pouvoir suivre les instanciations effectuées. C’est à creuser.
Ce mode de fonctionnement aurait toutefois quelques inconvénients : lorsqu’on instancie manuellement a, on sait qu’on risque de devoir l’enlever s’il n’est pas vraiment saisi avant de l’envoyer à la couche service. Et que faire si on décide de faire gérer ça en standard par le service ? Imaginons par exemple qu’une adresse ait été automatiquement instanciée pour un Client. À quel composant, à quelle couche, incombe le rôle de supprimer l’adresse créée dynamiquement si le fonctionnel indique qu’elle n’est pas correcte ?
Dommage que l’équipe de commons-beanutils soit peu réactive sur cette question à mon avis primordiale de gestion des propriétés. C’est aussi très dommage que l’idée d’avoir derrière la classe statique BeanUtils une instance de BeanUtilsBean ne soit pas poussée à son terme : en l’état, il est en effet impossible d’utiliser de façon transparente une sous-classe BeanUtilsBean qu’on aurait adaptée à ses besoins.
Je nous vois bien maintenir en interne une version patchée de commons-beanutils afin de résoudre le problème tant que nous utiliserons Struts 1, en espérant bien sûr que le patch en question soit finalement appliqué.
En même temps, il reste la question de la gestion de la suppression des propriétés instanciées dynamiquement. Mais je ne suis pas sûr que ce soit un véritable problème, c’est un code qu’il faut de toute façon écrire. Au final, il y a actuellement les deux points suivants à gérer :
C’est à mon sens un point qu’il serait intéressant de creuser. Avec Struts 2 par exemple, écrire un Interceptor chargé de l’instanciation dynamique ferait l’affaire pour enlever le point 1 ci-dessus.
Le tout serait ensuite de définir un emplacement de choix pour faire la validation, puis la suppression des propriétés fonctionnellement “inacceptables”. À part ce point, je ne vois aucun frein à cette évolution. Cette question se posant pour n’importe quel formulaire de saisie, le monde de l’informatique aurait à mon sens beaucoup à gagner à trouver un véritable pattern pour gérer ce cas…
[1] c’est à dire que facture.getClient() renvoie bien null si la facture en question n’a pas de client, et non une instance bâtarde de Client qu’il vous faut ensuite analyser pour savoir si c’est un vrai client ou bien simplement une instance positionnée pour gérer des contraintes de présentation.
Martin Fowler a pondu ce soir un long billet sur la politique de Microsoft envers Ruby. Il parle ensuite de sa sensation selon laquelle une certaine désaffection pour la plate-forme .Net serait en cours, et que les AlphaGeeks (tiens, il faudrait un questionnaire, “êtes-vous un AlphaGeek ?” :-)) seraient en train de quitter l’environnement de développement MS.
Quelques morceaux choisis :
A few years ago my (limited) contacts in Redmond told me that they were seeing a real drift of technical leaders away from the Windows platform. More recently these signs seem to be increasing.
The tools, with their rigid role-separations, actively discourage the blurry boundaries that agilists prefer.
Pour ceux qui ont récemment joué avec WPF, Blend et consorts, on voit très bien ce qu’il entend par là.
The attitude to open-source is a large part of this problem. When Java appeared there were yawning gaps in its portfolio […] Those gaps and bad ideas were fixed by the open-source community. […] .NET has also got its gaps, and again the open source community has stepped up to fill them. Yet Microsoft refuses to collaborate with these efforts, […] Microsoft ended not just bringing out a competitive library, but deliberately making it incompatible. That’s not the kind of reaction that encourages people to invest their time in the platform.
Je connais peu .Net, mais est-ce que MS travaille à l’intégration ou en tout cas encourage un projet comme NHibernate ?
MAJ : ajout de liens :
Today, we received Oracle. They were coming to speak about their business Intelligence offer, Oracle Application Server and so on.
When speaking about Toplink, the guy said something like: “We could say Toplink is kind of a father to Hibernate. Obviously, it’s already almost 15 years of existence.” Well, why not. Though I didn’t see any article interviewing Gavin King confirming that, but apart from reusing their ideas or not, Toplink was here before, OK.
The assertion that surprised me was another one, something like: “As Toplink is older than Hibernate, it’s obviously more robust and has more functions.”
Well, I’m not sure I would agree with this one. In fact, as Toplink Essentials was only released in the OpenSource world very recently (may 2006 in Glassfish, so the JPA implementation even more, if I’m right), and experts seems to agree that about 90% of the projects today use Hibernate for the persistance layer (Didier Girard says it in the TV4IT Webcast. I think this is more of a feeling for him, so if anybody has some statistics about, I’m very interested. I should also ask Sami Jaber for his feeling about it.).
Webcast (in french, see about 9/10 of the video for the “Hibernate is 90% of the current projects”) :
So, what is the right indicator about software robustness?
Is this the software that’s been released fifteen years ago, used by 10 people around the word since this time, or is this this other one, that’s been released 6 years ago, used by 90 people since then? Who was the most testable? The one that only few people could download to give it a try, or the one that’s been downloaded and tested tons of time by a lot different people?
In my opinion, but I also agree I only know Hibernate, I’m pretty sure Hibernate has already been thoroughly tested. At least, as much as Toplink has. My point is that the maturing of Hibernate was a lot quicker than Toplink’s one. Once more, it would be very interesting to put numbers in the debate. Hibernate has been opensourced since its start, so it always benefited from code reviews, patches and so on, and evolved very quickly.
To sum up, because of the fundamental differences between both development styles, I’m not sure that today Hibernate is still behind Toplink speaking about robustness, functions scope and so on. Though I’d be delighted to learn about interesting differences, if you know about it.
C’est un peu dommage. Mme Royal a cassé les pattes arrières de Nicolas Sarkozy sur le sujet des handicapés, mais a fait durer un peu trop le sujet. Elle a laissé M. Sarkozy reprendre du poil de la bête et faire le choqué, le blessé après la longue attaque, semble-t-il justifiée. Elle ressort de ce moment du débat avec moins de points que ce qu’elle aurait pu.
Pour résumer, Sarkozy propose de fournir un droit opposable pour tout (crèches, enfants handicapés scolarisés dans des écoles classiques…). Ségolène Royal lui répond, à juste titre il me semble, qu’on ne peut pas tout résoudre avec des lois et des passages en justice. Elle répond avec énergie à la partie sur les enfants handicapés, où elle explique qu’elle avait déjà mis en place des auxilliaires (7000 postes, je crois) spécialisés pour aider les enfants handicapés dans les écoles lorsqu’elle était ministre de l’éducation. C’est justement le gouvernement dans lequel travaillait Sarkozy qui aurait fait sauter ces postes. Le problème, c’est que ça a duré trop longtemps à mon goût. Elle aurait dû s’interrompre après la réponse qu’elle lui a faite, histoire de voir sa réaction. Il a eu le temps de préparer une réponse pendant qu’il faisait le pauvre petit gars qu’on attaque sans raison. Toutefois, sur le fond, je trouve qu’elle a très bien réagi.
Pour ceux qui comme moi n’ont pas accès à une télévision, mais à leur ordinateur, vous pouvez vous rendre sur le site d’Arte et cliquer sur Retransmission en direct sur Internet du débat Royal/Sarkozy pour le visionner en ligne.
De sensibilité plutôt encline à vouloir aider les plus démunis qu’à protéger l’ISF, j’ai une forte inclination à gauche. Toutefois, je m’intéresse aux arguments des candidats pour ne pas partir dans le mur aveuglément.
L’UMP me donne des raisons supplémentaires de ne pas voter pour elle. Je dirais même plus, le PS me donne des raisons de voter pour lui. Chose importante, vu le nombre de fois que l’on on a entendu notamment la gauche de la gauche “voter pour faire perdre la droite” et non simplement voter pour la gauche.
Merci à Thomas d’avoir rédigé un billet récapitulatif de l’initiative Candidats.fr, qui a consisté à poser des questions à chacun des candidats concernant différents sujets afférant à Internet, à la protection des droits d’auteurs, aux Mesures Techniques de Protection, ces fameuses DRM, les brevets logiciels.
À mon sens, la gauche est loin devant quant au traitement de la problématique des droits des citoyens sur Internet, la protection des consommateurs (vente liée, interopérabilité des lecteurs de musique numérique, …).
Une citation que j’aime beaucoup. Je ne sais pas si elle est de lui à l’origine, mais je l’ai trouvée chez Rags, CTO chez Sun :
It’s better to have an unanswered question than an unquestioned answer
Ou en français
Mieux vaut une question sans réponse qu’une réponse qu’on ne remette pas en question
J’ai l’impression que nous appliquons sans vraiment y faire attention ce principe. J’aime à penser que c’est le bon chemin. Ne jamais considérer que ce qu’on a est parfait, et surtout être toujours prêt à en écouter les critiques pour améliorer ses points faibles.
L’informatique n’est un long fleuve tranquille, il y a des milliers de ruisseaux pour arriver au même endroit Certains sont plus courts, d’autres plus longs, d’autres simplement plus rapides et toute la complexité est de choisir celui qui convient le mieux pour faire ce qu’on veut. Notre rôle est de sans cesse revérifier les routes et les cartes pour les utiliser afin que les suivants gagnent du temps… Et depuis ma petite expérience, ce n’est ni simple ni de tout repos, mais heureusement terriblement passionnant et enrichissant !