pr
git checkout gh_fork
git merge ma_branche
git commit -am ..
# git rebase ?
git push
Aller sur github, faire la PR, ou scripter l'api
pr par mail
git checkout mabranche
git rp | mail
Dans le cas d'une pr par mail, c'est l'upstream qui fera ton job de merge, de réconciliation et de rebase.
Alors que pour une pr plus classique, l'ui lui indiquera immédiatement si les commits sont en conflits, il n'aura qu'à faire sa petite revue de code pépère, si il a branché les hooks travis / , il aura ses résultats de CI automatiquement, et puis si il est content un coup de clic et zou c'est fini.
celui-ci devrait se débrouiller pour se synchroniser tout seul avec l'upstream.
Comment feras tu lorsque les versions auront suffisamment divergées pour nécessiter une réconciliation manuelle ?
Si tu veux juste faire un fetch en local, alors oui, un cron suffira, mais pour intégrer les changements dans ton local, un merge sera nécessaire, donc, éventuellement, réconciliation manuelle.
je peux faire la même chose avec du libre décentralisé
Je ne sais pas ce que c'est "la sortie de git request pull", j'ai dans l'idée que man git diff est ton ami.
Voir au préalable si l'upstream sera d'accord avec cette manière de procéder, et par ailleurs si tes changements l'intéresse d'une manière ou d'une autre.
créer un cron
Je doutes beaucoup sur cette option.
Je doutes beaucoup moins de la procédure usuelle qui consiste à faire un fetch, suivi d'un merge, éventuellement résoudre les conflits, puis générer un commit.
Sinon, c'est quoi le problème avec github au fait ?
Le truc c'est que tu te bats pour des idées dans un environnement qui n'en a que peu à foutre.
Tu es tout le temps tiraillé entre tes obligations de chef d'entreprise et tes désirs de citoyens participatif intelligent.
Alors la question que j'ai envie de poser est la suivante, en tant que personne responsable et réfléchie, penses tu qu'il vaille mieux se battre corps et âmes pour une idée dans un combat à l'effet marginal (selon moi hein), ou bien faut il re penser la question pour s'attaquer à la difficulté de fond afin de faire établir ces idées comme principe ?
Ici a et b partage le même contexte, une variable déclarée dans a est accessible dans b, vis-et-versa.
Donc au départ cette syntaxe apparait pour éviter les conflits de nommage de variable entre deux scripts de sources distincts (exemple, les scripts d'analytique chargés par dizaine sur certains sites).
A l'époque c'était une avancée appréciable, et appréciée.
Il faut préciser aussi que cette structure a était utilisée à un moment donné pour des boucles for mal foutu, exemple,
Pour en revenir à IIFE (Immediately Invoked Function Expression) les parenthèses '()' sont là pour appeler l'exécution de la fonction définie.
On peut en avoir plusieurs par scripts, donc ce n'est même pas l'équivalent stricte d'un main.
Par contre, en pratique, on s'en sert par convention comme un genre de main, en effet.
Cette structure (f(){})() semble être l'équivalent des blocs en C comme tu le cites.
Pour finir, cette structure tant à être désuète car on utilise de plus en plus des modules de chargement qui encapsule automatiquement le code dans une fonction pour éviter ces effets de bords d'écrasement de variable (cf AMD, require.js etc), et d'autres trucs.
Par ailleurs, avec node, c'est automatique, puisque l'utilisation de require fais ce travail.
En ce qui me concerne, est ce que c'est beau, est ce que c'est bien : osef.
Lorsque j'écris du node, je n'ai jamais besoin de celle ci,
Lorsque j'écris du web, j'utilise un système de build, donc je n'en ai pas besoin non plus et le cas de la boucle for sus cité, c'est vraiment de la m**** d'écrire ce code.
quand à savoir si un main serait utile à JS, bof, si j’arrive pas à trouver le main d'un script, je préfère faire autre chose que de m'en servir.
nvm ls
v0.12.13
v4.0.0
v5.0.0
v5.7.1
-> v6.0.0
v6.1.0
system
default -> 5.0 (-> v5.0.0)
node -> stable (-> v6.1.0) (default)
stable -> 6.1 (-> v6.1.0) (default)
iojs -> N/A (default)
[mh-cbon@pc15-home nsi-pl] $ nvm use 5.7.1
Now using node v5.7.1 (npm v3.6.0)
[mh-cbon@pc15-home nsi-pl] $ node err.js
Error: ENOENT: no such file or directory, open '.npmignore'
at Error (native)
[mh-cbon@pc15-home nsi-pl] $ nvm use 4.0.0
Now using node v4.0.0 (npm v2.14.2)
[mh-cbon@pc15-home nsi-pl] $ node err.js
Error: ENOENT: no such file or directory, open '.npmignore'
at Error (native)
[mh-cbon@pc15-home nsi-pl] $ node err.js
Error: ENOENT: no such file or directory, open '.npmignore'
at Error (native)
{ [Error: ENOENT: no such file or directory, open '.npmignore'] errno: -2, code: 'ENOENT', syscall: 'open', path: '.npmignore' }
[mh-cbon@pc15-home nsi-pl] $ node err.js
Error: ENOENT: no such file or directory, open '.npmignore'
at Error (native)
{ [Error: ENOENT: no such file or directory, open '.npmignore'] errno: -2, code: 'ENOENT', syscall: 'open', path: '.npmignore' }
/home/mh-cbon/projects/nsi-pl/err.js:10
throw err
^
Error: ENOENT: no such file or directory, open '.npmignore'
at Error (native)
[mh-cbon@pc15-home nsi-pl] $
var async = require('async')
var fs = require('fs')
var stream = require('stream')
var source
var stream = fs.createReadStream('.npmignore').on('error', function (err) {
console.log(err.stack)
console.log(err)
throw err
})
async/await ? Très peu pour moi ! Oui je parlais du module async.
si on a déjà une copie du fichier en local, on va utiliser cette copie, sinon on va passer par le réseau pour récupérer le fichier depuis le serveur.
En fait ce sera plus simple avec un through.
function streamDuFichierParIciOuLaBas(string) {
var stream = miss.through();
stream.pause();
// fais des trucs async ici pour trouver le fichier
// a un moment dans un callback
fn cb (){
srcStream.pipe(stream).resume();
}
// ou srcStream sera fs.readdable ou net.socket j'imagine.
return stream;
}
streamDuFichierParIciOuLaBas(string).pipe(streamDst);
Par contre, comme c'est un through et non un readable tu perds l'évènement close, tu n'auras plus que le 'end'
Pour le on('close') vs on('finish'), les deux donnent le même résultat ici. Ils ont une légère différence de signification, mais ce n'est pas important ici. Pour cozy-desktop, la sémantique de finish me convenait mieux.
J'avoue appliquer la chose bêtement. Si je veux savoir quand le fichier est écrit => close
La création du stream source est également plus compliqué : si on a déjà une copie du fichier en local, on va utiliser cette copie, sinon on va passer par le réseau pour récupérer le fichier depuis le serveur. Etc.
Pourquoi tu n'enrobes pas cette logique dans un readable ? Comme cela que le fichier existe, ou pas, tu pourrais faire tonStream('lefichier').pipe(…)
Tu pourrais réduire un peu toute cette complexité avec le async.
cf noms, ou mississippi, pour faire un readable rapidement.
Moi pendant ce temps je me demande pourquoi on parle d'angular sur un post au sujet de nodejs.
Et par ailleurs, pourquoi utiliserais je typescript pour écrire du code avec nodejs, puisqu'en ayant choisi ce langage, et cette plateforme, c'était en connaissance de cause, en fait par désir, de virer la contrainte du typage.
trop d'honneur, toutes ces remarques, pour quelqu'un qui n'était même pas fichu de mettre des retours à la ligne. A croire que celui-ci était souler de poster.
… Je n'ai pas utilisé mkfifo, ni de socket, pas plus que fd[4], j'ai balancé le token sur stdout, c'est moche, et après j'ai fais un peu de magie noire avec les streams.
En tout cas merci encore, j'ai appris des choses intéressantes !
Donc à priori seul teampass, et donc², il n'y a pas tellement d'alternatives.
En tout cas, merci.
Finalement, d'un point de vue technique celui qui me plait le plus c'est wkr, car c'est le seul à proposer
- un début d'api REST ré utilisable par d'autres
- une base de données rapide à setup (en l’occurrence un simple fichier json, donc c'est pas terrible pour le multi utilisateur, en tout cas ce n'est pas une dépendance à mysql) /gpass est pas trop mal sur le coup, c'est du sqlite/
- à la va vite je dirais que la dépendance à apache est optionnel, j'aime ça aussi.
en bref, ça tente personne de faire juste des api rest, et de laisser la vue à d'autres quand vous faites des projets web ? Ou de vraiment la séparer complètement, et intégralement.
[^] # Re: blah
Posté par mh-cbon . En réponse au message [Résolu] Comment gérer le fork d'un projet github dans une instance gitlab (framagit) ?. Évalué à -6.
J'avais vu la chose ainsi, ayant aussi fait la démarche de poser les commandes,
git clone gh.com/up/stream
git remote add upstream up/stream
git remote add gh git/hub
git remote add origin frama/git
git checkout -b gh_fork --track gh/master
travail
git checkout -b mabranche --track origin/master
touch…
git commit && git push
sync
git fetch upstream
git checkout mabranche
git merge upstream/master
pr
git checkout gh_fork
git merge ma_branche
git commit -am ..
# git rebase ?
git push
Aller sur github, faire la PR, ou scripter l'api
pr par mail
git checkout mabranche
git rp | mail
Dans le cas d'une pr par mail, c'est l'upstream qui fera ton job de merge, de réconciliation et de rebase.
Alors que pour une pr plus classique, l'ui lui indiquera immédiatement si les commits sont en conflits, il n'aura qu'à faire sa petite revue de code pépère, si il a branché les hooks travis / , il aura ses résultats de CI automatiquement, et puis si il est content un coup de clic et zou c'est fini.
Comment feras tu lorsque les versions auront suffisamment divergées pour nécessiter une réconciliation manuelle ?
Si tu veux juste faire un fetch en local, alors oui, un cron suffira, mais pour intégrer les changements dans ton local, un merge sera nécessaire, donc, éventuellement, réconciliation manuelle.
décentralisé ?
[^] # Re: blah
Posté par mh-cbon . En réponse au message [Résolu] Comment gérer le fork d'un projet github dans une instance gitlab (framagit) ?. Évalué à -6.
Peut être que ceci t’intéressera ?
https://developer.github.com/v3/pulls/#create-a-pull-request
Je pense toujours que c'est à ton upstream de te dire ce qu'il acceptera.
blah. Pourquoi pas. désaccord profond, flemme plus profonde encore.
Je ne comprends pas ce qui n'est pas simple :x
# blah
Posté par mh-cbon . En réponse au message [Résolu] Comment gérer le fork d'un projet github dans une instance gitlab (framagit) ?. Évalué à -3.
Dans les deux cas de tes deux solutions tu passeras par un remote upstream,
https://help.github.com/articles/configuring-a-remote-for-a-fork/
https://help.github.com/articles/syncing-a-fork/
Je ne sais pas ce que c'est "la sortie de git request pull", j'ai dans l'idée que
man git diff
est ton ami.Voir au préalable si l'upstream sera d'accord avec cette manière de procéder, et par ailleurs si tes changements l'intéresse d'une manière ou d'une autre.
Je doutes beaucoup sur cette option.
Je doutes beaucoup moins de la procédure usuelle qui consiste à faire un fetch, suivi d'un merge, éventuellement résoudre les conflits, puis générer un commit.
Sinon, c'est quoi le problème avec github au fait ?
# moi, ça me laisse pensif
Posté par mh-cbon . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à -8.
Le truc c'est que tu te bats pour des idées dans un environnement qui n'en a que peu à foutre.
Tu es tout le temps tiraillé entre tes obligations de chef d'entreprise et tes désirs de citoyens participatif intelligent.
Alors la question que j'ai envie de poser est la suivante, en tant que personne responsable et réfléchie, penses tu qu'il vaille mieux se battre corps et âmes pour une idée dans un combat à l'effet marginal (selon moi hein), ou bien faut il re penser la question pour s'attaquer à la difficulté de fond afin de faire établir ces idées comme principe ?
[^] # Re: En gros
Posté par mh-cbon . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à -10.
j'en pleure devant mon pc tellement c'est beau d'innocence
[^] # Re: Fonction
Posté par mh-cbon . En réponse au journal Plonk. Évalué à -2.
Si tant est que cela puisse aider…
Je crois qu'il faut rappeler dans quel contexte cette syntaxe à était popularisé.
Le problème est le suivant, sur une page web (node est un autre cas), les scripts sont chargés et appliquer au contexte global.
Ici a et b partage le même contexte, une variable déclarée dans a est accessible dans b, vis-et-versa.
Donc au départ cette syntaxe apparait pour éviter les conflits de nommage de variable entre deux scripts de sources distincts (exemple, les scripts d'analytique chargés par dizaine sur certains sites).
A l'époque c'était une avancée appréciable, et appréciée.
Il faut préciser aussi que cette structure a était utilisée à un moment donné pour des boucles
for
mal foutu, exemple,Résolution pourrie,
Résolution correcte,
Pour en revenir à IIFE (Immediately Invoked Function Expression) les parenthèses '()' sont là pour appeler l'exécution de la fonction définie.
On peut en avoir plusieurs par scripts, donc ce n'est même pas l'équivalent stricte d'un main.
Par contre, en pratique, on s'en sert par convention comme un genre de main, en effet.
Cette structure
(f(){})()
semble être l'équivalent des blocs en C comme tu le cites.Pour finir, cette structure tant à être désuète car on utilise de plus en plus des modules de chargement qui encapsule automatiquement le code dans une fonction pour éviter ces effets de bords d'écrasement de variable (cf AMD, require.js etc), et d'autres trucs.
Par ailleurs, avec node, c'est automatique, puisque l'utilisation de
require
fais ce travail.En ce qui me concerne, est ce que c'est beau, est ce que c'est bien : osef.
Lorsque j'écris du node, je n'ai jamais besoin de celle ci,
Lorsque j'écris du web, j'utilise un système de build, donc je n'en ai pas besoin non plus et le cas de la boucle for sus cité, c'est vraiment de la m**** d'écrire ce code.
quand à savoir si un main serait utile à JS, bof, si j’arrive pas à trouver le main d'un script, je préfère faire autre chose que de m'en servir.
# à la bonne heure
Posté par mh-cbon . En réponse au journal Quelle violence… ?. Évalué à -5.
Mais à part me signifier ma niaiserie par ton intellectualisme de façade,
tu veux en venir où ?
Tu proposes quoi ?
Et j'ai envie de rajouter, n'as tu pas encore senti peser sur tes réflexions l'inébranlable inertie de nos modes de vie ?
# la majorité des gens aiment partager leurs connaissances quand l'environnement est bienveillant
Posté par mh-cbon . En réponse au journal Les réunions pépé-malin - monter en compétence de manière ludique. Évalué à -4.
Mais sinon, tu en fais encore des speed meetup ?
[^] # Re: excellent !
Posté par mh-cbon . En réponse au journal Monter un cluster mémoire avec un raspberry pi. Évalué à -6.
Ah ouais ça à l'air cool les partitions JBOD ! J'ai presque envie de mettre le souk dans mes box pour le tester ahaha :x
Vraiment bon ce journal :)
# excellent !
Posté par mh-cbon . En réponse au journal Monter un cluster mémoire avec un raspberry pi. Évalué à -4.
Comme je n'ai rien de plus à en dire, l'as tu mis en place ?
As tu des retours à l'usage ?
[^] # Re: Stack traces...
Posté par mh-cbon . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à -5.
et bien, pourquoi ne fais tu pas du ruby ou de l'elixir alors ? Le but c'est de rendre un service, pas de s'obstiner à utiliser une techno, non ?
Oui tu devrais essayer comme je t'ai montré ici http://linuxfr.org/nodes/108933/comments/1656878
[^] # Re: Stack traces...
Posté par mh-cbon . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à -6.
Je confirmes. Même si j'aurais plutôt dit qu'avec de grands pouvoirs viennent de grandes responsabilitées !
Ceci dit avec async j'ai l'habitude d'avoir un callback de fin pour rattraper l'exception. Ceci dit je n'utilise pas waterfall.
Plus simplement si je dois binder uncaughtException, c'est que le code est mauvais.
[^] # Re: Stack traces...
Posté par mh-cbon . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à -6.
A défaut, mais c'est moche en effet.
[^] # Re: Stack traces...
Posté par mh-cbon . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à -5.
oui c'est dégueulasse.
[^] # Re: Stack traces...
Posté par mh-cbon . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à -6.
async/await ? Très peu pour moi ! Oui je parlais du module async.
En fait ce sera plus simple avec un through.
Par contre, comme c'est un through et non un readable tu perds l'évènement close, tu n'auras plus que le 'end'
[^] # Re: Stack traces...
Posté par mh-cbon . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à -5.
Ton exception n'est pas 'uncaught' puisque tu as abonné l'évènement 'error' du stream dans
C'est plutôt
Et quand t'en auras marre d'écrire trois lignes pour binder error, tu feras comme moi https://github.com/mh-cbon/cpkaaot/blob/master/lib/error-debug.js
J'avoue appliquer la chose bêtement. Si je veux savoir quand le fichier est écrit => close
[^] # Re: Stack traces...
Posté par mh-cbon . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à -6.
Par ailleurs,
Pourquoi tu n'enrobes pas cette logique dans un readable ? Comme cela que le fichier existe, ou pas, tu pourrais faire tonStream('lefichier').pipe(…)
Tu pourrais réduire un peu toute cette complexité avec le async.
cf noms, ou mississippi, pour faire un readable rapidement.
[^] # Re: javascript ?
Posté par mh-cbon . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à -9.
Moi pendant ce temps je me demande pourquoi on parle d'angular sur un post au sujet de nodejs.
Et par ailleurs, pourquoi utiliserais je typescript pour écrire du code avec nodejs, puisqu'en ayant choisi ce langage, et cette plateforme, c'était en connaissance de cause, en fait par désir, de virer la contrainte du typage.
[^] # Re: Stack traces...
Posté par mh-cbon . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à -6. Dernière modification le 13 mai 2016 à 10:41.
https://nodejs.org/api/errors.html
http://stackoverflow.com/questions/2923858/how-to-print-a-stack-trace-in-node-js
amha
fs.createWriteStream('.npmignore.old').on('close')
et nonfs.createWriteStream('.npmignore.old').on('finish')
[^] # Re: Votre annonce n'est pas cohérente avec le profil recherché
Posté par mh-cbon . En réponse au message Offre d'emploi - Chef de Projet - Expert Informatique - NOBATEK. Évalué à -6.
trop d'honneur, toutes ces remarques, pour quelqu'un qui n'était même pas fichu de mettre des retours à la ligne. A croire que celui-ci était souler de poster.
[^] # Re: Huh ?
Posté par mh-cbon . En réponse au journal Linux sur le bureau : combien de régressions ?. Évalué à -10.
donc +4 pour un mec qui ne sait ni rechercher, ni lire, un autre qui lui donne la cuillère et un dernier qui l'encourage !
Comme il dit l'autre,
@L'auteur du journal du dredi, les conclusions sont toujours les mêmes. Il manque un pilote. Il y à 10 ans déjà….
[^] # Résultat des courses...
Posté par mh-cbon . En réponse au message compatibilité sh -c 'echo "rr" 1>&3 && ls -al .' 3>&1. Évalué à -5.
… Je n'ai pas utilisé
mkfifo
, ni desocket
, pas plus quefd[4]
, j'ai balancé letoken
surstdout
, c'est moche, et après j'ai fais un peu de magie noire avec les streams.En tout cas merci encore, j'ai appris des choses intéressantes !
[^] # Re: histoire de ne pas me faire troller à coup de terrorisme intellectuel...
Posté par mh-cbon . En réponse à la dépêche Passbolt, un nouveau gestionnaire de mots de passe pour les équipes. Évalué à -8. Dernière modification le 16 avril 2016 à 15:27.
J'aurais dû préciser, en équipe !
Donc à priori seul teampass, et donc², il n'y a pas tellement d'alternatives.
En tout cas, merci.
Finalement, d'un point de vue technique celui qui me plait le plus c'est wkr, car c'est le seul à proposer
- un début d'api REST ré utilisable par d'autres
- une base de données rapide à setup (en l’occurrence un simple fichier json, donc c'est pas terrible pour le multi utilisateur, en tout cas ce n'est pas une dépendance à mysql) /gpass est pas trop mal sur le coup, c'est du sqlite/
- à la va vite je dirais que la dépendance à apache est optionnel, j'aime ça aussi.
Soit dit en passant, au sujet de gpass, je ne peux lire toutes les sources :( http://indefero.soutade.fr/p/gpass/source/tree/master/server/ref/index.php
en bref, ça tente personne de faire juste des api rest, et de laisser la vue à d'autres quand vous faites des projets
web? Ou de vraiment la séparer complètement, et intégralement.# histoire de ne pas me faire troller à coup de terrorisme intellectuel...
Posté par mh-cbon . En réponse à la dépêche Passbolt, un nouveau gestionnaire de mots de passe pour les équipes. Évalué à -9. Dernière modification le 16 avril 2016 à 14:03.
…et puis de toute façon à -6 je ne crains plus rien.
Bref, c'est juste bien comme software, l'idée me trottait dans la tête aussi.
Quand je serais motivé j'irais voir si il existe des alternatives. Ou ptet que les lecteurs en connaissent déjà ?
Ça fait combien de temps que vous travaillez dessus ? J’arrive pas à remonter la timeline dans github c'est trop long…
[^] # Re: Bof
Posté par mh-cbon . En réponse au journal Ce logiciel qui choisit ta fac. Évalué à -5.
https://github.com/openfisca/calculette-impots-m-source-code/tree/master/src
manquerait plus qu'une réduction budgétaire passe par là pour virer les personnes compétente à vérifier cela et on va moins rire.