De Devschuur Coffee Corner - Iteratie ⓬

[Jory]

gekkie schreef op woensdag 1 september 2021 @ 19:49:
[...]

Niet dat ik weet. Lijkt er op dat ze vooral geld proberen te halen uit het gemakt van een GUI voor de windows en mac klikkers.

Als ze gewoon een fatsoenlijke installer zouden hebben voor een "niet-GUI" versie, dan had ik echt geen Docker Desktop nodig. Hoezo is op een Linux apt install docker genoeg, maar is het op Windows bijna niet te doen zonder Docker Desktop te gebruiken (tenminste, dat is mijn laatste ervaring)?

wackmaniac schreef op donderdag 2 september 2021 @ 08:40:
[...]

5 dollar per gebruiker per maand is geen geld (...) Ik ben vooral benieuwd hoe open Docker staat voor een fixed price licentie voor een bedrijf. Ik zie vooral een hoop extra werk in het beheer van al die licenties.

Als dat allemaal losse licenties zijn die allemaal los beheert moeten worden, dan is de overhead voor een beetje een groot bedrijf al snel duurder dan de licenties zelf.

In de "Business" pricing tier zit "Centralised Management", dus daar zal die overhead waarschijnlijk wel een stuk minder zijn. Die kost wel meteen $21 pgpm.

[wackmaniac]

Jory schreef op donderdag 2 september 2021 @ 09:41:
[...]

Als ze gewoon een fatsoenlijke installer zouden hebben voor een "niet-GUI" versie, dan had ik echt geen Docker Desktop nodig. Hoezo is op een Linux apt install docker genoeg, maar is het op Windows bijna niet te doen zonder Docker Desktop te gebruiken (tenminste, dat is mijn laatste ervaring)?

Die ervaring heb ik dus ook op MacOS. En alle goedbedoelde workarounds die een Linux VM draaien met daarin de Docker Engine zijn prachtig, maar de tijd ik kwijt ben met opzetten - en supporten - besteed ik liever aan andere zaken. Heb al voorgesteld MacOS te vervangen door Linux, maar daar kreeg ik de handjes bij management en beheer nog niet echt lekker voor op elkaar...

Een andere reden waarom ik liever de licentiekosten betaal dan over te stappen op een alternatief is dat de meeste van mijn (dev) stacks nogal leunen op de netwerkmogelijkheden van Docker Compose. Dat zal ook allemaal omgebakken moeten worden als je wilt overstappen op een alternatief als Vagrant en ik denk ook dat dat geldt voor Podman, maar dat weet ik niet zeker.

Jory schreef op donderdag 2 september 2021 @ 09:41:
[...]

Als dat allemaal losse licenties zijn die allemaal los beheert moeten worden, dan is de overhead voor een beetje een groot bedrijf al snel duurder dan de licenties zelf.

In de "Business" pricing tier zit "Centralised Management", dus daar zal die overhead waarschijnlijk wel een stuk minder zijn. Die kost wel meteen $21 pgpm.

Precies dat. Nu is alleen de vraag of die overheid die $16 extra per maand per licentie waard is voor mijn baas

[ Voor 4% gewijzigd door wackmaniac op 02-09-2021 10:10 ]

[Hydra]

Sebazzz schreef op woensdag 1 september 2021 @ 19:54:
De wijzigingen hingen al boven de markt toen ze updates van de Docker client verplicht gingen stellen

Ja, dat was voor mijn ook al een dingetje. Ze hadden ook bijna elke dag wel een update. Opzouten

[Sebazzz]

Iemand ervaring met COM-interop met Office hier? Ik heb één of ander vaag probleem waarbij sommige calls naar VBA falen totdat het proces wordt herstart.

[ Voor 6% gewijzigd door Sebazzz op 02-09-2021 17:32 ]

[Lethalis]

Sebazzz schreef op donderdag 2 september 2021 @ 17:32:
Iemand ervaring met COM-interop met Office hier? Ik heb één of ander vaag probleem waarbij sommige calls naar VBA falen totdat het proces wordt herstart.

Het is een gokje van mij, maar probeer het eens met .NET 4.8 in plaats van .NET 5. COM interop is relatief nieuw in .NET 5, je weet maar nooit.

Lijkt alsof er iets in het geheugen blijft hangen.

[ Voor 4% gewijzigd door Lethalis op 04-09-2021 09:20 ]

[Lethalis]

wackmaniac schreef op donderdag 2 september 2021 @ 10:09:
[...]
Heb al voorgesteld MacOS te vervangen door Linux, maar daar kreeg ik de handjes bij management en beheer nog niet echt lekker voor op elkaar...

Een andere reden waarom ik liever de licentiekosten betaal dan over te stappen op een alternatief is dat de meeste van mijn (dev) stacks nogal leunen op de netwerkmogelijkheden van Docker Compose.

Het hoeft niet per se óf / óf te zijn natuurlijk. Voor nu gewoon even betalen zodat je niet direct de boel hoeft om te gooien en gewoon verder kan met het werk. En dan langzaam migreren naar een andere oplossing (waarbij ik dan Docker zou verwijderen ipv iets anders zoals MacOS... het is immers niet Apple die jou in deze een oor probeert aan te naaien).

[ Voor 9% gewijzigd door Lethalis op 04-09-2021 09:38 ]

[Sebazzz]

Lethalis schreef op zaterdag 4 september 2021 @ 09:19:
[...]

Het is een gokje van mij, maar probeer het eens met .NET 4.8 in plaats van .NET 5. COM interop is relatief nieuw in .NET 5, je weet maar nooit.

Lijkt alsof er iets in het geheugen blijft hangen.

Ha, dan kan ik net zo goed alles opnieuw bouwen iets omhoog porten is makkelijk, iets omlaag porten niet

Ik heb het nu opgelost door een subproces aan te roepen wat daarna weer afsluiten.

[ThomasG]

Sebazzz schreef op zaterdag 4 september 2021 @ 10:01:
[...]

Ha, dan kan ik net zo goed alles opnieuw bouwen iets omhoog porten is makkelijk, iets omlaag porten niet

Ik heb het nu opgelost door een subproces aan te roepen wat daarna weer afsluiten.

Als het maar een verbogen proces is, en niet dat je steeds (zoals gebruikelijk lijkt bij windows) een command prompt ziet voor een seconden

[OMX2000]

Dat dependabot op Github word ik wel blij van. Voor mijn eigen prutsels die ik op Github heb staan, maar ook omdat libraries die ik gebruik ook erop gewezen worden dat er mogelijke vulnerabilities in hun repo’s verstopt zitten. En da’s vooral in javascript/npm land geen overbodige luxe.

[Hydra]

OMX2000 schreef op maandag 6 september 2021 @ 10:55:
Dat dependabot op Github word ik wel blij van. Voor mijn eigen prutsels die ik op Github heb staan, maar ook omdat libraries die ik gebruik ook erop gewezen worden dat er mogelijke vulnerabilities in hun repo’s verstopt zitten. En da’s vooral in javascript/npm land geen overbodige luxe.

Heb eerder in een project dependabot gebruikt voor onze Java code nog voordat het 'gratis' was bij Github. Echt een topproduct. Enige nadeel is dat ik best veel warnings krijg op oude 'meuk' repo's, moet ff een keer gaan kijken hoe ik die kan excluden.

[Sebazzz]

ThomasG schreef op maandag 6 september 2021 @ 10:28:
[...]
Als het maar een verbogen proces is, en niet dat je steeds (zoals gebruikelijk lijkt bij windows) een command prompt ziet voor een seconden

Haha nee, maar het opofferen van een proces werkt in ieder geval.

Het lastige van dit soort bugs is dat ik het wel kan rapporteren maar het is ook vanwege intellectueel eigendom praktisch onmogelijk om een reproduceerbaar voorbeeld van te maken

[Pizzalucht]

Voor de mensen die GitLab gebruiken, ik gebruik deze al een tijdje op onze private instance:
https://gitlab.com/dependabot-gitlab/dependabot

Gebouwd op de core van Dependabot dus uiteindelijke werking is vrijwel hetzelfde.
Sinds kort kan hij automatisch repositories scannen naar een .gitlab/dependabot.yml en zichzelf automatisch activeren.

Wel met de disclaimer:

This software is Work in Progress: features will appear and disappear, API will be changed, your feedback is always welcome!

[.oisyn]

Ugh, passwords...

[DaFeliX]

Pizzalucht schreef op maandag 6 september 2021 @ 12:49:
Voor de mensen die GitLab gebruiken, ik gebruik deze al een tijdje op onze private instance:
https://gitlab.com/dependabot-gitlab/dependabot

Gebouwd op de core van Dependabot dus uiteindelijke werking is vrijwel hetzelfde.
Sinds kort kan hij automatisch repositories scannen naar een .gitlab/dependabot.yml en zichzelf automatisch activeren.

Wel met de disclaimer:

[...]

We gebruiken bij Tweakers op onze eigen Gitlab al een tijdje Renovatebot. Het heeft dezelfde werking als Dependabot. Ik weet niet meer de exacte afweging om Renovatebot ipv Dependabot te gebruiken, maar ik kan wel zeggen dat Renovatebot erg lekker werkt; en goed te configureren is.

Nu er nog voor zorgen dat er voldoende test-coverage is, zodat ie straks ook automatisch kan mergen

[ElkeBxl]

.oisyn schreef op maandag 6 september 2021 @ 13:37:
Ugh, passwords...

Just keep it simple

[Pizzalucht]

DaFeliX schreef op maandag 6 september 2021 @ 13:49:
[...]


We gebruiken bij Tweakers op onze eigen Gitlab al een tijdje Renovatebot. Het heeft dezelfde werking als Dependabot. Ik weet niet meer de exacte afweging om Renovatebot ipv Dependabot te gebruiken, maar ik kan wel zeggen dat Renovatebot erg lekker werkt; en goed te configureren is.

Nu er nog voor zorgen dat er voldoende test-coverage is, zodat ie straks ook automatisch kan mergen

Renovatebot lijkt er heel erg op zo te zien!

Ik vind automatisch mergen altijd wel een beetje eng... Straks pushed iemand even backdoor in een populaire opensource repo

[ Voor 3% gewijzigd door Pizzalucht op 06-09-2021 16:18 ]

[EagleTitan]

Pizzalucht schreef op maandag 6 september 2021 @ 16:18:
[...]


Renovatebot lijkt er heel erg op zo te zien!

Ik vind automatisch mergen altijd wel een beetje eng... Straks pushed iemand even backdoor in een populaire opensource repo

Maar controleer jij dan iedere dependency upgrade de hele source van de package?

[Pizzalucht]

EagleTitan schreef op maandag 6 september 2021 @ 16:25:
[...]


Maar controleer jij dan iedere dependency upgrade de hele source van de package?

De diff natuurlijk

[ Voor 4% gewijzigd door Pizzalucht op 06-09-2021 16:30 ]

[DaFeliX]

Pizzalucht schreef op maandag 6 september 2021 @ 16:18:
[...]


Ik vind automatisch mergen altijd wel een beetje eng... Straks pushed iemand even backdoor in een populaire opensource repo

of je hebt allerlei repo's met bekende beveiligingslekken omdat niemand de mr's (of pr's) merged

Maar je hebt wel een punt: Supply-chain attacks zijn interessant, en zeker in opkomst, en absoluut een risico. Toch denk ik dat het niet up-to-date houden van software een groter probleem is

[Koenvh]

DaFeliX schreef op maandag 6 september 2021 @ 16:38:
[...]


of je hebt allerlei repo's met bekende beveiligingslekken omdat niemand de mr's (of pr's) merged

Maar je hebt wel een punt: Supply-chain attacks zijn interessant, en zeker in opkomst, en absoluut een risico. Toch denk ik dat het niet up-to-date houden van software een groter probleem is

Maar dan heb je toch een ander probleem (namelijk niemand die iets updatet)? Ik vind automatisch updaten nogal riskant, dan toch liever een pull/merge request waar een mens op het knopje moet drukken.

[Pizzalucht]

DaFeliX schreef op maandag 6 september 2021 @ 16:38:
[...]


of je hebt allerlei repo's met bekende beveiligingslekken omdat niemand de mr's (of pr's) merged

Maar je hebt wel een punt: Supply-chain attacks zijn interessant, en zeker in opkomst, en absoluut een risico. Toch denk ik dat het niet up-to-date houden van software een groter probleem is

Zeker mee eens hoor, daarom ook een fan van tools als Dependabot, maar automatisch mergen durf ik op dit moment nog niet aan.

[Hipska]

Als iets automatisch gemerged is, hoeft dat nog niet te betekenen dat uw software daarna automatisch gereleased word he. Dus er is nog altijd de menselijke knop nadien..

[Pizzalucht]

Hipska schreef op maandag 6 september 2021 @ 17:03:
Als iets automatisch gemerged is, hoeft dat nog niet te betekenen dat uw software daarna automatisch gereleased word he. Dus er is nog altijd de menselijke knop nadien..

Gemerged naar development is hier in ieder geval wel automatisch deployen naar de testomgeving.
Daarbij is het controleren van de dependency update code veel makkelijker als je het in de bijbehorende MR doet, in plaats van als je gaat releasen.

[RedFox]

Pizzalucht schreef op maandag 6 september 2021 @ 16:30:
[...]




De diff natuurlijk

En ook van alle dependencies van de depency? En de dependencies daarvan, en .....

[Motrax]

Goed. Gisteren projectleider gesproken, van een stuk werk dat uitgesteld was tot na de zomervakantie. Dat was uitgesteld in goed overleg.

Blijkt de go-live datum op half oktober te staan, effectief eind deze maand af te moeten en er is nog geen functioneel ontwerp, laat staan technisch, laat staan een implementatie. Dan hebben we ook nog mensen die net na de zomervakantie op vakantie gaan, dus onze bezetting is niet 100%.

Oh en ik kan voorlopig geen contact opnemen met de leverancier, vanwege een financieel dispuut

Soms... heel soms... vraag ik mij af hoe we er telkens voor zorgen dat we een werkende IT omgeving hebben

[Tjolk]

Simpel zat: datum opnieuw prikken.

[Pizzalucht]

RedFox schreef op maandag 6 september 2021 @ 23:41:
[...]

En ook van alle dependencies van de depency? En de dependencies daarvan, en .....

Ja, op het moment dat er een dependency update is en er een MR komt van Dependabot dan vendored Dependabot alle (transitive) dependencies in de MR en check ik alle wijzigingen die daarbij komen. Het klinkt als meer werk dan het is, maar dankzij Dependabot valt dat juist enorm mee omdat je niet opeens 30 versies omhoog gaat.

[F.West98]

Pizzalucht schreef op dinsdag 7 september 2021 @ 11:06:
[...]


Ja, op het moment dat er een dependency update is en er een MR komt van Dependabot dan vendored Dependabot alle (transitive) dependencies in de MR en check ik alle wijzigingen die daarbij komen. Het klinkt als meer werk dan het is, maar dankzij Dependabot valt dat juist enorm mee omdat je niet opeens 30 versies omhoog gaat.

Eén van mijn grootste frustraties bij vooral npm-packages: het chronische gebrek aan een fatsoenlijke changelog... Laatst een setje packages zitten upgraden en dan gaat zo'n package gewoon 5 major versies omhoog zonder enige informatie over wat er dan veranderd is

[Koenvh]

F.West98 schreef op dinsdag 7 september 2021 @ 11:14:
[...]

Eén van mijn grootste frustraties bij vooral npm-packages: het chronische gebrek aan een fatsoenlijke changelog... Laatst een setje packages zitten upgraden en dan gaat zo'n package gewoon 5 major versies omhoog zonder enige informatie over wat er dan veranderd is

Fixed some bugs...

[ThomasG]

Koenvh schreef op dinsdag 7 september 2021 @ 12:25:
[...]

Fixed some bugs...

En niet te vergeten:
- Increase package size significantly, because our 3 line function needs documentation, tests, examples, and a license and NPM has no option for a small build only.

[Koenvh]

ThomasG schreef op dinsdag 7 september 2021 @ 12:35:
[...]
En niet te vergeten:
- Increase package size significantly, because our 3 line function needs documentation, tests, examples, and a license and NPM has no option for a small build only.

Onze elven werken constant eraan de gebruikerservaring te optimaliseren! In deze update hebben we wat updates doorgevoerd om <ding> nog beter te maken!

[Voutloos]

ThomasG schreef op dinsdag 7 september 2021 @ 12:35:
[...]
En niet te vergeten:
- Increase package size significantly, because our 3 line function needs documentation, tests, examples, and a license and NPM has no option for a small build only.

Exact 1 function per package is gekkenwerk, dus dit is een feature.

[ThomasG]

Voutloos schreef op dinsdag 7 september 2021 @ 13:07:
[...]
Exact 1 function per package is gekkenwerk, dus dit is een feature.

De repositories zitten er vol mee. Misschien gebruik je ze zelf niet direct, maar de dependencies van de dependencies van de dependencies wel. Dus voor je het weet heb je een node_modules van 600 MB voor een project wat nog geen 10 MB aan javascript oplevert.

Als je dan een project meerdere keren gekloond hebt, om gemakkelijker (gelijktijdig) aan verschillende branches te werken word je daar niet heel vrolijk van

[Mugwump]

ThomasG schreef op dinsdag 7 september 2021 @ 13:22:
[...]
De repositories zitten er vol mee. Misschien gebruik je ze zelf niet direct, maar de dependencies van de dependencies van de dependencies wel. Dus voor je het weet heb je een node_modules van 600 MB voor een project wat nog geen 10 MB aan javascript oplevert.

Als je dan een project meerdere keren gekloond hebt, om gemakkelijker (gelijktijdig) aan verschillende branches te werken word je daar niet heel vrolijk van

Ik heb als JVM developer dan ook een pleurishekel aan NPM. Wat een slap excuus voor een package manager is dat.

[Koenvh]

Mugwump schreef op dinsdag 7 september 2021 @ 13:32:
[...]


Ik heb als JVM developer dan ook een pleurishekel aan NPM. Wat een slap excuus voor een package manager is dat.

Ja, NPM heeft echt meer XML nodig

* Koenvh rent

[Mugwump]

Koenvh schreef op dinsdag 7 september 2021 @ 13:45:
[...]

Ja, NPM heeft echt meer XML nodig

* Koenvh rent

Ik zie geen XML in m'n gradle files hoor.

[SPee]

Alleen bij ons zijn die complex, waardoor een ander team dacht "ik snap het niet, welke hebben we nog niet die we kunnen gebruiken?"
Dus we hebben Gradle met legacy ant en projecten met Maven.

[RobertMe]

ThomasG schreef op dinsdag 7 september 2021 @ 13:22:
[...]
De repositories zitten er vol mee. Misschien gebruik je ze zelf niet direct, maar de dependencies van de dependencies van de dependencies wel. Dus voor je het weet heb je een node_modules van 600 MB voor een project wat nog geen 10 MB aan javascript oplevert.

600MB aan node_modules? Is dat alles? Ik heb een project met een node_modules map van 2,4GB. Geen idee wat daar allemaal in zit, maar ik wordt er niet echt blij van. Overigens geen idee hoe groot de resulterende assets (JS & CSS want Webpack + React) zijn, maar ik ga er niet vanuit dat dat over tientallen MBs gaat.

[PrisonerOfPain]

RobertMe schreef op dinsdag 7 september 2021 @ 14:15:
[...]

600MB aan node_modules? Is dat alles? Ik heb een project met een node_modules map van 2,4GB. Geen idee wat daar allemaal in zit, maar ik wordt er niet echt blij van. Overigens geen idee hoe groot de resulterende assets (JS & CSS want Webpack + React) zijn, maar ik ga er niet vanuit dat dat over tientallen MBs gaat.

We zijn geen nodejs shop (Rust) maar dependency management is echt wel een ding. Eens in de zoveel tijd gaan we over onze dependencies en kijken we wat ze binnenhalen - en als 't grote on-nodige dingen zijn dan PR-en we de projecten om te zorgen dat 't allemaal binnen de perken blijft.

[Motrax]

F.West98 schreef op dinsdag 7 september 2021 @ 11:14:
[...]

Eén van mijn grootste frustraties bij vooral npm-packages: het chronische gebrek aan een fatsoenlijke changelog... Laatst een setje packages zitten upgraden en dan gaat zo'n package gewoon 5 major versies omhoog zonder enige informatie over wat er dan veranderd is

Geen klachten over gebrek aan documentatie, goede voorbeelden?

Want dat is een irritatie puntje van mijn kant over open source packages. Ze werken, misschien, maar het kost vaak veel tijd om te snappen wat er gebeurd en wat het doet.

Of je hebt een package die het hele internet breekt
https://arstechnica.com/i...t-and-broke-the-internet/

[Lethalis]

F.West98 schreef op dinsdag 7 september 2021 @ 11:14:
[...]

Eén van mijn grootste frustraties bij vooral npm-packages: het chronische gebrek aan een fatsoenlijke changelog... Laatst een setje packages zitten upgraden en dan gaat zo'n package gewoon 5 major versies omhoog zonder enige informatie over wat er dan veranderd is

Mja en het risico dat een package van maintainer is veranderd en je geen idee hebt of die persoon te vertrouwen is.

Scary stuff.

Bijvoorbeeld:

https://www.trendmicro.co...teal-from-bitcoin-wallets

[ Voor 13% gewijzigd door Lethalis op 08-09-2021 07:42 ]

[bwerg]

ThomasG schreef op dinsdag 7 september 2021 @ 12:35:
[...]
En niet te vergeten:
- Increase package size significantly, because our 3 line function needs documentation, tests, examples, and a license and NPM has no option for a small build only.

Nou ben ik blij om te constateren dat ik helemaal niks met JS of NPM te maken heb hoor, dus vergeef mijn domme vraag, maar: een import die groter wordt omdat er meer tests zijn toegevoegd?

Lethalis schreef op woensdag 8 september 2021 @ 07:40:
[...]

Mja en het risico dat een package van maintainer is veranderd en je geen idee hebt of die persoon te vertrouwen is.

Wat dat betreft is het misschien beter om als package maintainer je package gewoon forkbaar te laten sterven als je er geen zin meer in hebt. Dan doet iedereen die overstapt op die ene populaire fork ten minste nog een beetje basaal onderzoek om te zien wat die nieuwe dependency nou eigenlijk precies toevoegt.

[ Voor 35% gewijzigd door bwerg op 08-09-2021 09:10 ]

[Kalentum]

Motrax schreef op woensdag 8 september 2021 @ 06:02:
[...]
Want dat is een irritatie puntje van mijn kant over open source packages. Ze werken, misschien, maar het kost vaak veel tijd om te snappen wat er gebeurd en wat het doet.

Die laatste zin beschrijft zo ongeveer alle software in de wereld

[GrooV]

Sowieso altijd opletten met externe packages, als je NuGet packages installeert kunnen die ook lekker powershell commando's/scripts uitvoeren op je PC.

Of misschien altijd opletten als je dingen van het grote boze internet binnen haalt

@Lethalis Tja als mensen opzettelijk NPM publish rechten overdragen (en de Github repo niet) dan is daar weinig aan te doen. Dat kan natuurlijk met alle software die van eigenaar wisselt. Package was al aardig inactief overigens

Gelukkig zijn er dingen zoals npm audit, dependabot en Nexus

[ Voor 6% gewijzigd door GrooV op 08-09-2021 09:34 ]

[wackmaniac]

bwerg schreef op woensdag 8 september 2021 @ 09:05:
[...]

Nou ben ik blij om te constateren dat ik helemaal niks met JS of NPM te maken heb hoor, dus vergeef mijn domme vraag, maar: een import die groter wordt omdat er meer tests zijn toegevoegd?

Standaard wordt er een artifact gemaakt van de repository. Dat betekent vaak ook de docs en tests. Meer tests, grotere artifact. Zelf voeg ik eigenlijk altijd een .gitattributes toe aan mijn packages met daarin export-ignore-regels voor de tests en wat andere bestanden. Niet elke package manager gebruikt echter git export, dus het heeft niet altijd effect op de grootte van het artifact.

[Voutloos]

Korte botte samenvatting: in het js NPM ecosysteem worden best practices relatief minder vaak gevolgd en bij NPM zelf hebben ze nog nooit proactief over edge cases nagedacht. Het is bizar hoe tientallen jaren ervaring in andere systemen genegeerd wordt.
Projecten gaan nou eenmaal dood, overdacht gaat niet altijd betrouwbaar, een namespace die je vrijgeeft wordt direct geclaimed door een ander etc etc. Facts of life.

[GrooV]

Voutloos schreef op woensdag 8 september 2021 @ 09:54:
Korte botte samenvatting: in het js NPM ecosysteem worden best practices relatief minder vaak gevolgd en bij NPM zelf hebben ze nog nooit proactief over edge cases nagedacht. Het is bizar hoe tientallen jaren ervaring in andere systemen genegeerd wordt.
Projecten gaan nou eenmaal dood, overdacht gaat niet altijd betrouwbaar, een namespace die je vrijgeeft wordt direct geclaimed door een ander etc etc. Facts of life.

Packages kunnen niet zo maar meer verwijderd/unpublished worden sinds het left-pad circus

https://docs.npmjs.com/policies/unpublish

[PrisonerOfPain]

Voutloos schreef op woensdag 8 september 2021 @ 09:54:
Korte botte samenvatting: in het js NPM ecosysteem worden best practices relatief minder vaak gevolgd en bij NPM zelf hebben ze nog nooit proactief over edge cases nagedacht. Het is bizar hoe tientallen jaren ervaring in andere systemen genegeerd wordt.
Projecten gaan nou eenmaal dood, overdacht gaat niet altijd betrouwbaar, een namespace die je vrijgeeft wordt direct geclaimed door een ander etc etc. Facts of life.

Voor rust hebben we cargo-deny draaien, die scant al onze dependencies op verboden packages en faalt de CI op t moment dat ie (bijvoorbeeld) duplicates, banned packages, packages met security vulnerabilities of packages die niet meer maintained zijn tegen komt in een PR. Nog steeds niet optimaal, maar een heel stuk beter dan niks.

[Voutloos]

GrooV schreef op woensdag 8 september 2021 @ 09:57:
[...]

Packages kunnen niet zo maar meer verwijderd/unpublished worden sinds het left-pad circus

https://docs.npmjs.com/policies/unpublish

Uiteraard. Maar dat was verre van proactief, NPM was al ruime tijd populair.

Voor alle genoemde edge cases is pas een fix gemaakt ná meerdere incidenten. Left-pad is toevallig het beroemdste incident, maar anders was er wel een andere trigger geweest. Het is een registry requirement, dus hoe de package de schuld krijgt is echt te makkelijk.
(Los van dat left-pad een imo belachelijke micro dependency is)

[ Voor 6% gewijzigd door Voutloos op 08-09-2021 11:03 ]

[F.West98]

Motrax schreef op woensdag 8 september 2021 @ 06:02:
[...]
Geen klachten over gebrek aan documentatie, goede voorbeelden?

Tijdens het upgraden had ik dat niet meer nodig natuurlijk Maar ja zeker, hoe ook grote packages als rxjs gewoon minimaal documentatie hebben...

Want dat is een irritatie puntje van mijn kant over open source packages. Ze werken, misschien, maar het kost vaak veel tijd om te snappen wat er gebeurd en wat het doet.

In de praktijk duik ik echt heel vaak de source code van een package in om te kijken wat het nou precies doet en wat ik kan doen qua API enzo... Kost inderdaad veel tijd,

[Sebazzz]

Koenvh schreef op dinsdag 7 september 2021 @ 13:45:
[...]

Ja, NPM heeft echt meer XML nodig

* Koenvh rent

En meer tightly-coupled dependencies aan de applicatieserver waar je je applicatie in wilt draaien

[Sebazzz]

Voutloos schreef op woensdag 8 september 2021 @ 11:02:
[...]
Uiteraard. Maar dat was verre van proactief, NPM was al ruime tijd populair.

Voor alle genoemde edge cases is pas een fix gemaakt ná meerdere incidenten. Left-pad is toevallig het beroemdste incident, maar anders was er wel een andere trigger geweest. Het is een registry requirement, dus hoe de package de schuld krijgt is echt te makkelijk.
(Los van dat left-pad een imo belachelijke micro dependency is)

Ik vindt het echt tekenend voor het npm-ecosysteem. Van hetzelfde laken een pak

[Hydra]

SPee schreef op dinsdag 7 september 2021 @ 14:07:
Alleen bij ons zijn die complex, waardoor een ander team dacht "ik snap het niet, welke hebben we nog niet die we kunnen gebruiken?"
Dus we hebben Gradle met legacy ant en projecten met Maven.

Maven is gewoon beter dan Gradle. Je hebt altijd developers die denken dat omdat ze een hele build in Groovy kunnen bouwen dat dat ook een goed idee is.

Daarbij loopt Gradle continue achter bij nieuwe Java releases omdat Groovy achter loopt (ze doen rare shit die eigenlijk niet mag). En dat gaat nu dat meer dichtgetimmerd wordt in Java releases alleen maar erger worden.

Dit geldt ook voor Lombok trouwens; die gaat misschien uberhaupt niet Java 17 compatible worden.

[Hydra]

Koenvh schreef op dinsdag 7 september 2021 @ 13:45:
Ja, NPM heeft echt meer XML nodig

XML is top. Het heeft structuur en validatie. Ik kan serieus niet geloven dat mensen liever JSON configs editor dan XML.


Daarbij; je IDE kan je maven POM vrijwel helemaal autocompleten. Met een NPM config of (nog erger) een build.gradle is dat veel lastiger.

[Hydra]

Voutloos schreef op woensdag 8 september 2021 @ 11:02:
Het is een registry requirement, dus hoe de package de schuld krijgt is echt te makkelijk.

Volgens mij geeft niemand left-pad de schuld. Het wordt gewoon aangehaald om te laten zien hoe debiel de NPM implementatie (vooral toen) was. Maven heeft al lang daarvoor laten zien hoe het wel moet (met Maven central was dit onmogelijk).

[Koenvh]

Hydra schreef op woensdag 8 september 2021 @ 17:34:
[...]


XML is top. Het heeft structuur en validatie. Ik kan serieus niet geloven dat mensen liever JSON configs editor dan XML.


Daarbij; je IDE kan je maven POM vrijwel helemaal autocompleten. Met een NPM config of (nog erger) een build.gradle is dat veel lastiger.

Mag ik ze ook beide ongeschikt vinden voor configuratie?

Mijn grootste probleem met XML is dat nagenoeg niemand meer een overzicht heeft wat het allemaal kan. Autocomplete is leuk, maar het moet ook zonder goed werken.

[Hydra]

Voutloos schreef op woensdag 8 september 2021 @ 09:54:
Korte botte samenvatting: in het js NPM ecosysteem worden best practices relatief minder vaak gevolgd en bij NPM zelf hebben ze nog nooit proactief over edge cases nagedacht. Het is bizar hoe tientallen jaren ervaring in andere systemen genegeerd wordt.

Golang doet dit ook. "Java is ouderwets! Wij weten het beter! Dependency management? We pullen gewoon de laatste versie van de master! YOLO!"

Nu begrijp ik dat ze daar wel een beetje op terug gekomen zijn, maar het is volkomen debiel om artifacts niet immutable, signed, versioned en namespaced te laten zijn. Als je niet snapt waarom dat een must is, moet je geen package manager maken.

[Kalentum]

Hydra schreef op woensdag 8 september 2021 @ 17:34:
[...]


XML is top. Het heeft structuur en validatie kan valideren tegen een schema. Ik kan serieus niet geloven dat mensen liever JSON configs editor dan XML.

Heb in het verleden vaak te maken gehad met XML die net zo goed JSON had kunnen zijn. Gewoon lekker freestylen zonder schema.

[Hydra]

Koenvh schreef op woensdag 8 september 2021 @ 17:38:
Mijn grootste probleem met XML is dat nagenoeg niemand meer een overzicht heeft wat het allemaal kan. Autocomplete is leuk, maar het moet ook zonder goed werken.

Wat bedoel je? Wat wel en niet kan is gewoon prima gedocumenteerd met Maven. Als iemand een <dependency> niet in een <dependencies> blok plakt; tja.

En natuurlijk zit er een learning curve aan maar als ik sommige Java devs zie die menen te kunnen programmeren maar geen zak van tools als git en maven snappen, (heb het niet over wie dan ook in dit topic by they way), dan vind ik dat toch wel een dingetje.

[Hydra]

Kalentum schreef op woensdag 8 september 2021 @ 17:40:
Heb in het verleden vaak te maken gehad met XML die net zo goed JSON had kunnen zijn. Gewoon lekker freestylen zonder schema.

Het ging hier specifiek over Maven poms toch?

En er is echt niks mis met XML als textueel serialisatieformaat. Tuurlijk is het minder efficient dan JSON, maar het heeft tenminste een schema. Kan je daar misbruik van maken? Sure. Maar dat maakt een formaat waar je uberhaupt geen schema hebt niet beter natuurlijk

[Creepy]

Sebazzz schreef op woensdag 8 september 2021 @ 17:14:
[...]

En meer tightly-coupled dependencies aan de applicatieserver waar je je applicatie in wilt draaien

Zijn er nog mensen die applicatieservers gebruiken?

[Sebazzz]

Creepy schreef op woensdag 8 september 2021 @ 21:14:
[...]

Zijn er nog mensen die applicatieservers gebruiken?

Natuurlijk, de Java 7 applicatie op J-to-the-boss EAP 6.4.0 die ik onderhoudt en we hebben overgenomen van een andere partij. Vandaag Hibernate geupdate, dat was echt een feest.

Gelukkig al twee componenten naar de Microsoft stack omgeschreven Een externe service en de database.

[ Voor 6% gewijzigd door Sebazzz op 08-09-2021 21:41 ]

[Creepy]

Hibernate..... succes he. Maaruh, omschrijven naar Spring Boot of Dropwizard kan ook he En skip dan Hibernate of alles wat er op lijkt....

[Mugwump]

Creepy schreef op woensdag 8 september 2021 @ 21:14:
[...]

Zijn er nog mensen die applicatieservers gebruiken?

Bij ons draait nog wel oude meuk op JBoss / Wildfly ja.
Nieuwe dingen zijn vaak serverless of een spring boot runnable jars, al draaien die onder de motorkap natuurlijk ook wel weer jetty of tomcat.

[Sebazzz]

Nee, dankje, Java is niet een lekker paradigme als je .NET gewend ben. Zeker niet als je net van een 6 maanden lang .NET 5 project afkomt, maar .NET Framework ligt mij ook lekkerder

Maar Hibernate... op zich niets mis mee. Op .NET Framework een hoop met NHibernate gedaan - beviel prima. Soms een bugje hier, bugje daar, breaking change hier - maar een geadvanceerd ORM waar je een hoop aan kan sleutelen. Prima alternatief voor EF 5 (en Linq to SQL daarvoor) destijds.

Het is meer het hele applicatieserver model waar ik mij bij Java aan erger, en zeker bij Java 7 EE dat sommige dingen zo onhandig zijn. Maar deze applicatie hangt aan een infuus, het hoeft voornamelijk tot het einde blijven werken.

[RagingPenguin]

Hydra schreef op woensdag 8 september 2021 @ 17:40:
[...]

En natuurlijk zit er een learning curve aan maar als ik sommige Java devs zie die menen te kunnen programmeren maar geen zak van tools als git en maven dependency managers snappen, (heb het niet over wie dan ook in dit topic by they way), dan vind ik dat toch wel een dingetje.

FIFY

[Mugwump]

Sebazzz schreef op woensdag 8 september 2021 @ 22:40:
Nee, dankje, Java is niet een lekker paradigme als je .NET gewend ben. Zeker niet als je net van een 6 maanden lang .NET 5 project afkomt, maar .NET Framework ligt mij ook lekkerder

Maar Hibernate... op zich niets mis mee. Op .NET Framework een hoop met NHibernate gedaan - beviel prima. Soms een bugje hier, bugje daar, breaking change hier - maar een geadvanceerd ORM waar je een hoop aan kan sleutelen. Prima alternatief voor EF 5 (en Linq to SQL daarvoor) destijds.

Het is meer het hele applicatieserver model waar ik mij bij Java aan erger, en zeker bij Java 7 EE dat sommige dingen zo onhandig zijn. Maar deze applicatie hangt aan een infuus, het hoeft voornamelijk tot het einde blijven werken.

Sinds wanneer is Java een paradigme?

[whoami]

Creepy schreef op woensdag 8 september 2021 @ 21:52:
Hibernate..... succes he. Maaruh, omschrijven naar Spring Boot of Dropwizard kan ook he En skip dan Hibernate of alles wat er op lijkt....

(N)Hibernate: niks mis mee vind ik. 't Is al een tijd geleden dat ik het nog gebruikt heb, en ik vraag me af of het tegenwoordig nog 'een ding' is, met al die micro ORM's van tegenwoordig en EF Core op .NET.

[bwerg]

Hydra schreef op woensdag 8 september 2021 @ 17:42:
[Tuurlijk is het minder efficient dan JSON, maar het heeft tenminste een schema. Kan je daar misbruik van maken? Sure. Maar dat maakt een formaat waar je uberhaupt geen schema hebt niet beter natuurlijk

JSON heeft ook schemas. Waarmee ik niet wil zeggen dat ik blijer wordt van JSON dan van XML, maar het heeft schemas.

[Hydra]

Sebazzz schreef op woensdag 8 september 2021 @ 22:40:
Nee, dankje, Java is niet een lekker paradigme

Het is meer het hele applicatieserver model waar ik mij bij Java aan erger

Je loopt ook wel ff een jaar of 10 achter kwa wat jij denkt hoe Java dev eruit ziet hoor. Java EE is gewoon hardstikke dood. Vervelend voor je dat je daar mee in aanraking komt, maar je kunt ook 'nee' zeggen tegen antieke meuk.

[ Voor 12% gewijzigd door Hydra op 09-09-2021 10:50 ]

[Hydra]

bwerg schreef op donderdag 9 september 2021 @ 10:03:
JSON heeft ook schemas.

Daar zijn tools voor, maar er is niet echt een standaard. Daarbij wordt het nauwelijks ondersteund door tooling. Da's wel een flink verschil met XML, waar het altijd een onderdeel van de spec is geweest (beide versies).

[Hydra]

Creepy schreef op woensdag 8 september 2021 @ 21:14:
Zijn er nog mensen die applicatieservers gebruiken?

Ik heb al 8 jaar niet meer met applicatieservers gewerkt. Alles wat niet compleet antiek is, is Spring Boot, Quarkus, Micronaut, Vertx, etc.

Enige wat je 'tegen' Java kan hebben is de taal zelf, maar dan kan je gewoon Kotlin gebruiken.

[armageddon_2k1]

XML minder efficient dan JSON? Moet eerlijk gezegd melden dat wij in de praktijk dat verschil absoluut niet merken......

[Hydra]

armageddon_2k1 schreef op donderdag 9 september 2021 @ 10:49:
XML minder efficient dan JSON? Moet eerlijk gezegd melden dat wij in de praktijk dat verschil absoluut niet merken......

XML heeft meer overhead dan JSON, een XML document met dezelfde 'data' zal over het algemeen een aardig stuk groter zijn dan hetzelfde in JSON.

Maar is het is ook een compleet non-issue. Als efficiency belangrijk is, gebruik je wel Avro of Protobuf ofzo.

Beetje een segway maar; Weet nog dat ik heel lang geleden een intake had bij Rabo Internationaal. Had een gesprek met de 'enterprise architect' voor een software architect rol. Het was vooral de bedoeling dat ik aan developers uit ging leggen dat zijn idee zoals een compleet home-grown serialization formaat een goed idee was, want volgens hem was JSON te inefficient

[Marcj]

Hydra schreef op donderdag 9 september 2021 @ 10:53:
[...]


XML heeft meer overhead dan JSON, een XML document met dezelfde 'data' zal over het algemeen een aardig stuk groter zijn dan hetzelfde in JSON.

Maar is het is ook een compleet non-issue. Als efficiency belangrijk is, gebruik je wel Avro of Protobuf ofzo.

Beetje een segway maar; Weet nog dat ik heel lang geleden een intake had bij Rabo Internationaal. Had een gesprek met de 'enterprise architect' voor een software architect rol. Het was vooral de bedoeling dat ik aan developers uit ging leggen dat zijn idee zoals een compleet home-grown serialization formaat een goed idee was, want volgens hem was JSON te inefficient

Laat hem eerst maar aantonen dat bandbreedte en/of latency het grootste probleem is. Een beetje human readable protocol kan best handig zijn tijdens debuggen Ik ben nog nooit een systeem tegen gekomen waar dit echt de bottleneck is, meestal zijn er genoeg andere problemen om op te focussen

In mijn huidige project zijn we bezig met het opzetten van vele micro-services met behulp van Kotlin en het ktor web framework. En dit alles draait op Kubernetes in AWS. Ik moet zeggen dat ik er wel van gecharmeerd raak. De taal is een enorme vooruitgang op Java, maar je kunt wel eenvoudig zoveel bestaande libraries gebruiken.

[armageddon_2k1]

Hydra schreef op donderdag 9 september 2021 @ 10:53:
[...]


XML heeft meer overhead dan JSON, een XML document met dezelfde 'data' zal over het algemeen een aardig stuk groter zijn dan hetzelfde in JSON.

Maar dan nog, waar gaat het dan langzamer zijn? Het parsen? Dat is echt geen ordegrootte verschil hoor. De meeste tijd, bij grotere bestanden (> 1MB) zit hem in het overpompen en die overhead van XML valt dan helemaal weg doordat het gzipped is en dat aardig de grootte doet afnemen (vanwege de enorme herhaling).

En ik ben een stuk blijer met het human-readable stuk van XML dan dat ik dat ben van JSON. Als we toch aan het debuggen zijn.

[ Voor 9% gewijzigd door armageddon_2k1 op 09-09-2021 11:05 ]

[.oisyn]

Hydra schreef op donderdag 9 september 2021 @ 10:53:
Beetje een segway maar;

https://www.merriam-webst...-segway-commonly-confused

Zo kwam ik er laatst achter dat het blijkbaar wheelbarrow en barrowload was, en niet wheelbarrel en barrelload

[Mugwump]

Wij werken veel met serverless spul op AWS. Net als Hydra heb ik fantastische ervaringen met 'enterprise architecten' die vanuit hun ivoren toren van alles bedenken, zoals XML formaten waarbij elk element een halve kilometer aan namespaces bevat en berichten dusdanig generiek zijn dat je lang niet alle data die je ontvangt ook nodig hebt. Nou levert dat op SQS queues soms al problemen op omdat de maximale berichtgrootte van een berichtje op SQS 256kb is, maar bovendien scheelt het ons denk ik een ton per jaar aan AWS kosten door gewoon bij binnenkomst van dat soort berichtjes de boel door een ACL te halen waarna er nog 5% van de originele omvang overblijft.

[Hydra]

armageddon_2k1 schreef op donderdag 9 september 2021 @ 11:04:
Maar dan nog, waar gaat het dan langzamer zijn?

Lekker selectief gequote... Ik geef volgens mij in de regel eronder een antwoord.

[Hydra]

Mugwump schreef op donderdag 9 september 2021 @ 11:13:
Wij werken veel met serverless spul op AWS. Net als Hydra heb ik fantastische ervaringen met 'enterprise architecten' die vanuit hun ivoren toren van alles bedenken, zoals XML formaten waarbij elk element een halve kilometer aan namespaces bevat en berichten dusdanig generiek zijn dat je lang niet alle data die je ontvangt ook nodig hebt.

Op queues gebruik ik eigenlijk altijd Avro. Heeft ook een schema

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Mugwump]

Hydra schreef op donderdag 9 september 2021 @ 14:53:
[...]


Op queues gebruik ik eigenlijk altijd Avro. Heeft ook een schema


***members only***

Dat is ook altijd mooi inderdaad, van die corporate standaarden die organisatiebreed toolsets afdwingen.
Want ja dan kun je gewoon developers van plek A graaien en op plek B neergooien en dan kunnen ze magischerwijs zo aan de slag.

[Hydra]

Mugwump schreef op donderdag 9 september 2021 @ 15:07:
Dat is ook altijd mooi inderdaad, van die corporate standaarden die organisatiebreed toolsets afdwingen.
Want ja dan kun je gewoon developers van plek A graaien en op plek B neergooien en dan kunnen ze magischerwijs zo aan de slag.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[armageddon_2k1]

Hydra schreef op donderdag 9 september 2021 @ 14:50:
[...]


Lekker selectief gequote... Ik geef volgens mij in de regel eronder een antwoord.

Haha fair enough. Maar hoe moet ik anders discussie punten winnen?

[RagingPenguin]

Mugwump schreef op donderdag 9 september 2021 @ 11:13:
Wij werken veel met serverless spul op AWS. Net als Hydra heb ik fantastische ervaringen met 'enterprise architecten' die vanuit hun ivoren toren van alles bedenken, zoals XML formaten waarbij elk element een halve kilometer aan namespaces bevat en berichten dusdanig generiek zijn dat je lang niet alle data die je ontvangt ook nodig hebt. Nou levert dat op SQS queues soms al problemen op omdat de maximale berichtgrootte van een berichtje op SQS 256kb is, maar bovendien scheelt het ons denk ik een ton per jaar aan AWS kosten door gewoon bij binnenkomst van dat soort berichtjes de boel door een ACL te halen waarna er nog 5% van de originele omvang overblijft.

Nu kan je met JSON natuurlijk ook gewoon je data 100 objecten diep nesten als je wilt, echter is er geen schema standaard waarin een bepaald type architect dat kan afdwingen. (maar hebben we nu een voordeel gevonden van het niet hebben van een schema? ).

[RagingPenguin]

Mugwump schreef op donderdag 9 september 2021 @ 15:07:
[...]


Dat is ook altijd mooi inderdaad, van die corporate standaarden die organisatiebreed toolsets afdwingen.
Want ja dan kun je gewoon developers van plek A graaien en op plek B neergooien en dan kunnen ze magischerwijs zo aan de slag.

O ja, context en domeinkennis is natuurlijk niet belangrijk

[Mugwump]

RagingPenguin schreef op donderdag 9 september 2021 @ 15:54:
[...]


Nu kan je met JSON natuurlijk ook gewoon je data 100 objecten diep nesten als je wilt, echter is er geen schema standaard waarin een bepaald type architect dat kan afdwingen. (maar hebben we nu een voordeel gevonden van het niet hebben van een schema? ).

Ik zei dan ook nergens dat je van JSON geen zooitje kunt maken.

[Hydra]

armageddon_2k1 schreef op donderdag 9 september 2021 @ 15:49:
Haha fair enough. Maar hoe moet ik anders discussie punten winnen?

Sowieso krijg je van mij alle punten die je maar wil

[Hydra]

Mugwump schreef op donderdag 9 september 2021 @ 16:10:
Ik zei dan ook nergens dat je van JSON geen zooitje kunt maken.

"Er een zooitje van maken" is sowieso het grootste talent bij veel devs.

[PrisonerOfPain]

Hydra schreef op vrijdag 10 september 2021 @ 11:20:
[...]
"Er een zooitje van maken" is sowieso het grootste talent bij veel devs.

Het is best een belangrijke skill om te weten waar en wanneer je wel een zooitje kunt maken, en wanneer niet.

[Lethalis]

Hydra schreef op vrijdag 10 september 2021 @ 11:20:
[...]
"Er een zooitje van maken" is sowieso het grootste talent bij veel devs.

Het te graag willen fixen ook

Is niet altijd haalbaar... alleen kom ik daar soms pas na een lange tijd refactoren achter. Dan val je van het ene probleem in het andere, totdat een keer het besef komt dat je niet alle spaghetti kunt ontwarren.

En dan van jezelf balen dat je het überhaupt geprobeerd hebt, omdat je al die tijd geen steek verder gekomen bent.

[ThomasG]

Lethalis schreef op dinsdag 14 september 2021 @ 22:13:
[...]

Het te graag willen fixen ook

Is niet altijd haalbaar... alleen kom ik daar soms pas na een lange tijd refactoren achter. Dan val je van het ene probleem in het andere, totdat een keer het besef komt dat je niet alle spaghetti kunt ontwarren.

En dan van jezelf balen dat je het überhaupt geprobeerd hebt, omdat je al die tijd geen steek verder gekomen bent.

Dit is vooral het probleem bij ontwerpfouten. Wij hebben een stuk software waar een enorme ontwerpfout in zit, en de devs toentertijd hebben daar vrolijk op verder gebouwd in plaats van het oplossen, ondanks dat ze het wisten. Dat is gewoon niet meer recht te trekken zonder de halve applicatie te herschrijven. Management denkt dat er niets aan de hand is, want ze zien toch dat het werkt... Dat we constant door hoepels moeten springen om iets heel eenvoudigs toe te voegen begrijpen ze niet Gelukkig werk ik niet veel meer aan dat project.

[Kalentum]

ThomasG schreef op woensdag 15 september 2021 @ 09:58:
[...]
Dit is vooral het probleem bij ontwerpfouten. Wij hebben een stuk software waar een enorme ontwerpfout in zit, en de devs toentertijd hebben daar vrolijk op verder gebouwd in plaats van het oplossen, ondanks dat ze het wisten. Dat is gewoon niet meer recht te trekken zonder de halve applicatie te herschrijven. Management denkt dat er niets aan de hand is, want ze zien toch dat het werkt... Dat we constant door hoepels moeten springen om iets heel eenvoudigs toe te voegen begrijpen ze niet Gelukkig werk ik niet veel meer aan dat project.

Ik zit nu op een project wat precies dat doet: een datamodel wat een aantal jaren geleden nog wel min of meer OK was maar nu niet meer. Gelukkig hebben we wel support van management om het te fixen, want ze zien ook dat deze technical debt in de weg zit.

[Mugwump]

ThomasG schreef op woensdag 15 september 2021 @ 09:58:
[...]
Dit is vooral het probleem bij ontwerpfouten. Wij hebben een stuk software waar een enorme ontwerpfout in zit, en de devs toentertijd hebben daar vrolijk op verder gebouwd in plaats van het oplossen, ondanks dat ze het wisten. Dat is gewoon niet meer recht te trekken zonder de halve applicatie te herschrijven. Management denkt dat er niets aan de hand is, want ze zien toch dat het werkt... Dat we constant door hoepels moeten springen om iets heel eenvoudigs toe te voegen begrijpen ze niet Gelukkig werk ik niet veel meer aan dat project.

Ik doe ook alweer een tijd een project waarin we een stuk software eigenlijk volledig herontwerpen. Initieel nog wel wat gezeik gehad omdat het traject verkocht is als een lift-and-shiftwerkje en daarom uiteindelijk wel een keer of wat over budget heen zal gaan, maar dat is inmiddels ingezonken en geaccepteerd.
Zeker ook omdat we nu op hetgeen dat al staat wijzigingen binnen een uur in productie hebben staan, waar op het oude systeem nog een proces van weken doorgeakkerd moet worden.

Ondertussen hebben onze vrolijke vrienden in de ivoren toren (enterprise architecture) een compleet nieuw informatiemodel verzonnen en is de vraag wanneer wij dit 'even' kunnen implementeren. Aangezien het oude datamodel destijds bewust volledig is doorgelekt naar afnemers / klanten, gaat dat ook nog leuk worden.

[armageddon_2k1]

Hydra schreef op vrijdag 10 september 2021 @ 11:20:
[...]


"Er een zooitje van maken" is sowieso het grootste talent bij veel devs.

Overal eigenlijk. Een van de belangrijkste leringen van volwassen worden is dat je erachter komt dat 99% van de mensen maar wat doet. Het minimale doen tot de volgende vakantie.

Of ben ik nu te cynisch

[ Voor 3% gewijzigd door armageddon_2k1 op 15-09-2021 15:46 ]

[DevWouter]

armageddon_2k1 schreef op woensdag 15 september 2021 @ 15:46:
[...]


Overal eigenlijk. Een van de belangrijkste leringen van volwassen worden is dat je erachter komt dat 99% van de mensen maar wat doet. Het minimale doen tot de volgende vakantie.

Of ben ik nu te cynisch

Ik zeg bij interviews regelmatig dat ik heel hard werk om zo lui mogelijk te zijn. Soms iets te hard

[ThomasG]

DevWouter schreef op woensdag 15 september 2021 @ 16:27:
[...]


Ik zeg bij interviews regelmatig dat ik heel hard werk om zo lui mogelijk te zijn. Soms iets te hard

Liever lui dan moe

[gekkie]

Liever een beetje moe maar voldaan

[ Voor 17% gewijzigd door gekkie op 15-09-2021 17:10 ]

[AW_Bos]

Iemand deze al gezien?

https://www.werkenbijcoolblue.nl/codemuseum/

CoolBlue gaat voor een deel open-source
Een mooie manier om nieuwe programmeurs te werven.

[ Voor 19% gewijzigd door AW_Bos op 16-09-2021 10:08 ]

[dcm360]

Oh, niet eens stukjes geschreven in Delphi? Dat had wel mooi gepast in een museum.

[Koenvh]

Kun je nog ergens nieuwe ponskaarten kopen?