Développeurs : Atom va mieux s’intégrer à GitHub
Atom est un éditeur de code créé par GitHub, mais paradoxalement, il n’y avait pas vraiment de liens entre le logiciel disponible sur toutes les plateformes et le service en ligne qui permet de gérer et de partager le code source. Les propriétaires du service proposent une app dédiée pour télécharger ou mettre à jour un projet, et il fallait utiliser deux logiciels pour éditer le code et le publier.
La prochaine version de l’éditeur, actuellement en bêta, intégrera un module dédié à Git et à GitHub, sans avoir à installer un élément supplémentaire. Il prend la forme d’une barre latérale sur la droite de la fenêtre et affiche en deux onglets tout ce qu’il faut pour gérer un projet avec suivi de version.
Dans le premier onglet, vous aurez les changements pas encore soumis (commit), ceux qui sont prêts à être soumis (staged changes) et ceux sur lesquels vous travaillez encore. En bas de l’onglet, Atom affiche un champ pour rédiger un message et expliquer le changement. Ce premier onglet fonctionnera avec tous les projets versionnés avec Git, même sans utiliser le service GitHub.
Le deuxième onglet est spécifique au service en revanche. Il affiche toutes les pull-requests, c'est-à-dire les propositions de modifications, du projet en cours. Vous pourrez les ouvrir et afficher le détail de la proposition, comme vous le feriez sur le site, mais sans quitter votre éditeur de code habituel. Tout le détail sur les fonctions proposées est disponible à cette adresse.
Atom est totalement gratuit et open-source. L’interface n’est pas traduite en français et l’app fonctionne avec OS X 10.8 ou plus récent.
Grosse usine à gaz
J'ai préféré payer CodeRunner
@IGerard
Je préfère de loin VSCode... gratuit en plus.
En revanche, qu'apporte CodeRunner de plus ?
@lawappe
Le debugger intégré pour Bash, gros plus, pour moi
Et je le trouve bien fait, très dans l'esprit de Cocoa, et bel effort que j'ai voulu encourager en l'achetant.
Seul bémol comme d'habitude, l'ouverture de gros fichiers qui se fait en mémoire, j'ai envoyé un courier pour proposer mon aide... problème intéressant et difficile, mais pas de réponse.
J'utilise Xcode pour mon codage en général Swift et C, avec les produits JetBrain pour Python, Java, Scala... Emacs pour les gros fichiers... et CodeRunner pour tout le reste.
Oui, même constat pour moi : grosse usine à gaz. Je suis revenu à TextWrangler puis BBE maintenant.
J'en ai eu récemment marre des mises à jour plusieurs fois par semaine qui parfois cassent la compatibilité d'un plugin. Je suis revenu à SublimeText 3 et ça me va.
Indispensable pour faire tourner Julia, très utile pour développer et exécuter illico des scripts Python et R dans l'éditeur directement (avec le package "script").
Usine à gaz ? Au contraire : outil modulaire, polyvalent, multi-plateforme (atout inestimable !), bénéficiant d'un développement soutenu et d'acteurs très impliqués.
@occam
"Usine à gaz ? Au contraire : outil modulaire, polyvalent, multi-plateforme (atout inestimable !), bénéficiant d'un développement soutenu et d'acteurs très impliqués."
Il peut être un outils "modulaire, polyvalent etc." tout en étant une usine à gaz utilisant Electron et donc le moteur de Chrome.
(cf https://www.macg.co/logiciels/2017/04/developpement-electron-est-il-le-nouveau-flash-98251 et les commentaires de l'article en question)
@iGeek07
Effectivement, il est lourd, gourmand et lent. Comme toutes les apps desktop en JS.
@Nico S
Le meilleur moyen d'avoir tord absolument est de généraliser absolument.
@fte
Je veux bien un exemple d'app Electron légère et qui ne bourre pas la RAM... j'ai pas trouvé encore. Même que je ne renie pas Electron, 3 de mes pull requests ont été mergées ;-)
@Nico S
Flow utilise Electron je crois, et l'app marche vraiment très bien. Basecamp aussi il me semble.
Mais tu parlais d'apps desktop en JS, généralisant absolument, et non d'apps Electron spécifiquement. Qu'importe.
Quant à la RAM, et alors ? Elle est faite pour être utilisée. Ah oui, c'est vrai, Apple facture la RAM au prix du SSD, j'oubliais. J'ai 64 GB dans ma machine, la RAM j'en ai rien à faire. :)
@iGeek07
Pour certains l'usine à gaz commence avec l'interface graphique.
Pour d'autres l'usine à gaz commence lorsqu'il n'y a pas d'interface graphique.
Usine à gaz est une notion avant tout subjective.
Ce n'est qu'un outil de plus dans le vaste atelier du développeur, qui utilisera toujours une variété d'éditeurs et autres machins pour ses besoins variés. Il n'existe pas d'outil unique et universel.
@iGeek07
Je connais l'article que vous citez, et quelques autres dans la même veine. Je ne partage ni leurs prémisses, ni leurs conclusions. Surtout, il faudrait les mesurer à l'état actuel du logiciel.
Puisque vous reprenez le cliché « usine à gaz », il est nécessaire de préciser le sens que vous donnez à cette expression. Communément, le sens convenu est « système surdimensionné ou trop alambiqué au regard de sa tâche ». Je récuse expressément le raccourci « trop complexe », car en théorie des systèmes, ce n'est pas la complexité émergente qui est à l'opposé de la simplicité, mais la complication.
Tant la structure modulaire que la polyvalence sont incompatibles avec les sous-entendus véhiculés par la métaphore « usine à gaz». Il faut se décider, et l'ayant fait, il serait bon de justifier son choix.
Pour rappel, les véritables usines à gaz traitaient une matière première en apparence simple, le charbon ou la houille, pour en extraire par pyrolyse, craquage thermique et distillation un mélange gazeux composé essentiellement de dihydrogène, de méthane, de CO, d’hydrocarbures à chaînes plus longues et d'autres composantes en moindre volume. Parmi les „déchets” utilisables récupérés, des goudrons, du benzène, des hydrocarbures solidifiées, du sulfate d'ammonium, des sulfures, etc. Tout cela dans des processus initialement mal compris et mal maîtrisés, nécessitant de très grands volumes de traitement à haute température. Une chimie brutale et barbare, finalement inadaptée à la complexité des éduits comme des produits.
C'est ça, une vraie usine à gaz.
Pour les plus réfractaires à l'anglais, il existe un package (extension) pour traduire la plupart des entrées de l'interface.
Très bon outil. Pour le lent, lourd et gourmand j'utilise atom et jetbrain en permanence au boulot et le lent, lourd et gourmand est loin d'être atom.
Après je comprends, il y aura toujours des gens pour nous expliquer que les tech web sont intrinsèquement mauvaises mais la réalité est que atom est très bon et m'a fait oublier sublime text en quelques jours.
@AbsolutMoi
Au delà des "gens qui expliquent", terminologie rabaissante et méprisante, il y a des évidences techniques d'une part auxquelles s'ajoutent des mesures concrètes d'autre part.
De plus ce ne sont pas les technologies web qui sont directement en cause mais bien l'utilisation qui en est faite.
@AbsolutMoi
Les produits Jetbrains sont des IDE, Atom est un éditeur de texte. Pas comparable en terme de performances. Atom serait plus à comparer avec un autre éditeur comme Sublime, par exemple.
@Nico S
La frontière entre IDE et éditeur de texte est parfois ténue. Perso je travaille (presque toujours) avec Sublime Text. Avec les bon paquets (très modulables) ça en fait un environnement de développement où (presque) tout est intégré. Bref un IDE !
Évidemment si on compare à Xcode qui contient un constructeur d'interfaces et qui permet de créer des liens (outlets) à la souris entre objets graphiques et codes, c'est sûr que ce n'est pas le même monde.
@AbsolutMoi
Tu réalises que tu compares un environnement de développement complet doté de fonctionnalités avancées avec un éditeur modulaire ?
Salut. Comme dit plus haut Visual Studio Code intègre bien Github il me semble.
https://code.visualstudio.com