Episode 3 : Mathias découvre Eclipse (et un peu OSGI)

juin 29, 2010 5 Commentaires

Dans l’épisode 2, je vous ai dit à quel point les serveurs J2EE pouvaient être complexe dans la gestion d’application.
Il en est de même dans le monde des IDE avec la gestion des plugins.

Tout en étudiant J2EE, je suis tombé amoureux de mon IDE Java préféré : Eclipse. Pas seulement pour sont utilisation, mais aussi pour son architecture.

En effet, la réalisation de plugins pour Eclipse se fait de manière ultra puissante. A tel point que le « noyau » d’Eclipse peut être complètement extrait pour faire sa propre application qui n’a rien à voir avec un IDE : c’est le framework RCP (Rich Client Platform).
J’ai d’ailleurs à l’époque réalisé une application RCP pour la gestion de budget d’achat de livres pour les bibliothèques.

Malheureusement, la pauvreté des composants graphique en Java faisait du tors à cette plateforme.
Mais je restais subjugué par le moteur de plugins :

  • Les plugins sont isolés afin que si un plugin crash, les autres continuent leur vie
  • Les plugins sont aussi isolé coté sécurité : un plugin ne peut pas accéder aux codes d’un autre plugin si ce dernier ne l’a pas explicitement rendu « publique »
  • Les plugins peuvent publier et consommer des services, avec un model très élégant
  • Il y a une gestion de dépendance entre les plugins, avec la prise en compte des versions
  • L’installation et la mise à jour des plugins se fait d’une simplicité déconcertante

En fait, si la gestion des plugins est si balaise c’est car elle provient d’un standard de « développement par composant » : OSGI.

L’alliance OSGI est un organisme de personnes qui se mette d’accord ensemble sur des specs concernant les frameworks OSGI. C’est encore la que Java écrase .Net par sa maturité : il n’y a pas de monopole, il y a bien plusieurs acteurs derrière un « standard » ouvert qui va connaitre de multiples implémentations.

OSGI est donc un framework complexe de gestion de « modules » qui exposent des « services ». N’hésitez pas à lire le WIKI qui explique ça très bien : http://en.wikipedia.org/wiki/OSGi

En conclusion, Eclipse est une plateforme riche en plugins grâce au coté Open-Source de l’IDE, à l’API de plugins très bien faite mais aussi à l’aide du plugins pour développer des plugins :)

Qu’en est-il du coté .Net? VisualStudio a-t-il le même succès concernant le développement ce plugins? Offre-t-il une architecture de plugin aussi puissante? On verra ça dans un autre épisode ;)

Classé dans Développement, DotNetServer Tag(s) associé(s): , , , ,

Episode 2 : Mathias découvre J2EE

juin 29, 2010 4 Commentaires

En sortant de mes études, je me suis rapidement retrouvé dans le moule en adoptant Java. J’ai alors découvert les serveurs « conteneur de servlets » ou serveur J2EE, ce qui était quand même plus puissant que PHP…

Je vous ai parlé d’EASYPHP, avec lequel l’utilisateur avait une interface Web pour administrer sont serveur Apache: en 2 clicks n’importe qui peut créer un nouveau site web, sans connaitre le fameux “apache.conf”

Je suis fondamentalement contre la MMC de Windows, et je pense que IIS devrait aussi fournir une interface Web.
Encore aujourd’hui, je suis jaloux de la piètre interface de Tomcat qui permet de déployer à chaud une application web Java à distance avec une interface web, et de pouvoir gérer son cycle de vie (start/stop/reload).

Ca parait rien comme ça, mais il n’y a pas d’équivalent pour gérer les applications Web .Net, donc oui, je suis jaloux.

Tomcat n’est pas un serveur J2EE, on ne peut y déployer que des applications Web: WAR (Wab ARchive).
Mais un serveur J2EE est plus puissant: on peut y déployer des applications “service” (JAR/EAR) voir des tâches schédulées.
De plus, les applications offrent souvent des “MBean”: Managed Bean. Ce sont des objets qui sont accessibles à travers une couche de service, et tout les serveurs J2EE offrent une interface Web pour les gérer.
Vous pouvez ainsi exposer la bean “HttpCache” avec le service “Clear” par exemple. Bref, c’est le paradis des admins.

Alors quand vous allez voir les pages Web d’administration de JBoss ou SpringSource, on se dit qu’il manque clairement quelque chose à la plateforme .Net.

Classé dans Développement, DotNetServer Tag(s) associé(s): ,

Episode 1 : Mathias découvre PHP

juin 27, 2010 3 Commentaires

Bande de petits veinards, je vous offre le premier épisode aujourd’hui :)

PHP est l’un des premiers langages que j’ai étudié lors de ma formation. C’est en tout cas le premier avec lequel il était possible de « réaliser quelque chose », et non faire des « hello worlds »…

En fait, PHP était super simple à prendre en main, grâce à la magie de EASYPHP !
Ce dernier permet à tout débutant d’installer en quelques click un serveur Web, le module PHP, une base de donnée MySQL ainsi qu’un portail Web d’administration EASYPHP et un autre portail de gestion de la base PHPMyAdmin.

Je me suis alors dit : mais pourquoi un truc aussi magique n’existe pas pour .Net ?
De plus, le trio Apache+PHP+MySQL peuvent être installés sur Linux, ce qui a permis à cette techno de se répandre partout chez tous les hébergeurs à moindre coût !

Classé dans Développement, DotNetServer Tag(s) associé(s): ,

Introduction : Mathias est heureux… mais pourquoi ?

juin 27, 2010 Laisser un commentaire

YES !!! CA MARCHE !

Après des semaines de développement, j’ai finis par y arriver, et voici le résultat :

Mouhahahah, n’est elle pas merveilleuse mon applis ? Ah ? Non ?

Certes elle manque d’esthétisme, mais si elle a une carrosserie de Deudeuche, il y a la dessous un vrai moteur de Ferrari! (ou une usine à Gaz, c’est une question de point de vue).

Afin de comprendre mon excitation fasse à une pauvre fenêtre, il faut que je vous raconte un peu mon histoire….
Et comme c’est un peu long, je vais vous laisser digérer ça en plusieurs fois :

Classé dans Développement, DotNetServer Tag(s) associé(s):

Présentation de Spring.Net

juin 23, 2010 Laisser un commentaire

Je remercie David Coppet, Florent Dugué, Olivier Bazoud, Ophélie Rudent, ALT.Net, le SUG, Zenika, et l’équipe de France pour m’avoir permis de présenter Spring.Net.

C’était hier, dans les locaux de Zenika: http://www.eventbrite.com/event/727568176

Mais comme vous êtes nombreux à ne pas avoir pu y assister, et que certains d’entre vous souhaites consulter les sources des démos, je vous proposes de télécharger le tout sur mon Bitbucket: http://bitbucket.org/grozeille/spring.demo/src

J’espère que ça vous a plus, et que cela vous a permis de découvrir de nouvelles choses dans Spring.Net.
Si des gens d’ALT.Net  souhaite que je refasse la présentation à une date moins problématique, n’hésitez par à me le faire savoir.
De même, si vous souhaitez que j’approfondisse un sujet en prenant plus de temps à expliquer les démos, ce serait avec plaisir.

Share

Classé dans ALT.Net Tag(s) associé(s): , ,

DBus avec .Net

mai 5, 2010 1 Commentaire

Pour ceux qui ne le savent pas, je travail sur un serveur d’application .Net indépendant de la plateforme Windows: DotNetServer.

Après une version bonne pour une démo, j’ai voulu refactoriser le tout pour avoir quelque chose de viable.
Dans mon dernier billet, j’explique mon périple à la recherche d’un protocole de communication Inter-Processus, et j’ai choisi NDesk.DBus: l’implémentation full .Net de D-Bus.

La solution était sexy:

  • Déclaration des services par interface, ne pouvant exposer QUE des types simples ou Struct. Cela force à réaliser qu’en matière de communication, une instance d’objet ne veut rien dire et qu’on communique que par DTO.
  • Support des méthodes, propriétés et événements
  • Channel par Socket/TCP ou par Pipe
  • Communication optimisé binaire (pas d’XML ou de SOAP….)
  • Exposition des services sur le Bus avec un contrat au format XML (comme un WSDL en quelque sorte)
  • Cross-platform: provient du monde Linux mais existe sous Windows
  • Un standard de communication Inter-Processus, de plus en plus utilisé sous Linux, remplaçant CORBA (avec Bonobo)

Mais voila, tout n’est pas rose, et DBus me donne du fil à retorde.
L’implémentation .Net n’est pas très propre:

  • API pas très utilisable car quasiment tout est Internal
  • Pas de doc?
  • Ça manque de convention, le source n’est pas très lisible, j’ai envie de passer un coup de Resharper dessus :)
  • Beaucoup, beaucoup de commentaire du genre “//temporary hack” ou “//TODO“… beaucoup de code commenté qui prouve que la personne a voulu faire bien mais n’a pas eu le temps
  • Quand j’exécute DBusExplorer pour scanner mes services, cela plante 1 fois sur 2 mon client
  • Je n’arrive pas à faire marcher un service ou un client dans un Thread!!! Cela me bloque totalement

Je me demande si je ne vais pas revenir à une solution .Net Remoting:

  • implémentation .Net et Mono
  • channel IPC (par Pipe)
  • supporte les événements
  • DBus est vraiment orienté “Desktop” comme le D l’indique. J’en fait donc une utilisation détournée.

Mais une autre solution peut aussi faire l’affaire: ProtoBuf, un protocole performant inventé par Google.

Je vais tacher de vous tenir plus au courant, histoire aussi de recueillir des opinions concernant mes choix.

Classé dans Blabla, DotNetServer Tag(s) associé(s): , , ,

SOSNET

mars 9, 2010 6 Commentaires

Avec SOSNet, je dis STOP aux bugs!!

J’étais en train de manipuler les AppDomains sur mon projet DotNetServer (oui je sais le nom pu) et je voulais analyser la mémoire pour en savoir plus sur les Assembly chargée dans les AppDomains.

Pour cela, on peut utiliser WinDBG avec son extension SOS (Son of Strike) qui permet d’effectuer quelques commandes pour .Net. Il existe aussi une extension à SOS pour des commandes très utiles en .net: SOSEX.

Mais voila, WinDBG c’est barbare, en ligne de commande et pas très clair.
Yann Shwartz nous a fait une présentation sur touts ça lors d’une session ALT.Net, mais même après 1h d’explication, je crois qu’on est plus d’un à avoir laissé tombé la chose tellement c’est compliqué à utiliser.

Mais Yann a développé un outil formidable (oui oui, vraiment) qui permet de faire du LINQ sur nos objets en mémoire. Le projet s’appelle linqdbg et je vous invite tous à y contribuer. Associer cela à LinqPad et vous obtenez un outil puissant d’analyse de la mémoire de votre programme.

Mais je trouve tout de même que ce n’est pas la solution que j’attend. J’ai voulu quelque chose de plus “ergonomique” pour débuter avec Windbg.
J’ai trouvé pour cela SOSAssist mais je n’ai même pas réussi à l’exécuter (problème avec Windows 64bit?).

Ne trouvant rien d’équivalent, j’ai décidé de faire mon WinDBG Next Gen :)
Les sources du projet se trouve sur bitbucket car je suis devenu plus fan de Mercurial (HG) que de GIT.
Pour les plus flémard d’entre vous, vous pouvez télécharger la version compilée.

Et pour les vrais grosses huitres qui ne veulent même pas télécharger et l’exécuter, voici des screen de ce qui est possible de faire ;)

Sélectionnez une processus pour s'y attacher

Vous pouvez visualiser les AppDomains

Vous pouvez voir les Assembly chargée dans un AppDomain

Listing des types chargés en mémoire (avec recherche)

Double-click sur un type: vous voyez les instances. Double-click sur l'instance: vous voyez le détails de ses champs

Double-click sur un champ d'un objet: vous voyez le détail du membre... avec un 'Breadcrumb' pour naviguer entre les instances

La navigation d'instance fonctionne aussi avec les tableaux (sélection d'index)

Toutes les 'actions' sont tracées en ligne de commande. Il est toujours possible d'utilise les commandes comme avec WinDBG!!

Classé dans SoSNet Tag(s) associé(s): , , ,

DotNetServer

février 28, 2010 2 Commentaires

Comme je tarde à sortir mes posts sur les Techdays (et d’autres sujets, haha, surprise!), je vais en sortir un “tout petit”.

Pas de conteneur d’application en .Net… ou presque

En fait, c’est suite à une frustration absolue datant du premier jour ou j’ai découvert .Net (car je faisais du Java, avant, dans mon temps libre…).
Après avoir lourdement digéré J2EE, les EJB, RMI/IIOP, j’ai été déçu de ne rien voir de tel en .Net.
Certains dirait que ce n’est pas une grosse perte ;) En effet, J2EE n’a rien de simple, mais c’est quand même parfois puissant.

Je trouve stressant qu’une application .Net “d’entreprise” doit forcement dépendre des services Windows, des tâches schédulées, ou d’IIS. Déployer une application Java sur Tomcat est d’une simplicité déconcertante, et Microsoft propose un équivalent seulement dans le future Windows Server 2008 R2 avec Windows AppFabric.
Et encore, pour avoir vu la présentation aux Techdays, je suis plutôt déçu.
Lire la suite

Classé dans Développement, DotNetServer Tag(s) associé(s): , , , , ,

ALT.Net et l’orienté objet

janvier 25, 2010 5 Commentaires

La dernière réunion ALT.Net a été présentée par Frédéric Fadel sur le sujet: L’orienté objet : erreur historique ou la voie à poursuivre ?

Je remercie Freddy pour sa présentation et Octo pour leur accueil.

En résumé, nous avons évoqué les problèmes avec les langages objets, et ce qui nous fait perdre en productivité.
Pour cela, il faut définir exactement ce qu’est l’Objet: d’après Freddy : Héritage, Composition, Polymorphisme.

D’après lui, l’héritage est un handicap, la composition est une bonne chose, le polymorphisme aussi.
Lire la suite

Classé dans ALT.Net, Développement Tag(s) associé(s): , , , ,

Java for iPhone

janvier 21, 2010 Laisser un commentaire

Pour les fans de .Net et de l’iPhone, vous savez sans doute que vous pouvez vous éclater avec MonoTouch.
J’en profite pour dire que JB Evain en parlera aux TechDays.

La particularité et le défi de MonoTouch, c’est que le processeur de l’iPhone ne supporte pas une opération nécessaire à la compilation à chaud (JIT), qui est la base des langages sur une VirtualMachine (.Net et Java). L’application Mono est alors compilée nativement, avec une suppression des bibliothèques du framework inutilisées.

Et Java alors, est-ce que la communauté compte faire quelque chose?
Et bien une startup, Flexycore, l’a déjà fait: iSpectrum! Et le produit est gratuit pour les projets Open-Source!!! Ce qui n’est pas le cas pour MonoTouch.

Voici un aperçu de ce qui est possible:

Certes, la démo n’est pas “bandante”, mais derrière, il y a le support de J2ME, du JavaScript, les API de l’iPhone (comme le GPS) et bientôt l’API OpenGL ES.
Est-ce le retour de Java pour les jeux mobiles?

Classé dans Blabla, Développement Tag(s) associé(s): , , , ,

← Articles précédents

Articles plus récents →

Suivre

Get every new post delivered to your Inbox.