Reprise du message précédent :
Mon openid est down

heureusement, ils sont en train de faire une connection DOORS->ClearQuest, donc chaque tache devra être liée à une tache définie dans les requirements

DOORS ?? Kezako ? Une gestion de requirements ? Si c'est le cas, ça risque d'être encore plus lourd pour les développeurs, et ce, uniquement pour faire plaisir à des managers qui veulent pouvoir croire qu'ils maitrisent mieux le projet, parce que le refactoring, l'architecture ne fait pas partie des requirements.

Clearcase ça compte comme un

Chez GatsuCorp ou chez Kadreg?

Non, c'est lourd et chiant, mais c'est quand même largement mieux que de ne rien avoir, crois-moi. Par contre, Clearcase + Clearquest est un ralentisseur de productivité d'une efficacité absolument redoutable. Personnellement, je crois que je préfère nettement un bête Subversion à CC (sauf p-ê pour le merge), et je ne parle même pas de Mercurial.
Subversion + Jira = agile >>> Clearcase + Clearquest = pieds coulés dans le béton

Gatsu.

Ouais bof, ya des outils mais ils sont insuffisament utilisés imos:

• Peu de gens utilisent les liens entre JIRA et Subversion, et les commentaires de commit subversion... on va dire qu'il y a des coups de batte qui se perdent
• Pas assez de jiras, sur les projets sur lesquels je suis en tout cas, je suis obligé de demander à ce que les trucs soient jiraifiés
• Aucune culture de tests automatisés (je parle même pas de TDD là), et comme quasiment tous les projets sont maintenant springifiés (une bonne chose par ailleurs) ben le fait que ça compile ne veut plus dire grand chose, il est assez fréquent que les trucs pètent au démarrage des tomcats (quand Spring fait ses instanciations & injections) au lieu de pêter à la compilation Ca diminue grandement la valeur d'hudson et du continuous testing.
• La gestion des déploiements est pourrave Soit c'est fait manuellement soit c'est fait via des scripts shell customs avec des listes d'options longues comme le bras
• Sans compter que s'il n'y a pas de culture du test, il y a clairement une culture du "bandaid", donc il y a des gens qui fixent des bugs directement sur les instances de dev ou (pire) de valid, en les committant ou pas, etc... et naturellement de temps en temps il y a plusieurs personnes qui le font en même temps et on se retrouve avec des gens qui committent des fichiers en conflit svn

La partie la plus insupportable reste quand même l'absence de tests fonctionnels, alors qu'au final les consultants gagneraient un temps fou à avoir des trucs genre tests selenium pour les régréssions

 
you got point
 
C'est ça. Un gestionnaire de requirement, mais aussi capable de gérer les traceabilité des exigences vers les éléments les clarifiant (spec word) ou les implémentant (code source ou modèle).

(tu parles d'une discussion pour un dimanche matin

http://graphite.wikidot.com/start ça a l'air sympa comme truc

*penser à rajouter DOORS a mon CV*

et RCP aussi

Ah donc vous codez en Java ? Je croyais que vous faisiez essentiellement du PHP.  
En ce qui concerne les pb que tu cites, ça ressemble pas mal à ce qui se fait chez nous, finalement. Usage non systématique ou mauvais (on ferme un bug sans documenter la correction) de la base de bugs, pas de tests automatisés. Ah, et pas de Spring chez nous. En fait, l'injection de dépendance, personne ne connait. Il n'y a guère que moi qui en ait entendu parler, et c'est uniquement en blogifiant à mort. L'"architecte", et les guillemets ne sont pas de trop, ne sait clairement pas coder en Java. J'ai découvert ça il y a qq semaines quand j'ai filé un coup de main pour la correction de bugs en dernière minute. Donc tout le code est à  base de static, pas d'objets, pas d'interfaces, c'est du C simplifié.
Pour le déploiement, on a des RPM et des fichiers de config à la douzaine. Pour le "band aid", même chose ici.  
 
Au passage, pour la config, je regrette que la classe Properties de Sun ne sache pas interpréter les variables d'environnement, parce qu'on se retrouve à recopier des configs dans divers fichiers properties. Je pense que la prochaine fois, j'étendrai cette classe pour pouvoir faire cette interprétation. C'est pas difficile, et ça devrait être nettement plus propre pour la config.

Mon dieu non

La grande majorité du pôle ingé est en java (tous les gros projets, ~80% des effectifs), il y a une paire de gars qui font du .net, et le reste fait du PHP.

Genre @gatsucorp avec Spring, ils ont créé un truc pas mal pour ça:

<!-- Bean configuration management:
        use this mechanism to isolate configuration information that depends
        on the deployment (i.e dev/integ/valid/prod)
        The selector currently configured uses the hostname, but any implementation
        is possible.
        Default properties can be specified locally via the "properties" property. They
        get overriden by the values in the selected configuration.
        This implementation builds on Spring's standard PropertyPlaceholderConfigurer, see the
        documentation for the complete feature set. -->
    <bean id="propertyConfigurer" class="com.gatsucorp.framework.config.SelectablePropertyPlaceholderConfigurer">
        <property name="configLocations">
            <map>
                <entry key="gatsudev1" value="/WEB-INF/config/gatsudev1.properties" />
                <entry key="gatsudev2" value="/WEB-INF/config/gatsudev2.properties" />
                <entry key="gatsudev3" value="/WEB-INF/config/gatsudev3.properties" />
                <entry key="gatsudev4" value="/WEB-INF/config/gatsudev4.properties" />
                <entry key="gatsudev5" value="/WEB-INF/config/gatsudev5.properties" />
                <entry key="gatsudev6" value="/WEB-INF/config/gatsudev6.properties" />
                <entry key="gatsudev7" value="/WEB-INF/config/gatsudev7.properties" />
                <entry key="gatsudev8" value="/WEB-INF/config/gatsudev8.properties" />
                <entry key="gatsudev9" value="/WEB-INF/config/gatsudev9.properties" />
                <entry key="dev" value="/WEB-INF/config/dev.properties" />
                <entry key="integ" value="/WEB-INF/config/integ.properties" />
                <entry key="prod1" value="/WEB-INF/config/prod1.properties" />
                <entry key="prod2" value="/WEB-INF/config/prod2.properties" />
            </map>
        </property>
        <property name="configurationSelector">
            <bean class="com.gatsucorp.framework.config.CascadingConfigurationSelector">
                <property name="selectors">
                    <list>
                        <!-- bean class="com.gatsucorp.framework.config.SystemPropertyConfigurationSelector">
                            <property name="propertyName" value="config.name"/>
                            </bean-->
                        <bean class="com.gatsucorp.framework.config.HostnameConfigurationSelector" />
                        <!-- <bean class="com.gatsucorp.framework.config.JndiConfigurationSelector">
                            <property name="jndiName" value="java:comp/env/configName"/>
                            </bean> -->
                    </list>
                </property>
            </bean>
        </property>
        <property name="properties">
            <bean class="org.springframework.beans.factory.config.PropertiesFactoryBean">
                <property name="locations">
                    <list>
                        <value>/WEB-INF/config/common.properties</value>
                    </list>
                </property>
            </bean>
        </property>
    </bean>

Le principe, c'est que ça importe les contenus des fichiers properties dans le application-config spring (on peut y accéder sous la forme ${property.key}, et injecter les valeurs là où on en a besoin, vu que derrière tout est springifié, via xdoclet pour les vieux trucs sous Struts et directement pour les projets plus récents qui sont sous Stripes).

La property properties importe le fichier de conf' commun, la property configurationSelector importe les stratégies de sélection pour la conf secondaire, elles sont appliquées dans l'ordre (ici seul HostnameConfigurationSelector est utilisé, donc ça importe un fichier de conf en fonction du hostname) et enfin la property configLocations va mapper les clés sorties par la stratégie de sélection (les hostnames des machines, dans le cas présent) sur des fichiers properties avec lesquels overrider le contenu de common.

Ca marche pas trop mal globalement (même si ça pourrait être mieux, surtout au niveau du setup)

 
omg deja que je creve de rire quand j entends machinne pester contre java j imagine le carnage s il devait phpeter toute la journee
 

Non mais ça pourrait ptet être acceptable le PHP chez ratibus

Par contre chez gatsucorp, comment dire, l'équipe PHP ils ont commencé à introduire Subversion sur tous les projets il y a 6 mois si j'ai bien compris, genre après la GatsuTeam (qui ne fait que du front office et n'a pas un statut interne d'ingénierie)

 
ca t empecherait pas de t indigner a longueur de journee
 

 
bah s ils recrutent leurs ingés php sur hfr spe trop etonnant

De mon exemple les "up" et autres conneries du genre . Et ca, ç'est le commit pour la journée .

Je note    

when reality conflicts with dreams:
 
Ce que je veux:
un job en erlang voire haskell
 
Ce que j ai eu:
un job en java, je cherche en php
 
-VDM

(chaque ligne est un message de log complet, naturellement)
(et encore, j'ai pas inclus les 15 revs de suite où un collègue disserte sur l'intérêt d'aller élever des chèvres plutôt que de coder vu comme cette dernière activité lui réussit)

Et les chefs de projet / responsable technique, ils laissent faire ça ??

je pense qu les meilleurs messages viennent d eux

Comme je l'ai dit à 'much, les outils il y en a, c'est leur utilisation qui reste discutable.

Accessoirement, le concept de "chef de projet" ne fait pas exactement partie des méthodes gatsucorp

Oui, c'est un peu une encyclopédie des mauvaises pratiques, ce projet.  

Pas mal foutu, en effet.  
Et justement, je comptais proposer Hibernate + Spring + Stripes pour le prochain projet. Des retours d'XP ? (Portos s'oriente officiellement vers Tapestry 5 pour remplacer le truc MVC modèle 1 maison, mais je le sens moyennement, comme tout ce qui vient de l'équipe R&D après quelques années d'usage. Surtout à cause de la complexité qui semble être reconnue sur ce framework. Du coup, ça obligerait à envoyer les devs en formation une semaine chacun, alors qu'avec Stripes, je pense qu'un gars qui a déjà fait du Struts peut être rapidement opérationnel.)

Hibernate c'est globalement sympa, mais pas spécialement sexy (par contre je l'ai surtout utilisé en XDoclet, Hib3 + annotations c'est probablement plus mieux). Stripes je dirais que pour un framework web java ça a tendance à être vraiment bien (et la 1.5 a l'air d'apporter pas mal de trucs cool, même si j'ai pas du tout eu le temps ou l'occasion de regarder et que j'ai bossé qu'en 1.4), malgré des trucs que je supportes pas (genre le cycle binding & validation implicite, et la taglib de forms qui reste globalement un mapping 1:1 sur les éléments HTML un peu comme la taglib struts/html, je préfère largement des forms explicites et utiles pour l'affichage à la django.newforms). Je peux pas comparer à Tapestry que je connais pas.

Spring, je suis plus circonspect. D'un côté c'est clairement un progrès sur les dépendances statiques ou même les service providers, c'est ce qui est utilisé partout @gatsucorp et Stripes a une intégration native avec (et une extension pour l'intégration hibernate, aussi), de l'autre c'est plein de XML pas beau. Je te dirais de regarder les autres frameworks de DI, genre je viens de regarder la vidéo passée ici sur Guice et ça a l'air plutôt pas mal (pas de XML, annotations, moins de magie, et de 10000 pieds il m'a l'air conceptuellement plus simple, et Guice a l'air très orienté "injection dans les constructeurs", alors que spring@gatsucorp est plutôt utilisé en "injection dans les méthodes", ce qui pue la mort ).

Sur reddit, un mec avait aussi mentionné HiveMind, mais j'ai rien regardé là dessus, et le site a pas l'air d'avoir grand chose.

1. Do you use source control? svn, mais ca va changer
2. Can you make a build in one step? , même si pas utilisé vu que le logiciel est écrit en python
3. Do you make daily builds?
4. Do you have a bug database? incluse dans le logiciel
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule? inclus dans le logiciel
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy? Non relevant. Environnement linux full open-source.
10. Do you have testers?
11. Do new candidates write code during their interview? non, pas facile de trouver des dev python
12. Do you do hallway usability testing? via les partenaires

7/11

Ben si, c'est pas parce que t'es sous Linux et globalement en OSS qu'il n'y a pas des outils payants mieux que les gratuits

certe.

c'est tout récent, un mois et demi

 
en teletravail c est jouab'
 

Quelle boite/quel projet/etc...?

(pour l'embauche, pas possible de trouver des gens qui connaissent pas python mais seraient intéressés par se former/être formés à la place?)
(ça empêche pas de leur faire écrire du code dans un autre langage )

non

tiny

c'est comme ca qu'on fait...
mais tu connais python toi

Oui mais chuis chez gatsucorp

C'est une application desktop ? (je demande car on en avait fait une & le chargement était juste   à cause du chargement de tous les import... & je me demande si il existe une solution à ce problème)

un petit coucou des 24 heures du mans , a 2heures de la fin
on  va finir dans les 200 premiers

oui
et j'ai pas remarqué de lenteur de chargement...

Holy fucking shit
J'pensais que ça se limitait à la Gatsuteam

\o/

   
 
http://www.lemans.org/sport/sport/ [...] index.html

Oui, avec des annotations, c'est probablement plus léger.

Effectivement, le modèle de Stripes est quelque peu ancien, mais le framework a l'air relativement productif (pour du Java) et sans (mauvaises) surprises, et ça, c'est un plus non négligeable. Par contre, le fait qu'on ne puisse pas faire de composants réutilisables est un point négatif, mais peut-être qu'avec des outils JS à la qooxdoo/Prototype, il y aurait moyen de pallier élégamment à cette limitation, les composants réutilisables étant alors en JS (?).

Oui, en tant que composant d'injection de dép, Spring sent un peu son ancienneté (bien que remis au goût du jour), et j'ai généralement un faible pour les trucs plus simples, même si moins puissants. Spring n'est pas forcément très intéressant si on ne fait pas de J2EE mais seulement de l'injection de dépendances. Spring a réellement de l'intérêt dans les applis d'entreprise où, en-dessous/à coté de la couche présentation, on a aussi besoin de scheduling, de webservices, de transactions (JTA), de JMS, de JMX, gestion de la sécurité, etc. Il offre alors tout un tas d'API qui sont censées simplifier le développement J2EE. Il permet d'intégrer toutes ces API qui normalement se trouvent dans N jars distincts et qu'il faut apprendre séparément en ue solution  pratiquement complète et intégrée (du moins c'est le but du framework, tel que je le comprends). Et c'est justement dans ce genre d'applis que l'injection de dépendance montre tout son intérêt, parce que dans une architecture SOA, 20% à 50% du code consiste à invoquer et à gérer le cycle de vie des services. Donc Spring a un intérêt non négligeable dans ce type d'applis. Maintenant, si on a besoin que d'un ou deux services proposés par J2EE, Spring peut être avantageusement remplacé par Guice ou Picocontainer.

Apparemment, Hivemind est créé et utilisé par/pour Taperty.

Je vois pas trop en quoi c'est une question d'âge du modèle (struts est plus vieux, le binding & validation est également implicite, mais les forms sont des objets explicites & indépendants -- sauf à la limite pour les dynaforms), plutôt de conception et de vision du bouzin (genre ça a peut-être changé avec Rails 2, mais dans mes souvenirs la gestion des forms en Rails 1 c'était globalement absent, tout était à gérer manuellement si je me plante pas...)

De composants réutilisables?

Heuu normalement l'invocation et la gestion des cycles de vie des services c'est le "life and blood" des frameworks DI, Guice servirait pas à grand chose s'il le gérait pas
 
Par contre je comprend bien que les APIs de facilitation prévues dans Spring soient un avantage dans nombre de cas.

tu peux expliquer ?