Reprise du message précédent :
Le contenu de ce message a été effacé par son auteur

Aujourd'hui je me trompe de topic, d'interlocuteur, de sujet... me reste plus qu'à poster un post du forum dans mes mails et vice versa.

bon bha finalement, déception....

ça sera ni Flex, ni même Java ma première mission ici...

Scrum et PHP... c'est marrant, ça me fait bizarre de voir les deux dans la même phrase...

m'enfin en même temps, j'ai jamais pratiqué ni l'un ni l'autre.
Et Scrum, je pense pas que c'est plutôt une bonne nouvelle... j'ai changé de taf pour ça finalement.

c'est du scrum avec Excel ? comme j'en ai vu dans certaines boites ?

ça c'est la surprise

edit: en même temps, le tableur semble faire partie des outils possibles.

 
Hum, je regarderais peut être ce soir, car j'ai refais du stripes hier soir & j'ai pas trop trouvé d'où peut venir ton problème
 

@Override
 
    public ActionBeanContext getContext() {
 
        return context != null ? context : new ActionBeanContext();
 
    }

C'est quoi l'intérêt du test ?  
Normalement, Stripes va setter ton contexte.
 
Question basique de Stripes mais c'est le truc qui me turlupine quand même :  
 
J'ai un service qui me fourni une liste de livres (par exemple) et je veux afficher cette liste, il faut faire comment ?  
 
une jsp qui fait un useActionBean, qui set la liste des livres & qui retourne null comme résolution ?  

 
[/code]

@DefaultHandle
   public Resolution list() {
        maList = monService.list();
        return null;   
}

 
ou un event dans un action bean qui set la liste des livres & qui forward sur une jsp ? (mais là, je vois pas trop comment récup. ma liste)

@DefaultHandle
   public Resolution list() {
        maList = monService.list();
        return new ForwardResolution("majsp" );   
}

@DefaultHandle
   public Resolution list() {
        maList = monService.list();
        return new ForwardResolution("majsp" );   
}

Je ferais comme ça perso (mais c'est surtout parce que je suis pas fan du jsp-driven, et l'actionBean-driven ça permet d'utiliser les pretty urls dans 1.5), ton actionBean est disponible dans le contexte de la JSP (je sais plus sous quel nom par contre) donc tu peux trivialement récupérer ta liste avec ça.

bah tout pareil

  C'est pour ça que j'ai pris cette version. Simplicité, efficacité j'y crois à mort

Bah c'est un peu la JSP qui me pose le problème
  Surtout que dans les exemples de Stripes, (BuzTrucApplication), il récupère une liste mais il passe directement par le manager dans la jsp   avec un jsp:useBean. Niveau doc/exemple, je trouve que c'est pas génial sur ce genre de petite chose basique.

(Sinon pour le nom du bean dans le contexte, a coup sûr ça doit être actionBean)

J'ai du mal à voir où, tu utilises ${actionBean.maList} après avoir défini un getter dessus dans ton bean et baste, après tu itères e.g. à coup de c:forEach si besoin et roule

La doc de Stripes est très moyenne
Et ils sont très jsp-driven, aussi.

[/quotemsg]
Plus que probablement, mais je suis pas certain donc je m'avance pas

Le contenu de ce message a été effacé par son auteur

Non mais il va pas ne pas le faire, s'il le fait pas c'est que t'es arrivé sur ton actionBean sans passer par stripes, donc t'as des problèmes ailleurs.

Le contenu de ce message a été effacé par son auteur

ouais, la théorie est belle, mais quand la culture managériale c'est de faire les release maps et de budgets à 6 mois et de surveiller des feuilles de temps, ben ton changement culturel, il passe par des détails comme virer certains outils.
Ils sont pas mauvais en soi, mais il permettent tellement facilement de retourner en arrière que je pense qu'il faut pas les laisser trop en vue.
 
Pareil, je pense que smalltalk est un bon moyen d'enseigner l'objet, parce que tous ceux qui ont bidouiller du C sont perdus, et sont obligé d'écouter ce qu'on leur dit pour démarrer, ils ont pas la tentation des méthodes de 3000 lignes avec 300 ifs dedans (ce qu'ils faisaient en C) comme ils l'ont en java.
 
Donc en théorie oui, excel peut être utilisé avec scrum, les armes ça tue pas etc. mais la réalité c'est qu'il y a un lien psychologique entre les outils et le comportement.
 
C'est pour ça que j'aime bien les fiches cartonnée, ça a un petit côté old-school ce qui a un impact psychologique un peu plus fort, je pense que ça aide à changer de cap.

http://www.stripesframework.org/di [...] ycles+Etc.

C'est sûr maintenant    

fiches cartonnées ?

pour suivre tes backlogs je vois pas. Tu raies les points effectués ?

mais ton point est assez juste. On va être parmi les premiers projets de la boite à partir en Scrum. Donc autant couper les anciennes pratiques. Même si pour le coups, elles ont un poids assez faible. Je suis dans la boite depuis 8 jours, un autre membre de l'équipe était en AT depuis son embauche en juillet.

Le truc qui me choque plus, c'est que les liens entre l'équipe et le Scrum Master ont l'air assez forts d'après l'article Wikipedia. Ils insistent pas mal sur la proximité physique. Là, le Scrum Master sera ailleurs (je sais plus trop où, mais genre loin).

L'article appuie aussi sur la qualité de l'environnement, et là, je regarde le CRT 17" qu'on m'a collé en espérant qu'il ira pourrir ailleurs.

 
tellement vrai là où je suis en ce moment ...    

 
ben tu tombes exactement sur les problèmes de différence de culture et sur pourquoi ce truc c'est pas intégrer un nouvel algo, mais aussi toute une manière de penser.  
 
Nous pour XP on a recruter un leader très fort qui bossait en XP avant. Comme ça il faisait gourou de la secte (je pense que ça fait toujours secte ce genre de truc, t'es quand même en train de demander aux gens de penser différemment, même si t'as la science avec toi) il gardait les valeurs et se battait pied à pied.
 
Les fiches, c'est les taches de développement, ça correspond à une petite histoire que le product owner a écrite.
 
Concernant le burn-chart (ce qui a été réalisé, et qui donne la vitesse d'avancement et sur laquelle on projette la date de fin de projet) nous il était collé sur un mur (en fait derrière la porte, parce qu'il ne regarde pas les visiteurs) sur une feuille de plastique Véléda quadrillée.
Accrocher des trucs aux mur fait aussi partie de la culture agile, ça donne en général plus de poids aux infos (si elles sont concrètes, pas les slogans à la con) que simplement un tableau de bord numérique.

brissou > j'ai pas pris en photo notre burn chart, mais j'ai 2 truc :
 
le tableau des fiches avec le workflow :

 
le panneau de l'état des tests :

ce qu'on trouve sur google :
http://farm4.static.flickr.com/309 [...] 17.jpg?v=0
http://www.fromdelhi.com/wp-conten [...] rd_web.jpg

j'aime bien le panneau des tests, je me permettrai même un

lol !

excellent !

un autre truc qui m'inquiète.
 
On va faire une première itération de 6 semaines. Ensuite, le ScrumMaster va changer et devenir local, et toute ou partie de l'équipe sera modifiée.
et hop! seconde itération...
 
ça semble un peu chaud, non ?

le démarrage du processus c'est toujours la merde, il faut transitionner, on sait pas encore comment ça va marcher etc. Donc je suis pas trop étonné que ce soit un peu la chaud. Il faut tout faire en même temps : les hommes, le code, les outils, l'environnement de travail.
 
Par exemple, 6 semaines c'est pas agile mais on démarre pas du jour au lendemain donc c'est normal que ce soit tordu.

en fait ce qui me semble plus tordu, c'est plutôt de faire le premier cycle avec une équipe et de la changer tout de suite pour le deuxième, avec en plus un nouveau Scrum Master, qui sera cette fois débutant...
 
vu que le premier cycle sera plutôt une prise de marques, switcher tout de suite semble un peut rapide. On aura plein de débutants, plein de gens qui ont vu rapidement ce qu'est Scrum, et personne qui connait réellement.
 
En tout cas j'ai peur de ça.

Honnêtement c'est très intéressant, cette discussion, mais c'est HS, quoi.

ouais, mais comme ma marotte et que c'est moi qui ait créé le topic et ben c'est acceptable comme off-topic.
 
alors qu'une question de débutant sur java ça m'aurait fait chier par exemple, donc c'est pas acceptable.

perso je trouve ça intéressant...c'est périphérique au dev, mais c'est sympa d'avoir des retours d'XP sur ces méthodes qui dépassent les trucs totozifiants de 01.net genre "tain les gars, dans 10 ans le wifi ça va cartonner" (ah non merde ça c'est Gartner, j'ai encore confondu)

Ben oui, moi aussi je trouve ça intéressant, mais bon, y a "tech" et "Java" dans le titre du topic..

bon bha topic à part alors.

super : http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

C'est qui Gilles ?

ha bha merde alors :$

disons que c'est pas que Agile, c'est méthodo, au sens large

'lut,

une ch'tite question Log4J: j'ai une classe Main qui génère un FooThread à chaque demande user...

je tente d'avoir un log général qui reprend les logs de Main et de tous les FooThread (dans all.log; ça c'est OK) mais aussi un log par FooThread (un fichier à part entière: thread-1.log, thread-2.log,...)

avant que je ne creuse dans les Appenders et autres, est-ce que c'est faisable par défaut ? car tous les FooThread se retrouve dans le même fichier...

j'ai tapé un ${fthread} dans le nom du fichier mais le PropertyConfigurator n'aime pas trop

Je ne suis pas sur que cela soit possible avec les appenders de base, par contre tu peux écrite le tien pour faire ça.
Sinon tu peut utiliser le même fichier pour tout les threads et préfixer chaque ligne par le nom du thread.

Je dois copier un grand nombre de fichiers de la façon la plus efficace possible depuis un programme Java.
On me fait signe dans l'oreillette que java.nio est tout indiqué pour implémenter la copie parce qu'il utilise les fonctions natives de l'OS. Par contre, j'ai une question sur la taille du buffer : quelle taille choisir pour être optimal ?
Ça dépend de la taille des fichiers ? De la mémoire disponible ? Des performances du support source et du support destination ? Merci d'avance

tu mappes les 2 en mémoire et tu évites les buffers ?

 
Tu fais ça comment ?

http://java.sun.com/j2se/1.4.2/doc [...] g,%20long)
 
et sur ByteBuffer, t'as un put(ByteBuffer)
 
(jamais fait moi-même)

C'est pas un peu overkill ?

ben en fait j'ai surtout l'impression que ça fait moins de code qu'une boucle sur un read/write avec le controle pour vérifier combien il a lu ou écrit etc.
 
pas que je sois flemmard, mais moi le code sans boucles ça me fait triper