1. Qu'est ce qu'un site web ?

1.1. Nécessité du réseau entre ordinateurs

Il faut revenir aux fondamentaux.

Le rôle d'un ordinateur n'est rien d'autre que de traiter de l'information.
Cette information est enregistrée sous la forme de 0 et de 1 sur des objets physiques (disques durs, bandes magnétiques...).

Très vite, on avait le besoin que les ordinateurs s'échangent des données plus simplement que de devoir déplacer les cartes mémoires d'un poste à l'autre.

C'est ainsi que l'on a relié les ordinateurs ensemble avec des cables électriques pour qu'ils puissent s'échanger des données.
C'est plus ou moins comme cela que l'on schématise Internet : ce sont plein d'ordinateurs reliés ensemble avec des cables.

1.2. Prémices du web

Un jour, les hommes se sont dits que ce serait tout de même chouette si on pouvait afficher les documents d'un ordinateur de façon lisible.
C'est comme ça que le web et que le premier site web est né : l'ingénieur a réussi a afficher le contenu d'un fichier texte sur un ordinateur différent que celui qu'il utilisait.
Les bases sont posées, il ne reste plus qu'à définir tout cela.

* Le serveur : c'est l'ordinateur qui met à disposition les données
* Le client : c'est l'ordinateur qui affiche les données à l'écran

Sur l'ordinateur Client, on utilise un logiciel qui s'appelle un navigateur, il en existe quelques uns dont les plus connus sont sans doute encore aujourd'hui "Google Chrome" (que l'on appelle vulgairement Chrome et non Google car cela désigne déjà le nom du moteur de recherche), "Firefox Mozilla", "Microsoft Edge", "Internet Explorer", "Safari" (commun sur les ordinateurs d'Apple), puis beaucoup d'autres encore comme Opera, Brave...

A ce navigateur, on lui indique l'adresse d'un ordinateur Serveur, cette adresse a le même objectif qu'une adresse postale : localiser un ordinateur sur la carte.
Tous les ordinateurs branchés à Internet ont donc une adresse internet et on les identifie grâce à celle-ci.

Cette adresse est nommée "adresse IP" où le I veut dire Internet et le P veut dire Protocol.

Là où cela devient compliqué pour les hommes, c'est qu'on ne va pas commencé à retenir des adresses IP pour accéder à tel ou tel ordinateur comme on pouvait d'ailleurs le faire avec les numéros de téléphone dans le passé.
Concernant les numéros de téléphone, on utilise des répertoires de noms, à "Maman", tel numéro de téléphone, à "Police", un autre etc...

Pour les adresses des ordinateurs, c'est peu ou prou la même chose sauf que le répertoire est écrits par d'autres personnes que nous.
Ainsi, pour discuter avec le serveur français de Google qui a l'adresse IP 172.217.171.195, on passera par un répertoire général et on lui indiquera google.fr, c'est autrement plus simple.

Nous utilisons donc des noms pour cibler des ordinateurs sur le réseau Internet.

1.3. L'URL, l'adresse des ordinateurs sur le réseau Internet

Un navigateur est spécialisé avant tout pour récupérer des documents web auprès des ordinateurs serveurs. On lui indique l'adresse de ces ordinateurs avec ce que l'on nomme une URL.

Cette URL (ex: https://www.google.fr?q=toto) peut être décomposée en plusieurs bouts :
* https : indique le langage que devront utiliser le navigateur et le serveur pour communiquer ensemble (nous n'avons pas à nous en mêler)
* www : c'est un sous domaine qui veut dire world wide web, ce sous domaine est parfois utilisé et parfois non pour accéder à du contenu web
* google.fr : c'est le nom du domaine
* ?q=toto : c'est une façon de demander au site web des données précises

Lorsqu'on tape cette URL dans la barre d'adresse du navigateur, notre ordinateur communique alors avec un à plusieurs ordinateurs serveurs via le navigateur (c'est transparent pour l'utilisateur).
Ces ordinateurs serveurs vont alors lui retourner la plupart du temps une page, appelée page web.

1.4. Définition d'une page web

Une page web n'est rien d'autre qu'un fichier texte qu'un ordinateur serveur transmet à notre ordinateur client.

1.4.1 Exemple de page de type texte

Rien n'empeche à l'ordinateur serveur de vous afficher le fichier bonjour.html dont le contenu est le suivant :

ceci est une page web


Votre navigateur affichera alors dans ce cas le texte "ceci est une page web".

Je vous vois venir : je n'ai jamais vu une page web comme ça, sur une page web, il y a des couleurs, des images, du texte souligné, barré, gras, italique etc...

Et là je vous répond : effectivement, vous avez l'oeil ! Mais maintenant si je vous questionne à mon tour en vous demandant "Pourquoi et comment ?"

1.5. Pourquoi une page web c'est plus beau qu'un texte en noir et blanc ?

Et bien, d'une part pour se démarquer des autres pages et d'autres parts, il est évident que la page web a une portée plus subliminale avec des images/couleurs et autres animations qu'une simple page en noir et blanc.
Et donc, on peut vous vendre des produits.

2. Correspondances entre les différences versions WIFI

Voici la liste des principales normes Wifi et leur nom commercial, qui est plus pratique pour s'y retrouver :

802.11b  - Wifi 1 - 2,4 Ghz          - 2000
802.11a  - Wifi 2 - 5   Ghz          - 1999
802.11g  - Wifi 3 - 2,4 Ghz          - 2003
802.11n  - Wifi 4 - 2,4 Ghz et 5 Ghz - 2006
802.11ac - Wifi 5 - 2,4 Ghz et 5 Ghz - 2014
802.11ax - Wifi 6 - 2,4 Ghz et 5 Ghz - 2021
802.11be - Wifi 7

3. L'IP locale sous toutes ses formes


Il existe plusieurs moyens de noter une IP locale :

localhost
127.0.0.1
127.1
2130706433
0x7f000001
0x7f.0.0.1


3.1. La valeur 2130706433

La valeur 2130706433 est étonnante au premier abord mais ce n'est rien d'autre que la notation en base 10 (ie. nombre entier) de l'IP locale.

Une IP V4 classique va de 0.0.0.0 à 255.255.255.255, ce qui fait 4294967296 combinaisons (256^4).

Démonstration :

127.0.0.1 = 127*(256*256*256)+0*(256*256)+0*(256)+1 = 2130706433


3.2. La valeur 0x7f000001

La valeur 0x7f000001 peut s'écrire 7F 00 00 01, 7F étant la représentation hexadécimale de 127.

3.3. Quasiment toutes les 127.*.*.* sont locales.

Que ce soit 127.1.1.1, 127.255.1.112, ou quasiment tout ce qui commence par "127." pointe vers le localhost.

Seules certaines valeurs comme 127.0.0.0 ou 127.255.255.255 ne fonctionneront pas.

4. Le nitpicking


Parfois, on peut croiser le mot "nit" dans les pull requests de github.

Le mot "nit" est l'équivalent anglais du mot "lente".
La lente est l'oeuf du pou.
"Faire du nitpicking" revient donc à l'expression française "Chercher des poux dans la tête de quelqu'un".

Dans le cas d'une revue de code, on peut appeler nitpicker quelqu'un qui fait des commentaires sur des lignes non forcément pertinentes dans le fond (ex: relever une faute d'orthographe dans un commentaire).

Lorsque le relecteur pense lui même que son retour ne changera pas la face du monde, il peut commencer son commentaire par le mot "nit:". Ainsi, il est plus facile pour le codeur de filtrer les "bons retours" (ie. ceux sur le fond) des mauvais.



📖️️Source : https://en.wikipedia.org/wiki/Nitpicking


5. Pourquoi du private, du protected et du public ?

5.1. Les différences entre les visibilités

Alors, déjà il faut bien comprendre la différence entre les trois :
* lorsqu'un attribut ou une méthode d'une classe est private, seule l'instance de la classe peut y accéder ;
* lorsqu'un attribut ou une méthode d'une classe est protected, seules les instances de la classe ou des classes qui en héritent peuvent y accéder ;
* lorsqu'un attribut ou une méthode d'une classe est public, tout le monde peut y accéder, mère fille tonton tata... ;

5.2. En pratique : dans le doute, tout mettre en visibilité private.

En sécurité, on a une petite phrase qui revient assez souvent qui est "On interdit par défaut, et on autorise au cas par cas".

Et bien, dans une classe PHP, on peut tout à fait appliquer le même principe : tout déclaré privée et dans le besoin augmenter la visibilité.

5.2.1 Pourquoi pas tout en public ?

Lorsque tout est en public, on ne se pose pas vraiment de question, mais on ne contrôle plus très bien les choses.

Par exemple : si les attributs sont en visibilité public, rien n'empêche un autre développeur de mettre à jour leurs valeurs directement.

Mais si vous souhaitez faire autre chose au moment de l'affectation d'un attribut, par exemple contrôler que la nouvelle valeur corresponde aux règles métiers ? Et bien cela devient compliquer car il faudra repasser à tous les endroits où l'attribut est modifié pour ajouter le contrôle. Pire : si la modification de l'attribut passe par une méthode magique, cela devient très compliqué.

Si les attributs sont par défaut en visibilité private, vous maitrisez leurs changements de valeur via des méthodes qui sont publiques de type setAttribute($value).

C'est la même chose pour les méthodes, si elles sont en visibilité private par défaut, c'est lorsqu'on n'en aura besoin dans une autre classe que le besoin de la passer en public sera "peut-être" légitimé.

Bien sûr, avec le temps, on finit par mettre certaines méthodes directement en public, par exemple ce qu'on nomme les setters et les getters.
Mais pour d'autres méthodes, cela est plus prudent de les passer en visibilité private.

5.2.2 Et le protected ?

Quant au protected, cela est pratique d'y penser dès que l'héritage s'avère nécessaire (ex, on souhaite enrichir une librairie avec notre propre code).

Deux cas de figure se présentent alors :
* si la classe que vous créez a pour vocation d'être partagée avec d'autres membres de votre équipe de développement, il faudra bien réfléchir à la visibilité de chaque méthode (au pire, une Merge Request du développeur concerné vous demandera de faire une modification).
* si la classe que vous créez a pour vocation de rester dans votre projet, la réflexion autour de la visibilité est déjà moins impactante.

Dans les deux cas, une conception approfondie et un merge seront vos meilleures armes.

5.2.3 Ordre des déclarations

Il n'est pas évidenl Ô Ô;t de se rappeler s'il faut écrire

public static int $valeur;
OU
static public int $valeur;
OU
static int public $valeur;

Pour se rappeler que la visibilité est toujours indiquée en premier, il faut se mettre à la place de l'interpréteur : si l'attribut est private, il n'est peut être pas nécessaire de savoir le reste (static/type/valeur).

6. Pourquoi les certifications c'est commercial ?

Qu'on se le dise : ce n'est pas parce que vous avez une certification en informatique dans une technologie que vous êtes un expert dans cette technologie et l'inverse est certainement vrai : ce n'est pas parce que vous vous êtes autoproclamé expert (souvent lié avec le nombre d'années, ou même de mois dans les sociétés de service) que vous arriverez à avoir une certification. Autrement dit, la connaissance et l'expérience peuvent être dans ce contexte deux choses bien différentes.
Une certification n'a a priori qu'un seul intérêt : prétendre auprès de vos clients et/ou employeurs que vous avez une valeur validée par un tier légitimé par la paternité de la technologie ou par divers accords entre la société de formation et l'auteur de la technologie. Sauf qu'un étudiant ou même un jeune salarié qui aura passé une certification ne dupera personne : il n'a pas assez d'expérience professionnelle, il sait juste de manière ultra théorique tout ce qui concerne une technologie, ce qui est en soit très bien mais pas suffisant. A contrario, ce n'est pas parce qu'un professionnel ne connait pas toutes les subtilités d'une technologie qu'il sera inefficace, et ce pour deux raisons :

* la première est qu'internet est un moyen extrémement efficace pour trouver une solution à ses problèmes ; certes, cela peut des fois -dramatiquement- être un copier/coller d'un message venant de stack overflow ou tout simplement provenant de la documentation officielle de la techno, dans ce cas-là, le développeur aura de toute manière dépassé le problème et utilisé la technologie de la bonne manière (ie celle qui a été pensée lors de la conception de celle-ci).
* la seconde est que si cette subtilité est inconnue du professionnel expérimenté, c'est bien parce qu'elle l'est : subtile, il est certes très riche pour l'esprit de connaitre les tréfonds d'une technologie, en attendant, si cela ne sert dans la majorité des cas à rien, c'est une forme de temps perdu. Cependant, non seulement il n'est pas nécessaire de payer un organisme quelconque pour obtenir un A4 qui valide que l'on a bien potassé par coeur, en quelques dizaines d'heures tout au plus, toutes les signatures de fonctions, et à contrario, il est bien plus plaisant de s'instruire sur la technologie sans la volonté de passer un examen, l'employeur/le client n'aura pas de problème à le détecter et il pourrait appeler ça une passion.

Ainsi, un développeur passionné, ce n'est pas un développeur qui passe des certifications pour prétendre que c'est le meilleur (d'autant qu'un bon développeur ne se résume pas à un bon écrivain), c'est un développeur qui s'instruit par Plaisir, et ce plaisir, lorsqu'il arrive à le transmettre (le plaisir ET la connaissance induite, sinon c'est juste du domaine de l'Eros), cela profite à tout le monde.

En bref, rien ne vous empeche de vous former à une certification sans la passer. Non seulement, vous n'aurez pas la pression inutile d'un examen (la plupart du temps sans internet, ce qui est assez ironique), mais en plus vous allez acquérir des connaissances d'une façon extrèmement saine, de plus vous allez surement apprendre des choses qui vous seront surement plus utiles dans le cadre de vos projets.

D'autant que non seulement l'organisme en question va profiter économiquement de cette situation mais en plus cela va le pousser à mettre à jour sa technologie pour aller dans ce sens, et donc d'apporter des nouveautés la plupart du temps complétement superficielle dans sa technologie (ex: du sucre syntaxique, du déplacement de répertoire, un changement de nommage, d'arguments etc...).

On peut se donner des exemples et débattre sur les récentes modifications de SF3, puis SF4, puis SF5 pour s'accorder sur le fait qu'à part faire des mv dans tous les sens,tout était déjà possible sans trop de difficulté avec SF2.8 (la différence entre la 1.4 et la 2.0 justifierait par contre une différence notoire d'appréciation des deux certifications correspondantes).


7. Code écologique

7.1. Qu'est ce que le code le plus écologique ?

C'est un peu paradoxal, mais le code le plus écologique qui soit est souvent celui qui n'existe pas.

Car, s'il n'existe pas, on fait plusieurs économies :
* Economie de développement (cerveaux qui chauffent, IDE qui tourne, partages sur un gestionnaire de version (GIT, SVN etc...))
* Economie de tests automatiques (jenkins, gitlab CI, scrutinizer, tous ces trucs qui s'executent à chaque fois pour controler votre code)
* Economie de déploiement (la compression, l'envoi, le controle de sécurité, la décompression, l'installation (composer install, clear cache etc...))
* Economie d'execution (cron/appel HTTP qui provoque le lancement, l'execution en elle même (I/O, RAM, charge du processeur))
* Economie du SAV (débbogage, mises à jour (volontaire ou non)...)
* Economie de démantèlement (et ce qui s'en suit s'il s'agit d'un remplacement par quelque chose d'autre)

Toutes ses étapes de la vie du code consomment de l'énergie, en très grande partie électrique, et donc en tirant la ficelle tôt ou tard, de l'énergie fossile.

Et donc ? Et bien, avant d'écrire du code, il faudrait se demander s'il est vraiment nécessaire de le faire, et si c'est le cas, d'essayer d'en prévoir l'impact le plus faible possible.

7.2. Un code 'un peu' écologique

Un code peut être considéré comme écologique s'il améliore l'impact environnemental du ou des serveurs qui le ferait tourner, sans délocaliser l'exécution d'autres programmes.
Par exemple :
* du code qui supprimerait des fichiers / programmes / exécutions ;
* du code qui serait plus performant et moins gourmand en ressources.

/!\ ATTENTION : il ne faut pas que le gain apporté par ce code soit inférieur à l'impact des autres étapes nommées plus haut.
Par exemple, si un développeur doit travailler 2 mois pour optimiser un bout de code qui tourne une fois par an et qui consommerait quelques watts ; cela serait contre productif car cela induit des coûts énergétiques supérieurs aux gains.

Il faut donc se poser les bonnes questions :
- combien coûterait l'amélioration du code versus le code déjà en place ?
-> coût du temps de recherche/développement/tests/déploiement/execution
-> coût des ordinateurs qui servent à ces étapes.

7.3. Un code 'vraiment' écologique

Un code peut être considéré comme écologique s'il participe à un projet dont l'objectif est lui-même à portée écologique.
Exemple : calcul de l'optimisation de l'usage d'un terrain agricole, détection et alertes en cas de pollution, détermination de la forme idéal d'un moteur...
En d'autres termes, son impact doit être plus positif que négatif sur l'environnement, ce qui n'est malheureusement quasiment jamais le cas.

Le coût est directement relié à l'empreinte carbone du développement. Il faut également considérer que le salaire du salarié sera également dépensé à nouveau dans des produits ayant eux aussi un impact potentiellement négatif (il pourrait être positif si ce salarié se sent concerné par ses actes personnels vis-à-vis de l'environnement).

7.4. Ironie de cette page

L'impact de la rédaction de cette page a un bilan carbone surement négatif tant que son existence n'a pas éveillé les esprits et eu des conséquences écologiques positives.