Christie Poutrelle a écrit 224 commentaires

  • # Le web, mon ami

    Posté par (page perso) . En réponse au journal La ronde (boucle?) des langages. Évalué à 8. Dernière modification le 13/03/18 à 15:11.

    Vu que je travaille dans le web, je fais la ronde des langages, mais non pas au fil des ans, mais au fil des heures, avec son lot d'immaturité et déconvenue, le monde du web me tuera.

    • Mon expertise: Java (anciennement), PHP (depuis des années)
    • À côté, mais nécessaire: *SQL (si si c'est un langage à part entière)
    • Obligé à cause des autres (TM): TypeScript, JavaScript
    • De mon plein gré sur mon temps perso: Java, PHP, Python, C#

    Et j'en oublie sûrement, je suis amené parfois à intervenir sur toutes sortes de projets, toujours dans le web. Et les stacks sont tellement compliquées que de toute façon, c'est impossible sans être polyglotte.

    À noter que j'ai joué avec C, C++ et Rust aussi, mais à des fins de tests (notamment pour comparer le bytecode généré par les 3) - mais je n'ai pas un niveau assez élevé avec aucun de ces 3 là pour réellement pouvoir en profiter.

    Côté goûts:

    • Je hais: le C, le JavaScript, le Python, et tous les autres langages à typage dynamique (je sais, le C n'en est pas, mais le C est dangereux pour la santé), et encore plus ceux où le monkey patch est possible (franchement, pour tous les adorateurs de Python, désolé, mais c'est plus proche de JavaScript qu'aucun autre langage, mais on en parlera plus tard),
    • J'adore: le Rust, le PHP (c'est un biais, ça reste un langage de merde), le Java, le C#, et tous les langages à typage statique (bien que PHP moderne jouisse d'un typage fort, mais pas complètement statique car les checks sont au runtime, saloperie),
    • J'ai pas d'avis sur tous les autres.
  • [^] # Re: Shame on you.

    Posté par (page perso) . En réponse au journal TapTempo en PHP. Évalué à 2.

    Je t'ai reconnu, monsieur Delphi.

  • # Static ! Ouate !

    Posté par (page perso) . En réponse au journal Portage de TapTempo en PHP. Évalué à 1. Dernière modification le 13/03/18 à 09:17.

    Je vois que tu as fais le choix d'écrire le code sous la forme d'une classique avec que des méthodes statiques: dans l'absolu, le code est plus rapide écrit de cette façon, mais d'un autre côté, ça rend toutes les variables de ton code globales par définition, et donc non testable et sujet à effet de bord.

    La mode dans le PHP actuel (sauf avec Laravel, qui à mon sens n'est pas un framework mais une blague, attention, troll detected) c'est plutôt d'essayer d'aller vers l'immutabilité et de se rapprocher du fonctionnel (pour avoir le moins d'effets de bord possible et améliorer la testabilité du code).

    Ça reste bien entendu très théorique et religieux tout ça.

  • [^] # Re: Ou pas

    Posté par (page perso) . En réponse au journal TapTempo en PHP. Évalué à 2. Dernière modification le 13/03/18 à 09:12.

    Le soucis avec l'entrée standard en PHP, c'est que tant que tu n'as pas de line feed, les fonctions de lecture du flux ne te donnent rien. Je t'avoue que je n'ai pas réellement pris le temps de chercher pourquoi la réponse est dans le commentaire lié plus haut: stty -icanon désactive le buffering de STDIN, j'image qu'il est bufferisé pour des raisons de performance à l'origine (quand on lit le thread Stack Overflow là: https://stackoverflow.com/questions/3684367/php-cli-how-to-read-a-single-character-of-input-from-the-tty-without-waiting-f/3684565#3684565 on se rend compte que c'est bien dans le cas des remote terminals). Dans l'absolu, fread() et stream_get_contents() ici sont équivalents (j'ai testé les deux).

  • [^] # Re: Ou pas

    Posté par (page perso) . En réponse au journal TapTempo en PHP. Évalué à 2. Dernière modification le 13/03/18 à 09:11.

    Pas de fuite mémoire dans celle là

    En théorie c'est facile de faire du PHP sans fuite mémoire, faut éviter les static et les global (EDIT: et fgets apparament).

    par contre si on utilise un autre touche que Entrée, il efface les lignes précédentes du terminal

    Oui en effet, j'ai pas pris le temps de donner un peu d'amour à ce code !

  • [^] # Re: Ou pas

    Posté par (page perso) . En réponse au journal TapTempo en PHP. Évalué à 2.

    Ah c'est marrant, je suis pourtant remonté dans mon historique je l'avais pas trouvé !

  • # Oups

    Posté par (page perso) . En réponse au journal TapTempo en emacs lisp. Évalué à 3.

    Battez la mesure sous votre éditeur préféré

    Dans mon Eclipse, ça ne marche pas. Tu mens!

  • # Et sans le SDK android ?

    Posté par (page perso) . En réponse au journal scrcpy, une appli pour afficher et contrôler des devices Android. Évalué à 2.

    J'ai vu que sur archlinux, il y a package sur AUR - j'ai essayé de l'installer, malheureusement il nécessite tout de même qu'on installe l'Android SDK - est-ce possible de s'en sortir sans facilement en prenant le jar déjà compilé ?

  • [^] # Re: A peu près pareil que le top

    Posté par (page perso) . En réponse au journal Quel IDE pour quel langage. Évalué à 4. Dernière modification le 16/02/18 à 17:02.

    Perso j'utilise Eclipse pour PHP, avec PDT et les PDT Extensions du PDT Extension Group - je suis presque (je dis presque, il manque deux trois petites choses) on-par avec PHPStorm.

    Il n'y a aucun autre IDE Open Source qui arrive à un tel niveau de fonctionnalités qu'Eclipse, que ce soit pour PHP ou tant qu'IDE multi-languages.

    Pour tout ceux qui pensent qu'Eclipse est une usine à gaz lente, ça fait des années que ce n'est plus vrai - ça marche très bien aujourd'hui. Comparativement avec PHPStorm que pas mal de mes collègues utilisent (attention, je ne troll pas, c'est un excellent produit) il y a pas mal de scénarios ou Eclipse est plus stable et plus rapide:

    • très gros projets sur du SSHfs: Eclipse indexe plus rapidement que PHPStorm (parfois même sans le SSHfs tout court),
    • debuggueur XDebug (toujours PHP) sur un système de fichier avec des chemins bizarres et autres liens symboliques: Eclipse ne perd quasiment jamais le contexte là ou PHPStorm parfois n'arrive pas (du tout) à retrouver la source et ne peut lancer les sessions de debug.

    Voilà voilà, je tiens à défendre Eclipse car contrairement à cet espèce de mythe infâme que j'entends partout, il n'est pas plus lent que pas mal d'autres produits. Et il est extrêmement fonctionnel (de plus très configurable).

  • # Merci pour ce partage - mais la doc fouque

    Posté par (page perso) . En réponse au journal Publication de bibliothèques c++ sous licence libre. Évalué à 10. Dernière modification le 15/02/18 à 14:06.

    Merci pour ce partage, je n'ai pas grand chose à y redire sauf que c'est bien. Par contre, un point m'a fait pleurer (histoire de religion, goûts et couleurs tout ça).

    Après avoir remarqué que nous lisions le code même quand une documentation était disponible, juste pour être sûr au cas où la doc serait erronée ou devenue obsolète, nous avons choisi de tout supprimer. Ainsi nous ne perdons plus de temps à lire la doc avant de lire le code

    On dirait un bien mauvais troll.

    Chez nous on dit tout l'inverse, du code qui n'est pas documenté est, à mon avis, du code mort. Quand on tombe sur des milliers de lignes de code sans au moins avoir une doc meta qui explique l'architecture de la solution, sans besoin d'aller dans le détail, on passe notre chemin et on ne considère pas que c'est du logiciel libre, on ne considère que c'est pas du logiciel tout court.

    Dans les milliards de lignes de code qu'on trouve sur internet, comment veux-tu qu'on s'y retrouve si on a pas au moins un synopsis, un motto, une courte description ? Du code sans doc, c'est comme si il était déjà dans une poubelle.

  • [^] # Re: Données personnelles / Smartphone

    Posté par (page perso) . En réponse au journal Résolution pour 2018. Évalué à 2.

    Merci beaucoup pour cette liste, avec F-Droid c'est toujours difficile de séparer le bon du mauvais!

  • [^] # Re: Pas de résolution

    Posté par (page perso) . En réponse au journal Résolution pour 2018. Évalué à 3.

    j'ai eu un compte GMail avant son ouverture officielle, et c'est vrai que c'est super bien ficelé, ce truc. Du coup, c'est difficile de s'en passer. Cependant, comme je n'utilise quasiment jamais aucun autre service de Google

    Tu utilises le pire de tous car grâce aux mails de ta maman, ceux de ton ou ta ou tes partenaires, et ceux de ton ou ta meilleure pote, et à ceux de ton patron, Google connaît l'intégralité de ta vie perso depuis longtemps.

  • [^] # Re: Pas de résolution

    Posté par (page perso) . En réponse au journal Résolution pour 2018. Évalué à 3.

    uBlock Origin, Privacy Badger, Disconnect, Cookie Auto Delete, HTTPS Everywhere, Decentraleyes, Forget that page

    Ça ne sert strictement à rien d'utiliser autant d'extensions pour la privacy, sachant que moulte d'entre elles se croisent et apportent les mêmes features: le result résultat c'est que tu vas ralentir ton browser pour pas grand chose.

    Personnellement j'utilise uniquement uBlock origin et Privacy Badger, ça suffit. Privacy Badger n'est finalement même pas utile car lui même implémente un sous-set d'uBlock - je le garde uniquement car j'aime cette démarche ludique et interactive pour le blocage.

    La plupart des anti-pubs, enfin ceux qui ne sont pas sponsorisés (adblock c'est honteux) bloquent bien plus que simplement les pubs, et se basent absolument tous sur les mêmes listes et donc aboutissent au même résultat, sauf quand ils whitelist volontairement des fournisseurs de pub pour des raisons pécuniaires (hein adblock).

    Une autre fonctionnalité vraiment pas mal de Firefox, c'est les "container tabs" (des onglets d'une couleur différente) qui isolent les cookies, sessions, et site data.

  • [^] # Re: Navigateur

    Posté par (page perso) . En réponse au journal Résolution pour 2018. Évalué à 6.

    Moi ça rame un maximum, les pages ne s'ouvre pas ou alors très lentement.

    C'est étonnant, j'ai un smartphone qui a 4 ans (un Samsung S5 mini+) et j'utilise Firefox depuis toujours - comparé au stock browser Android, il est beaucoup plus rapide, et plante presque jamais.

    Pour info, j'utilise une ROM Lineage (0-google) - peut-être, et même sûrement, les ROM constructeur officielles sont en grande partie responsables des lenteurs.

  • # Puis-je me permettre de tester avec d'autres langages / vm

    Posté par (page perso) . En réponse au journal [Humour] vers un monde différent. Évalué à 4. Dernière modification le 18/12/17 à 15:30.

    [pounard@guinevere] /home/pounard
    >  cat test.c 
    #include <stdio.h>
    ```    int main () {
            printf("%.100f", 2 - 1.8 - 0.2);
            return 0;
        }
    

    [pounard@guinevere] /home/pounard

    gcc ./test.c
    [pounard@guinevere] /home/pounard
    > ./a.out
    -0.0000000000000000555111512312578270211815834045410156250000000000000000000000000000000000000000000000[pounard@guinevere] /var/www/laborange/remote-current-3.x
    > php -a
    Interactive shell

    php > echo 2 - 1.8 - 0.2;
    -5.5511151231258E-17
    php > C
    ``` [pounard@guinevere] /home/pounard
    > node
    > 2 - 1.8 - 0.2
    -5.551115123125783e-17
    > [pounard@guinevere] /home/pounard
    >

  • [^] # Re: Optimisez la clarté de votre code !

    Posté par (page perso) . En réponse au journal Optimisez votre code !. Évalué à 2. Dernière modification le 07/12/17 à 17:25.

    ps : sur un sujet parallèle, faut aussi que je me trouve une bibliothèque php qui permet de générer/lire des gros fichiers XLSX (ou ODS) qui ne souffre pas de fuites mémoire comme PHPExcel (bon outil pour des fichiers pas trop volumineux)

    Utilise https://github.com/box/spout http://opensource.box.com/spout/ c'est très exactement fait pour ça.

  • [^] # Re: Optimisez la clarté de votre code !

    Posté par (page perso) . En réponse au journal Optimisez votre code !. Évalué à 1.

    Ouais en effet, ça paraît logique.

  • [^] # Re: Optimisez la clarté de votre code !

    Posté par (page perso) . En réponse au journal Optimisez votre code !. Évalué à 1. Dernière modification le 07/12/17 à 17:04.

    Par exemple https://github.com/php/php-src/blob/6053987bc27e8dede37f437193a5cad448f99bce/ext/dom/document.c#L1473 (ext-dom) va lire le fichier en entier via https://github.com/php/php-src/blob/6053987bc27e8dede37f437193a5cad448f99bce/ext/dom/document.c#L1352 qui utilise http://xmlsoft.org/html/libxml-parser.html#xmlParseDocument - et là je perds mes petits parce qu'apparemment en interne ça utilise un SAX parser, qui n'est pas donc pas supposer charger le fichier en entier.

    Alors que XMLReader ici https://github.com/php/php-src/blob/6053987bc27e8dede37f437193a5cad448f99bce/ext/xmlreader/php_xmlreader.c#L884 (ext-xml) utilise http://xmlsoft.org/html/libxml-xmlreader.html#xmlReaderForFile et ce n'est pas précisé dans la documentation si il charge le fichier en entier ou non.

    A noter, ça fait longtemps que je ne l'ai pas utilisé, mais à l'époque, utilise XMLReader et XMLWriter m'avait sauvé d'un bon nombre de memory limit exceeded en PHP.

  • [^] # Re: Optimisez la clarté de votre code !

    Posté par (page perso) . En réponse au journal Optimisez votre code !. Évalué à 2.

    En effet (cf https://secure.php.net/manual/en/xmlreader.requirements.php ) tu as raison - peut-être qu'il utilise l'API plus bas niveau que les autres. Je sais que l'API DOMDocument ainsi que SimpleXML sont basée sur la libxml elle aussi - mais eux parsent les fichiers en entier pour les charger. Je me suis donc trompé :)

    Cependant le reste reste vrai, à savoir que XMLReader est basée sur un curseur sur le fichier, et ne le parse pas au complet, de mémoire (à moins que ça ait changé mais ça m'étonnerais) tu peux parser du XML invalide (en théorie je dis bien) avec jusqu'au moment ou tu tombes sur la partie cassée.

  • [^] # Re: Optimisez la clarté de votre code !

    Posté par (page perso) . En réponse au journal Optimisez votre code !. Évalué à 8.

    C'est absolument vrai, il faut toujours éviter les "premature optimization" - cependant, la performance commence toujours par une architecture logicielle claire et pensée en premier lieu pour les performances. Quand on importe toutes les semaines de centaines de milliers de lignes de gros fichiers XML, la mécanique a sérieusement intérêt à avoir été pensée pour dès le départ.

    Par exemple, l'auteur parle de Drupal, et je sais de quoi je parle j'en fais depuis presque 10 ans, et je suis certain que les gens ayant commencé le site ont utilisé les API de Drupal pour injecter le contenu. Cependant, ça devient très vite très compliqué (ça aurait été pareil avec une application Symfony ou Django basée sur un ORM) - où est la barrière que je peux franchir ou pas pour respecter les performances ? Est-ce que j'accepte de contourner les API du logiciel et potentiellement avoir des données obsolète dès leur import (évènements non lancés, listeners non reveillés) où est-ce que j'accepte que ce soit juste lent mais m'assure que tout le monde ai bien sa chance d'intervenir logiciellement au moment de l'injection des donnée ?

    La réponse que j'aurais apporté à ce genre de problématique c'est que bien souvent l'outil de base est mal choisi, et dès ce moment, avant même qu'une seule ligne du logiciel existe, ce choix aurait pu permettre d'éviter d'avoir se poser ces questions là.

    Puis, pour revenir au XML, utiliser du XPath, sérieusement ? Pour des très gros imports, si tu sais ce que tu fais et que tu connais le schéma, il faut mieux utiliser un lecteur séquentiel, comme l'API XMLReader, qui va juste être incroyablement plus rapide et ne pas consommer de mémoire, là où les implémentations basées sur la libxml2 (c'est à dire toutes en PHP, sauf l'API XML(Reader|Writer)) nécessitent de charger le fichier XML intégralement en mémoire, et en profitent pour passer une phase d'autocorrection du contenu (si si, ça le fait, et même plutôt bien).

    Bref, les performances ça se prépare en amont:

    • éviter les optimisations prématurées permet d'éviter de créer des goulots au niveau des caches, et de rendre illisible une API qui aurait pu l'être,
    • penser le design logiciel dès le départ pour être taillé pour notre métier, quitte à rendre plus compliqué et plus lent les tâches annexes moins importantes,
    • bien choisir l'outil de départ,
    • éviter de tomber dans les pièges classiques/cas d'école.
  • # Plutôt à l'aise, même si j'ai un accent atroce

    Posté par (page perso) . En réponse au journal Votre rapport à l’anglais ?. Évalué à 4. Dernière modification le 05/12/17 à 11:24.

    Quel est ton rapport à l'anglais ?

    J'adore lire et écrire en anglais, et j'ai eu des facilités plus jeune car mes parents m'ont fait prendre des cours ludiques dès très jeune, même si eux finalement ne le parlent que très mal.

    Comment as-tu fait pour le parler de façon acceptable ?

    Avoir eu du vocabulaire dès le départ m'a beaucoup aidé, ensuite, faut pas passer par quatre chemins, mon accent est édifiant tellement il est moche et peu fluide, la seule solution c'est la pratique: il faut voyager ou rencontrer des étranger.

    Comment tu fais pour ne pas être stressé avant/pendant un call ?

    Je fais pas, en anglais je suis toujours stressé. La seule façon de me calmer est de très bien connaître le sujet pour ne rien louper des subtilités, non de l'anglais, mais du sujet.

    Est-ce que tu pourrais être dans l'entreprise où tu es aujourd'hui si tu ne parlais pas anglais ?

    En vrai, oui, mais ça serait un gros handicap vu que je contribue à du logiciel libre. Le lire et l'écrire est le strict minimum.

    Est-ce que tu as dû te farcir des séries américaines en VO alors que tu détestes ça ?

    Je ne déteste pas ça, bien au contraire, je regarde tout en VO y compris le Japonais, le Danois, et le Français (et oui un film français en français est de la VO) [note: je ne parle ni japonais ni danois] - ce que j'aime c'est qu'on entend les vraies voix des acteurs. Les voix en doublage ont toujours une sonorité relative "fausse" et je le sens beaucoup. Si je ne comprends pas, je mets des sous-titres.

    Deux avantages ici:

    • avec les sous titres en français, au mieux ça te familiarise avec les sonorités de la langue, et donc tu es moins perdu le jour ou tu l'entends, c'est plus naturel, même si tu ne comprends finalement pas tout;
    • avec les sous titres dans la langue d'origine (et donc une transcription, et non une traduction) ça permet de s'améliorer dans la langue extrêmement rapidement, ça associe le visuel des mots à leur sons, et si tu as comme moi une mémoire visuelle, c'est super efficace !
  • [^] # Re: Ma vie, mon oeuvre

    Posté par (page perso) . En réponse au journal Votre rapport à l’anglais ?. Évalué à 6.

    ne te force pas à avoir un accent Anglais hyper classe, ni à parler vite

    Très clairement, c'est le meilleur conseil jamais donné: tu auras souvent affaire à des "non native english speakers" (sous entendre des gens qui ne sont pas d'origine anglo-saxonne) et qui auront eux aussi un accent imbuvable. Il faut mieux parler en Giblish (Global English - anglais parlé par les non-natifs; c'est aussi connu sous d'autres noms) et focaliser tes efforts sur ce que tu veux dire plutôt que comment le dire.

  • # Dommage que les autres ne fassent pas pareil

    Posté par (page perso) . En réponse au journal Ordinateurs portables Dell sous Linux. Évalué à 0.

    Dommage que les autres ne fassent pas pareil, je regrette vraiment que Lenovo ne permette pas de choisir Linux, du coup j'ai gardé le Windows au chaud dans un coin, ça peut toujours me servir.

  • # Pette question, mais pourquoi (ce n'est pas un troll) ?

    Posté par (page perso) . En réponse au journal Acheter un Thinkpad moddé, première partie. Évalué à 4. Dernière modification le 27/11/17 à 13:11.

    Quid du prix ? Le site est entièrement en chinois, j'avoue que j'ai du mal à me repérer dedans; quels avantages tires-tu d'avoir les anciens châssis avec du matériel neuf à l'intérieur ?

    Par exemple, j'ai un Thinkpad T470 - et OK le prix est probablement plus élevé que sur un modèle équivalent d'une autre marque (genre Asus ou autre) mais en retour j'ai matos qui est proportionnellement plus solide que ses équivalent moins cher (même de bonne marque) et la possibilité d'acheter les pièces détachées (pour remplacer que ce qui casse quand ça casse).

    Est-ce que faire confiance à cette entreprise chinoise du coup fourni les mêmes garanties, ou c'est juste pour faire de l’esbroufe ou que aimes réellement beaucoup plus les anciens châssis ?

  • # +1

    Posté par (page perso) . En réponse au journal A payé. Évalué à 2.

    J'ai donné aussi, peu, mais si tout le monde faisait de même, la fondation n'aurait plus rien à craindre.