Raphaël Delaporte (@rafdelaporte) nous a proposé de dompter un chameau cette semaine au JUG Nantes.
Et ne vous fiez pas à cette photo ! Notre chameau d'informaticien n'est pas un paresseux, bien au contraire ! Retour sur une présentation forte intéressante d'Apache Camel.
Dans le cadre de la recherche d'un objet en base de données par son identifiant, Hibernate fournit plusieurs méthodes via la classe HibernateTemplate. Parmi elles, on trouve la méthode load et la méthode get. Mais attention, malgré les apparences, ces deux méthodes de récupération d'objet sont différentes. Voici leur javadoc respective :
Object get(Class entityClass, Serializable id) throws DataAccessException
Return the persistent instance of the given entity class with the given identifier, or null if not found.
Object load(Class entityClass, Serializable id) throws DataAccessException
Return the persistent instance of the given entity class with the given identifier, throwing an exception if not found.
La principale différence entre ces deux méthodes est ce qu'elles renvoient dans le cas où l'objet correspondant à la classe et à l'identifiant donnés en paramètres n'existe pas : la méthode get renvoie null si elle ne trouve pas de résultat, alors que la méthode load renvoie un objet non null qui est un proxy. Ce proxy n'est d'ailleurs pas exploitable en mode debug.
Des nouvelles versions de SPIP pour les branches 1.9.x, 2.0.x et 2.1.x viennent de sortir (23 avril). Vous trouverez ainsi les versions 1.9.2.o, 2.0.18 et 2.1.13.
Ces nouvelles versions corrigent plusieurs failles de sécurité qui ont été repérées récemment, qui sont, pour la plupart, des failles concernant des possibilités d’injection XSS.
Ce billet présente brièvement la manière standard de faire la validation des données dans un projet java et ce quelque soit la nature du projet.
Généralement, la validation des données repose sur les (extensions des) frameworks utilisés (Struts, Spring MVC, .. ou les ORM tel Hibernate, ...).
Chaque tiers du projet possède une façon spécifique de faire la validation.
Nous présentons la validation de la JSR-303 car elle s'applique à tous les tiers.
Nous illustrons la validation JSR 303 avec l'implémentation de référence, v4.x, de JBoss Hibernate.
La démonstration est réalisée avec maven 2.x / Eclipse. Elle est testée sous java6 / Windows.
Mais elle doit fonctionner sur tout autre environnement linux ou u*x.
Maven n'est pas obligatoire mais il facilite la gestion des librairies et de leurs dépendances.
Passons à la pratique.
Dans la vie quotidienne, nous sommes entourés par les index : une adresse postale est une forme d’index, tout comme un numéro de téléphone ou un numéro de sécu. Pourtant, nombre de développeurs négligent l’indexation des données de sa base. Nous allons voir dans cet article pourquoi c’est important et comment optimiser cette partie. Cet article est basé sur ma propre expérience en la matière, ainsi que sur un certain nombre d’articles sur internet.
Déjà le dernier jour de la conférence Devoxx France, l'occasion pour moi de revenir sur les conférences qui m'ont marquées.
Les mots-clés de la 3ème et dernière journée de Devoxx France 2012 : langages alternatifs, agilité, open source, mobile, I/O, SQL/NoSQL...
Ma journée a commencé par la keynote de P. Chanezon : "Portrait du développeur en The Artist". Comme le titre l'indique, la première partie s'est chargée, non sans une touche d'humour, de faire le parallèle entre l'évolution du développement logiciel et le film qui a fait sensation cette année.
L'événement a été l'occasion de revenir sur les dernières bonnes pratiques en matière de développement HTML5, ainsi que sur la modélisation d'applications.
Voici un résumé des conférences auxquelles j'ai assisté lors de la journée du 19 avril 2012 à Devoxx France.
Je l'attendais depuis des mois, et la voilà arrivée : la conférence Devoxx France ! LA conférence des développeurs Java. Le développeur est donc, pour beaucoup de présentations, un sujet central. Je vais ici vous faire partager un retour à chaud sur cette première journée de conférences pour moi. Auparavant, bravo à toute l'équipe d'organisation : les horaires ont été respectés à la lettre !
Principaux mots-clés de ma journée : spring, java ee6, shubaka, qualité, ceylon, google...
Objectif de ce billet
Ce billet vise à présenter de façon sommaire la librairie SOS.dll et son utilité dans l’investigation de problèmes de mémoire dans une application .NET.
Présentation
L’utilisation du framework .NET, dans toutes ses versions, est désormais largement répandue. Avec ses belles promesses, comme la gestion de la mémoire automatique, il a conquis de nombreux adeptes réfractaires à cette tâche dans un langage sans Garbage Collector tel que le C++.
Malheureusement, nous avons maintenant des programmes qui consomment de plus en plus de mémoire, les développeurs ne faisant pas autant attention à leur conception de classes, et l’héritage excessif peut conduire à une consommation mémoire quelque peu gloutonne. Et soudain, alors que tout fonctionnait à merveille, c’est le drame : la terrible System.OutOfMemoryException! Ou encore, vous observez une utilisation mémoire qui vous semble extrême par rapport à votre domaine métier et les données que l’application gère.
Et nombre de développeurs sont plutôt désemparés face à de tels problèmes, et se lancent dans l’utilisation d’outils professionnels souvent coûteux, et lourds d’utilisation afin de tenter d’y voir clair. Et, comble de malheur, plus le logiciel fautif à analyser est complexe et consommateur de mémoire, plus l’utilisation de ces outils est lourde!
Heureusement, il y a un petit outil peu connu, d’une très grande légèreté et d’une accessibilité totale, étant directement intégré au Framework .NET, toutes versions confondues : il s’agit de SOS.dll.
Dimanche matin, à 8h00, 4 coureurs de Netapsys Atlantique se sont retrouvés devant les Machines de l'Île pour participer au marathon-relais de Nantes, avec quelques 160 autres équipes, et plus de 3 000 marathoniens.
Derniers commentaires