Nous sommes heureux de vous annoncer la sortie de la nouvelle version de Scub Foundation, notre solution libre (licence LGPL) d’industrialisation du développement et de la maintenance d’applications Java. Cette version standardise tous les aspects du développement jusqu'à la mise en place de l’intégration continue via Jenkins et de la gestion de la qualité via Sonar.
En plus des nombreuses améliorations sur les modèles de projets, d’une mise à niveau des bibliothèques et outils, nous avons aussi un nouveau site web avec une documentation plus complète, notamment sur des nouveaux sujets comme la gestion des logs avec Graylog.
note : Scub Foundation permet de standardiser le développement des applications en sélectionnant avec vous un ensemble d’outils pré-configurés, de frameworks, de conventions, de processus, de documentations et de modèles de projets qui structurent les développeurs et leurs développements.
Aller plus loin
- Scub Foundation, Usine logicielle Java libre (556 clics)
- Scub, ingénierie Java (191 clics)
# La licence
Posté par vlamy (site web personnel) . Évalué à 4.
LGPL, je pense. Non?
[^] # Re: La licence
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Oui, désolé !
http://about.me/straumat
[^] # Re: La licence
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Corrigé, merci.
# Usine
Posté par rzx . Évalué à 6.
Le terme d'« usine » me semble adapté pour parler d'un logiciel Java !
[^] # Re: Usine
Posté par Stéphane Traumat (site web personnel) . Évalué à 5.
quand vous aurez vu sonar, jenkins et eclemma, vous verrez que ce sont de bons outils :)
http://about.me/straumat
[^] # Re: Usine
Posté par Guillaume Smet (site web personnel) . É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: Usine
Posté par Maclag . Évalué à 9.
Pour les plus jeunes d'entre nous, remettons au goût du jour ce moment de bonheur à lire:
https://linuxfr.org/users/ploum/journaux/linuxfr-en-j2ee
[^] # Re: Usine
Posté par ckyl . Évalué à 4. Dernière modification le 30 janvier 2013 à 09:49.
Au niveau des outils pour le web oui.
Au niveau du langage malheureusement non. Au niveau des outils de base malheureusement non.
Bref Java c'est cool pour assembler des briques et faire de la plomberie.
Sonar c'est vraiment le dernier truc dont tu as besoin pour "gérer la qualité". Ca fini toujours en porn-metric qui ne sert à rien. Si tu as des règles à faire respecter et qu'elles ne le sont pas ca doit bloquer ton build pas pondre des graphes.
A quoi servent des rapports sur la complexité cyclomatique, le pourcentage de commentaire ou la duplication de code ? Ton équipe est compétente et résponsable ou elle ne l'est pas. Si elle ne l'est pas installer Sonar ne résoud aucun problème. Ton projet va déjà dans le mur depuis beaucoup trop longtemp.
[^] # Re: Usine
Posté par Guillaume Smet (site web personnel) . É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 ckyl . Évalué à 4.
Ca va être extrêment grossier donc pas très intéressant et sujet à dérive.
Pour le SE basiquement le langage, entre Java 5 et Java 7, est mort. Il y a eu d'énorme loupés dans le design de lib standard et des collections qui ne sont pas corrigés par soucis de backward compatibilité et qui forcent à mélanger 100 bibliothèques qui font la même chose (bonjour commons, guava & les amis). C'est assez pauvre en ADT. L'interaction avec les systèmes hôtes est ridicule. Pour prendre l'exemple le plus grossier il a fallut attendre fin 2011 pour avoir un accès basique aux fichiers.
Note que je ne dis pas "Java c'est nul". Je dis que c'est un langage moyen qui n'évolue plus mais qui est sauvé par d'excellentes boîtes logicielle et son outillage. J'ai certainement une vision biaisée par rapport à pas mal de dev Java qui font majoritairement de la webapp ou du webservice sans "gros code métier" hormis jouer avec une DB. On en revient à l'usine logicielle.
Sur le langage il ne s'est absolument rien passé de notable entre Java 5 et Java 7. A voir si Oracle relance la machine…
Je n'en ai encore jamais vu un bon cas d'utilisation.
Les outils peuvent être pratique. Mais les balancer dans une webapp ca n'a que peu d'interet. Les gens qui sont dans le code seront beaucoup plus productif à intégrer les outils dans leur environnement de dev. Les gens qui ne sont pas dans le code c'est pas leur soucis. Si ils en arrivent à trouver des problèmes avec Sonar ca à dérapé depuis bien trop longtemps. Ce n'est pas un outil qu'il te faut c'est revoir complètement ton équipe et son organisation.
Si tu n'es pas dans le code c'est le rôle de ton tech lead de faire ce genre de chose. Tu cherches à faire quoi en regardant le Sonar ?
C'est juste le principe de l'intégration continue: détecter et fixer les problèmes au plus tôt. Si le code est mauvais (c'est bien le but de Sonar non ? ) il ne passerait pas une code review et ne serait jamais intégré à la branche de dev. Là il a déjà été intégré donc tu échoues ton build comme tu le ferais pour un test qui ne passe pas et tu corriges maintenant. Pas dans 9 mois. Si ce n'est pas si important que ca à quoi servent les mesures et les règles mises en place ?
Si tu fonctionnes par patch et par code review tu peux même le faire en avance. C'est ce que font la plupart des projets Apache par exemple. Quand tu attaches un patch au bugtracker le robot fait passer un build et compare son résultat par rapport au dernier build. Il donne un +1 ou -1 pour chaque mesure. Le code n'est pas intégré tant que c'est pas vert ou que quelqu'un décide manuellement que c'est ok quand même.
Dire que c'est "la dernière chose dont tu as besoin" est volontairement provocateur qui vient contrebalancer le "Sonar youhou c'est super". Mais je pense vraiment que si tu cherches à produire du soft de qualité c'est effectivement très très très loin sur ta liste de priorité que tu
sois dev, development manager ou project manager. Il y a tellement d'autres choses qui paient 1000x plus avant.
[^] # Re: Usine
Posté par barmic . Évalué à 3.
C'est marrant tu reprend Guillaume qui dit que le langage c'est amélioré (en fait on parle là plus de la bibliothèque standard que dans le langage en lui même) et l'argument que tu donne c'est quelque chose qui justement a évolué dans le bon sens.
Et ça c'est bien. Si tu as besoin d'un langage qui a le comportement inverse choisi python.
Par common, je présume que tu parle de common collections principalement. Elle est presque inutilisable aujourd'hui à cause de sa compatibilité Java 1.4 (pas de généricité).
Pour guava une partie n'a plus de sens avec Java 7 grâce à des évolutions de la bibliothèque standard et du langage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Usine
Posté par ckyl . Évalué à 3.
C'est volontaire par ce que c'est l'argument le plus grossier pour ne pas rentrer dans un discours pointilleux. On peut lister des dizaines d'exemples mais je trouve que c'est sans fin et ca n'a que peut d'intêret.
Java à un énorme problème de ce côté là. Le langage et la lib standard se retrouvent paralysées. Y'a un moment ou il faut faire quelque chose (et on peut le faire sans rien, ou trop, casser) mais le JDK à du mal.
Absolument pas. Si je dis commons c'est commons. Pas un sous projet précis de commons.
Voila. Le fait que le JDK ait besoin d'être patché dans tout les sens pour le rendre productif et éviter de réinventer la roue implique une fragmentation de malade. Dès que tu ne bosses sur des projets sérieux tu te retrouves avec une base de code qui mélange 3 libs faisant presque la même chose mais qui ne se recouvrent pas entièrement donc tu dois garder les 3.
En fait le problème est juste délégué d'un niveau on se retrouve avec un sale JAR hell et des dépendances délirantes.
[^] # Re: Usine
Posté par barmic . Évalué à 2.
Ce que je ne comprends pas, c'est que tu parle de problème de bibliothèque standard (je ne dis pas qu'elle n'a pas de problème) et qu'il est nécessaire d'utiliser des bibliothèques autres pour faire certaines choses. Hors la plupart des langages compilés sans JIT ont une bibliothèque standard bien plus petite (je pense en particulier à C et C++, mais c'est applicable à d'autres). Je suis d'accord qu'une partie des bibliothèques actuelles sont trop grosses, mais le problèmes c'est surtout qu'elles sont trop grosses et cherchent à faire un peu trop de choses.
Sans trop casser ce n'est pas acceptable pour la politique de Java. Les nouvelles versions du langage ont déjà bien du mal à être utilisée donc casser la compatibilité même faiblement ce serait se tirer une balle dans le pied. Il n'y a qu'à voir les sécurités Java2 qui ne sont que très rarement utilisées. Sans rien casser je demande à voir. Par exemple tu reproche l'API d'accès au fichier. En Java 5 est arrivé Scanner qui simplifié la lecture en en Java 7 nio2 fini le travail, tu peut toujours continuer à utiliser les anciennes API (d'ailleurs nio2 ne remplace pas tout nio ni tout io). Le projet fonctionne par ajout de fonctionnalités dans l'API, mais c'est apparemment assez difficile de se mettre d'accord (par exemple les lambdas semblent être un vrai combat dans le JCP).
AMHA c'est surtout du à une très forte réutilisation, là où les autres écosystème en font beaucoup moins. C'est lié à la taille des bibliothèques qui cherchent toute à te préparer une expresso en réutilisant chacune une café différent (ou des fois le même café mais pas de la même année).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Usine
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Carrément d'accord !!! Combien de choses sont en deprecated de puis plus de dix ans dans la "lib standard" du JDK ?
Il y a un moment où il faut aussi dire que l'appli développée il y a dix ans a peut-être besoin d'être nettoyée si elle veut sauter d'un seul coup trois versions de JDK !
Rien qu'en virant l'ensemble des classes ou méthodes qui sont deprecated depuis 2 versions majeures, on gagnerait en lisibilité.
[^] # Re: Usine
Posté par barmic . Évalué à 2.
C'est pas l'optique de Java, C, C++, Fortran, ADA et un tas d'autres langages qui veulent pouvoir être utilisé dans des endroits critiques.
Personnellement je ne vois pas en quoi c'est un problème une API qui ne plaît pas il suffit de ne pas l'utiliser.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Usine
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Le problème, ce n'est pas qu'elle ne me plaît pas mais simplement, comme le dit Cykl, elle est paralysée.
Personnellement, je pense que quelque chose qui est deprecated devrait sortir de l'API au bout de deux ou trois révisions du langage, quitte à y revenir sous une autre forme plus tard.
[^] # Re: Usine
Posté par barmic . Évalué à 2.
En quoi elle est paralysée ? L'accès au fichier a subit 2 grosses mises à jour (nio et nio2), l'IHM en eu une grosse (swing pour remplacer awt). Oui on pourrait peut être espérer plus de nouveautés (swing commence à moisir par exemple), mais ça n'a rien à voir avec la compatibilité.
La dénomination commerciale/publique du langage depuis Java 5 est justement « Java 5 », « Java 6 » et « Java 7 », mais l'API est en version 1.5, 1.6 et 1.7. Ils se permettront de casser la compatibilité pour la version 2.x (pas prévue à ce que je sache).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Usine
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Effectivement, cela n'a rien à voir avec la compatibilité puisque AWT, io et Date, dont plus de la moitié de l'API est deprecated, se trouvent toujours dans l'API…
Ayant commencé avec du Java 1.2-beta4 en 1998, je sais, merci !! Et donc, ça fait donc 15 ans que la compatibilité n'a pas été cassée.
Finalement, peut-être que pour 1.99 aka Java99, on aura virer les trucs qui ne servent plus à rien :)
[^] # Re: Usine
Posté par barmic . Évalué à 2.
C'est quoi ta définition de paralysée ? Parce que si c'est le fait qu'elle ne peux plus évoluée, j'ai tenté de donner des exemples d'évolutions.
Je suis impressionné qu'on puisse voir ça comme un problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Usine
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Si on cassait jamais la compatibilité, on aurait encore que 640Ko de RAM disponible et on ferait encore des pirouettes pour les dépasser.
Maintenant, dans Java, c'est un problème parce que cela pousse certains à continuer à utiliser des trucs deprecated donc non maintenus et potentiellement troués comme pas possible. Ca alourdit la bibliothèque et sa doc.
Si tu veux continuer à faire du JDK 1.2, utilises un JDK 1.2 mais ne demandes pas au 1.7 de traîner les boulets de ses ancêtres.
D'ailleurs, plus haut tu parlais d'Ada, certaines constructions sont interdites dans la dernière version alors qu'elles étaient autorisées avant. Ce n'est pas sale pour autant !!
C'est même plutôt sain que de retirer ce qui peut poser problème ou qui n'a plus lieu d'être.
[^] # Re: Usine
Posté par ckyl . Évalué à 4.
Y'a deux pauvres sous systèmes qui évolue à chaque release tout les 2/3 ans. On rajoute les features qu'il manque mais absolument rien au niveau expressivité et productivité générale. On va quand même pas se tripoter sur les NIO2 qui ne font que combler une vaste blague !
Voilà tu as tout compris. On peut bouger pour devenir meilleur. Java l'a oublié pendant 7 ans. Il comble ses trous fonctionnels mais ne fait plus rien d'autre. Les API merdiques restes merdiques. Et on ne pousse rien d'un peu novateur pour chercher à rendre la plateforme meilleure, on laisse ca à groovy, scala ou clojure et aux libs externes et c'est bien dommage… Ca donne des débilités comme le système de logging, junit, devoir utiliser guava pour avoir des collections correctes, un pauvre multimap ou de bêtes outils pour bosser sur des les iterateurs.
Par contre le problème de garder toutes les APIs c'est que tu fais rapidement exploser la complexité et la taille du bouzin. Par exemple l'algorithme derrière le hashcode de String a été documenté du coup on peut plus le changer. Maintenant on en arrive à des patchs comme ca pour limiter le nombre de collision dans les collections. Et évidement comme toujours on balance une property système pour activer/désactiver la nouvelle fonctionnalité ce qui donne à terme une complexité folle pour les utilisateurs.
Si Java fait de gros effort pour la compatibilité j'ai l'impression que tu la surestimes beaucoup quand même. Avec une grosse base de code tu tombes souvent sur des changements dans les JDK (même en mineur):
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
http://www.oracle.com/technetwork/java/javase/compatibility-137541.html
http://www.oracle.com/technetwork/java/javase/compatibility-137462.html
Sachant que tu n'as pas tout là.
Citation needed.
[^] # Re: Usine
Posté par barmic . Évalué à 3.
Et en quoi c'est liée à la compatibilité ?
C'est le plus connu qui a évolué, mais il y a aussi le framework de parallélisation (qui va encore évolué avec Java8).
Je pense surtout que Java a le cul entre 2 chaises. Il est entre les gros et vieux langages comme C, C++, Fortran, ADA et autre et les langages dynamiques comme python ou ruby.
Il est batery included comme ces derniers mais a un rythme de révisions entre les deux. Il s'organise comme un standard avec un comité etc.
Les discussions sont houleuses au JCP et le rachat de Sun par Oracle ainsi que l'image et les pratiques d'Oracle n'ont rien arrangées. Mais de ce que j'en sais il y a des discussions pour avoir des lambda (tout le monde les veux mais chacun à sa façon) et surtout il y a une volonté de découper l'API pour la rendre plus modulaire (voir le JSR 337).
Je suis d'accord pour dire que le JCP a du mal à sortir des choses mais c'est parce qu'il est difficile de sortir un consensus pas un manque de volonté (du moins je pense pas).
Je la surestime probablement, mais c'est tout de même pas mal.
Ça ne ressort pas mais c'est un avis personnel.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Usine
Posté par ckyl . Évalué à 3.
C'est exactement ce que je dis. On bouche en s'en battant de rendre les trucs performants ou utilisables.
Le fork/join de la JSR166y est très bien. Une nouveauté. Cool ! (enfin c'est dispo comme lib externe depuis 5 ans)
En attendant tu peux toujours pas instancier un foutu Future sans utiliser l'
AbstractFuturede Guava (FutureTaskne marche qu'avec unRunnable). L'API des Executor est tellement mal gaulé que 90% des gens qui essayent de créer un thread pool avec un nombre min et max de thread se plantent (la compatibilité Java 5/6/7 en exercice). Faire un thread group nommé demande encore de dupliquer 30 lignes de code ou d'utiliser une lib externe. On peut continuer comme ca longtemps sur ce tout petit module fonctionnel mais le constat est généralisé sur presque tout le JDK.On rajoute des briques très bien. Mais les bases qui servent à construire ces briques sont en train de pourrir. Pour avec un semblant de DRY t'es obligé d'utilisé 1000 libs. Mais laisser ca a des third party c'est prendre le risque de retomber sur le délire du logging ou d'avoir une compatibilité beaucoup plus difficile à gérer que si le JDK cassait quelque chose ou se bougeait simplement le cul. Rare sont les projets reposant sur un OSGI ou assimilé et t'es bien malin quand ton runtime arrive déjà avec ses 30 libs dans une version donnée… Même en OSGI t'as intêret à être à grin très fin pour jamais tomber sur ce genre de problème.
Non par ce que le bateau s'est enlisé depuis longtemps et que le remettre à flot est difficile. Si on pousse pas ca avance pas.
La JSR 337 c'est juste la JSR de Java8 qui listent les JSR qui seront incluses. Le DRAFT-1 n'indique pour le moment absolument rien à propos de Jigsaw. Toute les chances pour que ce soit encore repoussé à Java 9.
Note que Jigsaw au niveau du JDK ne rend absolument pas l'API plus modulaire. Ils veulent juste pouvoir charger les différents sous modules du JDK par bout fonctionnel (réduire le coût du download + boot). Ca demande un énorme boulot de nettoyage puisqu'il faut péter toutes les dépendances qui traînent. Mais d'un point de vue utilisateur ca n'a absolument aucun impact.
Il me semble personnellement très foireux.
Je n'ai absolument jamais entendu ce genre d'idée. Autrement on inventerait pas des trucs comme tweaker la résolution de méthode virtuel pour ajouter les implémentation par défaut dans les interfaces pour le support des lambdas. On s'amuserait pas prévoir des gesticulations immondes pour réparer les conneries qui ont été fait avec l'autoboxing et son interaction avec les collections. Et on peut continuer.
[^] # Re: Usine
Posté par Guillaume Smet (site web personnel) . É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 ckyl . Évalué à 3.
Je pense aussi.
Tu vois les petites avancés des deux dernières releases de Java comme des plus. Ce qui est vrai. J'y vois un constat d'échec de n'avoir eu droit qu'a du sucre et ne pas s'être attaqué aux vrais problème en 7 ans. Je ne suis pas certain que l'argument compilé tienne entièrement. Car il y a déjà énormement à faire du côté JDK comme le trillion de libs le prouve.
Pour l'utilité de Sonar tu as raison encore. Évidement je caricature avec mes gros sabots car la phrase "Gérer la qualité avec Sonar" me fait rire. Ce n'est pas l'outil qui gère la qualité. C'est la démarche, l'organisation et la dynamique de l'équipe de dev. Si un dashboard sur l'intraweb aide très bien. Le travers de ce genre d'outil c'est que c'est généralement mis en place de facon transverse et la tout par en vrille. On sort du monde de la démarche pour entrer dans celui de l'outil.
Et on semble aussi d'accord sur le "1000x plus rentable". Tu le dis toi même je pense. Sonar c'est la couche de polish pour une équipe qui ronronne déjà et qui s'est déjà posé les bonnes questions et qui à déjà eu la démarche de chercher à livrer bien et toujours mieux. C'est désolant mais très peu de gens en sont là ou n'ont même pas réussi à comprendre qu'ils n'en étaient pas là. Dans ce genre de cas le truc genre Sonar font rapidement plus de mal que de bien.
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é.
[^] # Re: Usine
Posté par Guillaume Smet (site web personnel) . É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 Stéphane Traumat (site web personnel) . Évalué à 1.
In intègre Hibernate search dans le socle ainsi que elastic search dans pas longtemps. Plutôt que Wicket, on a préféré GWT.
Merci, je vais corriger pour postgresql
http://about.me/straumat
[^] # Re: Usine
Posté par Guillaume Smet (site web personnel) . É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 Stéphane Traumat (site web personnel) . Évalué à 1.
C'est gentil ça :)
http://about.me/straumat
[^] # Re: Usine
Posté par vlamy (site web personnel) . Évalué à 2.
C'est petit et non argumenté :)
Java n'est peut être pas le bon langage pour faire un OS (encore que certains pensent que si), mais quand on voit la charge que supportent les serveurs d'applications JEE type JOnAs ou Jboss : il n'y a vraiment pas de quoi se plaindre. Java a deux points forts pour moi : l'interopérabilité et l'outillage. Il est vrai que des (méga) usines à gaz sont développées avec java (Eclipse?), et encore on ne parle pas de prototypes de projets collaboratifs dans lesquels chacun amène sa bibliothèque, voir son service : on mélange tout, on touille et ça marche (lentement, mais ça marche).
Bref, c'est l'architecture du projet qui fait que le logiciel est une usine à gaz, pas le langage. Et :oui on peut faire de l'OSGI embarqué qui pédale !
# Gestion des sources avec SVN
Posté par 16aR . Évalué à 2.
Bonjour,
Est il possible de changer cette gestion des sources pour utiliser Git à la place ?
Git m'a apporté un tel confort au quotidien que repasser sur du svn me ferait pleurer :'(
# Java ou pas?
Posté par ariasuni . Évalué à 1.
Conseillerez-vous Java ou pas (pour n'importe quel projet)? J'ai vu beaucoup d'avis négatif et d'autres plus positifs…
J'aime pas trop le Java par rapport au C++ (System.out.print vs cout, Scanner vs cin, tableaux, Vector vs ArrayList (je ne sais pas si c'est réellement comparable), la plupart à cause des
newincessants).Et j'ai déjà eu des conneries tellement énormes… Du genre la vigule comme séparateur décimal en console (le seul qui fasse ça?) mais le point pour la fonction Double.parseDouble() (je crois que c'est ça le nom). Du coup l'affection directe à un flottant fonctionnait avec la virgule, mais dans une chaîne de caractères il fallait que ça soit un point pour que la conversion en flottant fonctionne.
Écrit en Bépo selon l’orthographe de 1990
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.