De Devschuur Coffee Corner - Iteratie ⑬

[Koenvh]

reputatio schreef op vrijdag 8 april 2022 @ 09:34:
Wij zijn opzoek naar een object storage provider, die S3-API compatible is, in Nederland voor het neerzetten van geautomatiseerde backups. Veel bekende providers zitten natuurlijk in de VS met servers in Nederland, waar nu ook backups geplaatst zijn. Maar we willen een tweede locatie, met voorkeur voor EU/NL, om ze neer te zetten.

Daarnaast uiteraard ook off-site, maar dan hebben we het in ieder geval op meerdere plekken

Iemand suggesties voor een goede provider in Europa / Nederland?
Ik zag zelf bijvoorbeeld OVH Cloud & PCExtreme, maar liefst hoor ik natuurlijk ervaringen van anderen!

Geen ervaringen, maar hier is ook een lijstje: https://european-alternat.../object-storage-providers

[reputatio]

Eärendil schreef op vrijdag 8 april 2022 @ 11:32:
[...]


https://www.scaleway.com/en/docs/storage/object/quickstart/

Thanks voor alle suggesties, na aanbevelingen van verschillende kanten gaan we denk ik voor Scaleway. En excuses, had inderdaad achteraf gezien niet in dit topic gemoeten.

[ElkeBxl]

reputatio schreef op vrijdag 8 april 2022 @ 13:29:
[...]


Thanks voor alle suggesties, na aanbevelingen van verschillende kanten gaan we denk ik voor Scaleway. En excuses, had inderdaad achteraf gezien niet in dit topic gemoeten.

Je had gewoon moeten ranten over een random provider, dan waren er waarschijnlijk ook suggesties gekomen

[CodeCaster]

Zijn hier nog mensen die GitHub Copilot gebruiken?

Ik heb het een tijdje ingeschakeld gehad in Visual Studio 2022, maar aangezien ze heel de Redo (na Undo) van Visual Studio hebben gesloopt en random whitespace inserten wanneer je op Tab drukt, heb ik het nu disabled.

Dat uiteraard afgezien van de volstrekt nutteloze suggesties die 'ie geeft.

For-loops die off-by-one zijn, code voorstellen voor gebruik van klassen uit third-party packages waarbij de properties helemaal niet bestaan, het hyperactieve willen afmaken van ieder comment dat je typt (maar volledig de plank misslaan, het lijkt een AI die een mashup maakt van alle teksten in je project)...

Dus het kost me meer mentale moeite om de suggesties door te lezen en aan te passen of te verwijderen dan wanneer ik het zelf zou tikken.

Eén keer leek het zowaar kloppende compilerende code te genereren, voor een notification area icon met contextmenu.

Maar helaas, als je de code uitvoerde, dan bleken de gegenereerde handlers te crashen, want hij propte een Application.Run(new FooForm()) in iedere menu-click-handler. Een WinForms-app heeft maar één message loop, dus dat werkt niet.

Is er iemand wel blij met de AI die ons werk ooit gaat vervangen?

[gekkie]

Het is dan ook meer A dan I, laten ze eerst maar eens komen met iets wat werkelijk basic kan redeneren.
Wat deze pattern-matching on steriods werkt prima voor sommige zaken, maar bij andere slaat het inderdaad de plank aardig mis.

[CodeCaster]

gekkie schreef op vrijdag 8 april 2022 @ 18:09:
Het is dan ook meer A dan I, laten ze eerst maar eens komen met iets wat werkelijk basic kan redeneren.
Wat deze pattern-matching on steriods werkt prima voor sommige zaken, maar bij andere slaat het inderdaad de plank aardig mis.

Ja, "maak deze tekst rood" of "tel tot tien" snapt het wel.

Maar ik was met System.CommandLine bezig om argumenten en opties te parsen, en er werd echt random code gegenereerd met klassen die toevallig dezelfde naam hadden als de klassen uit die namespace. Er werden constructors aangeroepen die niet bestonden, properties geïnitialiseerd die wellicht op een gelijknamige klasse uit een andere library wel bestaan...

Het "snapt" niet wat je doet, het herkent patronen en tapt uit een onmetelijke database aan code. Ik begrijp te weinig van machine learning en AI om definitief te bepalen dat dit bij voorbaat ten dode is opgeschreven, maar mijn hoop is niet hoog.

En dan nog: op het moment dat ik begin te typen in mijn IDE, heb ik een idee in m'n hoofd van wat de code moet gaan doen en hoe die eruit komt te zien. Continue suggesties die daar faliekant naast zitten, verstoren alleen maar m'n gedachten.

[ Voor 10% gewijzigd door CodeCaster op 08-04-2022 18:16 ]

[gekkie]

CodeCaster schreef op vrijdag 8 april 2022 @ 18:14:
[...]

Ja, "maak deze tekst rood" of "tel tot tien" snapt het wel.

Maar ik was met System.CommandLine bezig om argumenten en opties te parsen, en er werd echt random code gegenereerd met klassen die toevallig dezelfde naam hadden als de klassen uit die namespace. Er werden constructors aangeroepen die niet bestonden, properties geïnitialiseerd die wellicht op een gelijknamige klasse uit een andere library wel bestaan...

Het "snapt" niet wat je doet, het herkent patronen en tapt uit een onmetelijke database aan code. Ik begrijp te weinig van machine learning en AI om definitief te bepalen dat dit bij voorbaat ten dode is opgeschreven, maar mijn hoop is niet hoog.

En dan nog: op het moment dat ik begin te typen in mijn IDE, heb ik een idee in m'n hoofd van wat de code moet gaan doen en hoe die eruit komt te zien. Continue suggesties die daar faliekant naast zitten, verstoren alleen maar m'n gedachten.

Definitief ten dode opgeschreven zou ik niet willen zeggen.
Als er mechanisch-chemisch-electrische-zakken rond lopen die het kunnen, dan zou het wellicht ook puur electronisch moeten kunnen. Maar we zijn er nog lang niet en daar zijn nog wel wat doorbraken voor nodig denk ik. En ik heb het gevoel dat hem dat niet (alleen) in het vergroten van modellen zit en er meer rekenkracht tegen aan bonjouren.

Maar goed een paar trappen simpeler (al hoewel je daar ook over kunt twijfelen of het simpeler is omdat er soms minder context is om op verder te borduren) met predictive text input kom je het ook al regelmatig tegen, alleen zullen we daar op een hoop vlakken waar we het gebruiken en het bruikbaar achten wat vergevingsgezinder zijn.

Maar als mens kun je bijvb al wat info uit een variabele naam halen die je met domeinkennis vervolgens ergens toe brengt. AI lukt dat doorgaans niet echt. En dat gebrek aan afdoende context (ook wat niet in je code staat, maar wel in jouw achterhoofd zit), brede ervaring, gevoel en kennis dat schort er vaak aan.

[ Voor 18% gewijzigd door gekkie op 08-04-2022 18:33 ]

[ZpAz]

CodeCaster schreef op vrijdag 8 april 2022 @ 18:01:
Is er iemand wel blij met de AI die ons werk ooit gaat vervangen?

Kwam gisteren de Warp terminal applicatie tegen. Deze heeft A.I Command search. Maar nog niet veel gebruikt.

Je kan bijvoorbeeld intypen: `I want to make a new branch named my-new-branch` en dan komt hij met het juiste commando op de proppen.

Meestal type je natuurlijk het commando, maar als je die niet weet is dit mogelijk wel handig.

[Koenvh]

ZpAz schreef op vrijdag 8 april 2022 @ 19:22:
[...]


Kwam gisteren de Warp terminal applicatie tegen. Deze heeft A.I Command search. Maar nog niet veel gebruikt.

Je kan bijvoorbeeld intypen: `I want to make a new branch named my-new-branch` en dan komt hij met het juiste commando op de proppen.

Meestal type je natuurlijk het commando, maar als je die niet weet is dit mogelijk wel handig.

Ik heb er niet iets op tegen, maar zijn TUI's of GUI's niet een makkelijkere oplossing? Althans, ik gebruik vaak liever een GUI voor bijvoorbeeld git of ffmpeg dan te proberen de opties te onthouden.

[bwerg]

gekkie schreef op vrijdag 8 april 2022 @ 18:27:
Maar als mens kun je bijvb al wat info uit een variabele naam halen die je met domeinkennis vervolgens ergens toe brengt. AI lukt dat doorgaans niet echt. En dat gebrek aan afdoende context (ook wat niet in je code staat, maar wel in jouw achterhoofd zit), brede ervaring, gevoel en kennis dat schort er vaak aan.

Al was het maar dat je daarvoor een uur met een klant hebt zitten babbelen. Die AI zal toch echt bij dat gesprek moeten aanschuiven om zinnige suggesties te kunnen doen, denk ik.

[gekkie]

bwerg schreef op vrijdag 8 april 2022 @ 21:46:
[...]
Al was het maar dat je daarvoor een uur met een klant hebt zitten babbelen. Die AI zal toch echt bij dat gesprek moeten aanschuiven om zinnige suggesties te kunnen doen, denk ik.

Yups en dat niet alleen, je zult hem dan ook al moeten trainen met je data en die gesprekken vooraf, die context. En dat is best lastig. En wij torsen zoveel impliciete kennis mee van zoveel ervaringen, wat ook weer onderliggend is in dat soort gesprekken. Ik denk dat die matige context in zowel trainingsfase als bij inference dit soort toepassingen voorlopig nog wel lastig blijven maken en vaak een misser opleveren.

En het leren door begrip van wat abstractere zaken, zodat je daar op door kunt redeneren zonder het expliciet te zien of meegemaakt te hebben, dat zijn nog wel wat stappen te ver denk ik voorlopig. Aan de andere kant, als je er verder mee wilt komen, zul je ook dit soort dingen moeten blijven proberen te ontwikkelen en iteratief verder komen. Maar ik heb zelf wel sterk het gevoel dat er nog wel een paar eureka momenten en ontwikkelingen nodig zijn voordat het vakgebied die "I" van AI een beetje waar kan gaan maken.

[ElkeBxl]

Maandagochtend! Iemand koffie?


Vandaag en morgen nog werken en dan sinds lange tijd eens paar dagen congé pakken, gaat deugd doen

[azerty]

ElkeBxl schreef op maandag 11 april 2022 @ 07:20:
Maandagochtend! Iemand koffie?
[Afbeelding]

Vandaag en morgen nog werken en dan sinds lange tijd eens paar dagen congé pakken, gaat deugd doen

Yes please!

Nog 2 weken voor mij en dan is er een weekje verlof...

[hackerhater]

ElkeBxl schreef op maandag 11 april 2022 @ 07:20:
Maandagochtend! Iemand koffie?

Vandaag en morgen nog werken en dan sinds lange tijd eens paar dagen congé pakken, gaat deugd doen

Please, zoveel meetings vandaag

[Mschamp]

ElkeBxl schreef op maandag 11 april 2022 @ 07:20:
Maandagochtend! Iemand koffie?
[Afbeelding]

Vandaag en morgen nog werken en dan sinds lange tijd eens paar dagen congé pakken, gaat deugd doen

Niet echt een fan van coffee, maar ik zal de (digitale) taart voorzien vandaag

[Ghehe]

ElkeBxl schreef op maandag 11 april 2022 @ 07:20:
Maandagochtend! Iemand koffie?
[Afbeelding]

Vandaag en morgen nog werken en dan sinds lange tijd eens paar dagen congé pakken, gaat deugd doen

* Ghehe , die deze en volgende week congé gepakt heeft, groet U met een fris pintje

[azerty]

Ghehe schreef op maandag 11 april 2022 @ 11:34:
[...]


* Ghehe , die deze en volgende week congé gepakt heeft, groet U met een fris pintje
[Afbeelding]

Het mag, het is bijna middag ondertussen

[ElkeBxl]

Ghehe schreef op maandag 11 april 2022 @ 11:34:
[...]


* Ghehe , die deze en volgende week congé gepakt heeft, groet U met een fris pintje
[Afbeelding]

Dat is Charlotte De Witte, right? Meestal ben ik een hardrock en metal luisteraar maar zo'n minimal techno die ze speelt kan ik ook wel smaken! Lekker chill programmeren ondertussen

En santé!

[ElkeBxl]

azerty schreef op maandag 11 april 2022 @ 11:42:
[...]


Het mag, het is bijna middag ondertussen

[DevWouter]

ElkeBxl schreef op maandag 11 april 2022 @ 11:48:
[...]

[Afbeelding]

Pfff... Leugens. Als er ergens op aarde 1 over 5 is dan is het nergens op aarde 5 uur.

[ThomasG]

DevWouter schreef op maandag 11 april 2022 @ 12:39:
[...]

Pfff... Leugens. Als er ergens op aarde 1 over 5 is dan is het nergens op aarde 5 uur.

Maar dat zou wel moeten. Oorspronkelijk was het 12:00 als de zon op het hoogste punt stond. Dat is overal in de wereld op een ander moment. Door o.a. de trein hebben we nu een standaard tijd die eigenlijk nergens klopt. En in Nederland zitten we al helemaal verkeerd, omdat we in GMT+1 zitten terwijl we geografisch rond de GMT +20 min zitten.

[.oisyn]

DevWouter schreef op maandag 11 april 2022 @ 12:39:
[...]

Pfff... Leugens. Als er ergens op aarde 1 over 5 is dan is het nergens op aarde 5 uur.

Het is hier altijd 5 uur, en aangezien dit op aarde is, is het dus geen leugen

[RayNbow]

* RayNbow had ooit het idee om de CTCP-TIME-respons van een IRC client zodanig aan te passen dat het altijd 13:37 zou retourneren met een passende UTC-offset...

...maar te lui.

[ThomasG]

.oisyn schreef op maandag 11 april 2022 @ 13:56:
[...]


Het is hier altijd 5 uur, en aangezien dit op aarde is, is het dus geen leugen

Maar hoe weet je zeker dat je op aarde bent?

[hackerhater]

Zo. Een hard punt qua upgrades en wijzigingen van o.a. Docker ingenomen.
Tegenspraak, heen en weer en dan in het midden uit komen zoals ik wilde

[gekkie]

hackerhater schreef op maandag 11 april 2022 @ 15:00:
Zo. Een hard punt qua upgrades en wijzigingen van o.a. Docker ingenomen.
Tegenspraak, heen en weer en dan in het midden uit komen zoals ik wilde

[Afbeelding]

In het midden, ah, ben je de waarheid toevallig ook al tegen gekomen, die schijnt daar ook rond te moeten hangen volgens menigeen

[Matis]

gekkie schreef op maandag 11 april 2022 @ 15:31:
In het midden, ah, ben je de waarheid toevallig ook al tegen gekomen, die schijnt daar ook rond te moeten hangen volgens menigeen

Ah, de waarheid ligt bij ons altijd op het kerkhof

[gekkie]

Matis schreef op maandag 11 april 2022 @ 15:52:
[...]
Ah, de waarheid ligt bij ons altijd op het kerkhof

Daar bij die kerk in het midden van het dorp ?
(in menig topic hier op tweakers wordt de waarheid steevast in het midden geprojecteerd)

[ Voor 19% gewijzigd door gekkie op 11-04-2022 15:55 ]

[Janoz]

hackerhater schreef op maandag 11 april 2022 @ 15:00:
Zo. Een hard punt qua upgrades en wijzigingen van o.a. Docker ingenomen.
Tegenspraak, heen en weer en dan in het midden uit komen zoals ik wilde

[Afbeelding]

Ik ben wel benieuwd wat de harde start punten waren en waar het midden uiteindelijk lag

[hackerhater]

Janoz schreef op maandag 11 april 2022 @ 16:11:
Ik ben wel benieuwd wat de harde start punten waren en waar het midden uiteindelijk lag

Ik zette in om de huidige troep weg te gooien en van scratch te beginnen.
Het midden is dat de troep in orde wordt gemaakt

[Voutloos]

ThomasG schreef op maandag 11 april 2022 @ 14:04:
[...]
Maar hoe weet je zeker dat je op aarde bent?
[Afbeelding]

Hier zouden ze een goede film van moeten maken. En dan nog 3 extra.

[DevWouter]

Janoz schreef op maandag 11 april 2022 @ 16:11:
[...]


Ik ben wel benieuwd wat de harde start punten waren en waar het midden uiteindelijk lag

"We gaan docker in docker draaien"
"Nee"
"Fijn! Dan gaan we docker draaien buiten docker"
"Daar kan ik meeleven?"

@hackerhater Om eerlijk te wezen vroeg ik me ook af wat jouw extremere standpunt precies was. Zou je die kunnen toelichten? Hopelijk niet het bovenstaande Nevermind, eerst de overige posts lezen.

[ Voor 4% gewijzigd door DevWouter op 11-04-2022 20:49 ]

[Janoz]

hackerhater schreef op maandag 11 april 2022 @ 16:19:
[...]


Ik zette in om de huidige troep weg te gooien en van scratch te beginnen.
Het midden is dat de troep in orde wordt gemaakt

Ah, jij had de Netscape approach

[ThomasG]

Janoz schreef op dinsdag 12 april 2022 @ 08:41:
[...]


Ah, jij had de Netscape approach

Aan de andere kant is er genoeg rommel waarbij ze beter wél opnieuw hadden kunnen beginnen, mits ze dan natuurlijk wel goed hebben nagedacht.

[PrisonerOfPain]

Janoz schreef op dinsdag 12 april 2022 @ 08:41:
[...]


Ah, jij had de Netscape approach

Acht, dat 't bij Netscape een keer fout is gegaan wil natuurlijk niet zeggen dat we dat tot vaste regel moeten verkopen soms is herschrijven gewoon een prima oplossing.

[Woy]

PrisonerOfPain schreef op dinsdag 19 april 2022 @ 10:54:
[...]


Acht, dat 't bij Netscape een keer fout is gegaan wil natuurlijk niet zeggen dat we dat tot vaste regel moeten verkopen soms is herschrijven gewoon een prima oplossing.

Op zich is herschrijven niet zozeer het probleem, de problemen komen vaak vooral naar voren als er een big-bang overgang is tussen het te vervangen product en de vervanging ( Tenminste als het een project van enige omvang is ), waarbij de vervanging toch niet helemaal dezelfde functionaliteit blijkt te hebben, en de mensen niet meegenomen zijn in de beslissingen waarom dingen anders gaan.

Als dingen gewoon naast elkaar kunnen draaien dan is dat probleem een stuk minder, en kun je in de tussentijd gewoon nog sleutelen aan de nieuwe versie om ook oude gebruikers tevreden te krijgen, en zelfs nog wat tijd en onderhoud in het oude product blijven stoppen zolang de vervanging nog niet 100% voldoet aan de verwachtingen.

Natuurlijk moet je bij zoiets als netscape ook wel de tijdlijn in de gaten houden, want anders wordt je inderdaad aan alle kanten voorbijgelopen.

[ Voor 25% gewijzigd door Woy op 19-04-2022 11:09 ]

[Caelorum]

Dat en dat vaak wordt gekozen om de hele groep gebruikers in 1 keer over te zetten en niet eerst een subgroep met alle functionaliteit die zij nodig hebben.

Ik heb overigens persoonlijk echt een hekel aan die irrationele angst voor herbouw van een product. Zie waar ik nu zit het ook weer. Ja, maar er zit 15 jaar aan ontwikkeling in! Prima, maar de laatste 5 jaar is er niet veel meer gedaan en heeft iemand überhaupt nog wel in beeld of alle features die er inzitten nog gewenst en gewild zijn? (uiteraard niet). Maar dan wel zonder inzicht besluiten om "op de lopende trein" het te gaan moderniseren, waar mogelijk herbouw beter zou zijn.

[.oisyn]

PrisonerOfPain schreef op dinsdag 19 april 2022 @ 10:54:
[...]


Acht, dat 't bij Netscape een keer fout is gegaan wil natuurlijk niet zeggen dat we dat tot vaste regel moeten verkopen meestal is herschrijven naar Rust gewoon een prima oplossing.

^^ wat er daadwerkelijk rond ging in @PrisonerOfPain's hoofd

---

Deze week laatste week bij Nixxes . Ga mijn collega's wel missen. Een aantal ken ik dus al 17,5 jaar.

[ Voor 13% gewijzigd door .oisyn op 19-04-2022 12:04 ]

[PrisonerOfPain]

Woy schreef op dinsdag 19 april 2022 @ 11:06:
[...]
Natuurlijk moet je bij zoiets als netscape ook wel de tijdlijn in de gaten houden, want anders wordt je inderdaad aan alle kanten voorbijgelopen.

En je moet het in de juiste (historische) context plaatsen; het is een blogpost van Spolsky over een netscape release van 20+ jaar geleden; inmiddels zijn er een hoop project geweest en hebben we collectief een hoop lessen over software development kunnen leren.

[PrisonerOfPain]

.oisyn schreef op dinsdag 19 april 2022 @ 11:12:
[...]


^^ wat er daadwerkelijk rond ging in @PrisonerOfPain's hoofd

Ik ben eigenlijk blij dat ik door Rust te kiezen minder dingen zelf hoef te bouwen omdat we voor 't een en ander gewoon iemand anders z'n crate makkelijk kunnen gebruiken ipv zelf weer iets in te typen.

Deze week laatste week bij Nixxes . Ga mijn collega's wel missen. Een aantal ken ik dus al 17,5 jaar.

Succes met het afscheid, dat zal niet makkelijk zijn! We kijken naar je uit

[.oisyn]

PrisonerOfPain schreef op dinsdag 19 april 2022 @ 11:57:
Ik ben eigenlijk blij dat ik door Rust te kiezen minder dingen zelf hoef te bouwen omdat we voor 't een en ander gewoon iemand anders z'n crate makkelijk kunnen gebruiken ipv zelf weer iets in te typen.

Ik bedoelde meer dat je iets naar Rust wil herschrijven als het nog niet in Rust was geschreven

We kijken naar je uit

Ik ook . Is mijn werkplek al ingericht?

[ Voor 45% gewijzigd door .oisyn op 19-04-2022 12:04 ]

[Woy]

.oisyn schreef op dinsdag 19 april 2022 @ 12:01:
[...]
Ik ook . Is mijn werkplek al ingericht?

Ik denk dat dit klaar voor je staat

[Woy]

PrisonerOfPain schreef op dinsdag 19 april 2022 @ 11:56:
[...]


En je moet het in de juiste (historische) context plaatsen; het is een blogpost van Spolsky over een netscape release van 20+ jaar geleden; inmiddels zijn er een hoop project geweest en hebben we collectief een hoop lessen over software development kunnen leren.

We zouden een hoop geleerd kunnen hebben, er zit natuurlijk nog steeds een hoop waarheid in die blogpost, en in veel bedrijven zie ik weinig besef en actie om dat te voorkomen

[.oisyn]

Woy schreef op dinsdag 19 april 2022 @ 12:09:
[...]

Ik denk dat dit klaar voor je staat [Afbeelding]

Met CD-burner en optische muis, wat modern!

[PrisonerOfPain]

.oisyn schreef op dinsdag 19 april 2022 @ 12:01:
Ik ook . Is mijn werkplek al ingericht?

Min of meer, BTO is nog aan het bouwen aan je PC volgens mij want ze hadden wat moeite met om een threadripper te vinden maar het is ze gelukt uiteindelijk. Blijkbaar zijn letterlijk alle CPUs met een schappelijke core-count niet meer te kopen, en de stapje terug (van 32c64t) naar een alder lake (8e+8p/24t) was me net iets te groot dus ik ben blij dat ze nog een CPU hebben kunnen vinden voor je.

[Caelorum]

Jezus man.. en ik maar blij zijn met een 11800H

[.oisyn]

PrisonerOfPain schreef op dinsdag 19 april 2022 @ 12:21:
[...]


Min of meer, BTO is nog aan het bouwen aan je PC volgens mij want ze hadden wat moeite met om een threadripper te vinden maar het is ze gelukt uiteindelijk. Blijkbaar zijn letterlijk alle CPUs met een schappelijke core-count niet meer te kopen, en de stapje terug (van 32c64t) naar een alder lake (8e+8p/24t) was me net iets te groot dus ik ben blij dat ze nog een CPU hebben kunnen vinden voor je.

Ik zit hier nog op een 6700K

[PrisonerOfPain]

.oisyn schreef op dinsdag 19 april 2022 @ 12:36:
[...]



Ik zit hier nog op een 6700K

WAT? Dat ding heeft maar 4 cores? Mijn laptop heeft er meer

[P-Storm]

Ugh, waarom kunnen sommige CEO's niet luisteren naar wat er nodig is.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[P-Storm]

PrisonerOfPain schreef op dinsdag 19 april 2022 @ 12:21:
[...]


Min of meer, BTO is nog aan het bouwen aan je PC volgens mij want ze hadden wat moeite met om een threadripper te vinden maar het is ze gelukt uiteindelijk. Blijkbaar zijn letterlijk alle CPUs met een schappelijke core-count niet meer te kopen, en de stapje terug (van 32c64t) naar een alder lake (8e+8p/24t) was me net iets te groot dus ik ben blij dat ze nog een CPU hebben kunnen vinden voor je.

Altijd leuk wanneer je moet verdedigen dat 8 GB echt veel te weinig is, en 16 GB ook snel aan de max kan zitten. Nee dat doen we dan wel iets mee toch? Ik heb ze er toch van kunnen oivertuigen, en ik heb wat screenshots als bewijs gegeven, 2 IDE open, 3 docker containers en een aantal tabbladen van chrome open doet wat met je memory.

[.oisyn]

PrisonerOfPain schreef op dinsdag 19 april 2022 @ 12:40:
[...]


WAT? Dat ding heeft maar 4 cores? Mijn laptop heeft er meer

Op zich als je alle builds al over het hele netwerk distribueert doet het er sowieso niet zo toe hoeveel cores je zelf hebt. We hebben wat dat betreft hier nooit echt aandacht besteed aan veel cores in workstations (wel in build servers). Maar even los van dat was ik inmiddels wel alweer toe aan een nieuwe PC. Als ik niet wegging had ik daar ook echt wel een punt van gemaakt.

Wel zitten we nu geloof ik standaard op 64GB voor nieuwe PC's en een flinke SSD (naast die voor je standaard Windows drive)

[ Voor 10% gewijzigd door .oisyn op 19-04-2022 12:49 ]

[PrisonerOfPain]

.oisyn schreef op dinsdag 19 april 2022 @ 12:46:
[...]

Op zich als je alle builds al over het hele netwerk distribueert doet het er sowieso niet zo toe hoeveel cores je zelf hebt. We hebben wat dat betreft hier nooit echt aandacht besteed aan veel cores in workstations (wel in build servers). Maar even los van dat was ik inmiddels wel alweer toe aan een nieuwe PC. Als ik niet wegging had ik daar ook echt wel een punt van gemaakt.

Is het uberhaupt snel genoeg om win11, visual studio, slack en een browser te draaien? Of ben ik enorm disconnected met de wereld sccache hebben we nog niet naar omgekeken, vooral omdat 't de standaard setup wat moeilijker maakt en de asset builds zijn (nog) niet distributed, dus die is vooral ok omdat we een redelijke corecount hebben.

Wel zitten we nu geloof ik standaard op 64GB voor nieuwe PC's en een flinke SSD (naast die voor je standaard Windows drive)

We hadden laatst voor een stagaire een machine gemaakt met 64GB maar de standaard setup is 128G, volgens mij zetten we ze dan ook zo op dat niet alle RAM slots vol zitten zodat we nog een keer kunnen verdubbelen als het ooit nodig is. Verder altijd 1TB m.2 drives, waar we meestal genoeg aan hebben, al zit ik te denken om over een tijdje iedereen van een upgrade te voorzien. Maar goed, dat komt tzt wel.

Dikke machines zijn wel nice als je "snel even" wat uit wilt testen zonder het meteen stuk te moeten optimizen. Ik weet zo even niet meer welke GPU d'r in zit - denk een 6700 of een 3000 series iig omdat 't hele framework raytracing nodig heeft.

[PrisonerOfPain]

(Ik kan je wel vertellen - een snelle machine is wel fijn als je aan de compiler werkt hoor, want rustc from source builden is niet ideaal, en je bent constant clean-builds aan het doen voor je eigen sanity).

[.oisyn]

PrisonerOfPain schreef op dinsdag 19 april 2022 @ 13:01:
[...]

Is het uberhaupt snel genoeg om win11, visual studio, slack en een browser te draaien? Of ben ik enorm disconnected met de wereld sccache hebben we nog niet naar omgekeken, vooral omdat 't de standaard setup wat moeilijker maakt en de asset builds zijn (nog) niet distributed, dus die is vooral ok omdat we een redelijke corecount hebben.

4 cores zijn daar prima voor. Maar as said, ik was ook al wel aan de beurt voor een nieuwe PC, volgens mij zit ik in de batch van oudste dev PC's op kantoor . Maar goed, 64GB en een 2TB SSD helpt ook flink.

En win11, please not

[PrisonerOfPain]

.oisyn schreef op dinsdag 19 april 2022 @ 13:05:
En win11, please not

Get with the times grandpa

[.oisyn]

PrisonerOfPain schreef op dinsdag 19 april 2022 @ 13:10:
[...]


Get with the times grandpa

Ik wil geen gegroepeerde taskbar buttons

Vooralsnog is de enige reden om eventueel te willen upgraden het feit dat je de standaard console host kunt aanpassen naar iets als Windows Terminal

[PrisonerOfPain]

.oisyn schreef op dinsdag 19 april 2022 @ 13:42:
[...]


Ik wil geen gegroepeerde taskbar buttons

Vooralsnog is de enige reden om eventueel te willen upgraden het feit dat je de standaard console host kunt aanpassen naar iets als Windows Terminal

Eddy gebruikt volgens mij nog steeds nix os, heb je helemaal geen taskbar, probleem opgelost?

[.oisyn]

@PrisonerOfPain Waarom verbaast me dat niets

[ThomasG]

.oisyn schreef op dinsdag 19 april 2022 @ 13:05:
[...]


En win11, please not

FTFY

[.oisyn]

Windows FTW

[ElkeBxl]

ElkeBxl schreef op dinsdag 14 december 2021 @ 15:08:
[...]

Ach, maak er direct een monorepo van met een hoop microfrontends! Dat lost direct alle problemen op die je ooit zal hebben! Elke microfrontend kan dan elk hun eigen versie hebben van Angular, Vue, React, Svelte, Ember, Alpine, Backbone,... En om zeker te zijn, maak een paar van de microfrontends in whatever ander frontend frameworkje met 3 GitHub stars dat belooft "the future of webdevelopment" te zijn. Zo ben je zeker dat als er iets op de schop gaat, je niet 100% van je app moet herbouwen maar slechts een paar procent, zeker als je zorgt dat er genoeg frameworks gebruikt worden!

Ik zit op een meetup waar ze net spraken over 4 (ja, vier!) JS frameworks in 1 pagina te gebruiken (Vue, Svelte, Preact en Astro). Lord have mercy on our soul!

[RagingPenguin]

ElkeBxl schreef op woensdag 20 april 2022 @ 20:50:
[...]

Ik zit op een meetup waar ze net spraken over 4 (ja, vier!) JS frameworks in 1 pagina te gebruiken (Vue, Svelte, Preact en Astro). Lord have mercy on our soul!

More is less?

[gekkie]

Hmm ik mis nog een (geschift) sausje van VanillaJS om het geheel aan elkaar te verbinden

[Kalentum]

ElkeBxl schreef op woensdag 20 april 2022 @ 20:50:
[...]

Ik zit op een meetup waar ze net spraken over 4 (ja, vier!) JS frameworks in 1 pagina te gebruiken (Vue, Svelte, Preact en Astro). Lord have mercy on our soul!

Ik moest een dropdown toevoegen in een applicatie die Typescript en React gebruikt... behalve waar ik moest zijn. JQuery, datatable plugin, callbacks, inline css, api calls die html fragmenten teruggeven... mooi hoor, trip down memory lane

[gekkie]

Urghh ruk, ik me maar afvragen in welke /dev/null de mails van een bekende witgoedboer belanden.
Net maar even in de maillogs gedoken, lijkt de 2e tent te zijn die z'n zooi bij amazon host, die na de greylisting abort met het feestje:
TLS error on connection from xx-xxx.smtp-out.eu-west-1.amazonses.com (recv): The TLS connection was non-properly terminated.

Maar wat de onderliggende oorzaak is, wellicht dat mijn mailserver onvoldoende haast maakt met de greylisting ofzo. Met microsoft z'n outlook, gmail, alle mailservers werken eigenlijk, alleen bij amazon lijkt het er op dat het soms fout gaat (en blijft gaan bij hernieuwde mailpogingen). Irritant.

Edit: Ahh sommige DNSRBL's lijken niet te werken, dus de timeout laat dan even op zich wachten en kennelijk is Amazon het ongeduldigste jongetje van de klas, zonder de basis DNSRBL check komt de mail wel binnen.
Nu nog maar eens uitzoeken waarom die checks falen.

Edit2: Urghh tijdje geleden de pdns-recursor VM voor het hele antispam gebeuren geupgrade qua Debian en dit was nog een sysvinit install ... en ze leveren geen sysvinit script meer mee , systemD(isaster) strikes again.
Ahwell ook weer gefixt zo op de late avond.

[ Voor 26% gewijzigd door gekkie op 20-04-2022 23:59 ]

[ElkeBxl]

gekkie schreef op woensdag 20 april 2022 @ 22:01:
Hmm ik mis nog een (geschift) sausje van VanillaJS om het geheel aan elkaar te verbinden

Wow, daar gaan velen niet mee kunnen omgaan hoor als je met het zot fancy VanillaJS af komt! Vind daar maar eens iemand voor die dat nog wil schrijven!

RagingPenguin schreef op woensdag 20 april 2022 @ 21:44:
[...]
More is less?

"less = more" is hetzelfde als "more = less" natuurlijk

Kalentum schreef op woensdag 20 april 2022 @ 22:06:
[...]


Ik moest een dropdown toevoegen in een applicatie die Typescript en React gebruikt... behalve waar ik moest zijn. JQuery, datatable plugin, callbacks, inline css, api calls die html fragmenten teruggeven... mooi hoor, trip down memory lane

Haha nice! Zo'n stuff heb ik er in mijn huidig project allemaal uitgehaald. Maar ik kon de vorige frontender het niet kwalijk nemen. Dat was iemand die enkel jQuery kon en dan op zijn eigen Vue aan het leren was en blijkbaar niet alle docs gelezen had. Met alle gevolgen van dien dat het (zoals bij jou dan) een mengelmoes werd. Deed deugd om na maanden werk (want in 1 keer de sloophamer erdoor jagen lukte niet) jQuery uit de package.json te kunnen halen. Direct de bundle stuk kleiner

[ThomasG]

ElkeBxl schreef op woensdag 20 april 2022 @ 20:50:
[...]

Ik zit op een meetup waar ze net spraken over 4 (ja, vier!) JS frameworks in 1 pagina te gebruiken (Vue, Svelte, Preact en Astro). Lord have mercy on our soul!

Ah ja, de Belgische manier. Het moet een geheel vormen, maar ieder deel doet lekker waar ze zelf zin in hebben

[ElkeBxl]

ThomasG schreef op donderdag 21 april 2022 @ 08:58:
[...]
Ah ja, de Belgische manier. Het moet een geheel vormen, maar ieder deel doet lekker waar ze zelf zin in hebben

6 regeringen dus dan ook 6 frameworks: 1 belgisch framework, 1 vlaams (gemeenschap + gewest) framework, 1 waals gewest framework, 1 brussels hoofdstedelijk gewest framework, 1 franstalige gemeenschap framework en 1 duitstalige gemeenschap framework

[DevWouter]

ElkeBxl schreef op donderdag 21 april 2022 @ 08:57:
"less = more" is hetzelfde als "more = less" natuurlijk

Hmm... Less or more

[DevWouter]

@ElkeBxl
Als je een keer generdsniped wilt worden: https://single-spa.js.org/docs/ecosystem, het is een framework om 13 verschillende frontends te mixen.

[Caelorum]

En andere ontwikkelaars mij maar raar aankijken als ik zeg dat ik wel bij backend blijf, zodat ik mij kan focussen op domeinlogica.

[RagingPenguin]

Caelorum schreef op donderdag 21 april 2022 @ 09:31:
En andere ontwikkelaars mij maar raar aankijken als ik zeg dat ik wel bij backend blijf, zodat ik mij kan focussen op domeinlogica.

Backend developers kunnen er anders ook wel wat van hoor, met eindeloze hoeveelheden microservices in allerlei talen die dan via gRPC aan elkaar geknoopt worden. En dan nog wat serverless spul met allerhande storage oplossingen om het helemaal af te maken.

[Mugwump]

RagingPenguin schreef op donderdag 21 april 2022 @ 09:52:
[...]


Backend developers kunnen er anders ook wel wat van hoor, met eindeloze hoeveelheden microservices in allerlei talen die dan via gRPC aan elkaar geknoopt worden. En dan nog wat serverless spul met allerhande storage oplossingen om het helemaal af te maken.

Ach ja, op enterprise niveau horen ze de hypes weer over microservices, serverless en ga zo maar door en dat krijg je weer allerhande wereldvreemde doelarchitecturen. Werk nu bijvoorbeeld aan de migratie van een systeem dat vele duizenden events per seconde verwerkt en daarbij allerlei bepalingen en afleidingen moeten doen. Nou is dat echt wel een absurdistische monolith die uit z'n voegen barst, maar hoe je de boel dan splitst en knipt is wel iets waar je dan over na moet denken. In de ivoren toren in doelarchitectuurdroomland is besloten dat bepaalde zaken naar een externe service (en ander team) moet worden afgesplitst die dan een microservice beschikbaar stemt die wij bijna voor elk event moeten gaan aanroepen. Om onze eventverwerking niet volledig lam te leggen gaan wij natuurlijk niet eindeloos wachten op responses, dus daar zit een circuitbreaker tussen die openklapt als we te veel 'slow calls' krijgen van meer dan een seconde responstijd. Gevolg is dat wij nu regelmatig die circuitbreaker openklappen waardoor er in de data die wij weer uitleveren zaken ontbreken omdat de externe service de load niet aankan.
Doelarchitectuurfetisjisten blij, business zwaar gefrustreerd.

[ElkeBxl]

DevWouter schreef op donderdag 21 april 2022 @ 09:25:
@ElkeBxl
Als je een keer generdsniped wilt worden: https://single-spa.js.org/docs/ecosystem, het is een framework om 13 verschillende frontends te mixen.

Maar er staat geen "single-spa-vanillajs" tussen

[ThomasG]

DevWouter schreef op donderdag 21 april 2022 @ 09:25:
@ElkeBxl
Als je een keer generdsniped wilt worden: https://single-spa.js.org/docs/ecosystem, het is een framework om 13 verschillende frontends te mixen.

Maar hoe koppel je twee single-spa's aan elkaar?

[Woy]

ThomasG schreef op donderdag 21 april 2022 @ 10:27:
[...]
Maar hoe koppel je twee single-spa's aan elkaar?

Simpel, met iFrames natuurlijk

[ThomasG]

RagingPenguin schreef op donderdag 21 april 2022 @ 09:52:
[...]


Backend developers kunnen er anders ook wel wat van hoor, met eindeloze hoeveelheden microservices in allerlei talen die dan via gRPC aan elkaar geknoopt worden. En dan nog wat serverless spul met allerhande storage oplossingen om het helemaal af te maken.

Microservices zijn anders super handig. Wij gebruiken Spring Cloud, en als de architectuur eenmaal goed opgezet is gaat het als een trein. Nieuwe features of onderdelen van de applicatie opschalen was nog nooit zo gemakkelijk. Het onderhouden is relatief gemakkelijker (al zijn andere dingen weer iets meer werk), en kun je zonder al teveel moeite oude features uitfaseren.

[Woy]

ThomasG schreef op donderdag 21 april 2022 @ 10:47:
[...]
Microservices zijn anders super handig. Wij gebruiken Spring Cloud, en als de architectuur eenmaal goed opgezet is gaat het als een trein. Nieuwe features of onderdelen van de applicatie opschalen was nog nooit zo gemakkelijk. Het onderhouden is relatief gemakkelijker (al zijn andere dingen weer iets meer werk), en kun je zonder al teveel moeite oude features uitfaseren.

Microservices kunnen heel fijn werken, en hebben inderdaad een hoop voordelen. Maar het is niet triviaal om het juist op te zetten, en je moet ook tijdens de ontwikkeling na blijven denken over afbakening en manieren van communiceren. Het voorbeeld van @Mugwump over slow calls haalt dat bijvoorbeeld weer aan, dat zou kunnen duiden op een verkeerde opzet van de service, en dat bijvoorbeeld een meer event driven opzet beter zou zijn ( Natuurlijk niet goed te bepalen met de sumiere info die we hier zien, maar puur als voorbeeld ).

[Caelorum]

ThomasG schreef op donderdag 21 april 2022 @ 10:47:
[...]
Microservices zijn anders super handig. [...]

Het probleem uit zijn tekst was denk ik ook niet microservices, maar dat bijv elke microservice een andere taal+framework gebruikt. Dat is niet handig als er nog eens met microservices over teams heen geschoven wordt. Een beetje standaardisatie helpt daar wel.
Al heeft microservices niet het issue als micro-frontends dat het uiteindelijk allemaal in dezelfde browser op dezelfde brakke PC terecht komt. De omgeving waar het in komt is een stuk beter controleerbaar vanuit de business.

[Mugwump]

Woy schreef op donderdag 21 april 2022 @ 11:09:
[...]

Microservices kunnen heel fijn werken, en hebben inderdaad een hoop voordelen. Maar het is niet triviaal om het juist op te zetten, en je moet ook tijdens de ontwikkeling na blijven denken over afbakening en manieren van communiceren. Het voorbeeld van @Mugwump over slow calls haalt dat bijvoorbeeld weer aan, dat zou kunnen duiden op een verkeerde opzet van de service, en dat bijvoorbeeld een meer event driven opzet beter zou zijn ( Natuurlijk niet goed te bepalen met de sumiere info die we hier zien, maar puur als voorbeeld ).

Nee klopt. Het heeft deels ook wel te maken met het feit dat niet ieder team bij zo'n grote enterpriseklant even competent is en snapt hoe je een service zo opzet dat bijvoorbeeld je 99% lijn onder de 100ms ligt. Maar een systeem dat prima functioneert opknippen op een manier die leidt tot dit soort technische bottlenecks is niet handig en dat zie je toch wel veel gebeuren wanneer de afdeling blokjes en pijltjes (enterprise architectuur) z'n stempel te stevig op een organisatie drukt.

Kijk idealiter ga je in een systeem dat duizenden events per seconde moet verwerken niet een tiental externe services aanroepen die allemaal kunnen falen, zeker niet als het verkrijgen van de respons eigenlijk cruciaal is voor verdere verwerking van die events. Als je de verwerking daar op laat falen, dan heb je echt een serieuze hit op je uptime omdat je opeens afhankelijk bent van de uptime van al die andere services samen. Doe je dat niet, dan krijg je weer gezeik dat informatie ontbreekt of processen verderop in de keten niet goed functioneren.

[gekkie]

ThomasG schreef op donderdag 21 april 2022 @ 10:27:
[...]
Maar hoe koppel je twee single-spa's aan elkaar?

Geen idee, maar het resultaat lijkt op SPA lemon-cactus ?
Zuur en je prikt je steeds ?

[dev10]

Woy schreef op donderdag 21 april 2022 @ 11:09:
[...]

Microservices kunnen heel fijn werken, en hebben inderdaad een hoop voordelen. Maar het is niet triviaal om het juist op te zetten, en je moet ook tijdens de ontwikkeling na blijven denken over afbakening en manieren van communiceren.

Ik heb ergens wel eens gelezen dat een microservices architectuur niet zozeer een technische oplossing is, maar vooral een HR-oplossing en daar geloof ik nog steeds wel in. Als je te maken hebt met een kleiner team, geven al de losse microservices ook een hele hoop (onnodige) overhead.

[Mugwump]

dev10 schreef op donderdag 21 april 2022 @ 13:19:
[...]


Ik heb ergens wel eens gelezen dat een microservices architectuur niet zozeer een technische oplossing is, maar vooral een HR-oplossing en daar geloof ik nog steeds wel in. Als je te maken hebt met een kleiner team, geven al de losse microservices ook een hele hoop (onnodige) overhead.

Wat is er 'HR-oplossing' aan microservices? Als in, welk HR probleem is er en hoe lossen microservices dat probleem op?

[ Voor 7% gewijzigd door Mugwump op 21-04-2022 13:24 ]

[Caelorum]

dev10 schreef op donderdag 21 april 2022 @ 13:19:
[...]
Ik heb ergens wel eens gelezen dat een microservices architectuur niet zozeer een technische oplossing is, maar vooral een HR-oplossing en daar geloof ik nog steeds wel in. Als je te maken hebt met een kleiner team, geven al de losse microservices ook een hele hoop (onnodige) overhead.

Geen HR oplossing. Een oplossing om met meerdere teams aan een enkel groot product (of ecosysteem) te werken.

[dev10]

Mugwump schreef op donderdag 21 april 2022 @ 13:23:
[...]


Wat is er 'HR-oplossing' aan microservices? Als in, welk HR probleem is er en hoe lossen microservices dat probleem op?

Het is niet zozeer dat er een HR-probleem is, maar meer dat je kleine teams krijgt die zich gaan bezig houden met een specifieke microservice in plaats van met het grote geheel. Een soort van 'als iedereen goed zorgt voor z'n eigen kippen, hebben alle kippen het goed'

Zie: https://martinfowler.com/...roundBusinessCapabilities

HR-oplossing is misschien niet helemaal de juiste term. Misschien dat organisatorisch beter de lading dekt.

[ThomasG]

dev10 schreef op donderdag 21 april 2022 @ 13:36:
[...]


Het is niet zozeer dat er een HR-probleem is, maar meer dat je kleine teams krijgt die zich gaan bezig houden met een specifieke microservice in plaats van met het grote geheel. Een soort van 'als iedereen goed zorgt voor z'n eigen kippen, hebben alle kippen het goed'

Zie: https://martinfowler.com/...roundBusinessCapabilities

HR-oplossing is misschien niet helemaal de juiste term. Misschien dat organisatorisch beter de lading dekt.

Microservices hebben eigenlijk helemaal niets te maken met de grootte van het team. Maar met het gebruik van de applicatie. Een monolithic application schaalt gewoon heel erg slecht, vooral als sommige onderdelen veel meer gebruikt worden dan andere. Dan krijg je een enorme overhead, met enorme kosten, die voorkomen hadden kunnen worden.

Als de applicatie een microservice-achtige architectuur vereist, maar dat niet kan omdat je team te klein is, betekend dat eigenlijk gewoon dat je onderbezet bent. En dan heb je inderdaad een Human Resources probleem.

[Caelorum]

ThomasG schreef op donderdag 21 april 2022 @ 13:45:
[...]
Microservices hebben eigenlijk helemaal niets te maken met de grootte van het team. Maar met het gebruik van de applicatie. Een monolithic application schaalt gewoon heel erg slecht, vooral als sommige onderdelen veel meer gebruikt worden dan andere. Dan krijg je een enorme overhead, met enorme kosten, die voorkomen hadden kunnen worden.[...]

Dat ligt echt helemaal aan de applicaties. Soms kan je monolieten gewoon horizontaal schalen. Daarnaast is er vaak ook nul overhead van functionaliteit die niet worden gebruikt. In ieder geval als de monoliet een beetje fatsoenlijk is opgebouwd.

[....]
Als de applicatie een microservice-achtige architectuur vereist, maar dat niet kan omdat je team te klein is, betekend dat eigenlijk gewoon dat je onderbezet bent. En dan heb je inderdaad een Human Resources probleem.

Ik ga maar even een "gewaagde" uitspraak doen: Geen enkele applicatie vereist een microservice-architectuur. Wat wel zo is, is dat op een gegeven moment het organisatorisch handig wordt een team op te splitsen in meerdere teams en dat op een gegeven moment het aantal teams zodanig hoog worden dat het werken aan een enkele monoliet niet meer te doen is. Dat is het moment dat je gaat afsplitsen naar afzonderlijke applicaties en waar je eventueel een microservice-achtige architectuur op kan zetten.

[dev10]

ThomasG schreef op donderdag 21 april 2022 @ 13:45:
[...]
Dan krijg je een enorme overhead, met enorme kosten, die voorkomen hadden kunnen worden.

Ditzelfde argument geldt ook voor een microservices-architectuur ten opzicht van een monolith. Meer services betekent ook meer resources. In plaats van een databaseserver, heb je er bij wijze van spreken in eens drie nodig. Bij een kleine applicatie met een klein team, kun je je afvragen of dat het waard is en of je niet beter horizontaal kunt schalen.

Ik ben niet per se voor of tegen microservices en ik denk ook niet dat er een directe goed of fout is, maar klakkeloos een microservices architectuur inzetten neigt in mijn ogen snel naar premature optimalisatie.

[Mugwump]

dev10 schreef op donderdag 21 april 2022 @ 13:36:
[...]


Het is niet zozeer dat er een HR-probleem is, maar meer dat je kleine teams krijgt die zich gaan bezig houden met een specifieke microservice in plaats van met het grote geheel. Een soort van 'als iedereen goed zorgt voor z'n eigen kippen, hebben alle kippen het goed'

Zie: https://martinfowler.com/...roundBusinessCapabilities

HR-oplossing is misschien niet helemaal de juiste term. Misschien dat organisatorisch beter de lading dekt.

Ah op die fiets. Ik lees in deze omschrijving overigens meer dat teams over de functionele as in plaats van de technisch inhoudelijke as worden ingedeeld. Dat vind ik overigens vaak ook gewoon een vorm van technische problemen oplossen (of voorkomen). Ben zelf een groot voorstander van de DDD-aanpak waarbij je bounded contexts identificeert, waarbij die contexts dan als 'microservice' of als 'product' kunnen worden ingericht. Het idee dat er universele modellen voor zaken zijn te brouwen die toe te passen zijn op elk mogelijk (sub)domein leidt juist vaak tot veel problemen. Een product is in de context van voorraadbeheer iets heel anders dan in de context van facturatie. Dat heeft technische impact. Veel technische ellende ontstaat juist door zo'n one-size-fits-all aanpak.

Maar dan nog is het werken aan een "product" nog onafhankelijk van hoe groot je dat product maakt. Dat is ook gelijk een beetje de crux met iets als 'microservices'. Mensen gaan daar allerlei interpretaties aan hangen over hoe groot dan zo'n microservice zou moeten zijn. Ik zou eigenlijk altijd gewoon bij het ontwikkelen van een nieuw concept met enige vorm van complexiteit beginnen met een goed gestructureerde monolith waarin DDD concepten als bounded contexts leidend zijn, zodat je als de boel uit de klauwen groeit je makkelijk kunt kiezen wat je er al dan niet van afbreekt.

[DevWouter]

ThomasG schreef op donderdag 21 april 2022 @ 13:45:
[...]
Microservices hebben eigenlijk helemaal niets te maken met de grootte van het team. Maar met het gebruik van de applicatie. Een monolithic application schaalt gewoon heel erg slecht, vooral als sommige onderdelen veel meer gebruikt worden dan andere. Dan krijg je een enorme overhead, met enorme kosten, die voorkomen hadden kunnen worden.

Als de applicatie een microservice-achtige architectuur vereist, maar dat niet kan omdat je team te klein is, betekend dat eigenlijk gewoon dat je onderbezet bent. En dan heb je inderdaad een Human Resources probleem.

Je doet hier een beetje aan enterprise speak

Microservices kunnen ook een bottleneck vormen zelfs als ze goed ontworpen zijn. En genoeg voorbeelden van monolithic applicaties die uitermate goed schalen of juist breken wanneer ze in microservices worden opgebroken.

Microservices is één van de methodes om de architectuur in de applicatie te organiseren.
Service => Het verleent een dienst
Micro => Het is klein

Over tijd worden monolithic applicaties vaak opgebroken omdat de dienst die zij verlenen te complex wordt om in één keer te behappen (macro->micro) of omdat een gedeelte van de dienst (maar niet alles) hergebruikt kan worden in andere applicaties.

En er zijn ook voorbeelden waarbij microservices gebundeld worden (ik denk hier aan GraphQL) waarbij juist de services geen optimalisaties kunnen uitvoeren omdat ze niet over de schutting mogen/kunnen kijken (zie ook "Top Down vs Bottom Up TDD" waarbij beide methodes verschillende voordelen hebben).

@dev10 en @Caelorum Dat een microservice invloed heeft op hoe een team georganiseerd heeft te maken met het feit dat kenniswerkers (zoals ontwikkelaars) hun workload continue optimaliseren.

[CodeCaster]

Ik heb hier al vaker gezeken over Windows versus Mac, en de laatste maanden ben ik steeds meer aan die laatste aan het wennen. Het windowmanagement en gebruik van meerdere schermen blijft te wensen overlaten^*, maar waar ik me op Windows steeds meer aan erger: het startmenu. Hoe heeft Microsoft het nou in godesnaam voor elkaar gekregen om al jarenlang een volstrekt niet functionerende zoekfunctie in het startmenu te hebben?

Als ik op start klik (of de Windows-toets indruk) en "update" intik om naar "Windows Update" te gaan, dan moet Windows steevast een seconde of twee nadenken en toont dan "Discord". Ja, heel grappig, Discord heeft inderdaad iedere dag vijf updates, maar da's net niet waar ik naar op zoek was. Of het startmenu blijft wit na het intikken van een paar letters. Of het versrpingt op het moment dat je op Enter drukt, en start iets wat je helemaal niet zocht. En dat op iets van zestien cores, 32 GB en een SSD die een ontelbare IOPS aan kan en 2 GiB/s kan lezen en schrijven per seconde. Het lijkt echt alsof het startmenu niet geïndexeerd is, maar dat je hele systeem wordt doorzocht op het moment van tikken.

Hoe de fsck houden ze hieraan vast, en waarom lukt het ze niet om dit te verbeteren? De Mac weet binnen 2 letters en 0,2 seconden welk programma ik via Spotlight (Cmd+Spatie) wil lanceren.

^*: een scherm dat verbonden is, maar niet ingeschakeld of via een andere input aan een andere machine verbonden, eet nog steeds je muisaanwijzer en vensters op. En ook je Cmd+Tab verschijnt op een uitgeschakeld scherm, wanneer je voor het laatst op dat scherm die toetsencombinatie hebt ingedrukt. Vensters kunnen niet over meerdere schermen worden getoond. Het dock wil altijd je muis volgen, het is niet mogelijk om dit te pinnen aan één beeldscherm. Het positioneren van verschillende beeldschermen (met name met Universal Control ingeschakeld) is onhandig. Het verbinden van docks/DisplayLinks zorgt voor veel fouten en werkt vaker niet dan wel, beter start je de Mac gewoon op met dat appraat verbonden.

[ Voor 3% gewijzigd door CodeCaster op 24-04-2022 16:53 ]

[RagingPenguin]

CodeCaster schreef op zondag 24 april 2022 @ 16:52:
Als ik op start klik (of de Windows-toets indruk) en "update" intik om naar "Windows Update" te gaan, dan moet Windows steevast een seconde of twee nadenken en toont dan "Discord". Ja, heel grappig, Discord heeft inderdaad iedere dag vijf updates, maar da's net niet waar ik naar op zoek was. Of het startmenu blijft wit na het intikken van een paar letters. Of het versrpingt op het moment dat je op Enter drukt, en start iets wat je helemaal niet zocht. En dat op iets van zestien cores, 32 GB en een SSD die een ontelbare IOPS aan kan en 2 GiB/s kan lezen en schrijven per seconde. Het lijkt echt alsof het startmenu niet geïndexeerd is, maar dat je hele systeem wordt doorzocht op het moment van tikken.

Hoe de fsck houden ze hieraan vast, en waarom lukt het ze niet om dit te verbeteren? De Mac weet binnen 2 letters en 0,2 seconden welk programma ik via Spotlight (Cmd+Spatie) wil lanceren.

Same here, die zoek functie is inderdaad gewoon compleet ruk. Waar ik mij ook altijd mateloos aan erger is dat als je direct na het opstarten iets wilt zoeken je geen resultaten krijgt, enkel een wit vlak. En dan moet je eerst het startmenu sluiten en het dan opnieuw proberen voordat die het doet. Of dat die inderdaad verspringt en dan in edge bing opent ipv je programa.

Ongerelateerd: alt-tab tussen programma's die op een andere resolutie draaien is ook irritant traag met meerdere verspringen.

[Mugwump]

RagingPenguin schreef op zondag 24 april 2022 @ 17:49:
[...]


Same here, die zoek functie is inderdaad gewoon compleet ruk. Waar ik mij ook altijd mateloos aan erger is dat als je direct na het opstarten iets wilt zoeken je geen resultaten krijgt, enkel een wit vlak. En dan moet je eerst het startmenu sluiten en het dan opnieuw proberen voordat die het doet. Of dat die inderdaad verspringt en dan in edge bing opent ipv je programa.

Ongerelateerd: alt-tab tussen programma's die op een andere resolutie draaien is ook irritant traag met meerdere verspringen.

Daarom zweer ik ook nog bij Launchy zolang ik nog een Windowslaptop heb.

[bwerg]

CodeCaster schreef op zondag 24 april 2022 @ 16:52:
Hoe heeft Microsoft het nou in godesnaam voor elkaar gekregen om al jarenlang een volstrekt niet functionerende zoekfunctie in het startmenu te hebben?

Ik heb soms echt het idee dat MS een bepaalde weg ingeslagen is en als een concurrent later met een betere oplossing komt, het dan gewoon pure koppigheid van MS is om niet toe te geven dat MS dat idee misschien ook gewoon moet overnemen. En dat er dus jaren aan bepaalde keuzes wordt vastgehouden onder het mom "hier wen je als gebruiker vanzelf aan" en "het is niet slechter, het is anders". Al heeft macOS dat vast ook, gebruik het te weinig om dat te kunnen zeggen. En als het bij linux verkeerd is had je gewoon de verkeerde distro, dat ligt volledig aan de gebruiker.

Mijn persoonlijke verwondering nummer 1 ligt bij het niet hebben van tabs in file explorer - waarin ze eindelijk hebben besloten dat dat misschien anders moet, een decennium of wat nadat het op andere OS'en gangbaar werd.

[ Voor 9% gewijzigd door bwerg op 25-04-2022 07:53 ]

[Lethalis]

PrisonerOfPain schreef op dinsdag 19 april 2022 @ 13:10:
[...]
Get with the times grandpa

Dit was mijn motivatie om Windows 11 te gebruiken. Zo erg is het al met mij gesteld.

Het ziet er mooier uit, maar werkt voor de rest niet echt lekker. Zoekfunctie van het menu doet het vaker niet dan wel. Visual Studio 2022 zorgt er tijdens debug sessies nog steeds voor dat het switchen tussen vensters op Windows 11 vaak niet werkt. En je hebt een registry editor nodig als je een handig / niet dumbed down context menu wil in de verkenner.

Aan de andere kant zat ik laatst weer eens achter een Mac en daar kan ik ook niet aan wennen

En Linux is alleen leuk totdat je weer net dat ene dingetje nodig hebt dat het uiteraard niet doet, of alleen voor Windows en Mac gemaakt wordt.

Voorlopig blijf ik Windows gebruiken dus. Heb de nodige uitstapjes gehad naar Linux en ook de Mac, maar eindig altijd weer bij Windows.

[ Voor 16% gewijzigd door Lethalis op 24-04-2022 22:59 ]

[Mugwump]

bwerg schreef op zondag 24 april 2022 @ 22:24:

Mijn persoonlijke verwondering nummer 1 ligt bij het niet hebben van tabs in file explorer - waarin ze eindelijk hebben besloten dat dat misschien anders moet, een decennium of wat nadat het op andere OS'en gangbaar werd.

Dat hebben ze bij Internet Explorer ook vrij lang vol weten te houden

[jbdeiman]

dev10 schreef op donderdag 21 april 2022 @ 13:19:
[...]


Ik heb ergens wel eens gelezen dat een microservices architectuur niet zozeer een technische oplossing is, maar vooral een HR-oplossing en daar geloof ik nog steeds wel in. Als je te maken hebt met een kleiner team, geven al de losse microservices ook een hele hoop (onnodige) overhead.

Tjah, het geeft aan de ene kant overhead, aan de andere kant is het gemakkelijker aanpassingen door te voeren die niet direct van invloed zijn op overige onderdelen van het proces, een klein stukje op te schalen (hardware 'lenen' kost veel bij een grote applicatie, als je die steeds in het geheel moet opschalen), terwijl de rest dat niet hoeft te doen én het maakt het (met name in grotere teams overigens) handiger om in verschillende teams een stuk op te pakken/ te bouwen/ te verbeteren.
In ons geval (we komen van een Full Framework applicatie, met een relatief klein team (6 devs) is één van de redenen om dit om te zetten het beter schaalbaar maken van de applicatie (meer onderdelen schaalbaar krijgen), maar ook het versimpelen van onderhoud én updates van de applicatie. Een (micro)service laten stoppen en een nieuwe opstarten (eigenlijk andersom, met blue-green deployment) heeft weinig impact en gebruikers merken daar verder niets van. Een Full framework applicatie bijwerken heeft daarin gewoon wat meer impact.

I.m.o. is het enerzijds handig dat Marketing er gebruik van maakt, maar het biedt ook daadwerkelijk voordelen, het is geen gebakken lucht dat ze verkopen ofzo.

[RagingPenguin]

Mugwump schreef op maandag 25 april 2022 @ 08:30:
[...]


Dat hebben ze bij Internet Explorer ook vrij lang vol weten te houden

En ook voor powershell/command prompt.

[Caelorum]

jbdeiman schreef op maandag 25 april 2022 @ 08:57:
[...]
maar ook het versimpelen van onderhoud én updates van de applicatie. Een (micro)service laten stoppen en een nieuwe opstarten (eigenlijk andersom, met blue-green deployment) heeft weinig impact en gebruikers merken daar verder niets van. Een Full framework applicatie bijwerken heeft daarin gewoon wat meer impact.
[...]

Dit heeft alles met .net framework (en de opzet van de meeste applicaties daarin) en .net 6 te maken en niets met microservices natuurlijk. Er is ook geen reden waarom je niet een tweede monoliet op basis van .net framework ernaast kan draaien, die "warm" maken en dan geleidelijk de gebruikers over te hevelen en dan de oude uit te zetten. Update zonder downtime. Alleen wordt het meestal niet zo gedaan bij die applicaties.

[RagingPenguin]

Caelorum schreef op maandag 25 april 2022 @ 09:31:
[...]

Dit heeft alles met .net framework (en de opzet van de meeste applicaties daarin) en .net 6 te maken en niets met microservices natuurlijk. Er is ook geen reden waarom je niet een tweede monoliet op basis van .net framework ernaast kan draaien, die "warm" maken en dan geleidelijk de gebruikers over te hevelen en dan de oude uit te zetten. Update zonder downtime. Alleen wordt het meestal niet zo gedaan bij die applicaties.

Dat is vooral een kwestie van je applicaties stateless maken zodat je meerdere instances kan hebben zonder dat ze ander gedrag vertonen. En dat kan ook gewoon prima in een Dotnet MVC applicatie, dat doen wij hier voor alles. Daar zit verder niks statefulls in zolang je dat niet zelf toevoegd.