De Devschuur Coffee Corner - Iteratie ⑬

[.oisyn]

Hier even op terugkomend...

.oisyn schreef op vrijdag 6 september 2024 @ 14:59:
uitvoering: Aten 2-Port USB-C DisplayPort Hybrid Cable KVM Switch

Een kvm met 1 DP+USB-1, en 1 USB-C.

De audio hoeft van mij niet zo hard, maar dit is wel ideaal voor mijn huidige situatie.

Ik heb dit ding dus aangeschaft, werk vandaag thuis. Sluit mijn laptop erop aan met USB-C, kan ik 4k alleen op 30Hz. WTF?!

Nogmaals specificaties van dat ding gelezen, zou wel moeten kunnen. Desktop via DP is ook gewoon 40k@60Hz.

Dus toen maar de specs van deze Lenovo Thinkpad gelezen, en daar viel me iets op. Er zitten dus 3 USB-C aansluitingen achterop mijn werk-laptop. Twee daarvan ondersteunen Thunderbolt en de derde is "gewoon" USB-C. Ik heb op kantoor twee schermen die ik via die Thunderbolt-aansluitingen aansluit, dus dat deed ik thuis ook. Blijkt dus dat hij over de niet-Thunderbolt USB-C aansluiting wel 4k@60Hz kan

[ThomasG]

.oisyn schreef op woensdag 11 september 2024 @ 09:34:
Dus toen maar de specs van deze Lenovo Thinkpad gelezen, en daar viel me iets op. Er zitten dus 3 USB-C aansluitingen achterop mijn werk-laptop. Twee daarvan ondersteunen Thunderbolt en de derde is "gewoon" USB-C. Ik heb op kantoor twee schermen die ik via die Thunderbolt-aansluitingen aansluit, dus dat deed ik thuis ook. Blijkt dus dat hij over de niet-Thunderbolt USB-C aansluiting wel 4k@60Hz kan

Dat is wel gek. Je zou het dan eerder andersom verwachten. Zowel via USB-C als via Thunderbolt is onder de motorkap gewoon DisplayPort. Wat zou kunnen is dat je USB-C DP 2.x krijgt, en via TB DP 1.2 (omdat de TB controller verouderd is?), maar dan nog zou je volgens de DP specs gewoon 4K@60Hz moeten kunnen gebruiken

[Caelorum]

Meestal is het ook andersom op de laptops. 1 poort met thunderbolt, en 2 gewone.

[AW_Bos]

Een vreemd lijntje, en die zie ik vaker in Firefox op sites verschijnen. Ziet dat er bekend uit? Ik vermoed een renderbugje na een update?

[Mugwump]

AW_Bos schreef op woensdag 11 september 2024 @ 13:12:
Een vreemd lijntje, en die zie ik vaker in Firefox op sites verschijnen. Ziet dat er bekend uit? Ik vermoed een renderbugje na een update?


[Afbeelding]

Ik denk vouwinstructies voor wanneer je de pagina afdrukt.

[DevWouter]

AW_Bos schreef op woensdag 11 september 2024 @ 13:12:
Een vreemd lijntje, en die zie ik vaker in Firefox op sites verschijnen. Ziet dat er bekend uit? Ik vermoed een renderbugje na een update?


[Afbeelding]

Als ik naar het pixel patroon kijk dan zie ik lijn die verkeerde aliassing heeft. Mogelijk dat je graphics driver iets vreemds doet? Althans, ik heb het daar ooit in het verleden ook gezien (maar dan spreken we over meer da 15 jaar geleden)

[AW_Bos]

DevWouter schreef op woensdag 11 september 2024 @ 13:26:
[...]

Als ik naar het pixel patroon kijk dan zie ik lijn die verkeerde aliassing heeft. Mogelijk dat je graphics driver iets vreemds doet? Althans, ik heb het daar ooit in het verleden ook gezien (maar dan spreken we over meer da 15 jaar geleden)

Ik ga het eens verder uitzoeken. Wel erg maf, en altijd op dezelfde plek en dezelfde situatie op deze pagina.

[DevWouter]

AW_Bos schreef op woensdag 11 september 2024 @ 13:27:
[...]

Ik ga het eens verder uitzoeken. Wel erg maf, en altijd op dezelfde plek en dezelfde situatie op deze pagina.

Sluit eens een (andere) externe monitor aan of pas de resolutie aan (van het scherm, maar ook de monitor). Vaak geef je dat wat hints waar je het kan zoeken.

[AW_Bos]

DevWouter schreef op woensdag 11 september 2024 @ 13:31:
[...]

Sluit eens een (andere) externe monitor aan of pas de resolutie aan (van het scherm, maar ook de monitor). Vaak geef je dat wat hints waar je het kan zoeken.

In ieder geval niet in mijn monitor, omdat het gewoon over het scherm heen beweegt als ik scroll. Maar ik ga de drivers eens checken, en kijken wat mijn browser doet met bepaalde extenties.

[Voutloos]

Is meest waarschijnlijke dan niet gewoon dat het lijntje echt in de css staat als het enkel die pagina en plek is

[ZaZ]

.oisyn schreef op maandag 9 september 2024 @ 19:27:
[...]


Geen enkel scherm op mijn wishlist heeft usb-c

uitvoering: ASUS ROG Swift PG38UQ Zwart
uitvoering: Samsung Odyssey Neo G7 G70NC 43" Wit
uitvoering: Iiyama G-Master G4380UHSU-B1 Zwart

Maar het zijn dan ook geen office monitoren.

Staan die nog steeds op jouw wishlist? Die Samsung en Iiyama zijn beide echt waardeloos. Ik heb ze beide begin dit jaar gehad. Ik weet dat je zegt dat het geen office monitoren zijn maar zelfs voor 'gewoon' gebruik (lees niet gamen) is het gewoon 10 keer niets. Die BGR subpixel indeling maakt de tekst superlelijk. De kleuren van de Iiyama waren grauw. De Samsung was wat levendiger, maar die had buggy software. Af en toe versprongen de kleuren ineens naar een ander profiel en ik heb tig keer gehad dat ik alle 'auto adjust' dingen uit wilde schakelen in de menu's en dat er dan ineens dingen disabled waren die niet meer in te stellen waren tenzij je een factory reset uitvoerde. Pure rommel.

[.oisyn]

@ZaZ oh ja daar hadden we over geDM'd idd, dat was ik alweer vergeten . Goed dat je het noemt. Voorlopig zal het scherm er nog niet komen, maar dit verhoedt me om iig een impulsaankoop te doen

[.oisyn]

[RayNbow]

.oisyn schreef op zondag 15 september 2024 @ 22:22:
[Afbeelding]

Visual Basic:

Dim NoTheyDont(42 to 69)

[.oisyn]

Vraagje voor de Visual Studio gebruikers hier.

Nu ik een werk-laptop gebruik die ik mee naar huis neem, wissel ik nogal eens van scherm. Thuis heb ik een enkel 43" 4k scherm, op kantoor 2x 24" (). Maar de setup maakt nogal uit hoe ik Visual Studio indeel. Op de setup met twee kleinere schermen heb ik eigenlijk alleen maar code in de hoofd-window, en op de tweede monitor heb ik een toolwindow met solution explorer, output, etc.

Het is nogal irritant om elke keer weer die aanpassing te moeten maken. Is daar niet een goede extension voor oid?

.edit: oh lol VS kan dat out of the box al

[ Voor 4% gewijzigd door .oisyn op 16-09-2024 09:22 ]

[sky-]

Window layouts it is.

[.oisyn]

[Janoz]

[Kalentum]

Kandidaat tijdens sollicatiegesprek "I am a strong advocate for TDD bla bla bla"

Kandidaat wordt aangenomen.

Fast forward 3 maanden later: Ik krijg een code review verzoek van hem. Eerste keer. Verwachting hoog gespannen. En guess what... geen tests

[ Voor 8% gewijzigd door Kalentum op 19-09-2024 16:36 ]

[Mugwump]

Kalentum schreef op donderdag 19 september 2024 @ 16:34:
Kandidaat tijdens sollicatiegesprek "I am a strong advocate for TDD bla bla bla"

Kandidaat wordt aangenomen.

Fast forward 3 maanden later: Ik krijg een code review verzoek van hem. Eerste keer. Verwachting hoog gespannen. En guess what... geen tests

Moraal van het verhaal: nooit iemand aannemen op generieke statements.

[Kalentum]

Mugwump schreef op donderdag 19 september 2024 @ 18:10:
[...]


Moraal van het verhaal: nooit iemand aannemen op generieke statements.

Ik hoopte dat mijn gebruik van de passieve vorm al iets suggereerde...

[Mugwump]

Kalentum schreef op donderdag 19 september 2024 @ 19:00:
[...]


Ik hoopte dat mijn gebruik van de passieve vorm al iets suggereerde...

In de zin dat je zelf geen actieve rol had in het selectieproces bedoel je?
Ik heb zelf vaak genoeg in dat soort processen gezeten en het blijft toch wel lastig hoor. Hoezeer je ook kritisch doorvraagt, mensen die in zo'n gesprek ogenschijnlijk capabel lijken blijken in de praktijk toch regelmatig niet te voldoen.

[Kalentum]

Mugwump schreef op donderdag 19 september 2024 @ 19:17:
[...]


In de zin dat je zelf geen actieve rol had in het selectieproces bedoel je?
Ik heb zelf vaak genoeg in dat soort processen gezeten en het blijft toch wel lastig hoor. Hoezeer je ook kritisch doorvraagt, mensen die in zo'n gesprek ogenschijnlijk capabel lijken blijken in de praktijk toch regelmatig niet te voldoen.

Ja precies. Een hiring manager neemt het besluit op basis van input. En het interview dat ik doe is vrij generiek en een beetje van het niveau 'past deze persoon in het team'. Eigenlijk kun je niet falen in dat interview, tenzij je een hork bent op sociaal vlak. Dus ik had wel wat dingen over TDD gevraagd (wanneer het niet handig was enzo) en dan kom je met tekstboekantwoorden een heel eind.

In dit geval waren er andere mensen die enthousiaster waren dan ik. Ik was gematigd positief (ik ging er niet voor liggen, voordeel van de twijfel). Maar als je dan tijdens je sollicitatie enorm over TDD begint en dan werkelijk het eerste ding wat ik van je zie geen tests heeft, dan moet ik wel even lachen.

[Soultaker]

TDD staat voor Test-Devoid Development, toch?

[.oisyn]

Try, Debug, Deploy, toch?

[Mugwump]

Kalentum schreef op donderdag 19 september 2024 @ 19:34:
[...]


Ja precies. Een hiring manager neemt het besluit op basis van input. En het interview dat ik doe is vrij generiek en een beetje van het niveau 'past deze persoon in het team'. Eigenlijk kun je niet falen in dat interview, tenzij je een hork bent op sociaal vlak. Dus ik had wel wat dingen over TDD gevraagd (wanneer het niet handig was enzo) en dan kom je met tekstboekantwoorden een heel eind.

In dit geval waren er andere mensen die enthousiaster waren dan ik. Ik was gematigd positief (ik ging er niet voor liggen, voordeel van de twijfel). Maar als je dan tijdens je sollicitatie enorm over TDD begint en dan werkelijk het eerste ding wat ik van je zie geen tests heeft, dan moet ik wel even lachen.

Ja dat is wel redelijk ironisch, maar als je echt een beetje wilt weten wat mensen kunnen, dan moet je toch een soort van praktijkopdracht hebben die een beetje aansluit bij wat je doet. En dan nog merk ik vaak genoeg dat mensen die zo'n opdracht heel overtuigend maken toch vervolgens toch niet echt mee kunnen komen.

Zaken als diepgang, doorzettingsvermogen en begrip dat verder gaat dan het oppervlakte vind ik persoonlijk toch altijd heel lastig te toetsen.

[5pë©ïàál_Tèkén]

Mugwump schreef op donderdag 19 september 2024 @ 20:27:
Zaken als diepgang, doorzettingsvermogen en begrip dat verder gaat dan het oppervlakte vind ik persoonlijk toch altijd heel lastig te toetsen.

Dat zijn toch zaken die voor mij erg context afhankelijk zijn. Als developer je draai weten te vinden in een bedrijf hangt voor mij ook af hoe goed iemand wordt ingewerkt, hoeveel druk op hem/haar wordt gelegd en hoeveel ruimte er mag zijn om fouten te maken. Het heeft een reden waarom je bij het ene bedrijf na 2 jaar senior bent en bij het andere na 3 jaar nog junior - het duurt soms gewoon lang voor je echt bent ingewerkt en 'part of the crew' bent. De gesprekken zie ik dan ook als 'excursie' op zoek naar redenen om iemand niet aan te nemen. En hoe vaak zijn die gesprekken gekleurd door het eigen falen van het team?

[wackmaniac]

Mugwump schreef op donderdag 19 september 2024 @ 20:27:
[...]

Zaken als diepgang, doorzettingsvermogen en begrip dat verder gaat dan het oppervlakte vind ik persoonlijk toch altijd heel lastig te toetsen.

Ik merk bij de mensen die we de afgelopen jaren hebben aangenomen dat ze heel erg het idee hebben van software development dat ze altijd greenfield projecten mogen doen. En laten we wel wezen, dat is eigenlijk eerder uitzondering dan regel 😅 Ook lezen van bestaande code lijkt een skill te zijn die minder lijkt te zijn geworden. Net als de kunde om een probleem op te lossen, vooral als zo'n probleem over een aantal "schijven" gaat of voorbij een framework. Een van onze recente projecten gebruikt gewoon HTML-bestanden en een CSS-bestand, en onze nieuwe ontwikkelaar kon niet geloven dat we een web applicatie konden bouwen zonder React of Vue. Ik weet niet wat daar de oorzaak van is, wellicht de stroom aan YouTube videos van mensen als Nick Chapsas die alleen het nieuwste van het nieuwste laten zien in lege projecten, of de overdaad aan frameworks en abstracties bovenop die frameworks. Het zorgt er in elk geval voor dat deze oude software ontwikkelaar nog vaak genoeg zijn waarde kan laten zien.

[DevWouter]

@wackmaniac
Ik ben inmiddels zodanig gewend aan brownfield projecten dat ik een hekel heb gekregen aan greenfield. Te veel opties en afwegingen die gemaakt moeten worden, en dan komt er vaak nog bovenop dat prioriteiten vaak verschuiven.

[Mugwump]

wackmaniac schreef op vrijdag 20 september 2024 @ 08:28:
[...]


Ik merk bij de mensen die we de afgelopen jaren hebben aangenomen dat ze heel erg het idee hebben van software development dat ze altijd greenfield projecten mogen doen. En laten we wel wezen, dat is eigenlijk eerder uitzondering dan regel 😅 Ook lezen van bestaande code lijkt een skill te zijn die minder lijkt te zijn geworden. Net als de kunde om een probleem op te lossen, vooral als zo'n probleem over een aantal "schijven" gaat of voorbij een framework. Een van onze recente projecten gebruikt gewoon HTML-bestanden en een CSS-bestand, en onze nieuwe ontwikkelaar kon niet geloven dat we een web applicatie konden bouwen zonder React of Vue. Ik weet niet wat daar de oorzaak van is, wellicht de stroom aan YouTube videos van mensen als Nick Chapsas die alleen het nieuwste van het nieuwste laten zien in lege projecten, of de overdaad aan frameworks en abstracties bovenop die frameworks. Het zorgt er in elk geval voor dat deze oude software ontwikkelaar nog vaak genoeg zijn waarde kan laten zien.

Er is grappig genoeg in de online techwereld ook wel een beetje een tegenbeweging zichtbaar. In Nederland heb je b.v. Pieter Levels die van de daken schreeuwt dat ie miljoenen per jaar binnenharkt met zelf gehoste websites gebouwd in PHP en JQuery. Op Twitch volg ik wel wat mensen zoals Theprimeagen die ook als motto heeft 'maakt het nou allemaal niet moelijker dan het hoeft te zijn', ga geen cloud-based serverless oplossing met allemaal asynchrone communicatie aan alle kanten optuigen voor een simpel CRUD-app. Ga niet voor een of andere complexe megaschaalbare noSql oplossing als je ook gewoon met SqlLite uit de voeten kan, ga niet meer microservices ontwikkelen dan je gebruikers hebt en meer van dat soort zaken.
David Heinemeier Hansson (van Ruby on Rails en Basecamp) zit ook wel in die richting.

En laten we wel wezen, er wordt ook gewoon heel veel overengineered met bakken aan frameworks en abstracties. Je merkt ook dat mensen het hele besef van wat een vrij simpel stukje hardware aankan echt totaal kwijt zijn.
Ik denk dat het bij startende mensen vooral nog een gebrek aan ervaring en overzicht is. Vaak wordt er gegraaid naar frameworks, libraries of clouddiensten voor zaken waar ik persoonlijk echt binnen 2 uurtjes een eigen oplossing voor had geschreven, terwijl zij 2 dagen bezig zijn geweest om uberhaupt de boel aan de praat te krijgen en vervolgens nog tegen allerlei onverwachte zaken aan lopen die ergens diep weggestopt zitten in hetgeen ze gebruiken.

Aan de andere kant is in mijn ogen ook de arbeidsmarkt er wel debet aan. Elke vacature staat weer vol met heel specifieke ervaringseisen op het gebied van frameworkjes, libraries, clouddiensten en ga zo maar door. Ik vind het persoonlijk veel waardevoller dat een kandidaat goed snapt hoe het fundament onder databases werkt in plaats van dat ze 5 jaar ervaring hebben met Mongo, Cassandra of DynamoDb, dat je de fundamenten van messaging snapt in plaats van 10 jaar ervaring met ActiveMQ, SQS of Azure Servicebus hebt en ga zo maar door. De meeste van dat soort technologie is enorm vergankelijk, terwijl die fundamenten veelal echt al wel 50 jaar meegaan in de IT. Natuurlijk, ik snap ook wel dat je graag wilt dat mensen zich niet eerst nog een half jaar moeten inlezen in de hele technologiestack, maar ook daar helpt fundamenteel begrip veel meer dan specifiek weten hoe je iets met een bepaald framework of met een bepaalde library kunt doen.

[Caelorum]

Ahja, of mensen die zonder frameworks en libraries alsnog abstractie op abstractie gooien. Hoe vaak ik wel niet moet zeggen dat het beter is om die 3 lagen even samen te voegen en van 400 regels verspreid over 10 bestanden 100 in 3 bestanden te maken. Maarja, alles moet altijd zo modulair opgebouwd worden, want wie weet moet het in de toekomst wel uitgebreid worden.

Less is more en simpel is beter zijn niet dingen waar de gemiddelde enterprise ontwikkelaar aan doet. (Uitzonderingen daar gelaten)

[Marc3l]

Allemaal herkenbaar, heb een stagiaire begeleid en die had bij zijn opleiding voornamelijk Laravel geleerd maar weinig PHP. Als er dan bijvoorbeeld een PHP error naar voren kwam dan wist hij het niet meer.
Dus in de opleiding gaat het al fout, wat hij zelf ook aangaf.

[WernerL]

Design patterns en SOLID principes worden inderdaad vaak keihard misbruikt. Ik ben ook al de meest debiele oplossingen tegengekomen voor triviale problemen.

Je kunt toch niet voorspellen hoe requirements veranderen in de toekomst dus beetje nutteloos om op voorhand mega veel flexibiliteit in te bouwen. Simpele code is makkelijker te refactoren wanneer dat nodig is.

[Caelorum]

Het is niet dat ik geen rekening hou met veranderende requirements, maar mijn ervaring is juist dat simpele systemen dat beter ondersteunen.
En ja, dan worden ze weer complex, maar de truuk zit het dan ook in wat je gaat toevoegen, of je het niet kan mappen op iets bestaands met een simpele wijziging in het bedrijfsproces zonder noemenswaardige bijwerkingen, enz.
Het is ook iets waar je de stakeholders in mee moet nemen. Vaak zien of krijgen ze pas te horen dat de software te complex is geworden als het te laat is. Daar moet je eigenlijk op voorhand al op sturen, maar de meeste developers kunnen dat niet of zijn niet in een positie waarin ze dat mogen doen.

[CodeCaster]

WernerL schreef op vrijdag 20 september 2024 @ 09:29:
Design patterns en SOLID principes worden inderdaad vaak keihard misbruikt. Ik ben ook al de meest debiele oplossingen tegengekomen voor triviale problemen.

Je kunt toch niet voorspellen hoe requirements veranderen in de toekomst dus beetje nutteloos om op voorhand mega veel flexibiliteit in te bouwen. Simpele code is makkelijker te refactoren wanneer dat nodig is.

De gemiddelde CRUD-app: stop alles in managers, services en repositories, liefst aan de lezer overlatend te interpreteren wat waar hoort te gebeuren.

De gemiddelde PHP'er (voor Symfony en Laravel al helemaal): "ik ga mijn eigen mysql(i)-wrapper schrijven".

De gemiddelde dotnetter: "Entity Framework is nog niet repository genoeg, ik ga mijn eigen schrijven!", liefst met Query-methode waarvan de conditionele expressie rechtstreeks aan Where() wordt gevoerd, en die alleen gematerialiseerde lijsten teruggeeft zodat jij als aanroeper alles verliest wat EF te bieden heeft.

Hetzelfde zie je vaak gebeuren met HttpClient. Wat nou kant-en-klare extension methods gebruiken uit een MS-library, ik schrijf mijn eigen T Get<T>(string url)!

[ Voor 3% gewijzigd door CodeCaster op 20-09-2024 10:35 ]

[Mugwump]

CodeCaster schreef op vrijdag 20 september 2024 @ 10:34:
[...]

De gemiddelde CRUD-app: stop alles in managers, services en repositories, liefst aan de lezer overlatend te interpreteren wat waar hoort te gebeuren.

Het verbaast me sowieso wel dat er nog zoveel CRUD-maatwerk wordt gedaan. Als er toch iets vrijwel volledig gegenereerd kan worden zijn het wel dit soort zaken.

[.oisyn]

CodeCaster schreef op vrijdag 20 september 2024 @ 10:34:
[...]

De gemiddelde CRUD-app: stop alles in managers, services en repositories, liefst aan de lezer overlatend te interpreteren wat waar hoort te gebeuren.

De gemiddelde PHP'er (voor Symfony en Laravel al helemaal): "ik ga mijn eigen mysql(i)-wrapper schrijven".

De gemiddelde dotnetter: "Entity Framework is nog niet repository genoeg, ik ga mijn eigen schrijven!", liefst met Query-methode waarvan de conditionele expressie rechtstreeks aan Where() wordt gevoerd, en die alleen gematerialiseerde lijsten teruggeeft zodat jij als aanroeper alles verliest wat EF te bieden heeft.

Hetzelfde zie je vaak gebeuren met HttpClient. Wat nou kant-en-klare extension methods gebruiken uit een MS-library, ik schrijf mijn eigen T Get<T>(string url)!

With blackjack. And hookers.

[RagingPenguin]

Mugwump schreef op vrijdag 20 september 2024 @ 10:55:
[...]


Het verbaast me sowieso wel dat er nog zoveel CRUD-maatwerk wordt gedaan. Als er toch iets vrijwel volledig gegenereerd kan worden zijn het wel dit soort zaken.

Heel veel dingen die CRUD genoemd worden hebben stiekem toch nog best wel vaak wat business en domain logica inzich.

En dingen moeten tegenwoordig altijd agile, dus men heeft liever is doms en simpels voor de eerste story en kopieert dat dan handmatig nog 100X om de rest van sprints te vullen ipv een keer iets goeds op te zetten wat alles kan (genereren).

[CodeCaster]

Mugwump schreef op vrijdag 20 september 2024 @ 10:55:
[...]


Het verbaast me sowieso wel dat er nog zoveel CRUD-maatwerk wordt gedaan. Als er toch iets vrijwel volledig gegenereerd kan worden zijn het wel dit soort zaken.

Ach, ik heb van alles geprobeerd daaromtrent, niks wat echt bevalt. API Platform: je exposet je entities, een DB-change is een API-change. Niet handig. En je moet verdomd goed opletten welke properties je wel en niet wil laten exposen.

EasyAdmin: grappig om in een backoffice CRUD-schermen te genereren. Wil je wat aanpassen, ben je langer bezig met uitzoeken hoe.

ASP.NET+EF scaffolding: genereert sloten aan HTML die onmogelijk zijn aan te passen.

Het schiet allemaal niet op. En wat @RagingPenguin zegt, vaak wil je wel wat logica erachter en niet de rauwe entiteiten op een bewerkscherm. Leuk, een status-enum waarvoor een dropdown wordt gegenereerd, maar eigenlijk is dat een state machine met externe triggers, bijvoorbeeld.

Gelukkig hoef ik zelden tot nooit admin-schermen te bouwen, en zo wel, dan vraag ik waar in de bestaande applicaties ik kan afkijken.

Mogelijk is er iets dat beter werkt, maar waar ik werk, zijn we nooit zo lang bezig met de CRUD zelf.

[ Voor 4% gewijzigd door CodeCaster op 20-09-2024 11:25 ]

[RagingPenguin]

CodeCaster schreef op vrijdag 20 september 2024 @ 11:22:
[...]

Ach, ik heb van alles geprobeerd daaromtrent, niks wat echt bevalt. API Platform: je exposet je entities, een DB-change is een API-change. Niet handig. En je moet verdomd goed opletten welke properties je wel en niet wil laten exposen.

EasyAdmin: grappig om in een backoffice CRUD-schermen te genereren. Wil je wat aanpassen, ben je langer bezig met uitzoeken hoe.

ASP.NET+EF scaffolding: genereert sloten aan HTML die onmogelijk zijn aan te passen.

Het schiet allemaal niet op. En wat @RagingPenguin zegt, vaak wil je wel wat logica erachter en niet de rauwe entiteiten op een bewerkscherm. Leuk, een status-enum waarvoor een dropdown wordt gegenereerd, maar eigenlijk is dat een state machine met externe triggers, bijvoorbeeld.

Gelukkig hoef ik zelden tot nooit admin-schermen te bouwen, en zo wel, dan vraag ik waar in de bestaande applicaties ik kan afkijken.

Mogelijk is er iets dat beter werkt, maar waar ik werk, zijn we nooit zo lang bezig met de CRUD zelf.

Low-code is daar best wel goed in, maar de initiële opzet is dan vaak weer te groot voor een simpele admin. omgeving.

[Mugwump]

RagingPenguin schreef op vrijdag 20 september 2024 @ 11:34:
[...]


Low-code is daar best wel goed in, maar de initiële opzet is dan vaak weer te groot voor een simpele admin. omgeving.

Ja ik verbaas me ook altijd over de hoeveelheid tijd en effort die er met dat soort platformen nog steeds gaat zitten in vrij basale applicaties. Ik zie daar soms echt teams van 4 mensen een half jaar bezig met iets dat ik zelf vroeger in een week in elkaar knutselde met een LAMP stackje.

[Verwijderd]

Oh, ik vind admin schermen bouwen leuk, maar gebruik ook mijn eigen methodiek. Die db change is een api change houd je, alleen bijvoorbeeld in mijn methodiek genereer je een json met het db schema van de entity en die voer je uit zodat de oude entity hernoemd wordt in '_old' in de database en de nieuwe wordt gebruikt. De database wijzigingen zijn gescript.

Zo heb ik van de week een applicatie gemaakt (ollama) waarmee je een taalmodel kan selecteren (momenteel 4) en er tegen kan praten. Met sse (server sent events) wordt de response getoont.

[ZpAz]

Caelorum schreef op vrijdag 20 september 2024 @ 09:21:
Ahja, of mensen die zonder frameworks en libraries alsnog abstractie op abstractie gooien. Hoe vaak ik wel niet moet zeggen dat het beter is om die 3 lagen even samen te voegen en van 400 regels verspreid over 10 bestanden 100 in 3 bestanden te maken. Maarja, alles moet altijd zo modulair opgebouwd worden, want wie weet moet het in de toekomst wel uitgebreid worden.

Less is more en simpel is beter zijn niet dingen waar de gemiddelde enterprise ontwikkelaar aan doet. (Uitzonderingen daar gelaten)

De infra van het bedrijf waar ik nu werk is zo opgezet dat we de mogelijkheid hebben om verspreid over meerdere cloud-providers te kunnen werken en zo dat als het bedrijf ooit opsplitst daar ook alvast rekening mee gehouden is. Geen van beide gaat ooit gebeuren...

Er is wel meer aan te merken, onder andere dat we zeker meer bijdragen aan de levensstijl van Bezos dan nodig is.

[Mugwump]

ZpAz schreef op maandag 23 september 2024 @ 14:50:
[...]


De infra van het bedrijf waar ik nu werk is zo opgezet dat we de mogelijkheid hebben om verspreid over meerdere cloud-providers te kunnen werken en zo dat als het bedrijf ooit opsplitst daar ook alvast rekening mee gehouden is. Geen van beide gaat ooit gebeuren...

Er is wel meer aan te merken, onder andere dat we zeker meer bijdragen aan de levensstijl van Bezos dan nodig is.

Ik heb ook altijd wel een beetje m'n bedenkingen bij dat cloudagnosticisme. Ik snap het willen voorkomen van vendor lock-in, maar de vraag is of je jezelf daar qua TCO niet enorm mee in de voet schiet en in hoeverre je vervolgens echt makkelijk van cloudprovider kunt switchen zonder een flinke investering te moeten doen in migratie (en in het van de grond krijgen van beheer).

[.oisyn]

NIST draft for digital identity

[RagingPenguin]

.oisyn schreef op woensdag 25 september 2024 @ 08:50:
NIST draft for digital identity

[Afbeelding]

test1234 en nooit meer naar kijken

[Voutloos]

Beide was al recent NIST advies, top dat het in nieuwe docs komt.
Edit: ah, nu ook dwingender; het was SHOULD NOT en wordt nu SHALL NOT.

[ Voor 34% gewijzigd door Voutloos op 25-09-2024 09:24 ]

[Janoz]

.oisyn schreef op woensdag 25 september 2024 @ 08:50:
NIST draft for digital identity

[Afbeelding]

[CloudPrutser]

Hoi :W

[CloudPrutser]

Mijn hemel, wat maakt deze website mij kriebelig. Verschrikkelijk gewoon.

[Jolijter]

CloudPrutser schreef op vrijdag 27 september 2024 @ 14:54:
Mijn hemel, wat maakt deze website mij kriebelig. Verschrikkelijk gewoon.

Wil je erover praten?

[Mugwump]

Jolijter schreef op vrijdag 27 september 2024 @ 15:36:
[...]

Wil je erover praten?

Laten we dit even bewaren tot de volgende retrospective.

[Jolijter]

Mugwump schreef op vrijdag 27 september 2024 @ 15:44:
[...]


Laten we dit even bewaren tot de volgende retrospective.

Ai, als dat dan maar past in het gehanteerde format.

[CloudPrutser]

*snip* Mega-rant weg. Doe dit even in Feedback op moderatie binnen de Devschuur en dan zonder termen als "!$@&! - site", "Blijf maar lekker in de anus van DPG media" en "Tweakers is een klote-website."; laten we 't beschaafd en constructief houden.

[ Voor 102% gewijzigd door RobIII op 28-09-2024 21:37 ]

[CloudPrutser]

*snip*

[ Voor 93% gewijzigd door RobIII op 28-09-2024 21:34 ]

[RayNbow]

CloudPrutser schreef op zaterdag 28 september 2024 @ 19:14:
Tweakers is een klote-website. Veel te zakelijk en commercieel.

Voel je vrij om een andere, betere community op te zoeken?

Ja, er zijn regels op Tweakers en die kunnen vast wel eens als vervelend worden ervaren. Maar stel jezelf eens de vraag: waarom zijn die regels er?

[CloudPrutser]

RayNbow schreef op zaterdag 28 september 2024 @ 19:36:
[...]

Voel je vrij om een andere, betere community op te zoeken?

Ja, er zijn regels op Tweakers en die kunnen vast wel eens als vervelend worden ervaren. Maar stel jezelf eens de vraag: waarom zijn die regels er?

Nou laten we het eens omdraaien: als dit niet de plek is om te praten over Java, waar dan wel? Ik hoor graag wat ik verkeerd gedaan heb, want ik snap het gewoon niet.

Wellicht zie ik iets over het hoofd hier?

[ Voor 4% gewijzigd door CloudPrutser op 29-09-2024 11:37 ]

[Mugwump]

Als ik de moderatiemelding zie, dan heb ik niet het idee dat 'praten over Java' het problematische aspect van je post was.

[CloudPrutser]

Mugwump schreef op zondag 29 september 2024 @ 11:40:
Als ik de moderatiemelding zie, dan heb ik niet het idee dat 'praten over Java' het problematische aspect van je post was.

Nee klopt, het gaat ook om een gesloten topic. Het spijt me dat ik me gisteren even liet gaan, ik was dronken.

[CodeCaster]

CloudPrutser schreef op zondag 29 september 2024 @ 11:42:
[...]

Nee klopt, het gaat ook om een gesloten topic. Het spijt me dat ik me gisteren even liet gaan, ik was dronken.

Het hele asynchrone tekstformaat van nieuwsgroepen, fora en discussiesites heeft zich gewoon nooit zo geleend voor open vragen als de jouwe, geparafraseerd "wie weet een werkwijze waarmee ik me in 3-4 weken het ecosysteem van een programmeertaal eigen kan maken". Het schaalt niet.

We weten niet hoe je nieuwe werkgever werkt, en we weten niet wat jij weet en kunt. Het wordt gissen, het wordt algemeenheden jouw kant op slingeren, het wordt veel heen-en-weer, het wordt onbevredigend voor beide zijden.

Heb je een concrete vraag met daarbij alle randvoorwaarden: prima. Heb je een slecht gedefinieerd probleem: einde discussie (slotje/duplicate/ban). Dat is hoe het internet al decennialang werkt; waar dat niet gebeurt, heb je een eeuwigdurende september, en daar wordt niemand blij van.

[Ghehe]

Over Java gesproken, binnenkort is het weer Devoxx * Ghehe tekent present

[CloudPrutser]

Jullie hebben helemaal gelijk. Het is nu net alsof ik zelf niet al vijftien jaar op forums zit.

Bedankt voor jullie feedback, ik zal het niet meer doen.

[Antrax]

Mugwump schreef op vrijdag 27 september 2024 @ 15:44:
[...]


Laten we dit even bewaren tot de volgende retrospective.

Waarom niet gewoon terug naar de backlog? Dan plannen wij het binnenkort misschien opnieuw.

[Mugwump]

Antrax schreef op vrijdag 4 oktober 2024 @ 14:36:
[...]

Waarom niet gewoon terug naar de backlog? Dan plannen wij het binnenkort misschien opnieuw.

Dit is meestal het punt waarop ik terwijl andere mensen een uur lang discussiëren over in welke sprint het hoort het zelf in dat uurtje maar gewoon bouw en aan het eind van de discussie zeg 'het is af, zullen we het maar gewoon releasen?'.

[SPee]

En dan komt de klant met de melding dat een deel van de change te duur is en niet doorgaat en je dus die wijziging weer mag terugdraaien.
En ondanks dat de change nog niet is goedgekeurd, moet je al wel de planning van 3 maanden aan het eind van de maand afgerond hebben.

[Cartman!]

Mugwump schreef op vrijdag 4 oktober 2024 @ 17:05:
[...]


Dit is meestal het punt waarop ik terwijl andere mensen een uur lang discussiëren over in welke sprint het hoort het zelf in dat uurtje maar gewoon bouw en aan het eind van de discussie zeg 'het is af, zullen we het maar gewoon releasen?'.

https://programming-motherfucker.com/

[.oisyn]

[.oisyn]

#TeNerdyVoorInGgpt

[Damic]

* Damic is gisteren nacht begonnen om een aantal programma's van framework 4.8.1 om te zetten naar .net 8. Waarom is er zoveel standaard dingen veranderen
1. My.Application.Info.Title blijft leeg ondanks dat het is ingevuld
2. Application.ProductVersion is ook vervangen door iets anders, maar dat blijft ook op 0.0.0.0
3. Waarom krijg ik CA1416 warnings als het platform op windows staat

[RayNbow]

.oisyn schreef op maandag 11 november 2024 @ 16:44:
#TeNerdyVoorInGgpt

[Afbeelding]

((a × b) → c) → (a → (b → c))

[Caelorum]

Damic schreef op donderdag 14 november 2024 @ 10:44:
[...] 3. Waarom krijg ik CA1416 warnings als het platform op windows staat

Snel een .editorconfig aanmaken en die regel uitzetten.

[Lethalis]

Dit gebeurt de laatste tijd ineens best vaak Het ene moment zijn je NuGet references er, het volgende moment zijn ze weg. En ik heb dit op meerdere computers, in verschillende projecten. Oudere .NET 4 projecten maintainen met de nieuwste Visual Studio begint zo naderhand een crime te worden. Alles valt uit elkaar Het gaat om PackageReference's, dus die zouden gewoon zichtbaar moeten zijn in de solution explorer. En dat zijn ze soms ook, totdat Visual Studio weer ongesteld wordt. Studio herstarten, of zelfs de computer herstarten, helpt soms.

.NET 8 projecten doen het prima. Maar ja, dat is zo ongeveer 10% van onze code base. We hebben zoveel projecten die bijna niet te porten zijn (door de gebruikte componenten, of technieken... Sales module waar ik nu even aan sleutel die draait nog op ASP.NET WebForms ), dus het meeste draait nog op .NET 4.

Het is alleen vanuit de business echt niet te verantwoorden om al je zooi maar te herschrijven die je in 20 jaar tijd hebt opgebouwd.

Scary stuff. Kom bijna op het punt dat het niet meer gaat. Want ik krijg nu de hele tijd IntelliSense errors en dingen, terwijl de build het gewoon doet. Errors die geen errors zijn.

Ook het combineren van C# en Visual Basic werkt de laatste tijd minder goed. Normaal kun je vanuit Visual Basic code springen naar C# code met Go To Definition etc. De laatste tijd krijg ik vaak disassembled code te zien. Dus dan werkt het heel even en dan ineens niet meer. Het is echt een zooitje aan het worden.

En ja, we hebben ook nog veel VB.NET code. Vaak maak ik C# libraries aan als ik dingen aanpas en dan herschrijf ik stukjes in C# en roep ik die vanuit VB.NET aan. Maar alles herschrijven is veel te veel werk. Zeker voor modules die klanten eigenlijk meer "voor erbij" hebben. Totaal niet winstgevend om daar bergen met tijd aan te besteden.

Als het zo doorgaat, komt er een virtuele machine met een oudere Visual Studio speciaal hiervoor. Maar ja, dat is dan wel 90% van mijn werk

[ Voor 30% gewijzigd door Lethalis op 15-11-2024 10:42 ]

[scatman]

werk je met met packages.config of met "de packages in de csproj file"?
De csproj file is tegenwoordig de verkozen methode:
https://learn.microsoft.c...nfig-to-package-reference

[Lethalis]

scatman schreef op vrijdag 15 november 2024 @ 10:43:
werk je met met packages.config of met "de packages in de csproj file"?
De csproj file is tegenwoordig de verkozen methode:
https://learn.microsoft.c...nfig-to-package-reference

Ik werk met references in de csproj file (de PackageReference elementen). Libraries en Windows applicaties zijn daar allemaal naartoe gemigreerd bij ons.

WebForms kan het helaas niet. Maar ik heb dus in bijna alle projecten, dat het er zomaar mee kapt.

Collega van mij heeft er geen last van, enige verschil is dat hij nog op Windows 10 draait en ik overal op Windows 11. Maar ja, je kunt je bijna niet voorstellen dat dit te oorzaak is. Al moet ik wel toegeven dat mijn PC op de zaak laatst door Windows 11 compleet om zeep werd geholpen (UEFI was na een update corrupt en daarna had ik ook nog nieuwe drivers nodig voor mijn WIFI kaart, anders deed DHCP het niet meer).

Kwalitatief uitermate teleurstellend. Al blijven mijn andere Windows 11 machines tot nu toe werken (2 laptops en nog een desktop... ik heb er in totaal 4 waar ik op werk). Maar goed, daar heb ik dus ook het NuGet probleem.

Altijd fijn als je deadlines hebt, even snel wat dingen wil fixen en vervolgens het gereedschap uit elkaar dondert. Ik ben sowieso al met een project bezig, dat tussendoor kwam terwijl ik met een ander project bezig was, dat tussendoor kwam bij het project dat ik eigenlijk moet doen

"Het is belangrijk dat we deze dingen fixen in de boekhoudmodule"
"Paniek! Onze software kan niet meer mailen met Microsoft 365. Even Graph API inbouwen"
"Nog meer paniek! Die en die module doet het ook niet meer!"

Grom. Bijna weekend.

Microsoft is wel de rode draad in dit verhaal overigens. Ze vinden het bij Microsoft 365 ook leuk om SMTP auth bij klanten uit te faseren etc. En ja, natuurlijk was dit wel bekend... maar ja. Dat komt vaak bovenop de grote stapel van "dat moeten we nog doen". Totdat het stuk is.

PS
Net voor de gein even met een PowerShell script de regels code laten tellen: 519.631 regels code in C# en 1.649.754 regels code in VB.NET. Is misschien ook wat veel voor 3 programmeurs. Als je dan daarnaast de boel ook nog moet herschrijven... forget it.

PPS
Ik heb ook nog een test VM met Windows Server 2022 en daar lijkt het NuGet probleem zich tot nu toe niet voor te doen. Zou het echt aan Windows 11 liggen? Visual Studio versie is hetzelfde in beide gevallen (17.11.5).

Ik heb de NuGet packages ook nog in een lokale map gedonderd en als package source toegevoegd om netwerk issues uit te sluiten, maar dat heeft weinig invloed. Vage issue dit.

[ Voor 81% gewijzigd door Lethalis op 16-11-2024 12:40 ]

[Lethalis]

Lol, als ik de Serilog NuGet package verwijder, komen de andere NuGet packages (Dapper en Newtonsoft.Json) weer terug in de solution explorer Funky stuff op de vrijdagmiddag.

Het is dat ik geen alcohol meer drink

[ Voor 19% gewijzigd door Lethalis op 15-11-2024 13:30 ]

[heerhaan]

Hoofdpijn krijgen door gedoe met NuGet-packages en .NET framework is haast genoeg reden om het drinken weer op te pakken, ik snap wat je doormaakt.

Tevens, jeetje .NET 3.5? Ik vond mezelf al zielig dat ik net van een project afkom waar ik 2 jaar tegen .NET 4.8 aan heb mogen lopen hikken, pfwoah.

[whoami]

Microsoft is wel de rode draad in dit verhaal overigens. Ze vinden het bij Microsoft 365 ook leuk om SMTP auth bij klanten uit te faseren etc. En ja, natuurlijk was dit wel bekend... maar ja. Dat komt vaak bovenop de grote stapel van "dat moeten we nog doen". Totdat het stuk is.

Maar, is het dan de schuld van Microsoft of van falend project management ?

[whoami]

Tevens, jeetje .NET 3.5? Ik vond mezelf al zielig dat ik net van een project afkom waar ik 2 jaar tegen .NET 4.8 aan heb mogen lopen hikken, pfwoah.

En ik voelde me eerder deze week ook al schuldig omdat het project waar ik aan werk nog modules heeft die tegen .NET 6 draaien, wat dan weer dinsdag zijn end-of-support datum had bereikt. Alles is relatief, zeg maar

[ Voor 4% gewijzigd door whoami op 15-11-2024 14:36 ]

[Lethalis]

heerhaan schreef op vrijdag 15 november 2024 @ 14:06:
Hoofdpijn krijgen door gedoe met NuGet-packages en .NET framework is haast genoeg reden om het drinken weer op te pakken, ik snap wat je doormaakt.

Tevens, jeetje .NET 3.5? Ik vond mezelf al zielig dat ik net van een project afkom waar ik 2 jaar tegen .NET 4.8 aan heb mogen lopen hikken, pfwoah.

Mja, we hebben een ERP pakket met bijna 200 forms waarbij op bijna elk form een Grid component staat uit het jaar 0. En de code is om dat stomme component heen geschreven. Uiteraard allemaal bedrijfskritische forms, dus niemand durft dat aan te raken.

We hebben ooit een spin off gemaakt met een nieuw grid en dat was een complete hel om een aantal forms opnieuw te bouwen

Om het nog leuker te maken: we hebben nog welgeteld 1 computer waarbij de licentie voor dit component geactiveerd is. Je kunt het namelijk niet meer activeren, omdat de leverancier de licentieserver ervoor al heeft uitgezet.

Dus dat is de heilige "we maken een release" computer

Als je die component library wil installeren, moet je op Windows 11 hem ook eerst in compatibiliteitsmodus zetten En ja, we hebben uiteraard ook weleens een wrapper geschreven. Een component dat doet alsof het dat oude grid component is... maar dat hebben we nooit helemaal kloppend gekregen en hebben we zelfs tot de dag van vandaag spijt van (want dat is ook in gebruik en doet soms nog steeds gek).

[ Voor 15% gewijzigd door Lethalis op 15-11-2024 17:40 ]

[Lethalis]

whoami schreef op vrijdag 15 november 2024 @ 14:33:
[...]
Maar, is het dan de schuld van Microsoft of van falend project management ?

Welk project management?

[ Voor 39% gewijzigd door Lethalis op 16-11-2024 12:41 ]

[Lethalis]

whoami schreef op vrijdag 15 november 2024 @ 14:36:
[...]
En ik voelde me eerder deze week ook al schuldig omdat het project waar ik aan werk nog modules heeft die tegen .NET 6 draaien, wat dan weer dinsdag zijn end-of-support datum had bereikt. Alles is relatief, zeg maar

Nou ja, de grap is dat mijn .NET 6 projecten wel allemaal braaf bijgewerkt zijn naar .NET 8.

Alles is relatief

Die upgrade is namelijk makkelijk. Oude meuk van 20 jaar geleden upgraden is dat absoluut niet. Anders had ik het allang gedaan. Je wil niet weten hoeveel avonden en zelfs weekenden ik in alle jaren dat ik hier werk heb besteed om dingen te redden. Maar ik zie het soms ook niet meer.

[ Voor 46% gewijzigd door Lethalis op 16-11-2024 12:46 ]

[Sebazzz]

scatman schreef op vrijdag 15 november 2024 @ 10:43:
werk je met met packages.config of met "de packages in de csproj file"?
De csproj file is tegenwoordig de verkozen methode:
https://learn.microsoft.c...nfig-to-package-reference

En dan bij voorkeur centralized package management (Directory.Packages.props), want zo kan je ook transitive dependencies gemakkelijk pinnen.

[AlphaRomeo]

Lethalis schreef op vrijdag 15 november 2024 @ 17:32:
[...]

Mja, we hebben een ERP pakket met bijna 200 forms waarbij op bijna elk form een Grid component staat uit het jaar 0. En de code is om dat stomme component heen geschreven. Uiteraard allemaal bedrijfskritische forms, dus niemand durft dat aan te raken.

We hebben ooit een spin off gemaakt met een nieuw grid en dat was een complete hel om een aantal forms opnieuw te bouwen

Om het nog leuker te maken: we hebben nog welgeteld 1 computer waarbij de licentie voor dit component geactiveerd is. Je kunt het namelijk niet meer activeren, omdat de leverancier de licentieserver ervoor al heeft uitgezet.

Dus dat is de heilige "we maken een release" computer

Als je die component library wil installeren, moet je op Windows 11 hem ook eerst in compatibiliteitsmodus zetten En ja, we hebben uiteraard ook weleens een wrapper geschreven. Een component dat doet alsof het dat oude grid component is... maar dat hebben we nooit helemaal kloppend gekregen en hebben we zelfs tot de dag van vandaag spijt van (want dat is ook in gebruik en doet soms nog steeds gek).

Gokje: Janus GridEx? Die hebben wij dit jaar met veel werk omgeschreven naar Telerik.

[Lethalis]

AlphaRomeo schreef op vrijdag 15 november 2024 @ 18:08:
[...]

Gokje: Janus GridEx? Die hebben wij dit jaar met veel werk omgeschreven naar Telerik.

C1 Truedb grid

[Caelorum]

Sebazzz schreef op vrijdag 15 november 2024 @ 17:39:
[...]

En dan bij voorkeur centralized package management (Directory.Packages.props), want zo kan je ook transitive dependencies gemakkelijk pinnen.

Wat dan weer niet goed werkt met package lock https://github.com/NuGet/Home/issues/12409

[Caelorum]

@Lethalis klinkt wel echt als een hele slechte business strategie. Daar doe je op de werkvloer niets meer aan behalve toekijken hoe het faalt en op dat moment de juiste terugkoppeling/input geven aan het proces.

[Sebazzz]

Caelorum schreef op vrijdag 15 november 2024 @ 18:27:
[...]

Wat dan weer niet goed werkt met package lock https://github.com/NuGet/Home/issues/12409

Nee, maar package lock is zo buggy op allerlei vlakken dat die feature niet serieus te nemen is

[Styxxy]

AlphaRomeo schreef op vrijdag 15 november 2024 @ 18:08:
[...]

Gokje: Janus GridEx? Die hebben wij dit jaar met veel werk omgeschreven naar Telerik.

Die hebben we voor WinForms nog ook heel veel zitten. Zijn in "actieve" (qua ontwikkeling) applicaties (ons platform is opgedeeld in verschillende backoffice apps) de grids aan het omvormen naar DevExpress. De "dode" applicaties laten we momenteel voor wat het is, want we zijn toch aan het evalueren wat we met die apps gaan doen.

Maar sowieso is het een gigantisch werk om alles om te zetten. Ons management hoort dat niet graag en geeft er ons ook de ruimte niet voor. We proberen dan via de "boy scout rule" de grids om te vormen (dat mag wel), aka: indien er wijzigingen op de form met die grid gebeuren, wordt de grid ook omgevornd.

[ Voor 22% gewijzigd door Styxxy op 15-11-2024 22:20 ]

[Crazy D]

Lethalis schreef op vrijdag 15 november 2024 @ 17:32:
Dus dat is de heilige "we maken een release" computer

Als dit nog steeds de werkgever is die je me 5 jaar terug een keer via een PB stuurde... ik kan me nog herinneren dat we een layout tool aan het uitzoeken waren, en iets gevonden hadden dat dan wel goed werkte. Maar er zat een beveiliging in die licentie dat je echt maar op 1 machine tegelijk met die componenten bezig kon zijn (want multi user licentie was te duur). Hoevaak we geen netwerk stekkers eruit moesten trekken omdat 1 van ons op dat betreffende formpje wat moest doen wat geblokkeerd werd door de licentie controle...

Maar ik herken het probleem. De software waar ik veel mee doe, is "laatst" van VB6 volledig gemigreerd naar .NET. Een traject waarvan de ontwikkeling ruim 2 jaar heeft geduurd, met vervolgens natuurlijk de nodige stomme bugs (maar dan ook echt gewoon domme domme bugs) waardoor de 1e releases alsnog niet zo bruikbaar waren als dat ze hoopten.

Herbouwen dmv programmeren is nauwelijks een echt haalbare optie. Kost bakken met tijd en geld, en voor de gebruikers verandert er niets. Dat is best lastig verkopen richting management maar ook naar klanten, want om ondertussen ook nog nieuwe features toe te voegen of bugs op te lossen maakt het extra tricky.

Dan kun je idd beter een oudere machine online (nou ja, beetje offline dus ) houden, misschien kun je nog een virtual maken met windows 98 Of je moet kijken naar een compleet andere structuur (code genereren, dynamisch dingen doen, low code). Maar dat is ook geen eitje als je applicatie zo groot geworden is.

Nog maar 20 jaar tot je pensioen joh

[Lethalis]

Styxxy schreef op vrijdag 15 november 2024 @ 22:18:
[...]

Die hebben we voor WinForms nog ook heel veel zitten. Zijn in "actieve" (qua ontwikkeling) applicaties (ons platform is opgedeeld in verschillende backoffice apps) de grids aan het omvormen naar DevExpress. De "dode" applicaties laten we momenteel voor wat het is, want we zijn toch aan het evalueren wat we met die apps gaan doen.

Maar sowieso is het een gigantisch werk om alles om te zetten. Ons management hoort dat niet graag en geeft er ons ook de ruimte niet voor. We proberen dan via de "boy scout rule" de grids om te vormen (dat mag wel), aka: indien er wijzigingen op de form met die grid gebeuren, wordt de grid ook omgevornd.

Nadeel van DevExpress - ondanks dat het mooi is - is alleen wel de trage performance ervan. Onze klanten klagen steen en been daarover op hun veredelde rekenmachines.

Aan de andere kant vind ik het op mijn AMD Ryzen CPU met 32GB RAM en 1TB nvme ook takke traag. Klanten werken ook vaak op een Terminal Server met gewone HDD's.

Wij gebruiken het XtraGrid ook veel in een "iets nieuwer" pakket. Dat is 10 jaar oud ipv 20

PS
Ik heb o.a. een support portal met Angular en een .NET 8 backend gebouwd en dat reageert vele malen sneller op alles. Dus ik geloof dat een webapplicatie de toekomst is.

Maar het is een complete rewrite... mensen beginnen er al grapjes over te maken. "Zou jij niet een webpakket bouwen?".

Tsja, als ik mezelf clone en met 10 man er een aantal jaar aan werk wel, maar in mijn eentje kom ik er niet. Ik heb het nog niet opgegeven, maar het is echt een enorme berg werk. Ik hoop iig een aantal modules naar het web te brengen en te moderniseren.

[ Voor 25% gewijzigd door Lethalis op 16-11-2024 13:02 ]

[Lethalis]

Crazy D schreef op vrijdag 15 november 2024 @ 22:52:
[...]
Herbouwen dmv programmeren is nauwelijks een echt haalbare optie. Kost bakken met tijd en geld, en voor de gebruikers verandert er niets. Dat is best lastig verkopen richting management maar ook naar klanten, want om ondertussen ook nog nieuwe features toe te voegen of bugs op te lossen maakt het extra tricky.

Mja ik ben het met jou eens, maar tegelijkertijd is die gedachte ook de oorzaak van het probleem. Want als je het nooit aanpakt, komt er vanzelf een dag dat de situatie onhoudbaar wordt en het je niet meer lukt om de software te onderhouden of bij de klanten te draaien.

Ik wil er dolgraag een webapplicatie van maken, maar ja... is inderdaad complete rewrite. Directie staat hier overigens wel voor open, maar er komen voorlopig geen mensen bij... dus ik moet het dan zelf realiseren en dat is eigenlijk naast mijn gewone werk niet te doen.

Maak nu eigenlijk ook alweer de fout dat ik gisteravond en ook vanochtend heb gewerkt. Uit pure frustratie dat ik bepaalde dingen wil fixen die mij al jaren achtervolgen. Ik heb ruim 10 jaar geleden een module gebouwd die inmiddels ook behoorlijk verouderd is en daar voel ik mij persoonlijk verantwoordelijk voor. Maar ja. ASP.NET WebForms ellende.

Daar ben ik de backend inmiddels compleet van aan het verbouwen naar .NET 8. Helemaal klaar mee Maar ja...

[Caelorum]

Ahja. Nooit meer doen dan nodig. Dan moffel je alleen maar de pijn weg en komt er nooit verandering. Die extra persoon komt er vanzelf wel als vanuit IT gezegd wordt dat de business strategie niet meer kan worden uitgevoerd vanwege gebrek aan investering over de jaren.
Of je zo lang moet blijven bij een bedrijf die het daar op aan laat komen... Ik zou wegrennen iig.

[Lethalis]

Caelorum schreef op zaterdag 16 november 2024 @ 13:42:
Of je zo lang moet blijven bij een bedrijf die het daar op aan laat komen... Ik zou wegrennen iig.

Ik heb zo mijn eigen issues waardoor ik niet zo gauw weg ren. Voor de rest hebben we wel veel vrijheid, ik ga maar 2 dagen per week naar kantoor, kan vrij nemen wanneer ik dat wil etc. En dat is wel handig met een gezin.

Mijn vrouw is ook druk met haar werk en ik ben bang dat mijn thuissituatie op scherp komt te staan als ik ergens anders zou werken. Dan gaan we ruzie krijgen wie thuisblijft voor ons kind, omdat we beiden naar ons werk moeten.

En haar werk in de zorg is wat minder vergevingsgezind. Zij moet aanwezig zijn.

Dus ik voel mij op dit moment niet heel gemotiveerd om te switchen. Ik zie mezelf al aan komen kakken bij een nieuwe werkgever en elke week moeten zeggen dat ik eerder naar huis moet etc. Dat gaat niet.

Terwijl ik op mijn huidige werk al 17 jaar onderdeel van het team ben en zo ongeveer kan doen en laten wat ik wil. Werkgever vindt bijna alles goed als ik maar bereikbaar ben en het werk uitvoer. Hoe, wanneer en waar boeit hem niet zo.

Dus ja, dat ik daarvoor vaak met Windows Forms moet werken is dan maar ff zo. Zo is het ook wel weer. Niet alles is slecht.

PS
Ik probeer wel altijd mijn kennis uptodate te houden. Al is het alleen maar voor die dag dat het misschien wel buiten onze controle is. Stel het bedrijf houdt op te bestaan for whatever reason of ik moet er uit... dat ik iig andere dingen kán doen.

Daarom is soms overwerken om toch dingen naar .NET 8 te krijgen of een frontend in Angular bouwen ook een beetje een investering in mezelf.

[ Voor 21% gewijzigd door Lethalis op 16-11-2024 14:10 ]

[Voutloos]

Vaker ter sprake gekomen ja. If it makes you happy..

Als je maar weet dat gratis overwerken niets met een zakelijke relatie te maken heeft. Dus vooral als het je lol of energie geeft… Maar je moet absoluut 0 verwachten ervan, niet eens goodwill is gegarandeerd als puntje bij paaltje een fusie/verkoop/lastige tijd komt.

Twee dagen kantoor en vrijheid is inmiddels meer norm dan een perk. Ik wil ook niet fulltime naar kantoor, maar dat op overheidsbanen na amper een filter.

[Caelorum]

1 dag in de twee weken op kantoor. Kan op de dag zelf nog aangeven als ik niet werk. Werk regelmatig de ochtend niet en dan de avond wel, of bijv. vrijdagmiddag niet en dan 1 van de andere dagen langer.
Voordeel van op output worden beoordeeld ipv input.
En, ja wij hebben ook oude meuk (wie niet), maar er ligt iig een wil en enigszins een plan om eraf te komen.

Maar inderdaad, als het je maar gelukkig maakt is het prima. Persoonlijk werk ik geen overuren en al helemaal niet gratis.

[ Voor 14% gewijzigd door Caelorum op 16-11-2024 14:55 ]

[Lethalis]

Voutloos schreef op zaterdag 16 november 2024 @ 14:52:
Als je maar weet dat gratis overwerken niets met een zakelijke relatie te maken heeft. Dus vooral als het je lol of energie geeft… Maar je moet absoluut 0 verwachten ervan, niet eens goodwill is gegarandeerd als puntje bij paaltje een fusie/verkoop/lastige tijd komt.

Nee dat snap ik. Het kan ook morgen failliet zijn en dan was al het werk voor niks.

Daarom zoek ik vaak ook een beetje uitdaging qua techniek als ik het in mijn eigen tijd doe. Dus dan probeer ik nieuwe C# features uit, of werk ik met *.http files om mijn API te testen bijvoorbeeld. Ik wil er dan ook wel iets van leren en niet alleen maar voor mijn werkgever bezig zijn.

En ik doe het ook weer niet zo heel vaak hoor. Toevallig de afgelopen weken iets vaker, maar er zijn ook genoeg weken dat ik om 5 uur de computer uitzet en dat het klaar is. Hangt inderdaad ook een beetje af van hoe ik mij voel en ook een beetje de tijd van het jaar.

In de zomer doe ik vaak minder bijvoorbeeld, omdat het dan mooi weer is buiten en ik met mijn gezin ergens heen ga, of dat ik simpelweg aan de tuin werk of iets. Maar als het buiten grauw weer is en ik toch geen zin heb om iets te doen verder dan ben ik wat meer met mijn werk bezig.

Anderen gaan dan wellicht gamen ofzoiets, maar dan verveel ik mij altijd. En er zit bij mij ook een limiet aan hoelang ik mij kan vermaken met "niks doen". Na 10 filmpjes kijken op YouTube of Netflix heb ik het wel gezien zeg maar.

Zo ben ik in mijn jeugd ooit ook gaan programmeren. Ik kreeg toen ik 10 jaar oud was een PC met Commander Keen er op en nog wat spellen, omdat ik een Nintendo wou en mijn vader nog een PC over had. "Speel hier maar mee". Na een paar weken spelletjes spelen ging ik mij vervelen en heb ik mezelf programmeren aangeleerd

Toen ik nog jonger was speelde ik veel met Lego, maar dat was ook een kwestie van steeds grotere constructies bouwen. Een kerstman van bijna een meter hoog etc. En dan weer slopen, volgende project. Ik "speelde" minder dan ik "bouwde" zeg maar. Ik moet bezig zijn.

En dat is wel iets dat in mij zit en soms ook lastig is hoor. Ik put mezelf uit.

Mijn vrouw mag blij zijn dat ze mij redelijk onder controle heeft qua verbouwingen in huis Anders zou het ook nog eens "help mijn man is klusser" worden hier In mijn eerste flat begon ik de keuken te verbouwen zonder enige ervaring En zo deed ik wel meer dingen die soms lukten en soms niet

[ Voor 23% gewijzigd door Lethalis op 16-11-2024 15:33 ]

[.oisyn]

#googlemath



Ok.



Makes sense.



Sure.



Go home Google, you're drunk.

[ElkeBxl]

Advent of Code 2024 Het werd tijd om weer eens wat meer aanwezig hier te zijn

[wackmaniac]

Ik mis nog 4 sterren van afgelopen jaar, maar heb nog niet de motivatie gevonden om er weer in de puzzels van vorig jaar te duiken. Wil dit jaar wel weer meedoen, maar weet nog niet welke taal ik dit jaar zal gebruiken (probeer elk jaar een andere taal te gebruiken).

[.oisyn]