J'ai intégré quelques pom, on verra ce que ça donne.
Normalement, ça donne bien. On l'utilise depuis un bon mois de notre côté et ça m'a vraiment simplifié la vie. Le fait que ce soit simple et con fait que ça marche du coup.
Ce serait cool de pouvoir tout ajouter d'un coup, cliquer 50 fois sur suivre c'est un peu long la première fois.
Oui… En fait, on pouvait le faire avant qu'on me convainque de faire des boutons Ajax : on avait mis une case à cocher pour tout un bloc donné. On pourrait sans doute le refaire en Ajax aussi. Je le note.
La feature "regrouper les artifacts sous des projets" ce serait vraiment cool aussi pour retrouver les pom à mettre à jour
Vu qu'on extrait l'info du pom, on pourrait sans doute tagger les artifacts avec l'artifactId extrait du pom. Ca répondrait au besoin ?
Les services Rest, on y viendra sûrement. Il faut juste arriver à voir ce qui peut être utile.
Pour l'instant, ma priorité est d'arriver à enrichir l'information, notamment via l'ajout des release notes, annonces… C'est clairement une information relativement pénible à trouver quand on la multiplie par le nombre d'artifacts et le nombre de versions et qui a son importance quand on commence à envisager une mise à jour.
Mon dieu, un premier commentaire positif sur un journal. Inquiétant :).
Alors, architecture, c'est beaucoup dire… on a plutôt avancé en mode "faisons simple et on fera évoluer en fonction des besoins/idées" plutôt que concevoir un gros truc modulaire.
Mais ça pourrait se faire oui. Par contre, je dois avouer que le pom.xml a l'avantage de s'analyser super facilement (on a juste utilisé jsoup pour le faire). Pour les autres fichiers, c'est souvent moins simple.
En gros, si on nous fournit l'outil d'analyse, on pourra sans souci l'intégrer dans l'interface de notre côté.
De notre côté, on a prévu de rester sur Maven encore un moment, le temps que l'outillage se mette au niveau.
Après comme le l'ai dit si tu fait de la webapp ou assimilé en Java ton monde à entièrement changé en bien c'est 5 dernières années. Si tu es dans les couches basses et les choses "plus techniques", ce qui est mon cas, ton avis est peu être beaucoup plus nuancé.
Ouais, on fait un peu des deux (mais beaucoup plus de web) et c'est clair que c'est sur la partie web que ça a le plus évolué en bien.
Du coup, l'impression est sans doute plus largement positive vu de ma fenêtre, étant données les proportions de chaque.
En clair, le message que je voulais faire passer est que Java est vraiment un très très bon choix pour faire du web, désormais.
GWT… un choix que je ne comprendrais décidément pas :). Pour fournir un vrai avis argumenté, je trouve que c'est vraiment ce qu'on a conçu de plus pourri en terme d'ingénierie logicielle depuis les premiers jours de l'informatique.
Bonne chance pour la suite. Je pense qu'on doit avoir à peu près la même chose que Scub Foundation chez nous (à GWT près…) mais je dois avouer que je n'ai pas encore eu l'énergie de le distribuer largement/éditer, avec toute la charge de maintenance que ça a tendance à générer - ce qui n'empêche pas notre socle d'être libre.
L'interaction avec les systèmes hôtes est ridicule.
Suis d'accord là-dessus. Et d'accord aussi que toutes les librairies autour sauvent la baraque et font que ça n'est pas vraiment un souci (même si ça reste un petit facteur de pénibilité quand on débarque dans l'univers Java sans connaître les pointeurs qui vont bien).
Sur le langage il ne s'est absolument rien passé de notable entre Java 5 et Java 7.
Oui et non. Il y a pas mal de petits détails qui font des vrais changements. L'exemple que je prends toujours c'est la capacité à utiliser @Override sur les interfaces en Java 6. Ca a vraiment changé quelque chose par rapport à Java 5 même si ça paraît ridicule (après, il faut dire que c'était bien débile de l'avoir fait comme ça en Java 5).
Java 7 apporte aussi son lot d'améliorations. Certaines ont été reportées en Java 8 (tout le boulot démarré sur l'API date), on verra quand ça arrive mais il y a vraiment eu du boulot de fait.
c'est un langage moyen qui n'évolue plus
C'est là où tu as raté le "compilé" dans ce que j'ai dit. Mis à part les trucs hypes pour lesquels bien malins qui devinera s'ils seront encore là l'année prochaine, les langages compilés évoluent lentement. Et Java est plutôt dans les bons élèves de ce côté là, à mon sens.
C'est sûr que les langages interprétés évoluent beaucoup plus vite. Mais, franchement, je n'ai vraiment plus aucune envie de faire de l'interprété maintenant que je peux faire du compilé sans la lourdeur qui allait avec.
Ce n'est pas un outil qu'il te faut c'est revoir complètement ton équipe et son organisation.
Ce n'est pas en balançant des phrases à l'emporte pièce que tu convaincras grand monde. Mon équipe et mon organisation fonctionnent très bien, je te remercie de t'en préoccuper. Ce qu'on livre est plutôt dans le très haut du panier en terme de qualité par rapport à ce que j'ai pu voir sur la majorité des applications que j'ai auditées/relues.
On utilise Sonar intelligemment et ça nous convient bien. Le fait d'avoir des gens impliqués qui veulent faire du bon boulot est évidemment un facteur clé.
Ce n'est pas parce que tu ne le vois pas s'intégrer dans tes manières de travailler qu'on ne peut pas en faire un outil intelligent.
Sur le "paie 1000x plus avant", je ne sais pas si je suis d'accord. On faisait du bon boulot avant et ça nous a permis d'améliorer certaines choses avec un coût proche de 0. Résultat, j'ai trouvé ça rentable.
Après, j'ai vu des gens avoir tout l'outillage et faire des applications pourries jusqu'à la moelle. Je ne dis pas que ça résout tous les problèmes.
Mon dernier argument n'était pas le moindre. En société de services, tu as parfois des clients qui sont très pointilleux sur le sujet et ils veulent un joli rapport avec des jolis graphes. Et ils ne te lâcheront pas tant qu'ils ne les auront pas.
Et note que je suis bien d'accord que ce n'est pas ça qui va empêcher de faire du mauvais boulot et une archi toute pourrie.
Bref, je pense qu'on n'est pas loin d'être d'accord mais que je suis plus nuancé.
Par contre, mince alors, un débat argumenté sur Java sur Linuxfr, ça fait bizarre. Un mythe s'effondre.
Au niveau du langage malheureusement non. Au niveau des outils de base malheureusement non.
Tu peux développer ? Notamment au niveau de ce que tu appelles "outils de base" ?
Pour un langage compilé qui a une longue histoire, je trouve que Java évolue plutôt vite et dans le bon sens.
Sonar c'est vraiment le dernier truc dont tu as besoin pour "gérer la qualité".
Ce n'est pas parce qu'on peut en faire mauvais usage que c'est un mauvais outil. Pour le pratiquer depuis très longtemps, ça permet de se poser une fois de temps en temps et de regarder ce qu'il se passe quand on n'est pas dans le code au quotidien.
C'est aussi très pratique quand on reprend des projets externes.
Rien que le fait de packager plusieurs outils et de normaliser leur utilisation est un vrai truc apporté par Sonar.
Si tu as des règles à faire respecter et qu'elles ne le sont pas ca doit bloquer ton build pas pondre des graphes.
C'est une bonne idée, ça. Tant qu'à faire, le mieux est de bloquer le build sur chaque problème, comme ça, chaque build devient une aventure.
Mettre toutes les vérifications à faire dans le chemin du build n'est pas forcément toujours jouable sur les gros projets : ça peut fortement allonger le temps de build (et même si c'est déporté sur intégration continue, ça peut vite devenir casse pied). Se prendre un moment une fois par semaine pour relire le rapport Sonar qui est toujours dispo (je parle principalement de la partie violations), c'est plutôt très pratique.
Et pour l'avoir pratiqué, ça suffit pour qu'une équipe responsable intègre automatiquement les règles dans sa manière de coder (enfin, celles qu'elles n'avaient pas déjà intégrées parce qu'il y a quand même beaucoup de bon sens) au fur et à mesure.
A quoi servent des rapports sur la complexité cyclomatique, le pourcentage de commentaire ou la duplication de code ?
Duplication de code, ça sert de temps en temps, même si je suis d'accord que quand on code intelligemment, c'est peu souvent utile.
Pour la complexité, je fais principalement au feeling. Les commentaires idem.
Après, pour avoir subi un audit CAST (produit proprio équivalent) obligatoire sur un projet qu'on a livré à un client, ça nous a bien aidé à ce que les indicateurs CAST ne soient pas dans le rouge.
Oui, clairement, c'est dommage que Java pâtisse toujours de cette image d'usine à gaz car c'est vraiment devenu au fil des années un environnement super agréable à utiliser et très très productif - et qui sait que j'étais le premier à pester il y a 5+ ans de cela quand un projet Java commençait forcément par 4 mois d'étude pour savoir comment on allait le démarrer.
Une grosse partie de la lourdeur a disparu, ça a pas mal sédimenté, c'est très bien outillé (Jenkins, Sonar que tu citais mais aussi toute la gestion du cycle de vie), le fait que ce soit compilé est vraiment un plus à mon sens - d'autant qu'avec le déploiement à chaud, c'est quand même relativement peu contraignant -, et il y a des composants vraiment très très sympas - pour en citer deux que je bénis tous les jours : Wicket et Hibernate Search.
En plus, si on veut quand même continuer à faire des usines à gaz avec, utiliser des composants tout pourris et se plaindre, c'est toujours possible : tout le monde est content.
Bref, ça vaut le coup de rejeter un coup d'oeil pour ceux qui ont fui (à raison cough cough) il y a quelques années. On peut vraiment se faire plaisir à bosser avec.
Clairement, en entreprise, il faut vraiment se caler un proxy local. Mais vu que Nexus s'installe en 2 minutes, c'est parfaitement gérable.
Concernant les avantages, je dirai :
- mise au carré de tous les processus de build, livraison…
- capacité à centraliser les numéros de versions via des pom parents pour que tout soit homogène
- pas à galérer à récupérer des libs sur Internet / pas de répertoire lib commité dans les sources - sur des gros projets avec plein de libs, ça fait vite des énormes repositories - multiplié par plein de projets, c'est vite ingérable au niveau boîte. Le proxy Nexus sécurise les builds et conserve l'ensemble des artifacts utilisés de manière centralisée.
- le maven-release-plugin qui permet de poser les tags, construire les artifacts, monter les versions automatiquement etc… Une release propre se fait en deux commandes Maven, manipulations SCM comprises (tags, branches, mise à jour des versions dans les fichiers et commits des fichiers au bon moment pour que tout soit cohérent).
- pas mal de plugins vraiment utiles notamment pour la gestion des annotation processors (pour JPA, QueryDSL…), la construction de packages (maven-release-plugin, maven-assembly-plugin)
- une intégration Eclipse qui, maintenant, tient plutôt bien la route et aide pas mal à régler les soucis de dépendance (ah l'onglet Dependency hierarchy du pom.xml…)
On a un peu galéré au début mais cela fait quelques années que tous nos projets sortent comme cela et je ne regrette clairement pas l'investissement initial. Pour récupérer un projet, on se limite à :
- déclarer le repository SVN/Git dans Eclipse ;
- faire un Checkout as Maven projects ;
- Fin : ça builde, tout est là, je peux faire des releases avec les mêmes commandes que sur tous mes autres projets…
Par contre, je suis d'accord qu'il y a quelques années, quand on bidouillait et qu'on n'avait pas industrialisé le truc, c'était plutôt pénible. Le passage à Maven 3 a bien aidé aussi.
En conclusion, je dirai que ce n'est pas parfait, mais ça fait quand même bien le boulot une fois qu'on sait s'en servir et qu'on a mis en place les outils qui vont bien.
Effectivement, faire un système de lock dans postgresql va être assez embêtant. Je vais peut-être revoir ma copie, en ne mettant pas de possibilité de choisir son id.
Oui, ce n'est clairement pas l'idée du siècle de laisser l'utilisateur libre de choisir l'id. S'il choisit la valeur maximale de ta séquence - 1, ça va vite être pénible...
Sauf qu'un (select max(id) from table) ne fonctionnera que si tu lockes complètement la table à chaque fois. Sinon, ça te ramènera sans problème deux valeurs identiques dans deux transactions différentes dès que tu auras un certain débit de transactions.
C'est tout l'intérêt des séquences qui ne sont pas transactionnelles.
Ceci dit, un serial crée automatiquement une séquence associée _et_ la valeur par défaut qui va bien.
Pourquoi veux-tu préciser la valeur du champ dans ta requête ? Si tu ne le mets pas dans la requête, il prendra automatiquement la valeur par défaut. Je veux bien que _default_ soit utile parfois mais, là, je pense que tu peux t'en passer.
Et si jamais tu veux absolument mettre le _default_, pourquoi le mettre dans les paramètres alors que ça n'en est pas un ? Met le directement dans le texte de la requête.
Non. Lui, il veut un truc simple. Il ne sait d'ailleurs peut-être même pas qu'on sait faire les traductions de paquets.
Mmmh, tu as déjà parlé à des packagers ? Parce que je pense que tu te trompes en supposant que le packager va gérer lui-même les traductions dans les langues qu'il pratique (ça conduira de toute manière à des traductions approximatives, peu étant vraiment bilingues, encore moins trilingues).
La traduction est en général gérée par des équipes dédiées. Ca permet d'avoir une homogénéité dans les traductions (et même ainsi, c'est parfois peu satisfaisant).
Je vais prendre un exemple bête dans mon cas : si je fais un patch pour PostgreSQL qui demande une traduction, je ne vais pas la faire moi-même, y compris en français. Quelqu'un s'en occupe globalement et c'est bien mieux ainsi.
Accessoirement, ton fichier de méta-données avec toutes tes traductions dedans va vite devenir insupportable. Attends d'avoir du japonais et des gens qui l'éditent n'importe comment et qui vont te commiter un fichier complètement foireux.
Prenez un Windows, et regardez.
Difficile d'avoir une discussion argumentée quand tu sautes du coq à l'âne. Windows est traduit parce qu'un paquet de pognon est mis là-dedans.
Les distributions sont partiellement traduites parce que c'est un travail chiant, peu valorisant et que la majorité des gens qui le font ne sont pas payés pour le faire. Malgré toute leur bonne volonté, ils font ce qu'ils peuvent.
Accessoirement, les distributions Linux vont trop vite pour que les traductions suivent et on ne bloquera jamais une release parce que la traduction française n'est pas finie. Je suis assez sûr que chez MS, ils planifient la chose pour que le produit sorte dans une langue majeure avec *tout* traduit et plein de séances de relecture.
Une traduction homogène de qualité est un boulot titanesque (et je parle en connaissance de cause, j'avais repris les 6000-8000 clés de traduction d'un logiciel complètement histoire que tout soit homogène et cohérent - et 6000-8000, ce n'est pas bien gros quand on y pense).
L'utilisateur anglophobe sera totalement perdu. C'est ce genre de problème auxquels il faut faire attention.
Et tu penses que personne n'y a pensé avant toi ? Le manque de traduction n'a pas grand chose à voir avec une difficulté technique. C'est juste un manque de ressources dédiées à cela dans la durée.
Et espérer le résoudre en répartissant la traduction sur les packagers, ça donnera un truc aussi bien que les systèmes de traduction distribués où chacun traduit une chaîne en passant : rien de bien cohérent.
Setup sera un peu plus hackish, mais fera la même chose. En effet, on peut définir l'Installation-Root d'un paquet. Il suffit, quand on installe les paquets, de les installer dans /tmp/teporarytree. Une fois que tout est installé et testé (les postinst() des paquets peuvent servir à vérifier, ainsi que les || exit 1 dans le packagebuild), on copie simplement ce dossier dans /, et c'est fait.
Tu as bien en tête que la copie de fichiers n'est pas atomique ? Et qu'il ne va pas suffire de copier ? Il va aussi falloir supprimer les fichiers qui ne sont plus nécessaires, remonter d'éventuels conflits sur des fichiers de configuration existants suite à modification du fichier du paquet... Que se passe t-il avec ton système si le disque / est full pendant la copie ?
Je m'intéresse assez peu au sujet donc je n'ai aucune idée de comment rpm et dpkg ont réglé ces problèmes (et s'ils l'ont fait complètement d'ailleurs) mais tu n'as pas l'air d'en avoir plus et c'est inquiétant.
Si ça pète dans certains cas et que je me retrouve avec une installation cassée que je dois refaire, je vais vraiment être super content d'avoir gagné 2 secondes chaque mois quand je rajoute un paquet.
A mon avis, il faut vraiment que tu te poses et que tu réfléchisses à ce que veulent vraiment les gens. Tu verras que leur priorité n°1 sur un gestionnaire de packages est d'avoir un truc à toute épreuve.
Les gens ont grogné sur yum quand la lenteur était vraiment insupportable. Depuis que c'est acceptable sans être mirifique, les gens ne se plaignent plus trop.
Que tu attaques en réfléchissant à la performance et que tu en fasses une préoccupation majeure, pourquoi pas, il va bien falloir que tu te différencies. Mais sans avoir la vision globale de comment tu vas régler le problème du "rock solid", tu risques quand même fort d'arriver dans le mur à la fin.
Après, tu fais bien ce que tu veux. C'était juste un éclairage différent en passant sur ta démarche.
Pour RPM, j'ai cru voir (mais je n'en suis pas certain) qu'il faut taper manuellement le nom de tous les fichiers qu'on veut inclure dans le paquet.
Tu as raison de ne pas en être certain. Tu peux mettre des wildcards et ce n'est pas spécialement pénible. Ca permet en outre de vérifier que ton paquet n'oublie pas de fichiers ou que tu n'as rien oublié de ce que tu avais prévu.
A l'usage, c'est un très bon garde-fou.
alors que Debian nécessite un puissant gettext
C'est pratique de toujours supposer qu'il n'y a jamais de bonne raison pour les choix de design des autres. Debian réutilise un standard archi utilisé et archi connu. Ca semble plutôt un bon choix plutôt que de réinventer la roue. Les gens le connaissent, on trouve facilement de la doc et des outils pour le gérer.
Tu supposes que c'est lourd, que ça ralentit tout mais tu as fait un peu de profiling sur le sujet ?
Même si c'était le cas, je ne suis pas sûr que la différence justifie de se passer d'un standard de fait.
Après, je suis peut-être l'exception mais je n'ai jamais spécialement été handicapé par la lenteur que tu trouves si gênante. Je n'installe pas des paquets tous les jours de manière manuelle sur mon desktop (vu que tu as l'air de vouloir traiter la problématique desktop). Et quand je le fais, je n'ai pas l'impression de perdre mon temps à attendre. Peut-être aussi parce que je ne suis pas spécialement concentré dessus et que je fais autre chose en même temps.
Par contre, la chose vraiment importante AMHA, c'est la notion de transaction. Je ne veux pas qu'un upgrade commence et me laisse mon installation à moitié en vrac si je le coupe, s'il y a un souci dans l'upgrade ou si ma machine plante pour une raison X ou Y.
Typiquement, si tu regardes ce que fait yum :
* téléchargement de tous les paquets pour être sûr de tout avoir ;
* test de la transaction ;
* si c'est validé, on va réaliser l'installation.
Il y a une très bonne raison au fait de ne pas tout lancer en parallèle. Si tu n'as pas résolu ce problème, tu peux mettre ton système de téléchargement/installation parallèle à la poubelle.
Après, tu as peut-être déjà pensé à cela mais ça ne se voit pas trop dans ce que tu présentes. Je ne vois qu'une course à la vitesse, qui n'est pas spécialement une priorité sur ce type de logiciel AMHA. C'est un plus une fois que tu as tout le reste mais pas une priorité.
Après, je n'ai pas spécialement regardé ce que tu as fait. Je voulais juste mettre en exergue quelque chose qui me gêne profondément dans la démarche : quand on essaie de faire autrement, il est important de comprendre pourquoi les précédents ont fait comme ils ont fait. Ca peut être des raisons historiques, des raisons techniques ou le fait qu'ils n'y ont pas pensé. Mais il ne faut pas forcément toujours partir du principe que les idées des autres sont moins bonnes que les siennes.
Tu fais la moitié de la démarche en allant voir ce qu'ils font mais tu pars toujours du principe qu'ils ont tort et n'ont pas de bonnes raisons de le faire. Il y a un juste milieu à trouver.
Tu peux essayer de comparer Zend_Lucene et Lucene (et le résultat sera en faveur de Lucene) mais Solr est bien plus haut niveau (par opposition à bas niveau).
Il te fournit tout un tas de fonctionnalités par dessus Lucene :
- la capacité à définir un schéma avec des types (et tu peux cabler automatiquement tes types en fonction d'un suffixe sur le nom d'un champ) pour lesquels tu peux définir des filtres (suppression d'accents, passage en minuscules, tokenisations diverses) - c'est hyper pratique à l'usage ;
- la capacité à faire du faceting ;
- un parser de requêtes (DisMax) qui te permet d'envoyer des requêtes brutes que Solr traite en gérant lui-même les problématiques d'échappement ;
- la réplication d'index ;
- le fait de pouvoir envoyer tes requêtes via HTTP depuis n'importe quelle application (pratique pour centraliser l'indexation et partager la recherche) ;
- ...
Le tout enveloppé dans une application super bien packagée, bien documentée et d'une stabilité exemplaire (ça tourne depuis bientôt 2 ans sur un site à forte audience chez nous et on n'a *aucun* souci). On a maintenant plusieurs instances pour plusieurs clients et c'est partout du même niveau de stabilité.
Si je résume, Lucene est un composant permettant de construire des moteurs de recherche, Solr est une application de recherche.
Ca vaut vraiment plus que le coup d'oeil quand on a besoin de fonctionnalités de recherche. C'est clairement ce qu'on a de plus avancé en libre à l'heure actuelle et c'est vraiment un bonheur à utiliser, tellement c'est simple et bien documenté.
Je déconseille fortement Sequoia mis à part s'il a les compétences pour débugger et comprendre les problèmes rencontrés.
C'est plus que pointu et on a rencontré pas mal de problèmes de bloquage dans certains cas bizarres avec des vraies applications. On a corrigé ce qu'on a pu dans Sequoia mais certains problèmes n'étaient pas assez reproductibles pour qu'on puisse comprendre d'où ça vient.
Sequoia est plus ou moins abandonné par Continuent et il n'y a qu'Emmanuel Cecchet qui continue à travailler dessus.
Par ailleurs :
- Sequoia ne règle pas vraiment le problème du multi-master dans le sens où tu ne vas pas réussir à scaler tes écritures (elles sont répliquées en logiciel sur chaque noeud) ;
- Sequoia introduit un overhead non négligeable et ça dégrade quand même bien les performances sur une utilisation web standard (plein de petites requêtes).
Je n'ai pas eu le temps de regarder Tungstene le nouveau produit de Continuent. Ils ont annoncé du nouveau côté Open Source pour les prochaines semaines.
On a des séries de lightning talks. En étoffant un peu - notamment en décrivant mieux l'usage concret/métier de la chose -, je pense que ça pourrait rentrer dans ce cadre.
Montrer des usages atypiques de PostgreSQL (ici GIS sur le poste client) est très intéressant pour les lightning talks.
En passant, on est tout à fait prêt à discuter des propositions en avance de phase et aider les gens à la construire. N'hésitez pas à nous contacter pour cela.
Pour répondre à la question qui ne tardera pas, ce sera libre (en Apache 2 a priori) si un jour on décide de distribuer l'engin.
Pour l'instant, il n'y a qu'une seule installation et elle est à la maison. Comme je le disais, on a vraiment fait des choix adaptés à notre manière de faire notre métier, je ne sais pas si c'est généralisable sans qu'on rende le truc plus complexe que je ne le voudrais.
Et pour avoir passé plusieurs années de ma vie à développer GForge et à devoir faire du support à l'installation (car ce n'est jamais simple à installer des bestioles comme ça car très lié à l'environnement externe), je ne suis pas sûr d'avoir envie de remettre le couvert sur cet aspect.
Accessoirement, le meilleur acronyme que j'ai pu trouver, c'est Wombat Organizes the Management of Bevelopment And Teaming. Tu comprendras que c'est difficile de distribuer quelque chose dans ces conditions.
L'archi de la bête est grossièrement décrite dans une présentation interne que j'avais faite en mars : http://people.openwide.fr/~gsmet/linuxfr/20090327-Anatomie_d(...) . Il n'y a pas de capture vu que c'était interne mais ça donne une idée de comment c'est fait.
Ca a beaucoup évolué depuis mais, à mon sens, ce sont surtout les principes qui sont intéressants.
J'en avais pas mal discuté avec Christian Bayle qui est chez FT avec qui j'avais travaillé sur GForge et qui fait partie du projet européen Coclico dont on parle ici (auquel nous n'avons pas été conviés pour des raisons qui m'échappent vu notre historique d'activité sur le sujet des forges libres mais c'est une autre histoire :)).
Le changement de nom de GForge vers FusionForge n'est pas un fork. Toute l'équipe qui bossait encore sur GForge old school a basculé vers le nouveau projet FusionForge. Le problème était plus un problème de différenciation de nom entre GForge 5 AS, GForge 5 Community Edition... et le GForge libre original. Ca devenait difficile de suivre.
L'histoire de GForge est assez amusante car la création du projet vient de la fermeture du code de sf.net par VA Linux. Et finir par redevenir un projet proprio est une belle ironie de l'histoire.
Pour avoir fait partie du projet à l'époque, c'était assez simple : il fallait vraiment refondre entièrement le code et l'architecture (car c'est vraiment vraiment très très moche) et on n'arrivait pas à le financer malgré les clients assez prestigieux qui l'utilisent. Tim Perdue a alors pris la décision de faire cette réécriture en proprio. Perso, j'ai arrêté à ce moment-là car je ne voyais plus trop comment on allait arriver à refondre globalement le truc sans les ressources de sa boîte (refondre ce genre d'appli de fond en comble juste sur du temps perso avec un vrai boulot prenant à côté est assez illusoire).
GForge est un exemple typique de projet sur lequel on arrive à financer le service (installation, développements spécifiques - certains contribués mais ça ne suffit pas) mais où il est vraiment difficile de financer une évolution globale.
Le service prend vraiment du temps et demande des personnes assez compétentes (comme certains le disaient plus haut, c'est assez difficile de trouver des profils appli + système) et au delà du financement, le facteur temps des personnes compétentes devient vite très limitant.
De notre côté, on utilise maintenant une forge qui est vraiment très différente de ce qui se fait actuellement sur le marché : il s'agit vraiment d'un orchestrateur de droits et de services pour les projets et il n'y a plus vraiment de services hébergés en propre (on n'a pas redéveloppé un bugtracker, un gestionnaire de tâches, un browser de sources...).
Typiquement, ça crée des repos CVS, SVN, Git, des Trac, des espaces web où poser des fichiers, des sites Alfresco Share, le tout en quasi temps réel via une file d'attente (plus de symptômes cron qui est passé il y a 5 minutes et qui repassera dans une heure).
Les droits sont gérés via Spring Security, CAS et des modules Perl Apache qui font appel à des services REST qui vérifient les droits sur les projets pour les trucs type ViewVC ou Trac.
On a pu aussi prendre en compte toutes les règles métier de la boîte (ex : tous les développeurs de la boîte ont accès à tous les projets non confidentiels en lecture). Et si on souhaite ajouter un type de service, il suffit d'implémenter la petite couche qui va bien pour le créer, ce qui se fait en général assez rapidement, maintenant qu'on a pas mal d'exemples différents d'intégration.
Après, ça ne convient pas à tout le monde loin de là de ne pas avoir tout intégré dans une même application mais, pour l'instant, je trouve ça beaucoup mieux ainsi que ce qu'on avait avant, compte tenu de notre mode de fonctionnement en interne.
Il y a deux "noms" de PostgreSQL qui ont fait un tour chez Sun et on ne peut pas vraiment les appeler "le développeur principal" : le premier (Josh Berkus) fait principalement de l'advocacy et le deuxième (Peter Eisentraut) est loin d'être le plus actif de nos jours.
Accessoirement, ils en sont tous les deux partis, Josh peu après le rachat de MySQL et Peter il y a plusieurs semaines.
Pour trouver "les développeurs principaux", il faut plutôt regarder du côté de Red Hat (Tom Lane), du côté d'EntrepriseDB (plein), Command Prompt aussi et de tous les autres qui bossent sans casquette.
Il y a quelques personnes chez Sun qui font du PostgreSQL (entre autres choses) mais c'est plutôt du portage Solaris, de l'ajout de sondes DTrace et des benchs sur du matos Sun avec plein de threads. Bref, rien de critique.
Faudrait voir à se renseigner un peu avant de sortir des trucs comme ça...
Autant je trouve les tendances intéressantes, autant les chiffres bruts sont à prendre avec beaucoup de pincettes comme pour toute étude.
En effet, ils ne tiennent compte que des formations Anaska et ib. Si Anaska est très visible pour certains composants, ce n'est pas le cas pour d'autres. D'où le fait que les tendances sont tout de même intéressantes mais que comparer la répartition pour des composants phares Anaska et pour des choses moins visibles n'a pas vraiment de sens.
Pour prendre un exemple que je connais bien et où une répartition est donnée dans le document, Anaska est très très visible pour MySQL, beaucoup moins pour PostgreSQL où des acteurs plus spécialisés sont beaucoup plus présents (je pense à Dalibo notamment).
Du coup, la tendance est intéressante mais comparer la répartition entre les BD à partir de ces indicateurs est une très mauvaise idée (les chiffres de répartition sont donnés dans le document et une phrase dans les tendances générales y fait référence).
En dehors de ça, c'est très intéressant d'utiliser la formation comme point de vue pour avoir des grosses tendances. Merci pour ce document.
[^] # Re: Ça a l'air sympa
Posté par Guillaume Smet (site web personnel) . En réponse au journal Artifact Listener - Service de notification pour Maven Central - Java inside. Évalué à 1.
Normalement, ça donne bien. On l'utilise depuis un bon mois de notre côté et ça m'a vraiment simplifié la vie. Le fait que ce soit simple et con fait que ça marche du coup.
Oui… En fait, on pouvait le faire avant qu'on me convainque de faire des boutons Ajax : on avait mis une case à cocher pour tout un bloc donné. On pourrait sans doute le refaire en Ajax aussi. Je le note.
Vu qu'on extrait l'info du pom, on pourrait sans doute tagger les artifacts avec l'artifactId extrait du pom. Ca répondrait au besoin ?
[^] # Re: Joli boulot
Posté par Guillaume Smet (site web personnel) . En réponse au journal Artifact Listener - Service de notification pour Maven Central - Java inside. Évalué à 1.
Les services Rest, on y viendra sûrement. Il faut juste arriver à voir ce qui peut être utile.
Pour l'instant, ma priorité est d'arriver à enrichir l'information, notamment via l'ajout des release notes, annonces… C'est clairement une information relativement pénible à trouver quand on la multiplie par le nombre d'artifacts et le nombre de versions et qui a son importance quand on commence à envisager une mise à jour.
[^] # Re: Joli boulot
Posté par Guillaume Smet (site web personnel) . En réponse au journal Artifact Listener - Service de notification pour Maven Central - Java inside. Évalué à 2.
Mon dieu, un premier commentaire positif sur un journal. Inquiétant :).
Alors, architecture, c'est beaucoup dire… on a plutôt avancé en mode "faisons simple et on fera évoluer en fonction des besoins/idées" plutôt que concevoir un gros truc modulaire.
Mais ça pourrait se faire oui. Par contre, je dois avouer que le pom.xml a l'avantage de s'analyser super facilement (on a juste utilisé jsoup pour le faire). Pour les autres fichiers, c'est souvent moins simple.
En gros, si on nous fournit l'outil d'analyse, on pourra sans souci l'intégrer dans l'interface de notre côté.
De notre côté, on a prévu de rester sur Maven encore un moment, le temps que l'outillage se mette au niveau.
[^] # Re: Usine
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 1.
Ouais, on fait un peu des deux (mais beaucoup plus de web) et c'est clair que c'est sur la partie web que ça a le plus évolué en bien.
Du coup, l'impression est sans doute plus largement positive vu de ma fenêtre, étant données les proportions de chaque.
En clair, le message que je voulais faire passer est que Java est vraiment un très très bon choix pour faire du web, désormais.
Merci pour l'échange.
[^] # Re: Usine
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 3.
GWT… un choix que je ne comprendrais décidément pas :). Pour fournir un vrai avis argumenté, je trouve que c'est vraiment ce qu'on a conçu de plus pourri en terme d'ingénierie logicielle depuis les premiers jours de l'informatique.
Bonne chance pour la suite. Je pense qu'on doit avoir à peu près la même chose que Scub Foundation chez nous (à GWT près…) mais je dois avouer que je n'ai pas encore eu l'énergie de le distribuer largement/éditer, avec toute la charge de maintenance que ça a tendance à générer - ce qui n'empêche pas notre socle d'être libre.
Résultat des courses, je suis assez admiratif.
[^] # Re: Usine
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 3.
Suis d'accord là-dessus. Et d'accord aussi que toutes les librairies autour sauvent la baraque et font que ça n'est pas vraiment un souci (même si ça reste un petit facteur de pénibilité quand on débarque dans l'univers Java sans connaître les pointeurs qui vont bien).
Oui et non. Il y a pas mal de petits détails qui font des vrais changements. L'exemple que je prends toujours c'est la capacité à utiliser @Override sur les interfaces en Java 6. Ca a vraiment changé quelque chose par rapport à Java 5 même si ça paraît ridicule (après, il faut dire que c'était bien débile de l'avoir fait comme ça en Java 5).
Java 7 apporte aussi son lot d'améliorations. Certaines ont été reportées en Java 8 (tout le boulot démarré sur l'API date), on verra quand ça arrive mais il y a vraiment eu du boulot de fait.
C'est là où tu as raté le "compilé" dans ce que j'ai dit. Mis à part les trucs hypes pour lesquels bien malins qui devinera s'ils seront encore là l'année prochaine, les langages compilés évoluent lentement. Et Java est plutôt dans les bons élèves de ce côté là, à mon sens.
C'est sûr que les langages interprétés évoluent beaucoup plus vite. Mais, franchement, je n'ai vraiment plus aucune envie de faire de l'interprété maintenant que je peux faire du compilé sans la lourdeur qui allait avec.
Ce n'est pas en balançant des phrases à l'emporte pièce que tu convaincras grand monde. Mon équipe et mon organisation fonctionnent très bien, je te remercie de t'en préoccuper. Ce qu'on livre est plutôt dans le très haut du panier en terme de qualité par rapport à ce que j'ai pu voir sur la majorité des applications que j'ai auditées/relues.
On utilise Sonar intelligemment et ça nous convient bien. Le fait d'avoir des gens impliqués qui veulent faire du bon boulot est évidemment un facteur clé.
Ce n'est pas parce que tu ne le vois pas s'intégrer dans tes manières de travailler qu'on ne peut pas en faire un outil intelligent.
Sur le "paie 1000x plus avant", je ne sais pas si je suis d'accord. On faisait du bon boulot avant et ça nous a permis d'améliorer certaines choses avec un coût proche de 0. Résultat, j'ai trouvé ça rentable.
Après, j'ai vu des gens avoir tout l'outillage et faire des applications pourries jusqu'à la moelle. Je ne dis pas que ça résout tous les problèmes.
Mon dernier argument n'était pas le moindre. En société de services, tu as parfois des clients qui sont très pointilleux sur le sujet et ils veulent un joli rapport avec des jolis graphes. Et ils ne te lâcheront pas tant qu'ils ne les auront pas.
Et note que je suis bien d'accord que ce n'est pas ça qui va empêcher de faire du mauvais boulot et une archi toute pourrie.
Bref, je pense qu'on n'est pas loin d'être d'accord mais que je suis plus nuancé.
Par contre, mince alors, un débat argumenté sur Java sur Linuxfr, ça fait bizarre. Un mythe s'effondre.
[^] # Re: Usine
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 4.
Tu peux développer ? Notamment au niveau de ce que tu appelles "outils de base" ?
Pour un langage compilé qui a une longue histoire, je trouve que Java évolue plutôt vite et dans le bon sens.
Ce n'est pas parce qu'on peut en faire mauvais usage que c'est un mauvais outil. Pour le pratiquer depuis très longtemps, ça permet de se poser une fois de temps en temps et de regarder ce qu'il se passe quand on n'est pas dans le code au quotidien.
C'est aussi très pratique quand on reprend des projets externes.
Rien que le fait de packager plusieurs outils et de normaliser leur utilisation est un vrai truc apporté par Sonar.
C'est une bonne idée, ça. Tant qu'à faire, le mieux est de bloquer le build sur chaque problème, comme ça, chaque build devient une aventure.
Mettre toutes les vérifications à faire dans le chemin du build n'est pas forcément toujours jouable sur les gros projets : ça peut fortement allonger le temps de build (et même si c'est déporté sur intégration continue, ça peut vite devenir casse pied). Se prendre un moment une fois par semaine pour relire le rapport Sonar qui est toujours dispo (je parle principalement de la partie violations), c'est plutôt très pratique.
Et pour l'avoir pratiqué, ça suffit pour qu'une équipe responsable intègre automatiquement les règles dans sa manière de coder (enfin, celles qu'elles n'avaient pas déjà intégrées parce qu'il y a quand même beaucoup de bon sens) au fur et à mesure.
Duplication de code, ça sert de temps en temps, même si je suis d'accord que quand on code intelligemment, c'est peu souvent utile.
Pour la complexité, je fais principalement au feeling. Les commentaires idem.
Après, pour avoir subi un audit CAST (produit proprio équivalent) obligatoire sur un projet qu'on a livré à un client, ça nous a bien aidé à ce que les indicateurs CAST ne soient pas dans le rouge.
[^] # Re: Usine
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 6.
Oui, clairement, c'est dommage que Java pâtisse toujours de cette image d'usine à gaz car c'est vraiment devenu au fil des années un environnement super agréable à utiliser et très très productif - et qui sait que j'étais le premier à pester il y a 5+ ans de cela quand un projet Java commençait forcément par 4 mois d'étude pour savoir comment on allait le démarrer.
Une grosse partie de la lourdeur a disparu, ça a pas mal sédimenté, c'est très bien outillé (Jenkins, Sonar que tu citais mais aussi toute la gestion du cycle de vie), le fait que ce soit compilé est vraiment un plus à mon sens - d'autant qu'avec le déploiement à chaud, c'est quand même relativement peu contraignant -, et il y a des composants vraiment très très sympas - pour en citer deux que je bénis tous les jours : Wicket et Hibernate Search.
En plus, si on veut quand même continuer à faire des usines à gaz avec, utiliser des composants tout pourris et se plaindre, c'est toujours possible : tout le monde est content.
Bref, ça vaut le coup de rejeter un coup d'oeil pour ceux qui ont fui (à raison cough cough) il y a quelques années. On peut vraiment se faire plaisir à bosser avec.
Note pour Stéphane : il y a quelques & gt; qui traînent sur http://www.scub-foundation.org/accueil/documentation/tutorial-gestion-des-donnees-avec-postgresql/ .
[^] # Re: À suivre...
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Enfin, un client EBICS java libre. Évalué à 3.
Et, j'oubliais, vu que c'est beaucoup plus normalisé que du ant, les intégrations dans les outils tierces sont beaucoup plus industrielles aussi.
Typiquement, l'intégration dans Sonar ou Jenkins ne demande quasiment aucune configuration. C'est plutôt pratique quand on gère pas mal de projets.
Le fait que tu retrouves toujours la même arborescence est vraiment un plus aussi.
[^] # Re: À suivre...
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Enfin, un client EBICS java libre. Évalué à 3.
C'est comme tout, ça demande une prise en main.
Clairement, en entreprise, il faut vraiment se caler un proxy local. Mais vu que Nexus s'installe en 2 minutes, c'est parfaitement gérable.
Concernant les avantages, je dirai :
- mise au carré de tous les processus de build, livraison…
- capacité à centraliser les numéros de versions via des pom parents pour que tout soit homogène
- pas à galérer à récupérer des libs sur Internet / pas de répertoire lib commité dans les sources - sur des gros projets avec plein de libs, ça fait vite des énormes repositories - multiplié par plein de projets, c'est vite ingérable au niveau boîte. Le proxy Nexus sécurise les builds et conserve l'ensemble des artifacts utilisés de manière centralisée.
- le maven-release-plugin qui permet de poser les tags, construire les artifacts, monter les versions automatiquement etc… Une release propre se fait en deux commandes Maven, manipulations SCM comprises (tags, branches, mise à jour des versions dans les fichiers et commits des fichiers au bon moment pour que tout soit cohérent).
- pas mal de plugins vraiment utiles notamment pour la gestion des annotation processors (pour JPA, QueryDSL…), la construction de packages (maven-release-plugin, maven-assembly-plugin)
- une intégration Eclipse qui, maintenant, tient plutôt bien la route et aide pas mal à régler les soucis de dépendance (ah l'onglet Dependency hierarchy du pom.xml…)
On a un peu galéré au début mais cela fait quelques années que tous nos projets sortent comme cela et je ne regrette clairement pas l'investissement initial. Pour récupérer un projet, on se limite à :
- déclarer le repository SVN/Git dans Eclipse ;
- faire un Checkout as Maven projects ;
- Fin : ça builde, tout est là, je peux faire des releases avec les mêmes commandes que sur tous mes autres projets…
Par contre, je suis d'accord qu'il y a quelques années, quand on bidouillait et qu'on n'avait pas industrialisé le truc, c'était plutôt pénible. Le passage à Maven 3 a bien aidé aussi.
En conclusion, je dirai que ce n'est pas parfait, mais ça fait quand même bien le boulot une fois qu'on sait s'en servir et qu'on a mis en place les outils qui vont bien.
[^] # Re: Tiens, encore ?
Posté par Guillaume Smet (site web personnel) . En réponse au journal Fin de Mandriva .... Évalué à 7.
et riva bien qui riva le dernier...
[^] # Re: nextval()
Posté par Guillaume Smet (site web personnel) . En réponse au message PHP, PDO, Postgresql, SERIAL, et DEFAULT. Évalué à 1.
Oui, ce n'est clairement pas l'idée du siècle de laisser l'utilisateur libre de choisir l'id. S'il choisit la valeur maximale de ta séquence - 1, ça va vite être pénible...
[^] # Re: nextval()
Posté par Guillaume Smet (site web personnel) . En réponse au message PHP, PDO, Postgresql, SERIAL, et DEFAULT. Évalué à 1.
C'est tout l'intérêt des séquences qui ne sont pas transactionnelles.
Ceci dit, un serial crée automatiquement une séquence associée _et_ la valeur par défaut qui va bien.
Pourquoi veux-tu préciser la valeur du champ dans ta requête ? Si tu ne le mets pas dans la requête, il prendra automatiquement la valeur par défaut. Je veux bien que _default_ soit utile parfois mais, là, je pense que tu peux t'en passer.
Et si jamais tu veux absolument mettre le _default_, pourquoi le mettre dans les paramètres alors que ça n'en est pas un ? Met le directement dans le texte de la requête.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par Guillaume Smet (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 10.
Mmmh, tu as déjà parlé à des packagers ? Parce que je pense que tu te trompes en supposant que le packager va gérer lui-même les traductions dans les langues qu'il pratique (ça conduira de toute manière à des traductions approximatives, peu étant vraiment bilingues, encore moins trilingues).
La traduction est en général gérée par des équipes dédiées. Ca permet d'avoir une homogénéité dans les traductions (et même ainsi, c'est parfois peu satisfaisant).
Je vais prendre un exemple bête dans mon cas : si je fais un patch pour PostgreSQL qui demande une traduction, je ne vais pas la faire moi-même, y compris en français. Quelqu'un s'en occupe globalement et c'est bien mieux ainsi.
Accessoirement, ton fichier de méta-données avec toutes tes traductions dedans va vite devenir insupportable. Attends d'avoir du japonais et des gens qui l'éditent n'importe comment et qui vont te commiter un fichier complètement foireux.
Prenez un Windows, et regardez.
Difficile d'avoir une discussion argumentée quand tu sautes du coq à l'âne. Windows est traduit parce qu'un paquet de pognon est mis là-dedans.
Les distributions sont partiellement traduites parce que c'est un travail chiant, peu valorisant et que la majorité des gens qui le font ne sont pas payés pour le faire. Malgré toute leur bonne volonté, ils font ce qu'ils peuvent.
Accessoirement, les distributions Linux vont trop vite pour que les traductions suivent et on ne bloquera jamais une release parce que la traduction française n'est pas finie. Je suis assez sûr que chez MS, ils planifient la chose pour que le produit sorte dans une langue majeure avec *tout* traduit et plein de séances de relecture.
Une traduction homogène de qualité est un boulot titanesque (et je parle en connaissance de cause, j'avais repris les 6000-8000 clés de traduction d'un logiciel complètement histoire que tout soit homogène et cohérent - et 6000-8000, ce n'est pas bien gros quand on y pense).
L'utilisateur anglophobe sera totalement perdu. C'est ce genre de problème auxquels il faut faire attention.
Et tu penses que personne n'y a pensé avant toi ? Le manque de traduction n'a pas grand chose à voir avec une difficulté technique. C'est juste un manque de ressources dédiées à cela dans la durée.
Et espérer le résoudre en répartissant la traduction sur les packagers, ça donnera un truc aussi bien que les systèmes de traduction distribués où chacun traduit une chaîne en passant : rien de bien cohérent.
Setup sera un peu plus hackish, mais fera la même chose. En effet, on peut définir l'Installation-Root d'un paquet. Il suffit, quand on installe les paquets, de les installer dans /tmp/teporarytree. Une fois que tout est installé et testé (les postinst() des paquets peuvent servir à vérifier, ainsi que les || exit 1 dans le packagebuild), on copie simplement ce dossier dans /, et c'est fait.
Tu as bien en tête que la copie de fichiers n'est pas atomique ? Et qu'il ne va pas suffire de copier ? Il va aussi falloir supprimer les fichiers qui ne sont plus nécessaires, remonter d'éventuels conflits sur des fichiers de configuration existants suite à modification du fichier du paquet... Que se passe t-il avec ton système si le disque / est full pendant la copie ?
Je m'intéresse assez peu au sujet donc je n'ai aucune idée de comment rpm et dpkg ont réglé ces problèmes (et s'ils l'ont fait complètement d'ailleurs) mais tu n'as pas l'air d'en avoir plus et c'est inquiétant.
Si ça pète dans certains cas et que je me retrouve avec une installation cassée que je dois refaire, je vais vraiment être super content d'avoir gagné 2 secondes chaque mois quand je rajoute un paquet.
A mon avis, il faut vraiment que tu te poses et que tu réfléchisses à ce que veulent vraiment les gens. Tu verras que leur priorité n°1 sur un gestionnaire de packages est d'avoir un truc à toute épreuve.
Les gens ont grogné sur yum quand la lenteur était vraiment insupportable. Depuis que c'est acceptable sans être mirifique, les gens ne se plaignent plus trop.
Que tu attaques en réfléchissant à la performance et que tu en fasses une préoccupation majeure, pourquoi pas, il va bien falloir que tu te différencies. Mais sans avoir la vision globale de comment tu vas régler le problème du "rock solid", tu risques quand même fort d'arriver dans le mur à la fin.
Après, tu fais bien ce que tu veux. C'était juste un éclairage différent en passant sur ta démarche.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par Guillaume Smet (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 10.
Pour RPM, j'ai cru voir (mais je n'en suis pas certain) qu'il faut taper manuellement le nom de tous les fichiers qu'on veut inclure dans le paquet.
Tu as raison de ne pas en être certain. Tu peux mettre des wildcards et ce n'est pas spécialement pénible. Ca permet en outre de vérifier que ton paquet n'oublie pas de fichiers ou que tu n'as rien oublié de ce que tu avais prévu.
A l'usage, c'est un très bon garde-fou.
alors que Debian nécessite un puissant gettext
C'est pratique de toujours supposer qu'il n'y a jamais de bonne raison pour les choix de design des autres. Debian réutilise un standard archi utilisé et archi connu. Ca semble plutôt un bon choix plutôt que de réinventer la roue. Les gens le connaissent, on trouve facilement de la doc et des outils pour le gérer.
Tu supposes que c'est lourd, que ça ralentit tout mais tu as fait un peu de profiling sur le sujet ?
Même si c'était le cas, je ne suis pas sûr que la différence justifie de se passer d'un standard de fait.
Après, je suis peut-être l'exception mais je n'ai jamais spécialement été handicapé par la lenteur que tu trouves si gênante. Je n'installe pas des paquets tous les jours de manière manuelle sur mon desktop (vu que tu as l'air de vouloir traiter la problématique desktop). Et quand je le fais, je n'ai pas l'impression de perdre mon temps à attendre. Peut-être aussi parce que je ne suis pas spécialement concentré dessus et que je fais autre chose en même temps.
Par contre, la chose vraiment importante AMHA, c'est la notion de transaction. Je ne veux pas qu'un upgrade commence et me laisse mon installation à moitié en vrac si je le coupe, s'il y a un souci dans l'upgrade ou si ma machine plante pour une raison X ou Y.
Typiquement, si tu regardes ce que fait yum :
* téléchargement de tous les paquets pour être sûr de tout avoir ;
* test de la transaction ;
* si c'est validé, on va réaliser l'installation.
Il y a une très bonne raison au fait de ne pas tout lancer en parallèle. Si tu n'as pas résolu ce problème, tu peux mettre ton système de téléchargement/installation parallèle à la poubelle.
Après, tu as peut-être déjà pensé à cela mais ça ne se voit pas trop dans ce que tu présentes. Je ne vois qu'une course à la vitesse, qui n'est pas spécialement une priorité sur ce type de logiciel AMHA. C'est un plus une fois que tu as tout le reste mais pas une priorité.
Après, je n'ai pas spécialement regardé ce que tu as fait. Je voulais juste mettre en exergue quelque chose qui me gêne profondément dans la démarche : quand on essaie de faire autrement, il est important de comprendre pourquoi les précédents ont fait comme ils ont fait. Ca peut être des raisons historiques, des raisons techniques ou le fait qu'ils n'y ont pas pensé. Mais il ne faut pas forcément toujours partir du principe que les idées des autres sont moins bonnes que les siennes.
Tu fais la moitié de la démarche en allant voir ce qu'ils font mais tu pars toujours du principe qu'ils ont tort et n'ont pas de bonnes raisons de le faire. Il y a un juste milieu à trouver.
[^] # Re: Solr vs Zend_Lucene
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Solr 1.4 est de sortie. Évalué à 4.
Ca n'a pas grand chose à voir en fait.
Tu peux essayer de comparer Zend_Lucene et Lucene (et le résultat sera en faveur de Lucene) mais Solr est bien plus haut niveau (par opposition à bas niveau).
Il te fournit tout un tas de fonctionnalités par dessus Lucene :
- la capacité à définir un schéma avec des types (et tu peux cabler automatiquement tes types en fonction d'un suffixe sur le nom d'un champ) pour lesquels tu peux définir des filtres (suppression d'accents, passage en minuscules, tokenisations diverses) - c'est hyper pratique à l'usage ;
- la capacité à faire du faceting ;
- un parser de requêtes (DisMax) qui te permet d'envoyer des requêtes brutes que Solr traite en gérant lui-même les problématiques d'échappement ;
- la réplication d'index ;
- le fait de pouvoir envoyer tes requêtes via HTTP depuis n'importe quelle application (pratique pour centraliser l'indexation et partager la recherche) ;
- ...
Le tout enveloppé dans une application super bien packagée, bien documentée et d'une stabilité exemplaire (ça tourne depuis bientôt 2 ans sur un site à forte audience chez nous et on n'a *aucun* souci). On a maintenant plusieurs instances pour plusieurs clients et c'est partout du même niveau de stabilité.
Si je résume, Lucene est un composant permettant de construire des moteurs de recherche, Solr est une application de recherche.
Ca vaut vraiment plus que le coup d'oeil quand on a besoin de fonctionnalités de recherche. C'est clairement ce qu'on a de plus avancé en libre à l'heure actuelle et c'est vraiment un bonheur à utiliser, tellement c'est simple et bien documenté.
--
Guillaume
[^] # Re: Et Sequoia ?
Posté par Guillaume Smet (site web personnel) . En réponse au journal Réplication de BDD multi-maître asynchrône.. Évalué à 2.
C'est plus que pointu et on a rencontré pas mal de problèmes de bloquage dans certains cas bizarres avec des vraies applications. On a corrigé ce qu'on a pu dans Sequoia mais certains problèmes n'étaient pas assez reproductibles pour qu'on puisse comprendre d'où ça vient.
Sequoia est plus ou moins abandonné par Continuent et il n'y a qu'Emmanuel Cecchet qui continue à travailler dessus.
Par ailleurs :
- Sequoia ne règle pas vraiment le problème du multi-master dans le sens où tu ne vas pas réussir à scaler tes écritures (elles sont répliquées en logiciel sur chaque noeud) ;
- Sequoia introduit un overhead non négligeable et ça dégrade quand même bien les performances sur une utilisation web standard (plein de petites requêtes).
Je n'ai pas eu le temps de regarder Tungstene le nouveau produit de Continuent. Ils ont annoncé du nouveau côté Open Source pour les prochaines semaines.
# Pas tout à fait
Posté par Guillaume Smet (site web personnel) . En réponse au journal Réplication de BDD multi-maître asynchrône.. Évalué à 5.
Non, pas du tout : il n'y a aucune volonté d'intégrer Postgres-R dans PostgreSQL.
Les travaux actuels sur l'intégration d'une réplication à l'intérieur de PostgreSQL ne sont pas basés dessus (et ce ne sera pas du multi-master).
Dernièrement, on entend pas mal parler de http://www.rubyrep.org/ aussi. Ca peut valoir le coup d'oeil.
[^] # Re: Ca marche pas ?
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Appel à conférences pour le pgDay2009 européen. Évalué à 1.
On a bien reçu ta proposition sur la bonne adresse qui est présente sur le site.
Merci de nous avoir remonté la boulette.
--
Guillaume
[^] # Re: interet ?
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Appel à conférences pour le pgDay2009 européen. Évalué à 3.
En tous les cas, n'hésite pas à proposer quelque chose en suivant les instructions qui sont là : http://2009.pgday.eu/fr:callforpapers .
Montrer des usages atypiques de PostgreSQL (ici GIS sur le poste client) est très intéressant pour les lightning talks.
En passant, on est tout à fait prêt à discuter des propositions en avance de phase et aider les gens à la construire. N'hésitez pas à nous contacter pour cela.
[^] # Re: GForge → FusionForge
Posté par Guillaume Smet (site web personnel) . En réponse au message Offre d'emploi pour faire évoluer les forges (gforge, ...). Évalué à 3.
Pour répondre à la question qui ne tardera pas, ce sera libre (en Apache 2 a priori) si un jour on décide de distribuer l'engin.
Pour l'instant, il n'y a qu'une seule installation et elle est à la maison. Comme je le disais, on a vraiment fait des choix adaptés à notre manière de faire notre métier, je ne sais pas si c'est généralisable sans qu'on rende le truc plus complexe que je ne le voudrais.
Et pour avoir passé plusieurs années de ma vie à développer GForge et à devoir faire du support à l'installation (car ce n'est jamais simple à installer des bestioles comme ça car très lié à l'environnement externe), je ne suis pas sûr d'avoir envie de remettre le couvert sur cet aspect.
Accessoirement, le meilleur acronyme que j'ai pu trouver, c'est Wombat Organizes the Management of Bevelopment And Teaming. Tu comprendras que c'est difficile de distribuer quelque chose dans ces conditions.
L'archi de la bête est grossièrement décrite dans une présentation interne que j'avais faite en mars : http://people.openwide.fr/~gsmet/linuxfr/20090327-Anatomie_d(...) . Il n'y a pas de capture vu que c'était interne mais ça donne une idée de comment c'est fait.
Ca a beaucoup évolué depuis mais, à mon sens, ce sont surtout les principes qui sont intéressants.
J'en avais pas mal discuté avec Christian Bayle qui est chez FT avec qui j'avais travaillé sur GForge et qui fait partie du projet européen Coclico dont on parle ici (auquel nous n'avons pas été conviés pour des raisons qui m'échappent vu notre historique d'activité sur le sujet des forges libres mais c'est une autre histoire :)).
[^] # Re: GForge → FusionForge
Posté par Guillaume Smet (site web personnel) . En réponse au message Offre d'emploi pour faire évoluer les forges (gforge, ...). Évalué à 3.
Le changement de nom de GForge vers FusionForge n'est pas un fork. Toute l'équipe qui bossait encore sur GForge old school a basculé vers le nouveau projet FusionForge. Le problème était plus un problème de différenciation de nom entre GForge 5 AS, GForge 5 Community Edition... et le GForge libre original. Ca devenait difficile de suivre.
L'histoire de GForge est assez amusante car la création du projet vient de la fermeture du code de sf.net par VA Linux. Et finir par redevenir un projet proprio est une belle ironie de l'histoire.
Pour avoir fait partie du projet à l'époque, c'était assez simple : il fallait vraiment refondre entièrement le code et l'architecture (car c'est vraiment vraiment très très moche) et on n'arrivait pas à le financer malgré les clients assez prestigieux qui l'utilisent. Tim Perdue a alors pris la décision de faire cette réécriture en proprio. Perso, j'ai arrêté à ce moment-là car je ne voyais plus trop comment on allait arriver à refondre globalement le truc sans les ressources de sa boîte (refondre ce genre d'appli de fond en comble juste sur du temps perso avec un vrai boulot prenant à côté est assez illusoire).
GForge est un exemple typique de projet sur lequel on arrive à financer le service (installation, développements spécifiques - certains contribués mais ça ne suffit pas) mais où il est vraiment difficile de financer une évolution globale.
Le service prend vraiment du temps et demande des personnes assez compétentes (comme certains le disaient plus haut, c'est assez difficile de trouver des profils appli + système) et au delà du financement, le facteur temps des personnes compétentes devient vite très limitant.
De notre côté, on utilise maintenant une forge qui est vraiment très différente de ce qui se fait actuellement sur le marché : il s'agit vraiment d'un orchestrateur de droits et de services pour les projets et il n'y a plus vraiment de services hébergés en propre (on n'a pas redéveloppé un bugtracker, un gestionnaire de tâches, un browser de sources...).
Typiquement, ça crée des repos CVS, SVN, Git, des Trac, des espaces web où poser des fichiers, des sites Alfresco Share, le tout en quasi temps réel via une file d'attente (plus de symptômes cron qui est passé il y a 5 minutes et qui repassera dans une heure).
Les droits sont gérés via Spring Security, CAS et des modules Perl Apache qui font appel à des services REST qui vérifient les droits sur les projets pour les trucs type ViewVC ou Trac.
On a pu aussi prendre en compte toutes les règles métier de la boîte (ex : tous les développeurs de la boîte ont accès à tous les projets non confidentiels en lecture). Et si on souhaite ajouter un type de service, il suffit d'implémenter la petite couche qui va bien pour le créer, ce qui se fait en général assez rapidement, maintenant qu'on a pas mal d'exemples différents d'intégration.
Après, ça ne convient pas à tout le monde loin de là de ne pas avoir tout intégré dans une même application mais, pour l'instant, je trouve ça beaucoup mieux ainsi que ce qu'on avait avant, compte tenu de notre mode de fonctionnement en interne.
[^] # Re: GForge → FusionForge
Posté par Guillaume Smet (site web personnel) . En réponse au message Offre d'emploi pour faire évoluer les forges (gforge, ...). Évalué à 2.
GForge AS ressemble à ça : http://gforge.org/gf/ et le logo est spécifique (voir en bas de page).
[^] # Re: Donc Oracle rachète MySQL?
Posté par Guillaume Smet (site web personnel) . En réponse au journal Oracle rachète Sun. Évalué à 4.
Il y a deux "noms" de PostgreSQL qui ont fait un tour chez Sun et on ne peut pas vraiment les appeler "le développeur principal" : le premier (Josh Berkus) fait principalement de l'advocacy et le deuxième (Peter Eisentraut) est loin d'être le plus actif de nos jours.
Accessoirement, ils en sont tous les deux partis, Josh peu après le rachat de MySQL et Peter il y a plusieurs semaines.
Pour trouver "les développeurs principaux", il faut plutôt regarder du côté de Red Hat (Tom Lane), du côté d'EntrepriseDB (plein), Command Prompt aussi et de tous les autres qui bossent sans casquette.
Il y a quelques personnes chez Sun qui font du PostgreSQL (entre autres choses) mais c'est plutôt du portage Solaris, de l'ajout de sondes DTrace et des benchs sur du matos Sun avec plein de threads. Bref, rien de critique.
Faudrait voir à se renseigner un peu avant de sortir des trucs comme ça...
# Tendance intéressante mais...
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche La 4ème édition de l'observatoire du libre vient de sortir !. Évalué à 1.
Autant je trouve les tendances intéressantes, autant les chiffres bruts sont à prendre avec beaucoup de pincettes comme pour toute étude.
En effet, ils ne tiennent compte que des formations Anaska et ib. Si Anaska est très visible pour certains composants, ce n'est pas le cas pour d'autres. D'où le fait que les tendances sont tout de même intéressantes mais que comparer la répartition pour des composants phares Anaska et pour des choses moins visibles n'a pas vraiment de sens.
Pour prendre un exemple que je connais bien et où une répartition est donnée dans le document, Anaska est très très visible pour MySQL, beaucoup moins pour PostgreSQL où des acteurs plus spécialisés sont beaucoup plus présents (je pense à Dalibo notamment).
Du coup, la tendance est intéressante mais comparer la répartition entre les BD à partir de ces indicateurs est une très mauvaise idée (les chiffres de répartition sont donnés dans le document et une phrase dans les tendances générales y fait référence).
En dehors de ça, c'est très intéressant d'utiliser la formation comme point de vue pour avoir des grosses tendances. Merci pour ce document.
--
Guillaume