Choix de mon éditeur de code

Visual Studio Code

La première question à se poser dans un premier temps est: pourquoi changer d’éditeur de code ?

Effectivement, j’ai précédemment parlé d’utiliser des outils connus pour mon projet perso. Pourquoi ne pas suivre cette règle pour tous les outils utilisés en y incluant mon éditeur de code ?

La réponse est simple : je ne suis pas 100% satisfait avec mes précédentes expériences.

Voici la liste des prétendants

NotePad++ et Context

Je met ces deux dans le même panier car ils sont pour moi de très bon éditeur de texte que j’ai longuement utilisé par le passé mais que j’ai assez rapidement remplacé par Sublime Text. Je n’ai pas vraiment de commentaire négatif à faire mais peux être que les autres outils sont plus répandu et que j’ai naturellement été influencé. A tord ou a raison, …

Sublime text

Magnifique éditeur, j’étais à deux doigts d’acquérir la licence après une petite période de teste plutôt concluante. L’éditeur est rapide, multi-plateforme, « beau », propose de nombreux plugins et est régulièrement mis à jour. Il dispose d’une bonne visibilité dans la communauté des développeurs ou il est régulièrement mis en concurrence avec Atom. Ce qu’il manque à mon sens est une intégration « parfaite est simple » avec la ligne de commande ainsi qu’une bonne intégration de GIT.

Atom

Il a beau être resté longtemps installé sur mes différentes machines, je ne l’ai que très peu utilisé. Son éviction peut donc paraître sévère, mais il possède pour moi la pire des tares à aujourd’hui : la lenteur à l’ouverture ! Pourtant utilisé installé sur des disques SSD, avec des machines plutôt puissantes, rien n’y fait. La désinstallation de certains modules n’a pas aidé. Mes recherches sur Google ont été fatales à Atom, mettant en exergue mon ressenti. Certes la promesse est belle, mais la lenteur d’ouverture du soft est pour moi rédhibitoire !

Visual Studio Code

Arrivant en fin de test, c’est celui que j’ai retenu pour mon projet perso. Il regroupe pour moins tous les points forts des deux précédents et se targue d’une merveilleuse intégration de GIT et de la ligne de commande. Pour l’instant, il fait réellement mon bonheur pour écrire mon code PHP/Symfony.

Le choix de mon éditeur de code est donc fait : Visual Studio Code

Symfony 3, retour au PHP

Logo Symfony

Et le JavaScript dans tout ça ?

Effectivement, je retourne rapidement ma veste. Je passe en une semaine de JavaScript à PHP. (Sans compter qu’il y a un mois j’étais à fond dans le Ruby !

Révélation !

Au cours de mes nombreuses lectures, je suis tombé sur nombres d’articles vantant le mérite d’un projet personnel pour l’apprentissage d’une nouvelle techno. Je pense, et c’est ce que j’ai souvent fait, que c’est effectivement le meilleur moyen d’apprendre que de se mettre en situation concrète.

Et si je faisais ce projet dont je parle depuis maintenant 2 ans ?

Pas bête ! sachant que mon objectif global plus que d’apprendre une techno en particulier et de revoir mes compétences globales (et de les mètres à jour) sur le scope complet d’une application « moderne ».

Partir sur des bases connues pour un résultat sûr !

D’autres lectures (je ne lisais visiblement pas assez avant) ont réussi à me faire comprendre que si l’on veut réellement délivrer un projet perso, il était plus sur de partir sur des technologies connues plutôt que sur de la découverte absolut. L’idée globale étant qu’il vaut mieux délivrer une partie pas folichonne et non complète que rien du tout !

Virage à 180°

C’est donc comme ça que j’ai mis de côté certaines de mes expériences notamment avec Ruby pour revenir à mes fondamentaux : le PHP !

Symfony

Le choix du framework a été tout comme le choix du langage vite réglé par mes précédents travaux. L’envie de découvrir Laravel a été forte, mais par sagesse, je suis retourné à mon premier amour : Symfony. La bonne nouvelle c’est que je vais quand même avoir le droit à certaines nouveautés (je l’espère) puisque que Symfony est maintenant en version 3 et PHP en version 7 !

Il ne reste plus qu’à repartir de 0 pour ne pas commettre les erreurs du passé !

JavaScript world – mon « Hello World »

JavaScript

alert(‘Hello, JavaScript’)

Eh oui, il existe encore des gens qui en 2017 ne se sont pas mis au JavaScript. Pour moi, il n’y a aucune réticence technologique, mais simplement aucune opportunité professionnelle ou personnelle ne m’y a conduit.

2017 l’année du JavaScript ?

Mais, évidemment, les années passent et les temps changent. La fin d’année 2016 aura été le théâtre de quelques changements professionnels et certaines opportunités se sont ouvertes. Et avec elles a fait surface le « merveilleux » monde du JavaScript. Je me lance donc en ce début d’année dans ce monde obscur et tortueux avec pour objectif d’y faire mes premiers pas en partant d’à peux près 0. –> Tout le monde est passé par là à un moment ou à un autre alors pourquoi pas moi ?

Par où commencer ?

React ? Angular ? Node ? Babel ? ES6/7 ? Redux ? DOM ? … que des noms déjà entendus, mais tout n’est pas complètement claire encore. L’objectif est donc d’y voir un peut plus claire et d’avancer petit à petit dans cet environnement riche ou il est assez facile de se perdre.

Dans mes premières lectures techniques de l’année figure l’article de Sacha Greif « A Study Plan To Cure JavaScript Fatigue »

JavaScript Study plan
JavaScript Study plan

Tout n’est pas encore limpide, mais je vais m’orienter vers les bases de React.js pour dans un premier temps, voir à quoi cela ressemble et les possibilités du JavaScript.

Il est temps de mettre les mains dans le cambouis !

Ruby : Préparation de l’environnement de développement

Logo Ruby

Choix des outils

Rentrons maintenant dans le vif du sujet. Après avoir passé ma machine principale sous ubuntu spécialement pour faire du dev en Ruby On Rails, il faut maintenant la préparer. Faisons tout d’abord le point de ce qui est nécessaire.

  • Un éditeur de code ou environnement de développement intégré
  • Un gestionnaire de version
  • L’interpréteur et les librairies propres au langage

N’étant pas un expert, j’ai plus ou moins fouiné sur le net pour trouver quels étaient les outils les plus utilisé par les développeurs Ruby actuels.   Ceci m’a amené à construire mon environnement de la sorte :

  • Sublime text 3 pour mon éditeur
  • Git pour la gestion de version
  • Rbenv comme gestionnaire de version RUBY

Tout ceci n’a rien de vraiment farfelu et c’est bien là l’intérêt afin de trouver rapidement de l’aide au besoin.

L’installation

Pour rappel, je suis passé sous linux pour m’éviter tous les problèmes de configuration et d’installation de l’environnement de développement pour Ruby. Voyons donc comment tout cela se passe sous ubuntu.

  • Sublime Text 3

Pourquoi sublime texte ? Parce que je suis tombé dessus par hasard en cherchant une alternative à Notepad++ qui soit multi plateforme. J’ai essayé, j’ai adopté. Tout simplement.

Pour l’installation, rien de plus simple. Rendez-vous sur le site officiel : http://www.sublimetext.com/, télécharger la version 64bits linux puis avec le gestionnaire de paquet Ubuntu, il n’y a plus qu’à faire « Installer »

  • Installer Git

La magie de linux opère déjà. La simplification de l’installation est poussée à l’extrême grâce au gestionnaire de paquet Apt. Seulement deux actions sont à faire. Tout d’abord mettre à jour le catalogue d’apt et ensuite installer le paquet désiré. Pour ce faire, très simplement :

sudo apt-get update

sudo apt-get install git

Et voilà ! C’est encore plus rapide et simple que sous Windows. Avant de pouvoir utiliser Git, il reste deux petites configuration a effectué mais rien de bien méchant. Il faut simplement dire à Git qui vous êtes en renseignant votre nom et votre email qui seront vos identifiants Git. Tout aussi simplement, deux petites lignes de commandes suffisent :

git config --global user.name "Your Name"

git config --global user.email "youremail@domain.com"

Et voilà rien de plus, nous somme prête à faire du versionning avec Git.

  • Installer Rbenv

Il ne reste maintenant « que » le plus gros morceau. L’installation du Ruby lui-même. En effet, sans Ruby sur la machine, il est plutôt compliquer de développer avec. Pour sons installation, de par ses différentes versions et la nécessité de vouloir développer et gérer différents environnement avec différentes version, les développeurs Ruby font souvent le choix d’un gestionnaire de version Ruby.

Je ne pense pas avoir besoin de ça tout de suite ne travaillant pas sur 50 projets à la fois mais autant prendre de bonnes habitudes le plus vite possibles.

Dans un premier temps, on va installer certaines dépendances de Ruby qui seront régulièrement utilisée par les gem Ruby. Autant s’en occuper tout de suite.

sudo apt-get install git-core curl zlib1g-dev build-essential libssl-dev libreadline-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt1-dev libcurl4-openssl-dev python-software-properties libffi-dev

Passons maintenant à l’installation de rbenv. L’idée est d’utiliser notre nouvel outil « Git » pour récupérer la dernière version sur le dépôt de l’auteur. Cette fois, les commandes peuvent paraitre un peu barbare mais rien de bien compliquer en définitive :

git clone git://github.com/sstephenson/rbenv.git .rbenv

echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc

echo 'eval "$(rbenv init -)"' >> ~/.bashrc

exec $SHELL

Une dernière petite manipulation afin d’installer ruby-build qui sert à « compiler » les différents gem de Ruby. Et nous seront fin prêt !

git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

echo 'export PATH="$HOME/.rbenv/plugins/ruby-build/bin:$PATH"' >> ~/.bashrc

exec $SHELL

Nous allons maintenant pouvoir installer la dernière version de Ruby et la définir comme la version « global » de notre environnement :

rbenv install 2.2.3

rbenv global 2.2.3

Les problèmes commencent

ruby –v

Petit problème, la dernière commande qui aurait-du me donner la version de Ruby installé (soit 2.2.3) ne me renvoi un message pas sympa du tout :

roxanne7@roxyfix:~$ ruby -v

Le programme « ruby » n’est pas encore installé. Vous pouvez l’installer en tapant :

sudo apt-get install ruby

Si tout ne marche pas comme prévu, c’est que j’ai dû merder à un moment !

Welcome to linux me dis-je enfin !

Bon, en cherchant dans mon arborescence là ou « devrait » être installé Ruby, je verrais bien si celui-ci est installé …

InstallRubyCheck

Tout m’a l’air d’être bien installé. Petite vérification pour savoir si ruby marche :

rubyV_Ok

Le verdict tombe, mon shell ne connait pas le chemin de l’exécutable Ruby via rbenv. Dans la documentation de rbenv, c’est l’ajout de la ligne suivant qui permet de rediriger le path vers la bonne version de Ruby :

'eval "$(rbenv init -)"

 

Il faut donc maintenant chercher dans les différents fichiers qui chargent les paramètres du shell pour voir si cette ligne a bien été rajoutée et si ces fichiers ne se marchent pas dessus …

Le fichier ~/.bashrc contient bien les lignes gérant le PATH. Mais la surprise provient du fichier .bash_profile qui contient aussi quelques lignes pour mon PATH et rbenv … louche !

bash_profile

Certaines recherche vont m’apprendre que la présence de ce fichier empêche le chargement d’autres fichiers de profile. La solution serait donc de supprimer ce fichier.

Holà holà … Mais il vient d’où ce fichier ?

Probablement d’une mauvaise manip de ma part. En relisant la différente doc que j’ai lu pour arriver à mes fins ainsi que l’heure de création du fichier, la sentence est tombée : je suis fautif du syndrome du copier-coller sans réfléchir !

Solution simple :

remove_bash_profile

Résultat :

rbenv_marche

Ca y est, Ruby est donc installé et fonctionnel !

Les petits plus à faire par la suite :

echo "gem: --no-ri --no-rdoc" > ~/.gemrc

gem install bundler


install_bundler