PierreTurnbull

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: "" } })
});

PierreTurnbull

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)

PierreTurnbull

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

PierreTurnbull

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

PierreTurnbull

# 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

PierreTurnbull

# 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

PierreTurnbull

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

PierreTurnbull

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;

PierreTurnbull

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
},
{

PierreTurnbull

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