Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 88 sur 88 PremièrePremière ... 3878808182838485868788
Affichage des résultats 2 611 à 2 625 sur 2625
  1. #2611
    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.

  2. #2612
    Citation Envoyé par Mr Ianou Voir le message
    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
    une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
    Canard zizique : ?, , Φ, , ¤ , PL, 10h, , , , , , ?, , ?, ? ? ?, ?, ?, , , blues, BOF, BOJV, , ?, ?, 8, ?, ?, ?, 2, 80, ?, , , funk, fusion, ?, , ?, ?, ?, ?, ?, ? , noise, pop, , , $ $, , et ⚑, soul, , ?, (allez là si vous ne voyez pas les miquets)
    Canard lecture

  3. #2613

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

  5. #2615
    Citation Envoyé par Mr Ianou Voir le message
    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.

  6. #2616
    Citation Envoyé par M0s Voir le message
    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...
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  7. #2617
    Citation Envoyé par M0s Voir le message
    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

  8. #2618
    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))
    Dernière modification par Mr Ianou ; 09/12/2019 à 18h29.

  9. #2619
    Citation Envoyé par Mr Ianou Voir le message
    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....
    La programmation est une course entre le développeur, qui s’efforce de produire des applications à l’épreuve des imbéciles, et l’univers qui s’efforce de produire de meilleurs imbéciles... L’univers a une bonne longueur d’avance !!!

  10. #2620

  11. #2621
    Citation Envoyé par Mr Ianou Voir le message
    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 ?

  12. #2622
    Si tu veux documenter tes fonctions, utilise les triple guillemets juste après la signature, tu auras gratuitement l’attribut __doc__.
    une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
    Canard zizique : ?, , Φ, , ¤ , PL, 10h, , , , , , ?, , ?, ? ? ?, ?, ?, , , blues, BOF, BOJV, , ?, ?, 8, ?, ?, ?, 2, 80, ?, , , funk, fusion, ?, , ?, ?, ?, ?, ?, ? , noise, pop, , , $ $, , et ⚑, soul, , ?, (allez là si vous ne voyez pas les miquets)
    Canard lecture

  13. #2623
    @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.
    C'est la faute à Arteis

  14. #2624
    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).
    Dernière modification par gros_bidule ; 09/12/2019 à 22h12.

  15. #2625
    Citation Envoyé par gros_bidule Voir le message
    - 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

    Citation Envoyé par gros_bidule Voir le message
    - 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.

    Citation Envoyé par gros_bidule Voir le message
    -- 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.

    Citation Envoyé par gros_bidule Voir le message
    -- 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.

    Citation Envoyé par gros_bidule Voir le message
    - 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.
    C'est la faute à Arteis

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •