Het lijkt allemaal nogal in early development te zijn: https://github.com/minvws...-app-backend/pull/2/files , https://github.com/minvws...llers/DevOpsController.cs , https://github.com/minvws...ontentPusherEngine/App.csHMS schreef op donderdag 25 juni 2020 @ 14:26:
Ik kwam deze GitHub repo tegen van de Nederlanse COVID-19 notificatie app, en ik zit met stijgende verbazing door de code heen te bladeren.
Unit testen, niet aanwezig. Rechtstreeks zooi naar de HttpContext response schrijven vanuit een 'command'... wat?
Wel top dat het allemaal 'in the open' gebeurd, maar hoe ze het doen vind ik bedenkelijk
Dat hoop ik toch niet, vanaf 1 juli zou die getest moeten gaan worden in Twente. Of word het een geval van we laten de gebruiker testen en zien wel wat werkt...LEDfan schreef op donderdag 25 juni 2020 @ 14:42:
[...]
Het lijkt allemaal nogal in early development te zijn: https://github.com/minvws...-app-backend/pull/2/files , https://github.com/minvws...llers/DevOpsController.cs , https://github.com/minvws...ontentPusherEngine/App.cs
Waar gaan ze PusherEngine voor gebruiken? Verder interessant wat ze van plan zijn met de DevOpsController
Maar dan begrijp je niet wat ik zeg. Als ik zeg dat een term hip en hype is, dan bedoel ik niet dat een concept per definitie niet zou deugen. Ik vind 'serverless' ook een vreselijke hype, maar toch gebruik ik het veel. Er zijn prima situaties waarin je serverless (als in FaaS) in kunt zetten, maar er zijn ook situaties waar dat niet zo'n goede keuze is. Het feit dat ik het een hype noem slaat dan op het feit dat het de catch-all oplossing is geworden voor alle problemen in developmentland.Hydra schreef op donderdag 25 juni 2020 @ 12:52:
[...]
Nouja, stupid devs gonna stupid. Daar kun je sowieso niks aan doen. Je ziet dat er daar bij heel veel bedrijven gewoon een enorm gebrek is aan ervaren mensen. Maar als je diezelfde developers een monoliet laat bouwen, wordt dat ook een puinhoop.
Heb een voorbeeld gezien van een erg junior team dat 'microservices' deed waarbij alle microservices tegelijkertijd gedeployed moesten worden, en ze ook geen CI/CD hadden. En geen e2e tests. Tja. Die kan beter een monoliet bouwen, maar no way dat dat een monoliet zou worden die je later nog op kunt breken.
Maar ik vind microservices een 'hype' noemen net zoals als 'de cloud' een hype noemen.
Hetzelfde zie je met microservices of zelfs DDD.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Volgens mij begrijp jij niet dat hij hetzelfde zegt. De cloud was ook een een hype en zeker niet altijd de beste optie, maar inmiddels is het wel een trend.
{signature}
Ik denk dat je dan vooral ervaring hebt met teams die microservices veel te klein maken. Microservices zijn gewoon applicaties met een single responsibility. Dat kan nog best een 'groot' ding zijn. Mensen die voor ieder 'object' (Person, User, Order, Product) een aparte service gaan maken, hebben het gewoon niet begrepen.WernerL schreef op donderdag 25 juni 2020 @ 14:28:
Ik ben het deels met je eens maar dit kan ook prima opgelost worden zonder 'microservices'. Ik heb 8 maanden bij een bigCorp gewerkt en daar hadden we ook losse services die door verschillende teams onderhouden werden. Dan kan iedere individuele applicatie nog steeds een monoliet zijn die externe services aanspreekt.
Microservices zijn eigenlijk precies dat wat je beschrijft. Vroeger heette het SOA, nu heet het anders, en je ziet ook al weer dat dat volledig doorschieten nu weer de andere kant op gaat. Over een paar jaar ga je blogposts zien van mensen die van microservices naar een monoliet zijn gegaan, en dan een paar jaar later hoe ze het toch weer op zijn gaan breken. De geschiedenis is een cirkel
https://niels.nu
En de geschiedenis van een hoop code laat zich dan omschrijven als een rond bord met spaghetti bolognese ?
Ik denk dat we het gewoon eens zijn, maar ik vind de term 'hype' vooral iets dat primair negatief is. Dat doet me dan terugdenken aan die mensen die riepen dat de cloud pure hype was. Maar natuurlijk is het altijd zo dat je bij niieuwe dingen ziet dat er een component aan is dat het overhyped wordt. Het stukje "peak of inflated expectations" in de hype cycle:Mugwump schreef op donderdag 25 juni 2020 @ 15:06:
Maar dan begrijp je niet wat ik zeg. Als ik zeg dat een term hip en hype is, dan bedoel ik niet dat een concept per definitie niet zou deugen. Ik vind 'serverless' ook een vreselijke hype, maar toch gebruik ik het veel. Er zijn prima situaties waarin je serverless (als in FaaS) in kunt zetten, maar er zijn ook situaties waar dat niet zo'n goede keuze is. Het feit dat ik het een hype noem slaat dan op het feit dat het de catch-all oplossing is geworden voor alle problemen in developmentland.
Hetzelfde zie je met microservices of zelfs DDD.

https://niels.nu
Net alleen code, ook architecturen. Veel microservice architecturen zijn gebouwd door mensen die echt niet weten waar ze mee bezig waren. Alles roept alles aan, en alles is altijd stuk.gekkie schreef op donderdag 25 juni 2020 @ 15:49:
En de geschiedenis van een hoop code laat zich dan omschrijven als een rond bord met spaghetti bolognese ?
https://niels.nu
Achja de werkelijkheid is soms wat weerbarstiger dan de mooie pure abstractie waar mee je ooit begon.Hydra schreef op donderdag 25 juni 2020 @ 15:50:
[...]
Net alleen code, ook architecturen. Veel microservice architecturen zijn gebouwd door mensen die echt niet weten waar ze mee bezig waren. Alles roept alles aan, en alles is altijd stuk.
Blijft toch mooi tensorflow projectjes, die er dan na een tijd trainen met een totaal onzinnige exception brij ermee kappen, maar even printen welke batch aan files het uit je dataset betreft, ho maar.
[ Voor 20% gewijzigd door gekkie op 25-06-2020 15:58 ]
Was eigenlijk als een grap bedoeld... SorryMatis schreef op donderdag 25 juni 2020 @ 08:48:
[...]
Klopt, we zijn nu langzaamaan processen aan het verplaatsen naar Del Boomi (een iPaaS) zoals @Koenvh al opmerkte

Overigens vind ik de cloud wel een uitkomst, vooral voor kleine projecten. Voor een paar euro heb je al een server "in de cloud". Daarvoor laat ik in de spreekwoordelijke meterkast geen server 24/7 draaien (plus dat m'n internetverbinding dat ook niet aankan). Maar het is niet de magische oplossing voor alles, en ik heb ook genoeg bedrijven gezien die weer op eigen ijzer zijn overgestapt.
🠕 This side up
Klopt, al hoorde ik dat 'cloud is een hype'-verhaal hoofdzakelijk vanuit de beheerhoek. Voor mij als developer was het een verademing om niet 2 maanden te moeten wachten op een VMmetje voor wat dev / test doeleinden omdat men zo druk was en het geen prio had.Hydra schreef op donderdag 25 juni 2020 @ 15:49:
[...]
Ik denk dat we het gewoon eens zijn, maar ik vind de term 'hype' vooral iets dat primair negatief is. Dat doet me dan terugdenken aan die mensen die riepen dat de cloud pure hype was. Maar natuurlijk is het altijd zo dat je bij niieuwe dingen ziet dat er een component aan is dat het overhyped wordt. Het stukje "peak of inflated expectations" in de hype cycle: [Afbeelding].
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Dit is letterlijk de COVID curve van de USA:Hydra schreef op donderdag 25 juni 2020 @ 15:49:
[...]
Ik denk dat we het gewoon eens zijn, maar ik vind de term 'hype' vooral iets dat primair negatief is. Dat doet me dan terugdenken aan die mensen die riepen dat de cloud pure hype was. Maar natuurlijk is het altijd zo dat je bij niieuwe dingen ziet dat er een component aan is dat het overhyped wordt. Het stukje "peak of inflated expectations" in de hype cycle: [Afbeelding].

Toeval???????? Of zit Bill Gates erachter met z'n 5G Azure Cloud Nano bots?
[ Voor 3% gewijzigd door armageddon_2k1 op 25-06-2020 16:38 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
Ah oké, maar een junior mee laten werken aan een project is ook een vorm van leren toch? En was wel benieuwd hoe bedrijven dat normaliter aanpakken met technologieën waarmee niemand nog ervaring heeft.Hydra schreef op woensdag 24 juni 2020 @ 12:08:
[...]
Als iemand die nu aan de andere kant van de tafel zit: als wij een bedrijf inhuren voor werk is het 'leren' van dingen die ook voor andere klanten van toepassing kunnen zijn niet voor onze rekening. Trainen van je personeel doe je in je eigen tijd en niet op onze kosten. Dit stemmen we vooraf ook af; dus als het voor hen dan niet rendabel is, is dat het moment om het te zeggen.
Nice, sa password in source control.LEDfan schreef op donderdag 25 juni 2020 @ 14:42:
[...]
Het lijkt allemaal nogal in early development te zijn: https://github.com/minvws...-app-backend/pull/2/files , https://github.com/minvws...llers/DevOpsController.cs , https://github.com/minvws...ontentPusherEngine/App.cs
Connectionstrings in sourcecontrol, etc...
Zowiezo een appsettings.development.json file in git staan hebben

[ Voor 16% gewijzigd door whoami op 25-06-2020 17:03 ]
https://fgheysels.github.io/
Ik wil ook vast niet weten wat er in de EULA staat ? 'Y'whoami schreef op donderdag 25 juni 2020 @ 16:57:
[...]
Nice, sa password in source control.
Connectionstrings in sourcecontrol, etc...
Zowiezo een appsettings.development.json file in git staan hebben![]()
Als je mensen ermee wilt laten werken zal je toch ergens een settings voor dev moeten omschrijven? Deze bestanden lijken uitsluitend bedoeld om lokale ontwikkeling mogelijk te maken. Of sla ik nu volledig de plank mis?whoami schreef op donderdag 25 juni 2020 @ 16:57:
[...]
Nice, sa password in source control.
Connectionstrings in sourcecontrol, etc...
Zowiezo een appsettings.development.json file in git staan hebben![]()
Read the code, write the code, be the code!
Ja, in een daarvoor bestemde secret store. Niet in versiebeheer in ieder geval.wackmaniac schreef op donderdag 25 juni 2020 @ 17:29:
[...]
Als je mensen ermee wilt laten werken zal je toch ergens een settings voor dev moeten omschrijven? Deze bestanden lijken uitsluitend bedoeld om lokale ontwikkeling mogelijk te maken. Of sla ik nu volledig de plank mis?
[/quote]
The Secret Manager tool doesn't encrypt the stored secrets and shouldn't be treated as a trusted store. It's for development purposes only. The keys and values are stored in a JSON configuration file in the user profile directory.[quote]
Wat is precies de toegevoegde waarde? Niet in git? Maar moet je moet nog steeds ergens de wachtwoord communiceren met je ontwikkelaars.
The Secret Manager tool doesn't encrypt the stored secrets and shouldn't be treated as a trusted store. It's for development purposes only. The keys and values are stored in a JSON configuration file in the user profile directory.[quote]
Wat is precies de toegevoegde waarde? Niet in git? Maar moet je moet nog steeds ergens de wachtwoord communiceren met je ontwikkelaars.
[ Voor 83% gewijzigd door alienfruit op 25-06-2020 18:13 ]
Vragen om zelf een paar credentials aan te maken ?
Beter gewoon gebruik maken van Azure Vault en Azure AppConfig. Dan hoef je helemaal geen credentials te verspreiden, maar kan je gewoon toegang tot users/machines geven.alienfruit schreef op donderdag 25 juni 2020 @ 18:11:
[/quote]
The Secret Manager tool doesn't encrypt the stored secrets and shouldn't be treated as a trusted store. It's for development purposes only. The keys and values are stored in a JSON configuration file in the user profile directory.[quote]
Wat is precies de toegevoegde waarde? Niet in git? Maar moet je moet nog steeds ergens de wachtwoord communiceren met je ontwikkelaars.
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
is dat zo een probleem? Je kan evengoed stellen dat iedere ontwikkelaar zijn eigen DB lokaal heeft draaien en dus zijn eigen connectonstrng heeft.alienfruit schreef op donderdag 25 juni 2020 @ 18:11:
[/quote]
The Secret Manager tool doesn't encrypt the stored secrets and shouldn't be treated as a trusted store. It's for development purposes only. The keys and values are stored in a JSON configuration file in the user profile directory.[quote]
Wat is precies de toegevoegde waarde? Niet in git? Maar moet je moet nog steeds ergens de wachtwoord communiceren met je ontwikkelaars.
Is dat niet zo, dan kan je secrets in bv azure keyvault stoppen en ze zo ophalen. Alles is beter dan secrets in source control te hebben. Ze blijven er voor eeuwig in zitten.
https://fgheysels.github.io/
Ja, maar voor een lokaal ontwikkelomgeving maakt het niet zo veel uit toch? Voor andere omgevingen wil je het niet hebben natuurlijk. Of je het nou in een open secret manager bestand in Users slingert of in repository ipv. een README ergens of in een Confluence pagina. Allemaal niet zo boeiend zolang je het maar niet gebruikt voor productie.
Ik heb wel onlangs Gitleaks in onze CI gegooid eens kijken hoe goed dat werkt.
Ik heb wel onlangs Gitleaks in onze CI gegooid eens kijken hoe goed dat werkt.
[ Voor 10% gewijzigd door alienfruit op 25-06-2020 18:32 ]
Zelfs voor dev geldt bij mij: geen devsettings in sourcecontrol en zeker geen connectonstrings, keys, secrets in sourcecontrol
https://fgheysels.github.io/
Secrets niet in je source control snap ik, maar het probleem van een appsettings.development.json snap ik niet? Wij hebben er gewoon settings voor onze lokale omgeving in staan die bij iedereen gelijk is. Waarom zou je dat niet in mogen checken?
You are not special. You are not a beautiful or unique snowflake. You're the same decaying organic matter as everything else.
Lijkt mij in deze ook vrij onschuldig omdat er ook een docker-compose.yml bij zit met dezelfde settings. Wel handig dat je met 1 keer 'docker-compose up' de boel kan opstarten.
Ik snap niet waarom het zo erg is om een lokaal development wachtwoord dat in docker gebruikt gaat worden in git te zetten. En al helemaal niet waarom overige app config er niet in zou moeten.
Het is juíst handig om dat in git te hebben staan. Dan werkt je docker omgeving out of the box, met direct fatsoenlijke instellingen. In een geval voor mijn applicatie: direct je lokale smtp relay/sink geconfigureerd, db enzo direct naar de dev instance (ook in docker) verwijzen, etc. Natuurlijk wil je er geen api keys van externe partijen in hebben, maar dev is toch alleen maar lokaal.
Als je dit niet in je repository zet, hoe dan wel? Bij nieuwe werknemers zal je dan veel tijd kwijt zijn in het opzetten van de dev environment (je moet zus en zo instellen); of in het geval van open source software moet je het ergens documenteren toch?
Het is juíst handig om dat in git te hebben staan. Dan werkt je docker omgeving out of the box, met direct fatsoenlijke instellingen. In een geval voor mijn applicatie: direct je lokale smtp relay/sink geconfigureerd, db enzo direct naar de dev instance (ook in docker) verwijzen, etc. Natuurlijk wil je er geen api keys van externe partijen in hebben, maar dev is toch alleen maar lokaal.
Als je dit niet in je repository zet, hoe dan wel? Bij nieuwe werknemers zal je dan veel tijd kwijt zijn in het opzetten van de dev environment (je moet zus en zo instellen); of in het geval van open source software moet je het ergens documenteren toch?
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
SharepointF.West98 schreef op vrijdag 26 juni 2020 @ 00:41:
Als je dit niet in je repository zet, hoe dan wel?
Overigens zet ik het meestal niet in Git, maar an sich zie ik hier het probleem niet zo.
🠕 This side up
Het is ook waar je voor betaalt he. Als je een senior-level uurtarief betaalt en er blijkt een junior op te zitten doe constant fouten maakt, dan is het wat anders dan dat we 50e per uur kwijt zijn.esv77 schreef op donderdag 25 juni 2020 @ 16:55:
Ah oké, maar een junior mee laten werken aan een project is ook een vorm van leren toch? En was wel benieuwd hoe bedrijven dat normaliter aanpakken met technologieën waarmee niemand nog ervaring heeft.
https://niels.nu
En dat is dus precies mijn allergie met mensen die 'hype' roepen. Heb gewoon PTSD van die discussies met beheersorganisatiesMugwump schreef op donderdag 25 juni 2020 @ 16:14:
Klopt, al hoorde ik dat 'cloud is een hype'-verhaal hoofdzakelijk vanuit de beheerhoek. Voor mij als developer was het een verademing om niet 2 maanden te moeten wachten op een VMmetje voor wat dev / test doeleinden omdat men zo druk was en het geen prio had.
https://niels.nu
Ik had hier een grap terug geschreven maar eigenlijk hebben we 't hier over best wel veel dode mensen omdat de regering daar vol idioten zit. En da's eigenlijk niet om te lachen. Serious; WTF. Trump met z'n "we need to test less".armageddon_2k1 schreef op donderdag 25 juni 2020 @ 16:38:
Dit is letterlijk de COVID curve van de USA:
[Afbeelding]
Toeval???????? Of zit Bill Gates erachter met z'n 5G Azure Cloud Nano bots?
https://niels.nu
Als het alleen voor lokaal is, is het ook gewoon niet erg. In mijn Spring configs staan ook deze postgres credentials: user: postgres, password: postgres.F.West98 schreef op vrijdag 26 juni 2020 @ 00:41:
Ik snap niet waarom het zo erg is om een lokaal development wachtwoord dat in docker gebruikt gaat worden in git te zetten.
https://niels.nu
Door minder te testen sterven er ook (aantoonbaar) minder mensen aan COVID-19. Simpele struisvogel statistiekHydra schreef op vrijdag 26 juni 2020 @ 10:44:
Ik had hier een grap terug geschreven maar eigenlijk hebben we 't hier over best wel veel dode mensen omdat de regering daar vol idioten zit. En da's eigenlijk niet om te lachen. Serious; WTF. Trump met z'n "we need to test less".
If money talks then I'm a mime
If time is money then I'm out of time
Ik zie het andersHydra schreef op vrijdag 26 juni 2020 @ 10:46:
[...]
Als het alleen voor lokaal is, is het ook gewoon niet erg. In mijn Spring configs staan ook deze postgres credentials: user: postgres, password: postgres.
Wat als je dev database geen lokale database is , maar een database op een public cloud, ergens in een dev environment ?
Of als je dev database wel lokaal is, maar een developer uit je team veranderd die connectionstring eens naar de database in de cloud, en die wijziging wordt toch maar mee gecommit ?
(Het hoeft zelfs niet direct zichtbaar te zijn in de PR; de developer kan zijn fout zelf opmerken en corrigeren, maar als je geen squash commit doet, zit het toch maar mooi in je file history).
En wat betreft developer settings: die wil ik niet in de git repo omdat ik er van uitga dat iedere developer misschien wel zijn eigen settings / connectionstrings heeft. Als jij een developed tegen een lokale database die op jouw systeem draait, dan moet een andere developer die connectionstring die voor jou geldig is, toch aanpassen want hij zal hoogstwaarschijnlijk niet aan de DB kunnen die op jouw box draait.
https://fgheysels.github.io/
En toch, als je kijkt naar de oversterfte in de VS dan valt die ook wel weer mee.armageddon_2k1 schreef op donderdag 25 juni 2020 @ 16:38:
[...]
Dit is letterlijk de COVID curve van de USA:
[Afbeelding]
Toeval???????? Of zit Bill Gates erachter met z'n 5G Azure Cloud Nano bots?
Zeer vergelijkbaar met Europa, en ondanks de aanhoudende hoge testresultaten daar loopt dat getal ook gewoon terug.
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
Ik sluit me aan bij whoami boven mij.
Daarom gewoon een appsettings.Example.json comitten met dev-defaults die iedere developer lekker zelf kan wijzigen in zijn eigen appsettings.Development.json.
Daarom gewoon een appsettings.Example.json comitten met dev-defaults die iedere developer lekker zelf kan wijzigen in zijn eigen appsettings.Development.json.
Roses are red, violets are blue, unexpected '{' on line 32.
Dat is toch compleet wat anders? Volgens mij hebben we 't duidelijk over een 'lokaal' test ding dat niet van buiten te bereiken is.whoami schreef op vrijdag 26 juni 2020 @ 11:15:
Ik zie het anders
Wat als je dev database geen lokale database is , maar een database op een public cloud, ergens in een dev environment ?
Zelfde wat betreft je opmerking over gewoon flinke fouten maken. Is dat een afweging? Sure. Maar dat doe je normaliter met een apart profile zodat je uberhaupt de config niet hoeft aan te passen. Als je dat toestaat ga je wel meer fouten maken.
Edit: Ik denk dat mijn ervaring 'gekleurd' is door hoe Spring met configs werkt. Als je altijd maar 1 config file hebt en die moet editten om dingen lokaal te draaien e.d., dan kun je 'em beter 'gitignoren'. Maar dat heeft weinig met passwords te maken; je kunt ook perongeluk prod settings stuk maken.
[ Voor 43% gewijzigd door Hydra op 26-06-2020 11:47 ]
https://niels.nu
Ik denk dat ik een beetje 'verwend' ben met hoe Spring omgaat met profiles. De default profile heeft de confiig om je systeem lokaal te draaien, dus tegen een lokale DB. Dan heb je pro en test profiles waar de config settings (ex secrets) in staan voor die omgevingen. En dan is er nog een local profile die je .gitignored waarin je je eigen shit kan doen.WernerL schreef op vrijdag 26 juni 2020 @ 11:38:
Daarom gewoon een appsettings.Example.json comitten met dev-defaults die iedere developer lekker zelf kan wijzigen in zijn eigen appsettings.Development.json.
Er is dus niet 'maar' 1 configfile. Spring legt deze over elkaar heen voor je.
https://niels.nu
Symfony werkt op een vergelijkbare manier als Spring als ik lees hoe @Hydra het beschrijft. Dan kun je gewoon netjes .env.development committen en als de developer zelf zijn database wil draaien kun je door middel van .env.development.local je eigen connectiestring gebruiken.
Als je je ontwikkelomgeving hebt opgetuigd met bijvoorbeeld docker-compose is dat een hele fijne manier van werken.
Als je je ontwikkelomgeving hebt opgetuigd met bijvoorbeeld docker-compose is dat een hele fijne manier van werken.
Dat is ook hoe de configuratie via Microsoft.Extensions.Configuration werkt. Je kan allerlei verschillende sources over elkaar heen leggen en samenvoegen. Uiteraard zijn er ook packages voor environment variables, KeyVaults, en noem het maar op.Hydra schreef op vrijdag 26 juni 2020 @ 11:45:
[...]
Ik denk dat ik een beetje 'verwend' ben met hoe Spring omgaat met profiles. De default profile heeft de confiig om je systeem lokaal te draaien, dus tegen een lokale DB. Dan heb je pro en test profiles waar de config settings (ex secrets) in staan voor die omgevingen. En dan is er nog een local profile die je .gitignored waarin je je eigen shit kan doen.
Er is dus niet 'maar' 1 configfile. Spring legt deze over elkaar heen voor je.
Volgens mij bedoelt @whoami dat er bij het opzetten van de omgeving door Developer A een lokale omgeving opgetuigd kan worden. Als hij die config vervolgens commit in sourcecontrol, en Developer B denkt 'ik vind een cloud-db nu even handiger voor mezelf om geen db-engine te hoeven installeren' dus die wijzigt de config én commit dat vervolgens (per abuis, maar kun je gerust over het hoofd zien), dan staat er ineens een cloudconfig 'voor altijd' in je repository.Hydra schreef op vrijdag 26 juni 2020 @ 11:41:
[...]
Dat is toch compleet wat anders? Volgens mij hebben we 't duidelijk over een 'lokaal' test ding dat niet van buiten te bereiken is.
Je ziet een nieuwe piek in nieuwe cases pas in juni. Doden als gevolg van daadwerkelijke nieuwe cases volgen pas later. Het is dus nog te vroeg om daar echt iets over te zeggen.Grijze Vos schreef op vrijdag 26 juni 2020 @ 11:38:
[...]
En toch, als je kijkt naar de oversterfte in de VS dan valt die ook wel weer mee.
Zeer vergelijkbaar met Europa, en ondanks de aanhoudende hoge testresultaten daar loopt dat getal ook gewoon terug.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Symfony is dan ook wel redelijk gebaseerd op Spring.dev10 schreef op vrijdag 26 juni 2020 @ 12:10:
Symfony werkt op een vergelijkbare manier als Spring als ik lees hoe @Hydra het beschrijft. Dan kun je gewoon netjes .env.development committen en als de developer zelf zijn database wil draaien kun je door middel van .env.development.local je eigen connectiestring gebruiken.
Als je je ontwikkelomgeving hebt opgetuigd met bijvoorbeeld docker-compose is dat een hele fijne manier van werken.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Dan moet je daar een lokaal dev-specific profiel/override van maken, die wel in de ignore zit. Zo heb ik ook een applicatie die zowel in Docker, als gewoon direct in IIS draait; daar heb ik dan appsettings.Development.Docker.json en appsettings.Development.IIS.json voor. Op die manier kan je een ignored profiel maken voor de cloud-dev-db.whoami schreef op vrijdag 26 juni 2020 @ 11:15:
[...]
Ik zie het anders
Wat als je dev database geen lokale database is , maar een database op een public cloud, ergens in een dev environment?
Daarom maak je dus dev-specific profielen aan waar je dingen in wijzigt. Daar kan je eventueel zelfs een template voor maken. Maar inderdaad, je voorkomt dan geen domme fouten. Maar diezelfde domme fouten kunnen mensen ook maken door direct appsettings.json zelf te wijzigen, of, god forbid, de connection string te hardcoden.Of als je dev database wel lokaal is, maar een developer uit je team veranderd die connectionstring eens naar de database in de cloud, en die wijziging wordt toch maar mee gecommit ?
Dat is natuurlijk een andere usecase, en dan is het goed om dev specific conncetion strings te hebben in je eigen profiel. Maar als je dus in Docker draait, dan heb je wel die uniforme omgeving waarbij je in principe de connection strings kan delen.(Het hoeft zelfs niet direct zichtbaar te zijn in de PR; de developer kan zijn fout zelf opmerken en corrigeren, maar als je geen squash commit doet, zit het toch maar mooi in je file history).
En wat betreft developer settings: die wil ik niet in de git repo omdat ik er van uitga dat iedere developer misschien wel zijn eigen settings / connectionstrings heeft. Als jij een developed tegen een lokale database die op jouw systeem draait, dan moet een andere developer die connectionstring die voor jou geldig is, toch aanpassen want hij zal hoogstwaarschijnlijk niet aan de DB kunnen die op jouw box draait.
Zo werkt het ook in .NET; in principe heb je appsettings.json waar je dingen overheen kan leggen. Dus ook al zet je de appsettings.Development.json in de ignore, dan kunnen stomme developers nog steeds de source appsettings.json aanpassen.Hydra schreef op vrijdag 26 juni 2020 @ 11:45:
[...]
Ik denk dat ik een beetje 'verwend' ben met hoe Spring omgaat met profiles. De default profile heeft de confiig om je systeem lokaal te draaien, dus tegen een lokale DB. Dan heb je pro en test profiles waar de config settings (ex secrets) in staan voor die omgevingen. En dan is er nog een local profile die je .gitignored waarin je je eigen shit kan doen.
Er is dus niet 'maar' 1 configfile. Spring legt deze over elkaar heen voor je.
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
Dat klopt, maar als je die twee maanden ervoor kijkt, dan zie je dat de VS een veel minder afvlakkende curve heeft van infecties dan Europa. En toch verloopt de oversterfte volgens dezelfde lijn als Europa. Dat vind ik heel bijzonder..oisyn schreef op vrijdag 26 juni 2020 @ 12:19:
[...]
Je ziet een nieuwe piek in nieuwe cases pas in juni. Doden als gevolg van daadwerkelijke nieuwe cases volgen pas later. Het is dus nog te vroeg om daar echt iets over te zeggen.
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
Idd, maar eigenlijk is het hele probleem eigenlijk te herleiden naar het feit dat je secrets in een configuration-store zet.HMS schreef op vrijdag 26 juni 2020 @ 12:15:
[...]
Dat is ook hoe de configuratie via Microsoft.Extensions.Configuration werkt. Je kan allerlei verschillende sources over elkaar heen leggen en samenvoegen. Uiteraard zijn er ook packages voor environment variables, KeyVaults, en noem het maar op.
Ik denk dat het beter zou zijn als er gefaciliteerd wordt dat er een onderscheid gemaakt wordt tussen configuration & secrets, en dat die scheiding ook duidelijk is in het framework.
Ik ben dus eigenlijk wel een voorstander van dit idee.
https://fgheysels.github.io/
Tja, dan kom je denk ik in de discussie terecht wat nou precies een secret moet zijn en waar je dat moet opslaan. In dit specifieke geval denk ik niet dat het echt een probleem is, zeker omdat het een publiek project is. Hoe makkelijker het is om de boel te draaien en testen, hoe beter.whoami schreef op vrijdag 26 juni 2020 @ 14:26:
[...]
Idd, maar eigenlijk is het hele probleem eigenlijk te herleiden naar het feit dat je secrets in een configuration-store zet.
Ik denk dat het beter zou zijn als er gefaciliteerd wordt dat er een onderscheid gemaakt wordt tussen configuration & secrets, en dat die scheiding ook duidelijk is in het framework.
Ik ben dus eigenlijk wel een voorstander van dit idee.
Wat ik wel een probleem vind is hoe makkelijk het is om een waarde in je configuratie op je development machine aan te passen. Om nou te zeggen dat de 'dotnet secrets' command line tool erg lekker werkt...
Dus wat gaan mensen doen? Die passen de version controlled configuratie files aan, en checken dat vervolgens in. Dus ik denk dat het meer richting een tooling issue gaat, dan dat een configuratie item wat toevallig ook geheim moet zijn in de configuratie staat.
Daarnaast zouden ontwikkelaars even moeten kijken wat ze nou precies inchecken, dan is dat probleem ook weg. Tenminste, ik neem aan dat we de end-of-day commit stijl ondertussen aan het verlaten zijn
Uit je gelinkte issue door David Fowler:
Daar ben ik het wel mee eens, dat je in je applicatie kan zien dat een bepaalde waarde anders behandeld moet worden. Maar om nou een compleet andere configuratie store te maken alleen voor die change.. neuh.The idea of a secret as a first class concept has legs.
Er zijn genoeg methodes om die waardes buiten je source control om in de applicatie te krijgen, of je dat nou met een cloud service (Azure KeyVault, AWS Secret Store), environment variables, of op een andere manier doet.
Zelf ga ik stiekem voor de blah__blah__connectionString manier voor ASP.Net Core
Helemaal mee eens, maar het één sluit het ander niet uit.HMS schreef op vrijdag 26 juni 2020 @ 15:25:
Daarnaast denk ik trouwens dat het makkelijker is om van wachtwoorden en dergelijke af te stappen richting iets als Integrated Authentication/Managed Service Identities. Kan je hem ook niet per ongeluk online gooien
Secrets worden bv opgeslagen in KeyVault; in die keyvault kan een api-key zitten, of een connectionstring naar een on-prem database.
KeyVault benader je via managed identity, maar het heeft wel zin om in je code duidelijk een opsplitsing te hebben tussen configuratie & secrets.
Als je KeyVault als configuration source gaat toevoegen bv, dan ga je volgens mij voor iedere config setting die je wil ophalen, ook een call hebben naar KeyVault.
https://fgheysels.github.io/
Dat is ook een probleem. Als je niet meer kan opletten om dat ene bestand niet te committen, welke andere fouten maak je dan in je programma?HMS schreef op vrijdag 26 juni 2020 @ 15:23:
[...]
Daarnaast zouden ontwikkelaars even moeten kijken wat ze nou precies inchecken, dan is dat probleem ook weg.
En als je dat niet weet te repareren met git rebase??

Op mijn project worden branches pas na een rebase naar de master gecommit. Je zou verwachten dat we dus dat we wel weten hoe dat werkt en er gebruik van maken. Maar ik zie vrijwel niemand die zijn branche wat netter heeft gemaakt door een paar commits samen te voegen.
let the past be the past.
Ja precies, ik ben ook wel eens wat te snel geweest met een git addHMS schreef op vrijdag 26 juni 2020 @ 15:23:
[...]
Dus wat gaan mensen doen? Die passen de version controlled configuratie files aan, en checken dat vervolgens in. Dus ik denk dat het meer richting een tooling issue gaat, dan dat een configuratie item wat toevallig ook geheim moet zijn in de configuratie staat.
Bij ons staat configuratie in een .env die in .gitignore staat dus je kan prutsen wat je wilt. En als je opnieuw wil dan kun je een nieuwe .env genereren vanuit de secrets store
Volgens mij moet je het makkelijk maken om het goed te doen, en moeilijk om het verkeerd te doen, en met al deze keyvaultachtige oplossingen krijg ik het omgekeerde gevoel. Niet dat ik direct een betere oplossing heb, overigens.
Over secrets e.d. gesproken. Gisteren was ook dit in het nieuws: nieuws: Safari kan gebruikers bij websites laten inloggen met Touch ID of Fac...
Ik had al wel eerder naar Webauthn gekeken, maar toen werkte 't niet lekker, dus heb ik 't maar laten zitten. Nu nog eens de demo geprobeerd, en het werkte direct, zowel met Windows Hello als met mijn Yubikey. Mijn enige probleem nu is: wat doe je op een moment dat iemand zijn token/apparaat kwijtraakt/kapot gaat/gestolen wordt? Want back-up tokens, SMS-verificatie, e-mailreset e.d. zijn wel mogelijk, maar verre van ideaal.
Over secrets e.d. gesproken. Gisteren was ook dit in het nieuws: nieuws: Safari kan gebruikers bij websites laten inloggen met Touch ID of Fac...
Ik had al wel eerder naar Webauthn gekeken, maar toen werkte 't niet lekker, dus heb ik 't maar laten zitten. Nu nog eens de demo geprobeerd, en het werkte direct, zowel met Windows Hello als met mijn Yubikey. Mijn enige probleem nu is: wat doe je op een moment dat iemand zijn token/apparaat kwijtraakt/kapot gaat/gestolen wordt? Want back-up tokens, SMS-verificatie, e-mailreset e.d. zijn wel mogelijk, maar verre van ideaal.
🠕 This side up
Wat ideaal is zou ik aan de gebruiker over laten? En dus meerdere opties bieden. Bij bv Bitwarden (_rs) heb ik m'n YubiKey gekoppeld, en volgens mij ook een recovery code gehad, maar je kunt gewoon meerdere YubiKeys koppelen, dat is dus ook al een optie om kwijtgeraakt / diefstal / gestolen "op te lossen". Wat je ook vaak leest is dat wordt aanbevolen om niet één YubiKey te hebben, maar op zijn minst twee, waarvan je eentje veilig opbergt. Zolang je dan dus zorgt dat beiden wel zijn bijgewerkt (of in ieder geval de echt belangrijke dingen. Als je service A alsnog kunt resetten met een mail naar B zou een goede MFA op B het niet perse onveiliger maken als je de hardware token voor A kwijt bent).Koenvh schreef op vrijdag 26 juni 2020 @ 15:59:
Over secrets e.d. gesproken. Gisteren was ook dit in het nieuws: nieuws: Safari kan gebruikers bij websites laten inloggen met Touch ID of Fac...
Ik had al wel eerder naar Webauthn gekeken, maar toen werkte 't niet lekker, dus heb ik 't maar laten zitten. Nu nog eens de demo geprobeerd, en het werkte direct, zowel met Windows Hello als met mijn Yubikey. Mijn enige probleem nu is: wat doe je op een moment dat iemand zijn token/apparaat kwijtraakt/kapot gaat/gestolen wordt? Want back-up tokens, SMS-verificatie, e-mailreset e.d. zijn wel mogelijk, maar verre van ideaal.
Da's natuurlijk handig voor jou en mij, maar ik weet niet of die keuze positief is de spreekwoordelijke Henk en Ingrid. Het gaat hier overigens om een publieke website, niet iets wat alleen voor één bedrijf beschikbaar is (want daar kun je dat gewoon door de helpdesk laten doen). Overigens is meerdere Yubikeys natuurlijk een goed idee, maar daarvoor zijn ze vaak net te prijzig.RobertMe schreef op vrijdag 26 juni 2020 @ 16:07:
[...]
Wat ideaal is zou ik aan de gebruiker over laten? En dus meerdere opties bieden. Bij bv Bitwarden (_rs) heb ik m'n YubiKey gekoppeld, en volgens mij ook een recovery code gehad, maar je kunt gewoon meerdere YubiKeys koppelen, dat is dus ook al een optie om kwijtgeraakt / diefstal / gestolen "op te lossen". Wat je ook vaak leest is dat wordt aanbevolen om niet één YubiKey te hebben, maar op zijn minst twee, waarvan je eentje veilig opbergt. Zolang je dan dus zorgt dat beiden wel zijn bijgewerkt (of in ieder geval de echt belangrijke dingen. Als je service A alsnog kunt resetten met een mail naar B zou een goede MFA op B het niet perse onveiliger maken als je de hardware token voor A kwijt bent).
🠕 This side up
Daarom de keuze bij de gebruiker laten en meerdere opties bieden? Punt is uiteraard wel dat als je de keuze tot bv TOTP per SMS geeft en iemand dat instelt als backup het ook de beveiliging van het hele systeem onderuit kan halen. Immers is het zwakste punt dan het SMS stuk, en maakt die YubiKey als alternatief het niet meer veiliger.Koenvh schreef op vrijdag 26 juni 2020 @ 16:11:
[...]
Da's natuurlijk handig voor jou en mij, maar ik weet niet of die keuze positief is de spreekwoordelijke Henk en Ingrid. Het gaat hier overigens om een publieke website, niet iets wat alleen voor één bedrijf beschikbaar is (want daar kun je dat gewoon door de helpdesk laten doen).
Valt wel mee toch? De U2F variant (waar het hier over gaat en minste is wat nodig is voor Webauthn) kost uit mijn hoofd twee of drie tientjes. (De 5 kost dan wel weer om en nabij het dubbele).Overigens is meerdere Yubikeys natuurlijk een goed idee, maar daarvoor zijn ze vaak net te prijzig.
Da's mijn punt nu juist. Enerzijds wil je juist goede beveiliging (Yubikey), maar aan de andere kant blijven mensen ook mensen, en techniek techniek. Je kunt er niet vanuit gaan dat het nooit kapot gaat. Wat ik eigenlijk zou willen is dat met je Yubikey een officieel certificaat zou komen, waarmee je later bij Yubikey een originele herstelsleutel kunt bestellen, zoals dat nu ook al met sommige fysieke sloten kan. Of dat je dat zelf kunt printen (bij het genereren uiteraard), al is dat natuurlijk minder veilig. 't Is voor mij de reden dat ik m'n Yubikey (4) eigenlijk minder gebruik dan ik zou willen.RobertMe schreef op vrijdag 26 juni 2020 @ 16:16:
[...]
Daarom de keuze bij de gebruiker laten en meerdere opties bieden? Punt is uiteraard wel dat als je de keuze tot bv TOTP per SMS geeft en iemand dat instelt als backup het ook de beveiliging van het hele systeem onderuit kan halen. Immers is het zwakste punt dan het SMS stuk, en maakt die YubiKey als alternatief het niet meer veiliger.
[...]
Valt wel mee toch? De U2F variant (waar het hier over gaat en minste is wat nodig is voor Webauthn) kost uit mijn hoofd twee of drie tientjes. (De 5 kost dan wel weer om en nabij het dubbele).
Ook hoop ik dat een eID gebruiken voor Webauthn in de toekomst mogelijk is, want dan hoeven de meeste mensen geen apart apparaat daar meer voor aan te schaffen (althans, vanaf januari 2021 werkt de Nederlandse identiteitskaart als het goed is ook als eID, en ik kan me wel voorstellen dat mensen €60 te gortig vinden), maar aangezien m'n eID sowieso niet werkt onder Firefox zonder add-on ben ik bang dat dat nog wel even gaat duren.
🠕 This side up
Dit kan niet. Een slot is een mechanisch iets met een vaste afstelling. Een YubiKey (/U2F hardware sleutel) is dat niet. Per website wordt immers een nieuw public/private key pair gegenereerd. En YubiCo weet uiteraard niet welke private keys er voor jouw YubiKey zijn aangemaakt en kan die dus onmogelijk herstellen.Koenvh schreef op zaterdag 27 juni 2020 @ 17:56:
Je kunt er niet vanuit gaan dat het nooit kapot gaat. Wat ik eigenlijk zou willen is dat met je Yubikey een officieel certificaat zou komen, waarmee je later bij Yubikey een originele herstelsleutel kunt bestellen, zoals dat nu ook al met sommige fysieke sloten kan.
Uitprinten lijkt mij eigenlijk sowieso geen handige optie (al is het maar dat het vrij onhandig is om hem opnieuw in te typen), maar ik begrijp wat je bedoelt. Een (versleutelde) backup kunnen maken van de data op de YubiKey zou een optie kunnen zijn. Alleen brengt ook dat weer beveiligingsrisico's met zich mee. In relatie daaraan is het blijkbaar ook van YubiCo een bewuste keuze om geen firmware upgrades voor de YubiKeys te maken, omdat dat ook weer kans geeft op malafide firmwares die de private keys lekken etc.Of dat je dat zelf kunt printen (bij het genereren uiteraard), al is dat natuurlijk minder veilig.
Maar in principe heb je gelijk, iets van een backup optie zou eigenlijk wel een vereiste moeten zijn. Al is het maar dat je bv de data van de ene YubiKey kunt syncen naar een andere YubiKey als zijnde backup (voor diegenen die wel twee YubiKeys kopen en een als backup bewaren). Maar beveiligingstechnisch is het natuurlijk wel een dingetje. Wellicht dat het in die zin wellicht ook beter is als er een splitsing komt in "die hard security" vs "betere security, maar wel meer user friendly" en dus hardware sleutels die je wel kunt backuppen etc.
Zoiets zou wellicht kunnen. Beetje hetzelfde id als dat Chrome + Android telefoon ook als hardware token kan werken. Dat je op PC wilt inloggen, op telefoon een melding krijgt die je moet bevestigen en via Bluetooth gecontroleerd wordt of de telefoon ook daadwerkelijk in de buurt van de PC is. Zoiets zou wellicht dus ook kunnen met eID waarbij je op telefoon de ID kaart scant en op basis daarvan iets terug gecommuniceerd wordt naar de PC waarop je aan het inloggen bent.Ook hoop ik dat een eID gebruiken voor Webauthn in de toekomst mogelijk is, want dan hoeven de meeste mensen geen apart apparaat daar meer voor aan te schaffen (althans, vanaf januari 2021 werkt de Nederlandse identiteitskaart als het goed is ook als eID, en ik kan me wel voorstellen dat mensen €60 te gortig vinden), maar aangezien m'n eID sowieso niet werkt onder Firefox zonder add-on ben ik bang dat dat nog wel even gaat duren.
@RobertMe Inderdaad. Ik snap de overweging van Yubico wel, en in een bedrijfssetting waar iedereen zo'n ding heeft om mee in te loggen op hun werk-pc en werkomgeving is het natuurlijk ook een hele logische keuze. Immers, het is ontzettend veilig, en mocht de sleutel kwijtraken, dan kun je altijd naar de helpdesk gaan en zeggen "Ik ben m'n sleutel kwijt". Dat je persoon <X> bent kunnen ze wel in persoon identificeren.
Online gaat dat natuurlijk wat lastiger (de meeste websites kennen mijn e-mailadres en naam, maar dat is 't dan wel zo'n beetje), en dan zou ik liever de iets-minder-veilige oplossing kiezen dan zelf buitengesloten worden.
Overigens heb je daar geen telefoon voor nodig, een kaartlezer zou genoeg zijn. Zo dus:
[YouTube: Aanmelden met eID kaartlezer]
Dat werkt op dit moment al voor websites die specifiek eID-ondersteuning hebben, maar lijkt nog niet met Webauthn te werken. Voor de Duitse eID-kaart is er al wel een add-on (https://addons.mozilla.or...webauthn-eid-for-firefox/ ), maar het zou natuurlijk mooier zijn als het standaard met elke eID-kaart zou werken in Webauthn.
Online gaat dat natuurlijk wat lastiger (de meeste websites kennen mijn e-mailadres en naam, maar dat is 't dan wel zo'n beetje), en dan zou ik liever de iets-minder-veilige oplossing kiezen dan zelf buitengesloten worden.
Overigens heb je daar geen telefoon voor nodig, een kaartlezer zou genoeg zijn. Zo dus:
[YouTube: Aanmelden met eID kaartlezer]
Dat werkt op dit moment al voor websites die specifiek eID-ondersteuning hebben, maar lijkt nog niet met Webauthn te werken. Voor de Duitse eID-kaart is er al wel een add-on (https://addons.mozilla.or...webauthn-eid-for-firefox/ ), maar het zou natuurlijk mooier zijn als het standaard met elke eID-kaart zou werken in Webauthn.
🠕 This side up
If money talks then I'm a mime
If time is money then I'm out of time
Volgens F12 komt de postcode neer op Nederland, TX, USA.Matis schreef op zondag 28 juni 2020 @ 10:44:
Wait wut?!
[Afbeelding]
Het wordt nog beter![]()
[Afbeelding]
Da's wel een eindje weg ja.
Ik werk voornamelijk aan C#- en TypeScript-projecten in Visual Studio, en een gemiddelde commit raakt zo 5-10 bestanden, en ik commit een handvol keren per dag. Het is erg foutgevoelig om met de hand bestanden toe te voegen, en iedere keer te zorgen dat je configuratiebestand niet word meegestuurd.SPee schreef op vrijdag 26 juni 2020 @ 15:56:
[...]
Dat is ook een probleem. Als je niet meer kan opletten om dat ene bestand niet te committen, welke andere fouten maak je dan in je programma?
En als je dat niet weet te repareren met git rebase??![]()
Op mijn project worden branches pas na een rebase naar de master gecommit. Je zou verwachten dat we dus dat we wel weten hoe dat werkt en er gebruik van maken. Maar ik zie vrijwel niemand die zijn branche wat netter heeft gemaakt door een paar commits samen te voegen.
En ja, ik bekijk wat ik commit voor ik het commit, en nog eens voor ik het push, maar iedere handmatige actie die voor problemen zorgt als 'ie wordt vergeten, is een actie die je zou moeten automatiseren. Developers blijken achteraf toch steeds maar mensen.
Ik heb daar dus een andere oplossing voor nodig, zoals een configuratie die op development voor iedereen gelijk is, of een externe configuratiebron. Liefst niet met environmentvariabelen.
[ Voor 45% gewijzigd door CodeCaster op 28-06-2020 10:59 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Oh ja, de winkelzoeker start daar ook als ik 5131 of 5126 als PC opgeef: https://www.plus.nl/supermarktenCodeCaster schreef op zondag 28 juni 2020 @ 10:49:
Volgens F12 komt de postcode neer op Nederland, TX, USA.
Da's wel een eindje weg ja.
4731 komt wel weer in de goede regio terecht

If money talks then I'm a mime
If time is money then I'm out of time
Werd eerder ook al aangehaald, maar kun je dat configuratiebestand niet in de .gitignore zetten? Danwel die van de repo zelf, danwel die van je lokale machine die van toepassing is op alle repos op die machine.CodeCaster schreef op zondag 28 juni 2020 @ 10:49:
Ik werk voornamelijk aan C#- en TypeScript-projecten in Visual Studio, en een gemiddelde commit raakt zo 5-10 bestanden, en ik commit een handvol keren per dag. Het is erg foutgevoelig om met de hand bestanden toe te voegen, en iedere keer te zorgen dat je configuratiebestand niet word meegestuurd.
En ja, ik bekijk wat ik commit voor ik het commit, en nog eens voor ik het push, maar iedere handmatige actie die voor problemen zorgt als 'ie wordt vergeten, is een actie die je zou moeten automatiseren. Developers blijken achteraf toch steeds maar mensen.
Ik heb daar dus een andere oplossing voor nodig, zoals een configuratie die op development voor iedereen gelijk is, of een externe configuratiebron. Liefst niet met environmentvariabelen.
BertS schreef op maandag 29 juni 2020 @ 11:18:
En toen was het stil op Github...
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Die hebben wat last van outages.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Aan het knielen voor de nieuwe master ?
(zou wel tijd worden, hoop opensource projecten zitten nu in de wacht op het verdict van github waar iedereen zich aan gaat conformeren).
(zou wel tijd worden, hoop opensource projecten zitten nu in de wacht op het verdict van github waar iedereen zich aan gaat conformeren).
[ Voor 64% gewijzigd door gekkie op 29-06-2020 12:45 ]
Welke open source projecten dan?gekkie schreef op maandag 29 juni 2020 @ 12:44:
Aan het knielen voor de nieuwe master ?
(zou wel tijd worden, hoop opensource projecten zitten nu in de wacht op het verdict van github waar iedereen zich aan gaat conformeren).
En waarom zou je in vredesnaam moeten wachten?
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ik ben bang dat we er nooit achter zullen komenMugwump schreef op maandag 29 juni 2020 @ 13:20:
[...]
En waarom zou je in vredesnaam moeten wachten?
Xen o.a., ondanks dat ze niet hoofdzakelijk op github hosten.
Onder andere in naam van de vrede inderdaad. Scheelt een hoop discussie over wat het uiteindelijk dan zou moeten worden. Plus dat men kennelijk wat github vindt en doet nog steeds als defacto standaard ziet.Mugwump schreef op maandag 29 juni 2020 @ 13:20:
[...]
En waarom zou je in vredesnaam moeten wachten?
En ze daarmee dus ook hun keuze van de nieuwe benaming voor master er afhankelijk van maken. Dus zolang ze er daar nog niet uit zijn gebeurd er niet zo veel.
Want? Je kunt niet werken totdat er een nieuwe default branch naam is gekozen?gekkie schreef op maandag 29 juni 2020 @ 13:55:
[...]
Onder andere in naam van de vrede inderdaad. Scheelt een hoop discussie over wat het uiteindelijk dan zou moeten worden. Plus dat men kennelijk wat github vindt en doet nog steeds als defacto standaard ziet.
En ze daarmee dus ook hun keuze van de nieuwe benaming voor master er afhankelijk van maken. Dus zolang ze er daar nog niet uit zijn gebeurd er niet zo veel.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Owh interpreteer je het zo, uhmm neu dat lukt meestal nog wel geloof ikMugwump schreef op maandag 29 juni 2020 @ 13:59:
[...]
Want? Je kunt niet werken totdat er een nieuwe default branch naam is gekozen?
Ja ik dacht ook dat ze geblokt waren. In het geval van Xen, wat bedoel je dan precies?gekkie schreef op maandag 29 juni 2020 @ 14:12:
[...]
Owh interpreteer je het zo, uhmm neu dat lukt meestal nog wel geloof ik
Kwam net deze nerdversie van The Onion tegen. Sommige artikelen zijn best geslaagd.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Mugwump schreef op maandag 29 juni 2020 @ 17:14:
Kwam net deze nerdversie van The Onion tegen. Sommige artikelen zijn best geslaagd.
Apple's self-driving car will run on proprietary form of electricity incompatible with The Standard Model of particle physics

If money talks then I'm a mime
If time is money then I'm out of time
Als gedwongen ThinkPad gebruiker kan ik deze wel waarderen
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Dan veranderen ze het latergekkie schreef op maandag 29 juni 2020 @ 13:52:
[...]
Xen o.a., ondanks dat ze niet hoofdzakelijk op github hosten.
Je hoeft alleen maar je Azure Devops, CircleCI, Docker Hub, GitVersioning, README, CONTRIBUTING.md te herconfigureren en vervolgens je git historie te herschrijven dat elke "merge changes from 'master'" is herschreven naar de correcte tekst, de tags te hertaggen, en software waar de master branch in het build ID zit opnieuw te compileren en te publiceren.
Ik hoop niet dat ik hier nog een /s aan moet toevoegen.
[ Voor 5% gewijzigd door Sebazzz op 29-06-2020 23:19 ]
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Hehe de historie herschrijven. dat is wel de strekking van de quote die de afgelopen maand in mijn hoofd is opgekomen.
De man schreef in 1948 al zeer zinnige dingen.“Every record has been destroyed or falsified, every book rewritten, every picture has been repainted, every statue and street building has been renamed, every date has been altered. And the process is continuing day by day and minute by minute. History has stopped. Nothing exists except an endless present in which the Party is always right.”
Het einde van geschiedenis is in de maak
[ Voor 89% gewijzigd door Wilf op 30-06-2020 01:31 ]
Toshiba's Accupoint was superieur.Sebazzz schreef op maandag 29 juni 2020 @ 23:14:
Als gedwongen ThinkPad gebruiker kan ik deze wel waarderen
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Breng m'n thinkpad dagelijkse tot grote hoogten met d'r clitje.Sebazzz schreef op maandag 29 juni 2020 @ 23:14:
Als gedwongen ThinkPad gebruiker kan ik deze wel waarderen
Helaas een van de weinigen die ze nog heeft.
Dat gaan ze dus ook doen.
Ik gok dat ze dat nog laten voor wat het is, al kan ik me voorstellen dat er best (een vocaal) iemand te vinden is voor het concept dat men "de pijn moet voelen".Je hoeft alleen maar je Azure Devops, CircleCI, Docker Hub, GitVersioning, README, CONTRIBUTING.md te herconfigureren en vervolgens je git historie te herschrijven dat elke "merge changes from 'master'" is herschreven naar de correcte tekst, de tags te hertaggen, en software waar de master branch in het build ID zit opnieuw te compileren en te publiceren.
Ik hoop niet dat ik hier nog een /s aan moet toevoegen.
Wat was daar anders aan ?
(kan me het niet herinneren van m'n eerste laptop een toshiba stoeptege dat anders aanvoelde of zo, wel dat ik het een stuk prettiger vond dan een touchpad, zelfs CAD tekeningen maken in de trein was niet zo'n probleem met een *point)


[ Voor 17% gewijzigd door gekkie op 30-06-2020 09:42 ]
Die van Lenovo vergeleken met wat Toshiba had in de jaren '90? Puntiger, harder.gekkie schreef op dinsdag 30 juni 2020 @ 09:38:
[...]
Wat was daar anders aan ?
(kan me het niet herinneren van m'n eerste laptop een toshiba stoeptege dat anders aanvoelde of zo, wel dat ik het een stuk prettiger vond dan een touchpad, zelfs CAD tekeningen maken in de trein was niet zo'n probleem met een *point)
Mooie 403.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Zat er daar niet ook al een zakje bij met verschillende rubbertjes, van hard en stroef tot zacht en sompig ?RayNbow schreef op dinsdag 30 juni 2020 @ 10:27:
[...]
Die van Lenovo vergeleken met wat Toshiba had in de jaren '90? Puntiger, harder.
Vaag, ik zie een mooie 30 bij 30 tegel met, wat was het .. 1024x768 resolutie, of zou het nog 800x600 zijn geweest. Naja goochelen met "toshiba 320cdt" doet wonderen.Mooie 403.
Ik heb nog een SP 490CDT hier liggen. Ik denk niet dat ik hoef te googlen naar een 320CDT.gekkie schreef op dinsdag 30 juni 2020 @ 10:40:
[...]
Vaag, ik zie een mooie 30 bij 30 tegel met, wat was het .. 1024x768 resolutie, of zou het nog 800x600 zijn geweest. Naja goochelen met "toshiba 320cdt" doet wonderen.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
De casing lijkt wel +/- hetzelfde te zijn.RayNbow schreef op dinsdag 30 juni 2020 @ 10:45:
[...]
Ik heb nog een SP 490CDT hier liggen. Ik denk niet dat ik hoef te googlen naar een 320CDT.
Mooie xircom realport pcmcia netwerk kaart en modem (zonder dongle

Ah those good old times, 2 dagen laten buffelen om met 3dstudio een scene te renderen waarvan je het nu zelfs in realtime nog niet te pruimen vindt qua simpelheid.
LOL:Mugwump schreef op maandag 29 juni 2020 @ 17:14:
Kwam net deze nerdversie van The Onion tegen. Sommige artikelen zijn best geslaagd.
https://www.theolognion.c...notepad-declared-a-witch/
Roses are red, violets are blue, unexpected '{' on line 32.
Oh joy, jetbrains slikt m'n BTW nummer niet meer .. ohja het geklooi van onze overheid.
Helaas nergens zelf te wijzigen in hun account systeem, dan maar weer een mailtje aan wijden.
Helaas nergens zelf te wijzigen in hun account systeem, dan maar weer een mailtje aan wijden.
Klopt, ik heb exact hetzelfde probleem gehad. Blijkbaar hebben ze daar geen rekening gehouden met onze klunzige belastingdienst die even alle BTW-nrs van ZZP-ers heeft aangepast.gekkie schreef op dinsdag 30 juni 2020 @ 13:35:
Oh joy, jetbrains slikt m'n BTW nummer niet meer .. ohja het geklooi van onze overheid.
Helaas nergens zelf te wijzigen in hun account systeem, dan maar weer een mailtje aan wijden.
Gewoon ff een mailtje naar hun servicedesk sturen. Ik had binnen een half uur een reactie met een vraag wat mijn nieuwe BTW nummer was en dat hebben ze gelijk aangepast
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Hier al binnen 2 minuten, alsof er iemand op zat te F5'enJanoz schreef op dinsdag 30 juni 2020 @ 13:58:
[...]
Klopt, ik heb exact hetzelfde probleem gehad. Blijkbaar hebben ze daar geen rekening gehouden met onze klunzige belastingdienst die even alle BTW-nrs van ZZP-ers heeft aangepast.
Gewoon ff een mailtje naar hun servicedesk sturen. Ik had binnen een half uur een reactie met een vraag wat mijn nieuwe BTW nummer was en dat hebben ze gelijk aangepast
Jullie weten het ongetwijfeld al:
MCSD, MCSE certifications retire; with continued investment to role-based certifications
MCSD, MCSE certifications retire; with continued investment to role-based certifications
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Vorig jaar net mijn MCSD gehaaldSebazzz schreef op dinsdag 30 juni 2020 @ 15:54:
Jullie weten het ongetwijfeld al:
MCSD, MCSE certifications retire; with continued investment to role-based certifications
Hail to the king baby!
Fucking hell, kut Synology.
Ik heb die C2 Backup service met een 1TB account. Nu ben ik daar blijkbaar overheen gegaan. Dat slaat op zich nergens op, want ik heb maar niets van 700GB aan backupbare data.
Maar nou is die C2 Backup taak suspended. En als hij suspended is, mag ik de folders niet aanpassen of zelfs ook maar inzien (die tab is grijs). En ik kan 'm niet resumen, want ik ben over mijn quota.
.edit: oh lol ik zie het al, het zijn windows file histories van wat dev projectjes die aardig in de papieren lopen. Met name de intermediate files en binaries.
.edit2: file history van outlook database files, ja ook erg nuttig
. 140GB. Misschien moet ik mijn hele appdata folder maar eens excluden, goed voor 213GB in totaal.
.edit3: oh ik snap het, je moet eerst de version discarden die ervoor zorgde dat de boel suspended raakte. Irritant wel dat je volgens mij dus niet op fileniveau kan discarden. Leuk dat ik mijn backupset nu verkleind heb, maar dat zorgt er niet voor dat ie weggaat uit oudere versies
. Misschien moet ik maar from scratch beginnen, en dan hopen dat mijn huis vannacht niet afbrand ofzo.
Ik heb die C2 Backup service met een 1TB account. Nu ben ik daar blijkbaar overheen gegaan. Dat slaat op zich nergens op, want ik heb maar niets van 700GB aan backupbare data.
Maar nou is die C2 Backup taak suspended. En als hij suspended is, mag ik de folders niet aanpassen of zelfs ook maar inzien (die tab is grijs). En ik kan 'm niet resumen, want ik ben over mijn quota.

.edit: oh lol ik zie het al, het zijn windows file histories van wat dev projectjes die aardig in de papieren lopen. Met name de intermediate files en binaries.
.edit2: file history van outlook database files, ja ook erg nuttig
.edit3: oh ik snap het, je moet eerst de version discarden die ervoor zorgde dat de boel suspended raakte. Irritant wel dat je volgens mij dus niet op fileniveau kan discarden. Leuk dat ik mijn backupset nu verkleind heb, maar dat zorgt er niet voor dat ie weggaat uit oudere versies

[ Voor 47% gewijzigd door .oisyn op 02-07-2020 14:16 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
.oisyn schreef op donderdag 2 juli 2020 @ 13:11:
Misschien moet ik maar from scratch beginnen, en dan hopen dat mijn huis vannacht niet afbrand ofzo.

Exact expert nodig?
Waar woon je?.oisyn schreef op donderdag 2 juli 2020 @ 13:11:
Misschien moet ik maar from scratch beginnen, en dan hopen dat mijn huis vannacht niet afbrand ofzo.
🠕 This side up
Ik heb het anders aangepakt. Ik heb roulation voor nu even aangezet, met een max aantal versies van 2. Dan hou ik wel backups maar zou de oude meuk overmorgen weg moeten zijn. Daarna kan het dan weer groeien (en dan stap ik ook over op een progressief retentieplan waarbij van recente changes meer versies worden bijgehouden dan van oude changes).
Maar goed, dat is de C2 versioning. De culprit is nu meer de Windows versioning. Die wil ik eigenlijk wel houden op mijn sourcefiles, maar niet op de intermediate data. Helaas kun je alleen expliciet folders excluden, geen filetypes of path patterns oid
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Heb je een 5G mast op jouw dak?.oisyn schreef op donderdag 2 juli 2020 @ 13:11:
.edit3: oh ik snap het, je moet eerst de version discarden die ervoor zorgde dat de boel suspended raakte. Irritant wel dat je volgens mij dus niet op fileniveau kan discarden. Leuk dat ik mijn backupset nu verkleind heb, maar dat zorgt er niet voor dat ie weggaat uit oudere versies. Misschien moet ik maar from scratch beginnen, en dan hopen dat mijn huis vannacht niet afbrand ofzo.
Lekker op de bank
Dit topic is gesloten.
Let op:
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.