DevNote - #3 - ls
Lundi 11 février 2008 à 02 h 37
Je n'aurais jamais pensé que travailler en équipe serait si dur.
Peut être que c'est parce que à cause du côté scolaire, que des gens avec peu de compétences se retrouvent sur un tel projet. Ou peut être tout simplement parce que ils ont réussi à se montrer meilleurs qu'il ne le sont.
En entreprise cela n'arriverait certainement pas, du moins pas une telle différence de niveaux. Alors, le côté "apprendre à travailler en équipe, comme en entreprise", c'est plutôt raté.
Reste que ce projet est une bonne chance de prouver nos capacités, voire même de nous élever donc je ne le laisserais pas tomber et y contribuerai jusqu'au bout.
Ce sont les statistiques du svn sur les deux derniers mois.
A l'heure où je parle, on est à la révision 57. Sacré avancement par rapport à avant.
Je ne suis plus tout seul non plus à m'activer sur le code et comme je suis mauvais en gtk et tout ce qui est interfaces graphiques, ça aide.
Fait marrant, les copiers coller sont finalement pas si présents que ça. Il y a eu beaucoup plus de modifications que prévues, obligeant à reprogrammer entièrement certaines parties. D'autres ont été reprogrammées sans même se baser sur aircrack-ng; le code source de ce dernier tombe parfois dans le folklore.
Ceci est la fenêtre principale, nommée "list" puisque son but est de lister les réseaux environnants.
Pour pouvoir arriver à ce résultat, elle met en mode "monitor" la carte wifi et reçoit donc chaque trame 802.11 circulant dans le coin. Elles sont ensuites interprétées une par une pour afficher ce résultat en temps réel et non par scan d'environ 5 secondes, où le résultat n'est affiché qu'après le scan. Ca peut paraitre inutile, mais pas tant que ça puisque pour cracker un réseau wifi le mode monitor sera nécéssaire.
A terme de quelques semaines, notre but est une nouvelle fenêtre qui permettra de donner plus de détails de ces réseaux (comme sur kismet / kismac), et à partir duquel il sera possible d'attaquer le réseau en question.
Une fois cela fait il y aura un plugin permettant d'évaluer la sécurité du réseau, et lui donner une note. Pour se donner bonne conscience.
Ensuite, l'on s'amusera à coder de petites features par ci par là. On a déjà le channel hoper intelligent (augmente les chances de trouver un réseau), un power affiché sur plus de cartes que aircrack-ng le fait.
Compteur geiger, brouilleur de canal, localisation gps, connection au réseau une fois la clé crackée + test de débit intégré, spoof d'ap et fout à micro ondes pour plus tard.
Peut être que c'est parce que à cause du côté scolaire, que des gens avec peu de compétences se retrouvent sur un tel projet. Ou peut être tout simplement parce que ils ont réussi à se montrer meilleurs qu'il ne le sont.
En entreprise cela n'arriverait certainement pas, du moins pas une telle différence de niveaux. Alors, le côté "apprendre à travailler en équipe, comme en entreprise", c'est plutôt raté.
Reste que ce projet est une bonne chance de prouver nos capacités, voire même de nous élever donc je ne le laisserais pas tomber et y contribuerai jusqu'au bout.
Ce sont les statistiques du svn sur les deux derniers mois.
A l'heure où je parle, on est à la révision 57. Sacré avancement par rapport à avant.
Je ne suis plus tout seul non plus à m'activer sur le code et comme je suis mauvais en gtk et tout ce qui est interfaces graphiques, ça aide.
Fait marrant, les copiers coller sont finalement pas si présents que ça. Il y a eu beaucoup plus de modifications que prévues, obligeant à reprogrammer entièrement certaines parties. D'autres ont été reprogrammées sans même se baser sur aircrack-ng; le code source de ce dernier tombe parfois dans le folklore.
Ceci est la fenêtre principale, nommée "list" puisque son but est de lister les réseaux environnants.
Pour pouvoir arriver à ce résultat, elle met en mode "monitor" la carte wifi et reçoit donc chaque trame 802.11 circulant dans le coin. Elles sont ensuites interprétées une par une pour afficher ce résultat en temps réel et non par scan d'environ 5 secondes, où le résultat n'est affiché qu'après le scan. Ca peut paraitre inutile, mais pas tant que ça puisque pour cracker un réseau wifi le mode monitor sera nécéssaire.
A terme de quelques semaines, notre but est une nouvelle fenêtre qui permettra de donner plus de détails de ces réseaux (comme sur kismet / kismac), et à partir duquel il sera possible d'attaquer le réseau en question.
Une fois cela fait il y aura un plugin permettant d'évaluer la sécurité du réseau, et lui donner une note. Pour se donner bonne conscience.
Ensuite, l'on s'amusera à coder de petites features par ci par là. On a déjà le channel hoper intelligent (augmente les chances de trouver un réseau), un power affiché sur plus de cartes que aircrack-ng le fait.
Compteur geiger, brouilleur de canal, localisation gps, connection au réseau une fois la clé crackée + test de débit intégré, spoof d'ap et fout à micro ondes pour plus tard.
> Alors, le côté "apprendre à travailler en équipe, comme en entreprise", c'est plutôt raté.
Au contraire, c'est très réaliste malheureusement.
C'est le même problème, parfois pire vu qu'en France, peu d'entretien d'embauche font passer des tests de niveau... et qu'au niveau du "management" vielle école, tous les informaticiens se valent.
Autant que tu sois au courant, très peu d'entreprise ont saisi l'importance et la différence entre un bon développeur (qualité de code, design évolutif, commentaires, pas de hacks, gestion des erreurs, code de débuggage inclus/prévu, etc..) et un mauvais (que des hacks, pas de commentaires, code figé, bugs à la pelle.).
Les "managers" ne voient trop souvent que la différence de prix initiale (salaire), pas la différence de prix finale (temps, bugs, recodage complet pour la prochaine version, code pas fini, travail manuel nécessaire par dessus, .etc.)
Bref, il vaut mieux apprendre à composer avec. La loi du genre étant la loi du minimum: le niveau de l'équipe est équivalente au niveau du plus faible...
- Dans ces cas-là encore plus que d'autre la programmation par paire s'impose. (cf extreme programming.)
- Faire un découpage réaliste (donc pas égalitaire) du travail
- Utiliser des outils de vérification (outils d'analyse de code, genre splint, valgrind), de formatage (astyle)
- Relecture obligatoire de tous les commits au moment du commit (sinon risque d'oubli de la part de l'autre de ce qu'il a voulu coder. et donc nuit de relecture de code indigeste pour solutionner des bugs...)
Dans certains cas, tu devras même écarter du clavier certains "développeur" pour leur donner la chance de faire le manuel, faire des tests utilisateur etc...
Mieux vaut être réaliste et tabler là-dessus et être prévoyant.
Autre solution, choisir son entreprise avec beaucoup de soin. Un bon critère c'est le 'pas de test' à l'entrée... et une liste de question à poser ...
Par exemple, poser ce genre de questions...
Il ne faut pas se leurrer, dans "le monde réel" tenir un cahier de specs, ne pas être dérangé, avoir que des brutases dans l'équipe et encore plus la programmation par paire je n'en ai jamais vu.
Oh des tentatives si, mais le but numéro 1 des patrons c'est de faire de la thune, donc aller vite, tant pis pour les bugs tant que c'est encaissé.
Ce qu'ils voient
1/ Recette veut dire paiement,
2/ Si paiement passer au nouveau client donc encaisser le premier tiers.
2/ Coder propre = plus de temps = T'as pas lu les deux premiers points connard ?
C'est une des raisons pour laquelle depuis je suis indépendant.
Sinon bon courage phtc, c'est un chouette projet.
Et merci à Aircrack qui m'a évité de tomber en dépression lorsque ma ligne Free a été coupée plus de 2 mois.
L'idée première était de prévenir phtc sur ses doutes quant à avoir des développeurs de bas niveau dans une équipe en entreprises, et de lui donner des solution connues pour essayer de remédier au problème.
si tu veux avoir de belles promotions et un meilleur salaire en entreprise, fait n'importe quoi.
sinon, je suis vraiment impatient de voir ce que ca va donner, ca a l'air de bien avancer en tout cas =)
c'est magnifique :')
Pas rassurant c'est vrai mais c'est toujours bon à savoir.
La plus part des outils cités je ne les connaissais pas (je cherchais encore après un logiciel rien que pour vérifier les malloc / free des autres et même parfois de moi même)
Et façe à une équipe de dev plus ou moins dérangeante aussi ça aide d'avoir des professionnels qui en parlent. Ma prof de gestion de projets est même plutôt hors sujet.
C'est un peu à cause de ça que l'on s'est tous retrouvés bloqués au début et maintenant que l'on doit rattraper le retard alors que l'on avait déjà le handicap d'une équipe loin d'être top.