Artisan Développeur

Qualité, amélioration continue, agilité.

Vagrant snapshot, safety first

When you want to test something, in my case it’s the upgrade to php7.3, I encourage you do use the really simple snapshot function of Vagrant.

First, see the VMs of your system:

vagrant global-status
id       name                        provider   state    directory                                              
--------------------------------------------------------------------------------------------------------------- 
0313ed0  default                     virtualbox poweroff /var/www/phpStorm/blog.xXXXx.com/trellis              
1407963  default                     virtualbox poweroff /var/www/phpStorm/xxx/xxxxx-com/trellis       
3879b77  default                     virtualbox running  /var/www/phpStorm/xxx-dev/xxxxxx-com/trellis   
ac34ac8  default                     virtualbox poweroff /var/www/phpStorm/xxx-dev                              
b292e76  default                     virtualbox running  /var/www/phpStorm/xxxxxxxx-com/trellis           
3fb0c96  default                     virtualbox running  /var/www/phpStorm/vagrant/xxxx                    
6e6b27f  default                     virtualbox running  /var/www/phpStorm/xxxxxx                               
2b7849a  poc-xxxxxx               virtualbox running  /var/www/phpStorm/laravel/projects/poc_xxx       
a8f3ca7  consume-channel-xxxxxx-api virtualbox running  /var/www/phpStorm/laravel/consume_channel_xxxxxx_api 

Some of these VMs are old, and not needed anymore, before I continue, I prefer to do some clean up first.

vagrant global-status --prune
id       name                        provider   state   directory                                              
-------------------------------------------------------------------------------------------------------------- 
6e6b27f  default                     virtualbox running /var/www/phpStorm/xxxxx                               
a8f3ca7  consume-channel-xxxxx-api virtualbox running /var/www/phpStorm/laravel/consume_channel_xxxxx_api 

A lot better ! Next the snapshot:

vagrant snapshot save 6e6b27f 2019_08_20_save_xxx_before_php_7_3
==> default: Snapshotting the machine as '2019_08_20_save_xxx_before_php_7_3'... 
==> default: Snapshot saved! You can restore the snapshot at any time by 
==> default: using `vagrant snapshot restore`. You can delete it using                                                                
==> default: `vagrant snapshot delete`.  

Really easy ! Last paranoid check before the upgrade:

vagrant snapshot list 
2019_08_20_save_xxx_before_php_7_3

Now I can break it all and restore my snapshot !

happy experiments

remplacer php7.0 par php 7.1/7.2/7.3 debian 9 (Stretch)

Il y a un dépôt pour les version récentes de php: https://packages.sury.org/

Pour l’installer regardons le README.txt, c’est une bonne habitude à prendre: https://packages.sury.org/php/README.txt

Il faut installer 3 packages:

  • apt-transport-https
  • lsb-release
  • ca-certificates

Avant d’installer, on peut vérifier si ils sont déjà présents:

dpkg --list apt-transport-https lsb-release ca-certificates

ou:

apt list --installed | grep "apt-transport-https"
apt list --installed | grep "lsb-release"
apt list --installed | grep "ca-certificates"

Si ça n’est pas installé:

apt install apt-transport-https lsb-release ca-certificates
(j'utilise apt au lieu de apt-get, un article en anglais sur les différences: https://itsfoss.com/apt-vs-apt-get-difference/)

On récupère la clef GPG du dépôt:

wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg

On mets le dépôt dans un fichier de sources de apt:

sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'

Mise à jour de la liste des paquets disponibles

apt update

D’abord je fais la liste des packages php déjà installés (pour avoir un historique de parano):

apt list --installed php* > php_packages_installed

Pour installer la dernière version de PHP il suffit de faire

apt upgrade

J’aime bien enlever ce qui n’est pas nécessaire:

apt remove php7.0* libapache2-mod-php7.0

Pour installer une version spécifique de PHP disons 7.2, je récupère tous les packages avec php7.0 dans leur noms depuis ma liste précédemment sauvegardée:

cat php_packages_installed | grep "php7.0" > php_packages_installed_php7_0
sed -i 's/php7.0/php7.2/g' php_packages_installed_php7_0
xargs -L1 -a php_packages_installed_php7_0  echo | cut -d/ -f1 > php_packages_to_install

Avant de faire l’installation des packages, une petite lecture de https://www.php.net/manual/en/migration71.deprecated.php
Par exemple, j’avais mcrypt installé …

sed -i '/php7.2-mcrypt/d' php_packages_to_install

Pour installer:

apt install $(xargs -a php_packages_to_install echo )

J’imagine qu’il d’optimiser mes commandes bash, ou bien une option de conf de APT pour séléctionner php7.2, mais c’est comme ça que j’ai procédé pour tester dans ma vm.

Les commentaires/améliorations/informatinos sont les bienvenus !

ps: si php ne fonctionne pas vous pouvez essayer de faire :

dpkg-reconfigure libapache2-mod-php7.3

Développeur ou codeur ?

( Post original sur https://artisandeveloppeur.fr/developpeur-ou-codeur/ – si vous voulez commenter, allez sur l’article original. Je vous invite au passage à aller lire les posts des autres contributeurs sur cet excellent blog ! )

Qu’est ce que réellement le métier de développeur ?
Qu’est ce qu’on doit attendre d’un développeur ?
Est-ce qu’un codeur est un développeur ?

Pour répondre à ces questions nous allons avancer ensemble à travers 4 courtes parties:     

  1. Contexte
  2. Le métier de développeur est en crise 
  3. Le marché du travail perverti par une gestion inadaptée
  4. Donc un dév c’est quoi ?
  5. Conclusion
1 – Contexte:

Avant tout il faut faire la différence entre le professionnel que tu es et le poste que tu occupes. En tant que professionnel tu n’es pas défini par:

  • par ta formation
  • par ton langage/framework/techno
  • par le titre de ton poste
  • tes responsabilités dans ta boîte
  • tes certifications

Tu es défini par la manière dont tu vois et tu pratiques ton métier, ta mentalité, tes valeurs. Dans cet article et plus largement dans notre communauté d’artisans développeurs ce qui nous intéresse c’est la manière dont tu travailles, dont tu abordes le développement.

2 – Le métier de développeur est en crise

Alors oui, je plaide coupable c’est un titre de paragraphe provocateur mais le métier de développeur à été dévoyé et les dév sont vus à tord comme «des gens qui écrivent du code». Une ressource qu’ils mettent derrière un bureau, qui prend ses user stories, ou ses specs et qui doit « juste coder ce qu’on lui demande ». En réalité un développeur est avant tout un interlocuteur qui doit comprendre les besoins, le métier, évaluer et synthétiser. C’est le lien, le dernier maillon entre la vision et l’implémentation. Beaucoup de formations, souvent « accélérées », sont apparues ces dernières années pour apprendre à développer. Mais elles apprennent à coder et pas à développer. Je soupçonne une grande partie des organismes de profiter du besoin croissant de dévs, de dispenser des formations pour « produire » les employés dont le marché à besoin. Cependant, et c’est l’objet de la partie suivante, je pense que le marché se trompe, et il prends un très mauvais chemin. Donc, lorsque tu as appris à coder tu n’es pas un développeur. C’est sûr, là tu vas te dire, c’est de la rhétorique, c’est pareil: codeur, développeur, programmeur, programmateur (IMAGE) Oui, je fais la différence entre un développeur (appelé dév tout au long de cette article) et un codeur (appelé … non en fait on l’appelle pas :p ).

3 – Le marché du travail perverti par une gestion inadaptée

Je ne suis pas historien et je n’ai pas 40 ans d’expérience en informatique, mais à mon avis ce qui s’est passé, c’est qu’avec les méthodes de gestion de projet héritées des industries, de la construction et toutes ces choses très rigides, petit à petit on a découpé les rôles, on a donné à certains métiers la charge de concevoir, et d’autres la charge d’exécuter, comme l’architecte et les maçons. On a cloisonné pour chercher la rentabilité. Chercher à être rentable est en soit une bonne chose, c’est même primordial lorsqu’on gère en entreprise, mais la manière n’est pas la bonne dans ce cas. Les dirigeants qui ont suivis ce chemin se sont fourvoyés sur une chose, être développeur c’est un ensemble de compétences, si tu extrais le codeur du développeur, tu vas diluer les qualités professionnelles qui mènent à du code pérenne. Et la qualité baisse. C’est là où le fossé se creuse entre les entreprises qui veulent faire du bon travail en étant rentables et les entreprises qui veulent seulement être (très) rentables. Je reviens sur mon analogie avec la construction, on peut trouver:

  • l’équipe du terrassement (les ops)
  •  gros œuvres (les dév backend)
  •  les carreleurs (dév front)
  •  les peintres (UX)
  • l’architecte (l’ingénieur commercial + l’ingénieur architecte logiciel) 

Quand l’informatique est arrivée elle a été gérée comme le reste, pourquoi réinventer alors les méthodes de gestions de projets ? Mais ça ne va pas fonctionner sur le long terme et il ne faut pas que ça fonctionne comme ça : nous faisons de l’immatériel, qui doit rester en mouvement en permanence, changer, s’adapter, s’améliorer, appliquer des méthodes de gestion de projets finis, rigides, ne permet pas cette souplesse et cette capacité d’adaptation. On se rend bien compte maintenant que l’informatique en général et le développement en particulier est indispensable, complètement dissocié du reste, c’est immatériel, on ne doit pas le gérer comme du matériel. Le développement intervient partout, rien ne va plus lui échapper: télé, réfrigérateur, voiture, robots, médecine. L’autre point important lors du découpage de compétences, c’est que le codeur se retrouve très souvent à faire toujours la même chose ou du ressemblant, il devient super spécialisé et à force c’est la créativité qui souffre, et sans créativité, pas de solution innovantes, pas de designs pertinents, pas de nouveautés … Il est tellement enfermé dans sa spécialité qu’il trouve toujours comment faire correspondre un besoin à ce qu’il sait faire, et il déforme le besoin. Je cite Benoît (Gantaume) dans une épisode du podcast, « lorsque tu n’as qu’un marteau toutes les vis ressemblent à  des clous » Heureusement les méthodes agiles remettent l’humain à sa place dans les organisations, et si tu t’y intéresses un peu tu vois bien que le schéma qui ressort comme idéal est une équipe pas trop grosse qui sait tout faire, et qui fait en équipe.  Chacun a évidemment des compétences avancées dans son domaine, mais tout le monde participe. Dans ces équipes, les dévs reprennent leur place, il participent à la conception, encore faut il qu’ils aient correctement appris à le faire.

4 – Donc un dév c’est quoi ?

Tout ça pour dire quoi ? Tout ça pour dire que le métier de développeur n’est pas un métier d’écriture de code. Il englobe cette activité parmi d’autres. Si ma seule activité était de coder je serais malheureux, coder est un très bon moment dans mon métier de dév parce qu’il y a justement les autres aspects. Pour développer un logiciel il faut :

  • comprendre les besoins et le métier
  • poser et expliciter les problématiques
  • poser et expliciter les fonctionnalités attendues
  • concevoir les solutions aux problématiques
  • choisir la(les) meilleur(es) technologie(s), langage(s), framework pour implémenter ces solutions
  • passer à l’écriture du code (les tests sont compris, on reste dans une optique de TDD)
  • tester les fonctionnalités (chercher du retour utilisateur)

Dès lors on voit bien que juste coder ne permets pas de développer. Une des différences fondamentales entre un codeur et un développeur est l’abstraction, lorsque tu es développeur tu es capable de faire abstraction de ton langage de prédilection, de ton framework lorsque tu penses conception. La conception doit être agnostique, les compétences à mettre en œuvre à ce moment ne sont pas les compétences d’écriture du code. Pour expliquer une fonctionnalité, à travers une User Story aucun langage de programmation ne vient se mettre au milieu : « En tant que client, je veux pouvoir télécharger ma facture en PDF pour la conserver chez moi » Est-ce que tu va utiliser une librairie genre TCPDF, et le générer à la volée ? Est ce que tu vas conserver le fichier, et vérifier si il y a eu des changements la prochaine fois pour éviter de le générer à nouveau ? Comment dimensionner la prod si tu gardes les fichiers ? Quel impact sur les snapshots ou les rsync automatiques ? Ce sont des questions qui n’ont pas leur place à ce moment là, tu dois te forcer à ne pas penser à l’implémentation, sinon ta conception va être biaisée. Tu dois apprendre ou réapprendre à réfléchir à la conception, sans penser à ton langage. Je précise ici que la « conception » pour moi est le moment où tu imagines ton logiciel, ou tu réfléchis à ce dont tu as besoin, gérer des utilisateurs, des commandes, des factures etc. La conception que tu peux modéliser avec UML, ou merise par exemple. Mais pour faire ça il faut connaître les principes de base, le socle commun, ce que Benoît Gantaume nomme « les compétences profondes », par exemples: les principes de programmation orientée objet, les design pattern …

5 – Conclusion:

    Un développeur est un professionnel capable de s’imprégner du métier pour lequel il crée un logiciel, de concevoir les solutions aux problèmes posés, et d’imaginer les fonctionnalités nécessaires de manière agnostique, sans penser à l’implémentation.      Quelles sont les fonctionnalités que je dois produire pour satisfaire les besoins des utilisateurs.     Au final il implémentera ce qu’il a imaginé de la meilleur manière possible en utilisant les techniques, langages, framework les plus adaptés.          En aucun cas je ne minimise l’investissement et le temps passé à apprendre à coder, je ne dénigre pas le contenu des formations de ce genre, et je suis très content qu’elles puissent permettre des réorientations ou des prises de postes assez rapides dans le domaine.          Et pour finir la bonne nouvelle, si tu as appris à coder, il ne te reste plus qu’à continuer ta formation pour devenir développeur, apprendre la POO, les design pattern, le clean code, les bonnes pratiques … Ce fameux socle qui te permettra d’évoluer de « codeur en langage X » à « développeur », et les ressources ne manquent pas 🙂

  Je t’invite a écouter le podcast de Benoit Gantaume sur le sujet , et l’échange entre Benoit et JP Lambert sur la chaîne scrum life. https://www.youtube.com/watch?v=xcrKO5-R03Y