manatlan a écrit 1591 commentaires

  • [^] # Re: Coquille dans la doc

    Posté par (page perso) . En réponse au journal Reqman(2), un postman GPL qui utilise de simples fichiers YAML. Évalué à 1 (+0/-0).

    merci!

  • [^] # Re: « de simples fichiers YAML »

    Posté par (page perso) . En réponse au journal Reqman(2), un postman GPL qui utilise de simples fichiers YAML. Évalué à -2 (+0/-3).

    pas le plus agréable à utiliser.

    Avec un bon editeur, avec coloration syntaxique et tutti canti … ça va, au moins pour débuter.
    EN venant du monde python c'est peut être plus naturel d'avoir son éditeur réglé avec l'indentation sur 4 espaces. (pour éviter le mix tab/spaces)

    Après, quand tu as compris … ça va tout seul.

  • [^] # Re: Sympa

    Posté par (page perso) . En réponse au journal Reqman(2), un postman GPL qui utilise de simples fichiers YAML. Évalué à 1 (+0/-0).

    cool …

    n'hésite pas à faire du feedback …
    mon equipe et moi même l'utilisons tous les jours (plusieurs fois par jour !). ça réponds carrément à nos besoins, et j'aimerai savoir si ça réponds aux besoins des autres … sachant que j'ai tout fait pour que ça le fasse … (en me basant sur les concepts postman .. de collections (mais avec des folders/fichiers) et sur les environnements (avec le fichier reqman.conf))

    Nous, on a plus de 2000 tests, avec 500 requests … sur environs 100 apis rests, à travers plusieurs ressources, avec oauth2 flow … qu'on peut jouer et comparer sur 4 environnements différents (du local à la prod). J'ai également 500 tests sur diverses api persos …
    ça marche bien … pour nous/moi.

  • [^] # Re: « de simples fichiers YAML »

    Posté par (page perso) . En réponse au journal Reqman(2), un postman GPL qui utilise de simples fichiers YAML. Évalué à 0 (+2/-3).

    C'est vendredi … et je me retiens … (pas de trolls .. pas de trolls)

    C'est marrant comme les consciences ont évolué … mais qu'est ce que ça prends du temps !!!

    Il y a 20ans, on disait la même chose du python … patati, patata l'indentation …
    Maintenant, c'est complètement acquis …

    Il y a 10ans, le yaml rencontrait les mêmes rancœurs que le python jadis … patati patata l'indentation …
    Et maintenant, en faisant un peu gaffe; on voit que le yaml est vraiment devenu presque le standard au niveau config un peu partout.

    Du coup, on peut penser que dans 10ans … il sera complètement accepté !
    Bref … c'est une good news !

  • [^] # Re: don't be evil he said...

    Posté par (page perso) . En réponse au journal Reqman(2), un postman GPL qui utilise de simples fichiers YAML. Évalué à 1 (+0/-0).

    Tu as raison … Je vais virer ce texte. Ça crée une certaine ambiguïté.

  • [^] # Re: Les cookies

    Posté par (page perso) . En réponse au journal Reqman(2), un postman GPL qui utilise de simples fichiers YAML. Évalué à 1 (+0/-0).

    Les cookies créés lors d'une requête sont conservés et transmis dans les requêtes suivantes (dans la mesure où on reste sur le même domaine, path, etc…) … bref, tout comme une classique session http. (c'est ce que j'appel le "cookie handling"). (Techniqement, ils sont stockées dans la mémoire, lors de la session de test)
    Il n'y a pas (encore) de méthodes spécifiques autour des cookies (je n'en ai jamais vraiment ressenti le besoin). Ces derniers circulent par les headers http in/out. Du coup, le cookie est écrasable (via le header set-cookie, pour ne pas le re-transférer) … et récupérable dans les tests (pour tester).
    C'est minimaliste, certes … maintenant, est-ce suffisant ?! … mais effectivement il manquerait peut être qques sucres syntaxiques pour rendre cela plus facile, sans trop complexifier…

  • [^] # Re:

    Posté par (page perso) . En réponse au journal GUY : un module python3 pour créer des GUI multiplateforme (android aussi!). Évalué à 1 (+0/-0).

    s/pubs/libs/g

  • [^] # Re:

    Posté par (page perso) . En réponse au journal GUY : un module python3 pour créer des GUI multiplateforme (android aussi!). Évalué à 1 (+0/-0).

    Si t'arrives a installer les couches Kivy/bulldozer …

    Le tuto joint ne devrait poser aucun problème … Jusqu'au déploiement sur le play store…

    Chez moi ça marche !

    Maintenant Guy est exactement fait pour les gars comme nous. Python, pk c'est bon … Et HTML/je/CSS pour le front.

    A partir de la tout est possible … Tu peux profiter des 2 eco système et utiliser leurs meilleures pubs.

  • [^] # Re: Petites remarques

    Posté par (page perso) . En réponse au journal GUY : un module python3 pour créer des GUI multiplateforme (android aussi!). Évalué à 3 (+2/-0).

    Il faut forcément faire sois même la lecture du fichier ?

    non, ça c'est une feature pour des cas assez particulier où tu aurais besoin de produire du html dynamiquement.

    J'ai une démo, où j'utilise ça pour générer automatiquement des composants/sfc vuejs, à l'aide de vbuild

    a guy's app serving a vuejs/sfc UI (Play with sources)

  • [^] # Re: Petites remarques

    Posté par (page perso) . En réponse au journal GUY : un module python3 pour créer des GUI multiplateforme (android aussi!). Évalué à 3 (+2/-0).

    merci pour le retour

    l'utilisation de docstring pour le code html est peut être sympa pour les exemples, mais je pense qu'il peut devenir gênant sur des projets de plus grandes envergure car les classes ne sont plus documentables

    Tout à fait … ça a juste un côté très pratique pour "vite faire".
    Pour les plus gros projets : mieux vaut séparer le contenu du contenant

    mon rapide parcours de la documentation ne fa pas permis de trouver un moyen simple de faire le lien entre un fichier de template html et sa classe associée. Il faut forcément faire sois même la lecture du fichier ?

    Non, il suffit de créer un fichier du nom de la classe dans le répertoire "static".

    si tu as une classe

    class MyApp(Guy):
       ...

    --> il faudra un fichier "static/MyApp.html"

    C'est dans la doc, partie "rendering" … mais ça mérite eclaircissement

    le routeur http me semble vraiment simpliste, on ne peut pas faire de routage sur les verbes ou les entêtes http ?

    Ce dernier ne sert juste qu'à offrir une possibilité, coté back, de retourner du contenu par http. (une sorte de hook dans le serveur http de guy).
    C'est vraiment pour faire du spécifique.

    Mais une application guy communique par websocket principalement.

    Dans ce hook http, tu peux tester le verbe http, et réagir ou non.

    la documentation passe beaucoup de temps à toute que tel ou tel chose est un non-sens. Je pense que ça peut rendre la compréhension difficile pour un débutant

    Fort probable!

    il est question de mode serveur la sécurité est gérée d'une manière ou d'une autre ?

    Il y a le minimum ;-)

    Disons, qu'en "mode app" (app/cef), le serveur http/ws n'écoute que sur le localhost (pas en wide/0.0.0.0). Comme c'est dédié à la partie cliente-forcément en localhost) : c'est suffisant. Du coup, impossible de venir interférer sur le serveur à partir d'une autre machine que localhost.

    En mode serveur : il écoute en wide/0.0.0.0, car c'est plus pratique pour venir s'y connecter d'autres machines ;-). Après, si c'est destiné à être hébergé sur un vrai serveur. Tu peux mettre du nginx en front, avec certificats/ssl et co.

  • [^] # Re:

    Posté par (page perso) . En réponse au journal GUY : un module python3 pour créer des GUI multiplateforme (android aussi!). Évalué à 4 (+3/-0).

    Marrant … Je fais aussi du python et du java (jboss/springboot) ;-)
    Mais de là à dire que je fais plus de bug en python qu'en java … non ;-)
    Suffit d'être organiser et d'écrire des tests qui couvrent.

    De grands pouvoirs impliquent de grandes responsabilités.

    Peux-tu développer ?

    Une application guy : c'est en fait une partie serveur (backend), en python … et une partie cliente (frontend), en html/js. Ces 2 là, communiquent ensemble via une websocket. La partie cliente est automatiquement lancé dans un chrome "headless". Le tout, donne l'impression d'une vraie appli. Avec un peu de css/js, tu arrives simplement à donner un look'n'feel d'appli native, et bluffer ton client.

    Bref, c'est du "python pure" (Il faut, evidemment, qques connaissances html/js/css pour faire un GUI décent)

    Ce n'est lié aucunement à java.

  • [^] # Re:

    Posté par (page perso) . En réponse au journal GUY : un module python3 pour créer des GUI multiplateforme (android aussi!). Évalué à 7 (+6/-0).

    guy n'est pas exclusivement réservé au dev d'app android !

    Une même application, marchera tout aussi bien sur windows, linux, mac ou autres. C'est juste une feature supplémentaire que de pouvoir, aussi, en faire un apk/android.

    Accessoirement, côté backend, c'est du python (et pas du java)

  • [^] # Re: infos

    Posté par (page perso) . En réponse au journal GUY : un module python3 pour créer des GUI multiplateforme (android aussi!). Évalué à 3 (+2/-0). Dernière modification le 24/11/19 à 15:33.

    Pour quelqu'un qui débute/bidouille en Python, quelles sont les limitations ?

    Alors, c'est des contraintes plus liées à kivy/buildozer(p4a) qu'à guy. Je n'ai pas trouvé de liste exhaustive de ce qui marche ou ne marche pas. Mais globalement, il y a plus en plus de choses qui marchent ;-)

    Tout ce qui est pure python ne devrait pas poser de problèmes. Tout ce qui utilise des binaires peut être problématique.

    Peut-on en mettre plusieurs (par exemple la géolocalisation) ?

    Tout à fait ! séparé par des virgules.
    J'ai màj la doc pour pointer vers la liste exhaustive d'android

  • # asgi rules !

    Posté par (page perso) . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 6.

    Sans hésiter … Faut partir avec un framework asgi !
    Tom Christie est un (très) bon … et starlette un excellent choix (je l'utilise depuis 2ans).
    Mais faut targetter un python >=3.7. Starlette n'est toujours pas 3.5 compatible.
    Avec les micro tâches … tu peux faire tellement plus de choses, background task, socket, etc … sans sortir l'artillerie lourde (thread/multiprocess …)
    Et c'est tellement plus naturel, que tu gagnes énormément en lisibilité/maintenance.
    L'avenir est clairement ASGI …
    Quant au choix de starlette vs responder … starlette est l'original, responder est une surcouche. Les gars de starlette répondent très vite et bien.

  • [^] # Re: ça me semble parfait pour wuy

    Posté par (page perso) . En réponse à la dépêche minipy, un serveur Python dans son Android. Évalué à 1.

    bon, j'ai réussi, après 3/4h de galères, à faire le tuto pour tester la compilation/installation de l'apk sur l'android.
    Globalement, ça marche …
    (ma plus grosse galère : j'ai du récupérer le répertoire "sources" pour le mettre dans le NDK android (sinon erreur cxx-stl/system) du buildozer)

    mais à l'execution, la webview n'arrive pas à se connecter à la socket (sur xiaomi mi9 uptodate).

    mais c'est le même résultat que l'apk du playstore.
    (est-ce que ça marche chez qqu'un ?)

    Donc, c'est ISO ;-)

  • # ça me semble parfait pour wuy

    Posté par (page perso) . En réponse à la dépêche minipy, un serveur Python dans son Android. Évalué à 1.

    Merci pour ce post assez clair.

    J'édite une couche (https://github.com/manatlan/wuy) qui permet de réaliser "facilement" des GUI sur n'importe quelle plateforme. En utilisant principalement chrome, en mode "app" (un peu comme python-eel, mais en moins buggé).
    Le GUI se fait "facilement", en html/js/css … et wuy propose une couche JS qui permet de discuter facilement avec la partie serveur, via des websockets. Côté serveur, une couche python permet de discuter facilement avec le GUI. Accessoirement, c'est très facile de générer un "exe" pour chaque OS. Mais ça necessite d'avoir chrome sur l'os hôté.
    Alternativement, j'ai fait des tests avec cefpython3, pour embbeded chrome dans l'exe : ça marche à l'identique. (et permet de passer outre la necessité d'avoir chrome sur l'os hôte)

    (accessoirement, avec une couche comme vbuild (https://github.com/manatlan/vbuild), il est très simple d'embedder une appli vuejs en python only)

    J'aimerai porter cette solution sur android. J'ai un peu testé avec buildozer, mais je ne suis pas arrivé à mes fins. (Côté serveur python, j'utilise aiohttp).

    Si je comprends bien, j'aurai 2 options :
    - soit je fais, comme toi, j'utilise kivy, pour réutiliser la webview/android. et je devrai arrivé à m'en sortir avec tes infos . (en remplaçant tornado par aiohttp)
    - soit je persiste et j'essai de buildozer avec cefpython3. (mais ce dernier n'est pas encore compatible android, je crois)

    la soluce 1 me paraît plus simple maintenant …
    SI j'ai des soucis : tu peux m'aider ?

  • # Wuy

    Posté par (page perso) . En réponse à la dépêche mat2, version Web. Évalué à -2.

    Wuy aurait fait l'affaire très bien
    https://github.com/manatlan/wuy

  • # vbuild : webpacker vuejs sans nodejs

    Posté par (page perso) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 10.

    Juste un petit mot pour parler de vbuild qui permet de packager des vues, et de générer du JS … SANS NODEJS (python only)

    Et tu peux même développer tes composants en python, ou en js, et ou les 2… et mixer le tout …

    J'ai fait un outil de démo, pour comprendre :
    https://manatlan.alwaysdata.net/vbuild/

  • [^] # Re: transformer ?

    Posté par (page perso) . En réponse au journal WUY : simple GUI pour python3 ... et taptempo ;-). Évalué à 2.

    En anglais j'aurai dit qqchose du style : which let you turn on your script into gui
    Mon français n'est pas bon ;-)

    Voilà le script originel :
    https://github.com/TapTempo-Federation/TapTempo-python27/blob/master/TapTempo.py

    Il a bien été "transformé" en GUI (cf dans le post en haut)

    NB : la version wuy est plus courte/lisible que la version originelle ;-)

  • # qques vrais exemples

    Posté par (page perso) . En réponse au journal WUY : simple GUI pour python3 ... et taptempo ;-). Évalué à 4.

    J'ai rajouté qques vrais exemples (des vraies app utilisables IRL):

    https://github.com/manatlan/wuy/tree/master/examples

    Dont:

    • un WuyFreezer, un GUI pour freezer son app en standalone executable (marche sous toutes les plateformes)
    • un frontend à 'du' pour chercher les fichiers qui prennent de la place dans son filesystem
    • et le fameux taptempo ;-) (je ne m'en lasse pas, même si perso, j'utilise plutôt la version PWA sur mon smartphone ;-)
  • [^] # Re: mon rêve devient réalité.

    Posté par (page perso) . En réponse au journal WUY : simple GUI pour python3 ... et taptempo ;-). Évalué à 4.

    merci, suis content de donner du rêve ;-)

    Je pense qu'on est plein de dev ayant la double compétence python/html-js. Du coup, ça a du sens que de pouvoir proposer le front en js, avec un back en py3. Avec un framework comme vuejs, on arrive rapido à faire des GUIs balaises.
    Pour ma part, après avoir bien plongé dans les angular/riotjs/vuejs … refaire du GUI classique me semble fade.

  • [^] # Re: Ramivore 6.4

    Posté par (page perso) . En réponse au journal WUY : simple GUI pour python3 ... et taptempo ;-). Évalué à 2.

    J'ai patché … évitons le troll ;-)

  • # you make my day

    Posté par (page perso) . En réponse au journal La programmation concurrente en mode Goto. Évalué à 6.

    Suis abonné aux articles de sam&max …et celui là, je ne l'avais pas retenu (certainement le titre … goto -> au revoir ;-)
    Suis bien content que tu le ramènes ici (surtout un vendredi)

    ça m'a fait découvrir "trio". N'étant pas fan d'asyncio : suis ravi ;-)
    je vais potasser ça

  • [^] # Re: Périmètre différent

    Posté par (page perso) . En réponse au journal Portage de TapTempo en Python (2.7). Évalué à 1. Dernière modification le 28/02/18 à 09:59.

    Je pense que j'aurai passé plus de temps à tenter de le faire s’exécuter, et à comprendre son fonctionnement, que de re-coder "qqchose de similaire"

    Voilà un patch pour s'approcher de l'original :

    print "tapTempo : press any key (q for quit)"
    t=[]
    while getKey()!="q":
        t.append( datetime.datetime.now() )
        ll=[ (j-i).microseconds for i, j in zip(t[:-1], t[1:]) ][-5:]
        if ll: print "BPM:",60000000*len(ll)/sum(ll)
    

    NB: j'ai juste décaler à droite, les 2 dernières lignes

  • [^] # Re: Sans deque ?!

    Posté par (page perso) . En réponse au journal Portage de TapTempo en Python (2.7). Évalué à 2.

    J'ai essayé … mais impossible de faire des slice sur le deque … du coup, faut le reconvertir en list avant les slices ;-(

    Du coup, ça alourdi le code ;-)