De Devschuur Coffee Corner - Iteratie ⑬

[Lethalis]

Sebazzz schreef op woensdag 24 augustus 2022 @ 08:02:
Wij gebruiken Blazor Server, hier zijn we echt heel tevreden over Het werkt simpel, is gemakkelijk te begrijpen en echt een verademing tegenover de complexiteit van de JS SPA frameworks.

Dat hoorde ik dus ook van een ex collega van me en sindsdien ben ik erover aan het nadenken Angular is prima verder, maar als ik een bepaalde collega bij het project wil betrekken die het nog niet kent, is de leercurve best steil.

Blazor ziet er vrij simpel uit om mee te werken en daarmee krijg ik hem wel aan boord denk ik. De collega in kwestie heeft wel veel business kennis (heeft volop aan het Windows Forms pakket gewerkt), dus ik wil hem er graag bij.

Angular leren zit er waarschijnlijk niet in voor hem. Althans, het komt niet van de grond. Hij vindt het ook niks. Het idee alleen al dat hij de command line moet gebruiken voor de meest simpele handelingen staat hem tegen Hij wil gewoon Visual Studio en geen glorified text editor (vscode).

Aan de andere kant heb ik een andere collega die helemaal Angular fanaat is Maar die is vaak te druk met andere projecten, waardoor ik bang ben dat ik uiteindelijk niet veel aan hem heb.

Ik heb al een prototype in Angular, maar twijfel nu dus of ik nog een Blazor prototype ga bouwen en dan kijken hoe dat gaat.

[Sebazzz]

Ik raad je aan om te beginnen met de Clean Architecture template van Jimmy Bogard. Dat is echt een goede basis voor een Blazor project. Daarna kan je kijken welke principes je wilt toepassen op hoe je zelf projecten aanvliegt.

[Caelorum]

Lethalis schreef op woensdag 24 augustus 2022 @ 08:46:
[...]

Blazor Server werkt via de server. Het houdt een websocket (Signalr) verbinding open per browser venster. Qua schaalbaarheid is dat een nadeel, maar de kans is groot dat je met de meeste projecten nooit tegen een grens van pakweg 20.000 gelijktijdige connecties aanloopt.[...]

En dat is per server toch? Je zou dus ook meerdere instanties kunnen draaien en daarmee dat limiet verhogen?

[DevWouter]

Sebazzz schreef op woensdag 24 augustus 2022 @ 09:01:
Ik raad je aan om te beginnen met de Clean Architecture template van Jimmy Bogard. Dat is echt een goede basis voor een Blazor project. Daarna kan je kijken welke principes je wilt toepassen op hoe je zelf projecten aanvliegt.

1 probleem, de template bestaat niet. Er zijn wel een paar die door hem geïnspireerd zijn, maar die zijn niet echt “clean”.

[Lethalis]

Caelorum schreef op woensdag 24 augustus 2022 @ 09:24:
[...]
En dat is per server toch? Je zou dus ook meerdere instanties kunnen draaien en daarmee dat limiet verhogen?

Dat kan, maar geeft wel extra complexiteit omdat de state op de server staat.

Hoe dan ook, zijn beide Blazor versies een interessant alternatief voor JS frameworks. Zeker wanneer je teamleden hebt die de stap naar die JS frameworks nooit hebben gezet, maar wel .NET goed kennen.

En ik programmeer zelf ook 10x liever in C# dan in JavaScript of Typescript. Grootste nadeel van Typescript vind ik altijd dat het tijdens runtime gewoon JavaScript is. Dus je moet daar altijd rekening mee houden. Je kunt niet programmeren zoals je gewend bent (dat een instantie van X ook daadwerkelijk altijd X is... je moet er altijd op bedacht zijn dat het ook iets heel anders kan zijn).

[ Voor 4% gewijzigd door Lethalis op 24-08-2022 11:14 ]

[Mugwump]

Lethalis schreef op woensdag 24 augustus 2022 @ 11:07:
[...]

Dat kan, maar geeft wel extra complexiteit omdat de state op de server staat.

Hoe dan ook, zijn beide Blazor versies een interessant alternatief voor JS frameworks. Zeker wanneer je teamleden hebt die de stap naar die JS frameworks nooit hebben gezet, maar wel .NET goed kennen.

En ik programmeer zelf ook 10x liever in C# dan in JavaScript of Typescript. Grootste nadeel van Typescript vind ik altijd dat het tijdens runtime gewoon JavaScript is. Dus je moet daar altijd rekening mee houden. Je kunt niet programmeren zoals je gewend bent (dat een instantie van X ook daadwerkelijk altijd X is).

Nou ken ik Blazor niet echt, maar is feitelijk niet alles wat in de browser interactief gebeurt simpelweg Javascript tijdens de runtime?
Er is wel WASM, maar dat is niet bedoeld als drop-in replacement voor Javascript voor zover ik weet.

[Lethalis]

Mugwump schreef op woensdag 24 augustus 2022 @ 11:15:
[...]


Nou ken ik Blazor niet echt, maar is feitelijk niet alles wat in de browser interactief gebeurt simpelweg Javascript tijdens de runtime?
Er is wel WASM, maar dat is niet bedoeld als drop-in replacement voor Javascript voor zover ik weet.

Blazor WebAssembly compileert naar WASM

Er zit wel een JavaScript laagje tussen om met de DOM te communiceren.

[RobertMe]

Lethalis schreef op woensdag 24 augustus 2022 @ 11:07:
Dus je moet daar altijd rekening mee houden. Je kunt niet programmeren zoals je gewend bent (dat een instantie van X ook daadwerkelijk altijd X is... je moet er altijd op bedacht zijn dat het ook iets heel anders kan zijn).

Maar dat kan niet als je alles in Typescript doet? Want die bevat volgens mij ook type safe DOM stuff. Dus als de enige interactie met de DOM is, je alleen maar Tupescript code gebruikt etc, dan kun je niet ineens een Y i.p.v. een X krijgen.

En daarnaast bevat C# en elke andere taal natuurlijk datzelfde probleem. Als twee zaken (/libraries) met elkaar communiceren maar een can beide de ABI breekt dan ontploft de boel net zo hard at runtime. Als je een C# library gebruikt met een methode die een parameter van type X verwacht, maar vervolgens update je zonder controleren de dependency file en deployed dat dan kan het ook zomaar zijn dat die methode geen X meer verwacht maar een Y.
En ja, met compileren valt dat natuurlijk op en krijg je vooraf een error. Maar als je alleen maar Typescript gebruikt en vooraf netjes compileert dan kan er @runtime ook niks onverwachts gebeuren. Waarbij een Typescript (of front-end framework?) bv JavaScript events ook definieert als specifieke interfaces sat netjes volledig typed is. En met bv een JSX heb je dan ook een volledige type safe abstractie van de DOM.

[DevWouter]

@Lethalis Ik blijf het vooral verbazingwekkend vinden dat mensen een webapplicatie ontwikkelen, maar niet bereid zijn om het ecosysteem te begrijpen. En remote renderen is leuk tot dat je interactief bezig gaat zijn. Dan wil je dat bepaalde zaken door de client afgehandeld wordt en kom je alsnog uit bij JavaScript.

Verder inderdaad wat RobertMe in "De Devschuur Coffee Corner - Iteratie ⑬" aangeeft, uiteindelijk kan elke taal stuk als je het verkeerd gebruikt.

Blazor is oplossing voor een probleem met je team.

[RagingPenguin]

Lethalis schreef op woensdag 24 augustus 2022 @ 11:07:
[...]

En ik programmeer zelf ook 10x liever in C# dan in JavaScript of Typescript. Grootste nadeel van Typescript vind ik altijd dat het tijdens runtime gewoon JavaScript is. Dus je moet daar altijd rekening mee houden. Je kunt niet programmeren zoals je gewend bent (dat een instantie van X ook daadwerkelijk altijd X is... je moet er altijd op bedacht zijn dat het ook iets heel anders kan zijn).

Tja, als TypeScript developer vergeet ik altijd minstens 3 keer dat in C# van alles null kan zijn.

[RayNbow]

DevWouter schreef op woensdag 24 augustus 2022 @ 11:57:
Blazor is oplossing voor een probleem met je team.

Blazor is meer dan een oplossing voor mensen die geen JS kennen. Het is best handig om een webapplicatie te kunnen maken waarbij je reeds bestaande code kunt hergebruiken zonder dat je alles naar JS moet porten.

[RobertMe]

RagingPenguin schreef op woensdag 24 augustus 2022 @ 12:04:
[...]


Tja, als TypeScript developer vergeet ik altijd minstens 3 keer dat in C# van alles null kan zijn.

Als PHP developer vind ik het maar raar dat je expliciet null toe moet staan. Maarja, intussen heb ik ook wat in Kotlin gedaan, die hetzelfde werkt en ook niet compiled als je een null check mist. En daarnaast nu een beetje in Java bezig, en heb ik ook al een zoektocht gedaan hoe ik in Java iets van null safety zou kunnen forceren. Maar dat (b)lijkt toch nog een beetje onmogelijk te zijn. Met standaarden die nooit een standaard geworden zijn (JSR 305?). De enige implementatie afkomstig is van de voorsteller voor de standaard, die weer onderdeel is van "FindBugs", wat weer geforked is omdat die persoon niet meer reageerde. Vervolgens nog wat potentieel licensing gedoe erbij om de hoek komt kijken (Oracle staat het gebruik van java, sun, en afgeleiden niet toe in bv package namen, tenzij... het bv een officiële standaard implementeert, maar JSR 305 is dat dus niet, maar gebruikt wel javax). Dus dat heb ik maar weer even op een zijspoor gezet.
/rant

[.oisyn]

RobertMe schreef op woensdag 24 augustus 2022 @ 12:18:
[...]

Als PHP developer vind ik het maar raar dat je expliciet null toe moet staan.

Is dat nieuw? Fijn dat ze eindelijk eens een goede weg zijn ingeslagen.

[Mugwump]

RobertMe schreef op woensdag 24 augustus 2022 @ 12:18:
[...]

Als PHP developer vind ik het maar raar dat je expliciet null toe moet staan. Maarja, intussen heb ik ook wat in Kotlin gedaan, die hetzelfde werkt en ook niet compiled als je een null check mist. En daarnaast nu een beetje in Java bezig, en heb ik ook al een zoektocht gedaan hoe ik in Java iets van null safety zou kunnen forceren. Maar dat (b)lijkt toch nog een beetje onmogelijk te zijn. Met standaarden die nooit een standaard geworden zijn (JSR 305?). De enige implementatie afkomstig is van de voorsteller voor de standaard, die weer onderdeel is van "FindBugs", wat weer geforked is omdat die persoon niet meer reageerde. Vervolgens nog wat potentieel licensing gedoe erbij om de hoek komt kijken (Oracle staat het gebruik van java, sun, en afgeleiden niet toe in bv package namen, tenzij... het bv een officiële standaard implementeert, maar JSR 305 is dat dus niet, maar gebruikt wel javax). Dus dat heb ik maar weer even op een zijspoor gezet.
/rant

Java is extreem conservatief en zal iets als non-nullable types niet snel implementeren. Er zijn inmiddels wel Optionals sinds Java 8. Niet helemaal hetzelfde, maar je kunt methodes die potentieel null returnen dan wel bijvoorbeeld een Optional<String> laten returnen. Waar je zo'n methode dan aanroept weet je dat je rekening moet houden met het feit dat de waarde afwezig is (al kan elke idioot nog steeds gewoon blind optional.get() doen zonder enige afhandeling van de 'empty' situatie natuurlijk ).

[RobertMe]

RayNbow schreef op woensdag 24 augustus 2022 @ 12:13:
[...]

Blazor is meer dan een oplossing voor mensen die geen JS kennen. Het is best handig om een webapplicatie te kunnen maken waarbij je reeds bestaande code kunt hergebruiken zonder dat je alles naar JS moet porten.

En wat is er dan mis met een traditionele web applicatie i.p.v. een SPA? Als je niet de kennis hebt voor frontend stuff moet je je daar ook niet mee bezig houden, of de mensen die die kennis wel hebben inhuren/aannemen.
In die zin kan ik mij dan ook wel vinden in de reactie van @DevWouter. Als de C#ers / backenders geen "frontend kennen" dan ligt de oplossing niet in een frontend oplossing die het frontend naar het backend haalt.

Zeker die server side oplossing vind ik nogal heel hard klinken als ASP NET WebForms. Want dat was ook zo'n enorm succes... Waarbij elke button click volledig via de server ging en je zelfs geen ouderwetse <a/> tag fatsoenlijk kon gebruiken. Om nog maar te zwijgen over dat toen de volledige pagina één groot formulier was met een hidden input field met de volledige state / session...

En terug naar Blazor en gebrek aan kennis. Hoe ga je san problemen met (het gebruik van) Blazor oplossen? Je gebruikt dan een niche product om een kennis probleem op te lossen. Maar wie heeft dan de kennis om problemen met Blazor op te lossen? Dat zal dan ook "niemand" zijn, of @Lethalis omdat hij wel de interesses heeft om zijn kennis te verbreden. Maar dan ligt de bal dus bij dezelfde persoon als die ook al de "normale" (/"niet niche") oplossingen kent. Dus ben je weer terug bij af.

[RobertMe]

.oisyn schreef op woensdag 24 augustus 2022 @ 12:24:
[...]

Is dat nieuw? Fijn dat ze eindelijk eens een goede weg zijn ingeslagen.

Al sinds parameter type hints er in zitten, en dat is al van ergens vooraan in de 7 serie, als zelfs niet al in se laatste 5. Toentertijd kon je null ook alleen toestaan door de param een default value van null te geven (dus een, potentieel ongewenst, side effect erbij). Later, waarschijnlijk sinds je class members kunt typen, of return types zijn toegevoegd, kun (/moet) je in alle gevallen null toestaan met ?Type

[RobertMe]

Mugwump schreef op woensdag 24 augustus 2022 @ 12:25:
[...]


Java is extreem conservatief en zal iets als non-nullable types niet snel implementeren. Er zijn inmiddels wel Optionals sinds Java 8. Niet helemaal hetzelfde, maar je kunt methodes die potentieel null returnen dan wel bijvoorbeeld een Optional<String> laten returnen. Waar je zo'n methode dan aanroept weet je dat je rekening moet houden met het feit dat de waarde afwezig is (al kan elke idioot nog steeds gewoon blind optional.get() doen zonder enige afhandeling van de 'empty' situatie natuurlijk ).

True, maar dat doet niks aan je onverwacht null als parameter kunt ontvangen. En een method die geen optional returned kan nog steeds onverwacht null returnen.

[RagingPenguin]

DevWouter schreef op woensdag 24 augustus 2022 @ 11:57:
@Lethalis Ik blijf het vooral verbazingwekkend vinden dat mensen een webapplicatie ontwikkelen, maar niet bereid zijn om het ecosysteem te begrijpen. En remote renderen is leuk tot dat je interactief bezig gaat zijn. Dan wil je dat bepaalde zaken door de client afgehandeld wordt en kom je alsnog uit bij JavaScript.

Verder inderdaad wat RobertMe in "De Devschuur Coffee Corner - Iteratie ⑬" aangeeft, uiteindelijk kan elke taal stuk als je het verkeerd gebruikt.

Blazor is oplossing voor een probleem met je team.

Exact dit, en het hele concept van 'web applicatie in taal X' is ook niets nieuws. Toen Ruby populair was deden mensen dit met Ruby, toen alles Java was deden mensen dit met Java, etc. Geen van alle zijn ooit echt aangeslagen, niet omdat je er geen goede websites mee kan maken, maar omdat developers die goede websites kunnen maken frontend development snappen en dit soort dingen totaal niet nodig hebben. Het is niet dat dingen als Blazor slecht zijn, maar ze lossen het verkeerde probleem op.

[Lethalis]

DevWouter schreef op woensdag 24 augustus 2022 @ 11:57:
@Lethalis Ik blijf het vooral verbazingwekkend vinden dat mensen een webapplicatie ontwikkelen, maar niet bereid zijn om het ecosysteem te begrijpen.

Dat is een hele discussie op zich. Ik heb ook tegen mezelf moeten vechten om Angular echt te leren. Omslachtig dat ik het allemaal vond.

Maar het went en naarmate een project complexer wordt, begin je de voordelen te zien. En ik heb ook ergens nog het besef van "dit is nu gevraagd in de markt, dus ik kan het maar beter leren".

Niet iedereen heeft dat of ziet de noodzaak daartoe.

[DevWouter]

RayNbow schreef op woensdag 24 augustus 2022 @ 12:13:
[...]

Blazor is meer dan een oplossing voor mensen die geen JS kennen. Het is best handig om een webapplicatie te kunnen maken waarbij je reeds bestaande code kunt hergebruiken zonder dat je alles naar JS moet porten.

Ook in JS kan je code herbruiken. Sterker, ik vind (de laatste) module systeem in JS/TS beter dan dat van C#.

@RobertMe Het probleem met ASP State was dat je op een gegeven moment telkens megabytes aan het uploaden was, soms bij het alleen bewegen van de muis. En ik ken zelfs gevallen waarbij de state dusdanig groot was dat er een HTTP timeout ken. Dat is bij Blazor niet het geval, daar ontvang je de deltas van de state en niet de complete state.

[Lethalis]

RagingPenguin schreef op woensdag 24 augustus 2022 @ 12:04:
[...]
Tja, als TypeScript developer vergeet ik altijd minstens 3 keer dat in C# van alles null kan zijn.

Dat is tegenwoordig anders Al zet ik het zelf nog wel regelmatig uit, omdat ik de oude manier zo verschrikkelijk gewend ben en daarnaast ook nog aan legacy projecten werk.

Dus dan is het steeds omdenken tussen C# "oud" en "nieuw".

[DevWouter]

RagingPenguin schreef op woensdag 24 augustus 2022 @ 12:36:
[...]


Exact dit, en het hele concept van 'web applicatie in taal X' is ook niets nieuws. Toen Ruby populair was deden mensen dit met Ruby, toen alles Java was deden mensen dit met Java, etc. Geen van alle zijn ooit echt aangeslagen, niet omdat je er geen goede websites mee kan maken, maar omdat developers die goede websites kunnen maken frontend development snappen en dit soort dingen totaal niet nodig hebben. Het is niet dat dingen als Blazor slecht zijn, maar ze lossen het verkeerde probleem op.

Er zijn echt heel veel goeie sites gemaakt met Java en RubyOnRails.
En veel van de ASP.NET bestond vaak al in RubyOnRails.

Het probleem zoals ik het zie is eerder dat veel mensen denken "oh technologie X wordt door Y gebruikt dus dan moeten wij het ook gebruiken". Met als gevolg dat mensen een heel hoop cargocult introduceren zoals dat een typescript web-server trager is dan C# (nee, dat is het niet) of dat javascript extreem veel trager is voor rekenkundige taken (dat is echt overdreven en in mijn tests moest ik echt zoeken naar een bepaalde schaal om in C++ implementatie te verantwoorden).

[DevWouter]

Lethalis schreef op woensdag 24 augustus 2022 @ 12:43:
[...]

Dat is een hele discussie op zich. Ik heb ook tegen mezelf moeten vechten om Angular echt te leren. Omslachtig dat ik het allemaal vond.

Maar het went en naarmate een project complexer wordt, begin je de voordelen te zien. En ik heb ook ergens nog het besef van "dit is nu gevraagd in de markt, dus ik kan het maar beter leren".

Niet iedereen heeft dat of ziet de noodzaak daartoe.

Als iemand die een behoorlijke expert is op Angular gebied kan ik ook zeggen dat Angular een zeer onvriendelijke taal is. Het won vooral populariteit vanwege de template generators in de ng tool. Pas wanneer je goeie strategieën hebt ontwikkeld dan wordt Angular pas fijn. Tot die tijd is het gokken of je het juist doet.
Het helpt ook niet dat 90% van het advies online gewoon compleet fout is, zelfs toen het niet achterhaald was.

Verder ben ik een mafklapper die zo'n beetje bekend is met elke technologie en het meestal meerdere jaren gebruikt heeft. Dus als er iets nieuws komt dan ken ik de meeste concepten al

[CodeCaster]

DevWouter schreef op woensdag 24 augustus 2022 @ 11:57:
@Lethalis Ik blijf het vooral verbazingwekkend vinden dat mensen een webapplicatie ontwikkelen, maar niet bereid zijn om het ecosysteem te begrijpen. En remote renderen is leuk tot dat je interactief bezig gaat zijn. Dan wil je dat bepaalde zaken door de client afgehandeld wordt en kom je alsnog uit bij JavaScript.

Verder inderdaad wat RobertMe in "De Devschuur Coffee Corner - Iteratie ⑬" aangeeft, uiteindelijk kan elke taal stuk als je het verkeerd gebruikt.

Blazor is oplossing voor een probleem met je team.

Mwah. Abstracties kunnen je productiever laten zijn, en als het "goed genoeg" is voor het opzetten van een SPA met basically een serverside-taal waarbij de rest (inclusief IPC) voor je wordt geregeld, waarom niet?

ASP.NET WebForms werd ook al even aangehaald. AJAX-panels, grids die clientside verversen, modals, het was twaalf jaar geleden z'n tijd vooruit in vergelijking met de gemiddelde hand-coded site.

Natuurlijk had het enorme nadelen, en die werden vooral getriggerd door Win32/WinForms-developers die dankzij de UI-control-toolbox volledig konden negeren wat HTTP, HTML en JS waren.

Ik geloof ook niet dat de gemiddelde front-ender het verschil snapt tussen de capaciteiten van een smartphone, een tablet en een desktop met toetsenbord en muis, maar ze knallen gewoon alles in één grid van 16 ... dingen breed, en laten willekeurige dingen wegvallen wanneer het scherm te smal wordt. "Is this responsive design?", en vervolgens gebruiken ze zevenduizend libraries om een soort van functionerende applicatie te bouwen.

En bij iedere andere back-end moet het volledige wiel van API's aanroepen weer van spaak tot binnenband helemaal opnieuw uitgevonden worden, hoewel het genereren van OpenAPI-clients einde-fucking-lijk een beetje gemeengoed aan het worden lijkt te zijn.

[ Voor 4% gewijzigd door CodeCaster op 24-08-2022 13:07 ]

[Sandor_Clegane]

DevWouter schreef op woensdag 24 augustus 2022 @ 11:57:
@Lethalis Ik blijf het vooral verbazingwekkend vinden dat mensen een webapplicatie ontwikkelen, maar niet bereid zijn om het ecosysteem te begrijpen. En remote renderen is leuk tot dat je interactief bezig gaat zijn. Dan wil je dat bepaalde zaken door de client afgehandeld wordt en kom je alsnog uit bij JavaScript.

Verder inderdaad wat RobertMe in "De Devschuur Coffee Corner - Iteratie ⑬" aangeeft, uiteindelijk kan elke taal stuk als je het verkeerd gebruikt.

Blazor is oplossing voor een probleem met je team.

Waarom? Ik heb een schurfthekel aan Javascript, ik snap wel hoe het werkt en ik kan me er ook wel mee redden, maar dat ik het nu leuk vind om te programmeren? niet echt.

Ik wil wel eens een website of SPA schrijven dus gebruik ik Fable. Kan ik gewoon lekker F# schrijven en hij transpiled het wel naar Js/React. De F# compiler is zo goed dat ik op een hand kan tellen wanneer ik een undefined heb gehad of andere runtime exceptions.

Elmish is een intuïtieve manier om over applicaties na te denken (MVU) en dat vind ik een stuk eleganter dan andere JS frameworks die ik heb gezien. Er zullen nu vast JS frameworks zijn die het ook implementeren, zo werkt dat.

Om heel eerlijk te zijn vind ik het hele JS ecosysteem een wir war. Ik hoef geen duizenden dingen, ik wil gewoon een paar die goed zijn en dat het te overzien is.

[Lethalis]

RobertMe schreef op woensdag 24 augustus 2022 @ 11:53:
[...]
Maar dat kan niet als je alles in Typescript doet? Want die bevat volgens mij ook type safe DOM stuff. Dus als de enige interactie met de DOM is, je alleen maar Tupescript code gebruikt etc, dan kun je niet ineens een Y i.p.v. een X krijgen.

Typesafe DOM typings zijn er uiteraard en gebruik ik ook. Maar je kunt het altijd casten naar een type dat nergens op slaat en het gaat in eerste instantie verder alsof zijn neus bloedt.

Fouten opsporen is wat dat betreft lastiger dan in een runtime die dat er meteen voor jou uitvist door de cast niet eens toe te laten.

Ik ben wel blij dat Angular sinds versie 9 (dacht ik) strict typechecking voor zijn templates heeft. Dat scheelt voor mij al een hoop ellende. Zeker wanneer je aan het refactoren bent.

[RobertMe]

Lethalis schreef op woensdag 24 augustus 2022 @ 13:13:
[...]

Typesafe DOM typings zijn er uiteraard en gebruik ik ook. Maar je kunt het altijd casten naar een type dat nergens op slaat en het gaat in eerste instantie verder alsof zijn neus bloedt.

En hoe is dat anders dan in C# alles naar een object heen en weer casten? En een object kun ke volgens mij ook naar alles upcasten. En ook dan crasht die pas @runtime (tenzij je een as doet, die maakt er een null van meen ik?)

[RobertMe]

Sandor_Clegane schreef op woensdag 24 augustus 2022 @ 13:09:
[...]

Waarom? Ik heb een schurfthekel aan Javascript, ik snap wel hoe het werkt en ik kan me er ook wel mee redden, maar dat ik het nu leuk vind om te programmeren? niet echt.

Punt van @DevWouter is lijkt mij eerder gerelateerd aan "werk". Verwacht jouw werkgever dat je, zoals mijne het zou noemen "hippe shit", aan front-end gebeuren bouwt? Of ben je een backend developer die daar ook voor betaald krijgt en de andere zaken niet hoeft te kennen / doen.

Zelf ben ik backender, maar heb overal wel interesses in en een keertje frontend boeit mij ook niet (de frontend collega(s) kon ik ook vaak genoeg corrigeren of aanvullen). Maar van mijn mede backend collega's verwacht ik niet dat zij zich ineens met het frontene bezig gaan houden. En al helemaal niet met SPAs en aanverwante zaken.

[.oisyn]

RobertMe schreef op woensdag 24 augustus 2022 @ 12:29:
[...]

Al sinds parameter type hints er in zitten

Ah, alsnog optioneel dus . En zo te zien pas vanaf 8 bij class members.

Later, waarschijnlijk sinds je class members kunt typen, of return types zijn toegevoegd, kun (/moet) je in alle gevallen null toestaan met ?Type

Fijn toch?

[RobertMe]

.oisyn schreef op woensdag 24 augustus 2022 @ 13:24:
[...]

Ah, alsnog optioneel dus . En zo te zien pas vanaf 8 bij class members.


[...]

Fijn toch?

Ja ok. Als je typehints gebruikt dan kun je btmy default dus geen null gebruiken, maar moet je ? toepassen. Maar typehints an zich zijn geen verplichting.

En als het pas in 8 zit. Wel gek dat ik het dan in 7.4 toepas .

[Lethalis]

DevWouter schreef op woensdag 24 augustus 2022 @ 13:00:
[...]
Verder ben ik een mafklapper die zo'n beetje bekend is met elke technologie en het meestal meerdere jaren gebruikt heeft. Dus als er iets nieuws komt dan ken ik de meeste concepten al

Ik heb een gezin. Ik ben tegenwoordig al blij als het mij lukt om de belangrijkste ontwikkelingen te volgen.

Dat ik nog niks met Blazor heb gedaan, komt omdat ik mij op Angular heb gestort een hele tijd terug. Ik pak meestal 1 onderwerp en leer dat. En pas als ik op een redelijk niveau daarmee zit, ga ik verder met het volgende.

Ik word wel een beetje zenuwachtig van het woordje "DevOps" in vacatures. Dat lijkt me een heel onderwerp an sich, maar staat steeds vaker bij gewone developer vacatures. Het is nogal een breed onderwerp waar je alle kanten mee op kunt volgens mij.

Geen idee waar je dan moet beginnen. Tuurlijk, ik kan eens duiken in een tool als Jenkins, builds automatisch laten doen, en deployen door puur naar een bepaalde git branch te pushen. Allemaal leuk en aardig, maar waarom is dat mijn verantwoordelijkheid? Bezuinigd op de systeembeheerder / DevOps engineer?

Ach ja.

[.oisyn]

RobertMe schreef op woensdag 24 augustus 2022 @ 13:26:
[...]

Ja ok. Als je typehints gebruikt dan kun je btmy default dus geen null gebruiken, maar moet je ? toepassen.

Maar wat is je probleem daar dan mee?

En als het pas in 8 zit. Wel gek dat ik het dan in 7.4 toepas .

Ah ja, had net de docs gelezen maar was blijkbaar in de war met mixed

[Lethalis]

RobertMe schreef op woensdag 24 augustus 2022 @ 13:22:
[...]

Punt van @DevWouter is lijkt mij eerder gerelateerd aan "werk". Verwacht jouw werkgever dat je, zoals mijne het zou noemen "hippe shit", aan front-end gebeuren bouwt? Of ben je een backend developer die daar ook voor betaald krijgt en de andere zaken niet hoeft te kennen / doen.

Zelf ben ik backender, maar heb overal wel interesses in en een keertje frontend boeit mij ook niet (de frontend collega(s) kon ik ook vaak genoeg corrigeren of aanvullen). Maar van mijn mede backend collega's verwacht ik niet dat zij zich ineens met het frontene bezig gaan houden. En al helemaal niet met SPAs en aanverwante zaken.

Ik werk voor een klein bedrijf waar je in principe geacht wordt om van alles te kunnen. Maar niemand kan overal goed in zijn.

Dus als de vraag vanuit de klant wijst naar "ik wil een webapplicatie" dan bouwen we dat. Maar ja, iedereen heeft een andere achtergrond en dan moet je nou eenmaal schipperen.

Ik kan ook zeggen "Angular is veel handiger voor dit project, succes ermee" maar als ik daarmee een collega afschrik die ik eigenlijk wel nodig heb, dan breng ik het hele project in gevaar.

Daarmee wil ik overigens niet zeggen dat Blazor de oplossing is. Ik heb tot nu toe alleen presentaties erover gekeken, misschien is mijn conclusie straks alsnog dat ik bij Angular blijf.

Maar ervoor openstaan dat de keuze van een tool ook van de bestaande kennis in een team afhangt, is denk ik geen verkeerde insteek.

[F.West98]

RobertMe schreef op woensdag 24 augustus 2022 @ 13:18:
[...]

En hoe is dat anders dan in C# alles naar een object heen en weer casten? En een object kun ke volgens mij ook naar alles upcasten. En ook dan crasht die pas @runtime (tenzij je een as doet, die maakt er een null van meen ik?)

Nou ja zou je zeggen dus, maar ik heb met TS toch ook vaak genoeg runtime vage meuk gehad. Is al weer een tijdje geleden, maar van wat ik me herinner: alle TS tools zeggen dat iets een Foo is, de volledige class, maar in runtime klapt het dan toch omdat het gewoon een anonymous object bleek te zijn puur met de velden van Foo maar zonder de functies en weet ik het. (ja, dat bleek mijn fout natuurlijk)

Bottom line is dat je in C# en Java etc ook in runtime garantie hebt dat een variabele van type Foo daadwerkelijk die type heeft en niets anders. (zijn vast uitzonderingen voor te bedenken) In TS heb je die garantie niet. Het feit dat je een string en geen Foo krijgt in runtuime is natuurlijk een bug of slordigheid of slecht design, sure, maar in C# breekt het dan bij de source en in TS breekt het bij de usage. Dat maakt het enorm lastig te debuggen.

Zie ook deze twee voorbeelden:
C# - Breekt bij de assignment van z
TS - Breekt bij de usage van z

[RobertMe]

.oisyn schreef op woensdag 24 augustus 2022 @ 13:33:
[...]

Maar wat is je probleem daar dan mee?

Helemaal niks, achteraf. Maar als je alweer een paar jaartjes zit te PHPen (vanaf C#) en dan ineens met type hints gaat strooien dan en je de errors om de oren vliegen dan zit je wel even te vloeken.

En als je een typehint toepast op een field/property krijg je ook bij lezen een leuke uninitialized error als je probeert te lezen voor assignment. Dus je bent daarmee ook verplicht om de boel te initialiseren. Wat ook wel even wennen is als je een default van null gewend was (note: ook als je een nullable typehint gebruikt moet je alsnog null expliciet toekennen als je die als "default" wilt hebben. Onderwater hebben ze een ding "uninitialized" toegevoegd, en fields zijn by default uninitialized en een typed field lezen waarbij de "waarde" "uninitialized" is geeft een error).

Overigens werkt het bij Kotlin net zo. Een var & val moet je in de constructor (/init block) een waarde geven, anders compiled het niet. Alleen een "lateinit var" hoef je geen waarde te geven. Maar dan moet je dus wel zelf zorg er voor dragen dat er als je gaat lezen wel een waarde in zit (als je bv autowiring gebruikt en het framework de private fields via reflection vult is dit een vereiste. Je kunt dan zelf geen assignment doen dus compileert het niet met "var". Met "lateinit var" compuleert het wel en tegen de tijd dat je het field gaat gebruiken heeft het dependency injection framework al lang een assignment gedaan).

[RobertMe]

F.West98 schreef op woensdag 24 augustus 2022 @ 13:45:
Zie ook deze twee voorbeelden:
C# - Breekt bij de assignment van z
TS - Breekt bij de usage van z

Maar het gaat natuurlijk al mis bij het gebruik van dynamic & any Een beetje linter staat het gebruik van any überhaupt niet toe.

[F.West98]

RobertMe schreef op woensdag 24 augustus 2022 @ 13:48:
[...]

Maar het gaat natuurlijk al mis bij het gebruik van dynamic & any Een beetje linter staat het gebruik van any überhaupt niet toe.

Dat was ter illustratie Natuurlijk gaan dat soort dingen ergens fout, maar mijn punt was dat de source van die fout lastiger te achterhalen is. Als je in de API parsing ergens iets kapot maakt en iets verkeerds returnt krijg je niet daar de Error; maar pas 10 kilometer verderop wanneer die response in een data model zit en je na een user event een functie aanroept ofzo.

[RobertMe]

Lethalis schreef op woensdag 24 augustus 2022 @ 13:38:
[...]

Ik werk voor een klein bedrijf waar je in principe geacht wordt om van alles te kunnen. Maar niemand kan overal goed in zijn.

Maar je werkt dan bij een bedrijfje dat maatwerk doet? Klinkt mij persoonlijk dan raar in de oren dat jullie opdrachten aannemen waar jullie de kennis niet voor hebben. Dan moet er dus of een degelijke frontender komen of die opdracht niet aangenomen worden.
Ik persoonlijk zou in ieder geval liever dan alleen een opdracht durven aan te nemen als ik weet dat ik die succesvol kan afronden binnen budget. En niet een opdracht aannemen waarbij ik weet dat de uitvoerders het niet kunnen.
En als ik naar een aannemer ga en ik vraag die om een onmogelijk huis te bouwen hoor ik ook liever "dat gaat niet" of "dat kan ik niet en moet je bij X zijn" dan dat ik een huis koop dat op instorten staat.

Overigens werk ik zelf bij een bedrijf dat je het best kunt omschrijven als "wij ontwikkelen een SaaS", met een stuk of 5 a 10 programmeurs naast nog andere categoriën medewerkers zoals content ontwikkelaars etc, waaronder ook maar 1 frontender, nu 2 app developers (via nearshoaring) en de rest backend. En ik verwacht wel dat de backenders wat aanpassingen in de HTML kunnen doen (note: oude webapplicatie, dus geen fancy SPA stuff. Maar gewoon ouderwetse linkjes met requests naar de server die een nieuwe pagina retourneert). Maar ik verwacht niet dat zij ineens SPA achtige stuff gaan bouwen (frontender is wel wat Vue componentjes aan het opzetten).

[F.West98]

RobertMe schreef op woensdag 24 augustus 2022 @ 13:48:
[...]

Maar het gaat natuurlijk al mis bij het gebruik van dynamic & any Een beetje linter staat het gebruik van any überhaupt niet toe.

Waar het in mijn oorspronkelijke code destijds mis ging is volgens mij iets als dit:
https://www.typescriptlan...-HyW1vC29o6JLtYE7p7evqpAA

De linter en type checker vinden dit allemaal prima, maar als je ergens een inheritance structure hebt en je dus type checking gaat doen valt het ineens uit elkaar. Kijk nu weet ik wel dat je niet op deze manier een class kan constructen, maar vanuit een C# achtergrond is dit niet eens zo gek om te verwachten zegmaar

En laat ik extra duidelijk zijn: natuurlijk is dit programmer error maar het is echt heel lastig te debuggen aangezien het ver ver ver down the line fout gaat en niet bij de assignment.

[ Voor 9% gewijzigd door F.West98 op 24-08-2022 14:05 ]

[Mugwump]

RobertMe schreef op woensdag 24 augustus 2022 @ 12:31:
[...]

True, maar dat doet niks aan je onverwacht null als parameter kunt ontvangen. En een method die geen optional returned kan nog steeds onverwacht null returnen.

Klopt, al is het bij ons eigenlijk standaard wel best practice om in ieder geval bij externe entrypoints een Optional.ofNullable(..) en vervolgesn ifpresent / map te doen.
Maar afgezien van libraries die worden gebruikt in andere projection geldt vaak toch dat je externe entrypoints hebt (databases, command-line-, http calls, whatever) waarbij je geen controle hebt over wat er je systeem inkomt.

[RayNbow]

DevWouter schreef op woensdag 24 augustus 2022 @ 12:48:
[...]

Ook in JS kan je code herbruiken.

Kan ik reeds bestaande C#-code in JS hergebruiken dan?

RobertMe schreef op woensdag 24 augustus 2022 @ 12:26:
[...]

En wat is er dan mis met een traditionele web applicatie i.p.v. een SPA?

Ik doe daar geen uitspraak over. Ik geef alleen aan dat Blazor handig kan zijn als je al een C#-codebase hebt.

[Caelorum]

RobertMe schreef op woensdag 24 augustus 2022 @ 13:56:
[...]

Maar je werkt dan bij een bedrijfje dat maatwerk doet? Klinkt mij persoonlijk dan raar in de oren dat jullie opdrachten aannemen waar jullie de kennis niet voor hebben. Dan moet er dus of een degelijke frontender komen of die opdracht niet aangenomen worden.
Ik persoonlijk zou in ieder geval liever dan alleen een opdracht durven aan te nemen als ik weet dat ik die succesvol kan afronden binnen budget. En niet een opdracht aannemen waarbij ik weet dat de uitvoerders het niet kunnen.[...]

Niet alle maatwerk is fixed-price he. Veelal gebeurt ook gewoon uurtje-factuurtje en dan kan je dat best doen.

[hackerhater]

.oisyn schreef op woensdag 24 augustus 2022 @ 13:24:
[...]

Ah, alsnog optioneel dus . En zo te zien pas vanaf 8 bij class members.

Fijn toch?

Klopt, inderdaad optioneel of je het gebruikt in de code (wordt wel ten zeerste aangeraden)
Maar als de functies ze gebruiken kan je daar niks anders in gooien. Dan krijg je een harde runtime-error naar je hoofd.

In het algemeen kan je er tegenwoordig vanuit gaan dat moderne PHP-code strict typing op de parameters & return types heeft.

[RobertMe]

hackerhater schreef op woensdag 24 augustus 2022 @ 14:30:
[...]


Klopt, inderdaad optioneel of je het gebruikt in de code (wordt wel ten zeerste aangeraden)
Maar als de functies ze gebruiken kan je daar niks anders in gooien. Dan krijg je een harde runtime-error naar je hoofd.

Tenzij scalar type hints en strict types uit staat Als strict types uit staat (standaard, en ook lang niet alle libraries / frameworks passen het toe) en een param moet een string zijn en je geeft int 10 op wordt er automatisch een string van gemaakt. En als ee typehint een int is en je geeft string "10" op wordt er ook automatisch een int van gemaakt. En de cases met enmen int cast op string "10 appels en 5 peren" (dat dan 10 is) is ook nogal vaagjes, waarschijnlijken willen ze volgens mij ook gaan veranderen (naar een error / warning).

Caelorum schreef op woensdag 24 augustus 2022 @ 14:13:
[...]

Niet alle maatwerk is fixed-price he. Veelal gebeurt ook gewoon uurtje-factuurtje en dan kan je dat best doen.

Ah, de klant laten betalen voor de onkunde van de eigen mensen Ook dat probeerde ik uit te drukken in die post. Niet alleen de kosten kwestie maar ook gewoon een fatsoenlijk product leveren en niet "op hoop van zegen iets in elkaar draaien zonder echte kennis er van".

[Caelorum]

RobertMe schreef op woensdag 24 augustus 2022 @ 14:54:
[...]
Ah, de klant laten betalen voor de onkunde van de eigen mensen Ook dat probeerde ik uit te drukken in die post. Niet alleen de kosten kwestie maar ook gewoon een fatsoenlijk product leveren en niet "op hoop van zegen iets in elkaar draaien zonder echte kennis er van".

Ik zou het zelf ook niet doen, maar heb het jaren zien gebeuren, dus het kan wel.

[sig69]

Wij zijn een echte .Net toko dus Blazor Server ziet er voor ons eigenlijk wel interessant uit moet ik zeggen. Misschien volgende (kleine) projectje daar maar eens mee optuigen.

[DevWouter]

Sandor_Clegane schreef op woensdag 24 augustus 2022 @ 13:09:
[...]

Waarom? Ik heb een schurfthekel aan Javascript, ik snap wel hoe het werkt en ik kan me er ook wel mee redden, maar dat ik het nu leuk vind om te programmeren? niet echt.

Dat klinkt niet als een probleem van de taal

Lethalis schreef op woensdag 24 augustus 2022 @ 13:29:
[...]

Ik heb een gezin. Ik ben tegenwoordig al blij als het mij lukt om de belangrijkste ontwikkelingen te volgen.

Geen gezin, wel ben ik trainer en bijna elk weekend zit vol. Overigens volg ik het ook amper, maar als je met 10 taaltjes/systeempjes gewerkt hebt begint het allemaal op elkaar te lijken. Dan wordt het "oh, concept van A en de beperkingen van B". En dan sta je op 11 taaltjes die je ken.

Ik word wel een beetje zenuwachtig van het woordje "DevOps" in vacatures. Dat lijkt me een heel onderwerp an sich, maar staat steeds vaker bij gewone developer vacatures. Het is nogal een breed onderwerp waar je alle kanten mee op kunt volgens mij.

"Dev" kan je waarschijnlijk al, en "Ops" is vooral het operationeel brengen/houden. Het is een soort combi van software ontwikkelen en applicatiebeheerder zijn. In de regel komt het neer op uptime garanderen en de logs bijhouden. Daar zit een beetje tooling om heen, maar dat is vooral developers focussed.

RayNbow schreef op woensdag 24 augustus 2022 @ 14:09:
[...]

Kan ik reeds bestaande C#-code in JS hergebruiken dan?

Ja, dat kan en andersom ook.
C# -> JS is Blazor.Wasm
JS -> C# kan al heel lang op verschillende manieren, maar de bekendste is scriptengine.

Oh... Bedoelde je met een sterke integratie? Nee, maar dat is zelden/nooit bij meerdere runtimes.

[Sandor_Clegane]

DevWouter schreef op woensdag 24 augustus 2022 @ 16:51:
[...]

Dat klinkt niet als een probleem van de taal

Daarom is TypeScript er ook, omdat Javascript zo'n fijne taal is waar niets mis mee is.

Er zijn gewoon talen die ik prettiger vind werken, JS is daar niet een van. Daarom is het fijn als je gewoon in een taal kunt blijven werken zonder dat je ineens weer met een andere syntax aan de slag moet. Lagere "cognitive load", ben ik voor. Eerst vond ik een single pass compiler ook irritant, nu vind ik het eigenlijk wel handig: refereer je naar iets moet het er altijd boven staan. Maakt structuur ook wel handig: Types bovenaan en dan volgt de rest. Soms is het irritant, maar meestal kom je er wel uit.

Persoonlijk.

[ Voor 49% gewijzigd door Sandor_Clegane op 24-08-2022 17:11 ]

[DevWouter]

Sandor_Clegane schreef op woensdag 24 augustus 2022 @ 16:57:
[...]


Daarom is TypeScript er ook, omdat Javascript zo'n fijne taal is waar niets mis mee is.

<trol>Daarom is VB er ook, omdat C# zo'n fijne taal is waar niets mis mee is. :)</trol>

Oprecht: Elk taal heeft zijn voor en nadelen. En die weeg je af voor jouw persoonlijke situatie en dan kies je er een.

[Sandor_Clegane]

DevWouter schreef op woensdag 24 augustus 2022 @ 17:08:
[...]


<trol>Daarom is VB er ook, omdat C# zo'n fijne taal is waar niets mis mee is. :)</trol>

Oprecht: Elk taal heeft zijn voor en nadelen. En die weeg je af voor jouw persoonlijke situatie en dan kies je er een.

Is al goed.

[ Voor 51% gewijzigd door Sandor_Clegane op 24-08-2022 17:31 ]

[RayNbow]

DevWouter schreef op woensdag 24 augustus 2022 @ 16:51:
[...]


Ja, dat kan en andersom ook.
C# -> JS is Blazor.Wasm

Maar dan heeft Blazor dus een bestaansrecht voorbij het oplossen van een probleem met je team?

[armageddon_2k1]

Even een discussie starten:

print-debugging of debugger debugging

Ik ben fervent voorstander van het laatste, maar het valt me op, vooral bij mijn nieuwe opdracht, waar de legacy stack PHP is en een nieuwere stack volledig NodeJS + React in Typescript is, dat iedereen uitsluitend middels console.log debugged. Bij mijn vorige opdracht was hetgene waar ik aan werkte Kotlin en daar was het gewoon debuggen middels de IntelliJ debugger.

Ik heb meteen WebStorm/VSCode ingesteld met debugger en sourcemaps aan. En het is een eitje, maar de rest wil er echt niet aan en ik snap het niet. Het is zo ongelooflijk veel sneller dan:
- console.log neerplempen
- command+s
- wachten tot compiler compiled heeft en service opnieuw start (~5s)
- request nog een keer sturen via Postman/Insomnia
- console.logs interpreteren
- rinse and repeat

Zo was er een issue dat er een bepaalde controller een nog al bizarre exception gooide. Mijn routine was als volgt:
- breakpoint in exception handler
- exception triggeren
- stacktrace
- voila, externe api had een verlopen SSL certificaat en die werd niet goed afgehandeld

1 minuut werk, terwijl de rest al 10 minuten overal console.logs aan het plempen was.

Maar, ik merk dat het enorm community specifiek is. Zo merk ik het in mijn Rust-zij-avontuurtjes ook, dat de meesten print-debuggen.

Hoe staan jullie hierin? Ik heb echt het gevoel alsof je autorijdt met 1 hand en 1 voet en 1 oog, als ik alleen maar println-debug.

[erwn]

Print-debuggen is verschrikkelijk. En geen debuggen.

[Matis]

Als de situatie het even toelaat debug ik ook met de debugger (PHP), maar soms ontkom je er niet aan om alleen middels logging te debugger.

Overigens poep ik daar ook altijd de stacktrace uit, dus drijft de oorspronkelijke fout ook relatief snel boven.

[Sandor_Clegane]

Meh, beide zijn handig. Soms loop ik tegen timing issues aan van andere systemen (TCP Timeouts) en dan is een print handig omdat het programma dan gewoon door "loopt". Onder print versta ik dan ook zoiets als serilog met een console sink.

Zoals met alles: it depends.

[ Voor 14% gewijzigd door Sandor_Clegane op 26-08-2022 11:46 ]

[DevWouter]

armageddon_2k1 schreef op vrijdag 26 augustus 2022 @ 11:30:
Even een discussie starten:

print-debugging of debugger debugging

Nope, TDD all the way.
Een van de eerste dingen die mij opviel toen ik volledig TDD ging doen was dat ik niet langer mijn code ging debuggen. Het is vaak sneller en effectiever om een test toe te voegen.

De enige uitzondering is wanneer ik het gedrag van mijn code niet begrijp en dat is bijna altijd bij interactie met een ander systeem. Zoals een bestand opslaan en vervolgens direct weer inlezen waarbij ik een foutmelding krijg. Of, inderdaad, een SSL certificaat die niet gevonden kan worden. En Sandor_Clegane in "De Devschuur Coffee Corner - Iteratie ⑬" met zijn timingsproblemen is ook een goeie. Zo vergeet ik wel eens threadpool starvation

[Gropah]

Niet alle talen hebben even makkelijk een debugger beschikbaar. Bij java is het ongeveer een given, maar met bijvoorbeeld javascript moet je er even wat meer moeite voor doen en niet iedereen vind het die investering van tijd en moeite waard. En soms is hij er ook gewoon niet. Zo had Go had een tijdje geen (goede) debugger (maar dat is tegenwoordig gelukkig nogal anders door delve).

Zelf gebruik ik graag een debugger, maar voor javascript zut gebruik ik vaak genoeg printlines omdat ik het nauwelijks aanraak en het door de ontwikkelomgeving niet makkelijk word gemaakt om dat te koppelen. De inbrowser debugger is leuk, maar ook niet altijd handig of mogelijk.

[ Voor 4% gewijzigd door Gropah op 26-08-2022 11:51 ]

[Sandor_Clegane]

Ligt ook wel voor een groot deel aan de taal denk ik. Als je beschikking hebt over een Option type of een Result type en je gebruikt die om "externe" aanvoer in je programmatuur te valideren voordat je aannames doet over de "state" van je applicatie kun je al een heleboel dingen afvangen.

Dat brengt je dan weer bij het volgende, als dingen mislukken, heeft het dan überhaupt zin om door te gaan? Beetje het "happy path" programming.

code:

let socketReceive (socket:Browser.Types.WebSocket) =
    let socketReceive (dispatch:Dispatch<Msg>) =
        socket.onmessage <- (fun x ->
            match Decode.Auto.fromString<SocketMessage>(x.data.ToString()) with
            | Ok msg ->
                SocketMessage msg |> dispatch

            | Error e ->
                Browser.Dom.console.log(sprintf "Error %s" e)

        )
    Cmd.ofSub socketReceive

Bovenstaande voor een websocket die Ok of een Error kan geven en de error message in de browser console print, heb ik weinig problemen mee.

[Sebazzz]

DevWouter schreef op woensdag 24 augustus 2022 @ 11:57:
@Lethalis Ik blijf het vooral verbazingwekkend vinden dat mensen een webapplicatie ontwikkelen, maar niet bereid zijn om het ecosysteem te begrijpen.

Wie zegt dat het onwilligheid is? Er is geen "het ecosysteem" - Angular is een ding op zich, net zoals React en Vue. Het abstraheert allemaal de DOM met een eigen laagje.

Gulp/Webpack met een soort CSS bundling en compilation hou je toch wel, ook als je een Blazor applicatie ontwikkeld.

En remote renderen is leuk tot dat je interactief bezig gaat zijn. Dan wil je dat bepaalde zaken door de client afgehandeld wordt en kom je alsnog uit bij JavaScript

Gelukkig wordt die mate van interactiviteit vaak niet vereist in de meeste LOB applicaties die door waarschijnklijk de meeste van ons worden ontwikkeld

Blazor is oplossing voor een probleem met je team.

En Angular is een oplossing voor als je teveel tijd hebt zeker

Het laat ons productief zijn op de beste manier mogelijk, zonder teveel dubbelingen in code of cermony/boilerplate. Weinig glue code, maar concreet focussen op functionaliteit.

Als ik zie hoeveel code je nodig hebt om een formulier in Angular te maken met een paar complexe dynamische validatieregels, en het dan ook server-side te koppelen met je C# webapplicatie Nee, dankjewel.

[armageddon_2k1]

DevWouter schreef op vrijdag 26 augustus 2022 @ 11:44:
[...]

Nope, TDD all the way.
Een van de eerste dingen die mij opviel toen ik volledig TDD ging doen was dat ik niet langer mijn code ging debuggen. Het is vaak sneller en effectiever om een test toe te voegen.

Oh ja, dat zeker. Maar laten we die can-of-worms maar niet openen. Hoeveel devs ik wel niet tegenkom die gewoon geen tests schrijven of uberhaubt hun code niet testen zelf. Ik snap het gewoon niet. Echt niet.

Het idee dat je regressies afvangt na refactoring bijvoorbeeld is al helemaal vreemd.

Gelukkig lukt het me om het langzaam hier er ook in te krijgen en een collega pakt het heel gretig op. Dat is goed om te zien. Maar allemachtig zeg, hoe kan je nou code schrijven zonder tests.

Het is dat ik vaak bij langlopende projecten erbij kom en het dan nadien toe moet voegen, maar ik heb nu al een paar x gehad dat er geen enkele test is. Geen enkele.

En dat is het niet vreemd dat je tickets krijgt met: "Feature X werkt niet meer, net als 3 maanden geleden".

[ Voor 14% gewijzigd door armageddon_2k1 op 26-08-2022 12:06 ]

[armageddon_2k1]

Gropah schreef op vrijdag 26 augustus 2022 @ 11:50:
Niet alle talen hebben even makkelijk een debugger beschikbaar. Bij java is het ongeveer een given, maar met bijvoorbeeld javascript moet je er even wat meer moeite voor doen en niet iedereen vind het die investering van tijd en moeite waard.

Investering? Het is 1 minuut werk?

[Sebazzz]

armageddon_2k1 schreef op vrijdag 26 augustus 2022 @ 11:58:
[...]


Oh ja, dat zeker. Maar laten we die can-of-worms maar niet openen. Hoeveel devs ik wel niet tegenkom die gewoon geen tests schrijven of uberhaubt hun code niet testen zelf. Ik snap het gewoon niet. Echt niet.

Ik snap het wel, je denk namelijk zonder TDD sneller af te zijn, sneller resultaat te hebben.

Tijdens het ontwikkelproces begin je dan al een beetje vast te lopen en uiteindelijk verdere doorontwikkeling en onderhoud wordt zeker duur doordat je geen tests hebben die functionaliteit borgen. Maarja, dat is een ander potje waar dat uit betaald wordt - zeker bij klantprojecten.

[armageddon_2k1]

Sebazzz schreef op vrijdag 26 augustus 2022 @ 12:01:
[...]

Ik snap het wel, je denk namelijk zonder TDD sneller af te zijn, sneller resultaat te hebben.

Tijdens het ontwikkelproces begin je dan al een beetje vast te lopen en uiteindelijk verdere doorontwikkeling en onderhoud wordt zeker duur doordat je geen tests hebben die functionaliteit borgen. Maarja, dat is een ander potje waar dat uit betaald wordt - zeker bij klantprojecten.

Je hebt tests schrijven en TDD. TDD vereist discipline en een investering die zich 100% uitbetaalt. Maar dat zie ik bijna nergens echt gebeuren.

Ik ben al blij als mensen de requirements van een feature uitschrijven in tests. Dan zie ik iig hoe de feature geinterpreteerd is. Het is dan geen TDD maar meer validatie.

[Koenvh]

Sandor_Clegane schreef op vrijdag 26 augustus 2022 @ 11:42:
Meh, beide zijn handig. Soms loop ik tegen timing issues aan van andere systemen (TCP Timeouts) en dan is een print handig omdat het programma dan gewoon door "loopt". Onder print versta ik dan ook zoiets als serilog met een console sink.

Zoals met alles: it depends.

Inderdaad. Dingen als concurrencyproblemen of tokens met een hele korte levensduur zijn niet praktisch met een debugger op te lossen.

Ik zie het als een gereedschapskist. Bepaalde gereedschappen wend ik vaker aan, maar uiteindelijk kun je er meerdere gebruiken om je doel te bereiken. Je hoeft jezelf niet te beperken tot alleen een hamer of alleen een schroevendraaier.

[DevWouter]

armageddon_2k1 schreef op vrijdag 26 augustus 2022 @ 11:58:
Het is dat ik vaak bij langlopende projecten erbij kom en het dan nadien toe moet voegen, maar ik heb nu al een paar x gehad dat er geen enkele test is. Geen enkele.

Ik zit vaak in soort gelijke situaties en ben van mening dat geen tests de voorkeur heeft over wat sommige mensen denken dat een test is. Sommige mensen schrijven een test met als doel om te zorgen dat de code niet "zomaar" aangepast kan worden.

En in brownfield projecten kan je ook TDD toepassen, maar in de beginfase (ik spreek hier C#) zit je vaak met proxy classes. De eerste paar pull requests waarbij ik TDD introduceer zijn soms een gevecht omdat er nogal wat "nutteloze" code in staat. Maar een paar commits later en het team begint een voorkeur te krijgen voor mijn code omdat de infrastructuur en code daar zoveel simpeler is. Tevens geven de tests ze ook meer vertrouwen in hun aanpassingen waardoor ze sneller gaan werken. En dat is mooi want daardoor kan ik me concentreren op de oude meuk dat nog vol met bugs zitten waar niemand weet van heeft.

Het team dat sterk afwijkt van mijn werkmethode moet ik nog tegenkomen. Wel vereist het wat begeleiding en moet ik in het begin wel even opletten dat ze niet in de gebruikelijke valkuilen stappen zoals 100% test coverage of code schrijven die ze "mogelijk in de toekomst nodig hebben".

[DevWouter]

Sebazzz schreef op vrijdag 26 augustus 2022 @ 11:58:
[...]

Wie zegt dat het onwilligheid is?

Men wilt het toch niet leren?

Er is geen "het ecosysteem" - Angular is een ding op zich, net zoals React en Vue. Het abstraheert allemaal de DOM met een eigen laagje.

Gulp/Webpack met een soort CSS bundling en compilation hou je toch wel, ook als je een Blazor applicatie ontwikkeld.

Met "bekend zijn met het ecosysteem" bedoel ik dat je de target omgeving goed begrijpt (in dit geval web en dus HTTP, HTML, CSS, JavaScript, secure context et cetera).

Gelukkig wordt die mate van interactiviteit vaak niet vereist in de meeste LOB applicaties die door waarschijnklijk de meeste van ons worden ontwikkeld

Ik zie het vaak terug bij client side validatie en vreemd genoeg navigatie.

Het laat ons productief zijn op de beste manier mogelijk, zonder teveel dubbelingen in code of cermony/boilerplate. Weinig glue code, maar concreet focussen op functionaliteit.

Zoals je aangeeft laat het "jullie" productief zijn. Er zijn genoeg teams die het tegendeel beweren
En ik wou dat C# iets had wat van het niveau van rxjs is.

Als ik zie hoeveel code je nodig hebt om een formulier in Angular te maken met een paar complexe dynamische validatieregels, en het dan ook server-side te koppelen met je C# webapplicatie Nee, dankjewel.

Misschien een paar versies terug, maar tegenwoordig is het simpelt. Het is juist in de recente versie van dotnet dat het complexer is geworden, zeker als je dynamische formulieren hebt. Maar dat is ook omdat ik vaak meer checks client side hebt terwijl server side meestal weg kom met een generieke 5xx melding.

[Sebazzz]

DevWouter schreef op vrijdag 26 augustus 2022 @ 12:53:
[...]

Misschien een paar versies terug, maar tegenwoordig is het simpelt.

Dit noem ik niet simpel

Het is juist in de recente versie van dotnet dat het complexer is geworden, zeker als je dynamische formulieren hebt.

Ik zie niet hoe, zeker niet als je zoiets als FluentValidation gebruikt. Als je library-schuw bent heb je ook nog gewoon IValidatableObject.

[armageddon_2k1]

DevWouter schreef op vrijdag 26 augustus 2022 @ 12:28:
[...]

Ik zit vaak in soort gelijke situaties en ben van mening dat geen tests de voorkeur heeft over wat sommige mensen denken dat een test is. Sommige mensen schrijven een test met als doel om te zorgen dat de code niet "zomaar" aangepast kan worden.

Hmm, ik voel me aangesproken hierdoor Wellicht ten onrechte.
In het geval van totaal ontbrekende tests voeg ik soms tests toe aan kritische business-logica om in ieder geval te garanderen dat na refactors aan de belangrijkste requirements nog steeds voldaan wordt. Bedoel je dat?

Dus, stel je voor dat je een service hebt die middles 1 methode 4 andere services aanroept en daar vanalles gepingpongt wordt, dan voeg ik initieel even een paar tests toe op die bovenliggende service methode om de in- en outputs te valideren. Die bovenliggende service zit natuurlijk op een hoog niveau.

Mocht er dan een dev in een van de diepere services iets aanpassen wat een van de requirements beinvloedt, dan bokt die ene test. Dat is dan natuurlijk ook gewoon een integratietest.

En later, mocht het dan lukken, dan kunnen we de diepere services individueel gaan unit-testen.

[DevWouter]

Sebazzz schreef op vrijdag 26 augustus 2022 @ 13:05:
[...]

Dit noem ik niet simpel

Daarom gebruik ik die ook niet.
Serieus, je wilt niet weten hoeveel slecht advies er over angular te vinden is. Ik zou https://angular.io/guide/...efining-custom-validators als startpunt nemen en daarna zou ik cross-field validation pakken.

Ik zie niet hoe, zeker niet als je zoiets als FluentValidation gebruikt. Als je library-schuw bent heb je ook nog gewoon IValidatableObject.

FluentValidation mag van mij dood, die valt bij mij in de categorie automapper: Een oplossing die te makkelijk verkeerd gebruikt kan worden. En IValidatableObject is fijn tenzij je een voorkeur hebt voor PODs. Toen ik dit las verbaasde me ik er over dat Microsoft hier geen composition ipv inherintence hanteerde.
Overigens is dit een "mij-probleem"

[DevWouter]

armageddon_2k1 schreef op vrijdag 26 augustus 2022 @ 13:41:
[...]


Hmm, ik voel me aangesproken hierdoor Wellicht ten onrechte.
In het geval van totaal ontbrekende tests voeg ik soms tests toe aan kritische business-logica om in ieder geval te garanderen dat na refactors aan de belangrijkste requirements nog steeds voldaan wordt. Bedoel je dat?

Nee, ik bedoel stommiteiten als implementatie van een andere functie uit een andere class testen ipv die aangeroepen wordt. Of metadata inspectie.

Zaken waardoor als je ergens een functie wilt aanpassen dat alleen kan door 10 andere zaken aan te passen en waardoor je uiteindelijk besluit "fuck it, ik verwijder die test en schrijf het opnieuw wanneer ik het ga aanraken".

[Sandor_Clegane]

DevWouter schreef op vrijdag 26 augustus 2022 @ 13:48:
[...]

Daarom gebruik ik die ook niet.
Serieus, je wilt niet weten hoeveel slecht advies er over angular te vinden is. Ik zou https://angular.io/guide/...efining-custom-validators als startpunt nemen en daarna zou ik cross-field validation pakken.


[...]

FluentValidation mag van mij dood, die valt bij mij in de categorie automapper: Een oplossing die te makkelijk verkeerd gebruikt kan worden. En IValidatableObject is fijn tenzij je een voorkeur hebt voor PODs. Toen ik dit las verbaasde me ik er over dat Microsoft hier geen composition ipv inherintence hanteerde.
Overigens is dit een "mij-probleem"

Deze hele post haalt toch je argument onderuit?

[DevWouter]

Sandor_Clegane schreef op vrijdag 26 augustus 2022 @ 14:16:
[...]

Deze hele post haalt toch je argument onderuit?

Hé, niemand zei dat ik maar 1 "mij-probleem" heb

[Sandor_Clegane]

DevWouter schreef op vrijdag 26 augustus 2022 @ 14:21:
[...]


Hé, niemand zei dat ik maar 1 "mij-probleem" heb

hehehe, wat minder bot: ik denk dat je vergeet hoeveel kennis je (onbewust) al hebt waardoor dingen "simpel" lijken.

Niets is simpel, als het simpel was zou iedereen het doen.

[DevWouter]

Sandor_Clegane schreef op vrijdag 26 augustus 2022 @ 14:23:
[...]

hehehe, wat minder bot: ik denk dat je vergeet hoeveel kennis je (onbewust) al hebt waardoor dingen "simpel" lijken.

En ook niet dat ik maar 2 mij-problemen had...

Maar inderdaad, dat is het nadeel van ervaren zijn. Dan sta je vaak niet stil bij hoeveel complexe afwegingen wij in één keer doen waar we paar jaar geleden uren over deden. Overigens probeer ik altijd om de domste in het bedrijf te zijn om anderen zo snel mogelijk de kennis en ervaringen te laten opbouwen die ik al bezit.

Niets is simpel, als het simpel was zou iedereen het doen.

Ik gebruik die zin zó ontzettend vaak bij juniors/mediors wanneer ik ze gefrustreerd zie worden omdat het "simpel zou zijn". Ze onderschatten zo vaak hun eigen capaciteit om beter te worden. Dan leg ik vaak uit hoeveel uren ik in mijn vak heb gestopt en dat zij over een paar jaar op mijn plek zullen zitten om dit uit te leggen aan hun junior.

[Sandor_Clegane]

DevWouter schreef op vrijdag 26 augustus 2022 @ 14:37:
[...]


En ook niet dat ik maar 2 mij-problemen had...

Maar inderdaad, dat is het nadeel van ervaren zijn. Dan sta je vaak niet stil bij hoeveel complexe afwegingen wij in één keer doen waar we paar jaar geleden uren over deden. Overigens probeer ik altijd om de domste in het bedrijf te zijn om anderen zo snel mogelijk de kennis en ervaringen te laten opbouwen die ik al bezit.

oe.......

Ik gebruik die zin zó ontzettend vaak bij juniors/mediors wanneer ik ze gefrustreerd zie worden omdat het "simpel zou zijn". Ze onderschatten zo vaak hun eigen capaciteit om beter te worden. Dan leg ik vaak uit hoeveel uren ik in mijn vak heb gestopt en dat zij over een paar jaar op mijn plek zullen zitten om dit uit te leggen aan hun junior.

Ik probeer het altijd mee te geven zodat mensen hun werk op waarde weten te schatten. Vooral in de creatieve tak heb je vaak de volgende dynamiek: "maar je vindt het toch leuk om te doen?" waarbij ze onuitgesproken bedoelen: "dan hoef ik er toch niet zoveel voor te betalen". Fuck em.

Vooral bij jonge mensen is het een valkuil.

Programmeren is een creatief proces.

[ValHallASW]

DevWouter schreef op vrijdag 26 augustus 2022 @ 12:53:
En ik wou dat C# iets had wat van het niveau van rxjs is.

System.Reactive aka Rx.NET? (hoewel rxjs volgens mij wel een stuk beter onderhouden wordt)

Overigens heb ik met zowel RxJs als Rx.NET geen positieve ervaringen. Het ziet er allemaal prachtig uit, tot je iets complexers wilt, het niet werkt, en je geen enkele tooling hebt om er achter te komen waarom het niet werkt (en dat is dan meestal door slecht gedocumenteerd gedrag van operators, die zelf weer slecht te debuggen zijn, etc.). En ja, ik heb me ingelezen.

Het zou natuurlijk kunnen dat ik de scenarios waar reactive wél meer waarde toevoegt dan het aan complexiteit kost nog niet ben tegengekomen

[Sandor_Clegane]

ValHallASW schreef op vrijdag 26 augustus 2022 @ 19:31:
[...]

System.Reactive aka Rx.NET? (hoewel rxjs volgens mij wel een stuk beter onderhouden wordt)

Overigens heb ik met zowel RxJs als Rx.NET geen positieve ervaringen. Het ziet er allemaal prachtig uit, tot je iets complexers wilt, het niet werkt, en je geen enkele tooling hebt om er achter te komen waarom het niet werkt (en dat is dan meestal door slecht gedocumenteerd gedrag van operators, die zelf weer slecht te debuggen zijn, etc.). En ja, ik heb me ingelezen.

Het zou natuurlijk kunnen dat ik de scenarios waar reactive wél meer waarde toevoegt dan het aan complexiteit kost nog niet ben tegengekomen

Wat wel grappig is, is dat Rx juist uit .Net komt: het hele idee dat IObservable de natuurlijke tegenhanger van IEnumerable is.

[Koenvh]

Ik kwam vandaag deze hCaptcha voor het eerst tegen:


Ik ga toch weer liever verkeerslichten aanklikken geloof ik

[Sandor_Clegane]

Koenvh schreef op vrijdag 26 augustus 2022 @ 19:53:
Ik kwam vandaag deze hCaptcha voor het eerst tegen:
[Afbeelding]

Ik ga toch weer liever verkeerslichten aanklikken geloof ik

Ze zijn de parameters van het algoritme wat scherper aan het afstellen: een hond herkennen is niet genoeg, nu ook of hij lacht.

Thank you for your service!

[RagingPenguin]

Sandor_Clegane schreef op vrijdag 26 augustus 2022 @ 19:46:
[...]


Wat wel grappig is, is dat Rx juist uit .Net komt: het hele idee dat IObservable de natuurlijke tegenhanger van IEnumerable is.

Mwa, dat een IObservable (eigenlijk een continuation) een sequence van values bevat in is FP kringen al een heel stuk ouder dan .Net uberhaupt is.

[Sandor_Clegane]

RagingPenguin schreef op vrijdag 26 augustus 2022 @ 22:05:
[...]


Mwa, dat een IObservable (eigenlijk een continuation) een sequence van values bevat in is FP kringen al een heel stuk ouder dan .Net uberhaupt is.

Dat zal vast, everything old is "new" again.

[DevWouter]

@Sandor_Clegane en @RagingPenguin
Een IObservable is beter te vergelijken met eventhandler dan een IEnumerable. Bij IEnumerable heb je namelijk een pull/poll handeling nodig terwijl IObservable juist push is.
Op https://github.com/dotnet/reactive staat een tabelletje waar ze met elkaar vergelijken worden.

@ValHallASW
De juiste scenarios zijn inderdaad erg handig
Het is vooral handig als je met veel events werkt die je samen wilt gebruiken en die je met elkaar moet mixen.
Denk bijvoorbeeld aan het tonen van een een lijst met resultaten en een pager waarbij je ook de loading/ready/error state rekening mee wilt houden.

En het probleem met Rx.NET is dat van wat ik laatst gezien heb het nogal erg achterloopt.

[alienfruit]

Denk dat ik stop met open-source…
Laatst een PR gemaakt voor een project voor veel gevraagde feature, na tijd PR niet geaccepteerd, nu paar weken verder, project maintainer opent PR met dezelfde aanpak waar ze bij mijn PR over vielen. Rete irritant.

[Caelorum]

@DevWouter hij zei natuurlijk ook tegenhanger.

Rx.net die achterloopt is ook wel.te begrijpen. Laatst keer dat ik een use case zag was silverlight nog een ding. Tenzij we die en wpf nog weer willen gebruiken...?

[Douweegbertje]

alienfruit schreef op zaterdag 27 augustus 2022 @ 03:31:
Denk dat ik stop met open-source…
Laatst een PR gemaakt voor een project voor veel gevraagde feature, na tijd PR niet geaccepteerd, nu paar weken verder, project maintainer opent PR met dezelfde aanpak waar ze bij mijn PR over vielen. Rete irritant.

Ja dat is knudde

Ik check meestal toch even wie de maintainers zijn en hoe ze zich gedragen (hoe snel worden dingen gemerged, wat zeggen ze in issues) voordat ik er tijd in stop.
Meestal limiteer ik mijzelf tot alleen CNCF contributies daarom

[Mugwump]

DevWouter schreef op vrijdag 26 augustus 2022 @ 14:37:
Ik gebruik die zin zó ontzettend vaak bij juniors/mediors wanneer ik ze gefrustreerd zie worden omdat het "simpel zou zijn". Ze onderschatten zo vaak hun eigen capaciteit om beter te worden. Dan leg ik vaak uit hoeveel uren ik in mijn vak heb gestopt en dat zij over een paar jaar op mijn plek zullen zitten om dit uit te leggen aan hun junior.

Ik heb nu een vrij groot team en ik merk wel dat er op dat vlak veel verschil zit tussen individuele juniors / mediors (of zelfs seniors die zich vooral naar binnen hebben geluld / neer zijn gezet door een partij die iedereen met 1 jaar werkervaring senior maakt).
Er zijn erbij die voldoen aan het beeld dat jij hier omschrijft en in dat soort mensen investeer ik graag tijd. Daar zie je namelijk resultaat.

Ik heb echter ook wel types die eigenlijk het niveau 'copy-paste coder' nooit gaan overstijgen, omdat ze zich nooit echt in zaken lijken te willen verdiepen. Die willen vooral dat ik even snel een probleem voor ze oplos of even snel weer een nieuw 'trucje' leren. Ik probeer mensen vaak niet enkel uit te leggen waar ze specifiek in een bepaald geval tegenaan lopen, maar ook wat de onderliggende oorzaak is en hoe iets werkt.

Bij sommige van dat soort types geef je dan bijvoorbeeld wel eens een link naar documentatie over hoe iets werkt waar je dan vele uren zoet mee kunt zijn, maar dan krijg je doodleuk een minuut later terug 'de documentatie is niet duidelijk', waarmee ze feitelijk bedoelden dat ctrl-/cmd-f ze geen hapklaar antwoord op hun probleem opleverde. Misschien word ik gewoon een oude zeur, maar ik heb in mijn carrière gewoon ook heel veel tijd geïnvesteerd in het lezen van boeken, volgen van trainingen en ga zo maar door. Er lijken in de nieuwe generatie developers toch ook wel veel Tiktokdevelopers te zitten die verwachten dat alles maar te begrijpen valt door naar een filmpje van maximaal 10 seconden te kijken bij wijze van spreken.

[Sandor_Clegane]

DevWouter schreef op zaterdag 27 augustus 2022 @ 02:38:
@Sandor_Clegane en @RagingPenguin
Een IObservable is beter te vergelijken met eventhandler dan een IEnumerable. Bij IEnumerable heb je namelijk een pull/poll handeling nodig terwijl IObservable juist push is.
Op https://github.com/dotnet/reactive staat een tabelletje waar ze met elkaar vergelijken worden.

@ValHallASW
De juiste scenarios zijn inderdaad erg handig
Het is vooral handig als je met veel events werkt die je samen wilt gebruiken en die je met elkaar moet mixen.
Denk bijvoorbeeld aan het tonen van een een lijst met resultaten en een pager waarbij je ook de loading/ready/error state rekening mee wilt houden.

En het probleem met Rx.NET is dat van wat ik laatst gezien heb het nogal erg achterloopt.

YouTube: RxJs - explained by Rx Inventor Erik Meijer
From the horse's mouth.

Mugwump schreef op zaterdag 27 augustus 2022 @ 08:17:
[...]


Ik heb nu een vrij groot team en ik merk wel dat er op dat vlak veel verschil zit tussen individuele juniors / mediors (of zelfs seniors die zich vooral naar binnen hebben geluld / neer zijn gezet door een partij die iedereen met 1 jaar werkervaring senior maakt).
Er zijn erbij die voldoen aan het beeld dat jij hier omschrijft en in dat soort mensen investeer ik graag tijd. Daar zie je namelijk resultaat.

Ik heb echter ook wel types die eigenlijk het niveau 'copy-paste coder' nooit gaan overstijgen, omdat ze zich nooit echt in zaken lijken te willen verdiepen. Die willen vooral dat ik even snel een probleem voor ze oplos of even snel weer een nieuw 'trucje' leren. Ik probeer mensen vaak niet enkel uit te leggen waar ze specifiek in een bepaald geval tegenaan lopen, maar ook wat de onderliggende oorzaak is en hoe iets werkt.

Bij sommige van dat soort types geef je dan bijvoorbeeld wel eens een link naar documentatie over hoe iets werkt waar je dan vele uren zoet mee kunt zijn, maar dan krijg je doodleuk een minuut later terug 'de documentatie is niet duidelijk', waarmee ze feitelijk bedoelden dat ctrl-/cmd-f ze geen hapklaar antwoord op hun probleem opleverde. Misschien word ik gewoon een oude zeur, maar ik heb in mijn carrière gewoon ook heel veel tijd geïnvesteerd in het lezen van boeken, volgen van trainingen en ga zo maar door. Er lijken in de nieuwe generatie developers toch ook wel veel Tiktokdevelopers te zitten die verwachten dat alles maar te begrijpen valt door naar een filmpje van maximaal 10 seconden te kijken bij wijze van spreken.

Volgens mij kun je dit gewoon samenvatten als een gebrek aan nieuwsgierigheid.

[ Voor 47% gewijzigd door Sandor_Clegane op 27-08-2022 09:19 ]

[RagingPenguin]

DevWouter schreef op zaterdag 27 augustus 2022 @ 02:38:
@Sandor_Clegane en @RagingPenguin
Een IObservable is beter te vergelijken met eventhandler dan een IEnumerable. Bij IEnumerable heb je namelijk een pull/poll handeling nodig terwijl IObservable juist push is.
Op https://github.com/dotnet/reactive staat een tabelletje waar ze met elkaar vergelijken worden.

Dit is meer een interessant verschil tussen paradigms dan iets waar een hard antwoord op bestaat. Vanuit een imperatief of OOP perspectief heb je helemaal gelijk, en dat is ook hoe IObservable in plain-old dotnet is geïmplementeerd.

Maar vanuit een functioneel perspectief is het gewoon een black-box die ergens tussen 0 en oneindig waardes gaat bevatten en waarvoor we join, map en bind kunnen implementeren. Oftewel, exact hetzelfde wat we ook voor lists en trees kunnen doen. Nu leidt dat wel tot een iets andere implementatie waarbij je het ding wat pushed in de box stopt, i.p.v. een public method om te publiceren. Maar dat heeft mensen er niet van weerhouden om dit ook voor de dotnet observalble te doen System.Reactive.Linq.

[Mugwump]

Sandor_Clegane schreef op zaterdag 27 augustus 2022 @ 09:09:


[...]


Volgens mij kun je dit gewoon samenvatten als een gebrek aan nieuwsgierigheid.

Dat is het ook niet helemaal in mijn ogen. Een totaal gebrek aan nieuwsgierigheid kom ik ook wel tegen, maar dan vaak eerder bij oudere collega's die niets liever willen dan 0 verandering en enge nieuwe dingen in de laatste 10 jaar tot aan hun pensioen.

Vaak is er juist bij het soort mensen dat ik beschrijf wel de nieuwsgierigheid om met nieuwe dingen bezig te gaan zoals allerlei hippe serverless technologie en dergelijke, maar interesse in de verdiepingsslag die in mijn ogen echt noodzakelijk is om door te groeien als developer als je ooit senior / leader / architecturele ambities hebt ontbreekt. Overigens niet alleen op het technische vlak, maar vaak nog veel meer op het functionele, al snap ik ook wel dat als developer waar al heel wat technische kennis van je gevraagd was je ook nog verdiepen in de concepten en bedrijfsprocessen waar 'de business' zich mee bezighoudt best pittig is. Maar als je als developer op het niveau zit dat je werk kan doen in de vorm van 'maak een mapping van dataformaatje A naar dataformaatje B' of 'Doe hetzelfde als we op deze andere plek in de codebase doen, maar dan net iets anders', dan blijft je marktwaarde wel wat beperkt.

[Lethalis]

Mugwump schreef op zaterdag 27 augustus 2022 @ 11:11:
[...]
Vaak is er juist bij het soort mensen dat ik beschrijf wel de nieuwsgierigheid om met nieuwe dingen bezig te gaan zoals allerlei hippe serverless technologie en dergelijke, maar interesse in de verdiepingsslag die in mijn ogen echt noodzakelijk is om door te groeien als developer als je ooit senior / leader / architecturele ambities hebt ontbreekt.

Misschien toch ook een beetje een generationele kloof? Jeugd die met social media is opgegroeid en eigenlijk altijd afgeleid is?

Ik had vroeger geen andere keuze dan het boek of de documentatie lezen Al kan tegenwoordig het kijken van iemand die dingen uitlegt op YouTube (zoals Tim Corey) wel iets toevoegen... maar hoofdzakelijk lees ik nog steeds boeken en documentatie.

Maar goed, ik ben met 41 jaar oud ook niet meer de jongste. Ik kwam laatst op Reddit al een post tegen die het over veertigers had alsof het "oudjes" waren in de IT

[ Voor 9% gewijzigd door Lethalis op 27-08-2022 12:50 ]

[Sandor_Clegane]

Mugwump schreef op zaterdag 27 augustus 2022 @ 11:11:
[...]


Dat is het ook niet helemaal in mijn ogen. Een totaal gebrek aan nieuwsgierigheid kom ik ook wel tegen, maar dan vaak eerder bij oudere collega's die niets liever willen dan 0 verandering en enge nieuwe dingen in de laatste 10 jaar tot aan hun pensioen.

Vaak is er juist bij het soort mensen dat ik beschrijf wel de nieuwsgierigheid om met nieuwe dingen bezig te gaan zoals allerlei hippe serverless technologie en dergelijke, maar interesse in de verdiepingsslag die in mijn ogen echt noodzakelijk is om door te groeien als developer als je ooit senior / leader / architecturele ambities hebt ontbreekt. Overigens niet alleen op het technische vlak, maar vaak nog veel meer op het functionele, al snap ik ook wel dat als developer waar al heel wat technische kennis van je gevraagd was je ook nog verdiepen in de concepten en bedrijfsprocessen waar 'de business' zich mee bezighoudt best pittig is. Maar als je als developer op het niveau zit dat je werk kan doen in de vorm van 'maak een mapping van dataformaatje A naar dataformaatje B' of 'Doe hetzelfde als we op deze andere plek in de codebase doen, maar dan net iets anders', dan blijft je marktwaarde wel wat beperkt.

Intrinsieke vs extrinsieke motivatie. Nieuwsgierigheid is, in mijn optiek, een uiting van de eerste.

Je "marktwaarde" hou je ook niet vol. (extrinsiek)

[RagingPenguin]

Mugwump schreef op zaterdag 27 augustus 2022 @ 08:17:
[...]
Misschien word ik gewoon een oude zeur, maar ik heb in mijn carrière gewoon ook heel veel tijd geïnvesteerd in het lezen van boeken, volgen van trainingen en ga zo maar door. Er lijken in de nieuwe generatie developers toch ook wel veel Tiktokdevelopers te zitten die verwachten dat alles maar te begrijpen valt door naar een filmpje van maximaal 10 seconden te kijken bij wijze van spreken.

Mugwump schreef op zaterdag 27 augustus 2022 @ 11:11:
[...]


Dat is het ook niet helemaal in mijn ogen. Een totaal gebrek aan nieuwsgierigheid kom ik ook wel tegen, maar dan vaak eerder bij oudere collega's die niets liever willen dan 0 verandering en enge nieuwe dingen in de laatste 10 jaar tot aan hun pensioen.

Lethalis schreef op zaterdag 27 augustus 2022 @ 12:48:
[...]

Misschien toch ook een beetje een generationele kloof? Jeugd die met social media is opgegroeid en eigenlijk altijd afgeleid is?

Zijn die jonge broekies die niet de moeite willen nemen om zich ergens echt in te verdiepen en die oudjes die van niets nieuws willen horen niet gewoon hetzelfde soort mensen, maar dan met 20 jaar ervaring doen alsof ze iets toevoegen?

[phex]

Ik denk wat ook een verschil is dat de mensen rond de 40 dit vak echt gekozen hebben omdat ze het interessant vonden.

[opa]
Tegenwoordig zie ik veel "framework only", "salaris-vergelijkers" en "mijn code werkt niet, dus dat ligt vast aan de library" developers...

- Als je je beperkt tot wat een framework je biedt, dan kijk je nooit verder dan je neus lang is, en groei je niet
- Salaris is echt niet het belangrijkste, en als je nou eerst echt goed wordt, kun je alsnog vragen wat je wilt.
- Als iets niet werkt, dan duik je toch in een library? Andermans code is echt geen black magic voodoo, beter nog, misschien leer je er nog iets van!
[/opa]

[phex]

RagingPenguin schreef op zaterdag 27 augustus 2022 @ 14:25:
Zijn die jonge broekies die niet de moeite willen nemen om zich ergens echt in te verdiepen en die oudjes die van niets nieuws willen horen niet gewoon hetzelfde soort mensen, maar dan met 20 jaar ervaring doen alsof ze iets toevoegen?

misschien wel haha

[Kalentum]

phex schreef op zaterdag 27 augustus 2022 @ 14:26:
- Als iets niet werkt, dan duik je toch in een library? Andermans code is echt geen black magic voodoo, beter nog, misschien leer je er nog iets van!

Ha ja, mijn favoriete opmerking als iemand zit te mopperen dat iets 'te magic' is ofzo: "Het is maar code".

[CodeCaster]

Ik vind libraries en frameworks vaak niet het summum van schone, leesbare, begrijpbare code. Bakken vol reflectie, ongedocumenteerde aannames, code die al tien jaar wordt meegezeuld en onaantastbaar is, tests die er wel zijn, maar weer legio custom layers eromheen hebben...

Ik heb zelf vaak zat in de code van .NET Framework, Entity Framework en ASP.NET (Core/MVC) gedoken om dingen uit te zoeken (voor mezelf of voor anderen op Stack Overflow), maar het is al snel "too much" om daarvan als junior iets te kunnen leren.

Als je zo'n framework al aardig kunt toepassen in applicaties, dan is het zeker nuttig om de code, PR's, docs en tests te bekijken.

Maar @DevWouter, jij roept hier al jaren dat TDD de heilige graal is en beter dan gesneden brood en wat dies meer zij, maar je moet er wel mee in aanraking komen, of jezelf erin verdiepen, mensen hebben die je (in persoon, online of op schrift) de fijne kneepjes kunnen bijbrengen. En laat veel geschreven materiaal en video online nou bar slecht zijn en nooit verder gaan dan Hello World of een TODO-app...

[Sandor_Clegane]

Tijd voor TDDO-app.

[Mugwump]

phex schreef op zaterdag 27 augustus 2022 @ 14:26:
Ik denk wat ook een verschil is dat de mensen rond de 40 dit vak echt gekozen hebben omdat ze het interessant vonden.

[opa]
Tegenwoordig zie ik veel "framework only", "salaris-vergelijkers" en "mijn code werkt niet, dus dat ligt vast aan de library" developers...

- Als je je beperkt tot wat een framework je biedt, dan kijk je nooit verder dan je neus lang is, en groei je niet
- Salaris is echt niet het belangrijkste, en als je nou eerst echt goed wordt, kun je alsnog vragen wat je wilt.
- Als iets niet werkt, dan duik je toch in een library? Andermans code is echt geen black magic voodoo, beter nog, misschien leer je er nog iets van!
[/opa]

Had laatst nog weer zo'n fantastische discussie met een team dat gebruikt maakt van een oude API die een upgrade nodig heeft, waaronder overschakelen naar Oauth.
Zij: "Nee wij kunnen dat niet combineren met OAuth"
Ik: "Uh.. Aanroepje voor authenticatie token, meegeven als header en klaar. Even wat cachen voor efficiëntie. Zo gedaan toch?"
Zij: "Wij gebruiken libraries en die zijn niet compatible met elkaar".

[Kalentum]

Mugwump schreef op zaterdag 27 augustus 2022 @ 16:23:
[...]


Had laatst nog weer zo'n fantastische discussie met een team dat gebruikt maakt van een oude API die een upgrade nodig heeft, waaronder overschakelen naar Oauth.
Zij: "Nee wij kunnen dat niet combineren met OAuth"
Ik: "Uh.. Aanroepje voor authenticatie token, meegeven als header en klaar. Even wat cachen voor efficiëntie. Zo gedaan toch?"
Zij: "Wij gebruiken libraries en die zijn niet compatible met elkaar".

Bij wat voor soort bedrijf werk jij? Ik ben hier echt verbaasd over (en de andere dingen die je post). Gaat er iets fout bij de sollicatieprocedures ofzo? Een soort basishouding van 'ik weet nog niet hoe maar we krijgen dit wel voor elkaar' lijkt me toch wel het minste. Het is geen rocketscience ofzo.

[Mugwump]

Kalentum schreef op zaterdag 27 augustus 2022 @ 16:42:
[...]


Bij wat voor soort bedrijf werk jij? Ik ben hier echt verbaasd over (en de andere dingen die je post). Gaat er iets fout bij de sollicatieprocedures ofzo? Een soort basishouding van 'ik weet nog niet hoe maar we krijgen dit wel voor elkaar' lijkt me toch wel het minste. Het is geen rocketscience ofzo.

Ik werk bij een IT dienstverlener. Die verhalen zijn wat we bij een klant meemaken. Vrij grote partij maar weinig interne IT competentie en legio meer en minder competente partijen die mensen aan ze leveren. Klant probeert zelf ook een IT afdeling op te bouwen met als gevolg dat wij "senior" developers in ons team geschoven krijgen die wij zelf misschien net aan zouden nemen als junior.