Skip to content

Instantly share code, notes, and snippets.

Avatar
🐻
hi

Pierre Turnbull PierreTurnbull

🐻
hi
View GitHub Profile
View script mongo.js
use prod;
accounts = db.accounts.find().toArray();
accounts.forEach(account => {
accountId = account._id
account.deactivatedUsecases = account.desactivatedUsecases
db.accounts.updateOne({ _id: accountId }, { $set: account })
db.accounts.updateOne({ _id: accountId }, { $unset: { desactivatedUsecases: "" } })
});
View normes.md

Normes

  • noms de variables :
    • formatés :
      • pour les booléens, utiliser un nom qui correspond explicitement à un booléen. ex : isActive (on sait au premier coup d'oeil que la variable contient soit true soit false, pas { name: 'Bob' } ou 51
      • pour les fonctions, un verbe. ex : getFormattedItems
      • pour les listes, item + 's'. ex : users
    • compréhensibles au premier coup d'oeil.
      • la liste de noms des utilisateurs actifs => activeUserNames plutôt que names ou actives
      • pertinence par rapport au contexte. Ex : items.map(item => item.a) plutôt que items.map(x => x.a)
View workflow revues.md
  1. le reviewer fait des commentaires
  2. l'auteur effectue des changements puis inscrit le numéro du commit en réponse, ou répond par commentaire si pas de changements nécessaires.
  3. lorsque l'auteur a répondu à tous les commentaires d'un reviewer, il lui refait une demande de revue
  4. l'auteur regarde les changements faits. Grâce aux numéros de commit en commentaires, il peut très facilement voir les changements faits, et tout le monde peut s'y retrouver plus facilement.
  5. si l'auteur trouve encore des choses à redire, on revient à l'étape 1. : le reviewer rajoute un commentaire dans un fil si besoin, ou refait un nouveau fil. Il marque comme "résolues" les fils qui le sont. C'est à lui de les marquer comme tel et pas à l'auteur de la PR, le but étant qu'un fil ne soit "résolu" que lorsque les 2 parties sont d'accord.
  6. si les changements conviennent au reviewer, il approuve la PR
  7. l'auteur peut merge lorsque les reviewers ont accepté sa PR

Note : les reviewers peuvent s'inscrire comme "assignees" sur l

View Git conflict resolution.md

Initial situation

We need to merge branch1 and branch2 on master. First, we'll update each branch from master in order to fix potential conflicts. Then we'll merge the branches on master.

          7 - 8 branch2
         /
1 - 2 - 4 - 9 master
View branch dependency.md
# branch1 comes from master's head.
# branch1 is not integrated on master yet but we need to create branch2 that depends on branch1.
# this gist shows how to work on branch2 and then integrate it on master.

# initial situation:
# 
# 1 - 2 - 3 - 4 master
#          \
#           5 - 6 branch1
View logs.sh
# display filtered logs from a Docker container
function dcl () {
# display logs
docker logs $(docker ps | grep $1 | head -c 12) |
# filter by keyword (ex: clientId)
if [ -z "$2" ]
then
cat
else
View suggestions_normes.md

ESLint

Linter = affiche des erreurs ou warnings lorsque certaines normes ne sont pas respectées.

Utiliser es-lint:recommended pour avoir une config de base standard.

Ajouter :

  • no-unused-expressions
  • no-useless-concat
View migration-script.sql
delimiter $$
drop procedure if exists migrate_forecasts $$
create procedure migrate_forecasts(instance_id int, user_id int, fx1_id int, fx2_id int)
begin
declare f1id int default null;
declare f2id int default null;
declare f1p int default null;
declare f2p int default null;
declare forecast_to_keep_id int default null;
View hello
distanceMatrix = [{
'Av. Vieira Souto, 168 - Ipanema, Rio de Janeiro - RJ, 22420-004, Brazil': 'ZERO_RESULTS'
},
{
'Rynek Główny 12, 33-332 Kraków, Poland': 1540493
},
{
'27 Derb Lferrane, Marrakech 40000, Morocco': 2539727
},
{
View Basic Workflow
FROM MASTER BRANCH:
// create a new branch and navigate to it
git checkout -b branch_name
// stage the current directory
git add .
// commit the staged files with a message
git commit -m "message"
// navigate to the branch master
git checkout master