Aller au contenu

Le fil des geeks informatiques


Johnnieboy

Messages recommandés

Je crois pas qu’il y aie l’emulateur dans les dépots officiels de debian. Le plus simple c’est d’installer android-studio dans ton home ou /opt et de l’utiliser pour lancer l’émulateur. Tu peux ensuite utiliser adb pour y envoyer un apk. Le moins simple étant d’installer juste les sdk-tools (https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip) et utiliser sdkmanager pour installer l’émulateur + image android (je l’avais fait il y a un moment, mais c'est assez pénible, la documentation des outils en ligne de commande laissant beaucoup à désirer…)

 

Après tu peux aussi tenter d’installer un des nombreux projets android x86 sous qemu/virtualbox (genre https://forum.xda-developers.com/bliss-roms/bliss-roms-development/x86-bliss-x86-pc-s-t3534657)

  • Yea 1
Lien vers le commentaire

Bon je suis toujours dans la learning curve de vi, mais je trouve à l'utilisation ce système beaucoup plus logique que celui des éditeurs de texte "usuels". Finalement, même après des décennies d'utilisation d'emacs je trouve que j'ai perdu du temps et que j'aurais du passer à vi qui psychologiquement au final me va beaucoup mieux.

 

Contrairement à certains ici qui paramètrent tout je suis quelqu'un qui ne customise quasiment rien, or c'est un des gros avantages d'emacs que je n'utilisais absolument pas. D'autre part, le fonctionnement abstrait de vi me correspond mieux : tout comme je ne supporte pas les traitement de texte wysiwyg (que ce soit pour du texte ou de l'html) je préfère avoir le code cru sous les yeux et utiliser la souris/le tactile, le moins possible.

Lien vers le commentaire
  • 2 weeks later...

Bonjour, je débute sur Git et je soumets ma difficulté suivante aux praticiens de cet outil.

 

Partons d'une branche master avec un module python monmodule.py qui contient 2 fonctions :

def fa():
    pass

def f1():
    pass

 

I. 1er cas de figure : pas de problème

 

2 développeurs nommés "dev_a" et "dev_1" travaillent simultanément sur ce même module via 2 branches parallèles.
Ils se partagent le travail de façon à modifier des fonctions différentes :
- "dev_a" modifie la fonction fa puis merge avec la branche master.
- Ensuite "dev_1" modifie la fonction f1 puis merge avec la branche master.
Tout se passe bien, on obtient sur la branche master, pour monmodule.py :

def fa():
    print("a")

def f1():
    print("1")

   
II. 2ème cas de figure : bizarre

 

Maintenant, les 2 développeurs se partagent le travail de façon à développer chacun une nouvelle fonction de leur côté, au sein du même module monmodule.py. Ils sont sûrs que ces 2 fonctions seront toujours rigoureusement indépendantes l'une de l'autre.

Dans une nouvelle branche, "dev_a" ajoute donc une fonction fb à la fin de monmodule.py, puis il merge avec la branch master qui devient :

def fa():
    print("a")

def f1():
    print("1")

def fb():
    print("b")

   
"dev_1", de son côté, dans une autre branche, ajoute une fonction f2 à la fin de monmodule.py. Dans la branche de "dev_1", monmodule.py devient :

def fa():
    print("a")

def f1():
    print("1")

def f2():
    print("2")

Et là, logiquement, on se retrouve face à un conflit quand "dev_1" essaie de merger sa branche avec la branche master.
C'est logique  mais c'est con aussi.
En effet, si :
- "dev_a" avait écrit sa nouvelle fonction fb entre fa et f1
- et "dev_1" avait écrit sa nouvelle fonction f2 à la fin du fichier
il n'y aurait pas eu de conflit.

 

Cela signifie-t-il qu'il n'a pas d'autre solution, pour éviter le conflit, que les 2 dev communiquent au préalable pour se mettre d'accord sur l'endroit où insérer leurs nouvelles fonctions respectives ?
Cela me laisse quelque peu perplexe...
Il y a certainement quelque chose que je n'ai pas compris (hormis le fait qu'il faut éviter de travailler simultanément et séparément sur le même module).

 

Lien vers le commentaire

Normalement il y a un ordre, non ? Je suis pas un grand spécialiste, mais il me semble que c'est la façon suivante qui se fait de façon classique.

Typiquement le premier dev après avoit fait ses changements et fait un commit dans sa branche locale, pull la branche master  et merge en local les changements. Puis seulement il push sur master.

Le deuxième dev fait la même chose ensuite. Il commit ses changements, pull de master (donc y compris les changements du premier ) merge et push ensuite sur master.

Sinon tu as un conflit car tu passes de la version au lieu d'avoir les versions 1 2 3 tu crées deux version 2 en parallèle avec des changements différents.

Si tu fais un pull avant un merge, alors tu t'assures de bien faire un merge avec la dernière version de master.

 

Atlassian a un bon guide je trouve sur les différents mode d'utilisation de git et les commandes associées.

https://www.atlassian.com/git/tutorials/comparing-workflows

 

Dans les toutes petites équipes si tu arrives à te synchroniser pour s'assurer qu'il y ait un certain ordre ça va. Sinon il faut dédier un responsable pour faire des push dans master et son rôle sera de pull les changements les uns après les autres des branches des autres dev. Les autres dev ne font que pull master régulièrement et push dans leur propre branche.

Lien vers le commentaire
On 27/04/2018 at 9:19 AM, Kassad said:

Bon je suis toujours dans la learning curve de vi, mais je trouve à l'utilisation ce système beaucoup plus logique que celui des éditeurs de texte "usuels". Finalement, même après des décennies d'utilisation d'emacs je trouve que j'ai perdu du temps et que j'aurais du passer à vi qui psychologiquement au final me va beaucoup mieux.

J'aime encore bien viM, mais il me manque toujours la gestion de plusieurs fichiers. Pour ça je préfère un outil comme sublime text qui essaie aussi de mettre un maximum l'accent sur l'usage du clavier tout en autorisant quand même les onglets pour passer d'un fichier à l'autre facilement à l'un d'un raccourcis clavier plutôt qu'à l'aide d'une commande..

Lien vers le commentaire
12 minutes ago, Noob said:

J'aime encore bien viM, mais il me manque toujours la gestion de plusieurs fichiers. Pour ça je préfère un outil comme sublime text qui essaie aussi de mettre un maximum l'accent sur l'usage du clavier tout en autorisant quand même les onglets pour passer d'un fichier à l'autre facilement à l'un d'un raccourcis clavier plutôt qu'à l'aide d'une commande..

J’aime bien https://github.com/kien/ctrlp.vim

Lien vers le commentaire
36 minutes ago, Sloonz said:

Effectivement ça a pas l'air mal. Après vim c'est vrai qu'on le trouve partout, mais pour que j'apprécie de l'utiliser il me faut quand même quelque extensions qui sont quasiment jamais installée. Du coup je vois jamais trop la différence avec Sublime Text surtout qu'avec sshfs on peut toujours accéder à des fichiers à distance de façon transparente pour l'éditeur.

 

Du coup j'ai un peu perdu du peu que je savais utiliser vim. Faudrait que je m'y remette tiens pour le fun.

Lien vers le commentaire

@Sloonz

J'ai refais un tour de piste autour de vim et j'ai découvert ranger un file manager en ligne de commande avec des commandes à la vim notamment pour renommer en masse les fichiers.

Sinon tu penses quoi de neovim ? Je dois dire qu'attacher neovim à VS code ou Sublime Text m'a l'air d'être le combo ultime, même s'il faut encore attendre pour que ça marche tip top.

Lien vers le commentaire

Pas encore testé neovim.

Perso j’arrive pas à voir l’intérêt d’un gestionnaire de fichiers. Shell + ls/cp/mv/rm/find me convient très bien. Pour le renommage en masse, perl-rename fait le job.

Lien vers le commentaire
On 10/05/2018 at 3:09 PM, Noob said:

@Sloonz

J'ai refais un tour de piste autour de vim et j'ai découvert ranger un file manager en ligne de commande avec des commandes à la vim notamment pour renommer en masse les fichiers.

Sinon tu penses quoi de neovim ? Je dois dire qu'attacher neovim à VS code ou Sublime Text m'a l'air d'être le combo ultime, même s'il faut encore attendre pour que ça marche tip top.

Vu que vim, c'est chiant comme la mort à configurer, je ne suis jamais passé à neovim juste à cause du manque de mes plugins (et surtout de leur config). Alors que justement le gros avantage de neovim est le decouplement du coeur par rapport à l'UI, permettant d'avoir même un neovim dans un navigateur par exemple.

Lien vers le commentaire

C'est vrai que ranger est pas méga utile, peut-être que je loupe un truc. Par contre pour neovim il y aussi un autre avantage, c'est que les plugins peuvent être invoqués de manière asynchrone.

Et aussi le fait que lua est 1000 fois plus rapide que vimscript.

  • Yea 1
Lien vers le commentaire
On 07/05/2018 at 5:12 PM, Kimon said:

Bonjour, je débute sur Git et je soumets ma difficulté suivante aux praticiens de cet outil.

 

Partons d'une branche master avec un module python monmodule.py qui contient 2 fonctions :


def fa():
    pass

def f1():
    pass

 

I. 1er cas de figure : pas de problème

 

2 développeurs nommés "dev_a" et "dev_1" travaillent simultanément sur ce même module via 2 branches parallèles.
Ils se partagent le travail de façon à modifier des fonctions différentes :
- "dev_a" modifie la fonction fa puis merge avec la branche master.
- Ensuite "dev_1" modifie la fonction f1 puis merge avec la branche master.
Tout se passe bien, on obtient sur la branche master, pour monmodule.py :


def fa():
    print("a")

def f1():
    print("1")

   
II. 2ème cas de figure : bizarre

 

Maintenant, les 2 développeurs se partagent le travail de façon à développer chacun une nouvelle fonction de leur côté, au sein du même module monmodule.py. Ils sont sûrs que ces 2 fonctions seront toujours rigoureusement indépendantes l'une de l'autre.

Dans une nouvelle branche, "dev_a" ajoute donc une fonction fb à la fin de monmodule.py, puis il merge avec la branch master qui devient :


def fa():
    print("a")

def f1():
    print("1")

def fb():
    print("b")

   
"dev_1", de son côté, dans une autre branche, ajoute une fonction f2 à la fin de monmodule.py. Dans la branche de "dev_1", monmodule.py devient :


def fa():
    print("a")

def f1():
    print("1")

def f2():
    print("2")

Et là, logiquement, on se retrouve face à un conflit quand "dev_1" essaie de merger sa branche avec la branche master.
C'est logique  mais c'est con aussi.
En effet, si :
- "dev_a" avait écrit sa nouvelle fonction fb entre fa et f1
- et "dev_1" avait écrit sa nouvelle fonction f2 à la fin du fichier
il n'y aurait pas eu de conflit.

 

Cela signifie-t-il qu'il n'a pas d'autre solution, pour éviter le conflit, que les 2 dev communiquent au préalable pour se mettre d'accord sur l'endroit où insérer leurs nouvelles fonctions respectives ?
Cela me laisse quelque peu perplexe...
Il y a certainement quelque chose que je n'ai pas compris (hormis le fait qu'il faut éviter de travailler simultanément et séparément sur le même module).

 

Git est con pour les conflits, j'ai presque l'impression que c'est volontaire. Pour moi, le second dév, avant de merger, doit rebaser et corriger lui même le conflit. C'est ainsi. Mais c'est souvent assez trivial si le rebase se fait rapidement.

Lien vers le commentaire
11 hours ago, Rübezahl said:

Vous auriez un ou des tutoriaux à recommander pour github ?

Git tout court ou github ?

11 hours ago, Rübezahl said:

Un guide de survie progressif ou dans le genre ?

Le lien que j'avais mis plus haut donne un peu une vue de haut pour comprendre comment on est sensé utilisé git à plusieurs.

Après si tu veux apprendre à t'en servir je dirais directement https://git-scm.com/book/en/v2

  • Yea 1
Lien vers le commentaire
5 hours ago, Noob said:

Git tout court ou github ?

Le lien que j'avais mis plus haut donne un peu une vue de haut pour comprendre comment on est sensé utilisé git à plusieurs.

Après si tu veux apprendre à t'en servir je dirais directement https://git-scm.com/book/en/v2

Pas mieux que le bouquin officiel.

Lien vers le commentaire

Merci beaucoup Noob et cedric.og pour vos réponses.

 

J'ai testé la proposition de Noob (à chaque étape : pull de master, tentative de merge en local et de push sur master).
Il n' a rien à faire, à un moment donné le second dev doit corriger un conflit (qui de fait est trivial).
Bon il semblerait que l'on soit obligé de faire avec !

Lien vers le commentaire

Il n'est pas forcément mauvais que l'outil pousse les développeurs à se coordonner et à, horresco referens, se parler.

Lien vers le commentaire
Le 12/05/2018 à 18:33, Noob a dit :

Git tout court ou github ?

Le lien que j'avais mis plus haut donne un peu une vue de haut pour comprendre comment on est sensé utilisé git à plusieurs.

Après si tu veux apprendre à t'en servir je dirais directement https://git-scm.com/book/en/v2

encore merci.

à signaler que ce bouquin est en cc by-nc-sa, et a une traduction fr

 

Lien vers le commentaire

J'ai jamais servi, mais ça ressemble à un site pour héberger le frontend d'un site statique ou serverless.

Ça automatise le déploiement et ça délègue toute la partie backend à des services comme AWS lambda si tu as en as besoin.

 

 

  • Yea 1
Lien vers le commentaire
  • 2 weeks later...
23 minutes ago, Rübezahl said:

Ma 1° pensée est que microsoft achète github expressément pour le couler.

(mébon, je peux me gourrer bien sûr).

Microsoft fait partie des premiers contributeurs open source au monde. C'est fini l'époque Ballmer. La stratégie de Microsoft est compléte et bien ficelée.

 

Après, qu'une boîte privée se fasse racheter par une boîte privée, on n'y peut rien. Si c'est le libre qui compte, et bien il fallait peut être commencer par publier sur une plateforme libre (ou tout au moins open source comme gitlab ces temps ci).

 

Si ça suit la ligne visual studio code, et bien honnêtement j'ai hâte de voir la suite.

  • Yea 2
Lien vers le commentaire

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
×
×
  • Créer...