Microsoft Visual Studio krijgt functie om tegelijkertijd aan project te werken

Microsofts integrated development environment Visual Studio krijgt een functie, waarmee ontwikkelaars tegelijkertijd aan een project kunnen werken. Live Share moet het mogelijk maken om dat te doen zonder de code te hoeven synchroniseren. Visual Studio Code krijgt de functie ook.

Bij het gebruiken van Live Share zien gebruikers van elkaar waar ze bezig zijn, omdat Visual Studio die gedeeltes highlight en de naam van degene die de code bewerkt erbij zet. De functie moet het mogelijk maken om tegelijkertijd aan dezelfde codebase te werken, waarbij bewerkingen onmiddellijk voor andere gebruikers zichtbaar zijn. Ook is het mogelijk om samen tegelijkertijd te debuggen.

Microsoft heeft de functie voor Visual Studio laten zien op zijn ontwikkelaarsconferentie Connect. Er komt binnenkort een gesloten bèta, waarin gebruikers kunnen spelen met de functie. Het is onbekend wanneer er een openbare testversie of stabiele versie van de functie beschikbaar komt.

Reacties (87)

[kuurtjes]

Kreeg eerder vandaag nog een mail van Github waar ze Teletype van Atom aanprezen:
https://teletype.atom.io/

Ik denk dan ook dat dit een reactie erop is.

[Martinspire]

Interessant dat er dan tegelijkertijd twee van dit soort technieken online verschijnen. Alsof er ergens een patent afgelopen is of iets dergelijks.

[Cerberus_tm]

Haha dat hoop ik toch niet! Ik vermoed eerder dat er al lang programma's zijn waar dit mee kan, alleen nog niet zulke bekende/goede programma's.

Overigens, wat betreft het tegelijk bewerken van dezelfde code zou ik willen zeggen: what could possibly go wrong?

[binair]

Ik zag dat eerder als een voordeel: je kan zien aan welke code een collega bezig is zodat je er gewoon kan afblijven. Geen merge conflicten meer

[vinno97]

Heb je dan geen problemen als iemand ergens iets aan het aanpassen is en jij begint te runnen?

[equit1986]

meestal zit die persoon naast je of in de dezelfde ruimte, of heb er mee contact middels skype of zo.
Dus dat stem je gewoon ter plekke af.

[GamingZeUs]

Je hebt allemaal een eigen GIT repo, als je commit pull je eerst en commit je dan je eigen veranderingen. De testversie draait HEAD.

Gaat alleen fout als je intensief samenwerkt, maar dan overleg je maar ff.

[dutchmartin]

Dit is vooral een oplossing als je op afstand aan pair programming wil doen of een code review. Dan zie jij gemakkelijk waarover de andere persoon het heeft

[ashwin911]

what could possibly go wrong?

Niet veel, want deze functie is er niet voor dat andere mensen willy nilly aan je code kunnen sleutelen. Je moet nog steeds mensen uitnodigen om toegang tot je bestand te krijgen. Dit is eerder een soort van screen share maar dan beter omdat je in je eigen environment kan werken. Bijvoorbeeld iemand met Visual Studio Code op een Mac kan iemand die op Windows met Visual Studio werkt om hulp vragen met zijn code. Zonder dat de andere opeens in een Mac environment moet werken zonder zijn plugins en shortcuts.

Denk aan remote troubleshooting, remote pair programming of remote code reviewing. Je moet het demo filmpje maar is bekijken https://www.youtube.com/watch?v=fWXe1HQ1wVA

[Reactie gewijzigd door ashwin911 op 22 juli 2024 14:21]

[Jeldert]

In 2008 met mijn afstuderen heb ik pair programming op afstand al mogelijk gemaakt in Eclipse. Via een plug-in kon je (met wat haken en ogen) samen programmeren aan hetzelfde project. Alle wijzigingen werden direct bij beide gebruikers toegepast.
Niet alleen tijdens het typen, maar ook renames, refactorings, etc.

Op https://jeldertpol.nl/software/xtc/ staat nog een en ander. Maar heb het sinds 2008 ook zelf niet meer gebruikt en onderhouden

[Martinspire]

En hoe werkte dat dan verder. Was het echt een uitkomst of vaak eerder irritant? Want ik kan me maar weinig use cases bedenken waarmee dit handig zou zijn

[Jeldert]

Het idee was om het alleen te gebruiken zoals je ook pair-programming zou doen, maar dan op 2 machines.
Of als je een aanpassing over meerdere lagen in je applicatie moet doorvoeren dat je dit met z'n 2en kan doen.
Ook als je tegen een probleem aanloopt en even een 2e paar ogen nodig hebt is het handig. Vooral omdat de 2e persoon ook zelf aanpassingen kan doorvoeren.

Wel moet ik zeggen dat er geen uitgebreide gebruikerstest zijn uitgevoerd. Dat heb ik als oefening voor de lezer overgelaten

[Anoniem: 902873]

Atom is ook gebouwd door Github xD Dan snap ik wel dat ze Atom aanprijzen.

[GrooV]

En Atom is weer gebaseerd op Electron waar ook VS Code op gebaseerd is

[triplecore]

Electron is een framework zodat je met NodeJS stand-alone applicaties kan maken en draaien. Het is dus niet per definitie zo dat ze de zelfde code delen voor hun hoofdfuncties.

[Reactie gewijzigd door triplecore op 22 juli 2024 14:21]

[GamingZeUs]

Framework doet meestal wel hoofdfuncties hoor! En de moeilijkste dingen zitten vaak in het framework (zodat je die maar eens hoeft te doen, samen, ipv allemaal meerdere keren).

Maar het is niet zo dat de USP's overlappen hierdoor - het zijn echt hele andere producten.

[StefanJanssen]

Eigenlijk is Electron een doorontwikkeld project vanaf Atom. Toen GitHub met Atom kwam waren mensen enthousiast dat het met javascript gebouwd was waarna ze Electron hebben gebouwd.

[diondokter]

Dit is niet voor Visual Studio, dit is ook voor de text editor variant 'Visual Studio Code'.
Groot verschil!

(De screenshot is wel goed)
Ontopic:
Ziet er goed uit, maar het kan GIT niet vervangen voor software development. Maar voor gewone text editing kan dit best handig zijn.

[Reactie gewijzigd door diondokter op 22 juli 2024 14:21]

[Capital_G]

We are excited to announce that we’re working on “Visual Studio Live Share”, which enables developers using Visual Studio 2017 or Visual Studio Code

Dus, nee, beide Visual Studio Code en Visual Studio 2017 krijgen de feature.

Om ook direct op je edit te reageren. Dit is heel iets anders dan git (populair versiebeheer systeem). Dit is meer gericht op live collaboratie op dezelfde code-base, iets wat op dit moment vrij lastig is. Dit doet men nu via XP (eXtreme Programming) of pair programming, maar dan moet je letterlijk naast elkaar zitten. Collaboratie over het internet, bijvoorbeeld voor mensen die thuis werken of nog beter, mensen die aan de andere kant van de aardbol zitten, heeft hier verwacht ik wel baat bij.

[Reactie gewijzigd door Capital_G op 22 juli 2024 14:21]

[Zarhrezz]

Ik zie hier de voordelen ook wel van. Het komt vaak genoeg voor dat dezelfde ontwikkelaars voor compleet andere functionaliteit in dezelfde service, class, API, etc. zitten. Versiebeheer vertelt je dan alleen dat er een merge conflict is en dat is dus achteraf. Deze feature helpt juist merge conflicten te voorkomen omdat je 'real-time' ziet dat iemand anders in dezelfde code zit te wijzigen.

[Anoniem: 85014]

Ja dat wel. Zou handig zijn om te weten of de plaats waar ik zaken wijzig in de nabije toekomst zal conflicten met een andere developer. Maar dan zonder dat mijn versie van de file ook mee aangepast wordt tot wanneer ik git pull --rebase doe.

Zo kan je op voorhand beter kiezen of die nieuwe functie een paar regels lager niet beter toegevoegd wordt, zodat eventuele merges door de tooling automatisch kunnen opgelost worden.

Dat wel, inderdaad. Maar ik wil de andere zijn of haar wijzigingen nog niet in mijn files tot na ik git-pull(--rebase) heb gedaan.

[Capital_G]

De werking zoals het filmpje het omschrijft is heel erg opt-in. Één developer moet zijn sessie 'delen' via een visualstudio.com linkje, en een tweede developer moet de link in zijn Visual Studio (code of 2017, dat maakt dan niet uit) plakken.

Het is dus niet zo dat je makkelijk kan zien wat andere mensen op dezelfde branch doen.

[Anoniem: 396858]

Op het moment dat je merge conflicten krijgt na het inchecken moet je toch echt de werkwijze aanpassen.

[Anoniem: 85014]

Heb in m'n carrière (~20 jaar bezig als ik mijn schooltijd mee mag rekenen, en dat mag gezien ik toen met open source dingen bezig was) nog maar zelden meegemaakt dat ik simultaan in dezelfde file bezig ben.

Wat ik de laatste jaren wel heel vaak doe is met VNC of desktop sharing (bv. in Lync) meekijken met een andere developer. Als ik dan met iets wil helpen dan click ik op 'Take control'. M.a.w. voor debugging sessies zie ik me deze feature nog wel gebruiken. Maar simultaan in dezelfde file werken? Hmm. Misschien voor erg eenvoudige features wel.

Het is handig aan bv. git dat degene die de wijzigingen pulled zich moet bezig houden met mergen. Het is ook handig om te weten wie de auteur is van iedere bij-elkaar horend stukje code (en laat een commit een prima scheiding daarvoor zijn). Voor versie-beheer en releases van het project is het handig om op die commits te taggen. Bijvoorbeeld d.m.v. de gitflow branching techniek.

Voor mensen die thuis werken en aan de andere kant van de aardbol is het eerder handig om zoals bij git de hele repository offline te kunnen gebruiken, tot jij klaar bent, en dan je hele set wijzigingen naar de remote te pushen (m.a.w. distributed version control). Live simultaan editen is dan wel handig voor debugging sessies. Maar of dit erg veel zal toevoegen aan iets remote desktop achtig weet ik niet.

Wat ik bv. wel handig vond, ooit (= heb ik ooit eens ergens kunnen toepassen), was integratie met VMWare (en andere virtualisatie technieken) om de hele virtual machine te kunnen pauzeren en een paar seconden terug te reverten en dan terug 'play'. Bv. voor race condities reproduceerbaar te krijgen in een debugging sessie. Stel iemand anders heeft net een race conditie gereproduceerd; dan wil ik zijn hele (virtuele) machine een paar seconde kunnen terugzetten en de boel terug afspelen. Als dit remote kan, en zo gedaan dat het altijd werkt, dan is dat wel iets tof..

Microsoft en tools voor ontwikkelaars was en is altijd wel een redelijk mooi verhaal geweest. Dus er is hoop dat ze blijven innoveren in Visual Studio. Simultaan editen echter ... (er zijn al heel wat editors die dit kunnen, en plugins om bestaande editors om te toveren ook)

[418O2]

Ik heb een junior op een andere locatie onder me en dit zou wel een goede manier zijn om te helpen met complexere code. Ik zie er wel naar uit!

[Anoniem: 85014]

Ja, dat beschouw ik als een debugging sessie.. een paar lijnen helpen (bij een junior) is iets anders dan werkelijk te samen aan een (onderdeel-)feature (= commit) werken.

Nuja, ik sta er niet helemaal sceptisch tegenover. Ik vraag me vooral af hoe ze dit gaan integreren met hun git ondersteuning (iets anders dan git gebruikt men toch almaar minder).

[418O2]

Ik (en ms) zien dit als pair programming en daar kan echt wel waarde in zitten.

[SuperDre]

Nouja, pairprogramming op afstand was al niet echt een problem hoor met remote desktop sharing. Enige verschil dan is dat maar 1 van de 2 kan typen, terwijl bij deze live sharing, je beide in dezelfde code tegelijkertijd kunt typen.

[Rafe]

live collaboratie op dezelfde code-base, iets wat op dit moment vrij lastig is.

Screenhero (overgenomen door Slack). VNC. Een gedeelde tmux sessie met vim. IMO is de vernieuwing hier dat het specifieker om code gaat met een Google docs-achtige manier van werken ipv algemeen desktop sharing. Maar het is niet erg lastig geweest de afgelopen jaren

[capsoft]

Ze hebben aangegeven dat ze bewust hebben gekozen om niet voor de zoveelste desktop sharing optie te gaan, omdat je mogelijk dan te veel deelt. Vertrouwlijke e-mails of andere zaken die je open hebt staan etc.
Verder is het nu zo gaaf dat je dus in je IDE zit (vs of code) en platform onafhankelijk bent.
Misschien komt er wel support in Visual Studio for mac, of jetbrains of ook atom, sublime etc. ze doen steeds meer met open source.

[JochemK]

Precies dit is waarom ik er zo enthousiast over ben. Ik programmeer heel veel samen met een remote collega. Nu doen we dat via screen sharing van Skype, maar dat betekent dat hij ook m'n chat schermen etc kan zien, dat wil ik lang niet altijd.

[diondokter]

Oh! Niet gezien. Meestal skip ik de introductie omdat die toch altijd hetzelfde 'we're excited to anounce...' text is.

[Anoniem: 85014]

Ik vraag me wel af wie de auteur van de commit gaat worden wanneer twee mensen tegelijk aan een reeks wijzigingen bezig zijn in een set van files. Per slot van rekening wil ik met git blame een paar weken later kunnen zien of ik bij Amanda Silver of bij iemand anders moet vragen waarom level apart wordt opgeslagen als die level toch altijd uit sentiment kan berekend worden met util.getHappinessLevel.

En ook als de unit testen erna op CI falen dan wil ik weten waar ik mijn rubberen kip moet neerleggen of naartoe moet smijten. Aangezien Amanda Silver betrokken is, en vermoedelijk een vrouw, zal dat vriendelijk neerleggen worden. Normaal kan ik bv. met git blame en een shell scriptje (om bv. het geslacht van de auteur uit te lezen) uitwerken of een robotarmpje het rubberen beest lanceert, of niet.

[OddesE]

Ik vraag me wel af wie de auteur van de commit gaat worden

Degene die hem commit en pushed neem ik aan? Dit staat toch gewoon los van Git?

[Anoniem: 85014]

Er zijn meerdere auteurs als je gelijktijdig bewerkingen doet alvorens ctrl+s te rammen op je keyboard(s).

Wie heeft dan wat geschreven? Meerdere auteurs per commit? Fine, maar dat werkt niet met git blame (waarbij de geschiedenis achter iedere lijn kam achterhaald worden, en dat is inderdaad iets goed en nuttig)

[OddesE]

Als je met zijn tweeen achter dezelfde comuter gaat zitten (of met team viewing sessie) in een traditionele pair programming sessie en dan 'samen' edits doet dan is er uiteindelijk toch ook maar één auteur volgens Git? Ik zie het probleem niet zo eerlijk gezegd.

[Anoniem: 85014]

Ik doe meestal git branch pair/feature-naam en dan met z'n twee commit en push ernaar continue. Eventueel met een remote die naar elkaars lokale repo gaat (bv. over ssh).

[MrSnowflake]

Misschien zorgt die ambiguïteit er wel voor dat er minder blame-game gespeeld wordt. Alleen maar goed.

[Anoniem: 85014]

Nee ja. Sorry. Maar soms moet ik als ervaren ontwikkelaar kunnen vragen waarom iets gedaan is hoe het gedaan is. Daar zit een factor 'blame' bij. Ik vind ook dat iedere ontwikkelaar zo zeker van zijn of haar stuk moet zijn dat hij of zij achter de wijzigingen kan staan.

En als er samen met je commit ook meteen een unit testje zat dat de code coverage voor de nieuwe lijnen afdekte, dan moet het al behoorlijk vieze slechte code zijn eer er sprake van 'blame-game' zal zijn.

Dit soort features hoort eerder de wijzigingen van de betrokken auteurs toch te annoteren dan dat de hele zaak ambigu wordt. Als jij trouwens ambiguïteit verkiest bij bv. git, is het dan niet beter dat je gewoon iedereen met dezelfde account laat committen?

[MeMoRy]

Ha, as if. De blame-game is niet verzonnen, maar een product van de evolutie van teamwork.
En dat begrijp ik ook wel. Een vergelijking: jij wil toch ook niet iemand anders remsporen in de wc hoeven opruimen? Als iemand er een troepje maakt, moet hij/zij dat zelf opruimen.

[Anoniem: 85014]

Of te minste uitleggen dat zijn troepje met bleekwater mag vernietigd worden (of mag uitleg verschaffen waaruit ik wel of niet opmaak dat het troep is die ik, ongeacht zijn mening, mag vernietigen, met vuur en bleekwater).

[MeMoRy]

Precies. Dit is de nachtmerrie van elke configuration manager. Commits moeten duidelijke losstaande functie hebben en te traceren zijn. Anders wordt bug-tracking weer zoveel werk als het vroeger was.

[Anoniem: 85014]

Welja. True story. Duizenden keren al in mijn carrière: Er is een bug. We vinden de plaats waar de bug zich manifesteert. We snappen niet waarom het zo gedaan werd. Waarom wordt het zo gedaan? Er is veel code bijgekomen dat afhankelijk is geworden van hoe het nu gedaan wordt. Nogmaals. WAAROM wordt het zo gedaan?

Dan wil ik de auteur kunnen vinden, om het te vragen. En ook alle auteurs van code die is beginnen afhangen van hoe het ooit gedaan is. Om het hen te vragen. Misschien maakten we allemaal collectief dezelfde fout. En kunnen we nu gewoon overal en in één keer het gedrag helemaal juist zetten.

Misschien is het zo bedoeld. Hoe vreemd ook. Voor één of andere uitstekende reden. Maar dat wil ik dus horen van een mens. Je weet wel. Dat is zo'n beest met hersenen en herinneringen die weet, of toch in ieder geval hoort te weten, waarom iets gedaan werd zoals het gedaan werd.

Nu hoor ik anderen al denken: daar dient documentatie en daar dienen commit messages voor! Dat is waar. Maar de realiteit is dat je zelden kan afleiden waarom wanneer iets vreemd in elkaar zit het gedaan is zoals het gedaan is.

[VanStino]

Ik was ook al triggered door de screenshot... Is het nu VS of VSCode? Mooi dat het om Code gaat, is ondertussen mijn favoriete tool voor JS, nu nog de collega's overhalen.

[90710]

Beide Wel mooi dat MS steeds meer VS Code en VS aan het gelijktrekken is (feature wise).

De video op het bronartikel laat heel goed zien hoe het werkt tussen VS Code en VS 2017.

[Reactie gewijzigd door 90710 op 22 juli 2024 14:21]

[OddesE]

De screenshot is VS Code volgens mij.

[Letters]

Bron zegt dat het beschikbaar wordt voor beide.

[Nedra]

Dit is geen vervanging voor versiebeheer zoals Git, (sterker nog, er zitten ook fantastische nieuwe features voor git in vs code) maar een manier om realtime samen te werken in software. Ik zie dit als een uitstekende manier om bijvoorbeeld (remote) pair programming te doen. Ik denk dat dit een aardige hit zal worden.

[Reactie gewijzigd door Nedra op 22 juli 2024 14:21]

[Stoney3K]

Visual Studio heeft sowieso al integratie-functies voor Git.

[Travelan]

Git is gebaseerd op een (in mijn ogen) verouderde assumptie van versiebeheer. Het wordt tegenwoordig vooral gebruikt om samen te werken, en daar is het niet primair voor ontworpen. Git is prima om versie en releasebeheer bij te houden, maar samenwerken kan echt veel moderner, en dit is in mijn ogen echt de toekomst. This is just the beginning.

[DenOkster]

maar het kan GIT niet vervangen voor software development.

En dat kun jij opmaken uit dit korte stukje tekst?

[Reactie gewijzigd door DenOkster op 22 juli 2024 14:21]

[Galan]

Duhuh colaboration en een repository zijn dan ook niet voor hetzelfde doel.
Het een gaat over samenwerking het ander over version control.

[Anoniem: 636203]

Hoe vaak heb je dit nu nodig? Je kan nu ook al gewoon met meerdere mensen aan een project werken, je moet dan later wel de veranderingen in de code 'mergen'.

Dit kan soms nuttig zijn, maar ik zie het niet vaak gebruikt worden. Los daarvan kost dit toch ook weer veel ontwikkel capaciteit bij Microsoft terwijl dit beter ergens anders benut had kunnen worden.

[Reactie gewijzigd door Anoniem: 636203 op 22 juli 2024 14:21]

[ToAoM]

Je kan het onderdeel van je workflow maken. Veel teams, ook bij Microsoft doen aan pair programming, maar steeds meer mensen werken remote (thuis) of distribited (over meerdere kantoren) en tegelijk zijn er bij grote bedrijgevn steeds meer ontwikkelaars en consultants die vooral onderweg zijn.

Om dan toch een deel van de "samenwerkingsbonus" te kunnen krijgen zijn dit soort tools echt super handig.

Bovendien helpt het om ontwikkelaars die samen in dezelfde codefile zitten hun aanpassingen zo te doen dat ze merge conflicten kunnen voorkomen. Code Lens was hier een eerste aanzet voor, maar dit is een duidelijke level-up.

Overigens bestond dit concept al veel langer in de vorm van het niet langer bestaande vsanywhere.

[Anoniem: 636203]

Ik begrijp dat het handig kan zijn, maar ik zie het gewoon niet veel gebruikt worden. Als ontwikkelaar werk je meestal aan een gedeelte van de code en zelden met meerdere mensen aan één bestand (als dat wel zo is dan is de code waarschijnlijk niet juist gestructureerd).

Pair programming zie je nog niet zoveel omdat veel bedrijven het gewoon te duur vinden.

[Reactie gewijzigd door Anoniem: 636203 op 22 juli 2024 14:21]

[ToAoM]

Dat pair programming "te duur" is, is een verschrikkelijk jammere opvatting. Alsof 2 ontwikkelaars achter 1 pc 50% minder productief zijn als 2 ontwikkelaars achter 2 pc's.

Reductie in fouten, kennisoverdracht, minder hand-offs etc besparen een hoop.

[Anoniem: 636203]

Ik ben bang dat werkgevers het zo niet zien, die denken gewoon dat het (bijna) twee keer zoveel kost om iets te maken. Of dat ze de helft minder features kunnen inbouwen in dezelfde tijd.

Het is moeilijk uit te leggen vermoed ik.

[Reactie gewijzigd door Anoniem: 636203 op 22 juli 2024 14:21]

[ToAoM]

Dat klopt, veel werkgevers zien het niet zo. Het is een veel terugkerend thema in scrum training (ik ben Scrum.org Professional Scrum Trainer) en in teams waar een duidelijke scheiding is tussen skills, helpt het enorm om de samenwerking te bevorderen en de kwaliteit te verhogen. Front-end developers leren over backends, testers over automatiseren, ontwikkelaars over test technieken. En zo wordt iedereen beter.

Het grootste probleem, net als met veel andere technieken, is dat de korte termijn een dip krijgt, mensen moeten leren samenwerken, open zijn om elkaars feedback direct te krijgen, accepteren dat facebook en andere afleiders naar de pauze worden verbannen etc. Ik ken genoeg ontwikkelaars die het verschrikkelijk vinden om "op de vingers gekeken te worden". Test Driven Development kent een soortgelijke leercurve, waarbij initieel alles langzamer gaat en een hoop frustratie opwekt

Eenmaal daardoorheen ga je echt veel verbetering ervaren. Helaas zijn veel werkgevers prioriteiten aan het najagen (lopen hopeloos achter op beloftes aan klanten) en is er dus geen tijd om zo'n drempel te slechten. Dus sturen ze mensen naar een training van 2 dagen voor Scrum, TDD, Uniti Testen, Design Patterns en hopen dat het daarme goed komt, maar het gaat pas echt werken als er tijd is om het toe te passen en ruimte om te leren.

[Anoniem: 890159]

En dat mergen gaat vaak genoeg fout, iemand heeft iets verkloot hier en de laatste master build niet. Uiteraard net voordat die persoon op vakantie ging zodat de rest eerst kan uitzoeken wat er aan mankeert.

[Legosteen11]

Lijkt me aan de ene kant wel handig om te zien wat de ander aan het doen is. Aan de andere kant lijkt het me echt extreem onhandig omdat als jij je project wil compilen en de ander is bezig met programmeren, de kans groot is dat er een regel nog niet afgemaakt is en je dus een foutmelding krijgt.

[plofkip]

Precies de bedenkingen die ik ook heb, maar daar zullen ze hopelijk wel over nagedacht hebben?

[Reactie gewijzigd door plofkip op 22 juli 2024 14:21]

[jip_86]

Het lijkt me wel meevallen. Heb net het filmpje zitten kijken en je moet actief een sessie starten met je collega. Op dat moment weet je wel vrij goed waar je mee bezig bent.

[SuperDre]

Ik denk dat dit vooral bedoelt is wanneer je samen bezig bent, dus 'pairprogramming'. Niet zozeer als je beide toevallig aan dezelfde code aan het werken bent maar wel dus apart.

[Ramon]

Dan sluit je de sessie toch af....

[guysp]

Daar is dit dan ook niet voor bedoeld. Deze functie is meer voor momenten als je vast zit en een collega/vriend vraagt om je te helpen. In plaats van het delen van je scherm en instructies moeten doorkrijgen, kun je je workspace delen en een collega/vriend ook laten typen in jou code.

[RoofTurkey]

Op het screenshot is Visual Studio Code te zien, niet bepaalt hetzelfde als de reguliere Visual Studio. Zelf kan ik nergens terugvinden of de gewone Visual Studio deze feature ook krijgt/gaat krijgen, iemand hier een idee van?

[HetGezegde]

Klik de link aan die in het artikel wordt genoemd -
Live Share - en je ziet daar het volgende staan:

We are excited to announce that we’re working on “Visual Studio Live Share”, which enables developers using Visual Studio 2017 or Visual Studio Code to collaborate in real-time! Learn more about Live Share and the upcoming limited private preview here.

[Reactie gewijzigd door HetGezegde op 22 juli 2024 14:21]

[sys64738]

Oh dat is echt een coole feature. Werk vaak vanuit huis en dan kun je wel screen sharen maar samen in dezelfde editor werken lijkt me veel handiger.

Zoals diondokter ook al zegt, is het voor VS Code (inmiddels behoorlijk populair). Zal mij benieuwen hoelang het duurt voor IntelliJ IDEA dit ook krijgt. Hopelijk snel want ik gebruik beide editors naast elkaar.

[CCJJVV]

Voor Intellij is er al een plug-in genaamd floobits. Waarmee je ook met meerdere mensen live samen kan werken.

[jannemien]

Ik zie het nut (nog) niet zo. Pair Programming en beide achter de knoppen? Dat is juist niet de bedoeling en werk je elkaar tegen in plaats van samen te werken.

En wat doet de functie als je in een feature branch zit? Dan weet je hooguit dat je snel je wijzigingen moet gemerged zien te krijgen voor je collega een conflict veroorzaakt...

[Ramon]

Ik zie het nut (nog) niet zo. Pair Programming en beide achter de knoppen? Dat is juist niet de bedoeling en werk je elkaar tegen in plaats van samen te werken.

Als je aan het pair programmen bent en je zit niet aan de knoppen dan kan dat soms nogal irritant zijn om uit te leggen wat je bedoelt, het even typen is dan sneller, en als je het dan direct kan typen in het juiste bestand scheelt dat weer gedoe.

En wat doet de functie als je in een feature branch zit? Dan weet je hooguit dat je snel je wijzigingen moet gemerged zien te krijgen voor je collega een conflict veroorzaakt...

Ik zie niet in wat dit met branching te maken heeft? In feite deel je gewoon de IDE van de gene die de sessie start.

[jannemien]

[...]
Als je aan het pair programmen bent en je zit niet aan de knoppen dan kan dat soms nogal irritant zijn om uit te leggen wat je bedoelt, het even typen is dan sneller, en als je het dan direct kan typen in het juiste bestand scheelt dat weer gedoe.

Als je allebei achter je eigen scherm zit, dan gebruik je nu toch waarschijnlijk software om je scherm te delen? Dat is wat er bij ons gebeurt als je niet fysiek naast elkaar zit, Scherm delen en headset op. Als je niet op elkaar ingespeeld bent en je krijgt het niet gecommuniceerd, dan kun je nu toch ook de bediening even overnemen?

[...]
Ik zie niet in wat dit met branching te maken heeft? In feite deel je gewoon de IDE van degene die de sessie start.

Ik ging er vanuit dat de functionaliteit lijkt op die van office: dat je ziet dat er iemand anders ook aan het werk is in hetzelfde bestand. Zolang die functie dan maar rekening houdt, dat een andere branch niet hetzelfde bestand is en dan geen live wijzigingen laat zien.

Hopelijk onderschat ik de functie en is het geweldig, maar pair programming lijkt me nog steeds niet handiger met deze functie dan met Skype.

[Martinspire]

Het lijkt me dat je dit gebruikt als je ook met zijn tweeën ergens aan werkt. En dat je dus dingen wilt proberen om bv problemen te achterhalen. Zo hoef je niet fysiek naar iemand toe of dat ie zijn desktop shared, maar hoef je alleen de code changes te delen.

Wat mij betreft maakt dit het mogelijk om met een mindere connectie toch samen wat te kunnen bekijken.

[jannemien]

Ik dacht meer aan de beperkte meerwaarde tov. bijv. Skype. Dat is wat er in onze organisatie gebruikt wordt: bellen en scherm delen. Ik zie zonder verbale toelichting geen toegevoegde waarde van in een editor verschijnende code.

[CCJJVV]

Dit is niet perse iets nieuws. Naast natuurlijk word online en Google docs is er ook al een plug-in genaamd floobits (https://floobits.com). Welke in principe de zelfde functie heeft als wat er nu dus voor visual studio komt. Floobits is al een behoorlijke tijd te gebruiken in combinatie met een aantal IDE's en textEditors waaronder Intellij en Sublime . Het werkt opzich behoorlijk goed met een niet al te hoge delay maar toch gebruik ik het zelden.

[Reactie gewijzigd door CCJJVV op 22 juli 2024 14:21]

[DenOkster]

Klinkt goed, zit dit ook in de community versie?

[SilentLucidity]

Als dit net zo werkt als office online op het moment doet dan houd ik mijn hart vast.