> Attention à ne pas confondre :
> "savoir ce que font les autres"
> et
> "tout faire comme les autres"
>
Il ne faudrait pas non plus par simple esprit de provocation ne rien
faire comme tout le monde

> Attention à ne pas confondre :
> "savoir ce que font les autres"
> et
> "tout faire comme les autres"
>
Il ne faudrait pas non plus par simple esprit de provocation ne rien
faire comme tout le monde

> Il ne faudrait pas non plus par simple esprit de provocation ne rien faire comme tout le monde

OK ; mais, comme l'esprit de contradiction se généralise, on peut dire que, maintenant, "ne rien
faire comme tout le monde", c'est "faire comme tout le monde".
Et lycée de Versailles.


@+

MCI

> Il ne faudrait pas non plus par simple esprit de provocation ne rien faire comme tout le monde

OK ; mais, comme l'esprit de contradiction se généralise, on peut dire que, maintenant, "ne rien
faire comme tout le monde", c'est "faire comme tout le monde".
Et lycée de Versailles.


@+

MCI

On 14 août, 08:56, Laurent Pointal <laurent.poin...@limsi.fr> wrote:
> Méta-MCI (MVP) a écrit :
>
> > Bonjour !
>
> >> "bonnes pratiques" ?
>
> > J'avoue que je me hérisse un peu, dès qu'on veut me dire combien de
> > glaçons je dois mettre dans mon pastis, de quelle façon il faut
> > développer, ce que je (ne) dois (pas) manger, comment discuter avec les
> > utilisateurs, etc.
>
> Mais toi tu as de l'expérience... combien de temps ça a pris ?
> J'ai eu des cours de sur ce genre de chose intéressant certaines fois,
> lourd d'autres fois (les comptages de lignes de codes... le COCOMO &
> co). Avec certaines techniques adaptées à certains cas (les grosses
> usines à gaz par exemple), d'autres pas.
> Le tout c'est de réussir à trier ce qui est utile/pratique et qui peut
> faire gagner du temps de ce qui est superflu/lourd/dépassé et qui en
> fera finalement perdre. Et d'avoir les outils ad-hoc (dans certains cas
> le coût des outils est très prohibitif).
>
> De ce que j'ai pu voir du sommaire du livre de Tarek, ça ne m'a pas trop
> choqué. Ca peut bien servie à un étudiant ou à un amateur qui veut se
> mettre à Python et qui devrais y trouver un raccourci vers les façonsde
> faires considérées généralement comme meilleurs.
>

Bonjour,

Merci pour la réponse Laurent, c'est exactement l'optique du livre.
Ce n'est pas un guide qui tente d'imposer telle ou telle méthodologie
de programmation ou d'analyse.
Mais simplement une synthèse, une introspection de mon expérience, mon
vécu dans la programmation de
petites et de grosses applications (zope, cps par exemple). Tout ce
que je me suis pris dans "les dents" en quelques sorte,
pendant 10 ans: pourquoi les tests unitaires servent vraiment,
pourquoi un outil comme subversion
est incontournable, des principes de base pour la conception (sans
prôner telle ou telle méthode),
les techniques Python qui marchent, comment écrire de la documentation
efficace sans
se noyer dedans, etc.

Je n'ai pas la prétention de dire que mon expérience est meilleure que
d'autres mais elle offre un
bon apercu de ce que peut vivre un développeur Python, et de ce qu'il
retient, comme le dit Laurent,
de toutes les techniques de programmation et d'analyse, pour son
travail de tous les jours.
A mon sens le développeur qui arrive à appliquer 100% de merise ou
d'UML sur un projet est un psychopathe
Puisqu'en général, un diagramme de classe couvre la plupart des
besoins de compréhension de l'archi.

Pour les "vieux de la vieille", et s'ils ne la pratique pas déjà
la partie la plus intéressante du livre est sans doute le Document
Driven Developement, qui présente
une approche originale de développement utilisée par exemple dans Zope
3.

Cdl

++

Tarek

> > Mais, je sais que la plupart des petits djeuns, frais moulus des écoles,
> > sont friands de ce genre de chose. Je crois que ça les rassure.
>
> Ouaips, même que certains ne veulent plus que faire de l'analyse,
> surtout pas mettre les mains dans le camboui des lignes de code...
>
> J'ai eu un collègue fou de la documentation et des notations UML & Co,
> qui là où j'aurais fait une petite doc synthétique, éventuellement avec
> un diagramme de classes pour expliquer un peu, pondait des pages et des
> pages de trucs verbeux qui n'apportaient AMA pas grand chose (par
> contre, il mettait les mains dans le camboui pour que le code
> correspondant tourne).
>
> A+
>
> Laurent.

On 14 août, 08:56, Laurent Pointal <laurent.poin...@limsi.fr> wrote:
> Méta-MCI (MVP) a écrit :
>
> > Bonjour !
>
> >> "bonnes pratiques" ?
>
> > J'avoue que je me hérisse un peu, dès qu'on veut me dire combien de
> > glaçons je dois mettre dans mon pastis, de quelle façon il faut
> > développer, ce que je (ne) dois (pas) manger, comment discuter avec les
> > utilisateurs, etc.
>
> Mais toi tu as de l'expérience... combien de temps ça a pris ?
> J'ai eu des cours de sur ce genre de chose intéressant certaines fois,
> lourd d'autres fois (les comptages de lignes de codes... le COCOMO &
> co). Avec certaines techniques adaptées à certains cas (les grosses
> usines à gaz par exemple), d'autres pas.
> Le tout c'est de réussir à trier ce qui est utile/pratique et qui peut
> faire gagner du temps de ce qui est superflu/lourd/dépassé et qui en
> fera finalement perdre. Et d'avoir les outils ad-hoc (dans certains cas
> le coût des outils est très prohibitif).
>
> De ce que j'ai pu voir du sommaire du livre de Tarek, ça ne m'a pas trop
> choqué. Ca peut bien servie à un étudiant ou à un amateur qui veut se
> mettre à Python et qui devrais y trouver un raccourci vers les façonsde
> faires considérées généralement comme meilleurs.
>

Bonjour,

Merci pour la réponse Laurent, c'est exactement l'optique du livre.
Ce n'est pas un guide qui tente d'imposer telle ou telle méthodologie
de programmation ou d'analyse.
Mais simplement une synthèse, une introspection de mon expérience, mon
vécu dans la programmation de
petites et de grosses applications (zope, cps par exemple). Tout ce
que je me suis pris dans "les dents" en quelques sorte,
pendant 10 ans: pourquoi les tests unitaires servent vraiment,
pourquoi un outil comme subversion
est incontournable, des principes de base pour la conception (sans
prôner telle ou telle méthode),
les techniques Python qui marchent, comment écrire de la documentation
efficace sans
se noyer dedans, etc.

Je n'ai pas la prétention de dire que mon expérience est meilleure que
d'autres mais elle offre un
bon apercu de ce que peut vivre un développeur Python, et de ce qu'il
retient, comme le dit Laurent,
de toutes les techniques de programmation et d'analyse, pour son
travail de tous les jours.
A mon sens le développeur qui arrive à appliquer 100% de merise ou
d'UML sur un projet est un psychopathe
Puisqu'en général, un diagramme de classe couvre la plupart des
besoins de compréhension de l'archi.

Pour les "vieux de la vieille", et s'ils ne la pratique pas déjà
la partie la plus intéressante du livre est sans doute le Document
Driven Developement, qui présente
une approche originale de développement utilisée par exemple dans Zope
3.

Cdl

++

Tarek

> > Mais, je sais que la plupart des petits djeuns, frais moulus des écoles,
> > sont friands de ce genre de chose. Je crois que ça les rassure.
>
> Ouaips, même que certains ne veulent plus que faire de l'analyse,
> surtout pas mettre les mains dans le camboui des lignes de code...
>
> J'ai eu un collègue fou de la documentation et des notations UML & Co,
> qui là où j'aurais fait une petite doc synthétique, éventuellement avec
> un diagramme de classes pour expliquer un peu, pondait des pages et des
> pages de trucs verbeux qui n'apportaient AMA pas grand chose (par
> contre, il mettait les mains dans le camboui pour que le code
> correspondant tourne).
>
> A+
>
> Laurent.

> "vieux de la vieille"

'ttention, hein !
C'est pas parce qu'on est vendredi qu'il faut insulter :
- moi ;
- ma femme.

Nous avons su rester jeune d'esprit (surtout moi). Et, ça, c'est ma méthode secrète pour bien (hum
?) programmer.

Non mais...



@+

Michel Claveau

> "vieux de la vieille"

'ttention, hein !
C'est pas parce qu'on est vendredi qu'il faut insulter :
- moi ;
- ma femme.

Nous avons su rester jeune d'esprit (surtout moi). Et, ça, c'est ma méthode secrète pour bien (hum
?) programmer.

Non mais...



@+

Michel Claveau

Méta-MCI (MVP), le 17/08/2007 a écrit :
>> "vieux de la vieille"
>
> 'ttention, hein !
> C'est pas parce qu'on est vendredi qu'il faut insulter :
> - moi ;

Madame s'en charge ?

> - ma femme.

Là, c'est vous qui vous en occupez ?


> Nous avons su rester jeune d'esprit

Vous parlez de vous à la manière de Louis XIV ?

> (surtout moi).

Aie ! l'erreur est donc avérée...

--
Pierre Maurette

Méta-MCI (MVP), le 17/08/2007 a écrit :
>> "vieux de la vieille"
>
> 'ttention, hein !
> C'est pas parce qu'on est vendredi qu'il faut insulter :
> - moi ;

Madame s'en charge ?

> - ma femme.

Là, c'est vous qui vous en occupez ?


> Nous avons su rester jeune d'esprit

Vous parlez de vous à la manière de Louis XIV ?

> (surtout moi).

Aie ! l'erreur est donc avérée...

--
Pierre Maurette

Moi, je vous le dis : " y'en a qui doivent faire de l'assembleur en cachette, pour avoir l'esprit
aussi tordu".

Moi, je vous le dis : " y'en a qui doivent faire de l'assembleur en cachette, pour avoir l'esprit
aussi tordu".

Méta-MCI (MVP), le 17/08/2007 a écrit :
> Moi, je vous le dis : " y'en a qui doivent faire de l'assembleur en cachette,
> pour avoir l'esprit aussi tordu".

Mes inutiles remarques se voulaient légères, amusées. Un vendredi...

Ceci dit il y a effectivement un rapport indirect avec l'assembleur.
J'ai effectivement publié, et écrire n'était pas mon métier. J'ai été
pris de terreur, le mot est à peine exagéré, à l'idée d'être lu, ce qui
est effectivement un comble, et jugé.
J'ai eu la coquetterie de vouloir rédiger. Je juge d'ailleurs le
résultat un peu verbeux, mais peu importe. Immédiatement s'est posée la
question du temps et de la personne. Pour le temps, dans un ouvrage
technique, le présent s'impose. Pour la personne, c'est un peu plus
ouvert. J'élimine le "tu", bien entendu. Restent le "on", le "je" et le
"vous". J'ai choisi le "vous". Là se pose la question de l'accord. J'ai
décidé - et il me semble que c'est la règle - que ce "vous" s'accordait
au singulier. Comme le "Nous" royal.

J'imagine que Tarek s'est plus ou moins posé les mêmes questions...

--
Pierre Maurette

Méta-MCI (MVP), le 17/08/2007 a écrit :
> Moi, je vous le dis : " y'en a qui doivent faire de l'assembleur en cachette,
> pour avoir l'esprit aussi tordu".

Mes inutiles remarques se voulaient légères, amusées. Un vendredi...

Ceci dit il y a effectivement un rapport indirect avec l'assembleur.
J'ai effectivement publié, et écrire n'était pas mon métier. J'ai été
pris de terreur, le mot est à peine exagéré, à l'idée d'être lu, ce qui
est effectivement un comble, et jugé.
J'ai eu la coquetterie de vouloir rédiger. Je juge d'ailleurs le
résultat un peu verbeux, mais peu importe. Immédiatement s'est posée la
question du temps et de la personne. Pour le temps, dans un ouvrage
technique, le présent s'impose. Pour la personne, c'est un peu plus
ouvert. J'élimine le "tu", bien entendu. Restent le "on", le "je" et le
"vous". J'ai choisi le "vous". Là se pose la question de l'accord. J'ai
décidé - et il me semble que c'est la règle - que ce "vous" s'accordait
au singulier. Comme le "Nous" royal.

J'imagine que Tarek s'est plus ou moins posé les mêmes questions...

--
Pierre Maurette

Oulà !

J'utilisais simplement le passage de paramètres par position :

"vieux de la vieille" (moi, ma femme)
vieux = "moi"
vieille = "ma femme"

Bon faudra attendre Python-3000, pour mettre une étoile, ce qui obligera à utiliser des paramètres
nommés.

Sur ce, je retourne à l'apéro...


Santé à tous !

Oulà !

J'utilisais simplement le passage de paramètres par position :

"vieux de la vieille" (moi, ma femme)
vieux = "moi"
vieille = "ma femme"

Bon faudra attendre Python-3000, pour mettre une étoile, ce qui obligera à utiliser des paramètres
nommés.

Sur ce, je retourne à l'apéro...


Santé à tous !