Si vous pensez que les résultats du serveur de compilation gagneraient à être visible en permanence par l'ensemble de l'équipe de développement, ce lapin est pour vous.
SOAP, http, Jabber et un lapin.
Dans cette application de Martin Woodward le lapin Nabaztag matérialise l'état du serveur Team Foundation Server, mais rien n'empêche d'adapter le principe à d'autres technos, Nant inclus. Les API du lapin, en mode REST, ont l'air très simple à mettre en oeuvre.
Quand même, plus geek que ça tu meurs.
Ceci dit magré l'apparence futile, il est possible que matérialiser dans le monde physique une partie du monde numérique soit un business à fort potentiel dans l'entreprise. Sous forme de lapin ? Peut-être pas.
[Mise à jour suite à commentaire : pour plus d'idées sur les moyens de matérialiser l'état d'un serveur de build, suivez ce post de Romain Verdier]
Hibernate et son cousin .Net NHibernate souffrent d’un handicap qui nuit à leur réputation. Dès 2006 Sami Jaber constatait que les premiers retours terrain étaient plutôt désastreux : "[...] des requêtes SQL générées de 70 pages imprimées (véridique), parfois 300 ou 400 requêtes par formulaires et des DBA qui crient au scandale".
Implicit Lazy loading
Le lazy loading implicite (littéralement "chargement paresseux") mis en œuvre par (N)Hibernate est en grande partie responsable de cette notoriété reprochable. Typiquement en lazy loading, un objet (disons client) dont les propriétés ont été renseignées par NHibernate verra ses objets associés (disons client.Commandes) initialisés paresseusement par une requête SQL, c'est-à-dire seulement quand nécessaire et si nécessaire.
Lazy road crossing. Rien à voir. Désolé.
Jusque là tout va bien, le lazy loading c'est plutôt bien pour éviter que toute la base de données ne se retrouve en mémoire par le biais de plusieurs associations.
Le hic, c'est que toute cette mécanique de requêtage automatique de la base de données se produit implicitement, presque à l'insu du développeur. Par exemple si le développeur doit écrire une itération sur tous les client.Commandes pour calculer le total des commandes, il écrira une boucle foreach (Commande commande in client.Commandes), et NHibernate va silencieusement générer et exécuter autant de requêtes SQL que de commandes associées à cet objet client. 150 commandes ? 150 requêtes envoyées une-à-une à la base de données...
D'un côté c'est génial parce que le développeur peut manipuler des objets C# purs et durs en ignorant qu'une base de données est à l'œuvre derrière le décor, orchestrée par NHibernate. De l'autre, et pour les même raisons, c'est une catastrophe. En ignorant la réalité du SGDB, les performances chutent et les DBA crient au scandale, parce que la façon optimale de charger des données en mémoire dépend, au cas par cas, de l'usage que l'on s'apprête à en faire. NHibernate n'ayant aucune vision de cet usage, l'optimisation des requêtes ne peut être menée que par le développeur grâce aux outils (join fetch par exemple) de NHibernate.
Malheureusement, quelles que soient les possibilités qu'offre NHibernate pour forcer le chargement d'une collection d'objets en un seul aller-retour SQL, le seul fait que le développeur ait la possibilité d'ignorer le moyen par lequel les objets persistent (conformément au principe de Persistence Ignorance –PI– de l'approche Domain Driven Design –DDD) promet quelques utilisateurs énervés par la lenteur de certains traitements, des DBA scandalisés et finalement des clients mécontents. Bref une sale réputation.
Explicit loading
Et c'est donc une décision marketing qui a conduit l'équipe Microsoft responsable d'Entity Framework à choisir le chargement explicite (explicit loading) plutôt qu'implicite. Dans le dernier numéro de MSDN Magazine, l'encart intitulé "Insights: Entity Framework Data Loading" et signé DiegoVega est clair à ce propos : " Following the "no hidden network roundtrips" principle, Entity Framework avoids automatic lazy loading".
Aucun aller-retour avec le SGBD n'aura lieu sans que le développeur ne le sache.
Le principe de l'explicit loading est simple : tant que le développeur n'a pas écrit le nécessaire pour charger une Commande de notre association client.Commandes, l'accès à une de ces commandes déclenche une exception. En explicit loading, les développeurs se soucient du SGBD, les DBA sont heureux, et l'image de Microsoft est sauve.
Alex considère les données disponibles sur le Web comme le matériau de base de ces oeuvres. Ajoutez au matériau de la 3D, beaucoup d'habilité en programmation, beaucoup de créativité. En bref du talent.
Alex Dragulescu : http://sq.ro/ (même le nom de domaine est travaillé...)
Entity Framework, la couche de mapping objets/base de données relationelle (ORM) de .Net actuellement en beta 3, sera multi-database comme l'est Nhibernate. On pourra basculer de SQL Server vers MySql aussi facilement qu'on change de T-shirt (oui, vous faites bien de vous méfier de ce genre de promesses...).
Pour preuve, ces éditeurs cités par InfoQ prévoient de livrer des providers ADO.Net compatibles Entity Framework pour Oracle, MySQL, PostgreSQL, SQLite et DB2 : http://www.infoq.com/news/2008/05/ADO.NETProvider
WPF a vraiment énormément de qualités. Le choix de WPF pour écrire une nouvelle application Windows ou refondre l'interface graphique d'une application existante serait un choix évident si seulement le déploiement de .Net 3.0 ou 3.5, nécessaire sur les machines XP, n'était pas si long. Vraiment trop long.
Le service pack 1 de .Net 3.5 corrige ce handicap en autorisant de ne packager que ce que votre application n'utilise réellement du framework .Net. Un package typique devrait ainsi atteindre 25Mo, soit à peu près l'équivalent du download d'Acrobat Reader.
Cette option des projets d'installation, baptisée Client Profile, sera configurable depuis Visual Studio 2008 SP1.
Microsoft, n°1 du logiciel, et Google, n°1 de la réclame (online bien sûr, mais aussi TV, radio et papier1), s'affrontent sur bien des marchés. Et la ligne de front s'étend parce que Microsoft vise le Web et ses revenus publicitaires récurrents tandis que Google vise le logiciel, eldorado publicitaire au regard de son absence de pub et du temps qu'on y passe.
Pour les logiciels de création de scènes 3D, Google Sketchup et Microsoft 3DVia sont en concurrence frontale. Ces softs sont en fait des à-côtés de la course à la cartographie que se livrent les deux monstres. En effet Google Earth comme Virtual Earth autorisent la visualisation des bâtiments en 3D. Mais comme ni l'un ni l'autre ne souhaitent développer eux-mêmes la modélisation 3D de la terre entière, c'est à l'utilisateur de créer ses propres modèles et de les partager, grâce à SketchUp pour l'un et 3DVia pour l'autre.
Très objectivement, SketchUp (version 6) est bien au-dessus de 3DVia (version 1.0) en termes de facilité d'emploi, de fonctionnalités, de librairies d'objets à importer et d'ouverture. SketchUp offre même un moyen d'automatiser les tâches de design répétitives et d'étendre les menus par des scripts Ruby.
Un essai d'utilisation de SketchUp. Sketchup permet aussi d'animer les scènes, voir ce lien (fichier AVI, 5 Mo, c'est vraiment beaucoup pour 10 secondes, on doit pouvoir faire mieux).
Une autre force de SketchUp est d'être indépendant de Google Earth là où 3DVia ne peut être lancé que pour intégrer de nouveaux objets à Virtual Earth. En somme SketchUp est un petit 3D Studio ou un petit Blender, alors que 3DVia, dont le moteur provient de Dassault Systèmes, n'est qu'un produit satellite de Virtual Earth.
En tout cas, moi qui cherchait un logiciel simple et puissant pour modéliser une maison avant déménagement, je ne cherche plus. Mais je ne m'attendais pas à le trouver du côté de Google. Ah et j'ai failli oublier : c'est gratuit.
Et quand on est vraiment fort, voilà ce que SketchUp donne :
Sur cette pub Flash en ligne apparait deux fois un acronyme autrefois sciemment oublié par Microsoft :
PHP "poussé" par Windows 2008 ? Impensable il y a quelques mois, mais le mouvement vers l'open-source annoncés par MS se concrétise. Le composant FastCGI, co-développé par Microsoft et Zend est responsable du renouveau entre IIS et PHP.
Figure extraite du brevet américain purement algorithmique "Systems and methods for USA Patriot Act compliance". A lire pour comprendre ce qu'est un brevet faible.
Il y a 10 ans, l'USPTO, organisme chargé des dépôts de brevets aux Etats-Unis, a été autorisé à enregistrer des brevets ayant trait à des méthodes génériques ("business methods") plutôt qu'à des inventions avec un pied dans le réel "physique". Le flot de brevets faibles (ou brevets baudruches, qui se dégonflent au premier procès) qui s'en est suivi a probablement bien plus participé à augmenter la richesse des cabinets juridiques spécialisés en propriété industrielle que celle des entreprises et investisseurs qui pensaient pouvoir s'y adosser.
Ouaou...
Le désenchantement est tel qu'aujourd'hui des entreprises comme IBM et Microsoft poussent la cour d'appel (CAFC, US Court of Appeals for the Federal Circuit) à mettre fin aux brevets purement abstraits à l'occasion d'une dispute déclenchée par l'USPTO lui-même. Un brevet déposé par Bernard Bilski et Rand Warsaw est à l'origine du débat. Il s'agit d'une demande de propriété exclusive pour une méthode de couverture de risques financiers au moyen de transactions. L'USPTO refuse le dépôt en raison de son caractère trop abstrait, déconnecté de toute implémentation, de toute description d'un système capable de mettre en œuvre la méthode : une idée en somme.
Etant donnée la proximité entre méthodes, algorithmes, théorèmes, logiciels et idées, l'avenir des brevets logiciels dépend de cette affaire.
WPF a vraiment énormément de qualités. Le choix de WPF pour écrire une nouvelle application Windows ou refondre l'interface graphique d'une application existante serait un choix évident si seulement le déploiement de .Net 3.0 ou 3.5, nécessaire sur les machines XP, n'était pas si long. Vraiment trop long.
Les commentaires récents