Le topic de la programmation MMA Arena: Atlassian VS Gitlab

**Mr Ianou** · 06/12/2019, 13h37

Et bien merci pour les quelques eclaircicement je sais pas si ça va faire de beau code mais j'essayerai de mettre ça ici pour rigoler.

**ducon** · 06/12/2019, 21h20

Envoyé par Mr Ianou

Bonjour messieurs.
J'ai pas trop l'habitude de faire ça mais je suis un petit peu sous la vague. J'ai besoin d'aide pour ce sujet python.
Mon groupe et moi même ne sont pas trop fort là dessus et j'avoue que je ne peux pas me permettre de louper ça.
Donc toute aide est le bienvenu j'ai le week-end pour plancher dessus.
Merci d'avance pour vos lumières et idées.

Si ça doit marcher sous Linux et Windows, utilise le module de Python qui va bien : os. Il te permettra de gérer de manière unifiée les différents systèmes d’exploitation (ouverture de répertoire, caractère de séparation des noms de répertoires, etc).
Pour lire un fichier, utilise le mot clé with, c’est plus propre :

Code:

extensions=set()
with open("fichier.lst","ro") as f:
  for ligne in f:
    if ligne.startswith("."):
      extensions.add(ligne.strip()) # vire la fin de ligne moche éventuelle

**Mr Ianou** · 07/12/2019, 17h15

Merci.

**Mr Ianou** · 09/12/2019, 09h35

Pff pour récupérer les informations sur carte réseau c'est la plaie.
J'ai au moins 80 lignes

**M0s** · 09/12/2019, 14h58

Envoyé par Mr Ianou

Pff pour récupérer les informations sur carte réseau c'est la plaie.
J'ai au moins 80 lignes

Et t'as le droit d'utiliser des librairies externes ou pas du tout? Dans le premier cas y'a des lib crossplatform comme psutil qui peuvent te permettre de récup le nom de l'interface et l'ip en à peine quelques lignes. Dans le second cas par contre va falloir que tu fasses tes propres libs, une pour chaque plateforme. Et que tu appelles ensuite la lib correspondate selon la plateforme :

Code:

import platform

if platform.system().lower() == 'windows':
    # importer la lib windows
elif platform.system().lower() == 'linux':
    # importer la lib linux
else:
    ...

Après y'a plusieurs méthodes pour faire ça. La plus simple, mais aussi la moins élégante étant d'envoyer des commandes spécifiques au système via subprocess par exemple. Genre 'ipconfig' sous Windows et 'ifconfig' ou 'ip' sous Linux. Et ensuite de parse la réponse pour extraire les valeurs.

**Teocali** · 09/12/2019, 15h30

Envoyé par M0s

Et t'as le droit d'utiliser des librairies externes ou pas du tout? Dans le premier cas y'a des lib crossplatform comme psutil qui peuvent te permettre de récup le nom de l'interface et l'ip en à peine quelques lignes. Dans le second cas par contre va falloir que tu fasses tes propres libs, une pour chaque plateforme. Et que tu appelles ensuite la lib correspondate selon la plateforme :

Code:

import platform

if platform.system().lower() == 'windows':
    # importer la lib windows
elif platform.system().lower() == 'linux':
    # importer la lib linux
else:
    ...

Après y'a plusieurs méthodes pour faire ça. La plus simple, mais aussi la moins élégante étant d'envoyer des commandes spécifiques au système via subprocess par exemple. Genre 'ipconfig' sous Windows et 'ifconfig' ou 'ip' sous Linux. Et ensuite de parse la réponse pour extraire les valeurs.

Faut un export Pcap, donc j'imagine qu'il est plus ou moins obligé de passer par une lib externe...

**Nattefrost** · 09/12/2019, 18h03

Envoyé par M0s

Et t'as le droit d'utiliser des librairies externes ou pas du tout? Dans le premier cas y'a des lib crossplatform comme psutil qui peuvent te permettre de récup le nom de l'interface et l'ip en à peine quelques lignes. Dans le second cas par contre va falloir que tu fasses tes propres libs, une pour chaque plateforme. Et que tu appelles ensuite la lib correspondate selon la plateforme :

Code:

import platform

if platform.system().lower() == 'windows':
    # importer la lib windows
elif platform.system().lower() == 'linux':
    # importer la lib linux
else:
    ...

Après y'a plusieurs méthodes pour faire ça. La plus simple, mais aussi la moins élégante étant d'envoyer des commandes spécifiques au système via subprocess par exemple. Genre 'ipconfig' sous Windows et 'ifconfig' ou 'ip' sous Linux. Et ensuite de parse la réponse pour extraire les valeurs.

Je faisais ça avant, puis bon finalement autant écrire un script .sh ou powershell si y a vraiment besoin que de ça. Mais parfois c'est dur de prévoir que le scope du script va grossir ou pas. Et ca n'est pas le sujet de l'exo

**Mr Ianou** · 09/12/2019, 18h06

Et voila le bousin.

Tout n'est pas finalisé mais j'avais plus le temps et il fonctionne (si vous voulez voir le monstre, oui y'a pas de commentaire mais j'avais vraiment plus de temps) :

Code:

#!/usr/bin/python3
# -*- coding: utf-8 -*-
import os
import csv
import re
import platform
from pathlib import Path
import shutil
import scapy.all as scapy

def lecture():
# fonction chargement des extension
    fichierExtension = "./extension.lst"
    fichier = open(fichierExtension, "r")
    cpt = 0
    plop = fichier.readlines()
    fichier.close()
    debutLigne = r"^\."
    regex = re.compile(debutLigne)
    listeExtension = []
    for f in plop:
        cpt += 1
        if re.match(debutLigne, f):
            f = f[:-1]
            listeExtension.append(f)
    return listeExtension
list = lecture()

def creationRepertoire():
    nomMachine = platform.node()
    #os.removedirs(nomMachine+"\\Sysconfs")
    os.mkdir(nomMachine)
    os.mkdir(nomMachine+"/Sysconfs")
    os.mkdir(nomMachine+ "/SysNets")



def lecteurWindows():
    lettre = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
    drives = []
    for d in lettre:
        if os.path.isdir(d + ":"):
            drives.append(d)
    return drives
lecteur = lecteurWindows()


#c'est moche mais je sais pas faire mieux
def parcourtEtCopie():
    cpt_lecteur = 0
    destination = os.getcwd() + "/"+ platform.node() + "/Sysconfs/"
    for i in lecteur:
        racine = lecteur[cpt_lecteur] + ":"
        for p in Path(racine).glob('.\\**\\*'):
            #print(racine + os.path.splitext(p)[1])
            if (os.path.splitext(p)[1]) in list:
                aCopier = os.path.abspath(p)
                try:
                    shutil.copyfile(aCopier, destination + os.path.basename(p))
                except:
                    pass

        cpt_lecteur += 1


def parcourtEtCopie():
    cpt_lecteur = 0
    destination = os.getcwd() + "/"+ platform.node() + "/Sysconfs/"
    for i in lecteur:
        racine = lecteur[cpt_lecteur] + ":"
        for p in Path(racine).glob('.\\**\\*'):
            #print(racine + os.path.splitext(p)[1])
            if (os.path.splitext(p)[1]) in list:
                aCopier = os.path.abspath(p)
                try:
                    shutil.copyfile(aCopier, destination + os.path.basename(p))
                except:
                    pass

        cpt_lecteur += 1





def parcourtEtCopieLinux():
    destination = os.getcwd() + "/" + platform.node()
    for root, dirs, files in os.walk("/"):
        if dirs == destination:
            continue
        else:
            for name in files:
                if (os.path.splitext(name)[1]) in list:
                    aCopier = root + "/" + name
                    #print(aCopier)
                    #print(destination+"/Sysconfs/"+ name)
                    shutil.copyfile(aCopier, destination + "/Sysconfs/"+name)







def creationFichierReseauLinux():
    fichierSortie = open(os.getcwd() + "/" + platform.node() + "/SysNets/reseau.csv", "w", newline='\n')
    writer = csv.writer(fichierSortie, delimiter=';')
    writer.writerow(("Nom_Interface", "Type_Interface", "Mac_Interface", "adresse IPv4", "adresse IPv6"))
    ipconfig = os.popen('ip a').readlines()
    listeMac = []
    listeIp = []
    listeNom = []
    listeDesc = []
    listeIp6 = []
    i = 0
    p = 0
    for ligne in ipconfig:
        if 'physique' in ligne.lower():
            mac = ligne.split(' ')[10].strip()
            listeMac.append(mac)

    for i in range(0, len(listeMac)):
        try:
            writer.writerow((listeNom[i], listeDesc[i], listeMac[i], listeIp[i],listeIp6[i]))
        except:
            pass



def creationFichierReseauWindows():
    fichierSortie = open(os.getcwd() + "/" + platform.node() + "/SysNets/reseau.csv", "w", newline='\n')
    writer = csv.writer(fichierSortie, delimiter=';')
    writer.writerow(("Nom_Interface", "Type_Interface", "Mac_Interface", "adresse IPv4", "adresse IPv6"))
    ipconfig = os.popen('ipconfig /all').readlines()
    listeMac = []
    listeIp = []
    listeNom = []
    listeDesc = []
    listeIp6 = []
    i = 0
    p = 0
    for ligne in ipconfig:
        if 'physique' in ligne.lower():
            mac = ligne.split(':')[1].strip()
            listeMac.append(mac)
        if 'IPv4' in ligne:
            ip = ligne.split(':')[1].split('(')[0]
            listeIp.append(ip)
        if 'Carte ' in ligne:
            nom = ligne.split(':')[0].strip()
            listeNom.append(nom)
        if 'Description' in ligne:
            ip = ligne.split(':')[1].split('(')[0]
            listeDesc.append(ip)
        if 'IPv6' in ligne:
            ip = ligne.split(' ')[12].split('(')[0]
            listeIp6.append(ip)

    for i in range(0, len(listeMac)):
        try:
            writer.writerow((listeNom[i], listeDesc[i], listeMac[i], listeIp[i],listeIp6[i]))
        except:
            pass



def creationDuPcap(timer):
    timer = int(timer)
    p = scapy.sniff(prn=None, lfilter=None, count=0, store=1, offline=None, L2socket=None, timeout=timer)
    scapy.wrpcap(os.getcwd() + "/" + platform.node() + "/SysNets/plop.pcap", p)



def zippage():
    shutil.make_archive(os.getcwd() + "/" + platform.node(), 'zip', os.getcwd() + "/", platform.node())
    shutil.rmtree(os.getcwd() + "/" + platform.node())



def plop():
    plop = platform.system()
    return plop


def main(args):
    if plop() == 'Windows':
        lecture()
        creationRepertoire()
        lecteurWindows()
        parcourtEtCopie()
        creationFichierReseauWindows()
        creationDuPcap(args[1])
        zippage()
    else:
        lecture()
        creationRepertoire()
        parcourtEtCopieLinux()
        creationFichierReseauLinux()
        creationDuPcap(args[1])
        zippage()

if __name__ == '__main__':
    import sys
    sys.exit(main(sys.argv))

**Mr Slurp** · 09/12/2019, 18h09

Envoyé par Mr Ianou

Et voila le bousin.

Tout n'est pas finalisé mais j'avais plus le temps et il fonctionne (si vous voulez voir le monstre, oui y'a pas de commentaire mais j'avais vraiment plus de temps) :

Un balise code peut être?
[code]
bla bla
blabla
[/code]

Code:

bla bla
   blabla

Parce que du python sans indentation....

**Mr Ianou** · 09/12/2019, 18h30

La fatigue.

**William Vaurien** · 09/12/2019, 19h16

Envoyé par Mr Ianou

oui y'a pas de commentaire mais j'avais vraiment plus de temps) :

Code:

...
#c'est moche mais je sais pas faire mieux
...

exemple de bons commentaires:

Je ne suis généralement pas fan des commentaires sauf ceux qui explique bien le pourquoi et le comment et qui sont à jour (genre doc du JDK)
Perso je préfère voir du code découpé en méthode et utilisant des variables avec des noms clairs et parlant.

Sinon comment vous faites quand vous avez 3 ou 4 tickets qui tournent autour du même sujet et que vous devez faire des branches dans git ?
Par exemple vous avez une nouvelle feature qui demande d'extraire une méthode, un bug à corriger qui nécessite de modifier la partie du code qui est localisée dans le code à extraire, et enfin virer les warning et les codes smell dans le fichier qui contient ce code.
(Là c'est encore assez simple, généralement le nombre de fichier est un peu plus grand).

Les modifications peuvent se faire dans n'importe quel ordre, mais souvent il y a un ordre logique qui simplifie le travail (par ex: refactoring, bug fix, new feature)
- Naturellement j'ai tendance à ne faire qu'une branche qui regroupera les différents changement avec la ref du ticket dans le commit.
Mais dans ce cas la pull request fait un gros paquet de diffs et obtenir l'aval de mes pairs devient plus compliqué.
- Une autre solution c'est de faire chaque étape individuellement, avec un temps d'attente entre chaque pull request. J'aime moins cette solution car ça empêche de faire du refactoring en passant et ça oblige à faire des pauses entre chaque étape: du coup il faut se replonger dans le code à chaque fois, et pour moi empêche d'avoir une vision globale.
- Une dernière approche que j'ai tenté c'est de faire les changements sous formes de "poupées russes": la première étape se base sur master, puis la deuxième branche se base sur la première et ainsi de suite. Ce système est assez pratique mais peut se transformer en cauchemar quand il y a des problèmes (changement sur une des branches intermédiaires, mêmes conflits à résoudre plusieurs fois...

Je n'ai trouvé aucune solution qui me convienne vraiment, même si généralement je tend vers la solution de tout mettre dans la même pull request.
Vous faites comment ?

**ducon** · 09/12/2019, 21h11

Si tu veux documenter tes fonctions, utilise les triple guillemets juste après la signature, tu auras gratuitement l’attribut __doc__.

**Orhin** · 09/12/2019, 21h15

@William :
Si les tickets sont vraiment proches et qu'il n'y a pas non plus beaucoup de changements (ou alors des trucs triviaux comme le renommage d'une variable ou le déplacement d'un fichier), solution 1.
Si par contre y'a pas mal de changements fonctionnels (donc nécessitant une relecture plus poussée), solution 2.

Jamais la solution 3, c'est un nid à emmerdes.

**gros_bidule** · 09/12/2019, 21h55

Aussi, il ne fait pas avoir peur de discuter de la façon de faire la relecture de code. Pas mal de monde ne sait pas comment la faire, n'a jamais lu la moindre bonne pratique, et en souffre peut être. Un petit panel de questions que l'on peut se poser :
- qui fait la code review ? Le lead dev ? Les devs, si oui combien ? Un peu des deux ?
- qui teste (s'il faut tester qqchose à la main) ? Comprendre : qui assure que le code a été testé autrement que via les tests unitaires & d'intégration ? Quid d'un cahier de test ? J'ai vu des équipes dire que c'est au dev de tester, d'autres au contraire que le dev a trop le nez dans son code pour bien tester, donc ça serait aux reviewers de tester. Perso j'opterais plutôt pour un effort sur les tests unitaires et d'inté. S'ils ne suffisent pas, c'est qu'à priori on n'a pas assez investi dessus. Quand c'est possible, bien sûr
- comment on se facilite la vie pour la relecture :
--- tout faire dans BitBucket, Gitlab ou bien récupérer la branche et regarder le diff dans son IDE (à titre perso je préfère quand ça commence à causer, ça permet d'avoir le lint de l'IDE, naviguer dans le code et faire des recherches, puis je maîtrise mieux les diff avec - je checkout ça dans un git worktree dédié) / autrement
--- si plusieurs commits, relire le gros diff ou le diff de chaque commit ? Trop de commits ? Ne pas avoir peur de demander à scinder une pull-request si elle est trop grosse ou si elle part dans tous les sens : même si ça va "embêter" le dev, ça va bcp moins embêter les reviewers, et à terme éduquer le dev
- les types de retours : par exemple j'avais un collègue qui faisait PLEIN de retours sur le formatage (genre 30 sur une pull-request, un sur chaque ocurence). Bah c'était chiant, on l'a recadré. A la limite 1 commentaire général pour dire "reformat stp" et voilà. Il faut faire gaffe à comment la review est vécue, ça devient facilement violent, autant pour le dev que le reviewer
- et j'en passe

Qqun avait fait un excellent article su le sujet, je le poste dès que je le retrouve.

---

Les poupées russes, je les conçois lorsque tu fais une feature 1, puis que tu veux faire une feature 2 qui a besoin que la 1 soit mergée. Même si ce n'est pas l'idéal, si ton chef veut absolument que tu commences à bosser sur la 2, tu n'as pas trop le choix. C'est la faute au chef on va dire ^^ (et je n'aime pas les chefs qui s’immiscent trop dans les pratiques de dev, et se fichent royalement de tes conditions de travail du moment que tu es productif).

**Orhin** · 09/12/2019, 23h01

Envoyé par gros_bidule

- qui fait la code review ? Le lead dev ? Les devs, si oui combien ? Un peu des deux ?

Dans l'idéal au moins 2 personnes de l'équipe avec un mix profil lead dev/junior histoire :
- d'avoir un regard à la fois expert et neuf (les questions naïves sont très bien pour éviter de s'encrouter dans ses habitudes)
- de faire monter en compétences les nouveaux en leur faisant analyser du code propre

Envoyé par gros_bidule

- qui teste (s'il faut tester qqchose à la main) ? Comprendre : qui assure que le code a été testé autrement que via les tests unitaires & d'intégration ? Quid d'un cahier de test ? J'ai vu des équipes dire que c'est au dev de tester, d'autres au contraire que le dev a trop le nez dans son code pour bien tester, donc ça serait aux reviewers de tester. Perso j'opterais plutôt pour un effort sur les tests unitaires et d'inté. S'ils ne suffisent pas, c'est qu'à priori on n'a pas assez investi dessus. Quand c'est possible, bien sûr

Sujet complexe.
C'est avant tout une question une question de criticité et de cout :
- le cœur métier de ton appli et les règles de gestion ? Si c'est bien découpé ça se teste unitairement plutôt facilement et c'est nickel pour la éviter les régression.
- ton interfaçage avec l'extérieur ? c'est là que l'intégration entre en jeu avec du mocking (ou des bancs de tests pour des trucs plus physique) mais certaines conditions peuvent être très compliquées à simuler
- ton UI ? Arf, là c'est quand même bien la merde à tester automatiquement. Surtout que la grande majorité des technos forcent à écrire les tests à posteriori (donc au revoir le TDD) et sont chiant à maintenir

Se passer de tests manuels est pour moi un erreur car un bon testeur ne fait pas que passer un bêtement un cahier de recette. Normalement il challenge ton ergonomie et cherche les conditions à la cons qui font remonter les cas limites (qui peuvent potentiellement être testés automatiquement plus tard une fois découverts).
De mon point de vue c'est quelqu'un qui doit être externe à l'équipe de dev et qui doit rédiger lui même le contenu des tests en se basant sur la spec (ce qui permet déjà de vérifier si elle même tient la route).
Par contre ça impose quelques contraintes en terme d'organisation des releases.

Les reviewers peuvent aussi tester un peu manuellement les fonctionnalités, mais cela ne permet pas de détecter les effets de bord et les régressions sur les autres fonctionnalités, là où une passe par la QA en fin de sprint permet de tout valider.

Envoyé par gros_bidule

-- tout faire dans BitBucket, Gitlab ou bien récupérer la branche et regarder le diff dans son IDE (à titre perso je préfère quand ça commence à causer, ça permet d'avoir le lint de l'IDE, naviguer dans le code et faire des recherches, puis je maîtrise mieux les diff avec - je checkout ça dans un git worktree dédié) / autrement

Dépend surtout de la taille de la merge-request et de la connaissance du code.
Si t'as posé toi même l'archi du projet et qu'il n'y a que quelques modifs (< 20), l'interface web de Gitlab est largement suffisante.
Au delà, une inspection plus poussée via l'IDE aide quand même pas mal en effet.

Envoyé par gros_bidule

-- si plusieurs commits, relire le gros diff ou le diff de chaque commit ? Trop de commits ? Ne pas avoir peur de demander à scinder une pull-request si elle est trop grosse ou si elle part dans tous les sens : même si ça va "embêter" le dev, ça va bcp moins embêter les reviewers, et à terme éduquer le dev

Perso je préfère relire uniquement le diff final, le détail des commits variants beaucoup trop d'une personne à l'autre (pleins de petits commits + vs commit par grosse fonctionnalité).
Par contre je suis d'accord que le scope de la merge-request doit être cadré, mais pour ça faut que la tâche et/ou user-story soit correctement définie dès le départ.

D'ailleurs c'est pas mal d'inclure des templates de merge-request avec des check-list pour forcer les devs à fournir un truc un minimum propre dès le départ.

Envoyé par gros_bidule

- les types de retours : par exemple j'avais un collègue qui faisait PLEIN de retours sur le formatage (genre 30 sur une pull-request, un sur chaque ocurence). Bah c'était chiant, on l'a recadré. A la limite 1 commentaire général pour dire "reformat stp" et voilà. Il faut faire gaffe à comment la review est vécue, ça devient facilement violent, autant pour le dev que le reviewer

+1
Si une règle générale n'a pas été respectée par le dev (convention de nommage, format, et) un seul commentaire suffit.
Par contre ces règles doivent aussi être définie clairement dans la doc (idéalement située dans les sources).

Après pour tout ce qui est formattage, le mieux c'est d'avoir un outil automatique de formattage (au minimum lié à un githook de pre-commit), ça met court aux débats et tout a la même tête.
Bon par contre tous les domaines ne sont pas aussi bien fournis, quand je fais autre chose que du web je pleure de ne pas avoir https://prettier.io/ tellement c'est pratique.

Discussion: Le topic de la programmation MMA Arena: Atlassian VS Gitlab

Outils de la discussion

Règles de messages