Témoignages sur vos pratiques de dévelopeur...

Kris73 · Le 03/04/2012, à 19:54

HP a écrit :

C'est dommage… bon, bien… si tu n'es pas développeur, ça risque d'être (très, très) dur de leur faire passer l'étincelle. Vaut mieux que tu leur balances de grands phrases copiées-collées, à l'emporte-pièce, en travers de la tronche, pour les briser, c'est mieux… genre :
Moi je dirais, que si t'es pas développeur, tu ne devrais pas t'improviser à donner des cours dans le domaine… après, c'est à voir comment tu gères çà au niveau de ta vergogne et/ou de Maslow ; heureusement pour toi, tu risques de tomber sur des victimes bien faciles…

Il n'y a pas un bouton pour supprimer les réponses creuses ? Non ? Bon....

Pylades · Le 03/04/2012, à 20:10

Java, plus généraliste que Python ?

Jules Petibidon · Le 03/04/2012, à 21:41

Peut-être faut il comprendre plutôt classique ?

Les principaux langages de programmation ont une syntaxe relativement proche. Python par contre est assez hors norme.

Java a l'avantage d'être au juste milieu entre complexité et simplicité.

kamui57 · Le 03/04/2012, à 21:42

Kris73 a écrit :

ArkSeth a écrit :
Un truc qu'il serait bien qu'ils apprennent aussi, c'est qu'il existe tout un tas de langages et de types de programmations différents (C, C++, Java, Python, PHP, Lisp etc.) et que chacun a ses avantages et ses inconvénients.
Tout à fait, le problème c'est l'horaire réduit de la spécialité ( 2h par semaine )...on va être obligé de faire des choix et de ne qu'évoquer les multiples langages...
On réfléchit à celui que l'on utilisera de manière plus poussée, a priori ce sera Java; on avait aussi le choix de Python mais on a choisit le plus "généraliste" ( je sais pas si le terme est bien choisi )...vous verriez les yeux qui s'éclairent quand on leur dit qu'il pourront programmer des applis Android
Chris

je connais quelqu'un (prof en lycée) qui suit une formation pour l'ISN (enfin ils sont plusieurs et yen a un qui y va et qui ramène cours et exos) car je l'aide en python, il fait du python et envoie les exos faits, mais il a parlé de java aussi, que l'inspecteur veut du java ou un truc dans le genre. Mais ils faisaient du scilab avant (je ne sais plus pour quoi), ils font maintenant du python, je crois qu'ils vont continuer en python, je pense que déjà c'est bien qu'il arrive à faire les exos demandés, il trouve pas ça facile, et je pense que ce serait encore plus dur en java.

Pylades · Le 03/04/2012, à 22:36

Python, ça reste de l’impératif et de l’orienté objet principalement, c’est très classique. Des langages comme Prolog, Lisp ou Haskell sont eux un peu plus ésotériques…

T’façons, rien n’égalera le Piet, de ce point de vue.

Kris73 · Le 04/04/2012, à 11:59

Jules Petibidon a écrit :

Peut-être faut il comprendre plutôt classique ?

Oui, c'est ce que je voulais dire

Hibou57 · Le 06/04/2012, à 17:38

Rafbor a écrit :

D'autres aspects du travail pratiqué en SSII sont aussi peu enviables. La spécialisation, par exemple. Les tâches sont en effet distribuées par équipes, et certaines personnes sont donc cantonnées à ne réaliser que les IHM, d'autres ne codent que les tests unitaires, d'autres écrivent la doc, ou les specs, etc.. Pas toujours intéressant, et donc on peut comprendre pourquoi certains sont déçus.

Ce qui peut être justifié et n’est pas nécessairement non‑enviable.

J’ai immédiatement pensé à ton commentaire en lisant ceci :

Non-Native UI Sucks (codinghorror.com). Février 2007.

Coding Horror a écrit :

Ultimately, the best any Java app can do is pretend to be a native app. To fake it. And more often than not, it can't even manage to do that:
This project should be a cautionary tale for people who think programmers should be interface designers. Apple and Microsoft at least recognize that these are different skill sets, and that looks and feels should be created by a team of programmers, graphic designers, and interaction designers. Sadly the Linux and Java communities haven't really figured this out yet, and are still trying to have programmers do it all, with predictable results. […]

Quand une chose, pour être bien réalisée, demande d’avoir de l’expérience et de la compétence dans sa réalisation, il n’y a pas de problème à confier chaque facette d’une réalisation à une personne spécialisée dans cette facette. Par contre, il faudra prendre soin de la communication entre les gens.

Il ne faut pas confondre « je ne peux pas, parce que je travail seul » (souvent par contrainte, justement) avec « ça ne doit pas être fait comme ça ».

Dernière modification par Hibou57 (Le 06/04/2012, à 18:14)

sweetly · Le 06/04/2012, à 18:35

Hibou57 a écrit :

Rafbor a écrit :
D'autres aspects du travail pratiqué en SSII sont aussi peu enviables. La spécialisation, par exemple. Les tâches sont en effet distribuées par équipes, et certaines personnes sont donc cantonnées à ne réaliser que les IHM, d'autres ne codent que les tests unitaires, d'autres écrivent la doc, ou les specs, etc.. Pas toujours intéressant, et donc on peut comprendre pourquoi certains sont déçus.
Ce qui peut être justifié et n’est pas nécessairement non‑enviable.
J’ai immédiatement pensé à ton commentaire en lisant ceci :
Non-Native UI Sucks (codinghorror.com). Février 2007.
Coding Horror a écrit :
Ultimately, the best any Java app can do is pretend to be a native app. To fake it. And more often than not, it can't even manage to do that:
This project should be a cautionary tale for people who think programmers should be interface designers. Apple and Microsoft at least recognize that these are different skill sets, and that looks and feels should be created by a team of programmers, graphic designers, and interaction designers. Sadly the Linux and Java communities haven't really figured this out yet, and are still trying to have programmers do it all, with predictable results. […]
Quand une chose, pour être bien réalisée, demande d’avoir de l’expérience et de la compétence dans sa réalisation, il n’y a pas de problème à confier chaque facette d’une réalisation à une personne spécialisée dans cette facette. Par contre, il faudra prendre soin de la communication entre les gens.
Il ne faut pas confondre « je ne peux pas, parce que je travail seul » (souvent par contrainte, justement) avec « ça ne doit pas être fait comme ça ».

Je ne comprends pas du tout le lien entre l'article que tu donnes et le discours de Rafbor. Il n'y a pas besoin d'être spécialiste UI pour savoir que coder une UI native est un vrai plus pour l'intégration de ton programme.

Hibou57 · Le 06/04/2012, à 18:52

Je répondais à son jugement négatif sur la spécialisation.

Rafbor · Le 07/04/2012, à 08:11

Hibou57 a écrit :

Je répondais à son jugement négatif sur la spécialisation.

Bien sur que faire appel à des spécialistes pour certaines tâches est un gage de qualité et de gain de temps, essentiels pour la réussite d'un projet, mais je parlais là de l'aspect purement intérèt au travail. Quand on s'imagine qu'on va coder des programmes géniaux et qu'on se retrouve à coder à longueur de journée des fonctions imaginées par d'autres, qu'on te donne seulement le nom des fonctions, leurs paramètres d'entrée et une description de ce qu'elle doivent faire et retourner, ben bôf quoi, en plus tu vois jamais tourner le programme terminé, tu te retrouves à faire le bouche-trou sur plusieurs projets simultanément, et tu codes comme un robot, en te disant que peut être, tu as mal choisi ta voie..
Bon en général, avec l'expérience et après avoir fait ses preuves, on accède à des tâches plus valorisantes et intéressantes, mais pas toujours.

djibb · Le 25/04/2012, à 12:32

Bonjour,
j'ai la chance d'enseigner aussi cette option l'année prochaine.
En ce qui me concerne, ce sera python. Une fois les paradigmes de ce langage compris, ils pourront se mettre à n'importe lequel. Mais au moins, ils n'auront pas à gérer les (), {}, ; qui sont vraiment des freins à l'apprentissage d'un langage. J'ai de très mauvais souvenirs de mes début en turbo Pascal. Et pourtant, j'aimais ça.
En plus, ils produiront du code propre. (indenté, quoi )

Concernant le code en lui-même... je crois qu'il faut différencier vraiment les mondes de la recherche et industriel. Les contraintes ne sont pas forcément les-mêmes et il est très compliqué de caser les programmeurs.

Je rejoins tout à fait ceux qui disent que la lecture de la doc est vraiment importante. Pour cela, python est très intéressant aussi. (__doc__() )

De quoi mouliner un peu : http://science-info-lycee.fr/le-forum/

sweetly · Le 25/04/2012, à 13:55

djibb a écrit :

Bonjour,
j'ai la chance d'enseigner aussi cette option l'année prochaine.
En ce qui me concerne, ce sera python. Une fois les paradigmes de ce langage compris, ils pourront se mettre à n'importe lequel. Mais au moins, ils n'auront pas à gérer les (), {}, ; qui sont vraiment des freins à l'apprentissage d'un langage. J'ai de très mauvais souvenirs de mes début en turbo Pascal. Et pourtant, j'aimais ça.
En plus, ils produiront du code propre. (indenté, quoi )
Concernant le code en lui-même... je crois qu'il faut différencier vraiment les mondes de la recherche et industriel. Les contraintes ne sont pas forcément les-mêmes et il est très compliqué de caser les programmeurs.
Je rejoins tout à fait ceux qui disent que la lecture de la doc est vraiment importante. Pour cela, python est très intéressant aussi. (__doc__() )
De quoi mouliner un peu : http://science-info-lycee.fr/le-forum/

Pour la lecture de la doc, je suis bien sûr d'accord. Mais j'insisterai également sur la clareté du code en lui-même. Des commentaires, une doc, peuvent ne pas être à jour. Le code l'est forcément. Et maintenant, avec l'habitude, je lis en tout premier lieu le code. S'il est mal écrit, ben ça me freine, et je vais voir une doc avec le risque qu'elle parle d'un truc obsolète. Donc à mon avis, il faut également mettre l'accent sur la lisibilité du code écrit, à la fois en terme de "mise en page" (indentation, retour chariot, longueur de fichiers) mais aussi sur la sémantique (noms de variables, fonctions, la bonne structure au bon endroit, etc.).

vthierry · Le 25/04/2012, à 15:12

> vous n’êtes peut-être pas sans savoir qu'une nouvelle spécialité s'ouvre à la rentrée prochaine en Terminale, baptisée ISN = Informatique et Sciences du Numérique; le but est de donner l'envie aux élèves de passer d'un statut de simple consommateur de solutions informatiques, à celui de quelqu'un qui a envie de comprendre ce qu'il y a derrière, voire à celui de créateur de ses propres solutions...

Les éléments proposés ici sont tres intéressants et http://science-info-lycee.fr/le-forum est le forum où les collègues profs qui vont enseigner l'ISN s'expriment sur ces sujets, hésitons pas à aller les aider, etc... !

BFB · Le 26/04/2012, à 19:36

Après leur avoir expliqué le pourquoi du comment des commentaires, et leur avoir laissé le temps d'intégrer cette pratique, il y a une bonne astuce pour ancrer définitivement l'importance de ceux-ci et vérifier qu'ils appliquent la bonne méthode.

Faites les faire un programme (ou exercice un peu long) la séance avant les vacances.
À la reprise des cours, passez dans les rangs et demandez-leur ce que fait leur programme, et pourquoi il donne le bon résultat.

Avant d'être confronté à cette situation, malgré le ait que je commentais déjà un peu mon code, que j'indentais bien et que l’utilisait des noms de variables clairs, je pensais que j'en faisait assez.

Rafbor · Le 26/04/2012, à 20:08

Faire du code brouillon et mal commenté, à moins d'être maso ou "je-m’en-foutiste", on le fait qu'une fois. Car quand on doit ré-intervenir sur son propre code 6 mois après, on est bien content de pouvoir se repérer et comprendre rapidement les algos-qui-tuent qu'on avait pondu fièrement et intelligemment à l'époque.
6 mois après, on les relis en transpirant et en se demandant si on a pas perdu des neurones depuis car on y comprend plus rien...

Kris73 · Le 26/04/2012, à 20:54

Rafbor a écrit :

Car quand on doit ré-intervenir sur son propre code 6 mois après, on est bien content de pouvoir se repérer et comprendre rapidement les algos-qui-tuent qu'on avait pondu fièrement et intelligemment à l'époque.

Je dirais même une semaine après, ça m'est arrivé y a pas longtemps
J'ai bien compris maintenant l'importance des commentaires, et qu'il soient clairs et détaillés !

Sympa de voir que d'autres futurs enseignants de la spé ISN ont rejoint ce fil...

afilmore · Le 26/04/2012, à 20:57

+1 Pour les commentaires et la clarté du code.

La structure du programme, la structure du code, les commentaires, le style, c'est fondamental à mon humble avis.

On trouve quelques "coding conventions" existantes dont on peut s'inspirer, j'ai bien aimé celle ci :
http://elementaryos.org/docs/developer- … ding-style

J'ai adopté assez rapidement cet élément :

Explicit namespaces, no "using" statements

Auquel j'ajoute, pas de variables génériques, genre "var".

Donc en fait, leur Hello World http://elementaryos.org/docs/creating-project
Perso, je l'écrirais comme ça :

int main (string[] args) {

    Gtk.init (ref args);

    Gtk.Window window = new Gtk.Window ();
    window.title = "My first elementary app";
    window.set_default_size (400, 500);
    window.destroy.connect (Gtk.main_quit);

    Gtk.Button button = new Gtk.Button.with_label ("Hello, world!");

    window.add (button);
    window.show_all ();
    Gtk.main ();
    return 0;
}

Niveau commentaires, je fais ce genre de trucs :
https://github.com/afilmore/lxdesktop/b … ation.vala

Je trouve ça allucinant que dans les entêtes de fichiers, y a souvent plus de lignes pour décrire les termes de licence que pour expliquer ce que fait le programme...

Kris73 · Le 26/04/2012, à 20:59

djibb a écrit :

Bonjour,
En ce qui me concerne, ce sera python. Une fois les paradigmes de ce langage compris, ils pourront se mettre à n'importe lequel.

Oui, au début c'est ce qu'on avait pensé, et puis comme dit précédemment, on s'est orienté plutôt vers Java, langage a priori plus utilisé "en live"...Sans vouloir faire bondir les spécialistes bien sur....:rolleyes:

Et puis, habituer les élèves assez tôt à des contraintes très strictes en terme de rédaction de code, ça nous semble une bonne chose....Un } ou un [ oublié, les IDE les détectent assez bien, non ?

De toute manière, on se doute bien qu'on ne va pas récupérer que des brêles en info, certains toucheront déjà un peu leurs billes...ils vont vite s'adapter

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 03/04/2012, à 19:54

Re : Témoignages sur vos pratiques de dévelopeur...

#27 Le 03/04/2012, à 20:10

Re : Témoignages sur vos pratiques de dévelopeur...

#28 Le 03/04/2012, à 21:41

Re : Témoignages sur vos pratiques de dévelopeur...

#29 Le 03/04/2012, à 21:42

Re : Témoignages sur vos pratiques de dévelopeur...

#30 Le 03/04/2012, à 22:36

Re : Témoignages sur vos pratiques de dévelopeur...

#31 Le 04/04/2012, à 11:59

Re : Témoignages sur vos pratiques de dévelopeur...

#32 Le 06/04/2012, à 17:38

Re : Témoignages sur vos pratiques de dévelopeur...

#33 Le 06/04/2012, à 18:35

Re : Témoignages sur vos pratiques de dévelopeur...

#34 Le 06/04/2012, à 18:52

Re : Témoignages sur vos pratiques de dévelopeur...

#35 Le 07/04/2012, à 08:11

Re : Témoignages sur vos pratiques de dévelopeur...

#36 Le 25/04/2012, à 12:32

Re : Témoignages sur vos pratiques de dévelopeur...

#37 Le 25/04/2012, à 13:55

Re : Témoignages sur vos pratiques de dévelopeur...

#38 Le 25/04/2012, à 15:12

Re : Témoignages sur vos pratiques de dévelopeur...

#39 Le 26/04/2012, à 19:36

Re : Témoignages sur vos pratiques de dévelopeur...

#40 Le 26/04/2012, à 20:08

Re : Témoignages sur vos pratiques de dévelopeur...

#41 Le 26/04/2012, à 20:54

Re : Témoignages sur vos pratiques de dévelopeur...

#42 Le 26/04/2012, à 20:57

Re : Témoignages sur vos pratiques de dévelopeur...

#43 Le 26/04/2012, à 20:59

Re : Témoignages sur vos pratiques de dévelopeur...

Pied de page des forums