Hoe krijg ik praktische ervaring in .NET?

[Ge0force]

Ik werk al meer dan 20 jaar als developer in hetzelfde bedrijf, maar heb daar enkel gewerkt met het sterk verouderde Visual Basic 6. Ik zou heel graag overstappen naar .NET, maar ondanks vele beloften van het management heb ik die kans nooit gekregen in mijn huidige bedrijf.

Daarom heb ik besloten om mezelf op te leiden in C# met behulp van online cursussen en zelfstudie. De voorbije maanden heb ik via Pluralsight de essentials van C# geleerd: classes, generics, interfaces, LINQ, lambda expressions etc. Ik had hierbij echt wel het gevoel dat dit vlot ging en vond het bovendien erg leuk om te doen.

Na het opmaken van een LinkedIn profiel werd ik gecontacteerd door diverse recruteringskantoren. Ik had gehoopt mijn kennis verder te kunnen opbouwen door effectief aan de slag te gaan in een ervaren team, maar ik word door bedrijven telkens geweigerd omdat ik bij technische screenings of praktische tests niet de nodige ervaring kan voorleggen. Ik weet bijvoorbeeld heel goed wat Interfaces zijn en hoe je ze moet gebruiken, maar niet wanneer je ze al dan niet moet gebruiken. Ik heb ook geen idee hoe een groot project vanaf nul moet opgezet worden.

Daarom wou ik hier eens horen of er developers zijn die via zelfstudie opgeleid zijn in .NET. Hoe hebben jullie het aangepakt om naast de theorie ook voldoende praktische kennis op te bouwen om als .NET developer aan de slag te gaan? Ook praktische tips van ervaren .NET developers zijn meer dan welkom!

Alvast hartelijk dank voor jullie suggesties!

[ Voor 3% gewijzigd door Ge0force op 27-01-2023 13:10 ]

[farlane]

Beetje open deur, maar praktische ervaring krijg je alleen door het te doen.

Dat is het makkelijkst denk ik bij je (huidige?) bedrijf: Ik kan me nl niet voorstellen dat men denkt dat doorgaan met VB6 een goed idee is, tenzij die software niet bedrijfskritisch/significant is? Waarom wil men niet de 21e eeuw in?

Met enige ervaring in software bouwen (20 jaar!) kun je met C# als nieuwe taal binnen *zeer* korte tijd produktief zijn, het liefst met een peer die hetzelfde traject doet (of heeft gedaan).

Ik vraag me af wat het *echte* probleem is eigenlijk...

[biomass]

Als je wat nieuws wilt, is het support statement van Microsoft ook niet hoopgevend. Voor mij persoonlijk is onderstaand statement wel rustgevend in de zin dat ik de komende jaren wel vrij zeker kan zijn dat niet ineens allerlei maatwerk projecten uit verleden uit het moeras komen opduiken met de vraag of er 'even' een update gebouwd kan worden...

Executive summary: The Visual Basic team is committed to "It Just Works" compatibility for Visual Basic 6.0 applications on the following supported Windows operating systems:

Windows 11
Windows 10
Windows 8.1
Windows 7 SP1
Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2008 R2

Als de bazen van TS geen software verkopen kan ik me houding van het management wel voorstellen, maar da's wel een treurige boel. In feite staat je professionele CV dan al zeker 15 jaar stil... Is er echt geen ruimte om nieuwe stukken software in .NET Core/Razor o.i.d te doen?

[Cyphax]

Als je je afvraagt wanneer je interfaces zou willen gebruiken, dan denk ik dat je eerder op zoek moet naar kennis over OO development, de basisprincipes uit bijvoorbeeld SOLID, en dat soort informatie. Kennis van de taal is een must om er software in te kunnen schrijven, maar daar kom je niet ver genoeg mee en dat heb je al wel gedaan. Maar software development is meer dan dat, heb je gemerkt.

In eerste instantie ben ik (als docent ict) geneigd voor te stellen om iets als hbo ict in deeltijd te gaan doen. Datgene wat je beschrijft leer je bijvoorbeeld bij ons in principe allemaal wel.

Ik heb zelf .net en c# ook via zelfstudie geleerd (en via collega's met meer ervaring dan ik) maar ik heb die studie daarvoor zelf ook gedaan, al was dat nog voor .net (en het is vandaag de dag ook nog steeds met name in Java, maar dat maakt in dit geval niets uit )

[ Voor 3% gewijzigd door Cyphax op 04-01-2023 21:06 ]

[Ge0force]

farlane schreef op woensdag 4 januari 2023 @ 20:32:
Dat is het makkelijkst denk ik bij je (huidige?) bedrijf: Ik kan me nl niet voorstellen dat men denkt dat doorgaan met VB6 een goed idee is, tenzij die software niet bedrijfskritisch/significant is? Waarom wil men niet de 21e eeuw in?

Met enige ervaring in software bouwen (20 jaar!) kun je met C# als nieuwe taal binnen *zeer* korte tijd produktief zijn, het liefst met een peer die hetzelfde traject doet (of heeft gedaan).

Ik vraag me af wat het *echte* probleem is eigenlijk...

Mijn collega's zijn al jaren bezig met het omzetten van de VB6 pakketten naar .NET hoor. Het "probleem" is dat ik daar nooit bij betrokken ben, met als excuus dat ik de enige ben die kennis heeft van VB6 en de oude pakketten. Een groot deel daarvan draait nog steeds operationeel bij onze klanten, en ik ben in m'n eentje verantwoordelijk voor technische en inhoudelijke updates, support, installaties etc. Daar ben ik full-time mee bezig, waardoor ik gewoonweg niet de kans krijg om aan .NET te beginnen, ook al vraag ik daar voortdurend naar.

Ik betreur het dat mijn bedrijf nooit de moeite heeft gedaan om de workload van die oude pakketten te verdelen onder de nieuwe collega's nadat de andere VB6 ontwikkelaars vertrokken zijn. Vandaar dat ik op zoek ben naar een ander bedrijf.

Ik ben er ook van overtuigd dat ik op korte termijn effectief kan ingezet worden in .NET onder begeleiding van ervaren developers. Helaas lijken de bedrijven die ik gecontacteerd heb daar niet toe bereid zolang ik onvoldoende ervaring heb met .NET.

[Ge0force]

Cyphax schreef op woensdag 4 januari 2023 @ 20:58:
Als je je afvraagt wanneer je interfaces zou willen gebruiken, dan denk ik dat je eerder op zoek moet naar kennis over OO development, de basisprincipes uit bijvoorbeeld SOLID, en dat soort informatie. Kennis van de taal is een must om er software in te kunnen schrijven, maar daar kom je niet ver genoeg mee en dat heb je al wel gedaan. Maar software development is meer dan dat, heb je gemerkt.

In eerste instantie ben ik (als docent ict) geneigd voor te stellen om iets als hbo ict in deeltijd te gaan doen. Datgene wat je beschrijft leer je bijvoorbeeld bij ons in principe allemaal wel.

Ik heb zelf .net en c# ook via zelfstudie geleerd (en via collega's met meer ervaring dan ik) maar ik heb die studie daarvoor zelf ook gedaan, al was dat nog voor .net (en het is vandaag de dag ook nog steeds met name in Java, maar dat maakt in dit geval niets uit )

Ik heb op Pluralsight een aantal cursussen gevonden over OO en SOLID. Ik ga die alvast eens bekijken, bedankt voor de tip!

Ik had ook al gekeken om om effectief les te gaan volgen in .NET, maar deeltijds werken is helaas geen optie in mijn bedrijf. Ik kan wel terecht in avondonderwijs, maar alleen al de cursus voor C# duurt dan twee jaar. Als er geen andere oplossing is dan zal het dat worden, maar ik wou eerst eens kijken of er andere (lees: snellere) opties zijn.

Ik heb gisteren ook de tip gekregen om gewoon zelf een willekeurig project te maken in C# en dan door een ervaren developer een code review te laten doen. Heb je enig idee waar ik hiervoor terecht kan?

[eheijnen]

Laat je niet ontmoedigen en blijf solliciteren.

Kijk imho vooral wat meer naar vacatures van bedrijven die inhouse ontwikkelaars zoeken. Die zijn ook vaak bereid wat meer tijd en moeite te steken in de groei van hun personeel.

Recruiters en/of detacheerders zoeken vaak naar "hapklare brokken".

Ga eventueel eens wat verder in op een afwijzing met een serieuze partij om te kijken of ze je wat meer informatie kunnen aanreiken zodat je beter gepositioneerd raakt in dit gebied.

[Cyphax]

Ge0force schreef op donderdag 5 januari 2023 @ 10:27:
[...]

Ik had ook al gekeken om om effectief les te gaan volgen in .NET, maar deeltijds werken is helaas geen optie in mijn bedrijf. Ik kan wel terecht in avondonderwijs, maar alleen al de cursus voor C# duurt dan twee jaar. Als er geen andere oplossing is dan zal het dat worden, maar ik wou eerst eens kijken of er andere (lees: snellere) opties zijn.

Je zou in minder dan 2 jaar wel genoeg ervaring moeten kunnen opdoen op die punten om door een sollicitatie heen te komen (niet als senior though ), als je er inderdaad aan toe komt. Voordeel van een opleiding is dat het materiaal is toegespitst op het werkveld (op hbo in elk geval), maar het nadeel kan inderdaad zijn dat het langer duurt omdat het mogelijk niet is toegespitst op jouw niveau, maar dat is moeilijk te voorspellen.

Ik heb gisteren ook de tip gekregen om gewoon zelf een willekeurig project te maken in C# en dan door een ervaren developer een code review te laten doen. Heb je enig idee waar ik hiervoor terecht kan?

Je zou kunnen vragen aan een van je collega's of die eens met je mee zou willen kijken. Online heb je misschien wat aan de subreddit voor code reviews (https://www.reddit.com/r/codereview/) of https://codereview.stackexchange.com/

Verder vind ik het kanaal van Nick Chapsas leuk om te volgen, en hij heeft ook een playlist met wat video's die gaan over Software Engineering die je eens kunt bekijken: YouTube: Software Engineering Fundamentals
Hetzelfde geldt voor het kanaal van Tim Corey, ook hij heeft wat video's over basics als SOLID: YouTube: Design Patterns: Single Responsibility Principle Explained Practical...

Dan is er nog de optie van bijdragen aan een bestaand (open source) project. Mocht je een project kennen dat in c# is geschreven, dan kan je kijken of er feature requests zijn waar je iets mee zou kunnen doen. Dan wordt je code ook gereviewed (daar ga ik in elk geval wel vanuit ) en doe je ook gelijk iets praktisch ermee. Bijkomend voordeel is dat je niet afhankelijk bent van je werkgever. Nadeel is dat je het in je eigen tijd zult moeten doen.

[Ge0force]

Hartelijk dank voor jullie feedback!

[farlane]

Ge0force schreef op donderdag 5 januari 2023 @ 10:18:
[...]
Mijn collega's zijn al jaren bezig met het omzetten van de VB6 pakketten naar .NET hoor. Het "probleem" is dat ik daar nooit bij betrokken ben, met als excuus dat ik de enige ben die kennis heeft van VB6 en de oude pakketten.

Toch denk ik dat "je poot stijf houden" tov je werkgever het snelst gaat werken; ik ga er dan voor het gemak van uit dat die jou wil houden als werknemer.

Met het risico om de botterik te zijn: Ik snap *echt* niet dat je werkgever met deze instelling denkt weg te komen. Ik snap ook niet dat jij je er zo lang in mee gaat. Waarom?

[downtime]

farlane schreef op donderdag 5 januari 2023 @ 23:50:
[...]

Toch denk ik dat "je poot stijf houden" tov je werkgever het snelst gaat werken; ik ga er dan voor het gemak van uit dat die jou wil houden als werknemer.

Met het risico om de botterik te zijn: Ik snap *echt* niet dat je werkgever met deze instelling denkt weg te komen. Ik snap ook niet dat jij je er zo lang in mee gaat. Waarom?

100% mee eens. Tijd dat TS bij zijn werkgever eens met de vuist op tafel slaat. Maak er maar een probleem van want zijn carriere staat nu op een dood spoor. Het is zonde om je schaarse vrije tijd te investeren om .NET praktijkervaring op te doen terwijl er gewoon .NET klussen bij zijn werkgever zijn. Ik vrees daarnaast ook dat veel potentiele werkgevers klussen in eigen tijd niet eens als praktijkervaring gaan zien maar als hobby. En TS dus blijven afwijzen voor vacatures.

Voorstel: Eis bij je werkgever dat iemand anders 50% van het VB6 werk oppakt zodat jij 50% van je tijd aan .NET kan besteden. Als tegenprestatie werk jij dan die collega in om die VB6 klussen op te pakken.
Niet alleen kun je daarmee je eigen loopbaan weer op de rails krijgen maar zij voorkomen dat ze straks in de problemen komen als jij naar een andere werkgever vertrekt waar je wel met .NET kunt werken.

[Anoniem: 543328]

Verwijderd

[ Voor 99% gewijzigd door Anoniem: 543328 op 24-10-2023 19:22 ]

[Ge0force]

farlane schreef op donderdag 5 januari 2023 @ 23:50:
[...]
Met het risico om de botterik te zijn: Ik snap *echt* niet dat je werkgever met deze instelling denkt weg te komen. Ik snap ook niet dat jij je er zo lang in mee gaat. Waarom?

Dat is zeker geen onredelijke vraag hoor. De voornaamste reden dat ik nog geen ontslag heb genomen is dat mijn huidige baan praktisch heel aantrekkelijk is: amper 10 minuten van thuis, drie dagen thuiswerk per week, 10 dagen anciënniteitsverlof per jaar, bovengemiddeld nettoloon etc etc. Vooral dat eerste weegt voor mij zwaar door, want de meeste ICT-jobs in mijn provincie zijn in Brussel, en dan ben ik dagelijks minstens twee uur onderweg.

Daarnaast heb ik een jaar of vijf geleden al bij verschillende bedrijven gesolliciteerd wegens aanhoudende problemen met de toenmalige manager. Bij al die bedrijven werd ik geweigerd vanwege mijn gebrek aan kennis van .NET, dus ik had toen al begrepen dat van werk veranderen niet eenvoudig zou worden. Vandaar dat ik nu .NET wil aanleren.

[Ge0force]

Anoniem: 543328 schreef op vrijdag 6 januari 2023 @ 08:24:
[...]

Hoeveel bedrijven heb je al gecontacteerd?

Je schrijft "lijken". Weet je zeker dat het alleen op kennis stukloopt? Heb je altijd om feedback gevraagd?

Is er ook al gesproken over salaris? Ben je bijvoorbeeld bereid om qua salaris een stap achteruit te gaan om het aantrekkelijker te maken voor een bedrijf om in je te investeren?

Ik heb zelf een zestal bedrijven in de buurt aangeschreven, en ben voor de rest zelf gecontacteerd via LinkedIn door recruteringskantoren zoals Cooder. Ondanks het feit dat ik telkens duidelijk aangeef dat ik nog geen praktische ervaring heb met .NET, laten die kantoren mij een volledige procedure doorlopen bij ICT/consultancy bedrijven. Na een praktische test of screening krijg ik dan te horen dat mijn vacature geweigerd wordt omdat ik niet meteen kan ingezet worden wegens onvoldoende kennis van .NET.

Ik ben gerust bereid om nog meer cursussen te volgen, maar ik stel ook vast dat ik tijdens die screenings en tests vragen krijg die eerder toetsen naar ervaring in plaats van gewoonweg basiskennis. Ik krijg dan vragen zoals "welke van onderstaande zijn geldige exceptions in .NET" of "welke van onderstaande blokken code geeft X als resultaat". Het aantal juiste antwoorden ligt tussen 0 en 5. Ik herken dan meestal wel minstens één van de opties uit de cursussen die ik heb gevolgd, maar verlies uiteindelijk punten doordat ik niet ALLE mogelijkheden kan aanduiden.

Bij mijn laatste sollicitatie heb ik de tip gekregen om zelf een applicatie zoals Tetris te schrijven in C#. Ik ben daar gisteren aan begonnen en heb al de nodige classes genoteerd, maar vind het toch moeilijk om in te schatten waarvoor ik aparte classes moet maken en in welke class in bepaalde methods schrijf. Dit lijkt me iets typisch dat komt met de ervaring.

Ik ben ook zeker bereid om minder te verdienen (en dat heb ik ook zo gecommuniceerd), maar ik moet wel mijn rekeningen kunnen betalen. €700 per maand minder verdienen is momenteel geen optie met de hoge energieprijzen.

[ Voor 7% gewijzigd door Ge0force op 06-01-2023 12:28 ]

[Anoniem: 543328]

Verwijderd

[ Voor 114% gewijzigd door Anoniem: 543328 op 24-10-2023 19:22 ]

[downtime]

Anoniem: 543328 schreef op vrijdag 6 januari 2023 @ 13:46:
[...]

Ik weet niet waar je woont

Hij zegt dat Brussel in zijn provincie ligt. Dus vermoedelijk België.

[Anoniem: 543328]

Verwijderd

[ Voor 95% gewijzigd door Anoniem: 543328 op 24-10-2023 19:22 ]

[gorgi_19]

downtime schreef op vrijdag 6 januari 2023 @ 00:21:
Niet alleen kun je daarmee je eigen loopbaan weer op de rails krijgen maar zij voorkomen dat ze straks in de problemen komen als jij naar een andere werkgever vertrekt waar je wel met .NET kunt werken.

Dan moet hij die eerst nog wel kunnen vinden. Zou me niks verbazen als een werkgever inschat / verwacht dat hij in een soort van 'gouden kooi' zit; hij kan vanwege gebrek aan kennis moeilijk elders aan de bak komen en ze willen / kunnen / verwachten dat de topicstarter niet .Net goed onder de knie gaat krijgen. Zou me ook niets verbazen als de overgang onderschat wordt; de overeenkomst tussen VB6 en c# is vrij minimaal.

Wat een risico is voor de topicstarter: er wordt al gewerkt met .Net binnen zijn organisatie, dus best kans dat zijn carrière echt op een dood spoor zit. Sterker, dat bestaande applicaties en klanten ook meer en meer gemigreerd gaan worden en bij hem weggehaald gaan worden.

Recruitmentsbedrijven lijken een moeilijke route. Je verwacht dan dat een bedrijf en de hoofdprijs aan een recruiter betaalt, jou (rekening houdend met je eerdere werkervaring en leeftijd) ook beter dan normaal beloont en investeert in een opleiding of je opleiden.

[ Voor 4% gewijzigd door gorgi_19 op 06-01-2023 15:37 ]

[Josk79]

Wat vervelend dat de werkgever je de kans niet wil geven om deel te nemen aan het .NET team. Dit lijkt me dé manier om erin te groeien. Ik denk dat je het iets harder moet spelen. Wellicht eisen dat je 2 dagen per week volop met .NET aan de gang kan gaan met als argument dat je op de huidige manier geen steek verder zult komen in je carriere. Zo kun je met de nodige begeleiding van de .NET programmeers .NET snel oppakken.

Hoe langer je in VB6 vastgeroest blijft, hoe lastiger het wordt om (in de toekomst) ergens anders aan boord te komen. Als je nu ergens wilt solliciteren zal je toch echt als junior opnieuw moeten beginnen; als je 2 jaar .NET ervaring opdoet bij je huidige werkgever zal je minstens al medior zijn verwacht ik.

Hoe moet het als binnen jullie bedrijf straks alles over is naar .NET? Dan ben je ineens overbodig of blijf je veredelde service-man die de boel mag installeren en eventuele problemen oplossen.

[Ge0force]

Anoniem: 543328 schreef op vrijdag 6 januari 2023 @ 13:46:

Mijn advies (als ex-bureau recruiter met 14 jaar ervaring) solliciteer vooral zelf direct bij bedrijven (dus zonder bureau recruiter).

Dat is prima advies, ik had er zelf nog niet bij stil gestaan dat ik zoveel meer kost via een recruteringsbureau. Ik denk dat ik via een sollicitatiebrief ook mijn enthousiasme kan overbrengen. Ik ga er werk van maken, thanks!

[Ge0force]

downtime schreef op vrijdag 6 januari 2023 @ 14:49:

Hij zegt dat Brussel in zijn provincie ligt. Dus vermoedelijk België.

Ik woon inderdaad in België op 30km van Brussel. Dat had ik er beter bijgezet, sorry

[Ge0force]

Josk79 schreef op vrijdag 6 januari 2023 @ 15:50:
Wat vervelend dat de werkgever je de kans niet wil geven om deel te nemen aan het .NET team. Dit lijkt me dé manier om erin te groeien. Ik denk dat je het iets harder moet spelen. Wellicht eisen dat je 2 dagen per week volop met .NET aan de gang kan gaan met als argument dat je op de huidige manier geen steek verder zult komen in je carriere. Zo kun je met de nodige begeleiding van de .NET programmeers .NET snel oppakken.

Hoe langer je in VB6 vastgeroest blijft, hoe lastiger het wordt om (in de toekomst) ergens anders aan boord te komen. Als je nu ergens wilt solliciteren zal je toch echt als junior opnieuw moeten beginnen; als je 2 jaar .NET ervaring opdoet bij je huidige werkgever zal je minstens al medior zijn verwacht ik.

Hoe moet het als binnen jullie bedrijf straks alles over is naar .NET? Dan ben je ineens overbodig of blijf je veredelde service-man die de boel mag installeren en eventuele problemen oplossen.

Bovenstaande is precies de reden waarom ik na meer dan 20 jaar toch van job wil veranderen. Ik ben halfweg in de 40, het is nu of nooit.

Ik wil en zal het hard spelen bij mijn werkgever, maar wil dan eerst uitzicht hebben op een alternatief. Ik wil nu niet zonder werk vallen.

[eheijnen]

Heb nog eens zitten zoeken en vond dit instituut (er zullen er zeker nog meer zijn).
https://www.groeipunt.be/

Nou geven ze hier geen C# opleiding. Wel geven ze ICT opleidingen, klassikaal en op afstand waaronder ook programmeren in diverse talen.

Ik denk dat het geen kwaad kan om daar eens een gesprek mee te hebben. Kan goed zijn dat je daar goede tips krijgt en/of ze je kunnen doorverwijzen naar andere instituten/scholen/cursussen.

[biomass]

Ge0force schreef op donderdag 5 januari 2023 @ 10:18:
Mijn collega's zijn al jaren bezig met het omzetten van de VB6 pakketten naar .NET hoor. Het "probleem" is dat ik daar nooit bij betrokken ben, met als excuus dat ik de enige ben die kennis heeft van VB6 en de oude pakketten. Een groot deel daarvan draait nog steeds operationeel bij onze klanten, en ik ben in m'n eentje verantwoordelijk voor technische en inhoudelijke updates, support, installaties etc. Daar ben ik full-time mee bezig, waardoor ik gewoonweg niet de kans krijg om aan .NET te beginnen, ook al vraag ik daar voortdurend naar.

Toen ik dit las, kreeg ik commentaar van mijn vrouw, want ik riep hardop "Wat??"
Ik dacht, kun je wel op vakantie dan? Het is toch de in de baas zijn belang dat iedere support engineer in zijn toko alle pakketten kan ondersteunen??

Ik ben zelf ook begonnen met VB6 en langzaam in .NET gegroeid, want geen tijd voor cursus.. Ik snap best dat je al zo lang in deze situatie zit want je woon-werk afstand is fantastisch.

Ge0force schreef op vrijdag 6 januari 2023 @ 19:14:
[...]
Bovenstaande is precies de reden waarom ik na meer dan 20 jaar toch van job wil veranderen. Ik ben halfweg in de 40, het is nu of nooit.

Ik wil en zal het hard spelen bij mijn werkgever, maar wil dan eerst uitzicht hebben op een alternatief. Ik wil nu niet zonder werk vallen.

Hoeveel nieuwe functionaliteit bak je maandelijks in VB6? Gebruik je in die codebase ook interfaces en classes? Als je wilt overstappen naar een ander bedrijf zou dat een van mijn vragen zijn aan iemand zoals jij Want als je 20 jaar software engineering ervaring hebt, is een basiscursus .NET ook eigenlijk niet spannend, een werkgever zal gewoon gereserveerd zijn omdat je nog niet veel parate kennis hebt van C# en de frameworks. Bedenk ook dat er standaard pakketten zijn die met .Net code aangepast kunnen worden, je hoeft niet perse als Full Stack C# developer te beginnen.

Ik denk dat je gewoon zelf voor het alternatief moet zorgen. Je kunt voorstellen om je VB6 projecten om te zetten in de baas zijn tijd, er zijn tal van redenen om van VB6 weg te migreren maar een van de redenen is dan dat je straks ook weg kan als je weg wilt, of dat de vakantieplanning met je collega's gewoon eenvoudiger word als je blijft(of zoals hierboven wat negatiever gezegd, weg moet als je weg kan).
Als het niet in de baas zijn tijd mag, dan moet je je baas toch eens vragen waarom? En dan kun je altijd nog beslissen om in je eigen tijd .NET versies te gaan bouwen van de projecten van je werk. Die route is wel lastiger want je kan dan niet claimen dat het bij klanten draait, je kunt het eigenlijk alleen maar laten reviewen bij het bedrijf waar je solliciteert.

Succes!

[Lethalis]

Ge0force schreef op woensdag 4 januari 2023 @ 12:43:
Ik werk al meer dan 20 jaar als developer in hetzelfde bedrijf, maar heb daar enkel gewerkt met het sterk verouderde Visual Basic 6.

Je had 15 jaar geleden al moeten overstappen naar iets anders.

Vanuit jouw positie zou ik zeggen: blijf het proberen met solliciteren. Bij mijn werkgever hebben we bijvoorbeeld nog steeds een VB6 project draaien bij een paar honderd klanten, maar de developer die daar af en toe aan werkt, doet ook het grootste deel van zijn tijd .NET.

Al moet ik toegeven dat ook wij huiverig zouden zijn om iemand aan te nemen die alleen maar VB6 heeft gedaan.

Anyways... blijf cursussen volgen online, bouw nieuwe projecten in jouw eigen tijd... deel ze eventueel op github, en bouw een portfolio op.

Uiteindelijk, als je genoeg basiskennis hebt opgedaan, durft misschien iemand het risico te nemen om jou een kans te geven.

Maar alleen VB6 ervaring hebben in 2023... oei oei oei.

PS
Als je genoeg .NET kennis hebt, kun je jouw werkervaring ook anders omschrijven... meer gericht om wát je gemaakt hebt ipv hoe je dat gedaan hebt. Software engineering is meer dan een taaltje gebruiken.

Maar eerst meer .NET leren!

[Lethalis]

Ge0force schreef op woensdag 4 januari 2023 @ 12:43:
Ik weet bijvoorbeeld heel goed wat Interfaces zijn en hoe je ze moet gebruiken, maar niet wanneer je ze al dan niet moet gebruiken.

Wanneer je een abstractie nodig hebt

Het is sowieso 1 van de best practices van SOLID:

Wikipedia: SOLID

"men zou afhankelijk moeten zijn van abstracties, niet van concrete implementaties"

Kortom: zodat je makkelijk een implementatie kunt uitwisselen voor een andere en code ook eenvoudiger kunt testen.

In nieuwere frameworks werk je dan ook vaak met een IoC container. Bijvoorbeeld in ASP.NET Core is het gebruikelijk dat je je services op 1 plek (program.cs of startup.cs) aan elkaar knoopt en dat alles voor de rest alleen maar afhankelijk is van interfaces.

Een andere best practice van SOLID is interface segregation:

"veel client-specifieke interfaces zijn beter dan één algemene interface"

C# kan in tegenstelling tot C++ geen multiple inheritance, maar je kunt wel meerdere interfaces implementeren in 1 class. Hoe specifieker en kleiner de interfaces zijn, des te minder afhankelijkheden krijgen de classes die ermee moeten werken... en des te kleiner wordt het risico dat je ze voor iets moet aanpassen.

Want dat is het thema... "software-entiteiten … moeten open zijn voor uitbreiding, maar gesloten voor wijziging". Je wil geen spaghetti code waar elke wijziging leidt tot een drama in de code. Goed gebruik van interfaces helpt dat te voorkomen.

Ik gebruik ze ook vaak simpelweg tussen de verschillende lagen (horizontaal) of zuilen (verticaal) van onze software om duidelijk een scheiding aan te brengen qua verantwoordelijkheid. Dit helpt ook weer om spaghetti te voorkomen.

Het liefst ook door code in verschillende assemblies onder te brengen, zodat je ook de verleiding weerstaat om afkortingen te nemen als je onder tijdsdruk staat.

Maar ja. Inlezen in best practices als SOLID kan geen kwaad iig. Dat betekent niet dat je meteen alles per se op die manier moet doen, maar het geeft jou de tools om complexere problemen structureel op te lossen... hopelijk zonder dat het spaghetti code wordt.

Op mijn werk genereren we bijvoorbeeld reports. Vroeger was dat 1 grote ball of mud qua code... ik heb dat volledig opgesplitst in een class die de query opbouwt en de data ophaalt, een class die de documenten genereert (in classes, ons eigen PrintDocument) en op het eind pas de renderers die er daadwerkelijk een PDF van maken of direct printen.

Vooral die laatste stap gaat bij mij via een interface, want daarvoor heb ik externe libraries nodig met meerdere implementaties. Dus ik heb een DevExpress renderer, een ComponentOne renderer, etc.

Moet het morgen op een andere manier? Geen probleem, bouw ik er even een renderer bij en klaar.

Vroeger kon de hele code dan overhoop. Tot zover even een praktisch voorbeeld

Bij mij is het al gauw: kan deze implementatie in de toekomst veranderen? Interface!

[Lethalis]

Ge0force schreef op donderdag 5 januari 2023 @ 10:18:
[...]


Mijn collega's zijn al jaren bezig met het omzetten van de VB6 pakketten naar .NET hoor. Het "probleem" is dat ik daar nooit bij betrokken ben, met als excuus dat ik de enige ben die kennis heeft van VB6 en de oude pakketten. Een groot deel daarvan draait nog steeds operationeel bij onze klanten, en ik ben in m'n eentje verantwoordelijk voor technische en inhoudelijke updates, support, installaties etc. Daar ben ik full-time mee bezig, waardoor ik gewoonweg niet de kans krijg om aan .NET te beginnen, ook al vraag ik daar voortdurend naar.

Interop Forms toolkit.

Zodra je iets nieuws in VB6 moet maken, bouw het als .NET assembly in laadt hem in het VB6 programma.

Hebben jullie daar al naar gekeken?

Zonde om nu nog nieuwe VB6 code te produceren iig.

En ik maar denken dat het bij mijn werkgever hopeloos is dat we nog steeds veel Windows Forms development doen. Maar dat is iig .NET Het is alleen jammer dat het er niet uitziet op mijn 4K monitor, waardoor ik echt geconfronteerd word met "dit is oude meuk". Visual Studio met no scaling opstarten zodat je een form kunt wijzigen in de designer... brrr.

Gelukkig doe ik ook genoeg web development om niet depressief te worden (Angular, .NET 6 api's, Docker, etc).

Uiteindelijk gaan we denk ik ook de nieuwe webview van Edge maar gebruiken om ook nieuwe schermen in de bestaande software naar het web te brengen. Mooi is anders, maar je moet ergens beginnen.

Er is immers geen duidelijk pad vanuit Microsoft. Toekomst van WPF is twijfelachtig en alles dat daarna uitkwam had zo'n korte levensduur dat je nog beter een web app kunt bouwen.

[ Voor 30% gewijzigd door Lethalis op 08-01-2023 12:27 ]

[biomass]

Interop Forms toolkit zou ik weg van blijven. Het was toen al een lapmiddel in om geen volledige conversie te hoeven doen en dat is het nu al helemaal. En als je het serieus wilt gebruiken in iets als ActiveX containers, dan houden de bugs en beperkingen je wel tegen. Been there, done that.

[Lethalis]

biomass schreef op zondag 8 januari 2023 @ 21:24:
Interop Forms toolkit zou ik weg van blijven. Het was toen al een lapmiddel in om geen volledige conversie te hoeven doen en dat is het nu al helemaal. En als je het serieus wilt gebruiken in iets als ActiveX containers, dan houden de bugs en beperkingen je wel tegen. Been there, done that.

Op mijn werk wordt het gebruikt om de externe koppelingen in het oude VB6 pakket te onderhouden. Die koppelingen zijn namelijk het enige dat nog regelmatig verandert, de rest van het pakket gebeurt niet veel meer aan.

Door die koppelingen in .NET te doen, houden wij ons oude pakket in de lucht terwijl we bijna geen VB6 meer doen

We gebruiken diezelfde koppelingen ook in ons nieuwere pakket. Maar goed, mijn collega - de laatste die af en toe nog VB6 doet - is er heel blij mee... want hij hoeft nu effectief maar een paar weken per jaar te klooien met VB6. Vroeger was dat een paar maanden.

Rest van het jaar doet hij ook gewoon .NET.

Dat wij nog überhaupt VB6 hebben, heeft een commerciële reden overigens... ons nieuwere .NET pakket is duurder in de markt gezet (als een Pro versie). Ook om de gigantische investering daarin terug te verdienen.

Ondanks dat veel klanten de stap hebben genomen, zijn er ook nog behoorlijk wat klanten die het te duur vinden.

Uiteraard hebben we ook over een lite versie van het nieuwe pakket nagedacht... maar dan is de angst weer dat mensen die nu wel de volle mep betalen ook die versie willen

Dus conclusie was om het oude pakket maar in de lucht te houden, maar wel door zo min mogelijk VB6 te moeten doen. En daarbij is die Interop Forms toolkit wel een redding geweest.

De klanten die het oude pakket gebruiken zijn meestal ook niet de meest veeleisende, dus dat scheelt. En zodra 1 van die klanten wel begint dan krijgt die uiteraard te horen dat die functionaliteit in het nieuwe pakket zit.

Soms werkt dat, soms niet.

Maar ja, wij kunnen ook niet eeuwig VB6 supporten. Als die ene collega van mij omvalt, wordt het al tricky... want voor de rest heeft niemand in 15 jaar VB6 aangeraakt hier. Niet eens met een lange stok

[biomass]

Ik zeg ook niet dat een nutteloze tool is, voor bepaalde toepassingen kom je dan in gebied waar de toolkit niet alle functionaliteit bied die je nodig hebt voor het bereiken van je doelen. Bij mij was dat doel toen het maken van ActiveX controls voor een VBA-enabled applicatie (niet van Microsoft zelf). Als je nu .NET wilt leren zou ik die Toolkit er pas bij pakken als je weet dat je er niet onderuit kan om het te gebruiken en je C# al redelijk onder de knie hebt. Anders kan het best een frustrerend traject worden

[Ge0force]

biomass schreef op zaterdag 7 januari 2023 @ 23:52:
Hoeveel nieuwe functionaliteit bak je maandelijks in VB6? Gebruik je in die codebase ook interfaces en classes?

Er zitten geen interfaces of classes in onze VB6-projecten. Dat kan blijkbaar wel, maar optimaal is het niet. Ik moet me ook houden aan de richtlijnen die aan het begin van het project gemaakt zijn. Hoe meer ik leer over .NET, hoe meer ik me erger aan die oude code.

De hoeveelheid nieuwe functionaliteit wisselt van tijd tot tijd. Dat gaat van kleine uitbreidingen tot bestaande functionaliteit die volledig herbekeken wordt. Regelmatig zijn er ook "dringende" wijzigingen op vraag van externe partners, bijvoorbeeld als die overstappen naar webservices. Dit is vaak veel werk omdat dit in VB6 niet native ondersteund wordt.

[Lethalis]

Ge0force schreef op maandag 9 januari 2023 @ 13:41:
[...]
De hoeveelheid nieuwe functionaliteit wisselt van tijd tot tijd. Dat gaat van kleine uitbreidingen tot bestaande functionaliteit die volledig herbekeken wordt. Regelmatig zijn er ook "dringende" wijzigingen op vraag van externe partners, bijvoorbeeld als die overstappen naar webservices. Dit is vaak veel werk omdat dit in VB6 niet native ondersteund wordt.

En daarom moet je dat ook gewoon in .NET doen en via Interop aanroepen.

Complete tijdverspilling om het aanroepen van webservices in VB6 te gaan lopen doen. Meestal zodra iets veel tijd (en dus geld) gaat kosten, heb je een zeer sterk argument om het anders te doen

Sowieso vraag ik me af hoe goed dat nog lukt met VB6 als je met partners te maken hebt die security hoog in het vaandel hebben staan. VB6 en TLS 1.3 seems like a lot of fun.

[Ge0force]

Lethalis schreef op zondag 8 januari 2023 @ 11:32:
Wanneer je een abstractie nodig hebt

Het is sowieso 1 van de best practices van SOLID

Ik heb afgelopen weekend een online cursus over SOLID gevolgd en nu is me een en ander duidelijk geworden. Bedankt voor de tip!

Ik ben ook begonnen met een eenvoudige C# applicatie te maken. Ik heb gekozen voor Tetris omdat die game qua structuur heel logisch in elkaar zit en ik (voor mij nieuwe) technieken zoals generics en abstractie eenvoudig kan toepassen. Het is regelmatig wat zoeken en code verplaatsen, maar we geraken er wel.

[Ge0force]

Lethalis schreef op maandag 9 januari 2023 @ 13:49:
[...]
Sowieso vraag ik me af hoe goed dat nog lukt met VB6 als je met partners te maken hebt die security hoog in het vaandel hebben staan. VB6 en TLS 1.3 seems like a lot of fun.

TLS 1.3 zit gelukkig ingebouwd in de HTTP-libraries van Windows die ik vanuit VB6 kan aanspreken. sFTP was een grotere uitdaging en over oAuth 2.0 wil ik het liever niet hebben.

Interop kende ik niet maar ga ik zeker eens bekijken. Bij technische wijzigingen is er vaak een grote tijdsdruk, waardoor ik niet de kans heb om uitgebreid met nieuwe dingen te experimenteren. Het gevolg is dan ook steeds dat er een "duct tape" oplossing wordt uitgewerkt.

Ik heb alleszins daarstraks nog maar eens een gesprek gehad met de manager over mijn huidige situatie. Hij was precies wel aangenaam verrast dat ik C# al in m'n vrije tijd ingestudeerd heb. Hij heeft me nu beloofd dat ik volgend kwartaal mee mag instappen in een nieuw .NET project. We zien wel of het er deze keer daadwerkelijk van komt. Ik blijf in elk geval verder trainen en projectjes maken.

[eheijnen]

@Ge0force
Welke SOLID cursus was dat?

[Lethalis]

Ge0force schreef op maandag 9 januari 2023 @ 13:51:
[...]
Ik heb afgelopen weekend een online cursus over SOLID gevolgd en nu is me een en ander duidelijk geworden. Bedankt voor de tip!

Mooi dat je een cursus over SOLID hebt bekeken

Een andere tip die ik kan geven, is dat je jezelf bekend maakt met architecturele patterns. Met name de veelgebruikte, zoals MVC (Model View Controller), MVVM (Model View ViewModel) en eventueel MVP (Model View Presenter).

Het idee is dat dit jou helpt om wat scheiding in jouw programma's aan te brengen. Dat elk onderdeel zijn eigen verantwoordelijkheid heeft en daarna hopelijk ook eenvoudiger te testen is.

In VB6 is dit wat lastiger, maar in .NET wil je graag een scheiding tussen de user interface (presentation layer) en de achterliggende code (business layer) aanbrengen (layered architecture). De bovengenoemde patterns helpen daarbij en verzorgen vaak op de 1 of andere manier de communicatie tussen het business model en de view (d.m.v. een controller, een view model, of een presenter).

Zelf ben ik bijvoorbeeld een beetje aan het spelen met WPF momenteel, en daarbij is het gangbaar om MVVM te volgen. De view (in dit geval de xaml die mijn user interface beschrijft) is door middel van data bindings gekoppeld aan een view model. Als er iets in mijn view model verandert, dan wordt de user interface bijgewerkt en andersom worden events en actions als command's aan mijn view model doorgegeven.

Het view model werkt op de achtergrond dan weer met het model (de business of domain layer) om daadwerkelijk dingen uit te voeren.

Maar alles heeft dus zijn eigen verantwoordelijkheid. Het is niet 1 grote brei aan code die allemaal bij een bepaald form hoort ofzo (vaak de code behind genoemd).

Anyways... als je SOLID leuk vindt, vind je misschien ook de klassieke Gang of Four patterns wel interessant. Het kan bij een sollicitatie wel handig zijn als je weet wat een Singleton is, een Iterator, een Observer of bijvoorbeeld een Adapter.

Begrijpen hoe iterators werken, maakt het ook een stuk eenvoudiger om te snappen hoe LINQ bijvoorbeeld werkt (met alle IEnumerable<T> extension methods). En observers vormen de basis van events. Het zijn de achterliggende patterns die aan de basis van een hoop dingen liggen.

[ Voor 5% gewijzigd door Lethalis op 09-01-2023 22:48 ]

[farlane]

Lethalis schreef op maandag 9 januari 2023 @ 22:27:
In VB6 is dit wat lastiger, maar in .NET wil je graag een scheiding tussen de user interface (presentation layer) en de achterliggende code (business layer) aanbrengen (layered architecture).

Dat is in VB6 ook simpel te doen. VB6 is niet hip, maar er is prima gestructureerde code mee te schrijven.

Er is immers geen duidelijk pad vanuit Microsoft. Toekomst van WPF is twijfelachtig en alles dat daarna uitkwam had zo'n korte levensduur dat je nog beter een web app kunt bouwen.

De enige stabiele UI toolkit voor .NET is ....... Windows Forms!

[Lethalis]

farlane schreef op maandag 9 januari 2023 @ 23:27:
[...]
De enige stabiele UI toolkit voor .NET is ....... Windows Forms!

Het is alleen jammer dat het niet meegroeit met de tijd. Veel succes met het mergen van designer files. Sowieso doet die designer maar wat. Bewaar je iets 2x, staat het op een andere plek. Hopeloos.

Enige voordeel van Windows Forms is de RAD manier van werken. Ik heb afgelopen week 3 schermen voor een bestaand pakket in elkaar geflanst waar ik met een moderne oplossing als Angular 2x zo niet 3x zolang over had gedaan.

Alleen jammer dat ik Visual Studio met /noscale moet opstarten om op mijn 4K monitor überhaupt de Windows Forms designer te kunnen gebruiken.

Nu ik voor een hobby project met WPF bezig ben, is dat wel een verademing. Maar goed, daar heb ik op mijn werk niks aan... ERP pakket met ~200 forms in *tromgeroffel* Windows Forms. Beetje opgeleukt met DevExpress.

Ik heb ook genoeg werk aan portals en webkoppelingen er omheen (Angular, .NET 6), maar de core business blijft die Windows Forms applicatie.

En ik wring mij in allerlei bochten om het met moderne tools te gebruiken. Probeer maar eens aan een team - dat gewend is om een Form te locken voordat ze het wijzigen - uit te leggen dat dit niet bij git past... maar dat hun werk ook niet eenvoudig te mergen is.

Het is alsof je een Lada elektrisch wil laten rijden.

Toch wil ik dolgraag naar git met het project.

Anyways... offtopic En ik moet gaan slapen

[Ge0force]

eheijnen schreef op maandag 9 januari 2023 @ 14:33:
@Ge0force
Welke SOLID cursus was dat?

Ik ben C# aan 't leren via Pluralsight. De eerste 10 uren zijn gratis, daarna €47 per maand.

https://www.pluralsight.com/courses/csharp-solid-principles

[eheijnen]

@Ge0force
Misschien een beetje overbodig ondertussen...

Ondanks dat er een oplossing is in je huidige situatie, blijf leren ook als dat na de tijd is.
Hiermee houd of versterk je je eigen positie en geeft je je meer kansen. Je maakt je daar zelf ook aantrekkelijk mee op de arbeidsmarkt en je huidige werkgever zal dat ook zien en misschien wel wat meer moeite doen om zijn werknemers aan te houden. (een mes dat aan allebei de kanten snijdt).

Weet niet hoe dat bij jullie zit maar hier kun je een gedeelte van de scholingskosten van de belasting aftrekken...

[Sito]

Josk79 schreef op vrijdag 6 januari 2023 @ 15:50:
Wellicht eisen dat je 2 dagen per week volop met .NET aan de gang kan gaan met als argument dat je op de huidige manier geen steek verder zult komen in je carriere. Zo kun je met de nodige begeleiding van de .NET programmeers .NET snel oppakken.

Hoe langer je in VB6 vastgeroest blijft, hoe lastiger het wordt om (in de toekomst) ergens anders aan boord te komen.

Wat mij betreft kan je het nóg harder spelen: ik wil 2 dagen per week meelopen met de .NET jongens, anders ga ik zoeken naar iets anders. Volgens mij zijn mensen die nu nog VB6 willen doen heel erg schaars, en zonder jou valt de hele bedrijfsvoering in het water.

Natuurlijk komt zoiets wel met enige risico’s en is het goed om een back-up te hebben voor als ze je echt laten gaan, maar je mag best hard optreden tegen een werkgever die in feite een groot deel van je carrière je heeft tegengehouden.

[eheijnen]

Sito schreef op dinsdag 10 januari 2023 @ 09:57:
[...]
Wat mij betreft kan je het nóg harder spelen: ik wil 2 dagen per week meelopen met de .NET jongens, anders ga ik zoeken naar iets anders.
...

Ik denk dat je met zo'n houding niet ver komt op de lange termijn bij een werkgever. Ik zou me in ieder geval niet onder druk laten zetten en al helemaal niet op zo'n manier.

En als je dat dan toch zou doen dan moet je wel zorgen dat je "een stel nieuwe schoenen hebt" voor als puntje bij paaltje komt. En dat was nou net waarom hij deze thread heeft gestart...

Daarnaast is het ook goed dat hij zelf het initiatief blijft nemen en zorgt dat hij zich verder ontwikkelt / up-to-date blijft en zich actiever opstelt naar de markt toe.

Misschien komt hij daardoor in de toekomst een baan tegen die nog veel beter is.

[ Voor 12% gewijzigd door eheijnen op 10-01-2023 10:52 ]

[Fiets]

Ik zal al SOLID langs komen. Het ligt er een beetje aan hoe diep je er in duikt, maar anders is IDEALS ook nog handig om te bekijken.

https://alibenmessaoud.co...ervice-Design-Principles/

[Haan]

SOLID, KISS, YAGNI, je kunt een heel boek vullen met die afkortingen

[Lethalis]

eheijnen schreef op dinsdag 10 januari 2023 @ 09:46:
Weet niet hoe dat bij jullie zit maar hier kun je een gedeelte van de scholingskosten van de belasting aftrekken...

In Nederland is het tegenwoordig niet meer zo'n feest. Je hebt een STAP budget eenmalig, als je op tijd bent...

Vroeger kon je het inderdaad van de belasting aftrekken.

[Lethalis]

Haan schreef op dinsdag 10 januari 2023 @ 11:15:
SOLID, KISS, YAGNI, je kunt een heel boek vullen met die afkortingen

KISS en YAGNI zijn ook wel leuke dingen om in het achterhoofd te houden

Meestal als je net allemaal nieuwe design patterns etc hebt geleerd, ben je namelijk geneigd om ze ook toe te passen... zelfs als het niet nodig is. Ik kom soms nog code van mezelf tegen waar ik spijt van heb Nog net niet van het type HelloWordService die via een Factory Hello World ophaalt zeg maar

[ Voor 17% gewijzigd door Lethalis op 10-01-2023 11:46 ]

[CodeCaster]

Haan schreef op dinsdag 10 januari 2023 @ 11:15:
SOLID, KISS, YAGNI, je kunt een heel boek vullen met die afkortingen

My IDEALS: you ain't gonna need a microservice-oriented architecture with a document-driven, web-scale database while connecting to the blockchain in search of a problem that you can solve with your Swiss pocket axe.

Face it: 75% van de developers op de markt is gewoon veredelde CRM/ERP-systemen aan het schrijven, en produceert daarbij ononderhoudbare, ontestbare, ondeploybare code, en verdient daar veel te veel mee.

Maar ontopic, in mijn ervaring (13 jaar back-end/desktop .NET en wat Delphi/PHP tussendoor, voornamelijk aan veredelde CRM/ERP-systemen werkend): je leert alleen van in grotere, diverse teams werken met mensen die veel meer weten dan jij én tijd en zin hebben om jou op een normale manier te begeleiden. Met zelfstudie ontwikkel je een blinde vlek.

Of je moet een goede autodidact zijn, maar dan was dit topic er niet geweest. Dus eis gewoon dat je werkgever in jou investeert, want weg ga je toch wel.

[ Voor 30% gewijzigd door CodeCaster op 10-01-2023 11:50 ]

[Lethalis]

CodeCaster schreef op dinsdag 10 januari 2023 @ 11:44:
[...]
Face it: 75% van de developers op de markt is gewoon veredelde CRM-systemen aan het schrijven, en produceert daarbij ononderhoudbare, ontestbare, ondeploybare code, en verdient daar veel te veel mee.

Mja, een groot deel van de marktwaarde zit hem ook niet in de technische skills...

Als ik mezelf met mijn directe collega's vergelijk, ben ik technisch gezien een "beter opgeleide" developer, omdat ik mij veel meer in de concepten erachter heb verdiept. Maar verdienen zij vaak meer geld, omdat ze betere social skills hebben, beter in staat zijn om wensen van klanten naar een technische oplossing te vertalen (omdat ze beter in staat zijn zich in de klant te verplaatsen, en ermee te sparren), etc.

Of simpelweg meer zelfvertrouwen hebben en dat uitstralen.

Kan ik nog zo mooie code produceren, maar eigenlijk boeit dat niemand.

[ Voor 4% gewijzigd door Lethalis op 10-01-2023 11:52 ]

[Kalentum]

De kans dat kennis van Visual Basic 6 over een aantal jaar zo schaars en gewild is dat je financieel binnen loopt is niet zo groot neem ik aan?

kwam dit tegen... uit 2012
https://jamessummerlin.co...-0-the-cobol-of-our-time/

[ Voor 27% gewijzigd door Kalentum op 10-01-2023 12:37 ]

[Haan]

Kalentum schreef op dinsdag 10 januari 2023 @ 12:07:
De kans dat kennis van Visual Basic 6 over een aantal jaar zo schaars en gewild is dat je financieel binnen loopt is niet zo groot neem ik aan?

Dan nog moet je er maar net zin in hebben om tot je pensioen aan oude meuk te moeten werken

[Ge0force]

Haan schreef op dinsdag 10 januari 2023 @ 12:36:
Dan nog moet je er maar net zin in hebben om tot je pensioen aan oude meuk te moeten werken

Daar bedank ik vriendelijk voor

[farlane]

Kalentum schreef op dinsdag 10 januari 2023 @ 12:07:
kwam dit tegen... uit 2012
https://jamessummerlin.co...-0-the-cobol-of-our-time/

Indeed, VB .Net is right on par with other languages such as C++, Java, and C#

Something tells me that in the year 2020, VB6 will still be here.

Nou ja, daar heeft ie dan wel weer gelijk in...

[Anoniem: 543328]

Verwijderd

[ Voor 150% gewijzigd door Anoniem: 543328 op 24-10-2023 19:22 ]

[Stoney3K]

gorgi_19 schreef op vrijdag 6 januari 2023 @ 15:35:
[...]

Wat een risico is voor de topicstarter: er wordt al gewerkt met .Net binnen zijn organisatie, dus best kans dat zijn carrière echt op een dood spoor zit. Sterker, dat bestaande applicaties en klanten ook meer en meer gemigreerd gaan worden en bij hem weggehaald gaan worden.

Aan de andere kant geeft dat TS ook een behoorlijk sterke onderhandelingspositie omdat hij onmisbaar is. Wanneer TS wegvalt of zelf opstapt, dan kan zijn werkgever ineens een hoop operationele systemen niet meer supporten omdat de kennis ontbreekt.

Het is dus ook in het belang van de werkgever dat TS de kans krijgt om zijn kennis over te dragen en de werkgever moet hem dan ook de mogelijkheid kunnen bieden om die projecten te migreren naar een modern platform.

Dat betekent dat TS best een sterke positie aan kan nemen: óf de werkgever zorgt ervoor dat hij kan doorgroeien in het bedrijf, of TS gaat op zoek naar een andere werkgever. Dat kun je ook gebruiken in je salarisonderhandelingen, vooral als je al iets van een aanbod van een andere toko hebt liggen, en een beetje bluffen mag op zo'n moment best.

Ik vermoed dat de werkgever TS alleen geen kansen geeft omdat ze bang zijn dat ie zijn biezen pakt als ie meer ervaring/kennis in .NET heeft en dus makkelijk ergens anders aan de slag kan.

[Ge0force]

Anoniem: 543328 schreef op dinsdag 17 januari 2023 @ 10:24:
@Ge0force Misschien heb je hier nog wat aan:
https://www.linkedin.com/...utm_medium=member_desktop

Bedankt Mark! 👍

[ocf81]

Laat ik even vooraf zeggen dat ik het onderstaande met de beste intenties heb geschreven en absoluut niet vervelend bedoel. De motivatie om toch even de zaken te benoemen zoals ik ze zie na het teruglezen van dit topic is: "Zachte heelmeesters maken stinkende wonden.".

Ge0force schreef op vrijdag 6 januari 2023 @ 12:21:
[...]


Ik heb zelf een zestal bedrijven in de buurt aangeschreven, en ben voor de rest zelf gecontacteerd via LinkedIn door recruteringskantoren zoals Cooder. Ondanks het feit dat ik telkens duidelijk aangeef dat ik nog geen praktische ervaring heb met .NET, laten die kantoren mij een volledige procedure doorlopen bij ICT/consultancy bedrijven. Na een praktische test of screening krijg ik dan te horen dat mijn vacature geweigerd wordt omdat ik niet meteen kan ingezet worden wegens onvoldoende kennis van .NET.

Ik ben gerust bereid om nog meer cursussen te volgen, maar ik stel ook vast dat ik tijdens die screenings en tests vragen krijg die eerder toetsen naar ervaring in plaats van gewoonweg basiskennis. Ik krijg dan vragen zoals "welke van onderstaande zijn geldige exceptions in .NET" of "welke van onderstaande blokken code geeft X als resultaat". Het aantal juiste antwoorden ligt tussen 0 en 5. Ik herken dan meestal wel minstens één van de opties uit de cursussen die ik heb gevolgd, maar verlies uiteindelijk punten doordat ik niet ALLE mogelijkheden kan aanduiden.

Ik denk dat je eerst veel meer ervaring op moet doen met .Net voordat je succes gaat hebben bij een sollicitatie. Vooral omdat je met 20 jaar ervaring waarschijnlijk niet meer op een junior niveau wordt ingeschat, terwijl je nu wel op dat niveau werkt als het om .Net specifieke zaken gaat.

Ge0force schreef op vrijdag 6 januari 2023 @ 12:21:
Ik ben ook zeker bereid om minder te verdienen (en dat heb ik ook zo gecommuniceerd), maar ik moet wel mijn rekeningen kunnen betalen. €700 per maand minder verdienen is momenteel geen optie met de hoge energieprijzen.

Als dat financieel niet kan zou ik nog even door gaan met oefenen in je eigen tijd, voor zo lang dat kan. Kijk eens vanuit het perspectief van een bedrijf: Wat bied iemand die 20 jaar heeft stilgestaan als het om eigenschappen als initiatief tonen, leergierigheid en vermogen om vernieuwing toe te voegen aan een bedrijf gaat? Sinds de introductie van Core verandert .Net elk jaar toch wel aanzienlijk. (oké en for-loop en een if-statement gaan niet zo snel anders worden, maar heel veel randzaken zijn als de waan van de dag in .Net) Als jij niet meebeweegt zit je na 2-3 jaar weer in hetzelfde schuitje, ondanks dat je met .Net bezig bent. Een project op je werk zal niet zo snel een andere versie van .Net gaan gebruiken, maar de wereld buiten raast door.

Ge0force schreef op vrijdag 6 januari 2023 @ 12:21:
Bij mijn laatste sollicitatie heb ik de tip gekregen om zelf een applicatie zoals Tetris te schrijven in C#. Ik ben daar gisteren aan begonnen en heb al de nodige classes genoteerd, maar vind het toch moeilijk om in te schatten waarvoor ik aparte classes moet maken en in welke class in bepaalde methods schrijf. Dit lijkt me iets typisch dat komt met de ervaring.

Dit lijkt me inderdaad een goed advies. Echt goed SOLID toepassen is iets dat zowel theoretisch als praktisch moet worden bestudeerd. Dit gaat echt om een stuk basiskennis omtrent OO programmeren. Wellicht is het ook goed om kennis van design patterns op te doen, als je daar nog geen kennis van hebt. Dat is namelijk het meest praktische handvat als het om de indeling van code gaat. (maar ook weten wanneer de inzet van een DP wel of niet handig is) Verder zijn er natuurlijk een aantal bibliotheken en .Net specifieke zaken die je op je duimpje moet kennen om aantrekkelijk te zijn voor een werkgever.

Stoney3K schreef op dinsdag 17 januari 2023 @ 18:09:
[...]
Aan de andere kant geeft dat TS ook een behoorlijk sterke onderhandelingspositie omdat hij onmisbaar is. Wanneer TS wegvalt of zelf opstapt, dan kan zijn werkgever ineens een hoop operationele systemen niet meer supporten omdat de kennis ontbreekt.

Het is dus ook in het belang van de werkgever dat TS de kans krijgt om zijn kennis over te dragen en de werkgever moet hem dan ook de mogelijkheid kunnen bieden om die projecten te migreren naar een modern platform.

Dat betekent dat TS best een sterke positie aan kan nemen: óf de werkgever zorgt ervoor dat hij kan doorgroeien in het bedrijf, of TS gaat op zoek naar een andere werkgever. Dat kun je ook gebruiken in je salarisonderhandelingen, vooral als je al iets van een aanbod van een andere toko hebt liggen, en een beetje bluffen mag op zo'n moment best.

Ik vermoed dat de werkgever TS alleen geen kansen geeft omdat ze bang zijn dat ie zijn biezen pakt als ie meer ervaring/kennis in .NET heeft en dus makkelijk ergens anders aan de slag kan.

Op zich terecht dat je zegt dat TS dus ook .Net moet gaan doen. En daar heb je ook gelijk in. Maar ik zou niet zo snel uitgaan van een sterke onderhandelingspositie of de bereidwilligheid van de werkgever om daar in te gaan investeren. Er is nu iemand nodig om dit klusje te doen... tot dat het niet meer nodig is. TS geeft al aan dat de codebase overgezet wordt naar .Net, maar om de een of andere reden mag TS daar niet aan meedoen. Zijn collega's kunnen VB6 lezen, dus het lijkt me een sterk verhaal dat niemand het zou kunnen oppakken.

De vraag die bij mij blijft opkomen is: "Wat is nu de echte reden dat TS geen .Net mag doen?".

[Lethalis]

ocf81 schreef op woensdag 18 januari 2023 @ 12:27:
De vraag die bij mij blijft opkomen is: "Wat is nu de echte reden dat TS geen .Net mag doen?".

Ik schrijf dit uiteraard ook met de beste bedoelingen naar @Ge0force toe, maar mijn inschatting is simpelweg dat hij het niet uit zichzelf heeft opgepakt.

Het zou compleet onmogelijk geweest zijn om mij de afgelopen 20 jaar VB6 te laten doen. Dat heeft niks met "niet mogen" te maken. Ik ben veel te nieuwsgierig naar allerlei dingen, pak vaak uit mezelf nieuwe dingen op, ook in mijn eigen tijd... en als het verschil tussen wat ik kan en wat ik dagelijks doe te groot wordt, dan klapt de boel simpelweg uit elkaar.

Dat @Ge0force zolang VB6 heeft gedaan, komt dus ook deels omdat hij dat blijkbaar kan (zolang daarmee aanmodderen zonder serieus in opstand te komen).

Hoe dan ook is het goed dat hij nu wél nieuwe dingen oppakt en hopelijk blijft hij dat ook doen. Op termijn zal dat zijn situatie sterk verbeteren.

[Ge0force]

Mijn eerste C# project Tetris is inmiddels bijna afgerond. Er ontbreken nog een paar features zoals een preview van de volgende shape, score, toename in snelheid etc maar de basis is er.

Ik vind het zelf wel moeilijk om te oordelen of mijn code voldoet. Vandaar mijn vraag of iemand zin en tijd heeft om mijn code kritisch te bekijken en feedback te geven? Het is zeker niet nodig om elke regel code te controleren, maar gewoon een check of deze voldoet aan de "best practices" en SOLID zou een enorme hulp zijn. Je kan mijn Tetris terugvinden op github:

https://github.com/Ge0force/Tetris

Ik heb zelf twijfels over het volgende:

- Interfaces/abstractie: ik gebruik abstractie enkel voor de verschillende vormen van blokken. Zijn er andere plaatsen in mijn code waar ik abstractie en/of interfaces had moeten toepassen ipv "new" te gebruiken?

- Namespaces: zijn er bepaalde richtlijnen over welke classes en interfaces best in een aparte folder/namespace geplaatst worden?

- Method CheckCollissons in class Playfield: ik gebruik 3 nested foreach loops om te bepalen of blokken elkaar overlappen. Had dit niet eenvoudiger gekund via Linq? Ik ben er niet uitgeraakt hoe ik kan filteren op objecten binnen objecten. Ter info: de vorm van een shape is een list van Points, en mijn playfield is een list van shapes.

- Method CheckFullLines in class Playfield: is er geen betere manier om objecten te verwijderen binnen een foreach loop? Had ik die controles ook via Linq kunnen doen?

- Ik krijg diverse warnings "non-nullable property X must contain a non-null value when exiting a constructor". Die properties krijgen bij de start van een game wel een waarde, en zouden niet null mogen zijn op het moment dat ik ze aanspreek dus ik maak ze liever niet nullable. Hoe wordt dit best opgelost?

- Er mag maar één instance van de class playfield bestaan. Maak ik er een singleton van of wordt dat niet meer gebruikt?

Alvast hartelijk dank voor de hulp!

Ge0

P.S. Als je gewoon Tetris wil spelen dan mag je de code natuurlijk ook clonen

[ Voor 5% gewijzigd door Ge0force op 21-01-2023 17:03 ]

[Cyphax]

Ge0force schreef op vrijdag 20 januari 2023 @ 21:45:
Ik vind het zelf wel moeilijk om te oordelen of mijn code voldoet. Vandaar mijn vraag of iemand zin en tijd heeft om mijn code kritisch te bekijken en feedback te geven? Het is zeker niet nodig om elke regel code te controleren, maar gewoon een check of deze voldoet aan de "best practices" en SOLID zou een enorme hulp zijn. Je kan mijn Tetris terugvinden op github:

https://github.com/Ge0force/Tetris

Dat geeft een 404, is ie niet private?

Ik heb zelf twijfels over het volgende:

- Interfaces/abstractie: ik gebruik abstractie enkel voor de verschillende vormen van blokken. Zijn er andere plaatsen in mijn code waar ik abstractie en/of interfaces had moeten toepassen ipv "new" te gebruiken?

Dit kun je wel een beetje meten door unittests te schrijven voor je code. Bij code waar dat dependency inversion principe niet (goed) is toegepast is het lastig om unittests te schrijven. Iets dat wat meer multi-tier is (frontend-backend-database bijvoorbeeld) leent zich er beter voor denk ik. Dat is meestal wel de context die wij gebruiken bij opdrachten voor studenten (en externe opdrachtgevers trouwens ook).

Het kan ook zijn dat je aanpak niet klopt. Ben je nou begonnen met code schrijven of heb je ergens eerst een model gemaakt? Dat laatste is misschien wel een goed idee. Je bent daar al bezig met vragen omtrent wat je wel en niet abstraheert, en hoe de relatie ligt tussen alle dependencies enzo.

[ Voor 10% gewijzigd door Cyphax op 20-01-2023 22:19 ]

[Ge0force]

Cyphax schreef op vrijdag 20 januari 2023 @ 22:13:
[...]

Dat geeft een 404, is ie niet private?

[...]

Dit kun je wel een beetje meten door unittests te schrijven voor je code. Bij code waar dat dependency inversion principe niet (goed) is toegepast is het lastig om unittests te schrijven. Iets dat wat meer multi-tier is (frontend-backend-database bijvoorbeeld) leent zich er beter voor denk ik. Dat is meestal wel de context die wij gebruiken bij opdrachten voor studenten (en externe opdrachtgevers trouwens ook).

Het kan ook zijn dat je aanpak niet klopt. Ben je nou begonnen met code schrijven of heb je ergens eerst een model gemaakt? Dat laatste is misschien wel een goed idee. Je bent daar al bezig met vragen omtrent wat je wel en niet abstraheert, en hoe de relatie ligt tussen alle dependencies enzo.

Het stond inderdaad op private, heb het nu veranderd naar public.

Ik was begonnen met een overzicht te maken van de entities die ik nodig heb voor Tetris: playfield, shapes, individuele blokken waaruit de shapes bestaan etc. Die heb ik vervolgens vertaald naar classes en dan bij elke class genoteerd welke methods er nodig zijn.

Relaties leggen vond ik moeilijk. Ik ben gewoon om met relationele databases te werken en daarbij spreekt dat voor zich, maar in een game is dat natuurlijk niet. De relaties die ik kon vinden zijn het speelveld (Playfield) dat een List van "IShapes" bevat. Elke Shape bevat een List van "Points" waarin het patroon is opgeslagen (bv L-vorm). De overige code bestaat voornamelijk uit methods die het gevolg zijn van events (timer, user input).

[Dido]

Een paar eerste reacties op je code, absoluut niet zaligmakend of volledig

Ge0force schreef op vrijdag 20 januari 2023 @ 21:45:
- Ik krijg diverse warnings "non-nullable property X must contain a non-null value when exiting a constructor". Die properties krijgen bij de start van een game wel een waarde, en zouden niet null mogen zijn op het moment dat ik ze aanspreek dus ik maak ze liever niet nullable. Hoe wordt dit best opgelost?

Dan moet je er dus voor zorgen dat ze geinitialiseerd worden in je constructor
In je shapes zou je dit kunnen oplossen door in je BaseShape een protected constructor te maken, die je vanuit je andere shapes aanroept om die variabelen een aarde te geven.

Dus iets als

code:

public abstract class BaseShape : IShape
{
    public Point Position { get; set; }
    public int Rotation { get; set; }
    public int MaxRotation { get; set; }
    public List<Point> Pattern { get; set; } = new List<Point>();
    public Point Pivot { get; set; }
    public Color PenColor { get; set; }
    public Color BrushColor { get; set; }
 
    protected BaseShape(Point position, int rotation, int maxRotation, Point pivot, Color penColor, Color brushColor)
    {
        Position = position;            
        Rotation = rotation;
        MaxRotation = maxRotation;
        Pivot = pivot;
        PenColor = penColor;
        BrushColor = brushColor;
    }
}

public class ShapeBar : BaseShape
{
    public ShapeBar(): base(new Point(4, -1), 0, 2, new Point(2, 2), Color.FromArgb(255, 255, 255, 0), Color.FromArgb(100, 255, 255, 0))
    {            
        Pattern.Add(new Point(0, 2));
        Pattern.Add(new Point(1, 2));
        Pattern.Add(new Point(2, 2));
        Pattern.Add(new Point(3, 2));
    }
}

De warnings in `Form1.cs` vertellen je ook exact wat je moet doen, verplaats de initialisers voor die objecten naar je constructor in plaats van `Form1_Load`. Je compiler gaat niet bijhouden of die method wordt aangeroepen voordat jij die properties aanspreekt

In `PlayField.cs` kun je de warning oplossen door `SpawnRandomShape` te renamen en aan te passen zodat ie een `IShape` teruggeeft, dat kun je in je constructor gewoon je `FallingShape` initialisen en toevoegen aan je `Field`:

code:

public PlayField(int width, int height)
{
    Field = new List<IShape>();
    FieldWidth = width;
    FieldHeight = height;
    FallingShape = CreateRandomShape();
    Field.Add(FallingShape);
}
public void SpawnRandomShape()
{
    FallingShape = CreateRandomShape();
    Field.Add(FallingShape);
}

private IShape CreateRandomShape()
{
    // Roll random number between 0 and 7
    Random rd = new Random();
    int rand_num = rd.Next(0, 7);
    // Reroll if result == 7 or result == previous result
    if (rand_num == 7 || rand_num == _lastRandomNumber)
    {
        rand_num = rd.Next(0, 6);
    }

     _lastRandomNumber = rand_num;

     // Result of roll determines which shape
    switch (rand_num)
    {
        case 0: return new ShapeBar();
        case 1: return new ShapeL();
        case 2: return new ShapeReverseL();
        case 3: return new ShapeStairsUp();
        case 4: return new ShapeStairsDown();
        case 5: return new ShapeSquare();
        default: return new ShapeT();
    }            
}

Pas trouwens ook met die `new Random()` aan! Maak die 1 keer aan, en hergebruik hem. Als je heel snel na elkaar twee keer een nieuwe Random maakt, wordt ie met dezelfde seed geinitialiseerd, zodat je hetzelfde "random" getal terugkrijgt.

Daarnaast lijkt er een code-smell te zitten in het feit dat je een random getal genereert en vervolgens controleert of het niet toevallig 7 is...

Dat zal hier niet zo heel veel uitmaken, maar er zijn situaties waarin je jezelf hiermee in de vingers gaat snijden. (Ik heb zo ooit een bug geintroduceerd waarin ik een nieuwe random gebruikte om een reeks getallen te husselen. Alleen werd die door een andere bug dubbel aangeroepen, en dat leverde dan een niet-gehusseld resultaat op )

Let er daarnaast op dat je niet alles public maakt (PlayField.FieldWith en FieldHeight kunnen gewoon private worden!) en let op je spelling. `CheckCollissons()` is geen correcte naam, maak er een gewoonte van dat soort typo's meteen aan te passen zodra je ze ziet (Visual Studio kan zelfs je spelling checken!)

Overigens kan die method ook gewoon `private` worden.

Dan zijn er nog wat kleine dingetjes die opvallen, zoals

code:

Graphics objGraphics;
objGraphics = e.Graphics;
objGraphics.DrawImage(_drawingArea, 0, 0, _drawingArea.Width, _drawingArea.Height);

Is gewoon hetzelfde als

code:

e.Graphics.DrawImage(_drawingArea, 0, 0, _drawingArea.Width, _drawingArea.Height);

Minder code is niet per definitie beter, maar een extra variabele definieren en initialiseren, terwijl je er niet mee doet voegt alleen verwarring toe.

Als uitsmijter: Als er in gegenereerde code dit staat:

code:

/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.

Dan is het wel zo handig om je daaraan te houden

Ik (of een toekomstige collega van je) word er niet vrolijk van als ik je source open, de `Designer.cs` wil openen en een foutmelding krijg omdat iemand een waarschuwing niet belangrijk genoeg vond

[Lethalis]

@Ge0force Als je van de "object sender" een "object? sender" maakt, ben je van de warnings af. Je kunt de definitie opzoeken en dan kom je op de PaintEventHandler en de EventHandler uit, waar je ziet dat er ook "object? sender" staat.

De warnings ontstaan ook door de nieuwe nullable support in .NET 6. Die kun je ook uitzetten in de project settings Iets waar ik mij zelf nogal eens schuldig aan maak. Na 20 jaar op de oude manier gewerkt te hebben (een object reference kan nou eenmaal null zijn), heb ik wat moeite om eraan te wennen.

Een dingetje waar ik wel zenuwachtig van word in jouw code, is dat veel System.Drawing objecten IDisposable zijn, maar jij nergens daar gebruik van lijkt te maken. Nu maak je gelukkig niet veel instanties aan en hergebruik je veel, maar je hebt bijvoorbeeld ook een darkRedBrush (SolidBrush) die je niet opruimt in de DrawBrick functie.

Sowieso zou ik dus alle objecten die andere objecten gebruiken die Disposable zijn, zelf ook IDisposable maken en ze dus ook netjes opruimen door Dispose aan te roepen. Of door using te gebruiken.

Een ander dingetje dat ik interessant vind, is dat een System.Timers.Timer een server based timer is. Dat wil zeggen dat hij voor het elapsed event een thread uit de ThreadPool vist (anders dan de main thread). Je zou dus ergens wat code verwachten qua thread synchronisatie. Omdat jij GDI+ gebruikt, heb je nu waarschijnlijk mazzel dat deze library intern aan locking doet.

Er is ook een System.Windows.Forms.Timer die single threaded is.

code:

// When the falling shape is stuck at the top line -> Game Over!
if(_playfield.FallingShape.TopMargin() <= 1)

Dit soort dingen vind ik ook cute... het is typisch zoiets van de IShape zelf aan jou zou kunnen vertellen. Dan komen we terecht bij de GRASP:

Wikipedia: GRASP (object-oriented design)

En met name de "Information Expert":

Problem: What is a basic principle by which to assign responsibilities to objects?
Solution: Assign responsibility to the class that has the information needed to fulfill it.

In dit geval kan er een IsStuckAtTopLine functie zijn of iets. Zelfde als een shape valt:

code:

// Drop the shape
_playfield.FallingShape.Position.Y += 1;

De shape zou zelf een Drop() of DropShape() functie kunnen bevatten.

Misschien wil je wel helemaal niet dat TetrisGame direct properties van shapes verandert, maar wil je shapes vertellen wat ze moeten doen. En dit scheelt je blijkbaar ook commentaar, want de code wordt dan zelf verklarend zeg maar.

In plaats van dat je "Drop the shape" erbij schrijft, roep je gewoon de Drop of DropShape functie aan. Misschien nog met een parameter erbij, voor als ze op een gegeven moment sneller moeten vallen.

Maar het zou dus - naar mijn mening - mooier zijn als de shapes wat meer functionaliteit bevatten.

Zo krijg je ook "Low coupling". Op dit moment heeft de TetrisGame class veel kennis van de interne properties van de Shape. Net zoals de GraphicsService. In theorie zou je het ook kunnen refactoren dat de Shapes zichzelf tekenen. Op dat moment hebben de andere classes bijna geen kennis nodig van de Shape.

PS
Ik kwam even niet op de naam, maar jouw code doet mij denken aan een "anemic domain model":

Wikipedia: Anemic domain model

The anemic domain model is described as a programming anti-pattern where the domain objects contain little or no business logic like validations, calculations, rules, and so forth. The business logic is thus baked into the architecture of the program itself, making refactoring and maintenance more difficult and time-consuming.

Maar goed, ik lees teveel boeken van Martin Fowler etc En er voldoet veel code op mijn werk helemaal nergens aan. Ik kan hele verhalen hierover houden tegen mijn collega's en dan krijg ik soms ook blank stares terug hoor.

[ Voor 50% gewijzigd door Lethalis op 21-01-2023 16:45 ]

[Ge0force]

Dido schreef op zaterdag 21 januari 2023 @ 14:13:
Een paar eerste reacties op je code, absoluut niet zaligmakend of volledig

Eerst en vooral 1000x bedankt om mijn code te bekijken! Je feedback is heel duidelijk en leerzaam!

Het gebruik van een protected constructor in een abstract class is inderdaad een betere oplossing. Ik had de values "later" toegekend in de constructor om de leesbaarheid te verhogen, maar dat kan ik evengoed bereiken door de namen van de properties toe te voegen bij de parameters in de constructor.

Dat er opnieuw een random getal gegenereerd wordt bij een 7, heb ik uitgewerkt op basis van een post op Reddit waarin beweerd wordt dat de NES-versie zo werkt. Geen idee of dit klopt.

Het aanpassen van "Designer.cs" was gewoonweg dom. Ik ben als straf 10 minuten in de hoek van de kamer gaan staan.

Ik krijg nu nog één fout over mijn timer nu ik deze aanmaak in de constructor ipv de method "Start":

Nullability of reference types in type of parameter 'source' of 'void TetrisGame.gameTimerTick(object source, ElapsedEventArgs e)' doesn't match the target delegate 'ElapsedEventHandler' (possibly because of nullability attributes).

code:

        public TetrisGame()
        {
            // Initalize game timer
            gameTimer = new System.Timers.Timer();
            gameTimer.Elapsed += new ElapsedEventHandler(gameTimerTick);
        }

        public void gameTimerTick(object source, ElapsedEventArgs e)
        {
            DropFallingShape();
        }

Het spreekt voor zich dat "source" niet null mag zijn, maar hoe vermijd ik dit? Ben ik verplicht om de timer effectief te starten in de constructor?

[Ge0force]

Lethalis schreef op zaterdag 21 januari 2023 @ 16:08:
@Ge0force Als je van de "object sender" een "object? sender" maakt, ben je van de warnings af. Je kunt de definitie opzoeken en dan kom je op de PaintEventHandler en de EventHandler uit, waar je ziet dat er ook "object? sender" staat.

Bedankt om m'n code te bekijken Lethalis! Ik had inderdaad al gemerkt dat de fout verdween door "object" nullable te maken, maar dit leek me onlogisch. Het object zou immers niet null mogen zijn als de timertick wordt aangeroepen. Ik kan gerust leven met deze oplossing, maar ik vind het vreemd dat .NET een fout geeft op de gangbare manier van events maken.

Lethalis schreef op zaterdag 21 januari 2023 @ 16:08:
Een dingetje waar ik wel zenuwachtig van word in jouw code, is dat veel System.Drawing objecten IDisposable zijn, maar jij nergens daar gebruik van lijkt te maken.

Ik heb nog geen cursus bekeken over IDisposable omdat ik uit een andere cursus begrepen had dat .NET objecten zelf opruimt als ze niet meer nodig zijn via de ingebouwde garbage collector. Is dat niet het geval, of is het gewoonweg veiliger omdat zelf te doen? Ik ben in VB6 gewoon om objecten op "nothing" te zetten als ik ze niet meer nodig heb.

Lethalis schreef op zaterdag 21 januari 2023 @ 16:08:
Er is ook een System.Windows.Forms.Timer die single threaded is.

Die gebruikte ik aanvankelijk. Maar ik wou dat mijn gameloop volledig onafhankelijk is van de gebruikte output. Ik ging er van uit dat ik de Forms.Timer enkel kan gebruiken als ik via Windows Forms werk. Ben ik daar verkeerd in?

Lethalis schreef op zaterdag 21 januari 2023 @ 16:08:
Misschien wil je wel helemaal niet dat TetrisGame direct properties van shapes verandert, maar wil je shapes vertellen wat ze moeten doen

Dat klinkt logisch. Ik ga morgen bekijken waar ik dit kan doorvoeren.

Lethalis schreef op zaterdag 21 januari 2023 @ 16:08:
In theorie zou je het ook kunnen refactoren dat de Shapes zichzelf tekenen. Op dat moment hebben de andere classes bijna geen kennis nodig van de Shape.

Ik ben blij dat je dit aanhaalt, want hier heb ik zelf ook al vaak over gepiekerd. Ik wil een duidelijke scheiding tussen de gamelogica en de graphics, omdat ik de game niet afhankelijk wil maken van Windows Forms. Enkel mijn GraphicsProvider mag zich bewust zijn dat de output een Windows Form is, dus het tekenen wou ik volledig in die class laten gebeuren.

Op dit moment heeft GraphicsProvider enkel een relatie met de class TetrisGame. Ik kan de GraphicsProvider doorgeven naar de shapes via de constructor van BaseShape, maar het leek me beter om het tekenen te beperken tot één class om het overzicht te bewaren. Hoe zou jij dit oplossen?

[Lethalis]

Ge0force schreef op zaterdag 21 januari 2023 @ 16:59:
[...]
Ik heb nog geen cursus bekeken over IDisposable omdat ik uit een andere cursus begrepen had dat .NET objecten zelf opruimt als ze niet meer nodig zijn via de ingebouwde garbage collector. Is dat niet het geval, of is het gewoonweg veiliger omdat zelf te doen? Ik ben in VB6 gewoon om objecten op "nothing" te zetten als ik ze niet meer nodig heb.

Het .NET framework leeft niet op zichzelf, maar gebruikt vaak bestaande Windows API's (die gewoon in C of C++ geschreven zijn). System.Drawing gebruikt dus GDI+ en reserveert daarbij "unmanaged resources":

https://learn.microsoft.c...bage-collection/unmanaged

Zodra je ergens ziet dat een class IDisposable implementeert, is dat een goede indicator dat er unmanaged resources in het spel zijn en doe je er altijd goed aan om Dispose() aan te roepen zodra je klaar bent met die class.

Het is ook meteen de reden waarom je moet oppassen met System.Drawing als je portable code wil schrijven voor bijvoorbeeld Linux. Veel mensen gebruiken om die reden libraries zoals SkiaSharp dat weer Google Skia op de achtergrond gebruikt.

Die gebruikte ik aanvankelijk. Maar ik wou dat mijn gameloop volledig onafhankelijk is van de gebruikte output. Ik ging er van uit dat ik de Forms.Timer enkel kan gebruiken als ik via Windows Forms werk. Ben ik daar verkeerd in?

Ik zal niet zeggen dat die insteek verkeerd is. Ik geef alleen maar aan dat je elke keer op een andere thread zit. En dat is meestal iets dat Windows Forms iig niet kan waarderen. Stel je had in die code de locatie van een control gewijzigd dan was de boel waarschijnlijk gecrasht.

Ik ben blij dat je dit aanhaalt, want hier heb ik zelf ook al vaak over gepiekerd. Ik wil een duidelijke scheiding tussen de gamelogica en de graphics, omdat ik de game niet afhankelijk wil maken van Windows Forms. Enkel mijn GraphicsProvider mag zich bewust zijn dat de output een Windows Form is, dus het tekenen wou ik volledig in die class laten gebeuren.

Op dit moment heeft GraphicsProvider enkel een relatie met de class TetrisGame. Ik kan de GraphicsProvider doorgeven naar de shapes via de constructor van BaseShape, maar het leek me beter om het tekenen te beperken tot één class om het overzicht te bewaren. Hoe zou jij dit oplossen?

Met een interface

Dus een shape vertelt alleen maar hoe die getekend moet worden aan een IGraphicsService ofzoiets. Hoe deze verder geïmplementeerd is (Windows Forms, WPF, etc maakt niet uit). Dus je kan een WindowsFormsGraphicsService die IGraphicsService implementeert doorgeven aan een shape (via TetrisGame die hem ook weer krijgt van de Windows Forms app).

En als het morgen WPF moet worden, dan maak je een WpfGraphicsService en geef je die door (inversion of control).

De IGraphicsService leeft dan in dezelfde assembly / library als de Shape, maar de implementaties ervan dus niet. Dus als laatste tip: verplaats jouw classes naar een aparte library die verder geen dependencies heeft, om jezelf te dwingen dat de core functionaliteit onafhankelijk is. En het is meteen een mooie scheiding van functionaliteit.

En als je eenmaal op het punt komt dat je een poor mans dependency injection hebt (omdat je steeds met de hand interfaces doorgeeft) dan snap je meteen waarom er containers voor zijn

PS
Zelfs de timer zou je via een interface door kunnen geven. De TetrisGame heeft dan simpelweg altijd een IGraphicsService en een ITimer nodig... dat zijn dingen die de class van zijn "environment" nodig heeft om te functioneren.

In theorie zou je dan de library zelfs vanuit een Blazor WebAssembly app kunnen gebruiken en tetris kunnen spelen in de browser.

Als dat lukt, weet je dat je het goed gedaan hebt

[ Voor 17% gewijzigd door Lethalis op 21-01-2023 17:30 ]

[Lethalis]

@Ge0force Nog als aanvulling op mijn laatste reactie: iets dat ik op mijn werk bijvoorbeeld vaak doe, is dat mijn "backend" of "web services" in een assembly wonen die los staat van ASP.NET.

De API controllers doen dus niets anders dan mijn business classes aanroepen. Moet het morgen in het nieuwste hippe framework? Gaan we ineens gRPC gebruiken ipv JSON? Prima, maar het heeft geen effect op mijn business (service) classes.

En daarnaast kan ik unit tests schrijven die mijn classes aanroepen om ze te testen.

Zo gaat jouw code dus ook langer mee... alleen de buitenste laag die ermee communiceert, verandert relatief vaak.

En ik heb dit helaas op de harde manier geleerd

[ Voor 4% gewijzigd door Lethalis op 21-01-2023 18:31 ]

[Ge0force]

Ik heb een aantal aanpassingen doorgevoerd op advies van Lethalis:

- Ik heb een apart project Tetris.BL gemaakt en alle classes die betrekking hebben op de gamelogica naar daar verplaatst.

- Toegang tot de GraphicsService gebeurt nu via IGraphicsService.

- KeyEventArgs werkt niet in classes, dus ik heb de "switch" voor de keycode nu in de form gedaan en in TetrisGame aparte methods gemaakt voor Up, Down, Left en Right.

- Shape heeft nu methods MoveLeft, MoveRight etc.

Het resultaat staat op GitHub.

Lethalis schreef op zaterdag 21 januari 2023 @ 17:10:
Zodra je ergens ziet dat een class IDisposable implementeert, is dat een goede indicator dat er unmanaged resources in het spel zijn en doe je er altijd goed aan om Dispose() aan te roepen zodra je klaar bent met die class.

De class GraphicsService blijft bestaan als één instance gedurende het volledige spel. Mijn Pen en Brush objecten worden echter in de methods aangemaakt. Aanvankelijk deed ik dit op class-niveau, maar ik kreeg daardoor regelmatig de foutmelding "object is in use". Ik zou denken dat ik deze objecten moet opruimen op het einde van de method? Is het voldoende om ze gewoon null te maken?

Lethalis schreef op zaterdag 21 januari 2023 @ 17:10:
En als je eenmaal op het punt komt dat je een poor mans dependency injection hebt (omdat je steeds met de hand interfaces doorgeeft) dan snap je meteen waarom er containers voor zijn

De cursus Dependency Injection staat nog op m'n to-do lijst. Ik vind het alleszins een goed idee om het tekenen vanuit de class "shape" te doen. Ik ga dit in de week proberen.

Lethalis schreef op zaterdag 21 januari 2023 @ 17:10:
Er is ook een System.Windows.Forms.Timer die single threaded is.

Ik kan system.windows.forms blijkbaar niet gebruiken in Tetris.BL. Bestaat hier een oplossing voor? Ik wil de class TetrisGame in elk geval volledig gescheiden houden van het "form" concept.

Verdere opmerkingen en feedback blijven welkom!

[farlane]

Ge0force schreef op zondag 22 januari 2023 @ 12:39:
De class GraphicsService blijft bestaan als één instance gedurende het volledige spel. Mijn Pen en Brush objecten worden echter in de methods aangemaakt. Aanvankelijk deed ik dit op class-niveau, maar ik kreeg daardoor regelmatig de foutmelding "object is in use". Ik zou denken dat ik deze objecten moet opruimen op het einde van de method? Is het voldoende om ze gewoon null te maken?

https://learn.microsoft.c.../keywords/using-statement

[Ge0force]

farlane schreef op zondag 22 januari 2023 @ 14:09:
[...]


https://learn.microsoft.c.../keywords/using-statement

Perfect, dankjewel! 👍

[Vishari Beduk]

Geinig idee dit Tetris spel
Ik heb ook even naar je code gekeken en dan valt het op dat jij de klassieke 'fout' maakt van iemand die funtioneel programmeren gewent is.
Een van de basis principes van OO is encapsulation. En die Utilities class is dat duidelijk niet.
Die RotatePoint method hoort in de Point class.
En ik mis een apart class waar die List<Point> Points in zit zodat je die RotatePattern method daar in kan zetten.
Vervolgens is het nergens voor nodig op new Point() te doen; je kan gewoon de oude objecten hergebruiken en alleen de positie erbinnen wijzigen.
Dat vind de garbage collector ook prettig.

[Vishari Beduk]

zoiets

code:

    public class Point
    {
        public int X { get; private set; }
        public int Y { get; private set; }  

        public Point(int x, int y) 
        {
            X = x;
            Y = y;  
        }

        public void RotatePoint(Point pivot, double angleDegree)
        {
            double angle = angleDegree * Math.PI / 180;
            double cos = Math.Cos(angle);
            double sin = Math.Sin(angle);
            int dx = X - pivot.X;
            int dy = Y - pivot.Y;
            double x = cos * dx - sin * dy + pivot.X;
            double y = sin * dx + cos * dy + pivot.X;

            X = (int)Math.Round(x);
            Y = (int)Math.Round(y);
        }

        public void MoveUp() => Y--;
        public void MoveDown() => Y++;
        public void MoveLeft() => X--;
        public void MoveRight() => X++;
    }

code:

    public class Pattern
    {
        private List<Point> Points { get; set; } = new List<Point>();

        public void Add(Point p)
        {
            Points.Add(p);
        }

        public void Remove(Point p)
        {
            Points.Remove(p);
        }

        public IEnumerator<Point> GetEnumerator()
        {
            return Points.GetEnumerator();
        }

        public int Count => Points.Count;

        public int Min => Points.Min(point => point.X);

        public int Max => Points.Max(point => point.X);

        public void RotatePattern(Point pivot, int angle)
        {
            foreach (Point p in Points)
            {
                p.RotatePoint(pivot, angle);
            }
        }
    }
}

[Ge0force]

Vishari Beduk schreef op dinsdag 24 januari 2023 @ 18:53:
Geinig idee dit Tetris spel
Ik heb ook even naar je code gekeken en dan valt het op dat jij de klassieke 'fout' maakt van iemand die funtioneel programmeren gewent is.
Een van de basis principes van OO is encapsulation. En die Utilities class is dat duidelijk niet.
Die RotatePoint method hoort in de Point class.
En ik mis een apart class waar die List<Point> Points in zit zodat je die RotatePattern method daar in kan zetten.
Vervolgens is het nergens voor nodig op new Point() te doen; je kan gewoon de oude objecten hergebruiken en alleen de positie erbinnen wijzigen.
Dat vind de garbage collector ook prettig.

Hartelijk dank om mijn code te bekijken! Ik ben in visual basic inderdaad gewoon om een "public" library the hebben met shared functies. Ik heb mijn code aangepast volgens jouw advies en dat ziet er een stuk beter uit.

Er wordt inmiddels ook getoond welke de volgende vorm zal zijn. Nu nog een score en we zijn er. 😉

[eheijnen]

@Vishari Beduk
Vraag me toch af of het in dit geval niet een optie is om die "RotatePoint" functie static te maken zodat er niet bij elke instantiatie weer een kopie van deze code in het geheugen komt?

[Vishari Beduk]

eheijnen schreef op woensdag 25 januari 2023 @ 13:22:
@Vishari Beduk
Vraag me toch af of het in dit geval niet een optie is om die "RotatePoint" functie static te maken zodat er niet bij elke instantiatie weer een kopie van deze code in het geheugen komt?

Code en variabelen zijn sowieso los van elkaar. Daar zorgt de Common Language Runtime voor.
Waarschijnlijk zijn deze geheugen concepten voor jouw interessant https://www.codeproject.c...ts-Stack-Heap-Value-Types

Maar nogmaals; C# is OO
En bij OO bekijk je alles als objecten; die vliegende dingen bij Tetris zijn objecten. En eigenlijk moet alle gedrag en inhoud binnen dat object opgesloten zitten.
De bedoeling is dat je tegen dat object zegt dat het een richting moet op gaan. Maar de interne details zoals dat het uit punten bestaat (en waar dat is opgeslagen) dat moet verborgen blijven voor de buitenwereld.

Normaal gesproken gebruik je 'static' zo min mogelijk, alleen voor https://learn.microsoft.c...structs/extension-methods

[Dido]

Vishari Beduk schreef op dinsdag 24 januari 2023 @ 18:53:
Die RotatePoint method hoort in de Point class.

Als we dan toch tot op dit detailniveau komen, zou ik de method gewoon `Rotate` noemen.

Ik word altijd een beetje kriegel van `Object1.Object1Property1.Property1Property2.DoSomethingWithProperty2ofProperty1ofObject1()` als het ook gewoon `Object1.Propertyt1.Property2.DoSomething()` kan zijn.

Maar da's wellicht een kewestie van smaak

Vishari Beduk schreef op woensdag 25 januari 2023 @ 14:10:
Normaal gesproken gebruik je 'static' zo min mogelijk, alleen voor https://learn.microsoft.c...structs/extension-methods

Mwah, als je geen aparte instances ergens van nodig hebt (en zeker als je dat wilt voorkomen) is `static` gewoon handig, er is weinig op tegen om het te gebruiken waar dat mogelijk is.

Ik ben wel met je eens dat je moet oppassen niet te veel static te gaan maken (bijvoorbeeld omdat je het lastig vindt om op het juiste moment en op de juiste manier instances aan te maken en te beheren )
Of zo veel mogelijk in extension methods stoppen, een verleiding waar ik zelf ook wel eens voor gevallen ben

Het risico van static classes en methods is wel dat je heel goed moet opletten of ze threadsafe zijn, en threadsafety is een hele leuke valkuil voor heel veel (niet alleen junior-) programmeurs.

[ Voor 49% gewijzigd door Dido op 25-01-2023 14:31 ]

[Vishari Beduk]

@Dido Ja klopt, die method moet gewoon Rotate() zijn.

Wat betreft het tweede; het meerendeel van moderne C# projecten zijn ASP.NET waarbij je de IoC-container gebruikt. En dan geef je bij het vullen van de container de lifecycle aan en dat is het.
Maar jij doelt waarschijnlijk op embedded of IoT projecten en dan wordt het leuk met locks enzo

[Dido]

Vishari Beduk schreef op woensdag 25 januari 2023 @ 14:47:
Wat betreft het tweede; het meerendeel van moderne C# projecten zijn ASP.NET waarbij je de IoC-container gebruikt. En dan geef je bij het vullen van de container de lifecycle aan en dat is het.

Ook dan moet er wel iemand zijn die over die lifecycle nadenkt

Maar jij doelt waarschijnlijk op embedded of IoT projecten en dan wordt het leuk met locks enzo

Nee hoor, ik heb helaas vooral te maken met legacy .NET framework meuk waarvan een groot deel ooit is opgezet door een .NET "specialist" die vond dat het een fantastisch idee was om persistency, DI, proxies, en de volledige model-laag in 1 enkele god-class te stoppen.

Dat is jarenlang de de facto "programmeerstandaard" geweest in een opgeving waarin de programmeurs PL-SQL programmeurs met een C# cursus waren, en die dus vrolijk elke bug die ze niet meteen konden verklaren oplosten door een `this.GodClass = new GodClass();` toe te voegen. Om vervolgens glazig te kijken als de database over de zeik gaat omdat de connection pool volloopt, een server op zijn plaat gaat omdat 8 gig toch echt heel snel vol zit of het updaten van een git-package de hele applicatie overhoop haalt.

Maar goed, dit zijn eigenlijk nou net de voorbeelden waar je in de praktijk tegenaan moet lopen om te leren hoe het niet moet, daar is de TS niet mee direct geholpen

[eheijnen]

Vishari Beduk schreef op woensdag 25 januari 2023 @ 14:10:
[...]

Code en variabelen zijn sowieso los van elkaar. Daar zorgt de Common Language Runtime voor.
Waarschijnlijk zijn deze geheugen concepten voor jouw interessant https://www.codeproject.c...ts-Stack-Heap-Value-Types

Maar nogmaals; C# is OO
En bij OO bekijk je alles als objecten; die vliegende dingen bij Tetris zijn objecten. En eigenlijk moet alle gedrag en inhoud binnen dat object opgesloten zitten.
De bedoeling is dat je tegen dat object zegt dat het een richting moet op gaan. Maar de interne details zoals dat het uit punten bestaat (en waar dat is opgeslagen) dat moet verborgen blijven voor de buitenwereld.

Normaal gesproken gebruik je 'static' zo min mogelijk, alleen voor https://learn.microsoft.c...structs/extension-methods

Voor de aardigheid nog eens vergeleken, en met de static functie is het zelfs iets trager