ttoinou Posted April 16, 2018 Report Share Posted April 16, 2018 La flemme d'heberger Link to comment
Rübezahl Posted April 19, 2018 Report Share Posted April 19, 2018 Je souhaiterais exécuter une appli android sur mon PC 64 bits debian stretch. Quelqu'un ici aurait déjà fait ça ? et aurait une solution simple à suggérer ? Merci. Link to comment
Sloonz Posted April 19, 2018 Report Share Posted April 19, 2018 Pas testé : https://anbox.io/ Sinon tu as toujours la possibilité de lancer un émulateur avec le SDK. 1 Link to comment
Rübezahl Posted April 19, 2018 Report Share Posted April 19, 2018 J'ai lu des mauvais retours sur anbox (mais ça date de juillet 2017 donc c'est peut-être arrangé). https://www.debian-fr.org/search?q=anbox Comme sdk dans les paquets officiels, il y a ça : https://packages.debian.org/stretch/android-sdk tu as déjà testé ? (ou tu as d'autres trucs à recommander ?) Link to comment
Sloonz Posted April 19, 2018 Report Share Posted April 19, 2018 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) 1 Link to comment
0100011 Posted April 27, 2018 Report Share Posted April 27, 2018 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. Link to comment
Kimon Posted May 7, 2018 Report Share Posted May 7, 2018 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). Link to comment
Noob Posted May 7, 2018 Report Share Posted May 7, 2018 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. Link to comment
Noob Posted May 7, 2018 Report Share Posted May 7, 2018 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.. Link to comment
Sloonz Posted May 7, 2018 Report Share Posted May 7, 2018 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 Link to comment
Noob Posted May 7, 2018 Report Share Posted May 7, 2018 36 minutes ago, Sloonz said: J’aime bien https://github.com/kien/ctrlp.vim 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. Link to comment
Noob Posted May 10, 2018 Report Share Posted May 10, 2018 @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. Link to comment
Sloonz Posted May 11, 2018 Report Share Posted May 11, 2018 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. Link to comment
cedric.org Posted May 11, 2018 Report Share Posted May 11, 2018 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. Link to comment
Noob Posted May 11, 2018 Report Share Posted May 11, 2018 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. 1 Link to comment
cedric.org Posted May 11, 2018 Report Share Posted May 11, 2018 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. Link to comment
Rübezahl Posted May 12, 2018 Report Share Posted May 12, 2018 Vous auriez un ou des tutoriaux à recommander pour github ? Un guide de survie progressif ou dans le genre ? Les projets avec 50 sous-répertoires, les issues et commits qui fusionnent ... on se croit dans une bataille de starwars Link to comment
Noob Posted May 12, 2018 Report Share Posted May 12, 2018 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 1 Link to comment
cedric.org Posted May 12, 2018 Report Share Posted May 12, 2018 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. Link to comment
Rübezahl Posted May 13, 2018 Report Share Posted May 13, 2018 Merci pour vos recos. C'est surtout pour m'en sortir avec github, mais il faut aussi un peu piger git pour le local. Merci. Link to comment
Kimon Posted May 15, 2018 Report Share Posted May 15, 2018 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 ! Link to comment
Rincevent Posted May 15, 2018 Report Share Posted May 15, 2018 Il n'est pas forcément mauvais que l'outil pousse les développeurs à se coordonner et à, horresco referens, se parler. Link to comment
Rübezahl Posted May 16, 2018 Report Share Posted May 16, 2018 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 Link to comment
Rübezahl Posted May 18, 2018 Report Share Posted May 18, 2018 quelqu'un ici a déjà utilisé netlify ? ... et pourrait expliquer un peu à quoi ça sert ? Link to comment
Noob Posted May 18, 2018 Report Share Posted May 18, 2018 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. 1 Link to comment
ttoinou Posted May 21, 2018 Report Share Posted May 21, 2018 Si même mamie s'y met... https://www.aarp.org/work/working-at-50-plus/info-2018/worlds-oldest-app-developer-fd.html Citation 82-Year-Old Proves You're Never Too Old to Code Japanese woman learned coding last year; she's since created a popular app 1 Link to comment
Rübezahl Posted June 4, 2018 Report Share Posted June 4, 2018 microsoft qui rachète github :-( Link to comment
Rincevent Posted June 4, 2018 Report Share Posted June 4, 2018 Il y a 3 heures, Rübezahl a dit : microsoft qui rachète github :-( Pourquoi être triste ? Link to comment
Rübezahl Posted June 4, 2018 Report Share Posted June 4, 2018 Ma 1° pensée est que microsoft achète github expressément pour le couler. (mébon, je peux me gourrer bien sûr). Link to comment
cedric.org Posted June 4, 2018 Report Share Posted June 4, 2018 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. 2 Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now