De Devschuur Coffee Corner - Iteratie ⑬

[Koenvh]

Ik ben nu in de wereld van de labelprinters en beletteringssystemen aan het duiken (want ik heb te vaak dat ik ergens een label voor kan gebruiken). Wat ik me afvroeg: zijn labelprinters net zo erg als normale printers?

O, en wie vindt ABC ipv QWERTY een handige opmaak?

[ Voor 11% gewijzigd door Koenvh op 27-07-2022 20:09 ]

[azerty]

Mschamp schreef op woensdag 27 juli 2022 @ 19:47:
[...]


***members only***

Hallo, medewerker aan hetzelfde bedrijf

[ShitHappens]

Koenvh schreef op woensdag 27 juli 2022 @ 20:07:
Ik ben nu in de wereld van de labelprinters en beletteringssystemen aan het duiken (want ik heb te vaak dat ik ergens een label voor kan gebruiken). Wat ik me afvroeg: zijn labelprinters net zo erg als normale printers?

O, en wie vindt ABC ipv QWERTY een handige opmaak?

Volgens mij doe ik al 14 jaar met zowel m'n Brother labelprinter (of eigenlijk, beletteringssysteem, van dat tape dus) en laserprinter. Dat icm username zegt genoeg?

Maar zonder gekkigheid, ik heb dat ding ooit voor een paar tientjes gehaald, heeft altijd probleemloos gewerkt en de tapes zijn nog steeds te krijgen.
Het ligt dus maar heel erg aan je eigen ervaring met normale printers

[mcDavid]

Koenvh schreef op woensdag 27 juli 2022 @ 20:07:
Ik ben nu in de wereld van de labelprinters en beletteringssystemen aan het duiken (want ik heb te vaak dat ik ergens een label voor kan gebruiken). Wat ik me afvroeg: zijn labelprinters net zo erg als normale printers?

O, en wie vindt ABC ipv QWERTY een handige opmaak?

Ligt eraan wat je koopt. Brother is inmiddels berucht vanwege de DRM op label cardriges.

[Neverwinterx]

PdeBie schreef op maandag 25 juli 2022 @ 11:55:
Wauw. Lang geleden dat ik er een tegenkwam, maar daar was weer zo'n irritante scraping website hoor!

https://stackoverflow.com...k-completedtask-vs-return
VS
https://programmerall.com/article/27052259626/

Wel amusante timing dat op moment van schrijven stackoverflow eruit ligt, maar de scraping website wel bereikbaar is.

[Koenvh]

mcDavid schreef op donderdag 28 juli 2022 @ 13:12:
[...]


Ligt eraan wat je koopt. Brother is inmiddels berucht vanwege de DRM op label cardriges.

Bestaat dat ook al?

[Mschamp]

azerty schreef op woensdag 27 juli 2022 @ 20:08:
[...]


Hallo, medewerker aan hetzelfde bedrijf

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[.oisyn]

Matt Parker's inefficient Python script: 30 days.
Some guy's solution using graph theory: 22 minutes.
.oisyn's solution: 7 seconds.

[DaFeliX]

.oisyn schreef op donderdag 4 augustus 2022 @ 20:14:
[...]
.oisyn's solution: 7 seconds.

is dat inclusief installeren van alle SDK's en compilen?

[CurlyMo]

@.oisyn samenvattend is de uitdaging dus om vijf 5 letter woorden te vinden uit het Engelse woordenboek waarbij geen letters dubbel mogen voorkomen?

[Oon]

Koenvh schreef op woensdag 27 juli 2022 @ 20:07:
Ik ben nu in de wereld van de labelprinters en beletteringssystemen aan het duiken (want ik heb te vaak dat ik ergens een label voor kan gebruiken). Wat ik me afvroeg: zijn labelprinters net zo erg als normale printers?

O, en wie vindt ABC ipv QWERTY een handige opmaak?

Was je hier al aan uitgekomen?

Ik heb zelf een Dymo 450 (al zeker 10 jaar) voor verzendlabels, labels zelf koop ik bij de welbekende driecijferige knockoff webshop. Voor van die smalle labels gebruik ik de handheld Dymo 160, daar zaten twee cartridges bij en ik heb er in een jaar of 2 tijd één opgemaakt door alles in mijn huis te labelen.

Ben zelf nog op zoek naar een apparaat om van die metalen labeltjes te maken die echt een letter in het plaatje knijpen ipv alleen tekst printen, die beginnen bij een veel lagere prijs voor een handmatige maar ik ben er nog niet helemaal aan uit. Ben dus wel benieuwd waar jij precies naar zocht en waar je evt. op uit bent gekomen

Maar om het nog enigszins on-topic te houden: dat zijn ze absoluut. Een handheld labelprinter is altijd gezeik met die cartridges want er zit dan zo'n bandje in dat precies goed door het apparaat moet lopen. Die ik heb heeft ook twee laagjes in de cartridge; een voor de tekst en een voor de achterkant ofzo. Heb 'm een keer laten vallen en toen was de cartridge gewoon kapot, omdat die twee bandjes niet meer aan elkaar zaten en niet meer tegelijk afgerold werden, dus dan probeerde hij wel te printen maar kwam de achterkant niet mee en kon je dus je label niet afknippen.

De USB-variant is gewoon een normale printer volgens je PC, in theorie kun je vanuit Word dus gewoon een printopdracht sturen als je het juiste papierformaat toevoegt. Maar printen vanuit een browser is bijvoorbeeld weer niet zomaar mogelijk omdat je daar die papierformaten niet hebt.
Er was een tijdje dat je vanaf de website van PostNL direct een label kon printen maar dat is ook niet meer zo, in ieder geval niet met die lijn Dymo printers.

Heb nog geen toepassing voor mijn label printers kunnen vinden binnen softwareontwikkeling helaas.

[Vihaio]

CurlyMo schreef op vrijdag 5 augustus 2022 @ 08:49:
@.oisyn samenvattend is de uitdaging dus om vijf 5 letter woorden te vinden uit het Engelse woordenboek waarbij geen letters dubbel mogen voorkomen?

Ik ben niet .oisyn, maar: Ja, dat is de uitdaging.

En daarbij wordt dit gebruikt als woordenboek (En vervolgens alle woorden die Wordle gebruikt, waardoor je imo beter meteen die lijst kan gebruiken)

[ Voor 26% gewijzigd door Vihaio op 05-08-2022 09:13 ]

[Caelorum]

De lijst staat sowieso niet vast. Hij heeft alleen die lijst gebruikt, omdat hij die al had. En de crosscheck tegen wordle lijst omdat die ook makkelijk te verkrijgen is. Maar als jij de complete oxford woordenboekwoordenlijst hebt in een handig te parsen format mag je die best gebruiken.

[Oon]

Caelorum schreef op vrijdag 5 augustus 2022 @ 09:18:
De lijst staat sowieso niet vast. Hij heeft alleen die lijst gebruikt, omdat hij die al had. En de crosscheck tegen wordle lijst omdat die ook makkelijk te verkrijgen is. Maar als jij de complete oxford woordenboekwoordenlijst hebt in een handig te parsen format mag je die best gebruiken.

Die van de OLD staan gewoon op https://www.oxfordlearnersdictionaries.com/wordlist/ en de Oxford University verkoopt blijkbaar zelf de lijst van de OED: https://languages.oup.com/products/oxford-wordlists/ (al staat er niet expliciet bij dat het de OED is, alleen Oxford).

De OED heeft overigens 'maar' 273k woorden, terwijl de Amerikaanse Webster al op 470k zit, en wiktionanry.org op 578k. Ik weet niet of dat het probleem moeilijker of makkelijker maakt, maar ik zou dan neigen naar de open-source optie waar je de grootste kans hebt om ook de minder gangbare woorden tegen te komen

[armageddon_2k1]

En nu unicode support inbouwen.

[Caelorum]

Oon schreef op vrijdag 5 augustus 2022 @ 10:14:
[...]
De OED heeft overigens 'maar' 273k woorden, terwijl de Amerikaanse Webster al op 470k zit, en wiktionanry.org op 578k. Ik weet niet of dat het probleem moeilijker of makkelijker maakt, maar ik zou dan neigen naar de open-source optie waar je de grootste kans hebt om ook de minder gangbare woorden tegen te komen

Het probleem was juist dat die grote sets veel afkortingen bevatten als echte woorden, terwijl ze dat niet zijn. Dus je moet wel goed de set van tevoren checken (of de gevonden paren achteraf).

[.oisyn]

Caelorum schreef op vrijdag 5 augustus 2022 @ 09:18:
De lijst staat sowieso niet vast.

Dat klopt, maar als je de perf van implementaties wil vergelijken dan is het natuurlijk wel handig dat iedereen dezelfde dataset gebruikt

[dcm360]

Zo te zien in de comments onder de youtube-video zijn er genoeg kijkers die redelijk vlotte oplossingen weten te bedenken. Tijdens het kijken van de video had ik al het vermoeden dat het probleem niet zo complex zou zijn, en ik heb zelf in een half uurtje een vrij naïeve oplossing in elkaar gezet die een oplossing geeft in minder dan 90 seconden. Met een leuk verhaaltje (en een hint voor een efficiënte oplosrichting) erbij zou het nog wel in de Advent of Code kunnen passen ook.

[Josk79]

.oisyn schreef op donderdag 4 augustus 2022 @ 20:14:
[YouTube: Can you find: five five-letter words with twenty-five unique letters?]

Matt Parker's inefficient Python script: 30 days.
Some guy's solution using graph theory: 22 minutes.
.oisyn's solution: 7 seconds.

Josk79's solution in C#: 8 seconds

[Caelorum]

Het valt me eigenlijk wel tegen dan @.oisyn niet Rust heeft gebruikt...

[.oisyn]

Caelorum schreef op vrijdag 5 augustus 2022 @ 19:56:
Het valt me eigenlijk wel tegen dan @.oisyn niet Rust heeft gebruikt...

Ben nog steeds niet zo proficient in Rust dat ik dat zo even uit mijn mouw schud. Dit heb ik ook maar in een uurtje ingetypt

Het is al heel wat dat ik de boel op github heb gezet

[ Voor 8% gewijzigd door .oisyn op 05-08-2022 20:58 ]

[Koenvh]

Oon schreef op vrijdag 5 augustus 2022 @ 08:57:
[...]

Was je hier al aan uitgekomen?

Ik heb zelf een Dymo 450 (al zeker 10 jaar) voor verzendlabels, labels zelf koop ik bij de welbekende driecijferige knockoff webshop. Voor van die smalle labels gebruik ik de handheld Dymo 160, daar zaten twee cartridges bij en ik heb er in een jaar of 2 tijd één opgemaakt door alles in mijn huis te labelen.

Ben zelf nog op zoek naar een apparaat om van die metalen labeltjes te maken die echt een letter in het plaatje knijpen ipv alleen tekst printen, die beginnen bij een veel lagere prijs voor een handmatige maar ik ben er nog niet helemaal aan uit. Ben dus wel benieuwd waar jij precies naar zocht en waar je evt. op uit bent gekomen

Maar om het nog enigszins on-topic te houden: dat zijn ze absoluut. Een handheld labelprinter is altijd gezeik met die cartridges want er zit dan zo'n bandje in dat precies goed door het apparaat moet lopen. Die ik heb heeft ook twee laagjes in de cartridge; een voor de tekst en een voor de achterkant ofzo. Heb 'm een keer laten vallen en toen was de cartridge gewoon kapot, omdat die twee bandjes niet meer aan elkaar zaten en niet meer tegelijk afgerold werden, dus dan probeerde hij wel te printen maar kwam de achterkant niet mee en kon je dus je label niet afknippen.

De USB-variant is gewoon een normale printer volgens je PC, in theorie kun je vanuit Word dus gewoon een printopdracht sturen als je het juiste papierformaat toevoegt. Maar printen vanuit een browser is bijvoorbeeld weer niet zomaar mogelijk omdat je daar die papierformaten niet hebt.
Er was een tijdje dat je vanaf de website van PostNL direct een label kon printen maar dat is ook niet meer zo, in ieder geval niet met die lijn Dymo printers.

Heb nog geen toepassing voor mijn label printers kunnen vinden binnen softwareontwikkeling helaas.

Ik heb geen tijd meer gehad om zelf op onderzoek uit te gaan, maar de ervaringen zijn vaak eerder negatief dan positief lijkt het.

[Oon]

Koenvh schreef op vrijdag 5 augustus 2022 @ 21:46:
[...]

Ik heb geen tijd meer gehad om zelf op onderzoek uit te gaan, maar de ervaringen zijn vaak eerder negatief dan positief lijkt het.

Het blijven printers, de enige vorm die nog enigszins betrouwbaar is is de 'embossing' label makers, want dat is gewoon een draaischijf om een enkele letter te selecteren en dan klem je die letter op het metalen plaatje.

Voor de digitale 'gewone' label printers zit er ook wel echt heel veel verschil in betrouwbaarheid per merk. Als je weg blijft van rotzooi als Leitz met hun DRM cartridges en slimme labelprinters met wifi die nooit werken, en weg blijft van de goedkopere Brothers e.d. dan zit je al redelijk goed. Mijn Dymo 450 heeft mij nog nooit in de steek gelaten, alleen de software is ruk maar dat went wel.

[Vihaio]

Josk79 schreef op vrijdag 5 augustus 2022 @ 19:54:
[...]


Josk79's solution in C#: 8 seconds

Pics repo or it didn't happen

[Josk79]

@Vihaio hier een gistje: https://gist.github.com/s...c1249ad875566bb7845136142

[.oisyn]

Josk79 schreef op vrijdag 5 augustus 2022 @ 19:54:
[...]


Josk79's solution in C#: 8 seconds

.oisyn's solution na sorteren op letter frequentie: 0,138388s
.edit: sorry, dat is 0,077205s nadat ik alle nutteloze verbose prints eruit heb gehaald, die nu niet meer verwaarloosbaar zijn

[ Voor 22% gewijzigd door .oisyn op 06-08-2022 03:31 ]

[KabouterSuper]

.oisyn schreef op donderdag 4 augustus 2022 @ 20:14:
[YouTube: Can you find: five five-letter words with twenty-five unique letters?]

Matt Parker's inefficient Python script: 30 days.
Some guy's solution using graph theory: 22 minutes.
.oisyn's solution: 7 seconds.

Mooi gedaan. Ik verbaas me wel over de frequentie van de letters (qxjz...nuroisea van laag naar hoog). In de cryptografie (kraken van geëncrypte berichten) zie ik vaak etaoins.... of eariotns.... gebruikt worden, zie bijv Wikipedia: Letter frequency. Blijkbaar zijn 5-letter woorden niet helemaal typisch qua letter frequentie. Of zijn de frequenties ongeveer hetzelfde?

[Josk79]

@.oisyn Zo zo, zeer netjes! Ik heb zelf ook nog 3 optimalisaties in gedachten (1. resultaatbuffer predifinieren in plaats van yield gebruiken, 2. sorteren op letterfrequentie, net als jij en 3. een 'jumpmap', wordt vervolgd...), ik hoop dat ik er dit weekend tijd en zin voor heb om toe te passen. Maar jouw snelheid zal ik niet gaan redden met mijn methode, verwacht ik.

Edit:
Na optimalisatie 1 duurt het nu 4,7 sec. Het wordt wel een memory-hog als ik dan bijv. laat zoeken naar combinaties van zes 4-letterwoorden...

[ Voor 19% gewijzigd door Josk79 op 07-08-2022 14:15 ]

[.oisyn]

Total time: 22968us (0.022968s)
Read:       11923us
Process:    10604us
Write:        441us

Custom file reads (33ms -> 12ms) en AVX2 optimalisaties (43ms -> 10ms)
Voor AVX2 heb ik maar even gebranched: https://github.com/oisyn/parkerwords/tree/sse

.edit: en nu met meerdere threads

Total time: 14272us (0.014272s)
Read:       11537us
Process:     2358us
Write:        377us

(de non-AVX2 komt hiermee op ongeveer 22ms)

[ Voor 45% gewijzigd door .oisyn op 08-08-2022 02:51 ]

[.oisyn]

AVX2 word processing en async file reads, al denk ik dat de AVX optimize daarmee ook meteen zinloos is geworden. Een file read van de complete file kost 7,5ms op mijn machine, daar kan ik weinig aan doen. Dus dan maar zoveel mogelijk werk verzetten terwijl we op reads zitten te wachten

Total time: 10379us (0.010379s)
Read:        8008us
Process:     2000us
Write:        371us

Wel jammer, vond het juist zo'n mooie vonst om met SIMD op zoek te gaan naar newlines in een string

.edit: wacht, en terwijl ik dit typ bedenk ik me opeens dat ik helemaal geen \r\n combinatie tegenkom op mijn windows machine, alleen maar \n. En verrek, ik open de file als tekst. Alle \r\n's worden dus omgezet naar \n door std, maar dat hoeft voor mijn algo helemaal niet

En idd, de file openen als binary:

Total time: 6761us (0.006761s)
Read:        4305us
Process:     2041us
Write:        415us

Fuck yeah onder de 10ms

[ Voor 42% gewijzigd door .oisyn op 08-08-2022 18:30 ]

[Caelorum]

Kunnen we iig vaststellen dat @.oisyn zich niet verveeld in de nacht en vroege ochtend.

[Dido]

Voor sommigen is een enkele AoC per jaar net wat te weinig, lijkt het wel

[Gropah]

Dido schreef op dinsdag 9 augustus 2022 @ 08:49:
Voor sommigen is een enkele AoC per jaar net wat te weinig, lijkt het wel

Wellicht word er daarom ook gekeken bij mijn werk of we zo iets kunnen op zetten voor vlak voor het vakantieseizoen

[Dido]

Gropah schreef op dinsdag 9 augustus 2022 @ 09:47:
Wellicht word er daarom ook gekeken bij mijn werk of we zo iets kunnen op zetten voor vlak voor het vakantieseizoen

Je hebt het verhaal van Eric Wastl wel eens gehoord/gezien wat betreft de hoeveelheid tijd, resources en mankracht die hij daarin stopt?
Hij is het hele jaar bezig om die ene maand 50 opdrachten klaar te hebben staan

[Gropah]

Dido schreef op dinsdag 9 augustus 2022 @ 09:55:
[...]

Je hebt het verhaal van Eric Wastl wel eens gehoord/gezien wat betreft de hoeveelheid tijd, resources en mankracht die hij daarin stopt?
Hij is het hele jaar bezig om die ene maand 50 opdrachten klaar te hebben staan

Ik heb dat wel eens gelezen, en ik heb er enorm veel ontzag voor. Maar bij ons zou het sowieso in afgeslankte vorm zijn, met minder verhaal en zonder doorlopende opdrachten. Beetje meer a la crash & compile, iets korter en lichter om ook nog een beetje leuk naast je werk te kunnen doen. Ik heb al een aantal C&Cs opgezet en gerund (en daar kan ik waarschijnlijk ook wel wat problemen van rehashen), dus dat moet goed komen

[ Voor 11% gewijzigd door Gropah op 09-08-2022 10:42 ]

[CodeCaster]

Na ruim een decennium .NET heb ik een jaartje geleden PHP weer eens opgepakt, en met namespaces, static code analyzers, generics/templates (soit, via comments, maar het werkt icm die analyers), lambda's en volwassen frameworks lijkt het tegenwoordig echt wel ergens op.

Maar waarom. In Godesnaam. Is nog steeds alles. Van voor tot achter. STRINGS EN ARRAYS.

Overal. In elk framework. In elke API-client. Alle libraries. Alles. Is. Strings. En. Arrays.

Download een library om tegen het webshopplatform Shopify te praten. Kijk naar de documentie van het orders-endpoint. Wat gaat er in de GET-call? Een string-array, en twee strings. Wat komt eruit? Een array. Met daarin. String-arrays. Wat zit er in $response[0]["line_items"][0]? NOG MEER STRING ARRAYS. Wat zegt de library-documentatie over de inhoud van die arrays? "Zie de Shopify-documentatie".

Mijn $deity.

Genereer klassen uit die API, en vul de klassen met de data uit die JSON. Het is 2022, ja. De taal PHP mag dan een soort van objectgeoriënteerd zijn (laat ik niet beginnen over abstracte klassen die een interface mogen implementeren zonder declaratie van functies uit die interface, of static methodes in interfaces en het plezier dat dat oplevert), maar de developers houden nog steeds halsstarrig vast aan de praktijken van 1999.

Tijd voor een pilletje.

[ Voor 21% gewijzigd door CodeCaster op 09-08-2022 12:07 ]

[RayNbow]

CodeCaster schreef op dinsdag 9 augustus 2022 @ 11:57:
Maar waarom. In Godesnaam. Is nog steeds alles. Van voor tot achter. STRINGS EN ARRAYS.

Stringly typed

[ThomasG]

CodeCaster schreef op dinsdag 9 augustus 2022 @ 11:57:
Na ruim een decennium .NET heb ik een jaartje geleden PHP weer eens opgepakt, en met namespaces, static code analyzers, generics/templates (soit, via comments, maar het werkt icm die analyers), lambda's en volwassen frameworks lijkt het tegenwoordig echt wel ergens op.

Maar waarom. In Godesnaam. Is nog steeds alles. Van voor tot achter. STRINGS EN ARRAYS.

Overal. In elk framework. In elke API-client. Alle libraries. Alles. Is. Strings. En. Arrays.

Download een library om tegen het webshopplatform Shopify te praten. Kijk naar de documentie van het orders-endpoint. Wat gaat er in de GET-call? Een string-array, en twee strings. Wat komt eruit? Een array. Met daarin. String-arrays. Wat zit er in $response[0]["line_items"][0]? NOG MEER STRING ARRAYS. Wat zegt de library-documentatie over de inhoud van die arrays? "Zie de Shopify-documentatie".

Mijn $deity.

Genereer klassen uit die API, en vul de klassen met de data uit die JSON. Het is 2022, ja. De taal PHP mag dan een soort van objectgeoriënteerd zijn (laat ik niet beginnen over abstracte klassen die een interface mogen implementeren zonder declaratie van functies uit die interface, of static methodes in interfaces en het plezier dat dat oplevert), maar de developers houden nog steeds halsstarrig vast aan de praktijken van 1999.

Tijd voor een pilletje.

De Shopify API ondersteund GraphQL. Klinkt dus als een gevalletje slechte library

[CodeCaster]

ThomasG schreef op dinsdag 9 augustus 2022 @ 12:37:
[...]
De Shopify API ondersteund GraphQL. Klinkt dus als een gevalletje slechte library

Ja want dat is de heilige graal en daar komen lekkere typed objects uit.

Order->FulfillmentOrder->Fulfillment->FU query te diep

Of API v202109 heeft geen nodes of edges waar v202204 die wel heeft, dus kun je je halve query herschrijven (of gewoon niet uitvoeren tegen GraphQL). En dan nog, je moet de GraphQL-query als string schrijven, en krijgt weer string arrays terug.

[ Voor 26% gewijzigd door CodeCaster op 09-08-2022 12:58 ]

[Koenvh]

CodeCaster schreef op dinsdag 9 augustus 2022 @ 11:57:
Na ruim een decennium .NET heb ik een jaartje geleden PHP weer eens opgepakt, en met namespaces, static code analyzers, generics/templates (soit, via comments, maar het werkt icm die analyers), lambda's en volwassen frameworks lijkt het tegenwoordig echt wel ergens op.

Maar waarom. In Godesnaam. Is nog steeds alles. Van voor tot achter. STRINGS EN ARRAYS.

Overal. In elk framework. In elke API-client. Alle libraries. Alles. Is. Strings. En. Arrays.

Download een library om tegen het webshopplatform Shopify te praten. Kijk naar de documentie van het orders-endpoint. Wat gaat er in de GET-call? Een string-array, en twee strings. Wat komt eruit? Een array. Met daarin. String-arrays. Wat zit er in $response[0]["line_items"][0]? NOG MEER STRING ARRAYS. Wat zegt de library-documentatie over de inhoud van die arrays? "Zie de Shopify-documentatie".

Mijn $deity.

Genereer klassen uit die API, en vul de klassen met de data uit die JSON. Het is 2022, ja. De taal PHP mag dan een soort van objectgeoriënteerd zijn (laat ik niet beginnen over abstracte klassen die een interface mogen implementeren zonder declaratie van functies uit die interface, of static methodes in interfaces en het plezier dat dat oplevert), maar de developers houden nog steeds halsstarrig vast aan de praktijken van 1999.

Tijd voor een pilletje.

Je kunt er dus geen touw aan vastknopen?

Ik begrijp je ergernis wel. PHP is raar wat strings nou eigenlijk zijn (reeksen van bytes zijn bijvoorbeeld ook strings). Al moet ik wel zeggen dat ik het wel fijn vind dat het kán, in plaats van dat ik eerst voor alles wat in de JSON kan staan eerst een model moet maken, want da's vooral als je één waarde zoekt in een brij aan nested JSON echt een stuk makkelijker.

* Koenvh heeft nog nachtmerries van de structuur van Actions on Google

[.oisyn]

.oisyn schreef op maandag 8 augustus 2022 @ 18:24:
AVX2 word processing en async file reads, al denk ik dat de AVX optimize daarmee ook meteen zinloos is geworden. Een file read van de complete file kost 7,5ms op mijn machine, daar kan ik weinig aan doen. Dus dan maar zoveel mogelijk werk verzetten terwijl we op reads zitten te wachten

Total time: 10379us (0.010379s)
Read:        8008us
Process:     2000us
Write:        371us

Wel jammer, vond het juist zo'n mooie vonst om met SIMD op zoek te gaan naar newlines in een string

.edit: wacht, en terwijl ik dit typ bedenk ik me opeens dat ik helemaal geen \r\n combinatie tegenkom op mijn windows machine, alleen maar \n. En verrek, ik open de file als tekst. Alle \r\n's worden dus omgezet naar \n door std, maar dat hoeft voor mijn algo helemaal niet

En idd, de file openen als binary:

Total time: 6761us (0.006761s)
Read:        4305us
Process:     2041us
Write:        415us

Fuck yeah onder de 10ms

Iemand heeft alle implementaties gerund op zijn eigen machine en getimed.

Here is a google sheet summarizing the implementations I could find. Your latest version, @oisyn, and another submission by @dwmal1 is still missing but I hope I can add them laterhttps://t.co/a8fFWf2A9h

— Benjamin Paassen @EDM2024 (@bpaassen1) 9 augustus 2022

Matt Parker heeft een follow-up video gefilmd die volgende week gereleased wordt

Heads up everyone: I've just filmed the follow-up video! We can keep updating the table @bpaassen1 is working on, but (unless there is a breakthrough worthy of Future Matt filming an update) I'll not be able to add anything significant. Video should take about a week to release.

— Matt Parker (@standupmaths) 9 augustus 2022

Raad eens wie de snelste tijd heeft

[DevWouter]

.oisyn schreef op woensdag 10 augustus 2022 @ 11:56:
Raad eens wie de snelste tijd heeft

Gefeliciteerd met je 20 seconden van roem... of is het 0.010379 seconden?

[farlane]

.oisyn schreef op woensdag 10 augustus 2022 @ 11:56:
[...]
Raad eens wie de snelste tijd heeft

Saillant detail, de runner up is (maar) 7ms langzamer, gebruikt dezelfde algoritmes, niet geparallelliseerd en is geschreven in ..... uhuh

[.oisyn]

farlane schreef op woensdag 10 augustus 2022 @ 22:40:
[...]


Saillant detail, de runner up is (maar) 7ms langzamer, gebruikt dezelfde algoritmes, niet geparallelliseerd en is geschreven in ..... uhuh

Saillant detail is dat dat de entry is van miniBill, die *mijn* algo heeft geport naar Rust en daarbij gebruik maakt van Rayon, een parallellisatie-api

[farlane]

.oisyn schreef op woensdag 10 augustus 2022 @ 23:52:
[...]

Saillant detail is dat dat de entry is van miniBill, die *mijn* algo heeft geport naar Rust en daarbij gebruik maakt van Rayon, een parallellisatie-api

Beetje wel .
Was wel benieuwd hoe die Rust versie dan in een geparallelliseerde versie zou performen maar blijkbaar is 'ie dat al.

[Sandor_Clegane]

CodeCaster schreef op dinsdag 9 augustus 2022 @ 11:57:
Na ruim een decennium .NET heb ik een jaartje geleden PHP weer eens opgepakt, en met namespaces, static code analyzers, generics/templates (soit, via comments, maar het werkt icm die analyers), lambda's en volwassen frameworks lijkt het tegenwoordig echt wel ergens op.

Maar waarom. In Godesnaam. Is nog steeds alles. Van voor tot achter. STRINGS EN ARRAYS.

Overal. In elk framework. In elke API-client. Alle libraries. Alles. Is. Strings. En. Arrays.

Download een library om tegen het webshopplatform Shopify te praten. Kijk naar de documentie van het orders-endpoint. Wat gaat er in de GET-call? Een string-array, en twee strings. Wat komt eruit? Een array. Met daarin. String-arrays. Wat zit er in $response[0]["line_items"][0]? NOG MEER STRING ARRAYS. Wat zegt de library-documentatie over de inhoud van die arrays? "Zie de Shopify-documentatie".

Mijn $deity.

Genereer klassen uit die API, en vul de klassen met de data uit die JSON. Het is 2022, ja. De taal PHP mag dan een soort van objectgeoriënteerd zijn (laat ik niet beginnen over abstracte klassen die een interface mogen implementeren zonder declaratie van functies uit die interface, of static methodes in interfaces en het plezier dat dat oplevert), maar de developers houden nog steeds halsstarrig vast aan de praktijken van 1999.

Tijd voor een pilletje.

Meh, strong typing is leuk maar als je met crappy data, ik noem maar wat: command line output van verschillende OS'en, tot een domein model moet komen is het niet zo gek.

[CodeCaster]

Sandor_Clegane schreef op donderdag 11 augustus 2022 @ 20:36:
[...]


Meh, strong typing is leuk maar als je met crappy data, ik noem maar wat: command line output van verschillende OS'en, tot een domein model moet komen is het niet zo gek.

Als je commandline output moet parsen, heb je een OS dat API's mist. Of tsja, zeg, directorylistings van FTP.

Ik snap dat er uitzonderingen zijn, maar wat ik ondertussen in een jaar ben tegengekomen, tot zo ongeveer alle API's van alle webframeworks, zijn het arrays met strings als keys en strings (of inception, weer arrays) als values.

Doctrine-queries, bijvoorbeeld. Leuk dat je entities hebt, maar DQL is een bak string-magie die runtime pas stukgaat. Ook de expressionbuilder gebruikt uiteindelijk alleen maar strings. Dat je IDE dan autocompletion voorstelt binnen die strings op basis van diens parsing van je entity-klassen is schattig, maar ook niet meer dan dat.

Of, ik noem maar wat, het bouwen van een form-element in Symfony:

PHP:

    public function buildForm(FormBuilderInterface $builder, array $options): void
    {
        $builder
            // ...
            ->add('dueDate', DateType::class, [
                'required' => $options['require_due_date'],
            ])

Welke parameters (naast"required") en options (naast "require_due_date") zijn er nog meer? Geen idee, zie de docs. En als het een onbekende key is, wordt 'ie dan genegeerd of throwt het? Verschilt ook weer per toepassing.

En zoals ik al zei, zo'n beetje alle API-clients werken niet met objecten, terwijl je die tegenwoordig prima kunt genereren uit OpenAPI-specificaties.

Gewoon onbruikbaar, onproductief, onprofessioneel.

[ Voor 6% gewijzigd door CodeCaster op 11-08-2022 20:54 ]

[Sandor_Clegane]

CodeCaster schreef op donderdag 11 augustus 2022 @ 20:53:
[...]

Als je commandline output moet parsen, heb je een OS dat API's mist. Of tsja, zeg, directorylistings van FTP.

Ik snap dat er uitzonderingen zijn, maar wat ik ondertussen in een jaar ben tegengekomen, tot zo ongeveer alle API's van alle webframeworks, zijn het arrays met strings als keys en strings (of inception, weer arrays) als values.

Doctrine-queries, bijvoorbeeld. Leuk dat je entities hebt, maar DQL is een bak string-magie die runtime pas stukgaat. Ook de expressionbuilder gebruikt uiteindelijk alleen maar strings. Dat je IDE dan autocompletion voorstelt binnen die strings op basis van diens parsing van je entity-klassen is schattig, maar ook niet meer dan dat.

Of, ik noem maar wat, het bouwen van een form-element in Symfony:

PHP:

    public function buildForm(FormBuilderInterface $builder, array $options): void
    {
        $builder
            // ...
            ->add('dueDate', DateType::class, [
                'required' => $options['require_due_date'],
            ])

Welke parameters (naast"required") en options (naast "require_due_date") zijn er nog meer? Geen idee, zie de docs. En als het een onbekende key is, wordt 'ie dan genegeerd of throwt het? Verschilt ook weer per toepassing.

En zoals ik al zei, zo'n beetje alle API-clients werken niet met objecten, terwijl je die tegenwoordig prima kunt genereren uit OpenAPI-specificaties.

Gewoon onbruikbaar, onproductief, onprofessioneel.

Ik ga geen ZFS API in C aanspreken. Sorry, mij iets te link. Ach, zeg nooit nooit, maar op het moment is dit gewoon sneller.

Ik snap je punt, maar op een gegeven ben je zoveel aan het transformeren om het allemaal met de juiste types op de juiste plek te krijgen dat een dynamische taal niet eens zo gek is.

Ik ben blij met F#, maar de enorme striktheid qua types maakt het soms een hoop hoepels om doorheen te springen. Voordeel is wel, als je het dan eenmaal in je domain hebt dan werkt alles weer 10 x zo snel.

[DevWouter]

CodeCaster schreef op donderdag 11 augustus 2022 @ 20:53:
Als je commandline output moet parsen, heb je een OS dat API's mist.

Uhm... Netwerk en Wifi configureren via een webapp op DietPi (Debian).
Je hebt zelfs commando's die met opzet JSON uitspugen zodat.

Ik geef toe dat het een uitzonderlijk iets is, maar ik heb zelfs een tijdje gezocht naar apt-packages die iets van een stabiele api introduceren, maar nope, het is config-files overschrijven. En laat nu geen enkele config-file op elkaar lijken

[Sandor_Clegane]

DevWouter schreef op donderdag 11 augustus 2022 @ 21:00:
[...]


Uhm... Netwerk en Wifi configureren via een webapp op DietPi (Debian).
Je hebt zelfs commando's die met opzet JSON uitspugen zodat.

Ik geef toe dat het een uitzonderlijk iets is, maar ik heb zelfs een tijdje gezocht naar apt-packages die iets van een stabiele api introduceren, maar nope, het is config-files overschrijven. En laat nu geen enkele config-file op elkaar lijken

Dit is het precies, plus je hoeft geen client op het OS te installeren. SSH naar de host met keys, juiste sudo config voor bijvoorbeeld de packetfilter en het werkt allemaal redelijk vlotjes.

Probleem is bijvoorbeeld dat route op BSD net iets anders is dan ip route of route op Linux.

[DevWouter]

Sandor_Clegane schreef op donderdag 11 augustus 2022 @ 21:05:
[...]


Dit is het precies, plus je hoeft geen client op het OS te installeren. SSH naar de host met keys, juiste sudo config voor bijvoorbeeld de packetfilter en het werkt allemaal redelijk vlotjes.

Probleem is bijvoorbeeld dat route op BSD net iets anders is dan ip route of route op Linux.

Vooral dat laatste. Als er één ding is dat ik onthouden heb voor linux is dat er heel veel methodes zijn om te configureren en dat alle documentatie/stackoverflow-posts online allemaal er naast zijn. Zo zijn er sommige die van mening zijn dat je altijd je machine moet herstarten bij een configuratie wijziging. Alsof het Windows 95 is

[Sandor_Clegane]

DevWouter schreef op donderdag 11 augustus 2022 @ 21:20:
[...]


Vooral dat laatste. Als er één ding is dat ik onthouden heb voor linux is dat er heel veel methodes zijn om te configureren en dat alle documentatie/stackoverflow-posts online allemaal er naast zijn. Zo zijn er sommige die van mening zijn dat je altijd je machine moet herstarten bij een configuratie wijziging. Alsof het Windows 95 is

Yup. En ik hoef het alleen maar te lezen. (voor het moment dan).

Kwam deze tegen: https://kellyjonbrazil.github.io/jc/

Misschien handig.

[DevWouter]

Sandor_Clegane schreef op donderdag 11 augustus 2022 @ 21:23:
[...]


Yup. En ik hoef het alleen maar te lezen. (voor het moment dan).

Kwam deze tegen: https://kellyjonbrazil.github.io/jc/

Misschien handig.

Bedankt, ik heb hem in de bookmarks gezet. (overigens is ip -j address ook heerlijk[/]


Helaas, mijn applicatie moet lezen en schrijven. Overigens heb ik geen moeite om parsers te schrijven, maar het is vooral uitzoeken wat alle mogelijke resultaten zijn. En dan heb je nog configured-values en running-values die niet perse gelijk hoeven te zijn.

En "faux-parsers" (regex ipv lexers) zijn trouwens heerlijk te schrijven met TDD.

[Sandor_Clegane]

DevWouter schreef op donderdag 11 augustus 2022 @ 21:35:
[...]


Bedankt, ik heb hem in de bookmarks gezet. (overigens is ip -j address ook heerlijk[/]

Klopt, punt is alleen dat je dan weer decoders moet schrijven die verschillen. BSD kent geen ip. Dan is het vaak simpeler om beide gewoon maar op dezelfde manier te doen: text line voor line parsen en dan maar patternmatchen op het resultaat.

Helaas, mijn applicatie moet lezen en schrijven. Overigens heb ik geen moeite om parsers te schrijven, maar het is vooral uitzoeken wat alle mogelijke resultaten zijn. En dan heb je nog configured-values en running-values die niet perse gelijk hoeven te zijn.

En "faux-parsers" (regex ipv lexers) zijn trouwens heerlijk te schrijven met TDD.

TDD? Daar is een REPL voor.

[CodeCaster]

Jullie noemen nu zaken waarvoor PHP bij uitstek geschikt is: scripten. Ik begrijp het ook goed hoor, ook vaak zat bezig geweest met uitzoeken waar de config van iets nu weer staat na een Ubuntu-upgrade en wat de layout van die file is, of waarvandaan hij gesymlinkt of zelfs gegenereerd is.

Mijn grieven zijn dus met het onderhouden van een grotere applicatie in PHP, die moet praten met meerdere externe systemen zoals databases en web-API's.

Als je een API consumeert waarvan een decimaal veld als float-in-string binnenkomt (want een echte float kan afrondingsverschillen hebben en elk kommagetal in PHP is een float), en je wil dat in de database wel als een decimal(18,2) hebben, dan wil ik dat dat ding van begin tot eind met naam en type aan te duiden is. En dat als je een kolom hernoemt, dat je niet alle 57 plekken moet nalopen waar iemand getQueryBuilder() aanroept om zelf met een DQL-string je oude kolom nog te noemen in een query.

Ook projections (partial selects) zijn uit Doctrine verwijderd bij de volgende versie, onder het mom van "het is een ORM, geen DAL, dus je moet en zal de hele entity (dus alle kolommen) queryen".

Wat als ik alleen m'n ordernummer en het totaalbedrag van alle orderregels wil? Dan moet ik een nieuwe klasse maken per query (want alle kolommen uit je query moeten op de klasse zitten en vice versa), of het wordt, surprise surprise, een array waarbij ik met strings moet gaan indexeren, en de aanroepende code dus moet "weten" dat uit $order["totalAmountExVat"] een string komt, met daarin een decimal.

Ik snap de beslissingen in het hele ecosysteem gewoon niet. Gelukkig ben ik verder weer lekker met .NET bezig. Een verademing dat je niet zomaar een int met een string kunt vergelijken Nog steeds jammer dat men een jaar of twintig geleden heeft besloten dat wel alles by default naar string kan.

[ Voor 6% gewijzigd door CodeCaster op 11-08-2022 22:05 ]

[Sandor_Clegane]

CodeCaster schreef op donderdag 11 augustus 2022 @ 22:04:
Jullie noemen nu zaken waarvoor PHP bij uitstek geschikt is: scripten. Ik begrijp het ook goed hoor, ook vaak zat bezig geweest met uitzoeken waar de config van iets nu weer staat na een Ubuntu-upgrade en wat de layout van die file is, of waarvandaan hij gesymlinkt of zelfs gegenereerd is.

Mijn grieven zijn dus met het onderhouden van een grotere applicatie in PHP, die moet praten met meerdere externe systemen zoals databases en web-API's.

Als je een API consumeert waarvan een decimaal veld als float-in-string binnenkomt (want een echte float kan afrondingsverschillen hebben en elk kommagetal in PHP is een float), en je wil dat in de database wel als een decimal(18,2) hebben, dan wil ik dat dat ding van begin tot eind met naam en type aan te duiden is. En dat als je een kolom hernoemt, dat je niet alle 57 plekken moet nalopen waar iemand getQueryBuilder() aanroept om zelf met een DQL-string je oude kolom nog te noemen in een query.

Ook projections (partial selects) zijn uit Doctrine verwijderd bij de volgende versie, onder het mom van "het is een ORM, geen DAL, dus je moet en zal de hele entity (dus alle kolommen) queryen".

Wat als ik alleen m'n ordernummer en het totaalbedrag van alle orderregels wil? Dan moet ik een nieuwe klasse maken per query (want alle kolommen uit je query moeten op de klasse zitten en vice versa), of het wordt, surprise surprise, een array waarbij ik met strings moet gaan indexeren, en de aanroepende code dus moet "weten" dat uit $order["totalAmountExVat"] een string komt, met daarin een decimal.

Ik snap de beslissingen in het hele ecosysteem gewoon niet. Gelukkig ben ik verder weer lekker met .NET bezig. Een verademing dat je niet zomaar een int met een string kunt vergelijken Nog steeds jammer dat men een jaar of twintig geleden heeft besloten dat wel alles by default naar string kan.

Helemaal mee eens hoor, daarom neem ik ook maar de pijn om het wel te transformeren naar records. Punt is dat de records nu ook weer naar readonly structs moeten. Zo ben je weer mooi aan het puzzelen.

Ik heb nog nooit met PHP gewerkt, denk dat ik het ook maar laat.

ToString() is gewoon de type van het object niet? Ik zie daar het probleem niet zo in.

[DevWouter]

CodeCaster schreef op donderdag 11 augustus 2022 @ 22:04:
Jullie noemen nu zaken waarvoor PHP bij uitstek geschikt is: scripten.

C# hier

Overigens kan je met elke taal goed scripten zolang je een system(...) hebt, IO-support en string manipulatie.

[Sandor_Clegane]

DevWouter schreef op donderdag 11 augustus 2022 @ 22:18:
[...]

C# hier

Deels.

[RagingPenguin]

CodeCaster schreef op donderdag 11 augustus 2022 @ 20:53:
[...]

Als je commandline output moet parsen, heb je een OS dat API's mist. Of tsja, zeg, directorylistings van FTP.

Ik snap dat er uitzonderingen zijn, maar wat ik ondertussen in een jaar ben tegengekomen, tot zo ongeveer alle API's van alle webframeworks, zijn het arrays met strings als keys en strings (of inception, weer arrays) als values.

Doctrine-queries, bijvoorbeeld. Leuk dat je entities hebt, maar DQL is een bak string-magie die runtime pas stukgaat. Ook de expressionbuilder gebruikt uiteindelijk alleen maar strings. Dat je IDE dan autocompletion voorstelt binnen die strings op basis van diens parsing van je entity-klassen is schattig, maar ook niet meer dan dat.

Of, ik noem maar wat, het bouwen van een form-element in Symfony:

PHP:

    public function buildForm(FormBuilderInterface $builder, array $options): void
    {
        $builder
            // ...
            ->add('dueDate', DateType::class, [
                'required' => $options['require_due_date'],
            ])

Welke parameters (naast"required") en options (naast "require_due_date") zijn er nog meer? Geen idee, zie de docs. En als het een onbekende key is, wordt 'ie dan genegeerd of throwt het? Verschilt ook weer per toepassing.

En zoals ik al zei, zo'n beetje alle API-clients werken niet met objecten, terwijl je die tegenwoordig prima kunt genereren uit OpenAPI-specificaties.

Gewoon onbruikbaar, onproductief, onprofessioneel.

O god, dit brengt weer allerlei trauma's terug van toen ik wat Drupal deed tijdens een stage. Die community klopt zichzelf vol trots op de borst dat ze het beter doen als WP en OOP met SOLID gebruiken. En sure, ze doen dingen met classes en design patterns maar ze inderdaad ook net als alle andere php-ers niet van magische strings en arrays afblijven.

Kijk, dingen als een EntityStorageInterface en EntityTypeManagerInterface klinken heel professioneel, totdat je het daadwerkelijk gebruikt en code als dit tegen komt:

PHP:

$storage = \Drupal::service('entity_type.manager')->getStorage('node');

$nids = $storage->getQuery()
  ->condition('type', 'article')
  ->condition('status', 1)
  ->execute();

$items= $storage->loadMultiple($nids);

foreach ($items as $item) {
    $value = $item->get('field_contact')->first()->getValue()['target_id'];
}

Wil je een service uit de service container? Dat is een string. Wil je een storage instance voor een entity type? Dat is een string. (en die hebben gewoon een eigen class btw). Wil je een conditie op een query? Dat is een string voor de property en een whatever voor de value. Een field op een node? Een string. De value van een object referentie? Een array van magische array. De inhoud daarvan? Iets met een magische string key. De value van die key? Een whatever, meestal een int. Etc, etc, etc.

En dit is letterlijk het eerste sample voor een join in de Drupal documentatie:

PHP:

// Example of a SELECT query which joins the {node} table to both the {node_field_data} and {users} tables.
$query = $connection->select('node', 'n', $options);
$query->join('node_field_data', 'nfd', 'n.nid = nfd.nid AND nfd.status = :status', array(':status' => 1));
$table_alias = $query->join('users', 'u', 'n.uid = u.uid AND u.uid = :uid', array(':uid' => 5));

Dat is minder leesbaar dan gewone SQL:

SQL:

SELECT * 
FROM node
JOIN node_field_data nfd ON n.nid = nfd.nid
JOIN users u ON n.uid = u.uid
WHERE nfd.status = :status AND u.uid = :uid

En er komt verder toch geen typed object uitrollen...

[ Voor 3% gewijzigd door RagingPenguin op 11-08-2022 22:36 ]

[RobertMe]

RagingPenguin schreef op donderdag 11 augustus 2022 @ 22:31:
[...]


O god, dit brengt weer allerlei trauma's terug van toen ik wat Drupal deed tijdens een stage. Die community klopt zichzelf vol trots op de borst dat ze het beter doen als WP en OOP met SOLID gebruiken. En sure, ze doen dingen met classes en design patterns maar ze inderdaad ook net als alle andere php-ers niet van magische strings en arrays afblijven.

Kijk, dingen als een EntityStorageInterface en EntityTypeManagerInterface klinken heel professioneel, totdat je het daadwerkelijk gebruikt en code als dit tegen komt:

PHP:

$storage = \Drupal::service('entity_type.manager')->getStorage('node');

$nids = $storage->getQuery()
  ->condition('type', 'article')
  ->condition('status', 1)
  ->execute();

$items= $storage->loadMultiple($nids);

foreach ($items as $item) {
    $value = $item->get('field_contact')->first()->getValue()['target_id'];
}

Wil je een service uit de service container? Dat is een string. Wil je een storage instance voor een entity type? Dat is een string. (en die hebben gewoon een eigen class btw). Wil je een conditie op een query? Dat is een string voor de property en een whatever voor de value. Een field op een node? Een string. De value van een object referentie? Een array van magische array. De inhoud daarvan? Iets met een magische string key. De value van die key? Een whatever, meestal een int. Etc, etc, etc.

En dit is letterlijk het eerste sample voor een join in de Drupal documentatie:

PHP:

// Example of a SELECT query which joins the {node} table to both the {node_field_data} and {users} tables.
$query = $connection->select('node', 'n', $options);
$query->join('node_field_data', 'nfd', 'n.nid = nfd.nid AND nfd.status = :status', array(':status' => 1));
$table_alias = $query->join('users', 'u', 'n.uid = u.uid AND u.uid = :uid', array(':uid' => 5));

Dat is minder leesbaar dan gewone SQL:

SQL:

SELECT * 
FROM node
JOIN node_field_data nfd ON n.nid = nfd.nid
JOIN users u ON n.uid = u.uid
WHERE nfd.status = :status AND u.uid = :uid

En er komt verder toch geen typed object uitrollen...

Klinkt alsof je beter Drupal 6 kunt gebruiken

PHP:

$result = db_query("SELECT * FROM foo WHERE bar = '%s'", $bar);
while ($row = db_fetch_array($result)) {
  ...
}

Verder niks aantrekken van het feit dat de "placeholders" nogal crappy zijn, NULL niet ondersteund wordt, je bij strings zelf de quotes moet plaatsen (ja echt ).

[DevWouter]

Over strings en data gesproken. Ik vind dit nog het mooiste van Typescript.
En dit is nog simpel. Ik heb ook complete "static typed" json parsers gezien.

JavaScript:

type RouteData = PathArgs<"/company/:companyId/customer/:customerId/vendor-user/:vendorUserId">;
                                                //        .
                                                //       /|\
var routeData: RouteData = {                    //        |
    companyId: "",// <-- Strong typed based on URL        |
    customerId: "",// <-- Strong typed based on URL       |
    vendorUserId: "", // <-- Strong typed based on URL    |
};


// The magic 
type PathParams<Path extends string> =
    Path extends `:${infer Param}/${infer Rest}` ? Param | PathParams<Rest> :
    Path extends `:${infer Param}` ? Param :
    Path extends `${infer _Prefix}:${infer Rest}` ? PathParams<`:${Rest}`> :
    never;

type PathArgs<Path extends string> = {
    [K in PathParams<Path>]: string
};

[Janoz]

Ach, in php zijn String niet eens String, of hebben ze ondertussen al de mb_* meuk al kunnen integreren?

[Sandor_Clegane]

DevWouter schreef op donderdag 11 augustus 2022 @ 23:59:
Over strings en data gesproken. Ik vind dit nog het mooiste van Typescript.
En dit is nog simpel. Ik heb ook complete "static typed" json parsers gezien.

JavaScript:

type RouteData = PathArgs<"/company/:companyId/customer/:customerId/vendor-user/:vendorUserId">;
                                                //        .
                                                //       /|\
var routeData: RouteData = {                    //        |
    companyId: "",// <-- Strong typed based on URL        |
    customerId: "",// <-- Strong typed based on URL       |
    vendorUserId: "", // <-- Strong typed based on URL    |
};


// The magic 
type PathParams<Path extends string> =
    Path extends `:${infer Param}/${infer Rest}` ? Param | PathParams<Rest> :
    Path extends `:${infer Param}` ? Param :
    Path extends `${infer _Prefix}:${infer Rest}` ? PathParams<`:${Rest}`> :
    never;

type PathArgs<Path extends string> = {
    [K in PathParams<Path>]: string
};

Typescipt heb ik nog nooit mee gewerkt. Voor Json gebruik ik Thoth: https://thoth-org.github.io/Thoth.Json/

code:

let fsLinuxDecoder : Decoder<Harddrive> =
    Decode.object (
        fun get ->
        {
            Harddrive.FileSystem = get.Required.Field "filesystem" Decode.string
            Harddrive.Size = get.Required.Field "size" Decode.string
            Harddrive.Used = get.Required.Field "used" Decode.int64
            Harddrive.Mounted = get.Required.Field "mounted_on" Decode.string
            Harddrive.Available = get.Required.Field "available" Decode.int64
            Harddrive.Percent = get.Required.Field "use_percent" Decode.int

        }
    )

Werkt wel mooi, alleen soms wel een gepriegel. Type providers zijn helemaal magisch.

[OMX2000]

DevWouter schreef op donderdag 11 augustus 2022 @ 23:59:
Over strings en data gesproken. Ik vind dit nog het mooiste van Typescript.
En dit is nog simpel. Ik heb ook complete "static typed" json parsers gezien.

JavaScript:

type RouteData = PathArgs<"/company/:companyId/customer/:customerId/vendor-user/:vendorUserId">;
                                                //        .
                                                //       /|\
var routeData: RouteData = {                    //        |
    companyId: "",// <-- Strong typed based on URL        |
    customerId: "",// <-- Strong typed based on URL       |
    vendorUserId: "", // <-- Strong typed based on URL    |
};


// The magic 
type PathParams<Path extends string> =
    Path extends `:${infer Param}/${infer Rest}` ? Param | PathParams<Rest> :
    Path extends `:${infer Param}` ? Param :
    Path extends `${infer _Prefix}:${infer Rest}` ? PathParams<`:${Rest}`> :
    never;

type PathArgs<Path extends string> = {
    [K in PathParams<Path>]: string
};

Impressive! Ik denk dat ik nogal achterloop qua syntax/features van Typescript. En ik had dit nooit zelf verzonnen.

[Koenvh]

Aaaaaah!
https://www.postnl.nl/ver...rzamelen/nl-crypto-stamp/

[gekkie]

Wil ik weten hoeveel cent van de laatste verhoging van den postzegels gespendeerd is om dit hieperdepieper project in elkaar te vlooien ?

[Koenvh]

gekkie schreef op woensdag 17 augustus 2022 @ 17:53:
Wil ik weten hoeveel cent van de laatste verhoging van den postzegels gespendeerd is om dit hieperdepieper project in elkaar te vlooien ?

Die cryptozegels kosten €9,05 per stuk geloof ik.

[RagingPenguin]

gekkie schreef op woensdag 17 augustus 2022 @ 17:53:
Wil ik weten hoeveel cent van de laatste verhoging van den postzegels gespendeerd is om dit hieperdepieper project in elkaar te vlooien ?

Nope

[Sandor_Clegane]

Koenvh schreef op woensdag 17 augustus 2022 @ 17:35:
Aaaaaah!
https://www.postnl.nl/ver...rzamelen/nl-crypto-stamp/

Het is ook te triest voor woorden. "Crypto chasers"........

Mooi op tijd ook, de kliek heeft net een nosedive gemaakt. Eigenlijk ook net goed.

[gekkie]

Koenvh schreef op woensdag 17 augustus 2022 @ 18:33:
[...]

Die cryptozegels kosten €9,05 per stuk geloof ik.

Maar dat zal wel voorgefinancierd zijn met de prijsstelling van mijn gelegenheid tot het likken van het achterwerk van de leden van ons koninklijk huis.

Maar voor €9,05 heb ik dan dus een "bewijs" dat ik ooit een postzegel gekocht heb, vrij prijzige kwitantie.
En dan moet het idee zijn dat mijn kwitantie in de toekomst veel geld waard gaat worden ofzo ?

Dat mevrouw Herna Verhagen er nou eerst eens voor gaat zorgen dat die bezorgers niet meer zelf aftekenen voor bezorging en tegelijkertijd het pakketje niet bij je afleveren. Heb ik wat meer aan als ze dat na al die jaren dat ik het aan haar gevraagd heb eindelijk eens fixt.

[ Voor 44% gewijzigd door gekkie op 17-08-2022 20:24 ]

[Koenvh]

Sandor_Clegane schreef op woensdag 17 augustus 2022 @ 18:36:
[...]


Het is ook te triest voor woorden. "Crypto chasers"........

Mooi op tijd ook, de kliek heeft net een nosedive gemaakt. Eigenlijk ook net goed.

Crypto chaser klinkt als een heel smerig drankje

[Sandor_Clegane]

Koenvh schreef op woensdag 17 augustus 2022 @ 22:06:
[...]

Crypto chaser klinkt als een heel smerig drankje

Waar je dan een fatsoenlijke, andere, chaser voor nodig hebt om de smaak uit je muil te krijgen.

[gekkie]

Tijd voor Buffy the Crypto slayer

[Koenvh]

Ik wilde gisteren met Cloudflare Pages experimenteren, maar hun buildopties zijn verrassend slecht gedocumenteerd (als je niet een van de standaard raamwerken gebruikt). Wat ik wilde doen was eigenlijk vrij simpel: LaTeX omzetten naar een PDF, van die PDF weer SVGs maken (als thumbnails), en dat samen met wat HTML en CSS online zetten. Met GitHub Actions is dat vrij makkelijk (ook het naar Cloudflare Pages publiceren), maar met de build options van Cloudflare Pages zelf was het verrassend lastig. Ook draait hun build systeem op Ubuntu Xenial (16.04) en mag je niets als root doen, dus dat helpt ook niet mee.

Het draait nu wel via GitHub Actions, maar ik had toch liever de pipeline puur bij Cloudflare gehad.

[farlane]

gekkie schreef op woensdag 17 augustus 2022 @ 20:20:
[...]
Dat mevrouw Herna Verhagen er nou eerst eens voor gaat zorgen dat die bezorgers niet meer zelf aftekenen voor bezorging en tegelijkertijd het pakketje niet bij je afleveren. Heb ik wat meer aan als ze dat na al die jaren dat ik het aan haar gevraagd heb eindelijk eens fixt.

Dan moet ze die mensen beter gaan betalen en kwaliteit belangrijker maken dan kwantiteit.

[phex]

CodeCaster schreef op donderdag 11 augustus 2022 @ 22:04:


Als je een API consumeert waarvan een decimaal veld als float-in-string binnenkomt (want een echte float kan afrondingsverschillen hebben en elk kommagetal in PHP is een float), en je wil dat in de database wel als een decimal(18,2) hebben, dan wil ik dat dat ding van begin tot eind met naam en type aan te duiden is. En dat als je een kolom hernoemt, dat je niet alle 57 plekken moet nalopen waar iemand getQueryBuilder() aanroept om zelf met een DQL-string je oude kolom nog te noemen in een query.

Je kan zelf data types maken in Doctrine.

Echter jouw specifieke voorbeeld van decimal bestaat gewoon al en is een string data type in Doctrine zodat je absolute precisie behoudt.

Elke andere oplossing zal ergens die route ook moeten bewandelen. Dat is gewoon een limitatie van PHP dat er geen decimal type bestaat.

Dus je enige optie is dan die string in een custom object type te wrappen.

CodeCaster schreef op donderdag 11 augustus 2022 @ 22:04:
Ook projections (partial selects) zijn uit Doctrine verwijderd bij de volgende versie, onder het mom van "het is een ORM, geen DAL, dus je moet en zal de hele entity (dus alle kolommen) queryen".

Wat als ik alleen m'n ordernummer en het totaalbedrag van alle orderregels wil? Dan moet ik een nieuwe klasse maken per query (want alle kolommen uit je query moeten op de klasse zitten en vice versa), of het wordt, surprise surprise, een array waarbij ik met strings moet gaan indexeren, en de aanroepende code dus moet "weten" dat uit $order["totalAmountExVat"] een string komt, met daarin een decimal.

Deze wist ik niet maar als je er over nadenkt logisch.

Als een ORM gebruikt, dan mapt deze altijd zijn results naar objecten. Dat is immers exact wat elk ORM doet. Een half object maakt dan niet veel sense, want dan is je object mogelijk niet meer valide.

Maar veel gevaarlijker is als je dit object opnieuw persist dan zal alle niet geselecteerde data uit je database verwijderd worden. Immers als je hetzelfde object zou gebruiken is voor het ORM niet te bepalen dat het maar een partial select was.

Dus dan blijven er 2 mogelijkheden over:

- Een ander object type definiëren.
- DBAL gebruiken IPV ORM. Voordeel van deze route is dat de syntax gelijk is aan ORM en je data type mapping in stand blijft. (Dus is een decimal een string by default)

Maar wat ik even niet snap is wat al deze klachten met API/webservices te maken heeft. Vanuitgande dat het een JSON data structuur is, dan heb je daar toch exact hetzelfde probleem in JSON?

[Caelorum]

phex schreef op vrijdag 19 augustus 2022 @ 04:18:
[...]

Immers als je hetzelfde object zou gebruiken is voor het ORM niet te bepalen dat het maar een partial select was.[...]

Wat extra state bijhouden over een entiteit kan natuurlijk gewoon.

[RobertMe]

Caelorum schreef op vrijdag 19 augustus 2022 @ 05:37:
[...]

Wat extra state bijhouden over een entiteit kan natuurlijk gewoon.

En dat doet Doctrine ook. Want voor de manier waarop die werkt, zijnde "roep flush() aan en alle gewijzigde entities worden opgeslagen" moet die de initiële state al weten. Anders kan die immers niet bepalen welke entities gewijzigd zijn. (Ja ok: via een active record achtige manier wel, maar dat gebruikt Doctrine niet. En van de entity die je queried krijg je in principe ook altijd een instance van de klasse zelf terug, en geen proxy. Een proxy wordt alleen gebruikt voor children die nog moeten autoloaden, en als een proxy instance bestaat voor een entity en je doet een query die die entity oplevert krijg je ook de eerder gemaakte, proxy, instance terug).

[CodeCaster]

phex schreef op vrijdag 19 augustus 2022 @ 04:18:
[...]


Je kan zelf data types maken in Doctrine.

Echter jouw specifieke voorbeeld van decimal bestaat gewoon al en is een string data type in Doctrine zodat je absolute precisie behoudt.

Elke andere oplossing zal ergens die route ook moeten bewandelen. Dat is gewoon een limitatie van PHP dat er geen decimal type bestaat.

Dus je enige optie is dan die string in een custom object type te wrappen.

Het gaat me niet om het type decimal, dat was een voorbeeld. Als je alles op de manier doet zoals veel PHP'ers doen, dan is het ID van de order die je uit een API binnenkrijgt $order["id"] in plaats van $order->id. En de inhoud van dat array-element kan dan een string zijn, of een int, of een fiets, wie zal het weten.

Vervolgens staat er ergens diep in een query-DQL-string "WHERE order_id = :id", in plaats van bijvoorbeeld Linq's .Where(o => o.id == id). En dan wordt het ding ergens aan een form gekoppeld met, je raadt het al, een array van arrays van strings, dus [ "columns" => [ "order_id" => [ "options" => [ ... ] ] ] ].

Het zijn o-ver-al strings. Dat zorgt voor problemen met types en met refactoring.

Deze wist ik niet maar als je er over nadenkt logisch.

Als een ORM gebruikt, dan mapt deze altijd zijn results naar objecten. Dat is immers exact wat elk ORM doet. Een half object maakt dan niet veel sense, want dan is je object mogelijk niet meer valide.

Maar veel gevaarlijker is als je dit object opnieuw persist dan zal alle niet geselecteerde data uit je database verwijderd worden. Immers als je hetzelfde object zou gebruiken is voor het ORM niet te bepalen dat het maar een partial select was.

Dus dan blijven er 2 mogelijkheden over:

- Een ander object type definiëren.
- DBAL gebruiken IPV ORM. Voordeel van deze route is dat de syntax gelijk is aan ORM en je data type mapping in stand blijft. (Dus is een decimal een string by default)

Maar wat ik even niet snap is wat al deze klachten met API/webservices te maken heeft. Vanuitgande dat het een JSON data structuur is, dan heb je daar toch exact hetzelfde probleem in JSON?

Je leest vaker uit een database dan dat je ernaar schrijft, en lezen heeft al snel performanceproblemen als je het over meer dan honderd records en gebruikers hebt en je datalaag niet is gebouwd met performance in het achterhoofd.

De aanname dat je altijd met een heel object werkt, in combinatie met automatische lazy loading van gerelateerde objecten en het feit dat een relationele tabel per definitie nooit plat is maar relaties heeft, zorgt ervoor dat de combinatie van veelgebruikte technieken (Symfony, API Platform, Doctrine) nooit goed kán performen.

Als je een API wil maken die wederom die orders wil exposen met, bijvoorbeeld, een SUM(orderline.quantity), dan gaat die genoemde combinatie van technieken out of the box alle orderregels ophalen per order, en er dan in PHP overheen loopen om de aantallen op te tellen.

Dus dan moet je een custom DataProvider (uit m'n hoofd) schrijven voor API Platform, een custom DTO voor Doctrine (want geen projections), want de aanname van API Platform is dat wat uit je API's komt precies je entities zijn. Dat is om te beginnen al zo'n verschrikkelijk slechte aanname dat ik niet snap dat dat framework zo populair is. Een API-resource is vaak een representatie van een aantal gemapte entities, en zou moeten losstaan van hoe je je data opslaat. Of GraphQL, maar goed.

Einde rant, goedemorgen, koffie?

[Koenvh]

De Oostenrijkse variant staat nu ook online, met een video! https://crypto.post.at/
[Video: https://crypto.post.at/video/Post_Crypto_stamp%204.0_Crawler_1920x1080.mp4]
Straks gaat alle post in de blockchain - stel je het voor, post, maar dan ook digitaal. Een soort e-Post - geniaal!

Ik hoop dat m'n NFT niet in het Suezkanaal vast komt te zitten

[ Voor 11% gewijzigd door Koenvh op 19-08-2022 12:16 ]

[CodeCaster]

Koenvh schreef op vrijdag 19 augustus 2022 @ 12:10:
De Oostenrijkse variant staat nu ook online, met een video! https://crypto.post.at/
[Video]
Straks gaat alle post in de blockchain - stel je het voor, post, maar dan ook digitaal. Een soort e-Post - geniaal!

Ik hoop dat m'n NFT niet in het Suezkanaal vast komt te zitten

Dus er zijn 150.000 "postzegels" uitgebracht, die je voor 9 euro per stuk kunt kopen. Niet dat je ze kunt gebruiken om post te versturen (of krijg je er wel een bruikbare postzegel bij?), maar je hebt dan wel een NFT! En men is ervan overtuigd dat dit een geliefd verzamelobject gaat worden, want fila... Fiatdealers..
filate... postzegelverzamelaars houden van verzamelen!

Kunnen we alsjeblieft stoppen met NFT's?

[Koenvh]

CodeCaster schreef op vrijdag 19 augustus 2022 @ 12:34:
[...]

Dus er zijn 150.000 "postzegels" uitgebracht, die je voor 9 euro per stuk kunt kopen. Niet dat je ze kunt gebruiken om post te versturen (of krijg je er wel een bruikbare postzegel bij?), maar je hebt dan wel een NFT! En men is ervan overtuigd dat dit een geliefd verzamelobject gaat worden, want fila... Fiatdealers..
filate... postzegelverzamelaars houden van verzamelen!

Kunnen we alsjeblieft stoppen met NFT's?

Hoor ik daar jaloezie op m'n vet coole postzegel?

[Sandor_Clegane]

Koenvh schreef op vrijdag 19 augustus 2022 @ 12:39:
[...]

Hoor ik daar jaloezie op m'n vet coole postzegel?

"Don't hate the player, hate the game"

[Mugwump]

CodeCaster schreef op vrijdag 19 augustus 2022 @ 08:10:
Je leest vaker uit een database dan dat je ernaar schrijft, en lezen heeft al snel performanceproblemen als je het over meer dan honderd records en gebruikers hebt en je datalaag niet is gebouwd met performance in het achterhoofd.

Voor de gemiddelde OLTP-toepassing gaat dat doorgaans wel op ja.

De aanname dat je altijd met een heel object werkt, in combinatie met automatische lazy loading van gerelateerde objecten en het feit dat een relationele tabel per definitie nooit plat is maar relaties heeft, zorgt ervoor dat de combinatie van veelgebruikte technieken (Symfony, API Platform, Doctrine) nooit goed kán performen.

Als je een API wil maken die wederom die orders wil exposen met, bijvoorbeeld, een SUM(orderline.quantity), dan gaat die genoemde combinatie van technieken out of the box alle orderregels ophalen per order, en er dan in PHP overheen loopen om de aantallen op te tellen.

Dus dan moet je een custom DataProvider (uit m'n hoofd) schrijven voor API Platform, een custom DTO voor Doctrine (want geen projections), want de aanname van API Platform is dat wat uit je API's komt precies je entities zijn. Dat is om te beginnen al zo'n verschrikkelijk slechte aanname dat ik niet snap dat dat framework zo populair is. Een API-resource is vaak een representatie van een aantal gemapte entities, en zou moeten losstaan van hoe je je data opslaat. Of GraphQL, maar goed.

Einde rant, goedemorgen, koffie?

Ik ben in de loop der jaren eigenlijk een steeds grotere hekel aan ORM beginnen te krijgen, zeker het meest basale 'genereer 1 op 1 objectjes met gerelateerde objects o.b.v. de tabelstructuur lijkt in het begin heel snel tot resultaat te leiden, maar je loopt al weer heel snel tegen beperkingen aan zoals hetgeen je hier beschrijft met lazy loading. Ik heb in het verleden wel eens met Hibernate gehad dat ik me afvroeg waarom een doodeenvoudige query opeens 20 seconden duurde. Debug logging aan en hij gaat doodleuk 800 sequentiële queries afvuren vanwege lazy loading.
Als ik tegenwoordig nog met SQL datastores werk, dan gebruik ik graag iets als JOOQ. Dat biedt veel van de voordelen die ORMs ook bieden, maar houd je data store / SQL centraal. Een hele makkelijke manier om b.v. in Postgres zo'n structuur met een order en een x aantal orderregels uit een andere tabel op te halen is middels Json object / aggregatiefuncties. Je hebt 1 query die netjes netjes een hierarchisch JSON modelletje uitspuugt en je hoeft in je code alleen maar even te deserializen naar objecten.

[Sandor_Clegane]

Mugwump schreef op vrijdag 19 augustus 2022 @ 13:02:
[...]


Voor de gemiddelde OLTP-toepassing gaat dat doorgaans wel op ja.


[...]


Ik ben in de loop der jaren eigenlijk een steeds grotere hekel aan ORM beginnen te krijgen, zeker het meest basale 'genereer 1 op 1 objectjes met gerelateerde objects o.b.v. de tabelstructuur lijkt in het begin heel snel tot resultaat te leiden, maar je loopt al weer heel snel tegen beperkingen aan zoals hetgeen je hier beschrijft met lazy loading. Ik heb in het verleden wel eens met Hibernate gehad dat ik me afvroeg waarom een doodeenvoudige query opeens 20 seconden duurde. Debug logging aan en hij gaat doodleuk 800 sequentiële queries afvuren vanwege lazy loading.
Als ik tegenwoordig nog met SQL datastores werk, dan gebruik ik graag iets als JOOQ. Dat biedt veel van de voordelen die ORMs ook bieden, maar houd je data store / SQL centraal. Een hele makkelijke manier om b.v. in Postgres zo'n structuur met een order en een x aantal orderregels uit een andere tabel op te halen is middels Json object / aggregatiefuncties. Je hebt 1 query die netjes netjes een hierarchisch JSON modelletje uitspuugt en je hoeft in je code alleen maar even te deserializen naar objecten.

Ik vind CQRS wel elegant.

[armageddon_2k1]

Sandor_Clegane schreef op vrijdag 19 augustus 2022 @ 13:26:
[...]


Ik vind CQRS wel elegant.

Ik weet het niet helemaal. Ik moet zeggen dat ik het nog nooit in een echte grote productie-omgeving tegen ben gekomen, maar waar ik het wel gezien heb vind ik het..... overkill? De beloftes van strikte scheiding van mutable en immutable data en vaak combinatie met event-sourcing wegen vaak niet op tegen de complexiteit van hoe het hele systeem nu weer werkt. En dat maakt het lastig om devs te vinden.

Maar ik heb er niet genoeg ervaring mee wellicht.

[Kalentum]

Mugwump schreef op vrijdag 19 augustus 2022 @ 13:02:
[...]


Voor de gemiddelde OLTP-toepassing gaat dat doorgaans wel op ja.


[...]


Ik ben in de loop der jaren eigenlijk een steeds grotere hekel aan ORM beginnen te krijgen, zeker het meest basale 'genereer 1 op 1 objectjes met gerelateerde objects o.b.v. de tabelstructuur lijkt in het begin heel snel tot resultaat te leiden, maar je loopt al weer heel snel tegen beperkingen aan zoals hetgeen je hier beschrijft met lazy loading. Ik heb in het verleden wel eens met Hibernate gehad dat ik me afvroeg waarom een doodeenvoudige query opeens 20 seconden duurde. Debug logging aan en hij gaat doodleuk 800 sequentiële queries afvuren vanwege lazy loading.
Als ik tegenwoordig nog met SQL datastores werk, dan gebruik ik graag iets als JOOQ. Dat biedt veel van de voordelen die ORMs ook bieden, maar houd je data store / SQL centraal. Een hele makkelijke manier om b.v. in Postgres zo'n structuur met een order en een x aantal orderregels uit een andere tabel op te halen is middels Json object / aggregatiefuncties. Je hebt 1 query die netjes netjes een hierarchisch JSON modelletje uitspuugt en je hoeft in je code alleen maar even te deserializen naar objecten.

Vraagje: als PostgreSQL JSON teruggeeft, hoe onthou je dan de datatypes van een database tabel? Ik zou toch wel erg vervelend vinden als alles wordt gecast naar strings, booleans en numbers

[Mugwump]

armageddon_2k1 schreef op vrijdag 19 augustus 2022 @ 13:35:
[...]


Ik weet het niet helemaal. Ik moet zeggen dat ik het nog nooit in een echte grote productie-omgeving tegen ben gekomen, maar waar ik het wel gezien heb vind ik het..... overkill? De beloftes van strikte scheiding van mutable en immutable data en vaak combinatie met event-sourcing wegen vaak niet op tegen de complexiteit van hoe het hele systeem nu weer werkt. En dat maakt het lastig om devs te vinden.

Maar ik heb er niet genoeg ervaring mee wellicht.

Ik werk nu aan een vrij groot systeem dat is opgezet middels event sourcing en losstaande projections. Eigenlijk werkt dat heel fijn. Het is herbouw van bestaande software die nog werkte op het one-size-does-not-fit-all principe.
In dat oude systeem gebeurde echt alles op 1 enkele database. Wegschrijven in hoog volume, verschillende soorten APIs, operationele real-time reporting en ga zo maar door. Dan kun je wel als een idioot verticaal blijven schalen, maar je blijft steeds maar weer tegen issues aanlopen en het betekent bakken werk voor mensen die ops werkzaamheden verrrichten.
In plaats van al die verschillende leesactiviteiten op 1 uniforme datastructuur en dus ook op 1 enkele technologie te laten werken hebben we dat nu volledig losgetrokken. Voor de ene toepassing is een elasticsearch cluster met een bepaald datamodel het handigst, voor een ander weer een DynamoDB table met een ander datamodel, voor analyse is vaak iets als Athena prima en ga zo maar door.
Ja je systeem wordt complex, maar je kunt ook meer fragmenteren op die manier. Waar in het oude systeem alles impact had op alles en je dus eigenlijk als developer ook het hele systeem goed moest kennen, kun je nu bijvoorbeeld gewoon een dedicated team / persoon op 1 specifiek onderdeel zetten.

Overigens is CQRS helemaal niet zozeer de opzet waar jij aan refereert en die ik hierboven beschrijf, maar vaak ook gewoon simpelweg dat je voor de R en de CUD twee verschillende modellen gebruikt in je code terwijl je alles nog gewoon netjes in 1 data store / model hebt staan. Ik vind de documentatie van Microsoft over dit soort onderwerpen altijd wel heel helder, ook al doe ik zelf niets met .Net (meer).

[Mugwump]

Kalentum schreef op vrijdag 19 augustus 2022 @ 13:35:
[...]


Vraagje: als PostgreSQL JSON teruggeeft, hoe onthou je dan de datatypes van een database tabel? Ik zou toch wel erg vervelend vinden als alles wordt gecast naar strings, booleans en numbers

Dat kan inderdaad een issue zijn, maar eentje die in veel gevallen (waaronder het voorbeeld waarin ik het gebruik) eigenlijk niet relevant is. In dit geval gaat de data sowieso in JSON-formaat via een API terug over de lijn, dus als je datastructuur niet in JSON gerepresenteerd kan worden, dan heb je sowieso een probleem.

[whoami]

Mugwump schreef op vrijdag 19 augustus 2022 @ 13:02:
[...]


Ik heb in het verleden wel eens met Hibernate gehad dat ik me afvroeg waarom een doodeenvoudige query opeens 20 seconden duurde. Debug logging aan en hij gaat doodleuk 800 sequentiële queries afvuren vanwege lazy loading.

Ligt dat aan Hibernate, of aan de developer die de HQL / Criteria / Hibernate config gemaakt heeft ? In principe zou je als developer moeten controleren hoe de queries die je ORM gegeneert er uit zien. En indien je een dergelijk n+1 probleem ziet, dat moeten oplossen.
Werken met een ORM heeft zo zijn voordelen, maar er komt ook een nieuwe verantwoordelijkheid bij: niet zomaar vertrouwen op wat voor achterliggende queries er uitgevoerd worden.

[whoami]

Sandor_Clegane schreef op vrijdag 19 augustus 2022 @ 13:26:
[...]


Ik vind CQRS wel elegant.

Waarom ? Kan je ook wat meer info geven waarom je dat elegant vind ?
Puur CQRS waarbij je verschillende datastores hebt voor reads & writes vind ik in 99% van de gevallen onnodig en te complex.

Dat je verschillende modellen hebt voor lezen & schrijven kan dan weer wel een voordeel zijn.

[Mugwump]

whoami schreef op vrijdag 19 augustus 2022 @ 13:52:
[...]
Ligt dat aan Hibernate, of aan de developer die de HQL / Criteria / Hibernate config gemaakt heeft ? In principe zou je als developer moeten controleren hoe de queries die je ORM gegeneert er uit zien. En indien je een dergelijk n+1 probleem ziet, dat moeten oplossen.
Werken met een ORM heeft zo zijn voordelen, maar er komt ook een nieuwe verantwoordelijkheid bij: niet zomaar vertrouwen op wat voor achterliggende queries er uitgevoerd worden.

Je maakt er gelijk een schuldvraag van, maar dat is nou juist precies hetgeen waar het mij om gaat. In plaats van dat je SQL optimaliseert op de plek waar het hoort (en waar het doorgaans ook veel efficiënter kan) zit dat nu zoveel mogelijk weggeabstraheerd in een framework dat zaken voor je pretendeert te doen, maar als je niet oplet toch vooral problemen veroorzaakt op dat punt. SQL wordt in mijn ogen ook vaak nog wel onderschat of misschien een beetje eng gevonden. Efficiënte SQL schrijven is een vak op zich (heb veel collega's in de BI hoek die dat nog veel beter kunnen dan ik) en dat goed doen kunnen en doen is vaak veel effectiever dan je weer in allerlei bochten wringen om een ORM te laten performen.

[Sandor_Clegane]

whoami schreef op vrijdag 19 augustus 2022 @ 13:53:
[...]


Waarom ? Kan je ook wat meer info geven waarom je dat elegant vind ?
Puur CQRS waarbij je verschillende datastores hebt voor reads & writes vind ik in 99% van de gevallen onnodig en te complex.

Dat je verschillende modellen hebt voor lezen & schrijven kan dan weer wel een voordeel zijn.

In de basis al het idee dat lezen en schrijven afzonderlijke acties zijn en dus ook niet via dezelfde lagen hoeven te lopen vind ik een slimme.

Het scheiden van de applicatie in, als het ware, twee "stromen" maakt het naar mijn idee ook gemakkelijker om erover te redeneren. Dat is naar mijn idee een van de belangrijkste eisen aan programmatuur: dat je kunt beredeneren hoe iets werkt en vooral ook een mentaal model kunt maken hoe het reageert als je wijzigingen maakt.

Zoals @Mugwump ook al aangeeft hoeft dit niet in combinatie met Event Sourcing te zijn, maar kun je prima aparte tabellen/materialized views in een SQL datastore hebben die het lezen afhandelen. Misschien op aparte shards etc.

[ Voor 11% gewijzigd door Sandor_Clegane op 19-08-2022 14:37 ]

[.oisyn]

TIL: het is vroedvrouw, niet voedvrouw.

[Caelorum]

En vroedmeester

[bwerg]

Geen wroetvrouw? Of verwar ik het nou met een verloskundige?

[Lethalis]

Zijn er hier eigenlijk .NET developers die het aandurven om Blazor (WebAssembly) te gebruiken?

Tot nu toe betekende frontend development bij ons een tijdje React of Angular, maar het idee dat je gewoon C# kunt gebruiken klinkt wel erg aantrekkelijk, al is het alleen maar omdat ik nog collega's heb die niet thuis zijn in de huidige technieken en Blazor ervoor zou kunnen zorgen dat ze sneller mee kunnen werken aan nieuwe projecten.

Blazor.. in een grote boog er omheen lopen of toch omarmen?

[Sebazzz]

Wij gebruiken Blazor Server, hier zijn we echt heel tevreden over Het werkt simpel, is gemakkelijk te begrijpen en echt een verademing tegenover de complexiteit van de JS SPA frameworks.

[RagingPenguin]

Sebazzz schreef op woensdag 24 augustus 2022 @ 08:02:
Wij gebruiken Blazor Server, hier zijn we echt heel tevreden over Het werkt simpel, is gemakkelijk te begrijpen en echt een verademing tegenover de complexiteit van de JS SPA frameworks.

Is het nog steeds zo dat alle state van een app server-side word bijgehouden (en dus elke actie via het network moet lopen en alle DOM updates door de server worden berekend) of zijn ze daar nu vanaf gestapt? De docs zijn daar nu niet echt duidelijk over, het is ook wel weer typisch microsoft om nu al 3 verschillende project types te hebben enzo

[Lethalis]

RagingPenguin schreef op woensdag 24 augustus 2022 @ 08:36:
[...]


Is het nog steeds zo dat alle state van een app server-side word bijgehouden (en dus elke actie via het network moet lopen en alle DOM updates door de server worden berekend) of zijn ze daar nu vanaf gestapt? De docs zijn daar nu niet echt duidelijk over, het is ook wel weer typisch microsoft om nu al 3 verschillende project types te hebben enzo

Blazor Server werkt via de server. Het houdt een websocket (Signalr) verbinding open per browser venster. Qua schaalbaarheid is dat een nadeel, maar de kans is groot dat je met de meeste projecten nooit tegen een grens van pakweg 20.000 gelijktijdige connecties aanloopt.

Blazor WebAssembly is volledig client side. Dit heeft wellicht mijn voorkeur. Nadeel is vooral de initial load time, hoewel daar al veel aan verbeterd is. Maar het dwingt je iig om een losse api voor de backend te gebruiken, wat voorkomt dat mensen er 1 grote spaghetti van maken. Daarnaast kun je er een SPA van maken en ook offline werken. Dat schijnt met Blazor Server niet te kunnen.

Voordeel van Blazor Server is wel: als je heel snel een klein project wil opzetten kan dat in 1 project... even harken en klaar.

Laatst nog een presentatie gezien over Blazor WebAssembly waarin ze modules uit Rust gebruiken en sqlite in de browser draaien met een lokale cache. Toch grappig dat dit kan

[ Voor 6% gewijzigd door Lethalis op 24-08-2022 08:49 ]