De Devschuur Coffee Corner - Iteratie ⑬

[Immutable]

Caelorum schreef op woensdag 16 augustus 2023 @ 10:00:
Ach .NET is synoniem aan C# tegenwoordig. Mensen vergeten de tientallen andere talen die ervoor bestaan. Al zijn die talen op een paar uitzonderingen na niet echt fatsoenlijk bruikbaar.

Wat betreft voor de GPU zaken schrijven. Tja, met dingen als Alea GPU (.NET, F# sluit er goed op aan btw), of Rust CUDA kan je prima de GPU gebruiken voor compute doeleinden zonder op c++ terug te hoeven vallen. En zo heb je ze voor vrijwel elke taal wel.

Helemaal eens, elke taal heeft wel weer zijn voor en nadelen.
Ik zie C# meer een opgezette taal als "tool" om applicatiebouwers compleet in te kapselen.(Microsoft Ecosysteem Jail)
Als Microsoft C# zoooo geweldig zou vinden. Waarom zijn de meest belangrijke applicaties van Microsoft nog altijd in C/C++ en niet C#?
(Zou bijvoorbeeld Microsoft Word in C++ beter of slechter werken, dan wanneer je hem zou schrijven in C#?)

C# is gewoon een taal voor hun ecosysteem gebouwd om hun C/C++ applicaties te laten verbinden met elkaar, en ervoor te zorgen dat men vast gaat zitten in hun ecosysteem. Een soort Microsoft Ecosysteem lijmtaal dat wel hogere performance heeft als andere scripttalen vanwege de runtime met bytecode.

Daarnaast heb je Systeemtalen, Applicatietalen, Scripttalen. Elke zijn voor en tegens, en kunnen bepaalde talen ook wel dingen overlappen. En je hebt altijd legacy code, dus C/C++ blijft sterk. Altijd goed om die 2 talen te kunnen schrijven. Die gaan nooit weg, en er blijft werk in te vinden.

Veel drivers zijn nog altijd in assembly/C geschreven, daarom zit je met de C ABI. Rust heeft meestal ook voor veel bibliotheken gewoon een Rust wrapper om een C library of driver heen. Zal denk ik ook wel zo blijven ook voor GPU's. Deze drivers worden toch door de hardware leverancier geschreven, en zie ze daar niet zo gauw denk ik overstappen op Rust. (En misschien heb ik dat wel mis... zou wat zijn. Van C naar Rust in die wereld zou een stap zijn die eens in de 50 jaar zou voorkomen?)

En waarom is Microsoft bijvoorbeeld core libraries aan het herschrijven in Rust, waarom niet in C#? Microsoft heeft C# om geld te verdienen niet om echt zelf te gebruiken in hun eigen producten zoals Windows, Microsoft Office e.d.
https://www.theregister.c...7/microsoft_windows_rust/

Denk ook meer dat C# en Java zoiets is als: Ik ga een huis maken, en koop mijn materialen en kant en klare doe het zelf pakketjes bij de Gamma. In plaats van dat je zelf in detail het huis laat ontwerpen bij een prominenten architect, zelf materialen groot inkoopt vaak van wat hogere kwaliteit en alles van de grond af zelf bouwd.
Of dat wanneer je gaat koken, een knor pakketje koopt. In plaats van compleet alles vers zelf klaarmaakt en kookt wat meer tijd kost. Beide hebben zo zijn voordelen en is er vraag naar. Daarom zie ik zelf C# en Java meer als een soort halve script taal. Uiteindelijk heb ik toch liever een kwaliteit huis, en kwaliteit eten. (persoonlijke mening.)

Het is hier en daar wel een beetje van, een drugs dealer die zelf zijn drugs wel verkoopt maar het zelf niet wil gebruiken.

[ Voor 11% gewijzigd door Immutable op 27-08-2023 11:36 ]

[RayNbow]

Immutable schreef op zondag 27 augustus 2023 @ 11:30:
Ik zie C# meer een opgezette taal als "tool" om applicatiebouwers compleet in te kapselen.(Microsoft Ecosysteem Jail)

Wat een onzin. De taal is een ISO-standaard en referentie-implementaties zijn open source.

[DevWouter]

Oh wauw... Echt?

Immutable schreef op zondag 27 augustus 2023 @ 11:30:
[...]

Helemaal eens, elke taal heeft wel weer zijn voor en nadelen.
Ik zie C# meer een opgezette taal als "tool" om applicatiebouwers compleet in te kapselen.(Microsoft Ecosysteem Jail)
Als Microsoft C# zoooo geweldig zou vinden. Waarom zijn de meest belangrijke applicaties van Microsoft nog altijd in C/C++ en niet C#?
(Zou bijvoorbeeld Microsoft Word in C++ beter of slechter werken, dan wanneer je hem zou schrijven in C#?)

Visual Studio? Azure Active Directory? SQL Server? Unity? De meeste games zijn geschreven in dotnet.
En nee, niet alles is "puur" C#, maar dat hoeft ook niet.

C# is gewoon een taal voor hun ecosysteem gebouwd om hun C/C++ applicaties te laten verbinden met elkaar, en ervoor te zorgen dat men vast gaat zitten in hun ecosysteem. Een soort Microsoft Ecosysteem lijmtaal dat wel hogere performance heeft als andere scripttalen vanwege de runtime met bytecode.

Nee, het is geen bytecode. Het is een IL die door de runtime naar native wordt gecompileerd. En die hopelijk met dotnet8 ook native ge-pre-compiled kan worden.

Daarnaast heb je Systeemtalen, Applicatietalen, Scripttalen. Elke zijn voor en tegens, en kunnen bepaalde talen ook wel dingen overlappen. En je hebt altijd legacy code, dus C/C++ blijft sterk. Altijd goed om die 2 talen te kunnen schrijven. Die gaan nooit weg, en er blijft werk in te vinden.

Als ik een kandidaat wiens kwaliteit zich vooral uit in hoe goed die persoon in taal A of B kan programmeren dan verdwijnt die vaak onder op de stapel. Het "coderen" van "logica" is namelijk maar 1 aspect.
Het is namelijk hoe we een taal gebruikt wordt dat zijn classificatie bepaalt, niet de taal zelf. Ik heb programma's gezien die C als script-taal gebruiken waarbij C# de applicatietaal is en LUA door het OS als systeemtaal gebruikt wordt.

Veel drivers zijn nog altijd in assembly/C geschreven, daarom zit je met de C ABI.

Niet "C ABI" gewoon "ABI". Het heeft te maken met welke adressen en commando's naar de hardware gestuurd kan worden.
Zie Wikipedia: Application binary interface

Rust heeft meestal ook voor veel bibliotheken gewoon een Rust wrapper om een C library of driver heen. Zal denk ik ook wel zo blijven ook voor GPU's. Deze drivers worden toch door de hardware leverancier geschreven, en zie ze daar niet zo gauw denk ik overstappen op Rust. (En misschien heb ik dat wel mis... zou wat zijn. Van C naar Rust in die wereld zou een stap zijn die eens in de 50 jaar zou voorkomen?)

Het is precies andersom. Het zijn Rust drivers met C wrappers. Wrappers zijn zeer makkelijk te genereren en hierdoor kunnen bestaande gebruikers van de drivers gewoon in C blijven schrijven.

En waarom is Microsoft bijvoorbeeld core libraries aan het herschrijven in Rust, waarom niet in C#? Microsoft heeft C# om geld te verdienen niet om echt zelf te gebruiken in hun eigen producten zoals Windows, Microsoft Office e.d.
https://www.theregister.c...7/microsoft_windows_rust/

Lees het artikel nog eens: Het gaat om nieuwe projecten, men doet daar niet herschrijven om het herschrijven. En bij dat soort besluiten maakt men allerlei afwegingen. En dynamic memory management is voor kernel libraries niet echt een pro, dus logisch dat dotnet geen kandidaat was.

Het is hier en daar wel een beetje van, een drugs dealer die zelf zijn drugs wel verkoopt maar het zelf niet wil gebruiken.

Zullen we dit soort extreme uitspraken maar achterwege laten? Het is erg beledigd naar mensen die het wel gebruiken, helemaal als jouw verhaal onjuistheden bevat.

[downtime]

Immutable schreef op zondag 27 augustus 2023 @ 11:30:

Denk ook meer dat C# en Java zoiets is als: Ik ga een huis maken, en koop mijn materialen en kant en klare doe het zelf pakketjes bij de Gamma. In plaats van dat je zelf in detail het huis laat ontwerpen bij een prominenten architect, zelf materialen groot inkoopt vaak van wat hogere kwaliteit en alles van de grond af zelf bouwd.

Hoeveel aannemers zouden hun eigen bakstenen bakken? Zelf bomen telen om planken van te zagen? Zelf ijzer smelten om spijkers van te maken? Soms loont het gewoon niet om alles zelf te doen.

C# en Java (en elke andere taal) lossen wat problemen op en daar staan ook wat nadelen tegenover. Dat is normaal. Toch kunnen die talen voor veel problemen toch de beste oplossing zijn. Wie schrijft er nu nog in assembler? Wie schrijft al zijn eigen libraries? Meestal is het goed voor de kwaliteit om dat door een specialist te laten doen zodat jij je aandacht kunt focussen op het probleem wat de klant echt opgelost wil zien.

[RagingPenguin]

Immutable schreef op zondag 27 augustus 2023 @ 11:30:
[...]

Ik zie C# meer een opgezette taal als "tool" om applicatiebouwers compleet in te kapselen.(Microsoft Ecosysteem Jail)

Dotnet applicaties op Linux hosten is tegenwoordig best normaal voor web applicaties (IIS heeft nog geen 10% marketshare).

Daarnaast heb je Systeemtalen, Applicatietalen, Scripttalen. Elke zijn voor en tegens, en kunnen bepaalde talen ook wel dingen overlappen. En je hebt altijd legacy code, dus C/C++ blijft sterk. Altijd goed om die 2 talen te kunnen schrijven. Die gaan nooit weg, en er blijft werk in te vinden.

Is het niet juist een van de trends van het algelopen decenium dat de vraag naar C en C++ developers sterk aan het afnemen is, en er enkel de meer competievere niches overblijven zoals game engines en embedded hardware?

Veel drivers zijn nog altijd in assembly/C geschreven, daarom zit je met de C ABI. Rust heeft meestal ook voor veel bibliotheken gewoon een Rust wrapper om een C library of driver heen. Zal denk ik ook wel zo blijven ook voor GPU's. Deze drivers worden toch door de hardware leverancier geschreven, en zie ze daar niet zo gauw denk ik overstappen op Rust. (En misschien heb ik dat wel mis... zou wat zijn. Van C naar Rust in die wereld zou een stap zijn die eens in de 50 jaar zou voorkomen?)

En waarom is Microsoft bijvoorbeeld core libraries aan het herschrijven in Rust, waarom niet in C#? Microsoft heeft C# om geld te verdienen niet om echt zelf te gebruiken in hun eigen producten zoals Windows, Microsoft Office e.d.
https://www.theregister.c...7/microsoft_windows_rust/

Denk ook meer dat C# en Java zoiets is als: Ik ga een huis maken, en koop mijn materialen en kant en klare doe het zelf pakketjes bij de Gamma. In plaats van dat je zelf in detail het huis laat ontwerpen bij een prominenten architect, zelf materialen groot inkoopt vaak van wat hogere kwaliteit en alles van de grond af zelf bouwd.
Of dat wanneer je gaat koken, een knor pakketje koopt. In plaats van compleet alles vers zelf klaarmaakt en kookt wat meer tijd kost. Beide hebben zo zijn voordelen en is er vraag naar. Daarom zie ik zelf C# en Java meer als een soort halve script taal. Uiteindelijk heb ik toch liever een kwaliteit huis, en kwaliteit eten. (persoonlijke mening.)

Het is hier en daar wel een beetje van, een drugs dealer die zelf zijn drugs wel verkoopt maar het zelf niet wil gebruiken.

Waarom zou je in hemelsnaam een DirectX component schrijven in een taal met managed memory, of (anno 2023) een desktop of web applicatie in een taal zonder managed memory?

[Mugwump]

downtime schreef op zondag 27 augustus 2023 @ 13:25:
[...]

Hoeveel aannemers zouden hun eigen bakstenen bakken? Zelf bomen telen om planken van te zagen? Zelf ijzer smelten om spijkers van te maken? Soms loont het gewoon niet om alles zelf te doen.

C# en Java (en elke andere taal) lossen wat problemen op en daar staan ook wat nadelen tegenover. Dat is normaal. Toch kunnen die talen voor veel problemen toch de beste oplossing zijn. Wie schrijft er nu nog in assembler? Wie schrijft al zijn eigen libraries? Meestal is het goed voor de kwaliteit om dat door een specialist te laten doen zodat jij je aandacht kunt focussen op het probleem wat de klant echt opgelost wil zien.

Ik snap ook niet waarom je talen als C/C++ in vredesnaam zou willen vergelijken met C# of Java. Totaal andere doeltoepassing. De kritiek op dat soort talen is eerder dat ze niet laagdrempelig genoeg zijn waardoor mensen de voorkeur geven aan Python, Ruby, PHP en ga zo maar door. En die talen zijn doorgaans nog een stuk minder geoptimaliseerd voor het soort toepassingen waarvoor je C/C++ gebruikt.

[CodeCaster]

RIP Insomnia. Ik heb Postman opgegeven omdat:

1. Het takketraag werd met opstarten.
2. Het een té diep geneste tablayout kreeg - van workspace naar project naar collection naar request, je weet nooit meer waar je zit.
3. Het geforceerd betaald werd; een team waar ik met 3 anderen gebruik van maakte werd plots gecapt op 3, dus de laatste die inlogde moest één van de anderen eruitgooien.

Ik betaal graag voor nuttige tooling, maar € 144 per jaar voor een HTTP/REST-client is echt té. Dus werd het Insomnia, wat met een OAuth-plugin prima bruikbaar te maken is. Supersnel, lekker overzichtelijk, klaar.

Tot de laatste update. Nu heb je ook die verdomde project/collection/request-layout. En zijn al m'n "losse" requests verdwenen.

En over SoapUI met z'n UI uit 2000 wil ik het niet eens hebben. Fantastische tool, enorm krachtig, leuk ook om testsuites in te bouwen, maar overkill om af en toe een request uit te voeren.

[ Voor 9% gewijzigd door CodeCaster op 30-08-2023 11:58 ]

[RobertMe]

CodeCaster schreef op woensdag 30 augustus 2023 @ 11:57:
RIP Insomnia. Ik heb Postman opgegeven omdat:

1. Het takketraag werd met opstarten.
2. Het een té diep geneste tablayout kreeg - van workspace naar project naar collection naar request, je weet nooit meer waar je zit.
3. Het geforceerd betaald werd; een team waar ik met 3 anderen gebruik van maakte werd plots gecapt op 3, dus de laatste die inlogde moest één van de anderen eruitgooien.

Ik betaal graag voor nuttige tooling, maar € 144 per jaar voor een HTTP/REST-client is echt té. Dus werd het Insomnia, wat met een OAuth-plugin prima bruikbaar te maken is. Supersnel, lekker overzichtelijk, klaar.

Tot de laatste update. Nu heb je ook die verdomde project/collection/request-layout. En zijn al m'n "losse" requests verdwenen.

En over SoapUI met z'n UI uit 2000 wil ik het niet eens hebben. Fantastische tool, enorm krachtig, leuk ook om testsuites in te bouwen, maar overkill om af en toe een request uit te voeren.

Is dit een verkapte vraag? Dan is dit een verkapt antwoord

Note: zelf maar zeer incidenteel gebruikt ~1 jaar geleden. Dus het kan best dat het dezelfde "issues" heeft.

[wackmaniac]

CodeCaster schreef op woensdag 30 augustus 2023 @ 11:57:
RIP Insomnia. Ik heb Postman opgegeven omdat:

1. Het takketraag werd met opstarten.
2. Het een té diep geneste tablayout kreeg - van workspace naar project naar collection naar request, je weet nooit meer waar je zit.
3. Het geforceerd betaald werd; een team waar ik met 3 anderen gebruik van maakte werd plots gecapt op 3, dus de laatste die inlogde moest één van de anderen eruitgooien.

Ik betaal graag voor nuttige tooling, maar € 144 per jaar voor een HTTP/REST-client is echt té. Dus werd het Insomnia, wat met een OAuth-plugin prima bruikbaar te maken is. Supersnel, lekker overzichtelijk, klaar.

Tot de laatste update. Nu heb je ook die verdomde project/collection/request-layout. En zijn al m'n "losse" requests verdwenen.

En over SoapUI met z'n UI uit 2000 wil ik het niet eens hebben. Fantastische tool, enorm krachtig, leuk ook om testsuites in te bouwen, maar overkill om af en toe een request uit te voeren.

Oh jee, ben hier net overgestapt van Postman naar Insomnia. Heb direct die nieuwe interface gehad, dus ik ben niets verloren, maar vind het wel onoverzichtelijk.

Kreeg op Reddit de tip dat de Jetbrains producten een vrij aardige HTTP client heeft, waar je ook omgevingen met variabelen kan optuigen. Heb het zelf nog niet geprobeerd.

[CodeCaster]

RobertMe schreef op woensdag 30 augustus 2023 @ 13:01:
[...]

Is dit een verkapte vraag? Dan is dit een verkapt antwoord

Note: zelf maar zeer incidenteel gebruikt ~1 jaar geleden. Dus het kan best dat het dezelfde "issues" heeft.

quote: https://en.wikipedia.org/...am#%22Cunningham's_Law%22

The best way to get the right answer on the Internet is not to ask a question; it's to post the wrong answer.

Ik was op zich niet op zoek naar een nieuwe client, ik kom hier alleen even mijn rant droppen omdat ik mijn Nuxt3 Content Docus-blog nog steeds niet live heb. (Omdat ik ruzie heb met de mappenstructuur en sortering daarvan.)

Ik word ook niet blij van de hoeveelheid verkeer naar hoppscotch.io en de vluchtigheid van local storage waarin je collecties worden bijgehouden.

[ Voor 12% gewijzigd door CodeCaster op 30-08-2023 13:10 ]

[CodeCaster]

wackmaniac schreef op woensdag 30 augustus 2023 @ 13:07:
[...]


Oh jee, ben hier net overgestapt van Postman naar Insomnia. Heb direct die nieuwe interface gehad, dus ik ben niets verloren, maar vind het wel onoverzichtelijk.

Kreeg op Reddit de tip dat de Jetbrains producten een vrij aardige HTTP client heeft, waar je ook omgevingen met variabelen kan optuigen. Heb het zelf nog niet geprobeerd.

Ook een goeie. Ik heb het All Products Pack, dus zal Rider moeten installeren om diens HTTP Client te testen.

[Kalentum]

Voor degenen die denken... "Postman, Insomnia, WTF? waarom niet gewoon curl?"

Morgenavond 2,5 uur lang curl masterclass van de maintainer himself!

https://daniel.haxx.se/bl...ng-the-curl-command-line/

[Caelorum]

wackmaniac schreef op woensdag 30 augustus 2023 @ 13:07:
[...]
Kreeg op Reddit de tip dat de Jetbrains producten een vrij aardige HTTP client heeft, waar je ook omgevingen met variabelen kan optuigen. Heb het zelf nog niet geprobeerd.

Wat overigens vanuit de Visual Studio Code (extensie uit 2016) hoek komt. Ondersteuning zit ook in Visual Studio 2022 en inderdaad in alle jetbrains IDEs.

[ Voor 19% gewijzigd door Caelorum op 30-08-2023 13:33 ]

[RobertMe]

Caelorum schreef op woensdag 30 augustus 2023 @ 13:31:
[...]

Wat overigens vanuit de Visual Studio Code hoek komt. Ondersteuning zit ook in Visual Studio en inderdaad in alle jetbrains IDEs.

Het lijkt mij vrij sterk dat in de JetBrains IDEs iets zit dat uit VS (Code) komt. Sure, wellicht features / ideeën over genomen. Maar het zijn toch wel drie IDEs die "from scratch" zijn gemaakt (ok, VS Code was een fork van <kom niet op de naam>, maar die was wel "from scratch").

[Caelorum]

RobertMe schreef op woensdag 30 augustus 2023 @ 13:34:
[...]

Het lijkt mij vrij sterk dat in de JetBrains IDEs iets zit dat uit VS (Code) komt. Sure, wellicht features / ideeën over genomen. Maar het zijn toch wel drie IDEs die "from scratch" zijn gemaakt (ok, VS Code was een fork van <kom niet op de naam>, maar die was wel "from scratch").

Laat ik het zo zeggen. Iemand had een extensie voor Visual Studio Code hoek gemaakt waarin die hele .http "standaard" is vastgelegd. Jetbrains heeft dat sinds dit jaar in hun eigen producten ingebouwd. Het idee komt uti de VS Code hoek.

Uiteraard de implementatie niet, al is die wel gewoon open source dus wie weet wat ze daarvan hebben overgenomen

[ Voor 8% gewijzigd door Caelorum op 30-08-2023 13:36 ]

[Caelorum]

Oja, en als iemand doorgaans zegt dat iets uit een bepaalde hoek komt van het vakgebied dan wordt daar doorgaans niet mee bedoeld dat het 1 op 1 overgekopieerd is...

En in dat geval is het helemaal logisch dat het niet is gedaan, want Jetbrains extensions zijn een mengelmoes van c#, kotlin en soms zelfs nog wat java, waar die van Visual Studio Code allemaal javascript(-like) zijn.

[ Voor 40% gewijzigd door Caelorum op 30-08-2023 13:38 ]

[RobertMe]

Caelorum schreef op woensdag 30 augustus 2023 @ 13:35:
[...]

Laat ik het zo zeggen. Iemand had een extensie voor Visual Studio Code hoek gemaakt waarin die hele .http "standaard" is vastgelegd. Jetbrains heeft dat sinds dit jaar in hun eigen producten ingebouwd. Het idee komt uti de VS Code hoek.

Uiteraard de implementatie niet, al is die wel gewoon open source dus wie weet wat ze daarvan hebben overgenomen

V.w.b. standaard en van wie het afkomstig is weet ik niet. Maar ik denk wel dat het er al langer in zit? Gebruik het maar zeer sporadisch, maar volgensmij ook al langer dan 1 jaar terug.

Alhoewel er daarvoor ook een totaal onbruikbare REST client in heeft gezeten.

[Caelorum]

RobertMe schreef op woensdag 30 augustus 2023 @ 13:38:
[...]
V.w.b. standaard en van wie het afkomstig is weet ik niet. Maar ik denk wel dat het er al langer in zit? Gebruik het maar zeer sporadisch, maar volgensmij ook al langer dan 1 jaar terug.

Alhoewel er daarvoor ook een totaal onbruikbare REST client in heeft gezeten.

ahja, 2020 blijkbaar. Nog steeds ruim later dan de VS Code extensie.

[Voutloos]

Rustig maar, ik gun het de Nieuwe MS Notepad wel om een keer een feature eerder te hebben dan de echte IDE's.

[Voutloos]

Postman en Insomnia zijn inderdaad vervelend. Ik wissel maandelijks van de ene naar de andere als ik bepaalde Dark Patterns weer zat ben.

Iets met ezel en steen, maar ik heb ook nog niet de perfecte rest client. Zal de Jetbrains client weer een keer proberen, die deed een paar jaar terug inderdaad bepaald niet mee.

[P-Storm]

Door de link van de curl masterclass url, kwam ik op https://daniel.haxx.se/bl...-that-is-wrong-with-cves/ uit. Weer een interessante read, en jammer dat het zo gelopen is.

[DevWouter]

P-Storm schreef op woensdag 30 augustus 2023 @ 16:24:
Door de link van de curl masterclass url, kwam ik op https://daniel.haxx.se/bl...-that-is-wrong-with-cves/ uit. Weer een interessante read, en jammer dat het zo gelopen is.

Helaas ook niet de eerste keer.
Overigens valt het bij mezelf op dat elke keer dat ik hoor dat iets een CVE heeft, en dat zijn andere tools dan curl, ik me vooral inlees wat het is om vervolgens de conclusie te trekken dat een non-issue voor mij is.

[CodeCaster]

Kalentum schreef op woensdag 30 augustus 2023 @ 13:24:
Voor degenen die denken... "Postman, Insomnia, WTF? waarom niet gewoon curl?"

Morgenavond 2,5 uur lang curl masterclass van de maintainer himself!

https://daniel.haxx.se/bl...ng-the-curl-command-line/

Ach ja, de command line, voor mensen die een hekel hebben aan productiviteit.

Ik werk fijner met een grafisch overzicht.

[DevWouter]

CodeCaster schreef op donderdag 31 augustus 2023 @ 08:51:
[...]

Ach ja, de command line, voor mensen die een hekel hebben aan productiviteit.

Ik werk fijner met een grafisch overzicht.

code:

git add . ;  git commit -m "Increase performance"; ./run-test && git push;

En dan ga ik in tussen drinken pakken.

[RagingPenguin]

Voutloos schreef op woensdag 30 augustus 2023 @ 15:05:
Rustig maar, ik gun het de Nieuwe MS Notepad wel om een keer een feature eerder te hebben dan de echte IDE's.

Ach ja, de echte IDE's. Dat die Jetbrains zooi nog met een beter uitgewerkte print functie komt dan een project-wijde zoek of git-intergratie zegt wel genoeg over welke demografie nog van die zinloos massive IDE's gebruikt

[ThomasG]

CodeCaster schreef op donderdag 31 augustus 2023 @ 08:51:
[...]

Ach ja, de command line, voor mensen die een hekel hebben aan productiviteit.

Ik werk fijner met een grafisch overzicht.

Het ligt er aan. Voor veel dingen gebruik ik een grafische interface. Voor het builden van C++ en Java code gebruik ik echter de command line. Voor git ook. Dat is zoveel sneller en productiever dan een GUI. (Behalve als je een Windows gebruiker hebt, of bash als shell gebruikt )

[CodeCaster]

ThomasG schreef op donderdag 31 augustus 2023 @ 11:25:
[...]
Het ligt er aan. Voor veel dingen gebruik ik een grafische interface. Voor het builden van C++ en Java code gebruik ik echter de command line. Voor git ook. Dat is zoveel sneller en productiever dan een GUI. (Behalve als je een Windows gebruiker hebt, of bash als shell gebruikt )

Ik ga deze discussie graag met iedereen aan, maar de CLI past niet in mijn Git-workflow.

Het samenstellen van een commit, dus het selecteren welke bestanden en/of hunks erin komen, is voor mij in Git Extensions:
• Ctrl+Spatie om het commit-scherm te openen
• Met de pijltjestoetsen navigeren door de gewijzigde bestanden, die in een ander panel direct een diff toont
• S voor Stage, U voor Unstage terwijl een bestandsnaam is geselecteerd; Ctrl+A, S is ongeveer 10x sneller getypt dan "git add . [Enter]".
• Tab, tab, commit message typen
• Ctrl+Enter om te committen
• Ctrl+Shift+Up om te pushen.

Bij een interactieve rebase rechtsklik ik op de commit vanaf waar die moet plaatsvinden en hou overzicht over de commits. Op de CLI moet ik hele paden gaan typen en hashes kopiëren en shit. Nog afgezien van het overzicht van welke branches er zijn, hoe ver die voor- en achterlopen, op een veel hogere resolutie dan die 120x40 karakters aan ASCII-art.

Maar ik heb de hele dag een Windows Terminal draaien met daarin verschillende tabs open; ik gebruik de CLI waar nodig.

[ Voor 8% gewijzigd door CodeCaster op 31-08-2023 11:39 ]

[roeleboel]

DevWouter schreef op donderdag 31 augustus 2023 @ 10:54:
[...]

code:

git add . ;  git commit -m "Increase performance"; ./run-test && git push;

En dan ga ik in tussen drinken pakken.

Iedereen weet toch dat productiviteit gemeten wordt in aantal muisclicks

[RobertMe]

CodeCaster schreef op donderdag 31 augustus 2023 @ 11:36:
Het samenstellen van een commit, dus het selecteren welke bestanden en/of hunks erin komen, is voor mij in Git Extensions:
• Ctrl+Spatie om het commit-scherm te openen
• Met de pijltjestoetsen navigeren door de gewijzigde bestanden, die in een ander panel direct een diff toont
• S voor Stage, U voor Unstage terwijl een bestandsnaam is geselecteerd; Ctrl+A, S is ongeveer 10x sneller getypt dan "git add . [Enter]".
• Tab, tab, commit message typen
• Ctrl+Enter om te committen
• Ctrl+Shift+Up om te pushen.

Hoe is dit veel anders dan git add -p? Dan vraagt die per hunk wat je wilt doen, met naast stagen / niks doen ook opties om de rest van de file te stagen of de rest van de file over te slaan. Waarbij je ook nog eens een hunk kunt aanpassen mocht je dat willen (dus puur de code om te stagen aanpassen zonder de file te wijzigen). Met y/n/s/e kom ik dan een heel eind (dus yes / no / split (als er bv 5 unchanged regels tussen 2 hunks zitten en die het als 1 hunk presenteert, met split krijg je beide dan los) / edit).

[CodeCaster]

DevWouter schreef op donderdag 31 augustus 2023 @ 10:54:
[...]

code:

git add . ;  git commit -m "Increase performance"; ./run-test && git push;

En dan ga ik in tussen drinken pakken.

Met het risico te happen: soms wil je gewoon de data zien die uit een API-call komt? Met functionaliteiten als syntax highlighting, het in- en uitklappen van geneste gegevens, het kunnen aanpassen van query/routeparameters, enzovoorts.

Daarna maak je integratietests, sure.

[CodeCaster]

RobertMe schreef op donderdag 31 augustus 2023 @ 11:42:
[...]

Hoe is dit veel anders dan git add -p? Dan vraagt die per hunk wat je wilt doen, met naast stagen / niks doen ook opties om de rest van de file te stagen of de rest van de file over te slaan. Waarbij je ook nog eens een hunk kunt aanpassen mocht je dat willen (dus puur de code om te stagen aanpassen zonder de file te wijzigen). Met y/n/s/e kom ik dan een heel eind (dus yes / no / split (als er bv 5 unchanged regels tussen 2 hunks zitten en die het als 1 hunk presenteert, met split krijg je beide dan los) / edit).

Dat het modal is (je kunt niet tegelijk andere informatie op je scherm hebben), dat je elke keer elk bestand moet behandelen en dat één voor één, dat het in een onoverzichtelijk terminal-font is (grote, niet-proportionele letters), dat het niet in je IDE opent maar in je default editor, enzovoorts.

[ThomasG]

CodeCaster schreef op donderdag 31 augustus 2023 @ 11:36:
[...]

Ik ga deze discussie graag met iedereen aan, maar de CLI past niet in mijn Git-workflow.

Het samenstellen van een commit, dus het selecteren welke bestanden en/of hunks erin komen, is voor mij in Git Extensions:
• Ctrl+Spatie om het commit-scherm te openen
• Met de pijltjestoetsen navigeren door de gewijzigde bestanden, die in een ander panel direct een diff toont
• S voor Stage, U voor Unstage terwijl een bestandsnaam is geselecteerd; Ctrl+A, S is ongeveer 10x sneller getypt dan "git add . [Enter]".
• Tab, tab, commit message typen
• Ctrl+Enter om te committen
• Ctrl+Shift+Up om te pushen.

Bij een interactieve rebase rechtsklik ik op de commit vanaf waar die moet plaatsvinden en hou overzicht over de commits. Op de CLI moet ik hele paden gaan typen en hashes kopiëren en shit. Nog afgezien van het overzicht van welke branches er zijn, hoe ver die voor- en achterlopen, op een veel hogere resolutie dan die 120x40 karakters aan ASCII-art.

Maar ik heb de hele dag een Windows Terminal draaien met daarin verschillende tabs open; ik gebruik de CLI waar nodig.

Mijn flow is volgt:
- gws - alias git git status --short, om te kijken wat ik veranderd heb.
- giA - alias voor git add --patch, en dan is het y/n/a/d/s. Vaak combineer ik dan met het begin van het path van wat ik wil committen. dus iets als giA module-1
- soms weet ik dat ik ik alles wil, en dan is het gewoon gia .
- gc - alias voor git commit --verbose
- soms zie ik uit gws dat ik losse commits wil doen van hele bestanden (of combinaties daarvan), en dan is het bijvoorbeeld gc path-1 file-2
- gp - alias voor git push

Mijn shell auto-complete git. Ik kan dus bijvoorbeeld gc typen, en daarna met tab door de bestanden cyclen. Ook het eventueel kopiëren en plakken van hashes is een fluitje van een cent: dubbel klik, command-copy, command-paste.

Dit alles gebeurt gewoon in de terminal onder aan mijn IDE. Of het nu IntelliJ of vscode is. En ja, de git commit message typ ik in vim.

Zo kun je een honderden regels code over meerdere bestanden reviewen en committen in een paar seconden. Kan geen GUI tegen op.

[ThomasG]

CodeCaster schreef op donderdag 31 augustus 2023 @ 11:46:
[...]

Dat het modal is (je kunt niet tegelijk andere informatie op je scherm hebben), dat je elke keer elk bestand moet behandelen en dat één voor één, dat het in een onoverzichtelijk terminal-font is (grote, niet-proportionele letters), dat het niet in je IDE opent maar in je default editor, enzovoorts.

Alles wat je hier noemt is alleen een probleem als je een slechte terminal gebruikt.

[CodeCaster]

ThomasG schreef op donderdag 31 augustus 2023 @ 12:00:
[...]
Mijn flow is volgt:
- gws - alias git git status --short, om te kijken wat ik veranderd heb.
- giA - alias voor git add --patch, en dan is het y/n/a/d/s. Vaak combineer ik dan met het begin van het path van wat ik wil committen. dus iets als giA module-1
- soms weet ik dat ik ik alles wil, en dan is het gewoon gia .
- gc - alias voor git commit --verbose
- soms zie ik uit gws dat ik losse commits wil doen van hele bestanden (of combinaties daarvan), en dan is het bijvoorbeeld gc path-1 file-2
- gp - alias voor git push

Mijn shell auto-complete git. Ik kan dus bijvoorbeeld gc typen, en daarna met tab door de bestanden cyclen. Ook het eventueel kopiëren en plakken van hashes is een fluitje van een cent: dubbel klik, command-copy, command-paste.

Dit alles gebeurt gewoon in de terminal onder aan mijn IDE. Of het nu IntelliJ of vscode is. En ja, de git commit message typ ik in vim.

Zo kun je een honderden regels code over meerdere bestanden reviewen en committen in een paar seconden. Kan geen GUI tegen op.

Ik ben vaak langer bezig met bepalen welke (delen van) bestanden in een commit komen dan met de rest. Ik zie niet hoe het intypen van (delen van) paden sneller is dan het aanklikken of met de pijltjestoetsen highlighten van bestanden, waarbij je dan ook nog eens direct de diff te zien krijgt.

Mijn git status is altijd direct in beeld in mijn Git-GUI. Ik ben ook allergisch voor terminals in IDE's. Leuk om een yarn watch of npm run dev of weet ik wat in te runnen, maar zodra je enigszins leesbaar meerdere regels in beeld wil hebben, moet je stuff gaan resizen. Dan Alt+Tab ik liever naar een dedicated terminal of GUI.

[CodeCaster]

ThomasG schreef op donderdag 31 augustus 2023 @ 12:08:
[...]
Alles wat je hier noemt is alleen een probleem als je een slechte terminal gebruikt.

Wat maakt een terminal dan "slecht" of juist goed?

[RagingPenguin]

CodeCaster schreef op donderdag 31 augustus 2023 @ 12:13:
[...]

Wat maakt een terminal dan "slecht" of juist goed?

Een hoop dingen die je zelf al noemt zijn enkel eigenschappen van slechte terminals zoals de Windows terminal: fatsoenlijke fontsize, highlighting, files openen in de juiste programma's e.d zijn allemaal dingen die elke redelijke terminal kan.

[Voutloos]

De meeste terminals zijn vrij slecht als je checkboxes wil aanklikken. Vermoeiend dit. Right tool for the job, en soms is er overlap.

[Kalentum]

CodeCaster schreef op donderdag 31 augustus 2023 @ 12:13:
[...]

Wat maakt een terminal dan "slecht" of juist goed?

Wat ik veel gebruik bij een terminal: eenvoudig opsplitsen (meerdere terminals in 1 venster en daar tussen wisselen), scroll history

Daarnaast maakt het ook wat uit wat voor shell je gebruikt. zsh met een paar plugins via Oh My Zsh scheelt al een boel. Werken met git wordt makkelijker, door de command history ploegen, file name completion.

[CodeCaster]

Kalentum schreef op donderdag 31 augustus 2023 @ 13:07:
[...]


Wat ik veel gebruik bij een terminal: eenvoudig opsplitsen (meerdere terminals in 1 venster en daar tussen wisselen), scroll history

Daarnaast maakt het ook wat uit wat voor shell je gebruikt. zsh met een paar plugins via Oh My Zsh scheelt al een boel. Werken met git wordt makkelijker, door de command history ploegen, file name completion.

Die heb ik op de Mac gebruikt, erg fijne shell inderdaad. Mooie kleuren, customizations, plugins, out of the box al veel leuke goodies.

Toch blijf ik Windows-fan en wil ik bestandsnamen gewoon in een lijstje zien en selecteren met toetsenbord in plaats van twintig keer per dag foo/bar/baz/services/IFooService.cs typen of laten completeren.

[ Voor 5% gewijzigd door CodeCaster op 31-08-2023 13:10 ]

[DevWouter]

CodeCaster schreef op donderdag 31 augustus 2023 @ 11:43:
[...]

Met het risico te happen: soms wil je gewoon de data zien die uit een API-call komt? Met functionaliteiten als syntax highlighting, het in- en uitklappen van geneste gegevens, het kunnen aanpassen van query/routeparameters, enzovoorts.

Daarna maak je integratietests, sure.

Het testen en alles is al vooraf gedaan (sowieso eerst de test dan de rest), die extra test-run is alleen maar om te garanderen dat er niet per ongeluk kapot code gepush wordt.

En wat betreft "data zien": Als ik TDD hanteer dan hoef ik zelden een inspectie te doen.

Overigens gebruik ik net zo vaak git log --grep=bug en gitk vanaf de command line. Wel is het zo dat ik gitk vaker gebruik als ik geen structuur verwacht (of wanneer iemand alleen maar ticket nummers in zijn commit zet)

[dev10]

In het kader van YOLO heeft DHH besloten dat TypeScript niet nodig is voor Turbo 8. Er is een pull request aangemaakt waarmee de library in een actie van TypeScript is aangepast naar Javascript. Verschillende mensen hebben daar opmerkingen over, maar de PR wordt binnen een paar uur gemerged met de opmerking:

All the love and appreciation to contributors who would prefer TypeScript. This is one of those debates where arguments aren't likely to move anyone's fundamental position, so I won't attempt to do that.

In een klap alle lopende pull requests grotendeels obsolete gemaakt en een hele hoop boze mensen. Ik vraag me af hoe hoog je ivoren toren dan is hoor.

[ThomasG]

dev10 schreef op donderdag 7 september 2023 @ 11:34:
In het kader van YOLO heeft DHH besloten dat TypeScript niet nodig is voor Turbo 8. Er is een pull request aangemaakt waarmee de library in een actie van TypeScript is aangepast naar Javascript. Verschillende mensen hebben daar opmerkingen over, maar de PR wordt binnen een paar uur gemerged met de opmerking:


[...]


In een klap alle lopende pull requests grotendeels obsolete gemaakt en een hele hoop boze mensen. Ik vraag me af hoe hoog je ivoren toren dan is hoor.

Dan vind ik deze pull-request de leukste: https://github.com/hotwired/turbo/pull/974

Als ik de blog-post lees staan daar exact dezelfde argumenten in die je zou kunnen gebruiken om geen unit-tests te hebben. Wat het project dus ook niet lijkt te hebben. Lijkt dus op een project van een stel cowboy programmeurs.

[ Voor 17% gewijzigd door ThomasG op 07-09-2023 11:50 ]

[dev10]

Het zijn wel precies de pull-requests die je kunt verwachten als je zo'n actie doorvoert. Toch vind ik daar ook nog wel wat van, want je gaat precies niet bereiken wat je er mee voor ogen hebt.

[Janoz]

All the love and appreciation to contributors who would prefer TypeScript. This is one of those debates where arguments aren't likely to move anyone's my fundamentallistic position, so I won't attempt to do that.

FIFY

[Caelorum]

Uit die blogpost:

While you may compile dialects into it, you still have to accept the fact that running code in the browser means running JavaScript.

Doe vlieger gaat eigenlijk ook niet meer op toch?

[Mugwump]

Caelorum schreef op donderdag 7 september 2023 @ 18:13:
Uit die blogpost:

[...]

Doe vlieger gaat eigenlijk ook niet meer op toch?

Niet meer sinds WASM inderdaad, maar dan nog. Een computer voert enkel machinecode uit, maar dat staat het gebruik en bestaan van tientallen gangbare programmeertalen ook niet in de weg.

[ThomasG]

Mugwump schreef op donderdag 7 september 2023 @ 22:18:
[...]


Niet meer sinds WASM inderdaad, maar dan nog.

Jawel, want WASM kan geen dom manipulaties doen. En om data/events van en naar de WASM te sturen heb je javascript nodig.Of je moet iets maken dat geisoleerd draait, en niet bij de dom hoeft. Dan heb je in principe geen javascript nodig.

[.oisyn]

WASM is idd meer gewoon een black box die je kunt aanroepen vanuit javascript en die ook weer callbacks kan doen naar jouw javascript code.

[Caelorum]

Tja, WASM geeft me gewoon flashbacks naar Flash websites: https://jnmaloney.github.io/WebGui/imgui.html
Werkt prima

[Ryur]

RobertMe schreef op woensdag 30 augustus 2023 @ 13:34:
[...]

Het lijkt mij vrij sterk dat in de JetBrains IDEs iets zit dat uit VS (Code) komt. Sure, wellicht features / ideeën over genomen. Maar het zijn toch wel drie IDEs die "from scratch" zijn gemaakt (ok, VS Code was een fork van <kom niet op de naam>, maar die was wel "from scratch").

Atom

[.oisyn]

Caelorum schreef op donderdag 7 september 2023 @ 22:37:
Tja, WASM geeft me gewoon flashbacks naar Flash websites: https://jnmaloney.github.io/WebGui/imgui.html
Werkt prima

Dit heeft natuurlijk weinig met WASM te maken, met webgl kun je precies hetzelfde.

[BarôZZa]

.oisyn schreef op vrijdag 8 september 2023 @ 08:59:
[...]


Dit heeft natuurlijk weinig met WASM te maken, met webgl kun je precies hetzelfde.

Het probleem van WASM vind ik dit: https://jnmaloney.github.io/WebGui/imgui.wasm

Waar we op een gegeven moment juist richting een semantischer web gingen, gaan we er nu weer verder vandaan.

Het is wachten tot zoiets als React of een ander hype framework besluit om alles naar WebAssembly te compileren en hoeraa, het hele web is weer onleesbaar zoals bij Flash. En als ze dan ook alles renderen in een canvas (eventueel met WebGL because why not), dan is het Flash cirkeltje helemaal weer rond. Lekker de rechter muisknop en tekst selecteren uitschakelen, misschien ook weer intro's maken en muziek op de achtergrond aan

[.oisyn]

@BarôZZa: volgens mij haal je wat dingen door elkaar. Die .wasm file is puur code. Net als javascript dat is. En beide hebben weinig met een semantisch web te maken, of de leesbaarheid van een pagina door een robot. En wat code-leesbaarheid voor de mens betreft, minified javascript is natuurlijk net zo min leesbaar. Waar jij geïnteresseerd in lijkt te zijn (het semantische web) is de DOM en hoe die is opgebouwd, niet zozeer in de achterliggende code die die DOM opbouwt.

WASM impliceert niet het renderen naar een canvas, en net zo min impliceert het gemis aan WASM niet dat men niet naar een canvas kan renderen.

Wat dit specifieke voorbeeld betreft, Dear ImGui is een "immediate gui" library voor C++ (en geport naar andere talen zoals Rust) met rendering backends voor bijv. OpenGL en Direct3D zodat je snel een UI op het scherm kunt toveren voor bijv. rapid prototyping of debugging in een 3D applicatie. Het wordt hier nogal uit context gebruikt. Maar evenmin is WASM hiervoor nodig, want er bestaan (natuurlijk) ook gewoon javascript bindings (via Emscripten).

[ Voor 39% gewijzigd door .oisyn op 08-09-2023 10:41 ]

[Sebazzz]

@Typescript discussie: DHH is sowieso wel een wat controversieel figuur tegenwoordig he

[Voutloos]

1. Hij zegt dat ie niemand wil gaan overtuigen want dat is toch kansloos.
2. Alle discussies hier/github/reddit beginnen met die quote.
3. Iedereen gaat alsnog met elkaar discussiëren over alle voor- en nadelen, al dan niet met wat ad hominems.

Wie is dan de gek?

[RagingPenguin]

Sebazzz schreef op zondag 10 september 2023 @ 10:46:
@Typescript discussie: DHH is sowieso wel een wat controversieel figuur tegenwoordig he

Is die eigenlijk altijd wel geweest, maar in het Ruby wereldje had genoeg fanboys om er mee weg te komen.

[RagingPenguin]

Voutloos schreef op zondag 10 september 2023 @ 11:36:
1. Hij zegt dat ie niemand wil gaan overtuigen want dat is toch kansloos.
2. Alle discussies hier/github/reddit beginnen met die quote.
3. Iedereen gaat alsnog met elkaar discussiëren over alle voor- en nadelen, al dan niet met wat ad hominems.

Wie is dan de gek?

FIFY:

1. Hij zegt dat ie niemand wil gaan overtuigen want dat is toch kansloos.
2. Hij geeft toch een lijst met zijn eigen argumenten
3. Hij duwt zijn mening door iedereens strot zonder enige input vanuit de community en zonder enige aankondiging
4. Geeft de community die het niet met hem eens is nog even een trap na door ze een 'tribe' en 'gang' te noemen die "niet snappen hoe JavaScript bedoelt is"
4. Surprised pikachu face voor de backlash

[Voutloos]

Niets FIFY, je bewijst precies mijn punt.

Zijn bericht is niveautje ‘ik doe niet meer mee’. Nou, laat hem dan. Zonde van de repo, maar die macht heeft hij, en zijn ware aard weet je dan bij deze. Rest enkel polariseren… dus ga gewoon (tercht) door met typescript, zonder DHH.
Een succesvolle fork is wellicht uiteindelijk het beste argument.

[ Voor 10% gewijzigd door Voutloos op 10-09-2023 14:21 ]

[.oisyn]

Maar volgens mij is er nog een hele andere tangent, namelijk het feit dat deze change er eigenlijk compleet zonder code review doorheen is geramd, waardoor de huidige code (door het gemis van types) ineens behoorlijk onduidelijk is geworden. Je kunt objectief gewoon stellen dat de kwaliteit nu achteruit is gegaan, en dat staat compleet los van elk argument voor of tegen het gebruik van typescript.

[Verwijderd]

.oisyn schreef op maandag 11 september 2023 @ 21:39:
Maar volgens mij is er nog een hele andere tangent, namelijk het feit dat deze change er eigenlijk compleet zonder code review doorheen is geramd, waardoor de huidige code (door het gemis van types) ineens behoorlijk onduidelijk is geworden. Je kunt objectief gewoon stellen dat de kwaliteit nu achteruit is gegaan, en dat staat compleet los van elk argument voor of tegen het gebruik van typescript.

Wat maakt type definitie per se beter dan loose types. Je moet gewoon de documentatie goed bijhouden. Ik wilde vroeger nog wel eens functies herbruiken die dan meerdere types aan kon, bij Kiss willen ze er niet aan, maar gebruiksgemak is ook wat.

Hetzelfde wat bij Java kan middels verschillende constructors. En een s voor je variabele om een string aan te duiden is ook wat over te zeggen.

[.oisyn]

Verwijderd schreef op maandag 11 september 2023 @ 22:31:
[...]


Wat maakt type definitie per se beter dan loose types.

Is dat een vraag gericht aan mij? Ik stelde niet het een of het ander in mijn post

Je moet gewoon de documentatie goed bijhouden.

Dat was dus ook mijn punt, dat dat niet is gedaan, de types zijn weggehaald en de change is erin geYOLO'd. De parameternamen zijn te generiek, maar aan het type kon je nog afleiden wat het moest zijn (bijvoorbeeld een parameter node met het type HtmlBodyElement, ik verzin maar iets). Gooi je de types weg, dan verdwijnt er informatie uit de code.

[ Voor 4% gewijzigd door .oisyn op 11-09-2023 22:50 ]

[armageddon_2k1]

BarôZZa schreef op vrijdag 8 september 2023 @ 09:33:
[...]

Het probleem van WASM vind ik dit: https://jnmaloney.github.io/WebGui/imgui.wasm

Waar we op een gegeven moment juist richting een semantischer web gingen, gaan we er nu weer verder vandaan.

Het is wachten tot zoiets als React of een ander hype framework besluit om alles naar WebAssembly te compileren en hoeraa, het hele web is weer onleesbaar zoals bij Flash. En als ze dan ook alles renderen in een canvas (eventueel met WebGL because why not), dan is het Flash cirkeltje helemaal weer rond. Lekker de rechter muisknop en tekst selecteren uitschakelen, misschien ook weer intro's maken en muziek op de achtergrond aan

Je bedoelt Flutter? Of Compose for Web? Of blazor?

[armageddon_2k1]

Trouwens, wat doen jullie met (senior) devs die gewoon geen tests schrijven?

[Caelorum]

armageddon_2k1 schreef op dinsdag 12 september 2023 @ 18:38:
Trouwens, wat doen jullie met (senior) devs die gewoon geen tests schrijven?

Je bedoelt junioren?

[Kalentum]

armageddon_2k1 schreef op dinsdag 12 september 2023 @ 18:38:
Trouwens, wat doen jullie met (senior) devs die gewoon geen tests schrijven?

opvoeden. code reviews en dan dus pas mergen als het allemaal goed is?

[CodeCaster]

armageddon_2k1 schreef op dinsdag 12 september 2023 @ 18:38:
Trouwens, wat doen jullie met (senior) devs die gewoon geen tests schrijven?

Dat heb ik ook aan @djidee gevraagd, en die zei: ze bewust maken van het risico, zodat ze kunnen committeren dat ze het risico bewust nemen. En opnemen in Definition of Done, zodat het niet af is als het niet bewezen getest is. En anders hogerop aankaarten. Toch?

[ Voor 7% gewijzigd door CodeCaster op 12-09-2023 20:07 ]

[Caelorum]

Overigens als het niet onkunde is maar onwil dan werken quality gates met minimum code coverage toch ineens wel hoor. Dat samen met wat test guidelines, zodat tests die geschreven zijn goed moeten zijn, kunnen ze mooi laten zien of ze wel echt senior zijn. En anders gewoon keihard hun plek wijzen

Ik merk dat ik zowel politieker als juist niet wordt naar mate ik langer in het vak zit. Richting beslissingsmakers mooi meelullen en sturen waar je kan en richting mededevelopers lekker wijzen op dat stilstand achteruitgang is in het vak en dat hoewel ze ooit de beste ontwikkelaars ooit waren (zijn we allemaal geweest), dat na verloop van tijd vaak toch is veranderd en ze nu links en rechts worden ingehaald door de nieuwe generatie.

[djidee]

Niet testen kan, als er geen (bekend) risico is, of als het risico geaccepteerd is (door de eigenaar van de applicatie that is).

Mbt unittesten kun je naast code coverage (100% is niet volledig) een keertje een dagdeel expirimenteren met Mutation testing om samen met de devs een beeld te krijgen van de kwaliteit van de unittesten.

En moet er structureel meer aandacht komen voor kwaliteit kun je ook nog acceptatie criteria meenemen in je userstories (quality gate: definition of ready, ontbreken ze, kan userstory niet opgepakt worden), en hij is pas done als daaraan voldaan is. Stukje shift left.

[Kalentum]

djidee schreef op dinsdag 12 september 2023 @ 21:29:
Niet testen kan, als er geen (bekend) risico is, of als het risico geaccepteerd is (door de eigenaar van de applicatie that is).

Mbt unittesten kun je naast code coverage (100% is niet volledig) een keertje een dagdeel expirimenteren met Mutation testing om samen met de devs een beeld te krijgen van de kwaliteit van de unittesten.

En moet er structureel meer aandacht komen voor kwaliteit kun je ook nog acceptatie criteria meenemen in je userstories (quality gate: definition of ready, ontbreken ze, kan userstory niet opgepakt worden), en hij is pas done als daaraan voldaan is. Stukje shift left.

Wat bedoel je met 'stukje shift left'?

Oh dat je eerder gaat testen, maar dan heb je het over integratietesten?

[ Voor 5% gewijzigd door Kalentum op 12-09-2023 22:12 ]

[Caelorum]

Kalentum schreef op dinsdag 12 september 2023 @ 22:11:
[...]
Wat bedoel je met 'stukje shift left'?

Oh dat je eerder gaat testen, maar dan heb je het over integratietesten?

Links is het idee van een product, rechts is productie. Naar links shiften betekend dat je eerder in het proces het oppakt. Dus bijvoorbeeld afdwingen nog voordat een user story of work item wordt opgepakt dat de testen zijn uitgedacht. Zodat als het werk begint je geen excuus hebt koppel dat met dan een work item pad.als afgemeld mag worden als de testen daadwerkelijk gemaakt zijn en je bent al een heel eind.

[Kalentum]

Caelorum schreef op dinsdag 12 september 2023 @ 22:36:
[...]

Links is het idee van een product, rechts is productie. Naar links shiften betekend dat je eerder in het proces het oppakt. Dus bijvoorbeeld afdwingen nog voordat een user story of work item wordt opgepakt dat de testen zijn uitgedacht. Zodat als het werk begint je geen excuus hebt koppel dat met dan een work item pad.als afgemeld mag worden als de testen daadwerkelijk gemaakt zijn en je bent al een heel eind.

TDD dus?

[Caelorum]

Kalentum schreef op dinsdag 12 september 2023 @ 22:53:
[...]
TDD dus?

TDD wordt meestal tijdens de implementatie toegepast. Of in ieder geval als het werk al is opgepakt. Het ging hier over tijdens de werkvoorbereiding de test cases al uitdenken. Of zo heb ik het begrepen.
Ik push er meestal ook wel op dat de requirements worden vastgelegd in een gherkin-achtige taal tijdens de werkvoorbereiding, zodat er met verschillende testtechnieken op los geschoten kan worden tijdens de implementatie. Maar ik doen het soms voor überhaupt requirements

Ik ben het overigens niet eens met @djidee. Testen is namelijk niet alleen voor de huidig bekende risico's, maar ook om een correcte werking naar de toekomst te kunnen garanderen (of in ieder geval iets meer). Daarnaast heeft de stakeholder of eigenaar er weinig over te zeggen net zo min als dat een opdrachtgever of financierder iets te zeggen heeft over bouwkundige tests in de bouwsector. Jij bent als developer (ook) verantwoordelijk voor de kwaliteit van het werk en mede-eigenaar van problemen die erdoor ontstaan.

[djidee]

Op kwaliteitscriteria zoals onderhoudbaarheid en observeerbaarheid zitten ook risico's.

En vanuit developersperspectief worden die vaak wel ingebracht en ook aangegeven wat het belang is.

No risk komt zelden voor, zodra kans (door complexiteit) of impact (belang voor stakeholder) toeneemt komen de risico's al snel naar boven.

Wat als.

De uitdaging is vaak om ze.

• vooraf concreet te maken
• consensus te bereiken (uitwisseling info + prioriteit bepalen)
• impact risico's mee te nemen in je schatting
• daar afspraken over te maken. Risico kan geaccepteerd worden (uiteindelijk altijd met instemming eigenaar kan team overrulen, verstandig is het vaak niet).

Als zaken concreet gemaakt worden, en risico wordt ondanks alle informatie toch geaccepteerd voorkomt dat later ook het 'hun van IT' blame game. Je hebt gezamenlijk risico's inzichtelijk gemaakt, overleg gepleegd en er is een besluit genomen. En bij onenigheid kan een eigenaar vaak hiërarchisch overrulen. Maar mijn ervaring is dat dat zelden meer gebeurd als zaken expliciet worden gemaakt (want boomerang).

[Kalentum]

Caelorum schreef op woensdag 13 september 2023 @ 00:21:
[...]

TDD wordt meestal tijdens de implementatie toegepast. Of in ieder geval als het werk al is opgepakt. Het ging hier over tijdens de werkvoorbereiding de test cases al uitdenken. Of zo heb ik het begrepen.

Ik probeer mij in te denken hoe die test cases er dan uit zien. Want unit tests zitten op de implementatie (method zus, class zo) en lijkt me niet dat je al een implementatie wilt vast leggen. Maar als je het wat abstracter houdt zit je al snel op user stories.

Ik push er meestal ook wel op dat de requirements worden vastgelegd in een gherkin-achtige taal tijdens de werkvoorbereiding, zodat er met verschillende testtechnieken op los geschoten kan worden tijdens de implementatie. Maar ik doen het soms voor überhaupt requirements

Ik ben het overigens niet eens met @djidee. Testen is namelijk niet alleen voor de huidig bekende risico's, maar ook om een correcte werking naar de toekomst te kunnen garanderen (of in ieder geval iets meer). Daarnaast heeft de stakeholder of eigenaar er weinig over te zeggen net zo min als dat een opdrachtgever of financierder iets te zeggen heeft over bouwkundige tests in de bouwsector. Jij bent als developer (ook) verantwoordelijk voor de kwaliteit van het werk en mede-eigenaar van problemen die erdoor ontstaan.

Zeker. Ik zit nu samen met tientallen devs in een code base van meer dan 10 jaar te werken en moet er niet aan denken als daar niet allerlei tests aan hangen. Dan zou mijn werk voor het grootste deel uit brandjes blussen bestaan.

Ik heb wel eens het gevoel dat er developers zijn die tests als een soort corvee achteraf zien. "het is af, ik moet alleen tests schrijven". Nee, dan is het dus nog niet af. Tests horen een integraal onderdeel van je werkwijze te zijn. Ik ben op zich wel verbaasd dat er senior devs zijn die dat niet doen. Bij ons wordt je er bij code reviews wel op aangesproken. En er is (non-blocking) tooling die detecteert dat je iets hebt gewijzigd zonder dat er tests zijn gewijzigd

[Verwijderd]

Kalentum schreef op woensdag 13 september 2023 @ 08:07:
[...]


Ik probeer mij in te denken hoe die test cases er dan uit zien. Want unit tests zitten op de implementatie (method zus, class zo) en lijkt me niet dat je al een implementatie wilt vast leggen. Maar als je het wat abstracter houdt zit je al snel op user stories.


[...]


Zeker. Ik zit nu samen met tientallen devs in een code base van meer dan 10 jaar te werken en moet er niet aan denken als daar niet allerlei tests aan hangen. Dan zou mijn werk voor het grootste deel uit brandjes blussen bestaan.

Ik heb wel eens het gevoel dat er developers zijn die tests als een soort corvee achteraf zien. "het is af, ik moet alleen tests schrijven". Nee, dan is het dus nog niet af. Tests horen een integraal onderdeel van je werkwijze te zijn. Ik ben op zich wel verbaasd dat er senior devs zijn die dat niet doen. Bij ons wordt je er bij code reviews wel op aangesproken. En er is (non-blocking) tooling die detecteert dat je iets hebt gewijzigd zonder dat er tests zijn gewijzigd

Stel je hebt een klein dev team en een grote code base. Tests kun je op allerlei manieren doen, maar vaak is dat bij kleine teams dan geen unit tests, want geen tijd / budget voor. Hoeveel tests heb je? Ik zie tegenwoordig veel mensen hameren op unit tests, ik wacht nog wel even totdat de ai goeie tests kan schrijven en dan gelijk 20.000 tests ofzo. Tests schrijven is ook een vak apart en de beste tests worden geschreven door andere mensen dan de uitvoerende developer (diegene die de code heeft geschreven).
Ik test momenteel met de hand en ondervind weinig bugs in mijn code. Maarja heb ook jaren ervaring met programmeren en debuggen.

Soms, 1 a 2x per jaar komt het voor dat ik een fout heb geconstateerd in vernieuwde code, dan duik ik in git en plaats de oude versie terug. Als dat niet kan, tsja dan wordt je er druk mee. Ik vind versie beheer bijvoorbeeld belangrijker dan tests.

[Caelorum]

In kleinere teams met erg beperkte tijd zou ik dan ook mee hameren op functionele tests op integratie of E2E vlak. Of hoe ik het liever verwoord: input-output met behulp van bijv. snapshot testing. En ja dan laat je de implementatie deels de test lijden, maar dat is dan een noodzakelijk kwaad. (Zie bijv. Verify voor .net).
En voor vastleggen van je test cases die je nu bijv. handmatig doet in de browser zou je bijv. kunnen kijken naar iets als Playwright test generator, zodat je eenmalig zelf de test uitvoert en er daarna een automatische test van is.
En de combinatie van die twee is nog mooier

(En dit is dan puur alleen om regressie te voorkomen en use cases vast te leggen)

[ Voor 6% gewijzigd door Caelorum op 13-09-2023 12:32 ]

[Janoz]

Verwijderd schreef op woensdag 13 september 2023 @ 12:05:
[...]


Stel je hebt een klein dev team en een grote code base. Tests kun je op allerlei manieren doen, maar vaak is dat bij kleine teams dan geen unit tests, want geen tijd / budget voor. Hoeveel tests heb je? Ik zie tegenwoordig veel mensen hameren op unit tests, ik wacht nog wel even totdat de ai goeie tests kan schrijven en dan gelijk 20.000 tests ofzo. Tests schrijven is ook een vak apart en de beste tests worden geschreven door andere mensen dan de uitvoerende developer (diegene die de code heeft geschreven).
Ik test momenteel met de hand en ondervind weinig bugs in mijn code. Maarja heb ook jaren ervaring met programmeren en debuggen.

Soms, 1 a 2x per jaar komt het voor dat ik een fout heb geconstateerd in vernieuwde code, dan duik ik in git en plaats de oude versie terug. Als dat niet kan, tsja dan wordt je er druk mee. Ik vind versie beheer bijvoorbeeld belangrijker dan tests.

Dit snap ik nooit. Dat met de hand testen. Dan trigger je met de hand een stukje code. Dat gaat toch veel sneller en makkelijker wanneer je dat automatisch doet? Als ik een comperator schrijf ben ik zo lui dat ik niet eens na ga denken of ik ergens een < of > had moeten gebruiken, met een unittest check ik sneller of de elementen in de door mij verwachte volgorde staan. En dat tests altijd door iemand anders zouden moeten worden gemaakt vind ik ook onzin. Of ik zelf genoeg cornercases bedacht heb komt er bij de code review ook wel uit. Voor integratie en E2E testen is het wel handig om een testspecialist er bij te hebben, maar in theorie hoeft diegene ook niet meer dan de daadwerkelijke features te bedenken en te bepalen of dat dekkend genoeg is.

[Mugwump]

Janoz schreef op woensdag 13 september 2023 @ 13:33:
[...]


Dit snap ik nooit. Dat met de hand testen. Dan trigger je met de hand een stukje code. Dat gaat toch veel sneller en makkelijker wanneer je dat automatisch doet? Als ik een comperator schrijf ben ik zo lui dat ik niet eens na ga denken of ik ergens een < of > had moeten gebruiken, met een unittest check ik sneller of de elementen in de door mij verwachte volgorde staan. En dat tests altijd door iemand anders zouden moeten worden gemaakt vind ik ook onzin. Of ik zelf genoeg cornercases bedacht heb komt er bij de code review ook wel uit. Voor integratie en E2E testen is het wel handig om een testspecialist er bij te hebben, maar in theorie hoeft diegene ook niet meer dan de daadwerkelijke features te bedenken en te bepalen of dat dekkend genoeg is.

Met de hand testen is echt bij gebrek aan beter. Wij zijn de laatste hand aan het leggen aan een migratie van een legacysysteem naar een cloud-native oplossing met CI/CD, op alle fronten geautomatiseerde testen en ga zo maar door.
In het oude systeem was de werkwijze letterljik:

1. Story oppakken en bouwen.
2. Deployen op test
3. Aan de voorkant wat data in het systeem gooien
4. In de database kijken of daar staat wat je verwacht
5. wat screenshotjes van het geheel maken en in Word plakken.
6. e-mailen ter goedkeuring

Niet geheel verwonderlijk pleurde het systeem de helft van de tijd om na een release bij een totaal gebrek aan regressietesten.

[Verwijderd]

Met de hand testen is echt bij gebrek aan beter.

Mee eens, maar schrijf maar eens 10.000 unit tests, ik denk dat je al gauw 3 jaar bezig bent, wellicht nog langer. Das toch kostbaar

[Janoz]

Je hoeft er ook niet 10.000 te maken, begin gewoon met 1. Nieuwe feature? Paar testjes erbij.

Maar de grootste winst bij legacy projecten zijn bugfixes. Tijdens de analyse van een bug is het juist super handig om een (integratie)-test te maken die die bug reproduceert ipv telkens maar met de hand de boel af te trappen en de stappen te doorlopen. En zodra de bug gefixed is heb je gratis een stukje testdekking er bij.

[ThomasG]

Ik zie dat hier wordt gesuggereerd dat bij een klein team en een grote codebase unit tests niet nodig zijn, vanwege beperkte tijd of budget. Daar ben ik het niet mee eens. In het verleden heb ik in een klein team met een uitgebreide codebase gewerkt waarin er weinig tot geen (unit) tests waren. Het resultaat daarvan was dat we voortdurend brandjes moesten blussen, dezelfde bugs steeds weer opdoken en dat we bij het mergen niet konden garanderen dat alles nog naar behoren functioneerde, etc. etc. Daar kwamen dan dagen/weken later achter na klachten van klanten.

Als je niet de mankracht, tijd of het budget hebt om (goede) tests te schrijven, heb je überhaupt niet de mankracht, tijd of het budget om die feature te ontwikkelen. Het schrijven van tests maakt namelijk deel uit van het ontwikkelingsproces. Als je dit niet doet, speel je gewoon met vuur. In de praktijk gebeurt dit helaas te vaak.

[phex]

Ik ben niet tegen tests, ik ben van mening dat ze heel waardevol zijn.

Maar als niet steeds bezig bent met (oude)bugs/brandjes fixen, dan heeft je team/code een hoge maturity en hoef je imho niet perse tests te schrijven.

De discussie is vaak:
- Als je geen tests schijft ben je per definitie slecht bezig
- Als je wel tests schrijft ben je tijd en geld aan het verspillen

Terwijl het volgens mij afhangt van je team, code base en use case.

[Creepy]

phex schreef op donderdag 14 september 2023 @ 10:27:
Ik ben niet tegen tests, ik ben van mening dat ze heel waardevol zijn.

Maar als niet steeds bezig bent met (oude)bugs/brandjes fixen, dan heeft je team/code een hoge maturity en hoef je imho niet perse tests te schrijven.

Als je niet steeds brandjes wilt blijven blussen, dan zijn tests ideaal. Dan valt er niet ergens wat onverwacht om, omdat er op een andere plek iets gewijzigd is want dat pikken je tests op. Dus goede tests == hogere maturity.

De discussie is vaak:
- Als je geen tests schijft ben je per definitie slecht bezig
- Als je wel tests schrijft ben je tijd en geld aan het verspillen

Terwijl het volgens mij afhangt van je team, code base en use case.

Als je tijd en geld aan het verspillen bent dan wordt je afgerekend alleen op nieuwe features en niet op kwaliteit. Dat zegt ook iets over de mate van volwassenheid Die tests betalen zich terug door minder bugs en sneller bugs fixen. Die tijd die je aan tests besteedt win je terug, altijd. Dat is misschien niet zichtbaar op hele korte termijn, maar na maanden of jaren is dat het wel. Bugs fixen in productie kost veel meer tijd dan bug fixen tijdens development.

[ Voor 10% gewijzigd door Creepy op 14-09-2023 10:44 ]

[Mugwump]

Verwijderd schreef op woensdag 13 september 2023 @ 14:18:
Met de hand testen is echt bij gebrek aan beter.

Mee eens, maar schrijf maar eens 10.000 unit tests, ik denk dat je al gauw 3 jaar bezig bent, wellicht nog langer. Das toch kostbaar

Voer die 10.000 test bij elke release maar eens met de hand uit, ik denk dat je 30 jaar bezig bent.
Flauw natuurlijk, maar het punt is dat het alternatief voor 'met de hand testen' niet is om achteraf elke regel code van een bestaande legacy codebase af te gaan dichten. Sterker nog, dat zou ik ten zeerste afraden. Ik vind dit wel een mooie representatie van tests op een legacy systeem:



Als je geen tests hebt, dan sta je alle wijzigingen toe. Als je 100% code coverage hebt, dan is zo ongeveer elke change breaking.
Je wilt altijd ergens in het midden zitten. Er is niets frustrerender dan een codebase waarbij een refactoring omwille van de kwaliteit van de code leidt tot 300 falende unit tests. Het andere uiterste is dus de eerder beschreven situatie waarbij je systeem bij elke release weer omvalt omdat je geen enkele vorm van regressie uitvoert.
Voor legacy systemen vind ik approval testing wel een prima manier.

[martin_v_z]

Interessante ontwikkelingen bij Unity.
Het bedrijf wil vanaf 2024 kosten in rekening brengen bij ontwikkelaars op basis van installaties. Aanpassingen op hun service agreement met terugwerkende kracht.

Het forum explodeert er zo'n beetje met boze ontwikkelaars die overwegen om over te stappen naar de concurrent.

Dit kan wel eens het einde van Unity betekenen, het vertrouwen is totaal weg bij ontwikkelaars.

Zijn er hier nog mensen die met Unity ontwikkelen? Ik had net een spel gelanceerd wat er op draait en wou beginnen aan mijn volgende project maar ik ga nu naar alternatieven kijken, ik heb weinig vertrouwen dat dit positief is voor de stabiliteit van het bedrijf en ga niet jaren investeren als ik de kans loop alles over te moeten doen.

[Verwijderd]

Vond het een verhelderend document. Voor de screenshots kan ik denk ik wel een docker image maken met chrome-php en google-chrome. Wellicht helemaal een test omgeving van maken. Dus api wordt dan een json-compare (in mijn geval) en de frontend dus html documenten met elkaar vergelijken met mooie screenshots. Zit ik alleen nog te denken aan unit tests in mijn ontwikkelde taal. De plugins moeten ook getest worden en de parser. Wellicht kan ik daar ook gewoon de output van pakken.

[Janoz]

phex schreef op donderdag 14 september 2023 @ 10:27:
Maar als niet steeds bezig bent met (oude)bugs/brandjes fixen, dan heeft je team/code een hoge maturity en hoef je imho niet perse tests te schrijven.

Als je geen tests schrijft betekent dit 1 van de twee volgende dingen:

• Je test enkel handmatig
• Je test niet

IMHO spreek je in beide gevallen niet van een hoge maturity..

[phex]

Ik snap waarom je dat zegt.

Maar als je niet bezig hoeft met bugs fixen door changes, dan zie ik in dat geval niet de waarde van geautomatiseerde tests.

Wij werken met releases die uitvoerig handmatig getest worden op wijzigingen en wij ervaren amper bugs in productie.

Nogmaals mijn punt is dat er situaties kunnen zijn waar geautomatiseerde tests niet nodig zijn. Misschien zeldzaam, maar als je dat niet kan voorstellen...

[RagingPenguin]

phex schreef op donderdag 14 september 2023 @ 15:47:
Ik snap waarom je dat zegt.

Maar als je niet bezig hoeft met bugs fixen door changes, dan zie ik in dat geval niet de waarde van geautomatiseerde tests.

Wij werken met releases die uitvoerig handmatig getest worden op wijzigingen en wij ervaren amper bugs in productie.

En hoe vaak hebben die mensen al exact dezelfde test uitgevoerd om tot de conclusie te komen dat er niks verandered is? Als je toch al een testplan hebt dan is dat heel simpel te automatiseren.

Nogmaals mijn punt is dat er situaties kunnen zijn waar geautomatiseerde tests niet nodig zijn. Misschien zeldzaam, maar als je dat niet kan voorstellen...

Dat het zonder kan sure. Dat het zonder beter is, nee. Goed handmatig testen kost een hoop manuren, en blijft een hoop manuren kosten voor zolang je product bestaat. Testen automatiseren heeft een te goede ROI om het niet de juiste keuze te laten zijn.

[phex]

Omdat de wijzigingen ook vaak op UI/UX gebied zijn bij ons. Dan kun je wel heel veel tijd steken in geautomatiseerde testen, maar wat test je dan? Iig niet alles.

Misschien werken jullie voor bedrijven waar alles dicht getimmerd is.

[ Voor 18% gewijzigd door phex op 14-09-2023 15:59 ]

[ThomasG]

phex schreef op donderdag 14 september 2023 @ 15:47:
Ik snap waarom je dat zegt.

Maar als je niet bezig hoeft met bugs fixen door changes, dan zie ik in dat geval niet de waarde van geautomatiseerde tests.

Wij werken met releases die uitvoerig handmatig getest worden op wijzigingen en wij ervaren amper bugs in productie.

Nogmaals mijn punt is dat er situaties kunnen zijn waar geautomatiseerde tests niet nodig zijn. Misschien zeldzaam, maar als je dat niet kan voorstellen...

Dit is een scenario wat (hopelijk) goed gaat zolang je zo'n beetje de enige bent die aan dat project werkt.

Stel nu dat er iemand bij komt, en hij maakt een nieuwe feature. Daarvoor moet hij bestaande code wijzigingen. Hij test handmatig zijn nieuwe feature, en het werkt hartstikke fantastisch. Maar nu heeft hij een bestaande feature stuk gemaakt. Hij wist bijvoorbeeld niet dat dit daar ook invloed op had, en dus niet getest. Of hij wist überhaupt niet eens af van deze bestaande feature.

[phex]

Wij hebben een klein team, dus dat komt niet zomaar voor.

Ik snap heus wel dat in een groot team test cases onmisbaar zijn

Ik probeer het stigma aan te vechten dat je geen professionele software kan maken zonder testcases.

[ Voor 28% gewijzigd door phex op 14-09-2023 16:02 ]

[ThomasG]

phex schreef op donderdag 14 september 2023 @ 16:01:
Wij hebben een klein team, dus dat komt niet zomaar voor.

Ik snap heus wel dat in een groot team test cases onmisbaar zijn

En wat nou als je besluit een andere baan te nemen? Dan gaat alle kennis van wat er handmatig getest moet worden, en wat waar invloed op heeft, verloren. En dan is er een probleem.

[phex]

Ja dat zou inderdaad een probleem zijn als ik de enige was die alle kennis had en dat ik zelf alles moest testen.

[Caelorum]

phex schreef op donderdag 14 september 2023 @ 15:58:
Omdat de wijzigingen ook vaak op UI/UX gebied zijn bij ons. Dan kun je wel heel veel tijd steken in geautomatiseerde testen, maar wat test je dan? Iig niet alles.

Misschien werken jullie voor bedrijven waar alles dicht getimmerd is.

Ook UI en UX kan je testen. Daarnaast zijn vermoed ik 95% van je handmatige tests vrij eenvoudige te automatiseren. Hoeveel uur test je nu per week voor een release? 5 uur? Dat had dan dus ook naar 15 minuten teruggebracht kunnen worden. Maar laten we een uur nemen en dus 4 uur tijdwinst per week. Dat is dan een volle maand voor 1 FTE dat je bespaard per jaar.
En ja testen schrijven kost ook weer tijd (of nouja, hoeft niet als je het goed opzet), maar die blijven wel voor altijd bij het bedrijf. Ook als jij en je collega's in 1 auto stappen en een boom van dichtbij zien, of als jullie allemaal aan een nieuw product gaan werken en dit product afstoten aan een extern team (die dus ook per uur betaald gaan krijgen).

[wackmaniac]

Wij hebben een klein team, dus dat komt niet zomaar voor.

Ik wilde dat ik jouw zelfvertrouwen had. Ik schrijf zelfs voor mijn huisvlijtprojectjes nog (unit) tests 🤣

[PatrickH89]

phex schreef op donderdag 14 september 2023 @ 16:01:
Wij hebben een klein team, dus dat komt niet zomaar voor.

Ik snap heus wel dat in een groot team test cases onmisbaar zijn

Ik probeer het stigma aan te vechten dat je geen professionele software kan maken zonder testcases.

Je kunt best professionele software maken zonder testcases, maar ook met een klein team ben je puur tijd (en dus geld) door de wc aan het spoelen als je alleen handmatig test. Bovendien ga je altijd meer bugs en regressies ervaren dan als je goed automatische testsuites bouwt. Dat is geen stigma, maar voortschrijdend inzicht van development in het algemeen. Niet geautomatiseerd testen is een kennis probleem.

[Janoz]

phex schreef op donderdag 14 september 2023 @ 15:47:
Ik snap waarom je dat zegt.

Maar als je niet bezig hoeft met bugs fixen door changes, dan zie ik in dat geval niet de waarde van geautomatiseerde tests.

Wij werken met releases die uitvoerig handmatig getest worden op wijzigingen en wij ervaren amper bugs in productie.

Nogmaals mijn punt is dat er situaties kunnen zijn waar geautomatiseerde tests niet nodig zijn. Misschien zeldzaam, maar als je dat niet kan voorstellen...

Ah, duidelijk. Niet mature vanwege optie 2 "alleen handmatig testen"

Mensen die vinden dat geautomatiseerde tests niet nodig zijn komen bij mij net zo over als mensen die IDE's overrated vinden. Leuk om lekker mee te flexen, maar in een professionele omgeving zou ik ze er niet bij willen hebben.

En klein team is echt geen excuus. Ook bij grote organisaties wordt over het algemeen nog steeds in kleine teams gewerkt.

[Verwijderd]

PatrickH89 schreef op donderdag 14 september 2023 @ 16:24:
[...]


Je kunt best professionele software maken zonder testcases, maar ook met een klein team ben je puur tijd (en dus geld) door de wc aan het spoelen als je alleen handmatig test. Bovendien ga je altijd meer bugs en regressies ervaren dan als je goed automatische testsuites bouwt. Dat is geen stigma, maar voortschrijdend inzicht van development in het algemeen. Niet geautomatiseerd testen is een kennis probleem.

Ik denk niet dat er een verschil zit, meer bugs etc. Maar ik denk wel dat je sommige dingen kan automatiseren. Ik heb vroeger aan een draak van een software programma gewerkt, waar we met 2 a 3 man aan werkten. Tests waren handmatig en bij elke release ( op zaterdag ) werdt er flink getest. Je kopieerde dan je branch naar live en daar zat soms nog wel een bugje in. Ik moet zeggen dat elke keer 2 uur testen er soms wat er doorheen schoot. Maarja, dat had je met tests. Zo werd het gedaan en meestal was er nog wel eens een bugje die dan door de week gedaan werd. Je kan niet allesafvangen met geautomatiseerde tests idem. Wat ik wel ga testen is bijvoorbeeld via de browser of je kan inloggen/uitloggen nieuw registeren eventueel etc. Tests kunnen veel opvangen maar niet alles (zoals extra wijzigingen in de db) bij een actie. De guru moet eruit maar bugs voorkom je niet. Waar de kracht van tests liggen is, eerder werkte het wel, na de update niet meer.

Zoals ik ook al eens eerder heb aangegeven is, je kunt geen 10en blijven produceren de hele dag over de code. Wat wel kan is 6-8, en dan met hotfixes brengen tot een 9-10.

Maar ik ga wat tests schrijven maar niet tot in den treure. Moet progressie inzitten en documentatie kost al veel, maar tijdens het documenteren een paar tests schrijven wellicht...

Trouwens andere vraag, iemand idee hoe je op mobiel kan debuggen? Heb met de Samsung browser dat ie niet doorlaadt (soms) maarja geen F12 voorhanden?

[ Voor 3% gewijzigd door Verwijderd op 14-09-2023 17:12 ]

[phex]

Janoz schreef op donderdag 14 september 2023 @ 17:05:
[...]


Ah, duidelijk. Niet mature vanwege optie 2 "alleen handmatig testen"

Mensen die vinden dat geautomatiseerde tests niet nodig zijn komen bij mij net zo over als mensen die IDE's overrated vinden. Leuk om lekker mee te flexen, maar in een professionele omgeving zou ik ze er niet bij willen hebben.

En klein team is echt geen excuus. Ook bij grote organisaties wordt over het algemeen nog steeds in kleine teams gewerkt.

Schattig dat de rest van mijn reacties negeert, ik heb nergens gezegd dat ik test overrated vind. Ik zei dat het bij ons niet waardevol genoeg was.

Maar zoek vooral bevestig in je eigen wereld en probeer je totaal niet in te leven in iemand anders realiteit.

[ Voor 3% gewijzigd door phex op 14-09-2023 19:48 ]