first commit

Author: Luca Montaigut

[email protected]

@@ -0,0 +1,65 @@
+# Le javascript dans le browser
+
+## neolectron — 29/05/2019 :
+
+Il faut savoir que le "javascript browser" (le javascript dans le contexte d'un navigateur internet), nous est fourni avec une **api**.
+
+(une api est un ensemble de fonction crée pour que tu puisse utiliser un systeme que tu connais pas [ici la page web])
+
+(donc c'est **un ensemble de fonctions qui t'aident a faire des trucs sur ta page web** [pour plus d'explication regardez le topic en haut "javascript n'est pas un language"])
+
+Cette api se trouve dans l'objet `window`, pour voir l'ensemble des variables et fonction que chrome nous file, il suffis de taper `window` dans la console chrome.
+
+Dedans on y trouve des trucs sympa comme la fonction alert pour mettre une popup et la fonction prompt pour poser une question.
+
+--
+
+L'objet qui nous interesse aujourd'hui c'est `document`
+(ou `window.document`, mais il est inutile de préfixer tout ce qui se trouve dans window par `window.`).
+document c'est l'objet qui est censé représenter notre page web dans son ensemble
+(donc cette fois ci c'est pas juste des fonctions pour nous aider a faire des trucs, c'est juste la variable dont chrome se sert pour representer la page web).
+
+--
+
+Dans document cette fois ci, on peut trouver du coup toutes les balises html qui sont dans notre page, a commencer par la balise body.
+
+On la trouve tout simplement dans document.body (ok là c'était facile, mais c'est pas le cas pour toutes les balises mdr)
+
+pour essayer de chopper la variable qui represente une balise html afin de pouvoir la modifier.
+(par ce que c'est le but du js de modifier l'html en live)
+
+--
+
+Ces variables qui représente des balises html on les appelle Node (rien a voir avec node js si t'as bien lu le post en haut tu sais)
+
+donc document.body est un Node.
+(donc node est la representation d'une balise html mais dans le js)
+
+facile, tapez le dans la console chrome, et on verra meme qu'il nous l'affiche en balise pour que ça soit plus lisible.
+(mais en vrai c'est une variable js normale pas d'inquietude)
+
+--
+
+Maintenant on fait quoi avec des nodes ?
+j'ai acces a body ok mais quoi apres ?
+comment je modifie la page web en fait ?
+
+--
+
+Et bien sur tout les nodes on a un fonction super simple a utiliser :
+querySelector
+(donc ça marche sur document.body.querySelector si t'as bien suivi par ce que body c'est un node)
+
+Et ce qui est encore plus stylé c'est que les paramètres c'est juste un selector css.
+(la syntaxe que t'utilise en css pour dire quelle div tu veux chopper).
+
+--
+
+par conséquent si je veux chopper la div qui a une class jambon, je devais faire :
+document.body.querySelector('.jambon')
+facile !
+
+Et si t'as bien suivi, ça va nous renvoyer exactement la premiere div qui se trouve dans body et qui contient la class jambon.
+
+Et le retour de cette fonction ben ça sera... ... ... ..un node !
+donc le node qui represente la div avec class jambon :)

[email protected]

@@ -0,0 +1,101 @@
+# Le javascript est une syntaxe
+
+## neolectron — 29/05/2019 :
+
+**le javascript est une syntaxe** (a prendre avec des pincettes - lisez bien)
+
+Le js n'a **pas** de stdlib qui permet de lire des fichiers, ça ne peut pas non plus manipuler du html, ni envoyer des requêtes réseau.
+
+**le js n'a pas d'io**
+
+le js ça peut rien faire.. c'est **purement algorithmique**.
+
+ça contient que des while, des if des for.
+ça contient quelques types a la con (primitifs ou non), genre Number Array Object Date etc...
+donc on peut RIEN faire en javascript. surtout que ... ça n'a pas interpréteur officiel.
+
+donc le js c'est juste une norme, en gros c'est un bout de papier qui dit "quand on tape ça , ça doit faire ça"
+(papier rédigé par la société ECMA qui gère aussi la norme du C# btw)
+tu peux run du js nulle part par defaut. le programme qui run du js n'existe pas...
+
+--
+
+donc comment ça marche ?
+
+--
+
+les navigateurs ont du implémenter chacun pour leur gueule, un programme qui parse le js, et qui exécute les bonnes instructions en conséquence.
+
+donc ils ont crée des interpréteurs js, qui parse du js et run des trucs en C ou ASM en backend finalement.
+
+sachant que les navigateurs faisaient plus ou moins ce qu'ils voulaient a l'époque, personne vérifiait réellement si tout était normalisé.
+
+donc certains implémentaient des trucs que d'autres n'avaient pas et vice versa.
+le seul truc qu'ils avaient en commun, c'est qu'ils devaient injecter dans le langage, des fonctions pour manipuler le HTML sinon ça servirait a rien.
+(encore une fois chacun a leur sauce)
+
+--
+
+suite ça on en arrive en 2000, quand les devs en ont eu marre que tout les navigateurs implémentaient leur merde a leur sauce,
+
+donc ils ont fait une lib super-lourde qui fait des if, pour savoir quelle api appeler en fonction des navigateurs.
+
+cette lib c'est jQuery. ça sert QUE a faire des if pour voir si le navigateur implémente ou non la feature que tu veux utiliser.
+
+--
+
+aujourd'hui la plupart des navigateurs suivent a la lettre les normes ECMA, et le support a bien progressé.
+(du coup si tu veux pas de support de vieux browser jQuery ne sert qu'a avoir des perfs pourries sur ton site.)
+
+--
+
+ducoup on en était là. on a une syntaxe un peu universelle qui run sur différents interpréteurs.
+
+c'est la guerre des navigateurs , tout le monde s'y met, microsoft/mozilla/apple/google,
+
+spoil: google a gagné.
+
+pourquoi ? => leur navigateur est plus rapide.
+pourquoi ? => leur moteur js est plus rapide.
+
+--
+
+donc finallement la guerre des navigateurs c'était une guerre des engine JS.
+
+--
+
+là certains mecs qui aimaient bien la syntaxe du js se sont dit que ça serait chouette d'en faire un langage, et d'avoir une stdlib,
+
+pour lire des fichiers ou même envoyer des requêtes réseau.. ce genre de trucs qui permettraient de faire du js un vrai langage.
+
+Ces mecs, s'appelle la team node (meme si c'était ptet pas les premier a avoir eu l'idée).
+
+Ils ont codé une api en C++ qui permet d'ouvrir/lire/écrire dans des fichiers, faire des requêtes etc etc.
+
+Ils l'ont juste injecté dans le moteur javascript de google (celui qui est dans chrome [le v8 de son pti nom]) et voilà.
+On a un moteur js codé par google qui a une stdlib dedans qui peut faire autant de choses que d'autres langages :)
+et ça c'est node-js.
+
+--
+
+pour dive un peu plus dans node :
+la team node a décidé de faire un language avec des io non-bloquantes.
+ce que ça veut dire, c'est que chaque io (des operations sur fichier / network / autres) serait asynchrone.
+
+en gros ça fonctionne avec une file d'attente, par ex :
+
+1- tu fais ta demande de request réseau.
+
+2- node enregistre une fonction nommée callback, qui sera déclenchée a la fin de ta request.
+
+2- tout le reste de ton code continue de s'exécuter même si cette request est pas finie (oui c'est ça l'async)
+
+3- quand la reponse a ta request réseau revient dans l'engine node, ils appellent ton callback en lui filant en paramètre la réponse.
+
+4- le code dans ta fonction de callback s'exécute.
+
+voilà ce que c'est node.
+
+(le schéma de base qui aide pas mal a se représenter le runtime)
+
+![event loop schema](./img/event_loop.png)

README.md

@@ -0,0 +1 @@
+# epic-answers

img/event_loop.png

@@ -0,0 +1,88 @@
+# Les pointeurs en C
+
+## La_Banane — 01/10/2017 :
+
+En C ( et dans le concept de mémoire en général ), tu peux adresser/parcourir une zone mémoire par `bloc de N octets`, en C t'as plusieurs types: `char | short | int | long`, respectivement ( sur la plupart des architectures ) `N = 1 | 2 | 4 | 8`.
+
+Quand tu définis un pointeur avec un type particulier, tu vas informer le compilateur de la manière dont tu veux accéder à la zone mémoire pointée par ce pointeur.
+
+Exemple simple, quand tu définis un pointeur `char *` sur une zone mémoire, tu vas informer le compilateur que tu veux accéder à cette zone mémoire octet par octet, ainsi avec un pointeur définis comme tel: `short *`, tu vas informer le compilateur que tu veux accéder à la zone mémoire 2 octets par 2 octets, ainsi: `char* p = addr`, `*p` va pointer sur la zone mémoire sur un seul octet,
+par conséquent avec: `short* p = addr`, `*p` va pointer sur la zone mémoire sur deux octets.
+
+Si tu incrémentes ton pointeur, le compilateur, ayant connaissance de ta volonté sur ton pointeur, va incrémenter l'adresse de manière relative au type défini.
+
+Ainsi en considérant le code suivant:
+
+```
+char* p_char = 0;
+short* p_short = 0;
+
+printf("p_char next memory addr: %d\np_short next memory addr: %d\n", p_char + 1, p_short + 1);
+```
+
+L'output donnera:
+
+```
+p_char next memory addr: 1
+p_short next memory addr: 2
+```
+
+C'est ce qu'on appelle l'arithmétique des pointeurs.
+Ainsi, en C il est défini un type `void`, qui informe le compilateur d'une ressource dont le type est "inconnu" ou "sans donnée" par exemple pour informer le compilateur qu'il ne doit pas attendre un retour de fonction sur une fonction donnée: `void func()` (a savoir qu'une variable classique ne peut pas être définie avec un type `void`), ainsi un pointeur défini comme tel: `void *`, défini une zone mémoire dont la manière d'adressage n'est pas définie.
+
+Par défault le type `void` a la même taille que le type `char`, cependant il ne peut pas être utilisé explicitement pour avoir le même comportement, c'est simplement unstable.
+
+On en arrive à une utilisation courante du type `void`, dont profite la fonction `malloc`, c'est à dire le fait de pouvoir caster implicitement un pointeur de type `void`.
+
+Ceci évite d'avoir un warning compilo et de profiter d'une certaine souplesse pour manipuler la zone mémoire allouée.
+
+En effet, si `malloc` retournait arbitrairement un pointeur de type char, alors le compilateur enverrait un warning si tu récupérait la valeur du pointeur dans un pointeur de type différent, par exemple de type short.
+
+On peut simuler:
+
+```
+#include <stdio.h>
+
+char* malloc_which_return_char_pointer() {
+    return NULL;
+}
+
+void* malloc_which_return_void_pointer() {
+    return NULL;
+}
+
+int main()
+{
+    char* good_char = malloc_which_return_char_pointer(); /* Le compilateur ne dit rien, le type du pointeur destinataire correspond au type du pointeur expéditeur */
+    short* bad_short = malloc_which_return_char_pointer(); /* Le compilateur trigger un warning, le type du pointeur destinataire ne correspond pas au type du pointeur expéditeur */
+
+    char* _good_char = malloc_which_return_void_pointer(); /* Le compilateur ne dit rien, le type du pointeur destinataire n'a aucune importance, car le type du pointeur expéditeur est de type void */
+    short* _good_short = malloc_which_return_void_pointer(); /* Le compilateur ne dit rien, le type du pointeur destinataire n'a aucune importance, car le type du pointeur expéditeur est de type void */
+
+    return 0;
+}
+```
+
+En compilant le code ci-dessus, le compilateur te retournera alors:
+
+```
+main.c: In function 'main':
+main.c:14:24: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
+     short* bad_short = malloc_which_return_char_pointer(); /* Le compilateur trigger un warning, le type du pointeur destinataire ne correspond pas au type du pointeur expéditeur */
+                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+Ce qui se passe ici est un `cast implicite` effectué par le compilateur. A noter que l'inverse est aussi possible, c'est à dire caster un type `char *` vers un type `void *` par exemple.
+
+```
+int main()
+{
+    char* p_char = 0;
+    void* p_void = p_char;
+    short* p_short = p_void; /* Le compilateur ne dit rien */
+    p_short = p_char; /* Le compilateur trigger un warning */
+    return 0;
+}
+```
+
+Enfin, quand tu fais: `char* p = malloc(...)`, ça ne pose théoriquement pas de soucis au compilateur qui comprend nativement ce que tu veux faire, cependant il est bien vu d'effectuer un cast explicite sur la ressource ( ici l'adresse d'une zone mémoire ) retournée par malloc ( ça vaut pour toute fonction qui retourne un pointeur de type void théoriquement ), puisque ça permet d'éviter toute potentielle incompatibilité de compilateur ainsi qu'une meilleur compréhension générale de ta variable, et de son rôle dans la suite du code.