Catégorie : développement

Tout ce qui concerne le développement en général, que ce soit des choses générales, ou des choses bien précises. Cela va de la gestion de projet à la recherche du fonctionnement de pointeurs en C.

Python : EAFP vs LBYL

Très souvent vous pouvez avoir deux styles de codes différents qui font la même chose en Python :


import os

if os.path.exists("fichier.txt"):
    os.unlink("fichier.txt")

import os
try:
    os.unlink("fichier.txt")
except OSError:  # levé si le fichier n'existe pas
    pass

Alors, lequel choisir ?

Personnellement, j’ai toujours préféré le premier choix, et pourtant… dans la documentation officielle, ils le déconseillent !

Pourquoi cela ? Explication : l’opposé de EAFP, c’est LBYL.

EAFP : Easier to ask for forgiveness than permission

Plus facile de demander pardon que la permission. Ce style de codage très utilisé en Python suppose l’existence de clés ou d’attributs valides et intercepte les exceptions si l’hypothèse s’avère fausse. Ce style propre et rapide se caractérise par la présence de nombreuses déclarations try and except. La technique contraste avec le style LBYL commun à de nombreux autres langages tels que C.

LBYL : Look before you leap

Réfléchir avant d’agir.

Ce style de codage teste explicitement les conditions préalables avant d’effectuer des appels ou des recherches. Ce style contraste avec l’approche EAFP et se caractérise par la présence de nombreuses déclarations if.

Dans un environnement multi-thread, l’approche LBYL peut risquer d’introduire une condition de concurrence entre « la vérification » et « la validation ». Par exemple, le code : if key in mapping: return mapping [key] peut échouer si un autre thread supprime la clé du mappage après le test, mais avant la recherche. Ce problème peut être résolu avec des verrous ou en utilisant l’approche EAFP.

Django et git : bonnes pratiques / idées pour faire du CI

Conseil d’un ami :

  • gitlab n’est pas 100% opensource, ils proposent une édition communautaire limité et la totalité des fonctionnalités est dispo avec la version entreprise, leur modèle économique c’est de brider la version CEE (community) dans pas mal de coin pour te pousser à prendre une licence, perso je trouve que c’est plus un freeware qu’autre chose
  • gitlab est pas mal mais honnêtement pour l’avoir beaucoup (vraiment beaucoup) utilisé dans le passé ce n’est pas la meilleur alternative.

Si tu cherche à mettre en place un truc je te conseille fortement de jeter un œil à :

Cette stack est un peu plus compliquée à mettre qu’un gitlab, mais c’est très puissant, surtout la partie gerrit qui transcende la manière de faire des revues de code.

Si le code Django / Python n’est pas correct, il y a des méthodes pour améliorer les choses notamment :

  • https://nvie.com/posts/a-successful-git-branching-model/
  • https://semver.org/

Il est également important de mettre en place un système de « core developer » même au sein d’un projet privé en entreprise, afin de garantir la cohérence des données et l’intégrité de l’historique. En effet, si tout le monde à les droits d’écriture sur tout, ça finira toujours à un moment donné à partir dans tous les sens… L’idée, c’est de donner les droits d’écriture à seulement 2-3 personnes de confiance qui ont un certain niveau et à tous les autres imposer de faire des forks dans leur namespace gitlab et de proposer des merge request (l’équivalent des pull requests avec github). Ainsi, la revue de code est obligatoire et il n’est plus possible de merger du mauvais code… et les développeurs « standard » (sans droits donc) ont juste 2-3 commandes de base à connaître pour bosser avec les autres. Sans ce genre de système cela ne peut pas réellement fonctionner car git à été developpé pour ce mode de fonctionnement (au même titre que svn et d’autres gestionnaire de version) et donc son workflow est idéal dans ce cadre.

Fonctionner comme ça m’a permis de :

  1. coder un petit robot qui réagissait au merge requests proposé et donc qui checkait tout un tas de choses automatiquement et qui proposait des commandes si les choses n’allaient pas
  2. responsabiliser les gens de l’équipe en les rendant responsables de leur propre forks
  3. faire monter en compétence l’équipe qui était ultra frileuse à faire du versionning puis au final à pris goût au truc…

J’ai fais des petites formations au début pour leur expliquer l’intérêt et expliquer la sémantique des changement et qu’il est important de penser ses commits de manière propre. Cela permet :

  • dans certains cas de retirer (revert) des bugs complet d’un seul coup,
  • de faire du debug de manière automatique sans rien toucher et de trouver les changements responsable d’un bug (git bisect),
  • de faire un gain énorme de qualité au final
  • d’avoir des historiques clairs avec des messages de commit ayant une réelle plus value (exemple)
  • d’automatiser tout un tas d’actions qui vont augmenter la qualité globale du projet et vont réduire les taches inutiles et donc laisser plus de temps pour les trucs fun à faire.

C’est gagnant gagnant, mais au début les gens râlent… il faut juste s’y préparer et avec le temps ils changent d’avis !

Utiliser Chrome pour imprimer / générer un PDF

Google Chrome a plein d’options cachées en ligne de commande, et parmi celles-ci, une option qui permet d’imprimer en PDF.
De plus, si, comme moi, vous ne voulez pas les numéros de pages / nom de fichier en haut et en bas, il vous faut ajouter l’option --print-to-pdf-no-header

google-chrome --headless --disable-gpu --run-all-compositor-stages-before-draw --print-to-pdf-no-header --print-to-pdf=Bureau/test.pdf file://Bureau/git_book.html

Et vous aurez votre fichier PDF qui sera généré ;

[0730/112224.164336:INFO:headless_shell.cc(615)] Written to file Bureau/test.pdf

Unicode : le minimum absolu que tout développeur doit savoir

Nb : j’ai toujours été très admiratif de Joël Spolsky (créateur de Trello qu’il a revendu $425M) et de ses articles excellents. Il l’a retiré de son wiki mais il est toujours disponible ici, sur Webarchive.

Je me permets de le copier coller, avec de très légères modifications, car il est excellent – cela n’est que mon opinion bien sûr.

Le minimum absolu que tout développeur doit absolument, positivement savoir sur Unicode et les jeux de caractères (aucune excuse !)

Par Joël Spolsky

Vous ne vous êtes jamais posé de questions sur cette mystérieuse balise Content-Type ? Vous savez, celle que vous êtes supposé mettre en HTML, et dont vous n’avez absolument jamais su ce qu’elle veut dire ?

Vous n’avez jamais reçu un email de vos amis en Bulgarie avec pour objet  » ???? ?????? ??? ????  » ?

J’ai été atterré de découvrir combien de développeurs ne sont absolument pas au jus à propos du monde mystérieux des jeux de caractères, encodages, Unicode et tous ces trucs-là. Il y a quelques années, un beta-testeur se demandait si le programme pourrait traiter des messages emails en japonais. En japonais ? Ils ont des emails, en japonais ? J’étais même pas au courant. Quand j’ai regardé de près au contrôle ActiveX que nous avions acheté pour parser les messages email au format MIME, nous avons découvert qu’il faisait très exactement ce qu’il ne fallait pas faire avec les jeux de caractères, et nous avons dû écrire du code vraiment héroïque pour défaire la mauvaise conversion qu’il effectuait et la refaire correctement. J’ai alors évalué une autre librairie du commerce, et elle avait elle aussi une implémentation complètement naze des codes de caractères. J’ai contacté le développeur de ce package et il pensait en gros qu’ « ils ne pouvaient rien y faire ». Comme beaucoup de programmeurs, il aurait bien voulu que ce sujet disparaisse de lui même, d’une manière ou d’une autre.

Mais il ne disparaîtra pas. Quand j’ai découvert que l’outil de développement web le plus populaire, PHP, avait une ignorance à peu près totale de ces questions d’encodage de caractères, qu’il utilisait d’une manière insouciante 8 bits pour les caractères, rendant de fait presque impossible le développement d’applications web internationales facilement, je me suis dit « trop, c’est trop ».

J’ai donc une annonce à vous faire : si vous êtes un programmeur, et que vous ne possédez pas les bases des caractères, des jeux de caractères, de l’encodage et d’Unicode, et que je vous attrape, je vais vous punir en vous faisant éplucher des oignons pendant 6 mois dans un sous-marin. Je vous jure que je le ferai.

Et encore une chose:

CE N’EST PAS SI DIFFICILE.

Dans cet article je vais vous donner exactement ce que tout programmeur en activité devrait savoir. Tout ce mélange « texte à plat = ascii = tout caractère est sur 8 bits » n’est pas seulement faux, c’est sans espoir, et si vous êtes encore en train de programmer de cette façon, vous ne valez pas mieux qu’un docteur qui ne croit pas aux microbes. Faites moi le plaisir de ne pas écrire une ligne de code de plus jusqu’à ce que vous ayez fini de lire cet article.

Avant de commencer, je devrais vous prévenir que si vous êtes l’une de ces rares personnes qui savent tout de l’internationalisation, vous allez trouver mon exposé un petit peu trop simplifié. Je veux vraiment juste donner ici un minimum afin que tout le monde puisse comprendre ce qui se passe et puisse écrire du code qui ait un espoir de fonctionner avec du texte dans n’importe quelle autre langue qu’une version d’anglais n’incluant aucun mot accentué. J’attire également votre attention sur le fait que la manipulation des caractères est seulement une minuscule partie de tout ce qu’il faut pour créer des logiciels qui fonctionnent dans toutes les langues, malheureusement je ne peux écrire que sur une chose à la fois, alors aujourd’hui ce sont les jeux de caractères.

Un point de vue historique

La façon la plus facile de comprendre tout ça est d’avancer chronologiquement.

Vous vous dites probablement que là je vais parler de ces très vieux jeux de caractères comme EBCDIC. Hé bien non. EBCDIC n’est pas vital pour vous. Nous n’avons pas à remonter si loin dans le temps.

La table ASCII

Il y a de cela presque longtemps, alors qu’Unix était inventé et que K&R écrivaient Le langage C, tout était très simple. EBCDIC était en train de disparaître. Les seuls caractères qui comptaient étaient ces bonnes vieilles lettres anglaises non accentuées, et nous avions un code pour elles appelé ASCII qui pouvait représenter chaque caractère à l’aide d’un nombre entre 32 et 127. L’espace était le 32, la lettre « A » la 65, etc. On pouvait facilement stocker ça sur 7 bits. Beaucoup d’ordinateurs, à cette époque, utilisaient des mots de 8 bits, ce qui fait que non seulement vous pouviez stocker n’importe quel caractère ASCII, mais vous aviez un bit entier à dépenser, que, si vous étiez vicieux, vous pouviez utiliser pour vos propres besoins déviants: les mous du bulbe de chez WordStar ont utilisé ce bit de poids fort pour indiquer la dernière lettre d’un mot, réellement, condamnant ainsi WordStar aux textes anglais uniquement. Les codes en dessous de 32 étaient appelés non imprimables et étaient utilisés pour les jurons. Je plaisante. Ils étaient utilisés pour les caractères de contrôle, comme le 7 qui faisait biper l’ordinateur et le 12 qui provoquait l’expulsion d’une feuille hors de l’imprimante, et l’aspiration d’une nouvelle.

Et tout cela était bel et bon, tant que vous êtes anglophone.

Parce que ces mots mémoire avaient de la place pour 8 bits maximum, beaucoup de gens se sont mis à penser « Bon sang, on peut utiliser les codes 128-255 pour nos propres besoins ». Le problème, c’est que beaucoup de gens ont eu cette idée au même moment, et qu’ils avaient chacun leur propre petite idée de quoi devait aller où dans cet espace de 128 à 255. L’IBM-PC avait quelque chose qui allait devenir connu comme le jeu de caractères OEM qui fournissait des caractères accentués pour les langues européennes et une brassée de caractères semi-graphiques… Des barres horizontales, des barres verticales, des barres horizontales avec des petites babioles suspendues à droite, etc., et vous pouviez utiliser ces caractères représentant des lignes pour fabriquer d’élégantes boîtes de dialogue et des lignes sur l’écran, que vous pouvez peut être même voir encore tourner sur un très vieux PC dans le pressing du coin. En fait dès que des gens ont commencé à acheter des PC en dehors d’Amérique toutes sortes de jeux de caractères OEM différents ont été imaginés, qui utilisaient tous les 128 caractères du haut pour leurs propres besoins. Par exemple sur certains PC le caractère 130 affichait un é, mais sur les ordinateurs vendus en Israël c’était la lettre hébreu Gimel (ג), ce qui fait que quand des américains envoyaient leurs C.V. en Israël ils étaient reçus comme des « csums ». Dans de nombreux cas, comme le russe, il y avaient beaucoup d’idées différentes de ce qu’ils fallait faire avec les 128 caractères du haut, ce qui fait que vous ne pouviez même pas interchanger de manière fiable des documents russes entre eux.

Cet OEM ouvert à tous finit par être codifié par le standard ANSI. Dans le standard ANSI, on était d’accord sur ce qu’il fallait faire en dessous de 128, qui était vraiment très proche de l’ASCII, mais on gérait les caractères à partir de 128 de plein de façons différentes, selon où on vivait. Ces différents systèmes furent appelés des pages de codes. Par exemple en Israël DOS utilisait une page de codes appelée 862, alors que les utilisateurs grecs utilisaient la 737. C’était la même chose en dessous de 128, mais différent au dessus, là où les lettres rigolotes habitaient. Les versions nationales de MS-DOS avaient des douzaines de ces pages de codes, capables de prendre en compte n’importe quoi de l’anglais à l’islandais , et il y avait même quelques pages de code « multi-langues » qui pouvaient faire de l’espéranto et du galicien sur le même ordinateur ! Houah ! Mais avoir, disons, de l’hébreu et du grec sur le même ordinateur était une impossibilité totale à moins d’écrire son propre programme capable d’afficher n’importe quoi à l’aide de bitmaps graphiques, parce que l’hébreu et le grec réclamaient des pages de codes ayant des interprétations différentes des nombres du haut.

Pendant ce temps, en Asie, des choses encore plus dingues étaient faites pour prendre en compte le fait que les alphabets asiatiques avaient des milliers de lettres, qui ne pourraient jamais tenir sur 8 bits. En fait, la solution trouvée fut un système bordélique appelé DBCS, « double byte character set », le jeu de caractères à double octet, dans lequel certaines lettres étaient stockées sur un octet, et d’autres sur deux. Il était facile de se déplacer vers l’avant à l’intérieur d’une chaîne, mais quasi impossible de reculer. Les programmeurs étaient encouragés à ne pas utiliser s++ et s-- pour se déplacer en avant et en arrière, mais plutôt d’appeler des fonctions, comme les AnsiNext et AnsiPrev sous Windows, qui savaient comment se débrouiller avec tout ce foutoir.

Mais même alors, beaucoup de gens se contentaient de prétendre qu’un octet était un caractère et qu’un caractère c’était 8 bits, et que du moment que vous ne déplaciez jamais une chaîne d’un ordinateur vers un autre, ou que vous ne parliez pas plus d’une langue, en gros ça marchait toujours. Mais bien sûr, dès qu’Internet apparut, déplacer une chaîne d’un ordinateur vers un autre devint un lieu commun, et tout ce merdier se cassa la figure. Heureusement, Unicode avait été inventé.

Unicode

Unicode fut un effort courageux pour créer un jeu de caractères unique qui inclurait tout les systèmes d’écriture raisonnables de la planète et quelques autres fictifs comme le Klingon, également. Certaines personnes sont persuadées à tort qu’Unicode est simplement un code 16-bits où chaque caractère tient sur 16 bits et qu’il y a donc 65536 caractères possibles. En fait, ce n’est pas correct. C’est le mythe le plus commun à propos d’Unicode, donc si vous pensiez ça, ne vous en faites pas.

En fait, Unicode possède une façon différente d’appréhender les caractères, et vous devez comprendre cette façon qu’Unicode a d’appréhender les choses, ou rien ne vous semblera clair.

Jusqu’à maintenant, nous sommes partis du principe qu’à une lettre correspondaient des bits qu’on pouvait stocker sur disque ou en mémoire.

A -> 0100 0001

En Unicode, une lettre correspond à quelque chose appelé un point de code (ou numéro de caractère, ou valeur scalaire Unicode) qui n’est qu’un concept théorique. Comment ce point de code est représenté en mémoire ou sur disque est une tout autre histoire.

En Unicode, la lettre A est un idéal platonicien. Elle flotte dans les cieux :

« A »

Ce A platonicien est différent de B, et différent de a, mais le même que A et A, et A. L’idée que A dans la police Times New Roman est le même caractère que le A dans la police Helvetica, mais différent de « a » en minuscule, ne semble pas tellement sujet à discussion, mais dans certaines langues, se demander simplement ce qu’une lettre est peut entraîner des controverses. Est-ce que la lettre allemande ß est une véritable lettre, ou juste une façon tordue d’écrire ss ? Si la forme d’une lettre change à la fin d’un mot, est-ce une lettre différente ? La langue hébreue répond oui, l’arabe non. Enfin bon, quoi qu’il en soit, les brillants membres du consortium Unicode ont réfléchi à tout cela durant la dernière décennie ou presque, à grand renfort de débats hautement politiques. Vous n’avez pas donc plus à vous en préoccuper. Ils ont déjà pensé à tout.

Toute les lettres platoniciennes de tous les alphabets se sont vues attribuer un nombre magique par le consortium Unicode qui s’écrit comme ceci: U+0645. Ce nombre magique est appelé un point de code. Le U+ signifie « Unicode », et les nombres derrière sont en héxadécimal. U+FEC9 est la lettre arabe Ain. La lettre anglaise A est la U+0041. Vous les trouverez toutes à l’aide de l’utilitaire charmap sous Windows, ou en visitant le site web d’Unicode.

Il n’y a pas de véritable limite au nombre de lettres qu’Unicode peut définir et ils sont réellement allés au delà de 65536, ce qui fait que toutes les lettres Unicode ne peuvent pas tenir sur deux octets, mais de toute façon c’était un mythe, alors…

OK, alors disons que nous avons une chaîne :

Hello

qui, en Unicode, correspond aux cinq points de code :

U+0048 U+0065 U+006C U+006C U+006F.

Juste une poignée de points de code. Des nombres, en fait. Jusque là nous n’avons rien dit sur comment stocker ou représenter ça en mémoire ou dans un message email.

Encodages

Et c’est là que les encodages interviennent.

La première idée pour l’encodage d’Unicode, celle qui a abouti au mythe des deux octets, fut: Hé, on n’a qu’à stocker ces nombres sur deux octets chacun! Hello devient donc:

00 48 00 65 00 6C 00 6C 00 6F

D’accord ? Pas si vite ! Est-ce que ça ne pourrait pas être :

48 00 65 00 6C 00 6C 00 6F 00

Hé bien, techniquement, oui, je pense bien que ça pourrait, et, en fait, les premiers « implémenteurs » voulaient pouvoir stocker leurs points de code Unicode en mode « poids fort derrière » [high-endian] ou « poids fort devant » [low-endian], selon que leur CPU était plus rapide ou plus lent dans l’un ou l’autre, et c’était bonnet blanc et blanc bonnet, et cela faisait déjà deux façons de stocker de l’Unicode. Alors les gens furent obligés d’en arriver à la convention bizarre de placer les caractères FE FF au début de toutes les chaînes Unicode ; on appela ça une marque d’ordre des octets Unicode (Unicode Byte Order Mark) et si vous intervertissiez vos octets de poids faible et fort ça donnait FF FE, et les gens qui lisaient votre chaîne savaient qu’ils devraient intervertir tous les autres octets. Pfff. Et toutes les chaînes Unicode en liberté dans la nature ne possèdent pas cette marque d’ordre des octets au début.

Pendant un moment il semblait que tout cela aurait pu suffire, mais les programmeurs se plaignaient toujours. « Regarde moi tous ces zéros! », disaient-ils, parce qu’ils étaient américains et qu’ils regardaient des textes en anglais qui utilisaient rarement des points de code au dessus de U+00FF. Et puis c’étaient des hippies libéraux en Californie qui voulaient préserver (sarcasme). Si ç’avait été des Texans, peu leur aurait importé de bâfrer deux fois la quantité d’octets. Mais ces mauviettes de Californiens ne pouvaient pas supporter l’idée de doubler la quantité de stockage nécessaire pour des chaînes, et puis, de toute façon, il y avait ces foutus documents, dehors, qui utilisaient tous ces jeux de caractères ANSI et DBCS, et qui allait convertir tout ça ? Moi?  [NdT: En français dans le texte]. Pour cette seule raison, un tas de gens décidèrent d’ignorer Unicode pendant plusieurs années et pendant ce temps les choses empirèrent.

Aussi fut inventé le brillant concept UTF-8. UTF-8 était un autre système pour stocker en mémoire vos chaînes de points de code Unicode, ces nombres U+ magiques, en utilisant des mots de 8 bits. en UTF-8, chaque point de code de 0 à 127 est stocké sur un seul octet. Seuls les points de code à partir de 128 et au delà sont stockés en utilisant 2, 3, en fait jusqu’à 6 octets.

Tout ceci a pour effet de bord très net qu’un texte anglais en UTF-8 ressemble exactement à sa version en ASCII, alors pour les américains il n’y a pas le moindre problème. Seul le reste du monde doit endurer le gage. Pour reprendre notre exemple, Hello, qui était U+0048 U+0065 U+006C U+006C U+006F, sera stocké comme 48 65 6C 6C 6F, ce qui est, le croiriez-vous, exactement comme si c’était stocké en ASCII, et en ANSI, et en n’importe quel jeu de caractères OEM de la planète. Maintenant, si vous êtes assez intrépide pour utiliser des lettres accentuées, ou des lettres grecques, ou des lettres Klingon, vous devrez utiliser plusieurs octets pour stocker un seul point de code, mais les américains ne s’en apercevront jamais. (UTF-8 a aussi cette agréable propriété qu’un vieux code de traitement de chaînes voulant utiliser un octet 0 en tant que null-terminateur ne tronquera pas les chaînes).

Je vous ai déjà indiqué trois façons d’encoder de l’Unicode. Les méthodes traditionnelles « stockez-moi-ça-sur-deux-octets » sont appelées UCS-2 (à cause des deux octets) ou UTF-16 (à cause des 16 bits), et vous devez toujours vous demander si c’est de l’UCS-2 à poids fort derrière [high-endian] ou de l’UCS-2 à poids fort devant [low-endian]. Et puis il y a une autre norme norme UTF-8 qui possède en plus l’agréable propriété d’être respectueuse si vous avez l’heureuse coïncidence de posséder à la fois des textes anglais et des programmes lobotomisés qui ne sont absolument pas au courant qu’il existe autre chose que l’ASCII.

Il y a en fait une poignée d’autres manières d’encoder Unicode. Il y a quelque chose qui s’appelle UTF-7, qui ressemble beaucoup à UTF-8 mais qui garantit que le bit le plus haut est toujours à 0, de manière à ce que si vous devez passer Unicode à travers une sorte de système email totalitaire qui pense que 7 bits c’est bien assez, merci, il pourrait encore se faufiler sain et sauf. Il y a UCS-4, qui stocke chaque point de code en 4 octets, qui a l’agréable propriété que tous les points de code sont stockés sur le même nombre d’octets, mais, bon sang, même un Texan ne serait pas assez intrépide au point de gaspiller autant de mémoire.

Et en fait, à partir du moment où vous vous figurez les choses en terme de lettres platoniciennes idéales représentées par des points de code Unicode, ces points de code Unicode peuvent être encodés dans n’importe quel schéma d’encodage de la vieille école ! Par exemple, vous pourriez encoder la chaîne Unicode pour Hello (U+0048 U+0065 U+006C U+006C U+006F) en ASCII, ou avec le vieil encodage OEM grec, ou avec l’encodage ANSI hébreu, ou avec n’importe lequel des centaines d’encodages déjà inventés, à un détail près : certaines lettres pourraient bien ne pas s’afficher ! S’il n’y a pas d’équivalent pour le point de code Unicode que vous essayer de représenter avec l’encodage que vous utilisez, vous obtenez généralement un petit point d’interrogation: ? ou, si vous êtes vraiment bon, une boîte. Alors, vous obtenez quoi? -> �

© Joël Spolsky

JavaScript : comment surcharger console.log()

J’avais besoin de décaler mes log pour voir rapidement si j’étais, ou pas, à l’intérieur d’une fonction.

Eh oui, après plusieurs années, même si on peut faire des points d’arrêt, JavaScript est là pour répondre à des événements utilisateurs et autres… donc il ne faut souvent pas arrêter pendant l’exécution ou la visualisation d’une page Web… on n’a toujours pas d’autre choix que de faire le bon console.log() des familles qui fait que le développement est extrêmement ralenti…

Je me suis donc crée les fonctions log_in(), log() et log_out().
Ainsi, quand j’entre dans une fonction, j’appelle log_in(), et tous mes log() dans cette fonction seront décalés, ce qui fait que je vois immédiatement où sont appelés mes logs ! Ensuite, ne pas oublier de faire un log_out().

let logLevel = 0;
let log = function () {
    let args = Array.from(arguments);
    if (logLevel > 0) {
        args = [Array(logLevel).fill(' ').join('')].concat(args);
    }
    console.log.apply(null, args);
};
let log_in = function () {
    log.apply(null, arguments);
    logLevel++;
}, log_out = function (s) {
    if (logLevel>0) {
        logLevel--;
    }
    log.apply(null, arguments);
};

Django : comment vérifier si on est en mode debug dans le template

Vous trouverez l’information dans beaucoup de sites, et cela semble très simple : dans votre template, il suffit de faire :

{% if not debug %}Je suis en debug !{% endif %}

En réalité cela ne suffit pas.

Il faut dans votre fichier settings.py, configurer correctement les adresses IP’s qui précisent qu’on est / ou pas / en mode « développement » :

INTERNAL_IPS = ['127.0.0.1', ]

(Notez que ce code peut être largement optimisé et dépendant de l’environnement, par exemple j’ai fait un settings.py qui prend cela en compte)

curl

Curl hints / aide

curl -v -H "Host:www.djangoproject.com" https://www.olivierpons.fr/

Django : faire des pages d’erreur sur mesure (404, 500, etc.)

Lorsque vous voulez faire des pages d’erreur sur mesure, c’est très simple… une fois que vous savez !
En effet, la documentation n’est pas très claire…

Voici un résumé de mon expérience, pour faire des pages d’erreur sur mesure (404, 500, etc.).
Il faut d’abord savoir que les erreurs sont des fonctions appelées (= vous ne pouvez pas le faire via les vues génériques).
Ensuite, la documentation donne un exemple, mais ce n’est pas assez.
Grâce aux raccourcis de Django, vous avez la fonction render() à laquelle vous pouvez passer un template et un contexte (= donc des variables).
Je me suis servi de cela pour créer un dictionnaire qui contient les erreurs, et les passer dans dans le contexte avec la clé title et content.


Voici le code des vues qui affiche une erreur « proprement » :

from django.shortcuts import render
from django.utils.translation import gettext_lazy as _
VIEW_ERRORS = {
    404: {'title': _("404 - Page not found"),
          'content': _("A 404 Not found error indicates..."), },
    500: {'title': _("Internal error"),
          'content': _("A 500 Internal error means..."), },
    403: {'title': _("Permission denied"),
          'content': _("A 403 Forbidden error means ..."), },
    400: {'title': _("Bad request"),
          'content': _("A 400 Bad request error means ..."), }, }
def error_view_handler(request, exception, status):
    return render(request, template_name='errors.html', status=status,
                  context={'error': exception, 'status': status,
                           'title': VIEW_ERRORS[status]['title'],
                           'content': VIEW_ERRORS[status]['content']})
def error_404_view_handler(request, exception=None):
    return error_view_handler(request, exception, 404)
def error_500_view_handler(request, exception=None):
    return error_view_handler(request, exception, 500)
def error_403_view_handler(request, exception=None):
    return error_view_handler(request, exception, 403)
def error_400_view_handler(request, exception=None):
    return error_view_handler(request, exception, 400)


Une fois les vues faites, il faut aller dans la déclaration principale de vos vues. Donc le fichier urls.py qui est la racine de votre projet. Si vous mettez le code ailleurs, il sera ignoré.

Dedans, déclarez vos fonctions qui gèrent les erreurs :

handler404 = 'app.views.errors.error_404_view_handler'
handler500 = 'app.views.errors.error_500_view_handler'
handler403 = 'app.views.errors.error_403_view_handler'
handler400 = 'app.views.errors.error_400_view_handler'

Et enfin, dans vos templates, créez un fichier errors.html dans lequel vous pouvez construire votre page HTML qui gère l’erreur « proprement », avec, en plus dans le contexte, les variables {{ title }} et {{ content }} qui affichent respectivement le titre et le détail de l’erreur.

Maintenant, comment, en mode « développement », tester ces pages ? Dans la pratique vous ne pouvez pas, car en mode développement, une erreur affiche les informations de déboguage, et pas vos pages !
La solution : faire une URL qui « simule » l’erreur. Exemple avec 404 : vous ajouter dans vos urls : path('404/', error_404_view_handler), et puis d’afficher votre URL adéquate, soit http://localhost:8000/404/ et vous verrez l’erreur !

IUT : projet JavaScript – jQuery à rendre le 12 avril minuit au plus tard

A rendre le dimanche 12 avril minuit au plus tard

Au vu des événements actuels, je reporte la date limite de rendu (qui était le 29 mars 2020) au dimanche 12 avril minuit au plus tard


Comment le rendre

Faites un fichier README.txt et déposez-le ici
Dans le fichier README.txt, précisez :

  • l’adresse de votre site
  • un nom d’utilisateur
  • un mot de passe
  • (et plusieurs nom/mot de passe, s’il y a plusieurs niveaux de droits (administrateur/visiteur etc.))
  • si vous avez utilisé des librairies spécifiques que je vous ai autorisées, merci de le re-préciser

Sujet

Ce que vous voulez tant que c’est dans le cadre de ce que l’on a vu. Vous avez tout le Web comme inspiration !
N’oubliez pas de me donner le nom et le mot de passe pour se connecter !
Si vous gérez des profils différents (admin / user ou autre), donnez moi les noms et mots de passe de différents profils !


Fonctionnalités obligatoires

  • Connexion + déconnexion (vu en cours)
  • Effets jQuery sur les éléments
  • Appels JSON : au moins deux appels en plus de ceux vus en cours

Sujets possibles

  1. Site de partage de photos
  2. Site de cocktails (cf ci-dessus)
  3. e-rated : site d’appréciations (selon des sujets, à définir)
  4. Ask-a-question : site où l’on pose des questions sur des sujets divers, et des gens répondent
  5. Write-a-book-together : site où l’on se connecte et où on peut écrire un livre à plusieurs
  6. Wedding-couple-site : site où l’on uploade + partage des photos de mariage + livre de commandes
  7. Playing-cards-collection : site où on scanne + échange des cartes (Magic the gathering)
  8. Polls-and-surveys : site de création de sondages (= QCM, exemple très beau ici : quipoquiz)
  9. Poems-generator : faire un cadavre exquis qui génère des poèmes + possibilité pour les utilisateurs de les noter / d’ajouter des mots
  10. The-future-of-post-it : faire un carnet de choses à faire pour les utilisateurs, qui envoie des mails de rappels de ces choses à des dates données
  11. Gift-ideas : un site où l’on va faire des idées de cadeaux / suggérer des idées de cadeaux + les noter (les meilleurs ressortent en premier)
  12. Le-bon-recoin : refaire le bon coin en plus simple
  13. Suggest-crawlers : site de suggestions : on clique sur un mot, il en suggère plein d’autres avec + définitions / liens de sites pour chacuns
  14. Tv-fans : site de présentations + notes d’émissions télé
  15. Faire le jeu SokoBan vu en cours, avec la possibilité de login, enregistrement. Pour les appels JSON supplémentaires, lorsque l’utilisateur choisit un tableau, s’en souvenir (= AJAX) et lorsqu’il se reconnecte, le remettre directement. Puis enregistrer son score lorsqu’il a terminé un niveau + montrer les meilleurs scores.

Pour les sujets qui suivent, ils sont possibles mais plutôt complexes et demandent plus d’investissement. Si vous êtes motivés, demandez-moi plus d’informations, je vous expliquerai les difficultés que vous allez rencontrer.

  1. Turn-by-turn : faire un jeu multijoueurs en tour par tour (jeu de cartes, de poker, ou de plateau etc)
  2. Chat-with-someone : site de chat/discussion
  3. A-maze-ing : site où l’on peut se ballader dans un labyrinthe et essayer d’en trouver la sortie

Sujet imposé si vous n’avez pas d’idée

Cocktails : on se connecte, on a une liste d’éléments (récupérés en JSON) disponibles, on coche ceux qui nous intéressent, on valide, c’est envoyé, et le retour en JSON affiche les cocktails qu’il est possible de faire avec ce que l’on a coché.


Ce que vous devez rendre

Idéalement

Une Url vers un site Web (utilisez Alwaysdata par exemple)

Si vous n’avez pas le choix

Les fichiers source de votre projet


Pour favoriser votre organisation

Utilisez ce que l’on a vu en cours (Google boilerplate)


Librairies autorisées

Interdiction d’utiliser une librairie JavaScript qui ne vienne pas des sites autorisés précédemment


Retard

Après le dimanche 12 avril minuit

Passé ce délai ce sera 1 pt par 2 heures de retard (je prendrai en compte la date de réception du mail).
Pour ceux qui essaient vraiment d’aller jusqu’à la dernière minute, toute heure entamée est comptée comme une heure complète. Exemple : un point en moins si je le reçois le 3 avril à 00:01.
N’oubliez pas de me donner le nom et le mot de passe pour se connecter !


Copier-coller

  • Copie sur une autre personne (« je se savais pas comment implémenter telle ou telle fonctionnalité dont j’avais besoin pour aller plus loin, je l’ai copiée sur un autre ») :
    • si la personne est clairement nommée : note pour la fonctionnalité divisée par 2 (uniquement la moitié du travail a été faite) ;
    • 0 aux deux personnes sinon ;
  • Si je m’aperçois que vous avez bêtement copié collé des sources Internet, je vous convoquerai pour vous demander de m’expliquer la fonctionnalité, et :
    • si vous ne savez pas m’expliquer le code alors 0 ;
    • si vous savez m’expliquer tout le code alors votre note totale sera divisée par vous + le nombre de contributeurs à ce projet, ce qui se rapprochera certainement de 0 aussi.

Voici un exemple de ce que vous pouvez faire, si vous choisissez le projet cocktails.


PDFs

JavaScript
jQuery