Engineering is like Tetris. Succes disappears and errors accumulate.
Hoe definieer je waardevol?phex schreef op donderdag 14 september 2023 @ 19:45:
[...]
Schattig dat de rest van mijn reacties negeert, ik heb nergens gezegd dat ik test overrated vind. Ik zei dat het bij ons niet waardevol genoeg was.
Maar zoek vooral bevestig in je eigen wereld en probeer je totaal niet in te leven in iemand anders realiteit.
Engineering is like Tetris. Succes disappears and errors accumulate.
Handmatig testen is nooit zo klinisch en consistent als geautomatiseerd testen. Goed handmatig testen is zo ontzettend arbeidsintensief dat zoveel mogelijk automatiseren (zeker met alle bijna kant-en-klare tooling tegenwoordig) altijd de voorkeur heeft.Verwijderd schreef op donderdag 14 september 2023 @ 17:05:
[...]
Ik denk niet dat er een verschil zit, meer bugs etc. Maar ik denk wel dat je sommige dingen kan automatiseren. Ik heb vroeger aan een draak van een software programma gewerkt, waar we met 2 a 3 man aan werkten. Tests waren handmatig en bij elke release ( op zaterdag ) werdt er flink getest. Je kopieerde dan je branch naar live en daar zat soms nog wel een bugje in. Ik moet zeggen dat elke keer 2 uur testen er soms wat er doorheen schoot. Maarja, dat had je met tests. Zo werd het gedaan en meestal was er nog wel eens een bugje die dan door de week gedaan werd. Je kan niet allesafvangen met geautomatiseerde tests idem. Wat ik wel ga testen is bijvoorbeeld via de browser of je kan inloggen/uitloggen nieuw registeren eventueel etc. Tests kunnen veel opvangen maar niet alles (zoals extra wijzigingen in de db) bij een actie. De guru moet eruit maar bugs voorkom je niet. Waar de kracht van tests liggen is, eerder werkte het wel, na de update niet meer.
Zoals ik ook al eens eerder heb aangegeven is, je kunt geen 10en blijven produceren de hele dag over de code. Wat wel kan is 6-8, en dan met hotfixes brengen tot een 9-10.
Maar ik ga wat tests schrijven maar niet tot in den treure. Moet progressie inzitten en documentatie kost al veel, maar tijdens het documenteren een paar tests schrijven wellicht...
Trouwens andere vraag, iemand idee hoe je op mobiel kan debuggen? Heb met de Samsung browser dat ie niet doorlaadt (soms) maarja geen F12 voorhanden?
Dan heeft het weinig zin hier verder een discussie over te houden.
Als je met deze insteek kwam discussieren dan kwam je eigenlijk niet discussieren.phex schreef op donderdag 14 september 2023 @ 20:01:
Als iedereen hier van mening is dat je zonder test cases niet fatsoenlijk kan ontwikkelen dan heb ik mijn eerste post over dit topic bevestigd gekregen.
Dan heeft het weinig zin hier verder een discussie over te houden.
Natuurlijk kun je software ontwikkelen zonder geautomatiseerde tests. Maar net als alle best practices bestaan ze met een bepaalde reden. Over het algemeen is het tijd voor reflectie als de overgrote meerderheid het niet met je eens is.
Naja dan is de "discussie" toch wel klaar?
[ Voor 77% gewijzigd door phex op 14-09-2023 20:23 ]
Ja dit helpt.
Volgens mij zegt niet iedereen dat je niet kan ontwikkelen zonder tests. Dat kan je prima.
Maar je kan gewoon veel moeilijker onderhouden zonder tests. Je hoeft echt niet vol TTD te gaan om de voordelen te hebben.
Edit: wat ik zelf heel fijn vind is als ik aan een feature werk die groot en complex is en niet alles uitgedacht is dat ik dan stukje bij beetje de functionaliteit bouw. Vervolgens borg ik het gedrag dat wel goed werkt met tests (dus niet tdd). Ik hoef er dan niet meer over na te denken.
Langzaam bouw ik dan verder totdat de hele feature werkt. Maar tijdens de bouw refactor ik, herstructureer ik en pas dingen aan. En als dan m’n tests falen en ik fix het dan blijf ik vooruitgaan. En uiteindelijk heb ik dan iets dusdanig complex gebouwd wat ook eens goed geborgd is kwa tests.
Er zijn de afgelopen jaren een paar van dit soort featured geweest die ik zo complex vond dat ik het moeilijk kon overzien. Door het dan zo stukje bij beetje op te bouwen heb ik uiteindelijk dingen gebouwd waarvan ik van tevoren niet had gedacht ze te kunnen.
[ Voor 53% gewijzigd door armageddon_2k1 op 14-09-2023 20:27 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
Je kan in Chrome op je PC remote debugging gebruiken met een Andriod device.Verwijderd schreef op donderdag 14 september 2023 @ 17:05:
[...]
Trouwens andere vraag, iemand idee hoe je op mobiel kan debuggen? Heb met de Samsung browser dat ie niet doorlaadt (soms) maarja geen F12 voorhanden?
Nou, ik kan het me prima voorstellen. Want zo hebben de meesten het denk ik ook wel ooit gedaan of meegemaakt. En ik zit nu grotendeels in zo’n project, vandaar ook dat ik de hele discussie opgerakeld had. Maar het is gewoon slecht schaalbaar en op de lange termijn erg duur. Nogmaals, er is een continuüm tussen niet automatisch testen en full coverage. Jij bent de extremist aan de ene kant. De rest is vermoedelijk de gematigde middenmoter.phex schreef op donderdag 14 september 2023 @ 20:10:
Ik roep redenen waarom het voor ons werkt. Daar kan niemand hier zich iets bij voorstellen, beter nog, meerdere personen hebben wel een neerbuigende opmerking klaar.
Naja dan is de "discussie" toch wel klaar?
Je zegt het zelf niet waardevol te vinden. Maar hoe definieer je waarde dan?
Kan jij je voorstellen waarom het wel zou helpen?
[ Voor 11% gewijzigd door armageddon_2k1 op 14-09-2023 20:36 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
Ja, of je zou eens kunnen bedenken of er misschien een kans op reflectie in zit. Als je een discussie ingaat met een mening die je bij voorbaat niet gaat veranderen was het toch nooit een discussie?phex schreef op donderdag 14 september 2023 @ 20:10:
Ik roep redenen waarom het voor ons werkt. Daar kan niemand hier zich iets bij voorstellen, beter nog, meerdere personen hebben wel een neerbuigende opmerking klaar.
Naja dan is de "discussie" toch wel klaar?
De kosten van een hotfix:
- klant verliest tijd door probleem
- klant belt een helpdesk of chat oid (en niet elke doet dat dus meerderen hebben het probleem gehad)
- helpdesk moet uitvragen
- helpdesk maakt ticket
- developer moet van z’n werk af door productie ticket
- moet reproduceren en uitpluizen
- moet fixen
- fix moet in acceptatie getest worden met handje
- productie update
- ticket sluiten en helpdesk inlichten
- klant inlichten
Fucking duur.
Geen tests schrijven is werk verplaatsen naar de toekomst waar meer mensen voor nodig zijn op een ongepland moment.
[ Voor 7% gewijzigd door armageddon_2k1 op 14-09-2023 20:51 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Verwijderd
Ja weet ik, heb het probleem nog niet in Chrome gehad, wel in de Samsung browser.RagingPenguin schreef op donderdag 14 september 2023 @ 20:24:
[...]
Je kan in Chrome op je PC remote debugging gebruiken met een Andriod device.
Waarschijnlijk een javascript bug want hij laadt de initiële pagina wel, maar laadt niet door (javascript) maar ook niet altijd. Herladen en het doet het. Misschien iets met cache en mijn laad mechanisme.
Tdd is heel mooi, maar tijdsintensief. Als je weet dat je maanden/ jaren op een project lijkt het mij de moeite waard. Maar ik ga browser tests schrijven en geen unit tests. Oftewel een screenshot voor de opmaak en een vergelijking file based met de content. Die unit tests (asserts) laat ik denk ik achterwege vanwege het feit dat ik die niet nodig vind. Wel handig om een methode te testen. Wellicht enkele plugins toch wel maar goed, om nou elke methode/plugin te testen (meeste zijn wrappers naar php functies) kom ik al gauw aan 1000+ tests die ik moet testen
TDD tijdsintensief? Misschien, maar het is wel tijd die goed besteed is. Het bespaart uiteindelijk tijd.Verwijderd schreef op vrijdag 15 september 2023 @ 00:13:
[...]
Ja weet ik, heb het probleem nog niet in Chrome gehad, wel in de Samsung browser.
Waarschijnlijk een javascript bug want hij laadt de initiële pagina wel, maar laadt niet door (javascript) maar ook niet altijd. Herladen en het doet het. Misschien iets met cache en mijn laad mechanisme.
Tdd is heel mooi, maar tijdsintensief. Als je weet dat je maanden/ jaren op een project lijkt het mij de moeite waard. Maar ik ga browser tests schrijven en geen unit tests. Oftewel een screenshot voor de opmaak en een vergelijking file based met de content. Die unit tests (asserts) laat ik denk ik achterwege vanwege het feit dat ik die niet nodig vind. Wel handig om een methode te testen. Wellicht enkele plugins toch wel maar goed, om nou elke methode/plugin te testen (meeste zijn wrappers naar php functies) kom ik al gauw aan 1000+ tests die ik moet testen
Overigens is TDD niet gelijk aan het schrijven van unit tests. TDD is dat je je tests eerst schrijft en dan de bijbehorende code. Heel productief, zeker als je het integreert in je workflow. Veel webdevelopment is nog steeds "edit code->save file->reload browser->result niet goed -> opnieuw' en door TDD kun je een flink deel van je code ontwikkelen zonder een browser te gebruiken.The results obtained showed the TDD
developers develop software code with a higher quality rate, and it results in
increasing team productivity than NON_TDD developers
Ik vond zelf unit tests altijd een beetje mosterd na de maaltijd. Dan ben je voor je gevoel klaar en dan moet je nog tests schrijven. Saai. Ik ben toen begonnen met een test-first aanpak. En dat werkt een heel stuk beter. Het is even omschakelen maar ik denk nu veel beter na over hoe mijn code moet werken (welke methods, classes, parameters). Wat uiteindelijk de kwaliteit ten goede komt en voor mezelf en mijn collega's tijd bespaart.
Ik ben verder geen TDD-fundamentalist. Ik sta er ongeveer zo in:
Be pragmatic about what you do and don’t need to test extensively. For example, if you are dealing with people’s money, you better be very confident in your code. That’s a situation that calls for ~%100 code coverage. For most other things, you can likely get away with testing the “happy path” and some of the obvious error states.
What has given me the most bang for my buck is writing integration tests for my backend’s API. Basically, I want to know that when I make requests to my server, I will receive the responses I am expecting. My frontend doesn’t care one bit about the implementation behind this interface. As long as I know that my API is working as expected, I can ship with some level of confidence.
Prior to experimenting with TDD, like most folks, I would write tests AFTER I had written my code. I still sometimes do this (don’t judge me). The issue with this, is that you have to go about testing your code some other way in the meantime, usually manually, and this is time intensive.
Sorry, je zegt zelf "we hebben geen geautomatiseerde test want we testen uitgebreid handmatig". Dat kan ik gewoon niet serieus nemen.phex schreef op donderdag 14 september 2023 @ 19:45:
[...]
Schattig dat de rest van mijn reacties negeert, ik heb nergens gezegd dat ik test overrated vind. Ik zei dat het bij ons niet waardevol genoeg was.
1 spookrijder? Ik zie er wel 10!Maar zoek vooral bevestig in je eigen wereld en probeer je totaal niet in te leven in iemand anders realiteit.
Ik zit al 25 jaar in het vak en heb in die tijd bij verschillende bedrijven en instellingen in verschillende vakgebieden gewerkt in teams van 1 tot 30 man. Ik denk dat 'mijn eigen wereld' best een fatsoenlijk referentiekader is.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Gebruik je Copilot?Caelorum schreef op vrijdag 15 september 2023 @ 09:37:
Software ontwikkelen is automatiseren. Waarom zoveel mensen in het vak vervolgens blind zijn om zichzelf en andere collega's te automatiseren is me echt een raadsel.
Engineering is like Tetris. Succes disappears and errors accumulate.
Ik ben ook van mening dat het er van af kan hangen. Al zit het em vaak in voor welke delen je tests belangrijk zijn el voor welke minder.phex schreef op donderdag 14 september 2023 @ 10:27:
(...)
De discussie is vaak:
- Als je geen tests schijft ben je per definitie slecht bezig
- Als je wel tests schrijft ben je tijd en geld aan het verspillen
Terwijl het volgens mij afhangt van je team, code base en use case.
Ik wil een paar statements maken over tests:
- Met testen test je enkel dat je bugs hebt, niet of dat je geen bugs hebt.
- Tests zijn code, kosten resources en onderhoud.
- Tests zijn automatisering, moeten meer opleveren dan ze kosten om rendabel te zijn.
- Tests zijn geen excuus om niet meer handmatig te testen.
- Het besluit om te investeren in tests is een business case.
Je kunt heel veel energie steken in een goede test coverage voor een bash scriptje van 5 regels dat je eenmalig gebruikt maar waarschijnlijk kun je, je energie ergens anders beter inzetten:“Program testing can be used to show the presence of bugs, but never to show their absence!”
― Edsger W. Dijkstra
- Als een bug optreed, had je het zonder tests ook gevangen.
- De test kost naar verhouding veel development tijd.
- De test zit complexe reactors waarschijnlijk alleen maar in de weg met een falende test.
Super complexe berekeningen zijn een no-brainer voor tests.
Bepaalde efforts zijn meer rendabel dan andere en je weet van te voren niet altijd waar jij of anderen tegenaan gaan lopen, dit zijn allemaal factoren die je mee kunt wegen in je test aanpak, en er zijn meer knoppen om aan te draaien dan alleen of je wel of niet tests schrijft, bijvoorbeeld wat voor tests je schrijft (unit, interaction etc.).
Ik neem even een eer genoemd uitgangspunt:
Als een UI component stuk gaat is er in mijn ervaring doorgaans het volgende aan de hand:phex schreef op donderdag 14 september 2023 @ 15:58:
Omdat de wijzigingen ook vaak op UI/UX gebied zijn bij ons. Dan kun je wel heel veel tijd steken in geautomatiseerde testen, maar wat test je dan? Iig niet alles.
- Errored de build omdat TypeScript detecteert dat ergens een interface/type niet klopt.
- Rendered een component totaal niet.
- Klopt de UI/UX niet meer.
Nu laat ik even beginnen met dat je wel UI/UX kan testen op verschillende manieren. Wij maken bijvoorbeeld gebruik van Chromatic op basis van Storybook stories voor visual regression en interactie testing. Lang verhaal kort: als je een style change maakt moet die expliciet goedgekeurd maken anders faalt je test.
De tests (stories) renderen een component in een geïsoleerde omgeving met vooringestelde input en context. Dit soort (ui) tests zijn vaak voor frontend waardevoller dan unit tests die een eenvoudig codepad volgen. Daarnaast is het het voor sommige componenten zo dat die zo simpel zijn dat je aan een enkele "smoketest story" al genoeg hebt. Die test dan:
- Of het component werkt met standaard (React) props.
- Bij een PR of het component met die initiële props er nog steeds hetzelfde uitziet als de vorige keer.
Deze story wordt bij ons vaak samen met het initiële component, een stylesheet, en een index bestand genereert door een simpel (niet getest) bash scriptje. De test voor het component is dus zo goed als gratis en de waarde ervan zeer hoog.
- Als een bug optreed, is een vrij goede kans om die te vangen.
- De test kost weinig development tijd.
- De test maakt complexe reactors goed te overzien.
We hebben ook scenario's waarin we gewoon TDD werken of zelf een case waarin we bewust meerdere test suites met andere aanpak hebben voor exact dezelfde code.
Ik ben niet zo'n fan van elkaar niet serieus nemen vanwege een andere mening. Daarnaast, geautomatiseerd testen vervangt handmatig testen niet.Janoz schreef op vrijdag 15 september 2023 @ 09:11:
[...]
Sorry, je zegt zelf "we hebben geen geautomatiseerde test want we testen uitgebreid handmatig". Dat kan ik gewoon niet serieus nemen.
Verwijderd
Teams veranderen, kennis vergaat, een goede test set zorgt dat alles nog staat.
Engineering is like Tetris. Succes disappears and errors accumulate.
Verwijderd
Leuk gezegdearmageddon_2k1 schreef op vrijdag 15 september 2023 @ 10:48:
Teams veranderen, kennis vergaat, een goede test set zorgt dat alles nog staat.
Ja, dat heet visual regression testing, genoeg tools voor. Als je React gebruikt is Storybook/Chromatic redelijk goto. Maar er bestaan er meer.Verwijderd schreef op vrijdag 15 september 2023 @ 10:46:
Ik ben meer van code, dat proberen te documenteren en ik dacht als ik dan toch documenteer wat een functie moet doen, wellicht 1 of meerdere tests erbij maken. Ik ben momenteel bezig met een framework en heb eigenlijk tot nu toe alles met de hand getest. Ook doordat het veel bestanden aanraken momenteel is, wil ik wachten met testen tot de documentatie fase. Had bijna een versie 1, maar dacht nog 1 module toe te voegen. Ook die weer met de hand getest. Nu is het zo dat ik het opnieuw moet documenteren want veel wijzigingen / grote impact. Mijn plan is om dan de api testbaar te maken en er een aparte testbranch van te maken met Chrome als headless browser en eigen data gescheiden van dev en productie. Iemand enig idee of die screenshots ook gecompared kunnen worden? Dus levert het telkens dezelfde png op, of jpeg ?
Wat wil je vergelijken? Uit je verhaal maak ik een beetje op dat je API output wilt testen, daar zijn andere tools voor.
Verwijderd
Ik wilde graag kunnen scripten in json en daar was nog niets voor, en ja het groeit naarmate de tijd vordert, maar zeker leuke leerweg geweest. Veel gekeken hoe andere php frameworks werken en de goede dingen geïmplementeerd, maar dan op mijn manier. Config, routing allemaal data geworden ipv code.
Heb wel een tijdje met react mogen werken. De cursus was leuk, maar onze codebase met typescript vond ik deste minder. Veel te grote source voor wat je wil eigenlijk. Basis elementen was not done op div na en typescript in kleine teams geeft je type checks, maar dat vind ik voor frontend eigenlijk overkill.
Json ga ik gewoon filebased vergelijken met een mooi screenshot als het ff kan
[ Voor 4% gewijzigd door Verwijderd op 15-09-2023 11:14 ]
Ja en chatgpt. Ik volg het hard op de voet en ik kan nu al met die dingen in 1 FTE een compleet extern team overbodig maken.
Als je json wilt vergelijken heb je geen screenshot nodig toch, gewoon een fixture? Volgens mij kan playwright screenshots vergelijken voor de visuele use case.Verwijderd schreef op vrijdag 15 september 2023 @ 11:13:
Ik gebruik liever geen react, typescript etc. Ik doe php, mijn template/json/javascript parser taal, html, css, geen scss, javascript (plain en mijn eigen gemakkelijke javascript library) en daar kan ik het meeste momenteel wel mee schrijven wat ik wil. Mijn parser zou ook xml/yaml/css kunnen parsen maar daar heb ik momenteel nog geen usecase voor.
Ik wilde graag kunnen scripten in json en daar was nog niets voor, en ja het groeit naarmate de tijd vordert, maar zeker leuke leerweg geweest. Veel gekeken hoe andere php frameworks werken en de goede dingen geïmplementeerd, maar dan op mijn manier. Config, routing allemaal data geworden ipv code.
Heb wel een tijdje met react mogen werken. De cursus was leuk, maar onze codebase met typescript vond ik deste minder. Veel te grote source voor wat je wil eigenlijk. Basis elementen was not done op div na en typescript in kleine teams geeft je type checks, maar dat vind ik voor frontend eigenlijk overkill.
Json ga ik gewoon filebased vergelijken met een mooi screenshot als het ff kan
Ik ben wel benieuwd wat dit nu zo fantastisch automatiseert in jouw geval. Ik ben zelf nog niet kapot van wat ik tot nu toe gezien heb. Misschien ook omdat er niet per se heel veel triviaal werk in onze codebase zit, maar zelfs dingetjes als 'hey schrijf even een stukje code dat iets zo en zo wegzet in S3' levert nou niet direct heel fantastisch bruikbaar werk op, terwijl dat nu bij uitstek het soort domme klopwerk is dat je weggeautomatiseerd wil hebben.Caelorum schreef op vrijdag 15 september 2023 @ 12:25:
[...]
Ja en chatgpt. Ik volg het hard op de voet en ik kan nu al met die dingen in 1 FTE een compleet extern team overbodig maken.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Heb je daar dan niet meestal al wel ergens zelf een bruikbare snippet van liggen, die min of meer ook minimaal aanpasbaar is zodat het netjes in de rest van de code integreert, net zoals je met die ChatGPT meuk ook zult hebben ?Mugwump schreef op vrijdag 15 september 2023 @ 12:43:
[...]
Ik ben wel benieuwd wat dit nu zo fantastisch automatiseert in jouw geval. Ik ben zelf nog niet kapot van wat ik tot nu toe gezien heb. Misschien ook omdat er niet per se heel veel triviaal werk in onze codebase zit, maar zelfs dingetjes als 'hey schrijf even een stukje code dat iets zo en zo wegzet in S3' levert nou niet direct heel fantastisch bruikbaar werk op, terwijl dat nu bij uitstek het soort domme klopwerk is dat je weggeautomatiseerd wil hebben.
Ja, en je hebt natuurlijk gewoon een SDK. Maar je hebt altijd ergens wat boilerplating.gekkie schreef op vrijdag 15 september 2023 @ 12:47:
[...]
Heb je daar dan niet meestal al wel ergens zelf een bruikbare snippet van liggen, die min of meer ook minimaal aanpasbaar is zodat het netjes in de rest van de code integreert, net zoals je met die ChatGPT meuk ook zult hebben ?
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ja maar hoe goed is ChatGPT in het oplepelen daarvan dat het qua style, naming etc. gelijk een goede fit is in jouw codebase (en het aanpassen van copy en paste boilerplate is toch ook zo wat) ?Mugwump schreef op vrijdag 15 september 2023 @ 12:53:
[...]
Ja, en je hebt natuurlijk gewoon een SDK. Maar je hebt altijd ergens wat boilerplating.
Of is het vooral dat het wat eenvoudiger zoekt in de snippets van stackoverflow en je kunt blijven volhouden dat je geen "stackoverflow copy&paster" bent
Maar inderdaad, vrijwel elk resultaat heeft wel iets van rework nodig, maar dan nog scheelt het een bak werk. 1 regel typen kan zo maar 40 regels aan nagenoeg correcte code opleveren. Klein beetje lezen welk reworken en dan kunnen we door. Kan ik me met belangrijkere of complexere zaken bezig houden.
Engineering is like Tetris. Succes disappears and errors accumulate.
Nou, het is wel ietsje anders dan het oplepelen van snippets.gekkie schreef op vrijdag 15 september 2023 @ 13:05:
[...]
Ja maar hoe goed is ChatGPT in het oplepelen daarvan dat het qua style, naming etc. gelijk een goede fit is in jouw codebase (en het aanpassen van copy en paste boilerplate is toch ook zo wat) ?
Of is het vooral dat het wat eenvoudiger zoekt in de snippets van stackoverflow en je kunt blijven volhouden dat je geen "stackoverflow copy&paster" bent
Voorbeeldje. Ik ben bezig geweest met mijn eigen taal maken, inclusief lexer, parser en interpreter. Bij het schrijven van de unit-tests kwam ie zelf met voorstellen van code in mijn eigen bedachte taal inclusief wat de verwachte output was.
Engineering is like Tetris. Succes disappears and errors accumulate.
In welke zin helpt dat? Laat je achteraf dan tests genereren die valideren dat de code doe wat de code zegt dat het doet?armageddon_2k1 schreef op vrijdag 15 september 2023 @ 16:58:
Juist met het schrijven van tests helpt copilot me enorm
Idealiter werk ik op een TDD-achtige wijze waarop je relevante functionele specificaties in tests vangt en je tests je ook helpen om ontwerp- en architectuurkeuzes te maken.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Je kunt in comments beschrijven wat copilot moet gaan doen. Dus dan kun je alsnog eerst je tests schrijven.Mugwump schreef op maandag 18 september 2023 @ 15:24:
[...]
In welke zin helpt dat? Laat je achteraf dan tests genereren die valideren dat de code doe wat de code zegt dat het doet?
Idealiter werk ik op een TDD-achtige wijze waarop je relevante functionele specificaties in tests vangt en je tests je ook helpen om ontwerp- en architectuurkeuzes te maken.
Het grappige is dat dát ook enigszins voor ChatGPT werkt. Je kunt ChatGPT de code laten schrijven, vervolgens uitgebreide unit tests laten schrijven. Vaak zie je dan dat een aantal unit tests falen. Meestal is de test wel goed, maar het resultaat niet. Als je dan de unit test resultaten copy-paste, verbeterd ChatGPT de code weer. Als dat fout gaat (/blijft gaan) ben je meestal niet specifiek genoeg geweest
Nee, ik definieer de interface en schrijf dan tests en copilot neemt heel veel boilerplate weg en vult goed aan. Daarna maak ik een implementatie en test die. Of, als ik niet zo formeel werk dan maak ik een class/functie/whatever met placeholders, ik creeer een relevante fixture en ik schrijf tests terwijl ik implementeer om de werking te borgen en impliciet als spec te dienenMugwump schreef op maandag 18 september 2023 @ 15:24:
[...]
In welke zin helpt dat? Laat je achteraf dan tests genereren die valideren dat de code doe wat de code zegt dat het doet?
Idealiter werk ik op een TDD-achtige wijze waarop je relevante functionele specificaties in tests vangt en je tests je ook helpen om ontwerp- en architectuurkeuzes te maken.
Volgens mij denken heel veel mensen dat copilot in dit geval dingen volledig uitwerkt maar dat is niet zo. En dan vindt men het tegenvallen. Het doet gewoon een hele nuttige autocomplete waar door ik gewoon veel efficiënter ben.
[ Voor 13% gewijzigd door armageddon_2k1 op 18-09-2023 16:27 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
Vooral Outlook/Microsoft is een absolute ramp.
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Ik ben die "you are using an adblocker, please disable it for our website because blablablaoebuad.bnacfdqm" ontiegelijk zat.
Dus heb ik het tegenovergestelde gedaan op m'n website(s), en toon een waarschuwing als iemand _geen_ adblocker gebruikt.
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
2. Alles uit, opslaan.Hey, wij serveren cookies!
1. Accepteren
2. Voorkeuren aanpassen
Hey, we zien dat je geen marketingcookies wil. Die zijn noodzakelijk voor ons voortbestaan. Accepteer ze alsnog, sluit een abo af, of be gone motherfucker.
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.
De "voorkeuren aanpassen" zijn dan meestal zo onoverzichtelijk en ontiegelijk ingewikkeld om doorheen te worstelen, dat de meeste mensen opgeven en op "accepteren" klikken. (Dark Patterns FTW, niet illegaal, dus doen!).oisyn schreef op woensdag 20 september 2023 @ 13:04:
Ik merk dat de no-cookie-detection de nieuwe adblock-detection is.
[...]
2. Alles uit, opslaan.
[...]
Ik gebruik meestal de Consent-O-Matic Firefox extensie, die dat redelijk aardig allemaal voor me doet achter de schermen.
[ Voor 4% gewijzigd door Firesphere op 20-09-2023 13:17 ]
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Het komt wel voor dat je soms een gigantische lijst ziet aan opties die je allemaal uit moet schakelen, maar dat is imho maar zelden. En dan over het algemeen op een site waar ik toch al niet per se hoef te zijn en ben ik er alleen maar op gekomen door een google search. Dan maar op naar het volgende zoekresultaat
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.
Dat komt toch ook weer door de wetgeving? Die stelt immers dat het opt-in moet zijn. Vervolgens in de keuzelijst alles standaard aan zetten lijkt mij daar nog steeds tegenin gaan? Ja, als gebruiker moet je nog steeds expliciet akkoord gaan, maar met een initieel scherm met "aanpassen of akkoord" lijkt het mij lastig te verantwoorden dat bij "aanpassen" nog steeds alles standaard aan staat en het wel voldoet aan "opt-in". Immers moet je als eindgebruiker dan nog steeds meer als alleen "Opslaan" doen om er vanaf te komen. Daar waar "opt-in" bij mij zou impliceren dat je net zo veel of meer handelingen moet doen "om het te krijgen" en niet "veel meer (alles uitvinken) om er vanaf tr komen"..oisyn schreef op woensdag 20 september 2023 @ 13:31:
@Firesphere Op zich merk ik dat de meeste sites toch standaard alles uit hebben staan bij het doen van aanpassingen, dus dan is het een kwestie van "aanpassen" en dan "opslaan" en klaar.
Niet gebruiken is volgens mij een valide keuze hoor.ThomasG schreef op woensdag 20 september 2023 @ 13:43:
Het vervelendste blijft toch dat je een keuze moet maken, of je kunt de website niet gebruiken. Ik wil geen keuze maken of ergens op klikken, ik wil alleen het stukje tekst lezen waar ik voor kwam. Daarna ben ik weer weg. Ze kunnen ook, zoals veel websites wél doen, een klein melding scherm onderaan plaatsen. En als je niets doet, geen tracking cookies.
Ik heb vaker dat bepaalde zoekresultaten sites tonen die "supergeoptimaliseerd" zijn qua SEO, maar ook zo'n vervelende cookieconsent hebben met dark-patterns. Dan ga ik weg en bezoek ik wel een andere site, die wellicht minder geoptimaliseerd is maar ook 't juiste antwoord heeft.
Het gebeurd mij zelden dat zo'n anti-pattern site unieke informatie bevat die nergens anders te vinden is op 't internet.
Einstein: Mijn vrouw begrijpt me niet
Dat klopt. Maar zulk soort websites komen helaas wel steeds vaker en steeds hoger in de resultaten terug. Hetzelfde geldt trouwens voor medium.com. Dat zie ik steeds vaker terug in de resultaten. Het heeft dan wel geen cookie melding, maar ze schrijven allemaal SEO artikeltjes over problemen waar ze geen oplossing voor geven, en je een account moet maken om het überhaupt te kunnen lezen. Die sla ik dus over, maar daardoor worden wel alle nuttige websites ver omlaag gedrukt in de zoek resultaten.DaFeliX schreef op donderdag 21 september 2023 @ 08:37:
[...]
Niet gebruiken is volgens mij een valide keuze hoor.
Ik heb vaker dat bepaalde zoekresultaten sites tonen die "supergeoptimaliseerd" zijn qua SEO, maar ook zo'n vervelende cookieconsent hebben met dark-patterns. Dan ga ik weg en bezoek ik wel een andere site, die wellicht minder geoptimaliseerd is maar ook 't juiste antwoord heeft.
Het gebeurd mij zelden dat zo'n anti-pattern site unieke informatie bevat die nergens anders te vinden is op 't internet.
Dat is juist het moment dat testen belangrijk zijn, hierdoor weet je wat er is veranderd en ja tuurlijk moet je de testen dan ook refactoren, maar je hebt wel een mooie maatstaaf of de code nog stabiel is.armageddon_2k1 schreef op donderdag 14 september 2023 @ 19:57:
[...]
En dan moet je een refactor doen vanwege een upgrade van een third party package waardoor je alle elementen van je software raakt…..
En dan moet je alles gaan testen. Met het handje.
Dit is als of je geen airback in de auto wilt omdat er mogelijk over vijf jaar een ander model wielen onder de auto komen.
STOP making fun of different programming languages
— Tom (@tom_antok) 23 september 2023
C is FAST
HTML is POPULAR
Go is COOL
Python is BEAUTIFUL
PHP
JavaScript is AWESOME
React is SMART
Rust is INTRIGUING
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.
Ajajajaj...
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Dat is exact mijn puntKriekel schreef op vrijdag 22 september 2023 @ 11:57:
[...]
Dat is juist het moment dat testen belangrijk zijn, hierdoor weet je wat er is veranderd en ja tuurlijk moet je de testen dan ook refactoren, maar je hebt wel een mooie maatstaaf of de code nog stabiel is.
Dit is als of je geen airback in de auto wilt omdat er mogelijk over vijf jaar een ander model wielen onder de auto komen.
Engineering is like Tetris. Succes disappears and errors accumulate.
But what about Perl?
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Ik voel me oud. Maar wellicht snap ik het gewoon helemaal niet. Maar wat ik nu gezien heb…. Ik voel me alsof ik weer scriptkiddies php scriptjes in 2007 met jQuery erbij zie maken.
Engineering is like Tetris. Succes disappears and errors accumulate.
Zo te zien is het ook gewoon een rebranding van een library die als sinds 2013 meegaatarmageddon_2k1 schreef op vrijdag 29 september 2023 @ 22:45:
De web wereld is wel echt een wereld apart. Nu is opeens HTMX de nieuwste hype. En ik begin me heel erg oud te voelen. Snippets aan HTML dynamisch inladen via een HTML API. Je leest het goed…. Een HTML API. Wat nou separation of concerns. Wat nou scheiden van data en presentatie.
Ik voel me oud. Maar wellicht snap ik het gewoon helemaal niet. Maar wat ik nu gezien heb…. Ik voel me alsof ik weer scriptkiddies php scriptjes in 2007 met jQuery erbij zie maken.
Op mijn vorige project zat een front end team die op een gegeven moment op het idee kwamen om... drum roll... server side html te genereren want dat was makkelijker dan met React server-side generated json client-side te renderen. Dit lijkt me een beetje in die trend passen.armageddon_2k1 schreef op vrijdag 29 september 2023 @ 22:45:
De web wereld is wel echt een wereld apart. Nu is opeens HTMX de nieuwste hype. En ik begin me heel erg oud te voelen. Snippets aan HTML dynamisch inladen via een HTML API. Je leest het goed…. Een HTML API. Wat nou separation of concerns. Wat nou scheiden van data en presentatie.
Ik voel me oud. Maar wellicht snap ik het gewoon helemaal niet. Maar wat ik nu gezien heb…. Ik voel me alsof ik weer scriptkiddies php scriptjes in 2007 met jQuery erbij zie maken.
Mooi, dan kunnen we namens het front end team dus ook de ontbreken regel over PHP invullen van een paar posts hier bovenKalentum schreef op zaterdag 30 september 2023 @ 11:33:
[...]
Op mijn vorige project zat een front end team die op een gegeven moment op het idee kwamen om... drum roll... server side html te genereren want dat was makkelijker dan met React server-side generated json client-side te renderen. Dit lijkt me een beetje in die trend passen.
90's PHP is kut weer helemaal de toekomst.
Dat server-side renderen moet natuurlijk wel met nodejsgekkie schreef op zaterdag 30 september 2023 @ 11:44:
[...]
Mooi, dan kunnen we namens het front end team dus ook de ontbreken regel over PHP invullen van een paar posts hier boven.
90's PHP is kut weer helemaal de toekomst.
Ahhh de frontend dames en heren willen fullstackKalentum schreef op zaterdag 30 september 2023 @ 11:45:
[...]
Dat server-side renderen moet natuurlijk wel met nodejs
https://laravel-livewire.com/
Geen waardeoordeel over de werkwijze, alleen de bevestiging dat er inderdaad weer steeds meer teruggevallen wordt op SSR.
If money talks then I'm a mime
If time is money then I'm out of time
Ik moet ondertussen alleen maar denken aan de partial updates van ASP.Net AJAX. Ook zo'n geweldig idee. Al zal de uitvoering deze keer vast beter zijn.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ik gebruik zelf Turbo in Rails (ja van de controverses van DHH).Matis schreef op zaterdag 30 september 2023 @ 15:04:
Laravel Livewire werkt exact op die manier. De backend rendert bij een wijziging in de front-end een nieuw stuk HTML en stuurt dat terug en de DOM wordt daarmee (deels) overschreven.
https://laravel-livewire.com/
Geen waardeoordeel over de werkwijze, alleen de bevestiging dat er inderdaad weer steeds meer teruggevallen wordt op SSR.
Livewire werkt exact hetzelfde ja
Oh je bedoelt vanillaJSCaelorum schreef op zaterdag 30 september 2023 @ 10:36:
Maar nu ineens hip is als een soort anti-framework movement. Uiteraard gaat dit door die populariteit ook uitgroeien tot een framework, maar hé. We moeten wel het wiel opnieuw blijven uitvinden hé!
http://vanilla-js.com/
Mijn favoriete framework!
Wel, dit basicaly hetzelfde als mensen die bv geen prepared SQL statements gebruiken om [vage reden]Mugwump schreef op zaterdag 30 september 2023 @ 18:32:
Ik doe echt vrijwel geen frontend meer en dit soort discussies bevestigen weer dat dat een prima keuze is geweest.
Ik zit vooral in de systemen die heel veel real-time data verwerken. Relationele database probeer ik ook te vermijden.RagingPenguin schreef op zondag 1 oktober 2023 @ 11:39:
[...]
Wel, dit basicaly hetzelfde als mensen die bv geen prepared SQL statements gebruiken om [vage reden]Idiots are everywhere
Het is en fantastisch concept hoor, maar als je b.v. met iets als DynamoDB hebt gewerkt, dan is het echt een crime om weer terug te moeten naar b.v. Postgres.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Waar zit dat hem dan in? Want wij hebben b.v. Postgres en ik kom er over het algemeen achter dat mensen gewoon veel te weinig weten van Postgres of SQL in het algemeen en dan maar naar een andere techniek hoppen. Daar beticht ik jou niet van hoor. Maar wij hebben een tijdje een Postgres expert gehad en dan sta je wel te kijken hoe enorm efficient je dat ding kan laten draaien. Honderden miljoenen records is absoluut geen enkel probleem om daar snel goed resultaat uit te kunnen halen.Mugwump schreef op zondag 1 oktober 2023 @ 12:05:
[...]
Ik zit vooral in de systemen die heel veel real-time data verwerken. Relationele database probeer ik ook te vermijden.
Het is en fantastisch concept hoor, maar als je b.v. met iets als DynamoDB hebt gewerkt, dan is het echt een crime om weer terug te moeten naar b.v. Postgres.
Realtime data is wss wel wat andere koek, maar ook daar hebben wij best veel succes gehad met dingen als CDC en Debezium.
Maar Postgres is ook gewoon extreem makkelijk als Dockertje op te spinnen voor lokaal dev. Iets wat me met Dynamo wat lastiger lijkt? EDIT: Nope: https://hub.docker.com/r/amazon/dynamodb-local
Nice.
Lijkt me sterk dat je voor sterk relationele data je gaat zitten kutten met een key-value database? Moet eerlijk bekennen weinig ervaring met Dynamo te hebben hoor.
EDIT:
https://docs.aws.amazon.c...-relational-modeling.html
Wel een lekkere stroman en kort door de bocht. Ook in RDBMS ga je een schema maken op basis van je business problems en access patterns.NoSQL design requires a different mindset than RDBMS design. For an RDBMS, you can create a normalized data model without thinking about access patterns. You can then extend it later when new questions and query requirements arise. By contrast, in Amazon DynamoDB, you shouldn't start designing your schema until you know the questions that it needs to answer. Understanding the business problems and the application use cases up front is absolutely essential.
De crux met dit soort dingen is: De business problemen die je op dit moment implementeert, zijn niet de business problemen over 3, 5, 10 jaar en de business weet ook vaak hun eigen problemen niet de beschrijven en dus moet je kunnen schakelen (hey?... Agile?). Daarom is het kennen van de business problems en use cases _up front_ een totale illusie. De vraag is hoe NoSQL daar dan mee om kan gaan.
[ Voor 39% gewijzigd door armageddon_2k1 op 01-10-2023 15:29 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
Zeer kort door de bocht. Ik ben een enorme fan van DynamoDB, ook single table design met tientallen miljoenen records maar kies gewoon de juiste DB voor de juiste taak en soms is dat DynamoDB, soms is dat PostgreSQL en soms is dat Elastic/Opensearch.Mugwump schreef op zondag 1 oktober 2023 @ 12:05:
Ik zit vooral in de systemen die heel veel real-time data verwerken. Relationele database probeer ik ook te vermijden.
Het is en fantastisch concept hoor, maar als je b.v. met iets als DynamoDB hebt gewerkt, dan is het echt een crime om weer terug te moeten naar b.v. Postgres.
Engineering is like Tetris. Succes disappears and errors accumulate.
Lijkt mij wel ja, sowieso voor PostgreSQL en MSSQL, maar het aantal records is daar ook niet persé leidend in. Het gaat bij grotere aantallen ook om de juiste indexes, fragmentatie, etc. Als je verkeerde indexes hebt, een enorme fragmentatie en je voert geen onderhoud uit kan ook een enterprise grade db systeem met sterke hardware erop onderuit gaan. Maar wat @Cartman! ook zegt: het is vooral belangrijk het juiste systeem te kiezen voor de taak die uitgevoerd moet worden.armageddon_2k1 schreef op zondag 1 oktober 2023 @ 16:14:
Maar tientallen miljoenen records moet toch peanuts zijn voor elke DB?
Ja het is een korte post en zoals ik zeg is er helemaal niets mis met postgres, integendeel. Soms is het zelfs noodzakelijk omdat je er gewoon heel veel meer mee kunt. Het is enorm veelzijdig.Cartman! schreef op zondag 1 oktober 2023 @ 16:01:
[...]
Zeer kort door de bocht. Ik ben een enorme fan van DynamoDB, ook single table design met tientallen miljoenen records maar kies gewoon de juiste DB voor de juiste taak en soms is dat DynamoDB, soms is dat PostgreSQL en soms is dat Elastic/Opensearch.
Waar het hem er voor mij in zit is dat postgres op grote schaal echt verre van triviaal is. Als je over zeer grote volumes data praat komt er heel veel tweaken en tunen aan te pas. Als je Dynamo goed inzet dan heb je op dat vlak echt nul werk.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Maar dat is meer een rigth-tool-for-the-job afweging. Ik doelde meer op mensen die bewust tegen elke best practices ingaan om redenen die eigenlijk gewoon neerkomen op "ik ben 20 jaar geleden gestopt met leren".Mugwump schreef op zondag 1 oktober 2023 @ 12:05:
[...]
Ik zit vooral in de systemen die heel veel real-time data verwerken. Relationele database probeer ik ook te vermijden.
Het is en fantastisch concept hoor, maar als je b.v. met iets als DynamoDB hebt gewerkt, dan is het echt een crime om weer terug te moeten naar b.v. Postgres.
Absoluut, maar mijn stelling was ook helemaal niet dat Dynamo een volwaardige vervanger voor een relationele database is. Mijn stelling is dat het een crime is om terug te moeten vallen op Postgres databases met vele terabytes aan data omdat onderhoud en performanceoptimalisatie zo veel meer werk, maar met name ook kennis vereisen. Maar de reden dat ik dat zei was natuurlijk omdat ik zelf ook met situaties zit waarbij de zoekpatronen het best passen op een relationeel model.Cartman! schreef op zondag 1 oktober 2023 @ 19:55:
Daarnaast vind t juist een verademing om soms Postgres te kunnen gebruiken omdat het type query niet haalbaar is in een enkele query in DynamoDB.
"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 zondag 1 oktober 2023 @ 17:48:
[...]
Ja het is een korte post en zoals ik zeg is er helemaal niets mis met postgres, integendeel. Soms is het zelfs noodzakelijk omdat je er gewoon heel veel meer mee kunt. Het is enorm veelzijdig.
Waar het hem er voor mij in zit is dat postgres op grote schaal echt verre van triviaal is. Als je over zeer grote volumes data praat komt er heel veel tweaken en tunen aan te pas. Als je Dynamo goed inzet dan heb je op dat vlak echt nul werk.
Always looking for developers wanting to work with Erlang.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Het is grappig, maar ik ben nog steeds geen fan van zulke states. De server weet wat er op de client gebeurt. Er is een persistente verbinding nodig. Server weg (stel je voor dat je een gecachete pagina bekijkt op je offline mobiele browser) = site weg, tenzij je daar extra rekening mee houdt.
[ Voor 4% gewijzigd door CodeCaster op 02-10-2023 10:59 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Dat is tegenwoordig sowieso al met alles zo! Wij kunnen op het werk niet eens kopieëren of koffie halen als het internet eruit ligt, want allemaal SaaS en dan kan het de medewerker-pas niet verifiërenCodeCaster schreef op maandag 2 oktober 2023 @ 10:58:
Het is grappig, maar ik ben nog steeds geen fan van zulke states. De server weet wat er op de client gebeurt. Er is een persistente verbinding nodig. Server weg (stel je voor dat je een gecachete pagina bekijkt op je offline mobiele browser) = site weg, tenzij je daar extra rekening mee houdt.

En wat ik tegenwoordig ook steeds vaker hoor op het station: "Door een storing kan er op de stations niet gepind worden. Bij een aantal kaart automaten kan (nog) met contact geld betaald worden"
Edit: Je kunt dit trouwens oplossen door de web-server gewoon mee te sturen naar de client als WASM
https://github.com/nlepage/go-wasm-http-server
[ Voor 9% gewijzigd door ThomasG op 02-10-2023 11:25 ]
Dynamo Streams is gewoon CDC en Postgres CDC gebruikt de WAL waardoor performance hit nihil is
Engineering is like Tetris. Succes disappears and errors accumulate.
https://github.com/seanmorris/php-wasm
Engineering is like Tetris. Succes disappears and errors accumulate.
Gewoon een kwestie van de juiste tool voor de job te kiezen.Mugwump schreef op zondag 1 oktober 2023 @ 12:05:
[...]
Ik zit vooral in de systemen die heel veel real-time data verwerken. Relationele database probeer ik ook te vermijden.
Het is en fantastisch concept hoor, maar als je b.v. met iets als DynamoDB hebt gewerkt, dan is het echt een crime om weer terug te moeten naar b.v. Postgres.
Relationele data ? RDBMS
schemaless data ? NoSql
Append only data (sensor uitlezingen, logs) ? Timeseries Database.
Heb van die laatste er momenteel eentje draaien met 67 miljard records.
https://fgheysels.github.io/
Ik snap je verhaal hier niet zo goed. htmx heeft een volstrekt andere approach dan WebForms, en hoewel Blazor een modus heeft die op WebForms lijkt (Blazor Server Apps) is het in beginsel een methode om .NET in de browser (dus client side) te laden en te draaien.CodeCaster schreef op maandag 2 oktober 2023 @ 10:58:
Turbo/Livewire/htmx/Blazor: het is gewoon allemaal WebForms all over again. De initiële html wordt wat uitgebreid met events en anchors, een user-event wordt serverside afgehandeld en geeft een nieuw, gedeeltelijk stuk html terug en updatet de pagina zonder volledige reload.
Het is grappig, maar ik ben nog steeds geen fan van zulke states. De server weet wat er op de client gebeurt. Er is een persistente verbinding nodig. Server weg (stel je voor dat je een gecachete pagina bekijkt op je offline mobiele browser) = site weg, tenzij je daar extra rekening mee houdt.
Juist met 'moderne' SPAs loop ik permanent tegen het probleem aan dat een persistente verbinding nodig is. Want ja, de pagina laadt wel, maar de 230 json requests op de achtergrond werken niet meer. Een 'domme' html + htmx approach heeft daar juist géén last van.
Waarom daar ophouden? Waarom niet gewoon een hele webserver in de browser. Cut out the middle man!armageddon_2k1 schreef op maandag 2 oktober 2023 @ 18:10:
PHP runtime in the browser:
https://github.com/seanmorris/php-wasm
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.
1 tool to rule them allwhoami schreef op maandag 2 oktober 2023 @ 20:11:
[...]
Gewoon een kwestie van de juiste tool voor de job te kiezen.
Relationele data ? RDBMS
schemaless data ? NoSql
Append only data (sensor uitlezingen, logs) ? Timeseries Database.
Heb van die laatste er momenteel eentje draaien met 67 miljard records.
Relationele data ? PostgreSQL
schemaless data ? PostgreSQL (JSONB)
Append only data (sensor uitlezingen, logs) ? PostgreSQL (TimescaleDB)
Lekker je relationale data joinen met je timeseriedata en je ongestructureerde data.
Het is uiteraard niet letterlijk hetzelfde als WebForms, maar lijkt wel op dat +AJAX. UpdatePanel en zo.ValHallASW schreef op maandag 2 oktober 2023 @ 20:50:
[...]
Ik snap je verhaal hier niet zo goed. htmx heeft een volstrekt andere approach dan WebForms, en hoewel Blazor een modus heeft die op WebForms lijkt (Blazor Server Apps) is het in beginsel een methode om .NET in de browser (dus client side) te laden en te draaien.
Juist met 'moderne' SPAs loop ik permanent tegen het probleem aan dat een persistente verbinding nodig is. Want ja, de pagina laadt wel, maar de 230 json requests op de achtergrond werken niet meer. Een 'domme' html + htmx approach heeft daar juist géén last van.
Stukjes HTML serverside laten renderen door client-side en/of server-side events over een side channel, hetzij een dedicated postback, hetzij een API-call, SSE, websockets, of zelfs hetzelfde endpoint met een extra header, whatever, same difference. Het principe is niets nieuws onder de zon.
Waar ik al een decennium tegen vecht, zijn "rich clients" die met hun JavaScript-updates de history state en daarmee caching en de back-button slopen. Vorige scherm? Wacht, eerst even alles opnieuw ophalen. Het kost extra moeite om dat te laten werken, moeite die gigantisch vaak niet wordt gespendeerd.
Ik zie niet hoe htmx/Turbo/Livewire/... dat gaat oplossen. Het blijven DOM-updates die niet de geschiedenis noch cache in geduwd worden.
Blazor heeft twee modi, en Server zie ik (gelukkig) vaker in het wild gebruikt worden dan de WASM-variant die eer er iets in beeld komt 20 MB aan WASM moet downloaden. Leuk voor een intranet-app, maar als je zoiets op het WWW zet, snap je het niet.
Maar die Blazor Server-variant heeft dus een persistente websocketverbinding nodig. Blader maar eens over ons @Verwijderds https://werkenmet.net/bedrijven. Elke klik doet een vage reconnect, en als een pagina openstaat in je browser en je die tab 29+ uur later opent (al dan niet offline), komt er een waas over het scherm waarin je gemeld wordt dat de verbinding met de server kwijt is.
Dat is niet hoe HTTP en HTML werken, en dat is niet hoe webapps zouden moeten werken.
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Of focus mangement. SPA's doen dat ook niet altijd even goed, maar als je willekeurig hele blokken html gaat vervangen word het nog erger.CodeCaster schreef op maandag 2 oktober 2023 @ 22:24:
[...]
Het is uiteraard niet letterlijk hetzelfde als WebForms, maar lijkt wel op dat +AJAX. UpdatePanel en zo.
Stukjes HTML serverside laten renderen door client-side en/of server-side events over een side channel, hetzij een dedicated postback, hetzij een API-call, SSE, websockets, of zelfs hetzelfde endpoint met een extra header, whatever, same difference. Het principe is niets nieuws onder de zon.
Waar ik al een decennium tegen vecht, zijn "rich clients" die met hun JavaScript-updates de history state en daarmee caching en de back-button slopen. Vorige scherm? Wacht, eerst even alles opnieuw ophalen. Het kost extra moeite om dat te laten werken, moeite die gigantisch vaak niet wordt gespendeerd.
Deze tools bestaan ook helemaal niet om een technisch probleem op te lossen. De enige reden waarom je dit soort dingen gebruikt is als je doel is om een web applicatie wilt maken, maar je developers geen web applicatie willlen/kunnen maken. Dat is een mensen probleem dat je op mensen niveau moet oplossen ipv je in allerlei vreemde bochten te wringen om de meest cursed website te maken.Ik zie niet hoe htmx/Turbo/Livewire/... dat gaat oplossen. Het blijven DOM-updates die niet de geschiedenis noch cache in geduwd worden.
Dan heb je https://github.com/PixelsCommander/HTML-GL nog niet gezienRagingPenguin schreef op dinsdag 3 oktober 2023 @ 11:14:
[...]
*knip* ipv je in allerlei vreemde bochten te wringen om de meest cursed website te maken.
HTML GL solves "the slow DOM problem" by creating WebGL representations of DOM elements and hiding actual DOM after. This speeds up HTML/CSS animations and transformations by using 3D hardware acceleration and allows to apply OpenGL effects as modern 3D games have.
[ Voor 5% gewijzigd door Caelorum op 03-10-2023 16:07 ]
Doe eens niet zo pragmatisch. Als je een probleem hebt in web wereld maak je een nieuw framework ,zo hoort het nou eenmaal.Caelorum schreef op dinsdag 3 oktober 2023 @ 16:03:
Dat kan toch ook door er een transformatie(translateZ 0 ofzo) overheen te halen die niets doet? Dat is iig hoe ik het een paar jaar geleden heb gefixes op een website ergens.
Engineering is like Tetris. Succes disappears and errors accumulate.
Formulieren die on blur de HTML van het formulier vervangen waar je in zit. Als je dan het veld waar de focus heengaat on-the-fly vervangt is de focus weg... Als je velden wisselt met <TAB> zijn deze gewoonweg niet in te vullenRagingPenguin schreef op dinsdag 3 oktober 2023 @ 11:14:
[...]
Of focus mangement. SPA's doen dat ook niet altijd even goed, maar als je willekeurig hele blokken html gaat vervangen word het nog erger.
[...]

Einstein: Mijn vrouw begrijpt me niet
Het FizzBuzzEnterpriseEdition idee zeg maar.armageddon_2k1 schreef op dinsdag 3 oktober 2023 @ 20:17:
[...]
Doe eens niet zo pragmatisch. Als je een probleem hebt in web wereld maak je een nieuw framework ,zo hoort het nou eenmaal.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ik noem geen namen, maar bij grote IT-consultants in Nederland (*kuch* beginnen met een C of S *kuch*) is dit 100% werkelijkheid.Mugwump schreef op woensdag 4 oktober 2023 @ 10:06:
[...]
Het FizzBuzzEnterpriseEdition idee zeg maar.
Ja, ik heb Kevlin Henney hier ooit eens over gehoord op een conferentie en die gaf ook aan dat mensen hem doorgaans vroegen of dit echt was of satire. Want ja, dit soort volstrekte overengineering zie je heel veel.ThomasG schreef op woensdag 4 oktober 2023 @ 10:47:
[...]
Ik noem geen namen, maar bij grote IT-consultants in Nederland (*kuch* beginnen met een C of S *kuch*) is dit 100% werkelijkheid.
Aan de andere kant zie ik ook heel veel underengineering helaas. Patronen en structuren kunnen wel degelijk houvast bieden. Vaak genoeg kilometers betekenisloze code moeten doorspitten en ergens proberen te achterhalen wat het doet.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Tegen de tijd dat je dat allemaal hebt opgezet is je sollicitatie-uurtje al voorbijMugwump schreef op woensdag 4 oktober 2023 @ 10:06:
[...]
Het FizzBuzzEnterpriseEdition idee zeg maar.
Maar of een kortere oplossing altijd beter is...
1
| for(let i=1;i<101;i++){console.log(`${(!(i%3)?'Fizz':'')}${(!(i%5)?'Buzz':'')}`||i);} |
(Al is dit meer iets voor [alg] Slechtste programmeervoorbeelden deel 5 natuurlijk
Dat is natuurlijk geen production-ready code, want moeilijk leesbaar en slechte maintanability. Gelukkig heeft ChatGPT mij geholpen met een over-engineered variant van dezelfde code. Dit is wel production ready!Oon schreef op woensdag 4 oktober 2023 @ 12:59:
[...]
Tegen de tijd dat je dat allemaal hebt opgezet is je sollicitatie-uurtje al voorbij![]()
Maar of een kortere oplossing altijd beter is...
JavaScript:
1 for(let i=1;i<101;i++){console.log(`${(!(i%3)?'Fizz':'')}${(!(i%5)?'Buzz':'')}`||i);}
(Al is dit meer iets voor [alg] Slechtste programmeervoorbeelden deel 5 natuurlijk)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
| class FizzStrategy { apply(number) { return number % 3 === 0 ? 'Fizz' : ''; } } class BuzzStrategy { apply(number) { return number % 5 === 0 ? 'Buzz' : ''; } } class DefaultStrategy { apply(number) { return number; } } class FizzBuzzFactory { createStrategy(strategyType) { switch (strategyType) { case 'Fizz': return new FizzStrategy(); case 'Buzz': return new BuzzStrategy(); default: return new DefaultStrategy(); } } } class FizzBuzzMachine { constructor(start, end, fizzBuzzFactory) { this.start = start; this.end = end; this.fizzBuzzFactory = fizzBuzzFactory; this.validateInputs(); } validateInputs() { if (!Number.isInteger(this.start) || !Number.isInteger(this.end)) { throw new Error("Invalid inputs: Start and end must be integers."); } if (this.start < 1 || this.end < 1) { throw new Error("Invalid inputs: Start and end must be greater than or equal to 1."); } if (this.start > this.end) { throw new Error("Invalid inputs: Start must be less than or equal to end."); } } run() { const fizzBuzzFactory = this.fizzBuzzFactory || new FizzBuzzFactory(); for (let i = this.start; i <= this.end; i++) { const fizzStrategy = fizzBuzzFactory.createStrategy('Fizz'); const buzzStrategy = fizzBuzzFactory.createStrategy('Buzz'); const output = fizzStrategy.apply(i) + buzzStrategy.apply(i) || i; this.logOutput(i, output); } } logOutput(input, output) { console.log(`Input: ${input} => Output: ${output}`); } } try { const fizzBuzzFactory = new FizzBuzzFactory(); const fizzBuzzMachine = new FizzBuzzMachine(1, 100, fizzBuzzFactory); fizzBuzzMachine.run(); } catch (error) { console.error(`FizzBuzzMachine error: ${error.message}`); } |
Kijk, daar hebben we nog wat aan, dat is nou proactief meewerken aan verbetervoorstellen!ThomasG schreef op woensdag 4 oktober 2023 @ 13:30:
[...]
Dat is natuurlijk geen production-ready code, want moeilijk leesbaar en slechte maintanability. Gelukkig heeft ChatGPT mij geholpen met een over-engineered variant van dezelfde code. Dit is wel production ready!
JavaScript:
1...
Nu ben ik eigenlijk wel benieuwd door hoeveel interviews van tech bedrijven ChatGPT heen zou komen
Edit: Voor de grap bovenstaande eens aan ChatGPT (3.5) voorgelegd, en die kwam met een nét wat korter antwoord dan ikzelf
1
| for(let i=1;i<=100;i++)console.log(`${i%3?'':'Fizz'}${i%5?'':'Buzz'}${(i%3&&i%5)?i:''}`); |
Ik mag de JSFuck versie van Tweakers niet delen:
/f/image/UZZGPWWNgqIKe0UaLXlNXZN7.png?f=fotoalbum_large)
https://codepen.io/Clicker8193/pen/MWZPpXg
[ Voor 38% gewijzigd door Oon op 04-10-2023 14:06 ]
Grootste nadeel van Blazor vind ik dat er voor ieder bestaand JS framework een interop library nodig is, als ik dat zie moet ik weer aan COM denken...
Nog groter nadeel is dat al deze library's door de community gemaakt worden, dus is er een nieuwe update van Google Maps, ben je afhankelijk van iemand die dit er als hobby bij doet. https://github.com/vikramlearning/blazorbootstrap zelfde geldt voor bootstrap https://github.com/vikramlearning/blazorbootstrap
Natuurlijk hoef je die libs niet te gebruiken en kan je zelf ook aan de slag maar dan vraag ik me echt af wat de meer waarde is. Ben dan toch meer fan van Nextjs (zelfs als .NET dev
Leest heel simpel composer.lock uit, en laat alle pakketten en versies en metadata in mijn CMS zien. Waarom zie ik dit niet vaker?
En ja, je kan ook zelf kijken in het lock-file, maar het kan ook geen kwaad om dit mooi zichtbaar te hebben als je geen zin hebt om je composer file op te speuren.
/f/image/HqOhsP4IN8dnFMWjB5T5fbs3.png?f=fotoalbum_large)
[ Voor 14% gewijzigd door AW_Bos op 04-10-2023 19:10 ]
☎ Telecommunicatie van vroeger
🚅Alles over spoor en treintjes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| import Data.List (transpose) fizzbuzz = zipWith (\i s -> if null s then show i else s) [1..] mergedFizzesAndBuzzes where fizzes = repeatEvery 3 "Fizz" buzzes = repeatEvery 5 "Buzz" repeatEvery k s = cycle (replicate (pred k) [] ++ [s]) mergedFizzesAndBuzzes = (map concat . transpose) [fizzes, buzzes] main = let n = 100 in mapM_ putStrLn (take n fizzbuzz) |
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
1
2
3
4
5
6
7
8
9
10
11
| let fizzbuzz n = match n % 3, n % 5 with | 0, 0 -> "FizzBuzz" | 0, _ -> "Fizz" | _, 0 -> "Buzz" | _, _ -> string n Seq.initInfinite ((+) 1) |> Seq.take 100 |> Seq.map fizzbuzz |> Seq.iter (printfn "%s") |
(Edit: met seq toch altijd net wat netter, maar minder leesbaar)
[ Voor 20% gewijzigd door Caelorum op 04-10-2023 19:58 ]
Je kan in Haskell ook gewoon normaal doen hoorCaelorum schreef op woensdag 4 oktober 2023 @ 19:56:
Ahja de slechter leesbare versie van f#
F#:
1 2 3 4 5 6 7 8 9 10 11 let fizzbuzz n = match n % 3, n % 5 with | 0, 0 -> "FizzBuzz" | 0, _ -> "Fizz" | _, 0 -> "Buzz" | _, _ -> string n Seq.initInfinite ((+) 1) |> Seq.take 100 |> Seq.map fizzbuzz |> Seq.iter (printfn "%s")
(Edit: met seq toch altijd net wat netter, maar minder leesbaar)
1
2
3
4
5
6
7
8
| fizzbuzz :: Integer -> String fizzbuzz n = case (n `mod` 3, n `mod` 5) of (0, 0) -> "FizzBuzz" (0, _) -> "Fizz" (_, 0) -> "Buzz" (_, _) -> show n main = mapM_ putStrLn $ map fizzbuzz [1..100] |
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.