El Titi a écrit 3948 commentaires

D'ailleurs personne ne lit Schopenhauer. Un génie probablement

Je vous invite à regarder cette série de vidéo sur le asyncio, asyn/await super bien fichue et qui aborde aussi les lib concurrentes ici:
https://www.youtube.com/watch?v=ijxLs1D9Zjs&list=PL2CXLryTKuwza0Ln5i1tY3RvkadTwPkyF&index=3:

Ca reprend le fond de l'article de Sam dont je n'aime définitivement pas la forme.

La série asynchrone:
https://www.youtube.com/watch?v=AjfSvp6Q-lM&index=1&list=PL2CXLryTKuwza0Ln5i1tY3RvkadTwPkyF

Le cours complet:
https://www.youtube.com/channel/UCIlUBOXnXjxdjmL_atU53kA

Tu n'es pas au courant ? iLife existait bien avant MyLife
Suis un peu le jeu !

Qui mieux que les inventeurs d'Electron pourraient répondre à ta question ?
Du coup, il se sont inspirés de Mozilla pour refaire un truc qui tient la route avec un langage qui ne prend pas l'eau ;-) … Rust et une couche de rouille pour épater la galerie en JS:

https://github.com/atom/xray

Une autre aspect important est aussi la documentation vivante ("living documentation").
Tes tests (le code de test) sont liés à tes scénarios d'exemple. Modifier les scénarios peut casser le code et un changement sur le code est répercuté sur les tests d'intégrations au travers de ces scénarios.

On rompt avec l'écueil de toutes les approche d'ingénierie dirigée par les modèles
et dans lesquels le modèle (qui constitue la spec) sert à générer le code et finit par ne plus être son reflet car on ne remonte plus les changements au niveau du modèle lorsque le code évolue.

Pour en finir avec le sieur, il est beaucoup plus à l'aise sur son terrain de jeu: les TUs et ce petit guide en 4 parties http://sametmax.com/un-gros-guide-bien-gras-sur-les-tests-unitaires-en-python-partie-1/ est une excellente entrée en matière pour ceux qui voudraient s'y mettre en python.

Sachant que pour les test d'acceptation en python (ATDD/BDD) Robot est un excellent complément:
http://robotframework.org/

Et pour ceux qui voudraient mieux comprendre cette approche en double boucle (à la old school sans framework ça marche aussi) un exemple en java très instructif:
https://www.infoq.com/articles/atdd-from-the-trenches

C'est la où tu méprends légèrement.
Tu confonds les DSL (Domain Specific Languages) textuels/graphiques et les autres langage plus généraux( UML & Co) avec le BDD.

Le principe du BDD est juste de s'appuyer sur une idée de bon sens que tout le monde applique de lui-même.
"Un exemple vaut mieux qu'un long discours".

Le livre fondateur:
https://www.amazon.com/Specification-Example-Successful-Deliver-Software/dp/1617290084/ref=sr_1_1?s=books&ie=UTF8&qid=1455777095&sr=1-1&keywords=specification+by+example

La syntaxe Gherkin (Given … When… Then… qui ressemmble étrangement au AAA -Arrange Act Assert d'un TU digne de ce nom au passage d'ou des frameworks TU à la http://spockframework.org/) est simplissime et n'est absolument pas ogligatoire pour faire du BDD.

Voici par exemple 2 frameworks qui ne requièrent pas l'usage de Gherkin et laissent exprimer les scénarios d'exemple au format libre (ce qui n'exclue pas des conventions dans une équipe)
https://gauge.org/
http://concordion.org/tutorial/java/markdown/

Et comme illustré dans un autre lien pointé plus haut (example mapping session) ce qui est demandé au client (et en collaboration avec lui) c'est juste de déterminer les exemples (les titres des scénarios). Le travail d'écriture des scénarios textuels et leur implem est laissé à la main de la dev team. Il sera demandé au client de relire ces scénarios (facilement compréhensibles pour le coup) et d'en rediscuter s'ili reste des zones d'ombres. Chaque acteur du projet (PO, QA et dev) appréhende du coup le métier plus précisément selon sa perspective.

Les articles de Sam sont en général très intéressants, mais dans le cas présent j'ai comme un"léger" doute sur sa bonne foi … ou ses compétences.

Le monsieur a sorti des exemples jouets tirés des frameworks qui évidemment ciblent des cas facilement implémentables sous forme de test unitaires alors que les tests concernés par le BDD sont en général des tests d'integration ou end to end (boîte noire) .

Visiblement beaucoup de concepts lui ont échappé dans le BDD et en particulier sa finalité qui est avant tout de récupérer des bonnes specs tirées d'exemples, ce qui permet de mettre tout le monde autour d'une table (les 3 amigos, "product owner", testeurs et devteam https://cucumber.io/blog/2015/12/08/example-mapping-introduction )
et de parler dans le langage du client (ubiquitous language). Ceci se retranscrit jusque dans le code et l'archi (Domani Driven Design)
https://blog.xebia.fr/2009/01/28/ddd-la-conception-qui-lie-le-fonctionnel-et-le-code/

Les tests autos ne sont qu'un "effet de bord" de l'approche
Il oublie allègrement la double boucle BDD (tests d'acceptation et TUs en même temps que le code) et en déduit que c'est de la merde parce que dans SON taf il n'en pas besoin. Un bel homme de paille en python
http://coding-is-like-cooking.info/2013/04/outside-in-development-with-double-loop-tdd/

Bref pour reprendre son ton cynique: "Il dit de la merde et ferait mieux de pas l'ouvrir sur tout et nimportnawak". Un tampon "Gros boulet" qui se perd

Définis-moi "historique".

Est-ce qu'un nom et une adresse mail doivent en faire partie et être figés ?

Un id utilisateur n'aurait pas suffit ? (comme ça on peut se marier et changer de nom, de pseudo,
changer de boite mail, et rester l'auteur … la vie quoi

Ca fait marrer de voir des tartines pour justifier une erreur de design. Cargo cult detected

Je ne vois pas en quoi c'est compliqué pour l'avoir déjà fait avec du BFG.
https://help.github.com/articles/removing-sensitive-data-from-a-repository/
Et heureusement, quand tu laisses echapper des passwords dans le code …
Pour les liens avec les "issues" tu perds la trace de qqs commit mais bon.

Après c'est sûr que c'était une super idée de hasher le user.name et mail dans le code alors qu'on peut signer ses commits autrement.
https://fiat-tux.fr/2018/04/21/signer-ses-commits-git-et-transferer-son-gpg-agent-sur-un-serveur-distant/

(Hg is dead :()

On ne voit pas ce projet dans l'agenda.
Quand est-t il présenté ?

Merci

Ah merdouille ! BLOUB

Pas d'objection pour moi à ce qu'on supprime le post

Je propose un nouveau fork du gestionnaire de version Git épuré de la commande rebase qui n'autoriserait éviterait de supprimer du code embryonnaire.

trump reset --hard origin

Pour mémoire:

Origine du nom

Le magazine PC World nous apprend que « quand on lui a demandé pourquoi il avait appelé son logiciel “git”, qui est à peu près l'équivalent de “connard” en argot britannique11,12, Linus Torvalds a répondu “je ne suis qu'un sale égocentrique, donc j'appelle tous mes projets d'après ma propre personne. D'abord Linux, puis Git.”13 ».

https://fr.wikipedia.org/wiki/Git

Sympa comme petit script.

Je n'ai pas encore eu le temps de le tester mais en survolant ton code et sauf erreur de ma part, si un fichier se retrouve plusieurs fois avec le même nom dans l'arborescence initiale, tu le téléchargeras autant de fois et la dernière version écrasera les précédentes.

Il serait pas mal de détecter ces doublons en stockant un dir de tous les noms et le cas échéant hasher les fichiers et s'ils sont différents et introduire ce hash dans le nom du fichier.

Ou alors peut-être une option pour refléter l'arborescence du serveur …

On va voir ce que le format va donner…

Mais, mais …
Quel est-ce laconique commentaire. ?

Où sont passées les envolées lyriques sur les performances médiocres du format VP8 qui bouffe la bande passante vs H.264 utilisé par toute l'industrie, y compris niveau hard.
Où sont passée les attaques de la pseudo libriste "Mozilla Foundation" qui défend un format libre de droit, comme une vulgaire poudre aux yeux alors que les brevets auxquels ils sont soumis le rendent caduque ?

Qu'on me rende Zenitram, là, maintenant … DLFP is dying !

Nous vivons dans un monde où selon ce que tu es prêt à peux payer, tu n'auras pas la même espérance de vie (alimentation, santé) ; poussons le cynisme jusqu'au bout !

Poussons le cyniMSe encore plus loin

J'fais des trous, des ptits trous encore des ptis trous

….
pom pom pom pom
ver ver ver ver

Et on m'mettra dans un grand trou
Où j'n'entendrai plus parler d'trou, plus jamais d'trou

Le "Bronson de Hawking" est une particule physique élémentaire découverte le 30 août 2003 et dont la réalité s'impose à nous régulièrement contrairement au Boson de Higgs

En fait le mobi et l'epub sont des doublons du pdf et ne s'ouvrent donc pas.
Il ne faut pas en tenir compte et la page de download s'avère finalement complètement fiable.
Ultime correction appliquée ;-)

Place à l'humour noir !

Corrigé Merci !

PS: Ca me fait tout bizarre de t'écrire ça ;-)

La version finale tient compte des fichiers qu'on ne peut pas récupérer en free et de toutes les exceptions.
Elle produit un petit rapport :

--------------> Total books count: 233
--------------> Total files count: 655
--------------> Total epub files count: 211
--------------> Total pdf files count: 233
--------------> Total mobi files count: 211

655 fichiers répartis dans 233 ebooks.
Tadaaa :)

A la réflexion, j'ai simplement rajouté une ligne et modifié le code pour tenir compte de cette exception :-)

Salut Nils !

Merci pour ton feedback.
Ceci provient du fait que je parse la page de download pour chaque ebook (?download=true) pour connaître les formats disponibles et éviter des 404 en récupérant tous les formats.
Visiblement, ce n'est pas fiable, car la page que tu m'indiques ne montre que le format pdf alors que les 3 sont disponibles.
J'ai republié le code pour ne plus parser cette page et tenter tous les formats.
Du coup l'execution est à peine plus longue car on va se prendre les 404 de tous les formats absents.

Pour les categories je l'avais remarqué. C'est pour ça que j'ai mis en #todo que j'aimerais récupéré toutes les catégories dans la balise "topic" :-)

PS: Ton blog est très sympa

Je l'ai déjà posté un peu plus haut mais en libre tu as, entre autres: Eclipse Che
https://www.eclipse.org/che/
qui a le bon goût d'être supporté par un concurrent de Cloud9: CodeEnvy

Cloud9 met à dispo du code source mais rien qui puisse permettre d'installer leur plateforme complète facilement en auto-hebergé ou en hosted dans une boîte par exemple.

Sinon le concept est vraiment sympa car tu peux démarrer from scratch sans installer tous tes plugins (tu as des templates en fonction des technos). Toute ton équipe bosse avec la même config et le must est quand même conjointe sur un même fichier. Le pair programming à distance c'est le top. Par contre je n'ai jamais essayé que sur des tous petits projets …
Pour Cloud9 par contre tu es assez lié à Github en terme d'intégration sauf à en passer par la ligne de commande

Clairement les IDEs cloud sont l'avenir dans les DSI …