• Ma carte son externe ne veut plus fonctionner j’ai toujours réussi à la faire fonctionner mais là pas encore trouvé de solution.
• J’ai un portable et à la maison et je travail sur un écran externe. Hé bien avec la nouvelle version plus rien n’apparaît sur mon écran externe. Apparement il y aurait un bug encore non résolu… Super pratique !
• A peu près toutes les heures mon écran se freeze complétement et une décoloration apparaît sur tout l’écran. Seul solution que j’ai trouvé, redémarrer Ubuntu…
• Et pour le dessert, j’ai souscrit à un abonnement Ubuntu One pour avoir 50 Gb d’espace de stockage. J’ai voulu synchrnosier mes documents (3.2 Gb de données) et j’ai laisser tourner mon ordinateur 8 jours pour uploader et il n’y a encore absolument rien en ligne ! Franchement ridicule pour dire qu’il s’agit là d’un service payant.

Bref, je trouve franchement lamentable qu’en passant à une version supérieure on a des problèmes de compatibilité matériel qui n’en étaient pas avec les versions précédentes. Et que dire sur Ubuntu One, le principe me plaisait mais c’est inutilisable ! Je me vois contrains d’annuler mon abonnement pour les mois suivants et je vais sûrement me tourner vers dropbox qui semble plus aboutis.

Le terme CMS est très utilisé mais souvent pas correctement. En effet, les développeurs ont tendance à oublier le sens même de ce terme qui se focalise vraiment sur de la Gestion de Contenu ! Si l’on regarde les centaines (sans trop exagérer…) de CMS qu’il existe en PHP on se rend compte que la plupart sont plus des « générateurs de sites » pour débutants plutôt que de véritables système de gestion de contenu. Ils se contentent généralement de fournir un moyen d’afficher du contenu sous forme d'(X)HTML sans que l’utilisateur n’ai besoin de toucher à du code. Pourtant, la gestion de contenu peut aller bien plus loin en fournissant sont contenu à d’autres plateformes qui n’ont rien à voir avec du Web ! Je pense notamment à l’eZ Conference 09 ou une entreprise a développé un site web avec eZ Publish qui fournissait en même temps des données sur des montres de plongée. Imaginez faire ça avec un CMS conventionnel et vous vous rendrez vite compte que c’est impossible ou très difficilement réalisable.

Mais alors qu’est-ce qui rend eZ Publish « plus malin » que les autres me direz-vous… C’est ça façon de stocker le contenu ! Dans la base de données d’eZ Publish vous ne trouverez pas la moindre trace d'(X)HTML, tout est stocké sous forme d’XML ce qui permet d’afficher les données comme bon nous semble. Joomla! par exemple, stocke directement de l’HTML dans la base de données ce qui lui permet de directement l’afficher sans se soucier de ça présentation. Avec eZ Publish il est nécessaire de créer un fichier pour chaque type de contenu avec du code XHTML qui s’occupe d’afficher les données au format Web. Grâce à cette façon de procéder, on a la possibilité d’afficher le contenu sous n’importe quelle forme, il suffit de créer d’autres fichiers de mise en forme pour s’adapter à d’autres standards… RSS, Atom etc.

Le point central d’eZ Publish est la gestion de contenu et non pas la création de sites web. Pour la partie site web ils ont développé une extension (eZwebin) qui permet de retrouver les fonctionnalités que l’on a l’habitude de retrouver dans d’autres CMS.

Je ne donne là que mon avis et ça n’engagen que moi, je suis ouvert à toute critique !

Le problème de la base de données est assez vite réglé en utilisant une base de données distante qui est partagée et utilisée par chaque développeur. Chaque poste client possède son propre serveur web ce qui permet au développeur de tester certains modules spécifiques à sa partie de développement. Avoir un serveur web sur son poste est également très utile pour faire du déboggage ou du profiling. Au début j’avais de gros problèmes de performances avec la base de données distante que j’ai finalement pu corriger (cf. Topic sur le forum).

Quant au problème lié à Subversion, il fallait que lorsqu’un développeur commit un fichier, la modification soit également faites sur le serveur de pré-production. Comme on part du principe que lorsqu’on fait un commit le fichier en question est fonctionnel il est intéressant de voir si c’est également le cas sur le serveur de pré-production. Pour celà j’ai simplement fais un checkout du projet dans le répértoire « www/mon_projet » de mon serveur web de pré-production et ensuite j’ai créer un script de post-commit qui force le projet sur le serveur de pré-production à faire un update.

Voici le script en question :

De cette manière, à chaque fois qu’un développeur de l’équipe commit un nouveau fichier, il est directement mis-à-jour sur le serveur de pré-production.

On a donc, via ce système, un environement de développement complet avec des serveurs de développement (les clients), un serveur de pré-production et le serveur de production final.

Je suis assez satisfait de cette configuration mais pas encore réellement convaincu que c’est la meilleure façon de travailler sur un projet web en équipe avec Subversion. J’attend donc vos retour d’expérience dans le domaine.

La grande nouveauté que va apporter cette version sont les « Object states » (états d’objets). Il nous sera désormais possible de créer des états, par exemple verrouillé – non verrouillé et ces états pourront être appliqués à n’importe quels objets.

Ensuite, lorsqu’on travaille sur les polices et droits d’accès on a la possiblité de définir certaines actions autorisées que si l’objet et dans un certain état. Pratique non ? On peut donc définir que le rôle d’éditeur ne peut utiliser le couple content – edit (module – action) que si l’objet à l’état non verrouillé.

J’ai récemment réalisé un projet ou cette fonctionnalité m’aurait été forte utile. En effet j’avais certains dossiers que l’utilisateur final de l’administration n’osait en aucun cas supprimer. Avec les objects states il m’aurait suffit de mettre ces quelques dossiers en états locked

Pour une description complète de cette journée vous pouvez vous rendre ici : http://blog.gauthier-garnier.fr/post/eZ-developer-day-a-Paris-7-novembre-2008

Triste fin pour moi Je me suis trompé de train et je me suis retrouvé à 300 km de Jazoon (on ne rigole pas) ! Du coup je ne peux pas suivre la dernière conférence que j’avais prévu de visiter. Désolé.

Tout d’abord ils nous a rappelé ce qu’est REST et AJAX.

REST (Representational state transfer) :
– Est un modèle client / serveur.
– Définit un style d’architecture
– Définit une façon de construire une application

L’orateur estime qu’aujourd’hui le web devrait utiliser REST mais que très peu de personnes l’utilisent correctement ! De plus les navigateurs ne supportent pas les méthodes « PUT » et « DELETE ». Heureusement AJAX permet de remedier à ce problème…

Ensuite il nous a présenté les Web Forms 2.0, ils sont devenu un standard Web. Ils seraient réalisables avec AJAX et DOM de Javascript mais on se compliquerais la vie.

Il nous a montré un exemple de formulaire 2.0 très intéressant, premièrement la méthode du formulaire n’était pas POST ou GET mais PUT ! Deuxièmement les input avait un type (email, date, time, etc…), la validation est donc automatiquement assurée. Troisièmement on passe une valeur de retour au formulaire, ce qui signifie qu’il n’y aura pas de chargement, il va juste mettre à jour une valeur.

L’un des aspects les plus intéressant est certainement la validation intégrée des inputs. Il y a également les répétiteurs qui permettent de répéter plusieurs fois des partie de code.

Seul soucis, actuellement les Web Forms 2.0 sont uniquement supporté par Opera 9.5… Dommage car ça a l’air vraiment puissant !

Je n’ai pas non plus résister à quitter la salle ! Ce labo était très inintéressant, donc je ne peux malheureusement pas vous dire grand chose !

J’ai plus perçu ce labo comme un bon coup de pub pour l’entreprise adhoc qu’autre chose…

Comme à chaque présentation de GWT il y a eu une petite introduction je ne vais donc pas vous la décrire.

La présentation est très intéressante, il nous a expliqué comment concevoir des applications web pour l’utilisateur et non pas pour le développeur. GWT va dans cette direction en générant un code JavaScript extrêmement diminué pour prendre moins de place lors des chargements. Typiquement pas de formattage du code variable très courte et pas de commentaires.

Il y a aussi une grande partie d’optimisation qui est réalisée grâce au « deferred binding » que je décrirai plus en détail dans mon reportage complet.

Une option intéressante qui a été présentée est la possibilité de compiler directement sur le serveur. Si l’on remarque que la machine du client est trop lente on peut passer la compilation au serveur.

Il a également préciser que l’on ne devrait pas utiliser de widgets si c’est juste pour faire de l’HTML.

Ensuite il a un peu présenter l’internationalisation qui est semblable à ce que l’on retrouve en Java. Puis il a abordé les problèmes que l’on rencontre avec AJAX au niveau des bookmarks et de l’historique de navigation. GWT permet de créer un historique pour les requêtes AJAX.

Pour finir il nous a présenté la gestion des erreurs et les « best practices » pour les gérer, les logs et les tests unitaires avec Selenium !

Petite déception : il n’a quasiment pas parler de Gears

Dommage que cette présentation soit venue après la première que j’ai suivis. L’orateur nous a simplement présenté GWT et fait une petite démo à la fin. Je n’ai donc pas trouvé très intéressant.

Il a quand même un peu décortiqué la problématique de la conversion entre Java et JavaScript notamment au niveau de la reflection et du chargement dynamique des classes. Ces deux fonctionnalités étant présentent dans Java mais pas dans JavaScript !