Ads, “unintrusive” or not, are just the visible portion of the privacy-invading means entering your browser when you visit most sites. uBO’s primary goal is to help users neutralize these privacy-invading methods in a way that welcomes those users who do not wish to use more technical means.
On découvre en lisant ces remarques que l’on est démuni. Triste !
Je me permets de revenir sur le sujet à titre pédagogique. Je souhaitais réaliser mon site Web de zéro. Je n’ai pas changé d’avis depuis mon dernier commentaire sur la méthode. Je pense que c’est fondamental de partir d’un modèle graphique pour mieux percevoir ce qui change dans l’apparence en fonction de divers aspects. Sinon, on se perd facilement avec la complexité. En bref, je trouve dommage que le choix graphique fluctuant intervienne avec la réalisation effective en CSS. À mon avis, c’est une mauvaise pratique de conception.
À noter : Les images sont placées au-dessus des titres dans la charte graphique du journal en ligne Le Monde. Le problème d’alignement des images ne se pose même plus.
Aucune mention des sources de cette fonction et de pourquoi elle existe. :(
C’est dommage, rien qu’un mot sur ses origines de programmation fonctionnelle aurait augmenter la qualité de l’article.
Je comprends l’exaspération devant la dette technique de tout projet. Malheureusement, un projet commence par créer de la dette pour valider un concept. L’important est d’avoir les moyens de remanier le projet régulièrement, le premier étant les tests fonctionnels comme le dit l’article.
Je privilégie même les tests de bout en bout (end to end). Par définition, les tests unitaires doivent être remaniés avec le code qu’ils testent.
Qu’est-ce qu’un Shell ? Une interface utilisateur pour interagir avec le système d’exploitation. J’ai l’impression que Nushell c’est une interface pour interagir avec un système d’information. En plus, c’est pas encore abouti.
Vous n’avez pas répondu à mon commentaire précédent. Plusieurs choses me font sourciller. Le Shell c’est trop compliqué pour ne pas en rajouter. Voir Affichage des variables.
Intéressant. Le passage sur les paradigmes déclaratif et procédural dans le paragraphe « Construire des usines à gaz » m’interroge fortement, ceci dans plusieurs domaines portant sur divers aspects. Qu’entendez-vous par « infrastructure » ? Brièvement, qu’est-ce que cela représente ?
Je ne peux plus éditer le message contenant le Makefile mais il contient des erreurs. Par exemple, les chemins dans les variables $(objs_tex) et $(objs_svg) sont spécifiés par rapport aux préfixes src/ et svg/ comme src/foo.pdf au lieu de foo.pdf ou bien $(BUILD_DIR)/foo.pdf.
Il me semble que seuls les fichiers générés automatiquement et qui sont plus anciens que les dépendances conjuguées sont effectivement reconstruits (sauf quelconque erreur de ma part dans le Makefile).
Effectivement ta proposition contient pas mal de bonnes idées, J’aime beaucoup ton idée d’avoir les macros en minuscule (et d’autres idées de macros bien sympa), le Makefile parait de suite moins agressif et plus lisible.
Mais il ne sert pas les mêmes objectifs que celui que je propose :
je me suis concentré avant tout ce pour quoi make a été créé, à savoir éviter à tout pris de recompiler ce qui existe. C’est pour cela que beaucoup de variables et macros ont un air plus abstrait (mais j’ai essayé d’expliquer son fonctionnement dans mon article) ;
il résulte aussi de long moment à écrire du LaTeX : la cible view par exemple m’a été très utile pour voir qu’il me manquait une image par exemple. Elle n’est donc pas là parce que le Makefile pourrait défaillir. Pour résumer ce Makefile m’est avant tout destiné;
je trouve qu’il illustre bien les concepts que j’ai expliqués dans mon premier article sur le sujet.
Je vais pas contre renommer ma variable OUTPUT en BUILD_DIR que je trouve plus parlante (dans mes prochains articles, j’ai la flemme de retoucher à celui là).
J’avais essayé de faire preuve d’esprit (pas top !). Mon point de vue est celui d’un novice ayant lu le manuel GNU Make. Je croyais que l’on pouvait améliorer nettement le Makefile à cause de l’aspect redondant ressenti. C’est la seule chose que je capte le mieux en informatique : chercher le style et l’inspiration.
Beaucoup de variables alors qu’il n’y a que peu de règles
Chemins avec une mauvaise consonance (trop significatif) dans des règles (pattern rule) : SVG_EXPORTED_DIR, OUTPUT
Maladresses techniques : default vs. all (.DEFAULT_GOAL), $(SC) vs. $(LATEX), SCFLAGS vs. LATEXFLAGS, [[IMAGES_DIR, SVG_DIR, IMAGES, SVG, OUTPUT, SVG_EXPORTED, DOCUMENTS]] à dépeindre (rentre en mauvaise consonance avec la première remarque). SC n’est pas tellement évocateur comme nom : SVG_PROGRAM. Je n’aurais pas du tout intégré les @echo ou alors dans chaque règle si nécessaire. Je pense que lorsque le Makefile est bien conçu c’est normalement superflu.
C’est difficile de proposer et bien faire les choses. Ci-dessous mon modeste essai (inachevé et approximatif).
Pour ceux qui l’ont raté
On découvre en lisant ces remarques que l’on est démuni. Triste !
Je me permets de revenir sur le sujet à titre pédagogique. Je souhaitais réaliser mon site Web de zéro. Je n’ai pas changé d’avis depuis mon dernier commentaire sur la méthode. Je pense que c’est fondamental de partir d’un modèle graphique pour mieux percevoir ce qui change dans l’apparence en fonction de divers aspects. Sinon, on se perd facilement avec la complexité. En bref, je trouve dommage que le choix graphique fluctuant intervienne avec la réalisation effective en CSS. À mon avis, c’est une mauvaise pratique de conception.
À noter : Les images sont placées au-dessus des titres dans la charte graphique du journal en ligne Le Monde. Le problème d’alignement des images ne se pose même plus.
Je ne saisis pas. Curieux de savoir comment le concept va être explicité. Où se situe l’abstraction ?
Merci de ton retour. Je vais aller consulter les liens et éditer l’article pour ajouter ces informations.
Aucune mention des sources de cette fonction et de pourquoi elle existe. :( C’est dommage, rien qu’un mot sur ses origines de programmation fonctionnelle aurait augmenter la qualité de l’article.
https://en.wikipedia.org/wiki/Fold_(higher-order_function)
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/reduceRight
Je comprends l’exaspération devant la dette technique de tout projet. Malheureusement, un projet commence par créer de la dette pour valider un concept. L’important est d’avoir les moyens de remanier le projet régulièrement, le premier étant les tests fonctionnels comme le dit l’article.
Je privilégie même les tests de bout en bout (end to end). Par définition, les tests unitaires doivent être remaniés avec le code qu’ils testent.
Qu’est-ce qu’un Shell ? Une interface utilisateur pour interagir avec le système d’exploitation. J’ai l’impression que Nushell c’est une interface pour interagir avec un système d’information. En plus, c’est pas encore abouti.
Optimisé pour un serveur. Pas pour un usage desktop et encore moins laptop.
S’il n’y avait que cela… Beaucoup d’utilisation de cat inutiles et des commandes hasardeuses, exemples :
au lieu de :
qui récupère arbitrairement uniquement la seconde adresses IP de la sortie de commande, résultat un utilisateur se pliant de ne voir que son IPv6 :-D
Ce n’est pas quick-tutoriel mais quick-old-and-dirty-tuitoriel :D
Et sinon en graphique il y a baobab un outil bien pratique
Abonnez-vous bien sûr à la chaîne merci.
Vous n’avez pas répondu à mon commentaire précédent. Plusieurs choses me font sourciller. Le Shell c’est trop compliqué pour ne pas en rajouter. Voir
Affichage des variables.C’est pas bien !
Intéressant. Le passage sur les paradigmes déclaratif et procédural dans le paragraphe « Construire des usines à gaz » m’interroge fortement, ceci dans plusieurs domaines portant sur divers aspects. Qu’entendez-vous par « infrastructure » ? Brièvement, qu’est-ce que cela représente ?
Abonnez-vous pour ne rien rater
Beaucoup d’erreurs dans son fichier Docker Compose. Bon, du coup c’est didactique parce qu’il faut corriger.
Je ne peux plus éditer le message contenant le Makefile mais il contient des erreurs. Par exemple, les chemins dans les variables
$(objs_tex)et$(objs_svg)sont spécifiés par rapport aux préfixessrc/etsvg/commesrc/foo.pdfau lieu defoo.pdfou bien$(BUILD_DIR)/foo.pdf.Édition :
Il me semble que seuls les fichiers générés automatiquement et qui sont plus anciens que les dépendances conjuguées sont effectivement reconstruits (sauf quelconque erreur de ma part dans le Makefile).
Bonjour Salim,
Effectivement ta proposition contient pas mal de bonnes idées, J’aime beaucoup ton idée d’avoir les macros en minuscule (et d’autres idées de macros bien sympa), le Makefile parait de suite moins agressif et plus lisible.
Mais il ne sert pas les mêmes objectifs que celui que je propose :
Je vais pas contre renommer ma variable
OUTPUTenBUILD_DIRque je trouve plus parlante (dans mes prochains articles, j’ai la flemme de retoucher à celui là).Salut ephase !
J’avais essayé de faire preuve d’esprit (pas top !). Mon point de vue est celui d’un novice ayant lu le manuel GNU Make. Je croyais que l’on pouvait améliorer nettement le Makefile à cause de l’aspect redondant ressenti. C’est la seule chose que je capte le mieux en informatique : chercher le style et l’inspiration.
C’est difficile de proposer et bien faire les choses. Ci-dessous mon modeste essai (inachevé et approximatif).