Pierre Tramonson a écrit 1453 commentaires

Non, l'anglais n'est plus obligatoirement en anglais.

Ouf ! J'ai cru qu'il était encore en anglais !

Ce qui m'intéresse aussi ce sont les outils d'audit de code utilisés pour Linux et les projets libres phares ainsi que leurs stats d'utilisation.

Leur usage est-il systématique ? Certainement pas.
A la rigueur c'est tolérable sur de petits projets de dév indépendants, mais dès qu'on rentre dans un logiciel un peu gros avec beaucoup de contributeurs, il faut un outil de verification !

Avec des pubs pour Microsoft Office ou SCO, ce serait du plus bel effet.

Encore un peu et il rejoint notre domi< national !

Unilog n'en a pas grand chose à faire. La mairie de Paris leur a demandé conseil sur un triple choix technique, budgétaire et humain (formation). Unilog a répondu.
Je ne comprends pas trop le troll de Daniel. Unilog n'est pas en avant vente Microsoft :)
Ceci dit je suis aussi curieux de lire ce rapport ;)

Ah zut il s'est vu tant que ça le troll ? ;)

Bon en fait ce que je voulais dire, c'est que lorsque je cherche une solution technique qui présente à la fois un aspect web (site internet ou intranet) et toute l'intégration de ce site dans un SI (alimentation batchs, interfaces avec d'autres applications, outils d'admin, appels RMI/CORBA, connexions EAI...), je pense plutôt à J2EE en premier, puis .NET puis PHP, malgré toutes mes affinités à utiliser PHP :)

Bien sur PHP est très adapté à la réalisation de sites (frontend et backend), mais lorsqu'on cherche à proposer une solution "globale" (même si le terme est un peu pompeux), au moins pour une application de taille respectable, je ne crois pas que PHP permette de faire tout ce que font les deux autres mastodontes ci-dessus.

Mais je pense que PHP peut tirer son épingle du jeu en multipliant l'interopérabilité avec les plateformes J2EE / .NET et les outils les plus utilisés en entreprise.

Et quand on ne veut pas faire de web ? PHP est-il toujours intéressant ?
Je veux réaliser une application de salle de marché, je la fais en PHP ?
Je veux avoir une chaîne de traitement batchs gros volume, c'est PHP qu'il me faut ?
Je veux une application client lourd, tiens si je la faisais en PHP ?

Mais je veux bien les URL où consulter tes sources.

Je vois ça comme un outil de standardisation de la communication/répartition des tâches entre équipes, ces équipes réalisant le métier d'une entreprise.

Cela suit un ensemble de flux ("workflow"), chacun étant composé d'étapes concernant un acteur (une équipe ou un ensemble d'equipes).
La facturation d'un devis, d'une commande, la réalisation d'un produit, suivent différentes étapes depuis une demande initiale vers une validation finale : c'est un processus métier.

Ce processus métier peut être décrit de manière graphique : BPML (un UML-like), puis traduit en un doc XML (BPEL) qui représente son exécution.

Bon, je vois bien à quoi ça sert, mais je ne sais pas si c'est bien.

Dans le monde des MMORPGs, la patience est une vertu. Aucun jeu ne sort jamais sans problèmes techniques ou de gameplay au début, seul le temps permet de distinguer les MMORPG qui sont suivis, qui évoluent, de ceux qui stagnent.
C'est bien souvent par les premiers patchs et les 2-3 premiers mois qu'on sait si un jeu va tenir ses promesses, rarement à sa sortie.

Je pense que le succès de NeL ira de pair avec celui de Ryzom, l'un étant la démo technologique à grande échelle de l'autre.

JNI imbittable ?
Pff franchement c'est pas très compliqué par rapport à d'autres aspects de la prog Java, il suffit d'écrire un wrapper.
Bien sur ça n'est pas aussi simple que réutiliser une lib sans rien avoir à faire, mais cela reste abordable.

Tu attaques la plate-forme J2EE sur cet aspect mono-langage, alors que c'est un choix délibéré à l'origine, même s'il y a eu des ouvertures vers d'autres langages depuis, via des APIs en plus.

Tu as mélangé des herbes à tisane dans ton café de 13h50 je crois.

Désolé mais dans tous les cas que j'ai pu rencontrer, la migration d'applications existantes vers .NET s'est aussi accompagnée de la réécriture complète du code en C#.
Il n'y a pas eu de réutilisation du code existant.
Ca ne veut pas dire que ce n'est pas intéressant dans certains cas !
Mais j'ai constaté que souvent homogénéiser les applis et les langages de dev cela va de pair.

Une bière bien fraîche ?

D'après les échos que j'en ai en ce moment, l'adoption d'OpenOffice.org est poussée à la fois par en haut (question de coût et de standards documentaires indépendants d'un fournisseur informatique) et par les services informatiques (dans lesquels on trouve beaucoup de personnes sensibilisées au logiciel libre).

Ce qui bloque encore, c'est la réticence des utilisateurs à changer de méthode de travail et d'outil. Il faut comprendre aussi que pour une personne qui a ses habitudes de travail, et qui a une certaine maîtrise d'un outil, il n'est jamais facile de se remettre de bon coeur au niveau débutant et de repartir de zéro (ou presque). On a une sensation de moins bien faire son travail, on est stressé parce qu'on n'est pas sur que le doc qu'on vient d'envoyer n'est pas impeccable, on perd du temps à trouver ses marques...

Les coûts de formation du personnel sont un point très important, ce n'est pas pour rien qu'il existe des services en "conduite du changement". Ca paraît un peu pipo comme formulation, mais c'est indispensable pour que la migration soit adoptée par l'utilisateur.

Sans oublier les coûts de migration : réécriture des modèles de doc, des macros MS Office, installations techniques...

Je suis assez d'accord, cela rend le code plus lisible, mais franchement je vois pas trop comment c'est possible de se planter dans le type d'objet d'une liste. Ca veut dire qu'on mélange des choux et des carottes. En général on s'en aperçoit à la compilation ou à la première exécution !

Avec une API pas encore assez mature qui dépend du bon vouloir de Microsoft. Chacun son goût.

Et Richie ? Tu as des nouvelles de lui ?

Ca n'est pas parce que Sun a accepté un compromis avec Microsoft sur StarOffice que cela l'empêche de soutenir OpenOffice.
Cela n'interdit pas non plus à Sun de continuer à contribuer de manière importante au développement d'OpenOffice.
Cet accord ne dit rien concernant les relations entre Sun et OpenOffice.
OpenOffice a besoin de Sun, tout comme Sun a besoin d'OpenOffice.

Je ne comprends donc pas pourquoi Sun et OpenOffice.org devraient collaborer dans un cadre nouveau, ni ce que cela peut changer dans leurs relations (hormis les appels aux trolls, forks, changements de licence qu'on voit habituellement dès qu'on parle d'un LL un peu connu).

Pourquoi voulez vous tout ramener à cette question ?

Ca m'intéresse tout ça, tu aurais des liens pour approfondir la chose ?

Il est vrai que la MSDN fournit pas mal d'exemples et aide beaucoup les débutants (traduction, liens vers des classes associées).

Cependant je lui trouve plusieurs défauts :
- quand on affiche une classe, on a la doc de tous les langages, et c'est pas super lisible (écrit trop petit par ex)
- ces exemples de code sont très mal indentés dans Firefox
- la navigation dans l'arborescence d'une API est mal foutue (interfaces/classes abstraites/packages tout ça ne saute pas immédiatement aux yeux)
- on n'a jamais de page résumant toutes les méthodes, arguments, classes mères et classes filles d'une classe
- les URLs directes sont difficilement lisibles et utilisables par le commun des mortels
- je ne sais pas la taille que ça fait mais ça m'a l'air d'être tout un bordel là dedans (ça tient sur un CD ?)
- la navigation est lente (entre autres synchro avec la TOC)

A côté de ça, la JavaDoc pêche de ces côtés-là :
- manque de tutoriaux simplement accessibles depuis la javadoc (les tutoriaux sont à l'extérieur de la javadoc, bien qu'ils soient librement téléchargeables)
- manque de traductions
- pas d'explications pour débutants

Mais avec qq années de Java derrière moi et qq mois de C#, je préfère bien évidemment la JavaDoc. Mon avis aurait peut être été différent si j'avais fait 3 ans de VB :)

C'est au moment de générer ton applet, tu peux lui dire d'importer des jars externes normalement, au lieu de juste faire un lien vers une lib externe. Mais c'est très mal si les jars de JAI sont gros ça va surcharger ton applet.

Le mieux étant d'avoir déjà les jars de JAI installés sur tous les postes clients.

Bon j'ai pas fait d'applets depuis 3 ans, alors...

A priori tu as besoin de récupérer les jars de JAI, qu'on trouve ici http://java.sun.com/products/java-media/jai/downloads/download-1_1_(...)

Ensuite tu lis la doc d'install http://java.sun.com/products/java-media/jai/INSTALL-1_1_2.html(...) je sais pas quoi tu dire de plus je me suis jamais servi de cette API.

Il faut mettre quelques jar dans jre/lib/ext et jre/bin comme d'habitude.

Comme ces deux paths sont connus par l'install initiale de n'importe quel JRE, tu ne devrais même pas avoir à modifier un quelconque classpath.

Comme précisé ici : http://java.sun.com/products/java-media/jai/iio.html(...) les classes de codec font partie d'un package com.sun.media.jai.* qui ne se trouve pas dans les J2SE et J2EE standards, puisque c'est en com.* au lieu d'être en java.* ou javax.*
Il y a ce qu'il faut dans l'API java pour manipuler des images mais pas pour utiliser les codecs, qui ne sont pas toujours utilisables sans royalties... Du moins je présume que c'est à cause de ça que ces classes ne font pas partie de l'API Java.

Il faut donc récupérer la lib (ou une autre) ailleurs. Tu trouveras une liste de liens ici par exemple http://java.sun.com/products/java-media/jai/utilities/jaiutils.html(...)

La doc de l'API Sun est dispo là : http://java.sun.com/products/java-media/jai/forDevelopers/jai-apido(...)

La MSDN est ignoblement inutilisable à côté de la JavaDoc.

J'ai lu ghetto communiste la première fois que j'ai vu le titre.
Il va falloir que je reprenne un café ça va plus du tout !