Virer le thème sombre de MacOS pour une application spécifique.

On va pas se mentir, le thème sombre de MacOS Mojave c’est vraiment cool. Malheureusement, certaines applications tierces ne sont absolument pas, mais alors absolument pas pensées pour le thème sombre…

Prenons par exemple MySQL Workbench :

Voilà qui donne quand même bien envie de se laver les yeux à l’acétone. Le tableau de résultat des lignes est tout simplement illisible.

Heureusement il existe une commande magique permettant d’exclure une application du DarkTheme.

D’abord vous devez trouvez l’ID de l’application que vous souhaitez exclure. Pour cela dans un terminal, tapez :

Note : Vous pouvez remplacer ‘MYSQLWorkbench’ par le nom de l’application telle qu’elle apparait dans le dossier « Applications » de votre Mac.

Pour MySQL Workbench, ca donne un résultat du style :

Il ne vous reste plus qu’à exclure cette application du DarkTheme avec la commande suivante :

Relancez l’application et bim !!

Si vous voulez que ça vous repique les yeux, vous pouvez faire sauter ce réglage avec la commande suivante :

Allez, maintenant vous savez comment prendre soin de vos yeux !

Gestion de projet avec Gitlab

Ces derniers jours nous avons utilisé Gitlab pour gérer nos projets.

Cette nouvelle approche permet au codeur d’être à la fois plus rigoureux dans la façon d’écrire son code mais aussi de monter en compétence car chaque ligne de code que vous écrivez sera relu et analysé par un autre membre de votre équipe.

Au niveau de l’équipe, cette gestion de projet permet de travailler ensemble et de façon asynchrone sur une même étape importante du projet (Milestone/Iteration).

L’énorme avantage de cette approche est de pouvoir créer, attribuer et gérer des taches qui sont intimement liées au code du projet. C’est à dire de créer une tâche, l’attribuer à un codeur et la lier de façon quasi automatique à une branche de travail. Le codeur pourra ainsi travailler sur cette tâche sans gêner ou ralentir ses collègues, même si ils travaillent sur des parties de code extrêmement proches.

 

LES ISSUES

Sur le même modèle qu’un KANBAN, les issues sont les tâches a faire.

Elles peuvent être attribuées à une ou plusieurs personnes.

Différents Labels (statuts) peuvent leur être assignés, Open, To Do, Doing, Review et Closed

Dans chaque issue, les différents membres de l’équipe peuvent partager et discuter sur la mise en oeuvre de la fonctionnalité demandé.

Chaque issue peut être lié ou non à une milestone (étape importante du projet). La milestone est terminé lorsque toutes les issues lié à cette dernière on été close.

Elles permettent également de créer en un seul clic, une Merge Request et la branche de travail associée.

LE BOARD

Les Board est semblable à un trello. On peut déplacer les différentes issues de labels en labels en fonction de leur avancement.

LES MERGE REQUESTS

Lorsqu’une issue a été prise ou attribuée à une personne, qu’elle est passé en Doing et que la merge request a été ouverte. Le codeur n’a plus qu’a aller travailler sur la branche associée de cette dernière.

Chaque merge request permet de :

  • Comparer les changements entre deux branches lors des codes review
  • Examiner et discuter des modifications proposées en ligne
  • Aperçu en direct des modifications
  • Empêcher de merger grace au status WIP
  • Résoudre automatiquement les problèmes de fusion.
  • Résoudre les conflits de fusion à partir de l’interface utilisateur
  • Squash les commits pour un historique plus propre

 

LE PROCESS A SUIVRE

Maintenant que les différentes couches de cette nouvelle approche de gestion de projet on été vue. Voici le process à suivre pour l’intégrer efficacement dans votre quotidien.

1 – Prendre une issue:

Si la tâche ne vous a pas encore été attribuée, allez dans le Board voir les issues qui sont dans le label To Do.

Sélectionnez l’issue désiré, lisez la en détail et attribuez la vous.

2 – Commencer à travailler:

Une fois l’issue attribuée à votre nom et que vous voulez commencer à travailler dessus.

Dans le Board glissez la dans Doing.

Ouvrez l’issue,  et cliquer sur Create Merge Request

Une merge request avec le satut WIP est crée automatiquement, la branche de travail associé à cette dernière a également été crée.

3 – Dans votre terminal:

Passez sur la branche Develop.

Faites un git pull. La nouvelle branche que vous venez de créer a été rapatrié.

Faites un git checkout votre-nouvelle-branche

4 – CODER

Faites des git commit/ push de temps en temps, le code sera pousser sur la branche de travail.

Faites également un git commit dès que vous voulez changez de branche

5 – Passer en Review:

Une fois que les demandes de l’issue ont été complétées.

git commit, git push votre code.

Allez voir dans GitLab votre Merge Request.

Il se peut que vous ayez des Merge Conflit. Vous pouvez tenter de les résoudre automatiquement sur GitLab.

Sinon dans votre terminal.

git commit votre travail

Puis faites un git checkout develop

un git pull

retournez sur votre branche de travail avec un git checkout votre-nouvelle-branche

git rebase develop, des merge conflits sont apparus!

Résolvez les.

git rebase –continue

git commit, git push -f

Retournez voir dans GitLab, votre problème de Merge Conflit a disparu.

Cliquez sur Resolve Wip Status, pour montrer que le travail est terminer pour cette merge request.

Passez également le status de la MR en Review

Allez également dans le Board et glisser l’issue concerné dans le label Review.

6 – Attendre les retours de la Review

Si vous avez des retours fait par votre reviewer reprenez à l’étape 4

(Pensez à close les discussions pour chaque commentaire fait lorsque vous avez résolu le problème.)

Si aucun retour sur votre Merge Request n’a été fait, votre reviewer fera le Merge.

7 – Reprendre à l’étape 1 jusqu’à avoir fini la Milestone

 

Vous êtes Reviewer:

Allez voir dans le Board les issues qui sont dans le label Review.

Sélectionnez en une.

Ouvrez la Merge Request associée. Vérifiez qu’il n’y a plus le statut WIP et qu’il n’y a pas de Merge Conflict. Sinon renvoyez au codeur.

Lisez dans Changes le nouveau code. Cliquez sur une ligne pour y laisser un commentaire si vous avez une question sur le fonctionnement ou une proposition de changement. Veuillez à que votre commentaire soit toujours bienveillant envers le codeur. Enseignez les bonnes pratiques.

Le codeur sera notifié de vos commentaires et saura qu’il doit retourner modifier son code.

Une fois que tout les changements on été effectués et que la Merge Request est parfaite à vos yeux. Vous pouvez merger.

Avant de Merge, pensez à sélectionner Remove Source Branch pour supprimer automatiquement la branche lié à la merge request et Squash Commits pour ne pousser qu’un seul commit dans la branche develop. (Ce commit portera le nom de la merge request)

 

 

 

 

 

v-validate et champs input

En utilisant vee-validate pour vérifier la présence de champs obligatoire d’un formulaire je me suis aperçu d’un problème, en testant le formulaire je ne pouvais écrire dans un de mes champs input sur mobile.

La fonctionnalité marchant très bien sur desktop, et pire encore elle marche parfaitement sur les autre champs du formulaire.

 

après plusieurs essais et plusieurs recherches google, il s’avère que le  problème viens de l’attribut v-validate. et je suis tombé sur un article intéressant qui nous raconte que le problème est connu, et que sur certain mobile, particulièrement sous chrome, le v-model n’est pas mis à jour en temps réel, et donc le v-validate n’arrive pas à gérer.

pour contourner le soucis on peut ajouter :

cela permet d’attendre que le model sois setter.

Dans mon cas cela a corrigé le problème sous chrome sur mobile.

 

Source : https://stackoverflow.com/questions/53538068/vuejs-form-validation-with-veevalidate-cant-type-on-some-mobile-devices

 

Stubber / mocker request.remote_ip

Pour faker une adresse IP d’appel, j’utilisais ça :
Seulement, Rubocop n’était pas content. Avec ça,
Rubocop est content, et c’est la manière la plus simple de le faire 😉

Overcommit, l’alternative facile aux git hooks

Plusieurs fois j’ai eu recours aux git hooks mais je ne trouve pas ça forcément pratique ou simple à écrire.

Premier exemple d’utilisation, ayant intégré rubocop dans le CI/CD, j’aimerais ne pas rater de livraison parce que j’ai oublié de lancer rubocop (ou rspec par exemple), avant de pousser le code.

Deuxième exemple, il m’arrive de bidouiller le code en local pour des tests par exemple (changer une adresse mail de destination, mettre des console log, des alert, etc).

Et évidemment, ce genre de chose ne doit pas se retrouver en prod. Ayant une mémoire de bébé poisson rouge, une fois sur deux, je push du code qui ne devrait pas aller en prod…

Continuer la lecture de « Overcommit, l’alternative facile aux git hooks »

Le Gemfile et bundler

Le Gemfile c’est bien et Bundler c’est formidable.

Gemfile

Avec le Gemfile, on peut (+/-) fixer (ou pas, au choix), les versions des gems utilisées.

Pour ça, plusieurs syntaxes sont possibles, un exemple étant bien plus parlant :

~> 2.0.3 équivaut à >= 2.0.3 et < 2.1.

~> 2.1 équivaut à >= 2.1 et < 3.0.

Bundle install

Petit rappel, lors d’un bundle install, bundler résout exlusivement les nouvelles versions de gems non résolues dans le Gemfile.lock.

Options dispos/utiles :
–clean Efface toutes les traces des gems non utilisées
–quiet pas de log durant l’installation
–without liste séparée par des espaces des gems à skip, combinable avec –with

Bundle update

Options dispos/utiles :
–group met à jour exclusivement les gems de ce group
–force redownload toutes les gems
–patch, –minor, –major met à jour s’il trouve une nouvelle patch, minor ou major

# Command Line Result
————————————————————
1 bundle update –patch ‘foo 1.4.5’, ‘bar 2.1.1’
2 bundle update –patch foo ‘foo 1.4.5’, ‘bar 2.1.1’
3 bundle update –minor ‘foo 1.5.1’, ‘bar 3.0.0’

Bundle exec

Toujours utiliser bundle exec, qui utilise exclusivement les gems du projet et pas celles du système.
Cela permet d’assurer une cohérence plus pointue entre les différents environnements, et d’être en corrélation avec le Gemfile.

Bundle add

Permet d’ajouter une gem dans le Gemfile tout en spécifiant sa version (la dernière publiée si pas spécifiée lors de la commande) ET de faire le bundle install
Top pour encore une fois garder de la cohérence et ne biaiser un bundle update malencontreux

Options dispos/utiles
–version, -v spécifie la version
–group, -g spécifie le/les groupes
–source, -s spécifie la source si différente de la source du Gemfile

Bundle clean

Permet de supprimer les gems non utilisées du dossier bundler (ATTENTION à où sont installées les gems, et qui/quoi les utilise !!)
–dry-run pour avoir une idée de ce qui va être supprimé

 

Avoir l’inspecteur web d’un smartphone sur son PC / Mac

  • Brancher le smartphone au pc avec un câble usb
  • Activer l’inspecteur web sur le device
    • Sur iOs :
      • Aller dans Réglages
      • Puis dans Safari
      • Puis dans Avancé
      • Et activer l’inspecteur web
    • Sur Android :
      • Aller dans Paramètres
      • Puis dans À propos du téléphone (tout en bas)
      • Cliquer plusieurs fois sur Numéro de build jusqu’à « être développeur »
      • Retour dans Paramètres
      • Dans Options développeurs
      • Activer le Débogage usb
  • Accéder à l’inspecteur
    • Pour iOs :
      • Ouvrir Safari
      • Dans l’onglet développement
      • Choisir le device et l’onglet concerné
    • Pour Android :
      • Ouvrir Chrome
      • Ouvrir l’inspecteur Web (Chrome DevTools)
      • Dans les options du Chrome DevTools
      • Cliquer sur More Tools
      • Remote devices
      • Choisir son device et accepter la demande d’autorisation sur le device
      • Cliquer sur le Inspect de l’onglet désiré

Ruby 2.1.5 avec Rbenv et Ubuntu 16.04

L’autre jour j’ai eu besoin d’intervenir sur un ancien projet Rails, qui tourne sur un serveur en Ruby 2.1.5 (sortie en novembre 2014, et sans support depuis mars 2017).

Avant d’envisager une montée de version, il fallait déjà que j’arrive à tester la version actuelle. Je pensais l’affaire rapide avec Rbenv : rbenv install 2.1.5  et le tour était joué.

Vous vous en doutez, la commande a échouée lamentablement. En regardant les logs j’ai compris que le problème était lié au paquet libssl-dev

/usr/include/openssl/asn1_mac.h:10:2: error: #error « This file is obsolete; please update your software. »

Grâce à Google, j’ai compris d’où venait mon problème : les anciennes versions de Ruby (inférieures à la version 2.3) ne sont compatibles qu’avec la version 1.0 du paquet libssl-dev.

Hors Ubuntu 16.04 est fourni avec le paquet en version 1.1.0. Il a donc fallu que je downgrade en version 1.0 le paquet fautif avec la commande suivante

J’ai pu ensuite installer Ruby 2.1.5 avec Rbenv tout simplement.