PROJET AUTOBLOG


Sam & Max: Python, Django, Git et du cul

Site original : Sam & Max: Python, Django, Git et du cul

⇐ retour index

AngularJS pour les utilisateurs de jQuery : partie 2

lundi 27 octobre 2014 à 07:53

Après une intro sans trop de code, on va passer à du concret.

Pour apprivoiser la bête, on va comme d’habitude lui faire donner la patte et dire bonjour :

<!doctype html>
<!-- Lien entre l'app et la page -->
<html ng-app="tuto">
  <head>
    <meta charset="utf-8" />
    <title>Hello Angular</title>
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.26/angular.js"></script>
    <script type="text/javascript">
 
    // Déclaration de l'app
    var app = angular.module('tuto', [])
 
    // Lancement du code quand angular est prêt
    app.run(function(){
        alert('Hello !')
    })
 
    </script>
  </head>
  <body>
  </body>
</html>

Pour comprendre ce snippet, il faut réaliser qu’Angular est d’abord et avant tout un moyen d’organiser son code, et qu’il vous incite à le séparer en conteneurs :

Dans ce code, nous déclarons un module (ou app, c’est kif-kif) nommé “tuto” et n’ayant aucune dépendance (le second paramètre est un array vide) :

var app = angular.module('tuto', [])

Les apps ne font pas grand chose. Ce sont de gros namespaces avec des dépendances, c’est à dire qui déclarent les autres apps nécessaires à leur fonctionnement. Par défaut, aucune autre app n’est obligatoire pour lancer notre code, donc on ne déclare aucune dépendance.

Il y a juste un piège qu’il faut connaître. Si je fais :

var app = angular.module('tuto')

(notez l’absence de second paramètre)

Angular va tenter de me chercher la référence d’app du nom de “tuto” qui existe déjà. L’absence de dépendance se note donc avec un array vide, et non l’absence d’array. Subtilité piégeuse s’il en est. Vu qu’on n’aura pas besoin de déclarer de dépendances avant longtemps, inutile de vous crisper dessus, je vous l’indique juste pour le débuggage qui va immanquablement arriver le jour où vous oublierez l’array vide.

Ensuite, on fait le lien entre notre code HTML et l’app via :

<html ng-app="tuto">

ng-app est ce qu’on appelle une directive. Toutes les directives préfixées ng- sont fournies avec le framework et déjà chargées, prêtes à être utilisées. Une directive est un bout de code Javascript appliqué à du HTML, dans ce cas précis via un attribut.

Vous vous souvenez dans les années 2000 comme on vous faisait chier avec le fait de ne pas mettre de Javascript inline dans du HTML ? Les directives, c’est du Javascript inline qui ne dit pas son nom.

Chaque page doit être liée à une app, et une seule. Si on ne met pas ng-app, notre code ne se chargera pas, si on en met 2, ça foire. C’est le point d’entrée de notre code. Nous déclarons donc que cette page sera gérée par notre app “tuto”.

Puis lance notre hello tonitruant :

    app.run(function(){
        alert('Hello !')
    })

app est la variable contenant la référence à notre app, et en utilisant la méthode .run, on lui passe un callback à appeler quand l’app sera prête.

Il y a plusieurs choses à réaliser ici :

Vous allez me dire, mais espèce de pignouf, pourquoi tu nous montres un code que personne n’utilise ?

Et bien parce que le titre du dossier est AngularJS pour les utilisateurs de jQuery, du coup je vous mets en terrain connu.

Mais la vérité, c’est qu’un vrai hello d’Angular ressemble à ça :

<!doctype html>
<html ng-app="tuto">
  <head>
    <meta charset="utf-8" />
    <title>Hello Angular</title>
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.26/angular.js"></script>
    <script type="text/javascript">
 
    /* La je recréé l'app à chaque fois pour des raisons de praticité, mais
        dans un vrai code vous auriez ça dans un fichier à part, une seule
        fois */
    var app = angular.module('tuto', [])
 
    // Création d'un controller, et attachement d'une variable au scope.
    app.controller('HelloCtrl', function($scope){
        // Attachement d'une donnée au scope
        $scope.hello = "Hello"
    })
 
    </script>
  </head>
  <body ng-controller="HelloCtrl">
    <!-- Affichage du message attaché au scope -->
    <h1>{{ hello }}</h1>
  </body>
</html>

Et là il y a beaucoup à dire.

Premièrement, contrairement à jQuery, il n’y a pas de notion de préparation du DOM. En vérité, on peut mettre son code Angular en vrac, et Angular va initialiser tout son monde dans le bon ordre, et exécuter ce qu’il faut au bon moment. Et ce bon moment est parfois avant que le DOM soit prêt.

Mais vous n’avez pas à vous en soucier.

Car avec Angular, on manipule très rarement le DOM. Très peu de $('selecteur'), $node.bind() et autre $node.append(), à part dans les directives.

La majorité de votre taf va être de définir des données en pur Javascript, de dire où elles vont dans la page, et de les manipuler en Javascript pendant qu’Angular s’occupe de mettre la page à jour automatiquement.

Nous avons pas mal de nouvelles notions ici. D’abord, le contrôleur…

C’est un bout de code qu’on va lier à un bout de HTML via la directive ng-controller :

  <body ng-controller="HelloCtrl">
    ...
  </body>

Le contrôleur va être responsable de mettre à disposition des données pour ce bout de HTML. On peut lier autant de contrôleurs qu’on veut dans une page, et même les imbriquer. Ici, on dit que notre contrôleur HelloCtrl est responsable de mettre des données à disposition pour le tag body et tout ce qu’il contient.

On fait rarement des contrôleurs qui ratissent aussi large dans de vraies apps, mais pour notre exercice, c’est très bien.

Comment met-on à disposition des données ? Qu’est-ce que veut dire “mettre à disposition” ? Quelles données ?

Notre contrôleur ressemble à ceci :

    app.controller('HelloCtrl', function($scope){
        $scope.hello = "Hello"
    })

La fonction de callback sera exécutée quand ng-controller="HelloCtrl" sera activé automatiquement par Angular. Vous n’avez pas à vous souciez de quand, il le fera au moment le plus optimisé.

La seule chose dont vous avez à vous soucier, c’est ce que vous allez mettre dedans.

Et il y a ici deux nouvelles notions :

L’injection de dépendance fait partie de ces trucs qu’Angular fait automatiquement pour vous. Quand vous déclarez une variable dans le callback d’un contrôleur, Angular va chercher ce nom en mémoire, et récupérer le service qui porte ce nom. S’il ne le trouve pas, il plante.

Une fois qu’il a trouvé le service, il va attendre tranquillement le bon moment pour appeler le callback. Ce moment opportun arrivant, il va lui passer le service en paramètre. On dit qu’il lui “injecte” le service.

En relisant ces paragraphes, je réalise qu’il y a un mélange de plein de termes : contrôleurs, services, injection, bla, bla, bla.

Voilà le deal :

  1. Vous déclarez un contrôleur et vous le liez à du HTML via ng-controlleur.
  2. Dans ce contrôleur vous dites “j’ai besoin du service Machin”
  3. Angular cherche s’il connait Machin. Si non, il plante.
  4. Angular prépare le HTML, décide qu’il est prêt, appelle votre contrôleur et lui passe Machin en paramètre automatiquement.

Les services sont justes des d’objets javascript ordinaires, qu’on a nommés d’une certaine manière pour qu’Angular puisse les injecter. C’est tout.

En effet, pour résoudre le problèmes d’espace de nom en Javascript et d’organisation d’une grosse application, les créateurs d’Angular on créé un grand registre. On enregistre notre code dedans sous un nom (Angular.module('nom_de_l_app'), app.controlleur('nom_du_controller'), etc.), et Angular récupère le bon code au bon moment. C’est essentiellement un moyen de pallier au fait que Javascript est dégueulasse.

Donc, plutôt que de faire des imports comme en Python, on va déclarer une variable en paramètre, et Angular injecte le bon objet pour vous. C’est bizarre, mais on s’habitue.

Du coup, là :

app.controller('HelloCtrl', function($scope){

Je dis “crée moi le contrôleur nommé ‘HelloCtrl’, et quand tu vas appeler le callback, passe lui l’objet nommé ‘$scope’ en paramètre. Fais ça au bon moment, je m’en branle, je veux pas le savoir. Démmerde toi, on a tous des problèmes.”

Le résultat, c’est que votre fonction sera exécutée automatiquement au bon moment, et qu’elle aura $scope qui lui sera passé.

Alors à quoi sert ce $scope ?

C’est simple : tout ce qui est attaché en attribut de $scope est accessible dans le HTML géré par ce contrôleur. Quand je fais :

    app.controller('HelloCtrl', function($scope){
        $scope.hello = "Hello"
    })

Et que après je lie mon contrôleur au HTML :

  <body ng-controller="HelloCtrl">
    <!-- Affichage du message attaché au scope -->
    <h1>{{ hello }}</h1>
  </body>

Ma variable hello est disponible ici (via les petites moustaches qu’on verra au prochain chapitre), parce que je suis dans body qui est géré par le contrôleur HelloCtrl qui contient un $scope avec l’attribut hello. Fiou ! Ca en fait des couches. Mais Angular, c’est comme un orgre un onion.

Vous touchez ici du doigt l’essence même du boulot des contrôleurs, et à peu près leur unique but : mettre des données à disposition du HTML. C’est le C de MVC.

C’est pour cette raison que je vous ai répété “Angular va tout faire au bon moment, vous n’avez pas à vous soucier de quand”. Ceci est en effet très frustrant à entendre quand on vient du monde de jQuery puisque qu’on doit savoir exactement quand on fait les choses : il faut que le DOM soit prêt, il faut que les éléments sur lesquels on travaille existent, il faut qu’on puisse récupérer des nodes et en ajouter.

Avec Angular, on ne fait rien de tout ça. On va déclarer ses données dans le contrôleur, et dire où elles doivent être mises dans la page. Angular se charge de faire le lien pour vous quand le HTML est prêt, quand le Javascript est chargé, quand les Dieux sont avec vous…



Télécharger le code de l’article.

Servir des fichiers statiques avec nginx

jeudi 23 octobre 2014 à 08:20

C’est un truc dont j’ai tout le temps besoin, alors l’article servira de pense bête. Marre de chercher à chaque fois :

        # sur django, on met tout dans /static/, donc par habitude je le fais
        # pour tout
        location /static/ {

            # Le dossier doit contenir le dossier 'static'. Par exemple si votre
            # arbo est /home/sametmax/repo/static, le chemin sera
            # /home/sametmax/repo. Rassurez-vous, personne n'aura accès aux
            # autres sous dossiers de "repo".
            root  /chemin/absolu/vers/dossier/;

            # On active la compression
            gzip  on;
            gzip_http_version 1.0;
            gzip_vary on;
            gzip_comp_level 6;
            gzip_proxied any;
            gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
            gzip_buffers 16 8k;

            # Sauf pour les vieux nav
            gzip_disable ~@~\MSIE [1-6].(?!.*SV1)~@~];

            # On dit au navigateur de le mettre en cache pour 3 mois. Faites gaffe,
            # mettez un param dans les url de vos balises script/link qui change
            # à chaque version du fichier, sinon vous ne pourrez pas mettre à jour
            # vos fichiers.
            expires modified +90d;
        }

Rapatrier une branche d’un repo distant en local

mardi 21 octobre 2014 à 19:00

Vous avez un repo local et un remote. Une branche a été créée sur le remote, et vous voulez la récupérer en local :

git checkout --track nom_du_remote/nom_de_la_branche

Par exemple :

git checkout --track origin/dev

Ce qui va avoir pour effet de créer une branche “dev” sur votre repo local, de vous switcher dessus, et la lier à la branche “dev” du remote “origin”.

Comme d’hab, assurez-vous que votre copie de travail est bien propre avant sinon ça va merder au moment de changer de branche.

Ouais, ouais, je sais, checkout est la commande fourre-tout de git qui fait absolument n’importe quoi. C’est relou.

Rapport de l’INDMS : le niveau des développeurs

lundi 20 octobre 2014 à 15:34

Dans un article précédent, j’avais souligné la baisse du niveau des devs et on m’avait demandé mes sources. Mes sources, comme souvent pour ce genre d’opinion, sont les études empiriques du très sérieux Institut National du Doigt Mouillé de Sam. Faudrait que je fasse un logo mais je suis une pine en graphique.

Aujourd’hui, à l’aide de chiffres scientifiquement approximatifs et d’analyse d’échantillons représentatifs localement, à moins que ce soit l’inverse, nous allons vous expliquer ce qui se trame.

Je ne suis pro en dev que depuis 10 ans. 10 ans, c’est court dans une carrière. Mais en informatique, c’est long. Suffisamment long pour avoir vu l’ère pré-msql_real_escape, les premiers ORM, la mode du NoSQL et le big Data. Suffisamment pour avoir vu le design via table, puis la psychose du xHTML valide strict et accessible pour finir sur le HTML 5 avec le retour du JS inline qui ne sert pas qu’à faire des flocons de neige. Suffisamment pour avoir vu Linux devenir utilisable, la programmation sur téléphone accessible (vous vous souvenez qu’avant on programmait les nokias en J2ME ?), la latence réseau devenir un bottleneck, le CPU et la mémoire étant relégués à un problème comptable sur 90% des projets. Et surtout, suffisamment pour voir le Dev Web passer d’un truc de bidouilleur à une spécialité à part entière du monde de l’informatique.

Mais même avant, sans faire de l’argent avec, j’avais les mains dedans. J’avais un ordi avec des disquettes 5 pouces, un écran en noir et vert et un bouton “turbo” qui overclockait le puce à 8Mhz. Wooosh ! Et encore avant, un ordinateur avec une cassette à bande magnétique que je n’ai jamais réussi à faire marcher.

Et puis on croise du monde, des gens d’expérience qui partagent. On lit des livres d’il y a 20 ans (almost perfect est disponible gratos au fait). On travaille. On forme. On recrute.

Cela m’a amené a plusieurs constats.

Le niveau de vie des développeurs s’est bien amélioré

Que ce soit au niveau qualité de matériel (2 écran HD pour utiliser VI, c’est le luxe), accessibilité de l’information (Google, c’est plus facile qu’un magazine ou des man pages sur disquette), automatisation (on compile très rarement les dépendances tierces maintenant), facilité de trouver un job (y a des annonces partout), tout est plus confortable.

Mais ce n’est pas le plus important.

L’image des dev s’est améliorée. Être le geek au collège n’était pas vraiment une partie de plaisir. En fait si j’avais rencontré Max dans la cour de l’école, on se serait probablement mis sur la gueule.

Aujourd’hui on vend des magazines avec en couv’ des geeks millionnaires, Hollywood s’est approprié la mythologie du hacker et la coolification (devrais-je dire coolifitude ?) de l’utilisation informatique rend la vie beaucoup plus facile.

Quand je dis à une meuf que je suis informaticien, elle ne fuit plus. C’est pratique. La logistique devenait compliquée.

Utilisation du piège à loup en % de rencards.

La dernière fois que Max a choisi une carrière d’un soir, il était chirurgien esthétique.

L’informatique a explosé

Comme vous pouvez le voir sur ce graphique, le nombre de connards à utiliser l’informatique a drastiquement augmenté. Ce faisant, il y a donc beaucoup plus d’appareils nécessitant d’être programmés sur le marché, les rayons, le chaumières et les poubelles.

Progression de la situation situationelle

C’est toujours mauvais quand on croise les effluves

Malgré des échelles qui n’ont rien à voir, la courbe de facilité des usages suit paresseusement celles des usagers, et ce n’est pas un hasard. La formule pour calculer la simplicité d’un système étant dépendante de la variable du nombre de boulets l’utilisant (Evidence = MasseConnards²).

Or, pour répondre à la fois à la simplification des usages, et à leur multiplication, il y a fallu créer un paquets d’abstractions qui ont rajouté des couches, ce qui explique la progression du niveau d’indirection.

Les formations n’ont pas suivi

Dans le cas le plus grave, elles ont des années de retard sur les technologies actuellement utilisées. Dans le meilleur des cas, elles sont dispensées par des gens qui ne travaillent pas, et donc ne fournissent pas aux apprenants les éléments nécessaires pour être un élément productif.

Enseignement uiversitaire en France

Je voulais rajouter le pourcentage de profs qui avaient fait une migration de schéma en prod, mais LibreOffice n’accepte pas les chiffres négatifs.

Je voulais rajouter le pourcentage de profs qui avaient fait une migration de schéma en prod, mais LibreOffice n’accepte pas les chiffres négatifs.

Les bons informaticiens restent donc ceux qui se forment eux-mêmes. Via un projet personnel, par simple passion, en travaillant pour financer leurs études, etc. Même pendant la vie professionnelle, ceux qui ne deviennent pas obsolètes sont ceux qui continuent à apprendre. Car la formation en info, c’est toute sa vie. Et c’est un train où le paysage avance en même temps que soi, donc si on s’arrête, en vérité, on recule.

Et du coup

Le niveau des dev baisse. Pas de manière absolue, mais de manière relative au niveau dont le marché a besoin, et également en pourcentage de la population totale.

C’est lié à la conjoncture : plus de demande et plus de confort impliquent qu’il y a plus de monde qui se lance dedans. La démocratisation, c’est bien, mais ça apporte également un flot de personnes qui font ça comme job alimentaire. Or, si la formation ne suit pas, et qu’ils ne se forment pas, le nombre de technos continue d’augmenter. Les abstractions continuent de s’accumuler. Les nouveaux produits continuent de sortir.

Si bien que le besoin de dev augmente, mais également l’exigence de la somme des compétences requises progresse. Car si on a plus besoin de connaître la différence entre un little endian et un gros portoricain, pour dev une app Web moderne il faut maitriser : CSS, Javascript/Python/Ruby, HTML, quelques frameworks par dessus tout ça, une base de données et peut être un ORM, un système d’exploitation, potentiellement une machine virtuelle, un système de déploiement, des préprocesseurs, un système de files de tâches, un moteur de recherche, un système de cache…

Et l’attente des clients, comme des employeurs, sur le résultat, a elle aussi grandi. On veut du mieux, plus vite, plus ergonomique. Ils le font bien à côté. Par contre, ce qu’ils peuvent payer pour ça n’a pas beaucoup bougé en France, ils pensent toujours qu’avec un bon fichier de conf on peut faire faire un clone de Youtube pour pas cher.

Du coup les bons devs qui restent, ceux qui se sont formés et continuent de se former, ceux qui sont noyés dans la masse grandissante des spleenés de la programmation qu’on a attiré avec la promesse d’un job, ils se barrent. Ils se barrent là où on les paie à la hauteur de leur compétence : aux USA et aux UK.

Je résume :

A l’embauche, le nombre de bons dev disponibles comparé à la demande grandissante et au nombre total de candidats, est en chute libre. Et ce, malgré le nombre de devs de talent, absolu, qui lui augmente dans le monde par le simple truchement de la démographie et de l’émulsion technologique.

Dans la vraie vie vivante, ça se traduit par des entretiens déprimants, des embauches tristes et des cours d’info frustrants.

Et la situation ne va pas s’arranger. Les besoins vont continuer à croître. Les bons dev ne vont pas sortir du chapeau. Faites en sorte que ce soit une bonne nouvelle pour vous :

Comment faire ? Arf, ça pourrait être un autre article. Un jour :)

Le cercle de ses amis

samedi 18 octobre 2014 à 14:16

Aujourd’hui une jolie blonde m’a trollé en recrachant mon sperme dans mon nombril.

J’ai trouvé ça hilarant, et j’ai éclaté de rire.

Elle a pris son sex toy et m’a dit : “je jouis encore une fois et on joue à Dota”.

Et je me suis occupé de ses seins pendant qu’elle s’occupait d’elle.

Je préfère ces moments là aux couchés de soleil, aux fleurs, aux restos avec bougies et aux boîtes de chocolat de la saint valentin.

L’humanité adore les clichés mais je pense qu’il appartient à tout à chacun de déterminer ce qu’on trouve charmant ou non. La partie coton, c’est de trainer avec des gens qui sont d’accord sur la question.

Je ne m’en fais pas trop sur le sujet.

J’ai Max pour me parler de la dernière thaï atomique qu’il a trouvé en VOIP.

J’ai un ami chinois qui m’a recommandé un super club échangiste alors qu’on surfait sur des sites de libertins.

J’ai une copine libanaise qui m’a signalé une bonne plage nudiste tandis qu’on mettait à jour son ordinateur sous Ubuntu.

J’ai un pote espagnol qui m’a raconté les envies de partouse de sa coloc avec son ex en jouant à LOL.

Geeks et cul, finalement, la formule du blog était pas si bête.