De Devschuur Coffee Corner - Iteratie ⑬

[CodeCaster]

Microsoft Ignite is zojuist afgetrapt, maar zoals elke conferentie en elk reclamepraatje is het ditmaal een poging "hoe kunnen we Copilot en Azure zo vaak mogelijk in elke zin verwerken", holy hell.

* CodeCaster vindt wel iets van mensen die generatieve modellen de beste uitvinding vinden sinds gesneden brood. Het heeft z'n nut, maar probeer het niet overal in te proppen...

[ Voor 38% gewijzigd door CodeCaster op 15-11-2023 18:33 ]

[Firesphere]

Microsoft...
https://ghuntley.com/fracture/

Geen spatader verandert

[boxlessness]

Firesphere schreef op donderdag 16 november 2023 @ 00:48:
Microsoft...
https://ghuntley.com/fracture/

Geen spatader verandert

Ik moet hierbij weer denken aan Steve Balmer's "developers, developers, developers". Microsoft heeft al heel lang door dat developers de achterdeur zijn waardoor ze hun producten een organisatie binnen krijgen. In onze organisatie zie ik het ook gebeuren, dat Azure als de candy-store gezien wordt waar gemakkelijk en snel dingen aan elkaar geknoopt worden, om vervolgens weer een tight-coupling te hebben met een ander Microsoft product (PowerBI is zo'n spin in het web aan het worden). Vervolgens lopen de (cloud)kosten uit de hand, zonder quick fix om dingen los te snijden, onder andere omdat mensen nu gewend zijn om dingen "op z'n Microsofts" te doen.
Laatst werd Python-in-Excel door management nog gezien als the next best thing since sliced bread voor onderzoekjes. Ik heb ze toch gewaarschuwd dat ze zich daarmee nog dieper in het Microsoft ecosysteem ingraven.

[Tribits]

Belofte maakt schuld, dus hierbij de eerste (en tijdelijk definitieve) versie van KoeienKasteel. Nu niet direct uit gaan pluizen onder welke naam het in is gechecked, het had net zo goed Arend Schulp kunnen zijn. Oh ja,, een en ander in leesbare vorm en met zo min mogelijk licentie. Vragen en opmerkingen zijn welkom, klachten mogen zoals gebruikelijk naar /dev/null

[ElkeBxl]

Advent of Code komt er weer aan

[Caelorum]

Oh mooi, kan ik weer rond dag 14 stranden omdat ik druk bezig ben met voorbereidingen.

[Ghehe]

ElkeBxl schreef op zondag 26 november 2023 @ 07:14:
Advent of Code komt er weer aan

De koffie zal weer rijkelijk vloeien als ik 25 dagen op een rij om 6u opsta. Vorig jaar 40 van de 50 sterretjes gehaald, hopelijk dit jaar ietsie beter

[wackmaniac]

De puzzels zijn weer een heerlijke rollercoaster aan moeilijkheidsgraad. Deel 2 van gisteren deed me denken aan Laternfish van twee jaar geleden.

[Kriekel]

Ik was van plan om dit jaar mee te gaan doen aan Advant of code, maar ben er nog niet aan toe gekomen . Mocht ik er later aan beginnen, is het leuk om alleen te doen en is het nog een beetje in te halen?

[MatHack]

Kriekel schreef op vrijdag 8 december 2023 @ 10:13:
Ik was van plan om dit jaar mee te gaan doen aan Advant of code, maar ben er nog niet aan toe gekomen . Mocht ik er later aan beginnen, is het leuk om alleen te doen en is het nog een beetje in te halen?

Ja hoor, je kunt alle jaren nog doen (dit is het 9e jaar), ik heb afgelopen jaar af en toe eens wat van de opdrachten van vorige jaren gedaan.

[DaFeliX]

Zo, even een rondje gedaan en in al m'n projecten .noai in de root gezet [0]...

[Caelorum]

Kriekel schreef op vrijdag 8 december 2023 @ 10:13:
Ik was van plan om dit jaar mee te gaan doen aan Advant of code, maar ben er nog niet aan toe gekomen . Mocht ik er later aan beginnen, is het leuk om alleen te doen en is het nog een beetje in te halen?

Zeker leuk om te doen. Inhalen is nu nog wel te doen, maar dan moet je nu wel beginnen met 3 dagen per dag te doen, anders loop je straks helemaal vast

(Ik moet ook nog beginnen haha)

[AW_Bos]

Ik heb gisteren een mooi hoogstandje gevonden om het jaar ge-roast mee af te sluiten
De website geroast.nl.

Je kan een foto uploaden, een simpele beschrijving over wie het gaat, en waar, en er komt een ware roast uit die ingesproken zijn door persiflages van bekende Nederlanders (Johan Dreksen, Brigitte Klaagdorp etc.. )

Geen idee hoe dit precies gebouwd is, maar ik vermoed wat wat tooltjes uit de kracht van AWS.
- Fotoherkenning na upload om een beschrijving te gebruiken.
- Beschrijving voeren aan ChatGPT (of AWS AI implementatie) met de eigenschappen om een roast te maken.
- En die tekst gebruiken om een stem te genereren (al weet ik niet hoe die stemmen nagemaakt zijn)
- En dan een video aanmaken met ffmpeg of een tooltje van wederom AWS.

Heb ik gelijk met zoiets?
Het resultaat is niet slecht te noemen, al hoewel ik het roasten een beetje mild vindt.

[Merethil]

AW_Bos schreef op donderdag 21 december 2023 @ 13:03:
Ik heb gisteren een mooi hoogstandje gevonden om het jaar ge-roast mee af te sluiten
De website geroast.nl.

Je kan een foto uploaden, een simpele beschrijving over wie het gaat, en waar, en er komt een ware roast uit die ingesproken zijn door persiflages van bekende Nederlanders (Johan Dreksen, Brigitte Klaagdorp etc.. )

Geen idee hoe dit precies gebouwd is, maar ik vermoed wat wat tooltjes uit de kracht van AWS.
- Fotoherkenning na upload om een beschrijving te gebruiken.
- Beschrijving voeren aan ChatGPT (of AWS AI implementatie) met de eigenschappen om een roast te maken.
- En die tekst gebruiken om een stem te genereren (al weet ik niet hoe die stemmen nagemaakt zijn)
- En dan een video aanmaken met ffmpeg of een tooltje van wederom AWS.

Heb ik gelijk met zoiets?
Het resultaat is niet slecht te noemen, al hoewel ik het roasten een beetje mild vindt.

Even geprobeerd omdat je "ik vindt" schreef en ik daarom een roast van jou wilde hebben

https://geroast.nl/ready_...3b4-b37f-ce69826fefa0.mp4

Omdat je "AW_Bos" heet "denkt" de AI wel dat je een politicus bent

[AW_Bos]

Merethil schreef op donderdag 21 december 2023 @ 13:53:
[...]


Even geprobeerd omdat je "ik vindt" schreef en ik daarom een roast van jou wilde hebben

https://geroast.nl/ready_...3b4-b37f-ce69826fefa0.mp4

Omdat je "AW_Bos" heet "denkt" de AI wel dat je een politicus bent

Gokje... Hij kijkt naar Wouter Bos die politicus was? Anyway, AW_Bos is vanaf begin af aan altijd een schuilnaam van mij geweest. Ik zou deze het liefst een andere naam willen geven, maar ik denk dat AW_Bos toch herkenbaarder blijft. Maar who knows...

[Firesphere]

Goeiemiddag... het is hier stil zeg!

[cariolive23]

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.

Real time data verwerken en daar ook op acteren, doen wij al vele jaren uiterst succesvol met PostgreSQL. 's Werelds grootste banken zijn erg blij met onze oplossing.

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.

DynamoDB kan ik niet over oordelen, wel over PostgreSQL: Dat werkt uitstekend! Ook met miljarden records en vele TB's aan data, waarbij je binnen enkele milliseconden een antwoord moet hebben op complexe vragen.

[OB1]

Ben voornemens om dit jaar met een project in mijn eigen tijd aan de slag te gaan. Gezien ik het serieus wil oppakken merk ik dat er al erg veel tijd zit in de voorbereiding, voordat ik ook maar een regel code heb geschreven of zelfs een technisch ontwerp op papier staat..

Hopelijk kan ik nog een keer deze maand beginnen met dingen ook echt te bouwen 🤞

[Kriekel]

Wat is het doel van je privé project? Kennis op doen? Of heb je een gebruiks doel voor de software die je gaat bouwen?
Ik heb zelf veel privé projecten opgezet die nooit een echt doel hadden. Daar heb ik veel van geleerd, maar ik heb ze nooit afgemaakt. Sinds een jaar ben ik bezig met een project dat daadwerkelijk wordt gebruikt en dat heeft toch echt een andere insteek. Ik leer er nog steeds veel van! Maar dat doe ik met mijn werk projecten gelukkig ook.

[DevWouter]

OB1 schreef op donderdag 4 januari 2024 @ 07:43:
Ben voornemens om dit jaar met een project in mijn eigen tijd aan de slag te gaan. Gezien ik het serieus wil oppakken merk ik dat er al erg veel tijd zit in de voorbereiding, voordat ik ook maar een regel code heb geschreven of zelfs een technisch ontwerp op papier staat..

Hopelijk kan ik nog een keer deze maand beginnen met dingen ook echt te bouwen 🤞

Zie de opmerking van Kriekel in "De Devschuur Coffee Corner - Iteratie ⑬"

Ik heb ook verschillende privé projecten gedraaid en er zit nogal een verschil in de aanpak.

Wel wil ik nog het al oude advies meegeven dat niemand wilt betalen voor potentie, dus spendeer niet al te veel tijd aan ontwerpen. Soms is bouwen, ook al is het achteraf vol met fouten, meer waardevol.

Jouw doel is namelijk een product, niet een project of een ontwerp. Project en ontwerpen zijn ondersteunende middelen.

[Mugwump]

cariolive23 schreef op donderdag 4 januari 2024 @ 06:25:
[...]

Real time data verwerken en daar ook op acteren, doen wij al vele jaren uiterst succesvol met PostgreSQL. 's Werelds grootste banken zijn erg blij met onze oplossing.


[...]

DynamoDB kan ik niet over oordelen, wel over PostgreSQL: Dat werkt uitstekend! Ook met miljarden records en vele TB's aan data, waarbij je binnen enkele milliseconden een antwoord moet hebben op complexe vragen.

Om de zoveel tijd wordt die post maar weer geciteerd met het idee dat je met Postgres niet in staat zou zijn om dat soort performance te halen op grote sets aan data, maar daar ging het helemaal niet om. Het ging om de hoeveelheid laat ik zeggen "DBA werk" die komt kijken bij het onderhouden en tunen van Postgres.

[OB1]

@Kriekel @DevWouter

Dank voor jullie wijze adviezen!

Mijn plan is om een tool voor mezelf te maken, daarmee zal ik het nodige leren. Mocht ik er toekomst inzien, dan zou ik het in een kleinere kring los willen laten.

Nu heb ik besloten om eerst een prototype te maken, zodat ik de technische werking kan aantonen voor mezelf, want er zitten wel wat uitdagingen voor mij in. Dan kan ik het zelf in gebruik nemen, om vervolgens naar de tekentafel te gaan en alles netjes vast te leggen.

[DevWouter]

@OB1

Vanwege het compliment dan nog een paar adviezen.

1. Sowieso releasen ook al is het drie keer niks. Dat jij het niks waard vind betekent nog niet dat anderen het niks waard vinden.
2. Prototype bestaat niet in software land, want wij kunnen dmv kopiëren en plakken heel snel de aantallen verhogen. En aan een minimal viable product besteden we vaak te veel tijd: https://leanylabs.com/blog/common-mvp-mistakes/
3. Eigen gebruik is leuk, maar dan wordt het een product specifiek voor jou. Dus snel publiek vinden, feedback verzamelen en klanten winnen. Je wilt niet dat jij de enige klant bent van je eigen product

[OB1]

DevWouter schreef op donderdag 4 januari 2024 @ 15:27:
@OB1

Vanwege het compliment dan nog een paar adviezen.

1. Sowieso releasen ook al is het drie keer niks. Dat jij het niks waard vind betekent nog niet dat anderen het niks waard vinden.
2. Prototype bestaat niet in software land, want wij kunnen dmv kopiëren en plakken heel snel de aantallen verhogen. En aan een minimal viable product besteden we vaak te veel tijd: https://leanylabs.com/blog/common-mvp-mistakes/
3. Eigen gebruik is leuk, maar dan wordt het een product specifiek voor jou. Dus snel publiek vinden, feedback verzamelen en klanten winnen. Je wilt niet dat jij de enige klant bent van je eigen product

Nogmaals dank voor de adviezen

Wat betreft (1) en (3), bij deze afgesproken!

Het gelinkte artikel ga ik vanavond op m'n gemak doorlezen, ik heb 'm in mijn notities opgeslagen. Ik snap echter de zin _Prototype bestaat niet in software land, want wij kunnen dmv kopiëren en plakken heel snel de aantallen verhogen_ niet, wat bedoel je hiermee? Bedoel je met aantal functionaliteiten in een applicatie?

[DevWouter]

OB1 schreef op vrijdag 5 januari 2024 @ 09:57:
Het gelinkte artikel ga ik vanavond op m'n gemak doorlezen, ik heb 'm in mijn notities opgeslagen. Ik snap echter de zin _Prototype bestaat niet in software land, want wij kunnen dmv kopiëren en plakken heel snel de aantallen verhogen_ niet, wat bedoel je hiermee? Bedoel je met aantal functionaliteiten in een applicatie?

Prototypes is een term die je vooral in industriële productie processen gebruikt. Dan komt er iets van de band afrollen en dat moet dan de norm zijn van wat er in de toekomst afgaat rollen. Het is dus vooral om te onderzoeken of er afwijkingen zijn.

Maar software tegenwoordig is vooral iteratieve verbeteringen en echt "prototyping" gebruiken we niet meer, immers dmv kopieren en plakken hebben we een exacte kopie zonder afwijking. Dus dan is er nooit een prototype geweest of het eindproduct is een prototype. Het proces bestaat nog wel, kinda, maar is eigenlijk vervangen door nieuwe methodologieën zoals scrum of paper prototyping (andere schaal).

[Voutloos]

Beetje filosofisch/offtopic, iedereen begrijpt wat met prototype bedoeld wordt. Tenminste voor hobby projecten, bij grote orgs wil je niet dat alle helikopterende managers onterecht denken dat iets af is dus zal je meer op woorden moeten letten.
Dat moet ik bijv ook tijdens $dayjob, maar het is niet per se het aspect dat ik er het eerste erbij haal als ik solo vrije tijd ga fröbelen.

[.oisyn]

Een proof of concept is natuurlijk ook gewoon een prototype. En dat we perfect kunnen kopiëren en plakken klopt op zich, maar dat impliceert niet dat je dat ook correct doet. Zeker als code uit een losstaand probeersel plakt om te integreren in een volwaardige applicatie kan er nog genoeg mis gaan.

[DevWouter]

@Voutloos en @.oisyn
Ik heb mezelf om de door jullie genoemde reden ook aangeleerd om Prototype/proof-of-concept/MVP/etc altijd een dag ontwikkeltijd te geven voor dat het de `rm -rf` krijgt
Want na 1 week weet ik zeker dat het alsnog een volledig product wordt (en dus niet een prototype was) of dat er heleboel geld en tijd ingestopt wordt die we nooit meer terug krijgen en het dus vooral een project is om mensen aan het werk te houden.

Verder de enige reden dat ik er zo fel op ben is omdat ik een keertje tijdje heb staan praten met iemand die industriële prototypes maakt. Dan wordt je toch een beetje bewust dat "software prototypes" gewoon super slap aftreksels zijn

[ Voor 9% gewijzigd door DevWouter op 05-01-2024 14:48 ]

[Voutloos]

DevWouter schreef op vrijdag 5 januari 2024 @ 14:47:
Verder de enige reden dat ik er zo fel op ben is omdat ik een keertje tijdje heb staan praten met iemand die industriële prototypes maakt. Dan wordt je toch een beetje bewust dat "software prototypes" gewoon super slap aftreksels zijn

Je kan ook precies met de omgekeerde conclusie eindigen:
In die industrie wordt blijkbaar geaccepteerd dat je het weggooit, moet itereren of nog een hele fabriek moet inrichten. Whatever er nog te valideren of te doen is.
Bij software wordt daar vaak overheen gestapt, maar misschien potverdikkie juist omdat jij niet het concept prototype met hand en tand verdedigt!

[Voutloos]

Mijn advies voor @OB1 is meer zoals @Kriekel stelde.
Voor de hobby kan je een ‘moving target’ accepteren. Steeds weer refactoren, scope bijstellen etc etc. Kan echt leuk en leerzaam zijn. Maar de ervaring leert dat je nooit gevoelsmatig voorbij v0.5 komt… en soms is dat prima!

Als het aspect met opleveren en feedback krijgen (of zelfs positieve feedback in de vorm van geld ) belangrijk is, dan kan je inderdaad beter de andere modus toepasssen: ship early and often.

[Voutloos]

Omdat het vrijmibo is: Die eerste modus is meer ipv een potje Factorio, Cookie Clicker en Universal Paperclips. Protip voor de vrijdag (en rest van het weekend) is om die spellen NIET op te zoeken.

[Mugwump]

Voutloos schreef op vrijdag 5 januari 2024 @ 12:52:
Beetje filosofisch/offtopic, iedereen begrijpt wat met prototype bedoeld wordt. Tenminste voor hobby projecten, bij grote orgs wil je niet dat alle helikopterende managers onterecht denken dat iets af is dus zal je meer op woorden moeten letten.
Dat moet ik bijv ook tijdens $dayjob, maar het is niet per se het aspect dat ik er het eerste erbij haal als ik solo vrije tijd ga fröbelen.

Ik heb dat bij mijn huidige klant met het concept "MVP", dat wordt vooral gebruikt om op een hele slechte manier development op te knippen in brokken die op zichzelf geen waarde toevoegen. De V van viable wordt niet bepaald begrepen en de M van minimal ook niet.

[.oisyn]

I was today years old toen ik erachter kwam dat de middelste naam van Macaulay Culkin... Macaulay Culkin is.

Ja, hij heet Macaulay Macaulay Culkin Culkin . Blijkbaar nadat hij op Twitter een poll was gestart over zijn nieuwe tweede naam, die voorheen Carson was.

EINDE BERICHT

[Mugwump]

.oisyn schreef op maandag 8 januari 2024 @ 14:01:
I was today years old toen ik erachter kwam dat de middelste naam van Macaulay Culkin... Macaulay Culkin is.

Ja, hij heet Macaulay Macaulay Culkin Culkin . Blijkbaar nadat hij op Twitter een poll was gestart over zijn nieuwe tweede naam, die voorheen Carson was.

EINDE BERICHT

Infinite recursion error?

[Merethil]

.oisyn schreef op maandag 8 januari 2024 @ 14:01:
I was today years old toen ik erachter kwam dat de middelste naam van Macaulay Culkin... Macaulay Culkin is.

Ja, hij heet Macaulay Macaulay Culkin Culkin . Blijkbaar nadat hij op Twitter een poll was gestart over zijn nieuwe tweede naam, die voorheen Carson was.

EINDE BERICHT

Inderdaad, al in 2018 blijkbaar:
(Van wikipedia)

In December 2018, Culkin announced that he would legally change his name to "Macaulay Macaulay Culkin Culkin" after holding a vote through his website to choose a new middle name, with "Macaulay Culkin" winning the vote over four other candidates.

Blijkbaar een vote op z'n eigen website ipv op Twitter, maar het internet heeft een Boaty McBoatface gedaan met z'n naam

Edit: Nou, ik heb weer een paar minuten van m'n leven vergooid door in de Wikipediafuik over McBoatfacing te springen: Wikipedia: List of Mcface spoofs

[ Voor 11% gewijzigd door Merethil op 08-01-2024 15:27 ]

[Snowfall]

Ik kwam vanochtend op kantoor van mn huidige opdrachtgever (pre pre pre startup) net zoals vrijwel elke 2de woensdag zodat ik een meeting kan bijwonen dat eigenlijk een email had moeten zijn.

Maar het was verdacht rustig op slack afgelopen week en de server was ook meerdere momenten niet bereikbaar dus ik heb weinig meegekregen van wat er gaande is, maar dus ik kwam op kantoor vanochtend om half 7 en kantoor was leeg. Echt niemand daar behalve de zogenaamde "CEO".

Blijkbaar is vorige week vrijdag het android team ontslagen en is het volledige iOS team opgestapt omdat "management" heeft besloten om niet meer platform native te gaan ontwikkelen maar React native te gaan gebruiken, en is "management" uit elkaar gevallen.

Nu is deze keuze gemaakt om de kosten te drukken want het blijkt dat het geld bijna op is. Veel te laat volgens mij want het geld is blijkbaar al op en nu proberen ze te salvagen en te verkopen wat ze kunnen verkopen.

Misschien is dit niet echt een Dev schuur rant maar ik vind dit zo bijzonder. Ik vind werken voor startups wel leuk omdat je soms t geluk hebt om er iets "sexy's " van te maken en er een leuk share package uit kan halen als dat logisch klinkt. En je altijd aan iets nieuws werkt. Maar wat ik zo bijzonder vind is hoe er in sommige bedrijven zo met geld wordt gestrooid alsof het niets is en alsof het niets hoeft op te brengen en opeens is het geld op en opeens bestaat het niet meer.

Ik heb zelf een startup in ontwikkeling (op eigen kosten uiteraard) en doe freelance er meestal naast voor shares in potentiële startups maar ik strooi echt niet zomaar met geld naar elk kleine kostenpost die we creëren. Dan bedoel ik vooral als in "Wat? je wilt Epyc server?" NOPE. "Je wilt een Mac Studio ultra?" Nope. enz enz. Maar die opdrachtgever zei echt letterlijk tegen bijna alles ja. En ik vind dat zo vreemd dat het soms lijkt alsof veel startups of startende bedrijven geld te verbranden hebben zo gauw ze investeerders hebben.

Sorry voor de niet zo Dev schuur rant maar echt soms ben ik echt verbaasd over hoe "dommig" sommige mensen zijn. Of misschien is het onmacht of geen management ervaring of geen financiële ervaring. Of ze hebben een idee maar pakken de realisatie compleet verkeerd aan.

Maar pluspunt is wel. Mijn overeenkomst loopt tot eind februari en CEO gaat me uit eigen zak doorbetalen tot eind februari om hun API in MVP te krijgen zodat ze het kunnen verkopen.

[Voutloos]

Maar eh… uiteindelijk doe je wel mee met dit alles, dus in het verlengde hoor je er zeker bij.

Ik hoor genoeg rode vlaggen die bij mij niet met een mac studio te compenseren zijn.

Wellicht heb ik ook een aversie tegen risico’s, of een tikkie paranoïde, maar ik zou op basis van dit verhaal niet verwachten dat het salarisstrookje in februari zonder drama is. :x

[RagingPenguin]

O ja, het startup mangement wereldje is ook altijd iets bijzonders. In mijn ervaring zit het vooral vol met gladde, jonge en naive jongens en meisjes die eigenlijk gewoon in een standaard starterfunctie als "junior serivice manager" zouden moeten zitten, maar daar te goed voor zijn

[RagingPenguin]

dubbel

[ Voor 97% gewijzigd door RagingPenguin op 10-01-2024 21:54 ]

[DevWouter]

@Snowfall In mijn beleving is jouw bericht een heerlijke DevSchuur post.

[Mugwump]

Hoewel ik met grote regelmaat loop te vloeken en tieren op het hele enterprisewereldje waarin ik me als externe consultant begeef, ben ik ook wel erg gehecht aan m'n comfortabele baantje in loondienst zonder enig gezeik.

[RagingPenguin]

Mugwump schreef op donderdag 11 januari 2024 @ 16:35:
Hoewel ik met grote regelmaat loop te vloeken en tieren op het hele enterprisewereldje waarin ik me als externe consultant begeef, ben ik ook wel erg gehecht aan m'n comfortabele baantje in loondienst zonder enig gezeik.

Ik denk dat we liever allemaal in de dierentuin naar de aapjes achter het hek kijken i.p.v. met de aapjes achter het hek zitten Als developers hebben we gelukkig het voorrecht om ons buiten het meeste gedoe van het corparate circus te houden, maar kunnen we wel lekker meegenieten van al het drama wat ons toch niet aangaat.

[armageddon_2k1]

RagingPenguin schreef op woensdag 10 januari 2024 @ 21:54:
O ja, het startup mangement wereldje is ook altijd iets bijzonders. In mijn ervaring zit het vooral vol met gladde, jonge en naive jongens en meisjes die eigenlijk gewoon in een standaard starterfunctie als "junior serivice manager" zouden moeten zitten, maar daar te goed voor zijn

Het zit vooral vol met mensen die veel praten en weinig kunnen, die geil worden van stoere termen gebruiken en passages quoten uit Walter Isaacson boeken. Het zit vooral vol met nietskunners.

Laatst ook weer eentje met het Musk mantra kwam over requirements..... ja leuk vriend, maar het helpt wel als we uberhaubt requirements hebben.

[ Voor 10% gewijzigd door armageddon_2k1 op 12-01-2024 10:50 ]

[Saven]

Iemand wat meer ervaring met (mariadb/mysql) databases en netwerken? Gebruik voor een hobbyprojectje een losse db-server. Die staat in hetzelfde datacenter/gebied als de webserver en ze draaien in hetzelfde 'private network'.

Echter, waar de gemiddelde query in ongeveer 500μs wordt uitgevoerd in een lokale omgeving (db en web in dezelfde vm) is dat in productie een paar milliseconden meer. Zeg maar een ms of 4 á 5 per query extra.

Dat lijkt enorm weinig natuurlijk. Maar met 20 queries zit je al op ~100ms aan extra responsetijd van de webserver. In sommige gevallen worden er nog meer queries uitgevoerd, dus dan tikt die overhead wel aan.

Ik begrijp dat er enige latency is vanwege het netwerk. Maar is 4ms per query normaal? Of wellicht andere quick tips?

[RagingPenguin]

Saven schreef op zondag 14 januari 2024 @ 14:16:
Iemand wat meer ervaring met (mariadb/mysql) databases en netwerken? Gebruik voor een hobbyprojectje een losse db-server. Die staat in hetzelfde datacenter/gebied als de webserver en ze draaien in hetzelfde 'private network'.

Echter, waar de gemiddelde query in ongeveer 500μs wordt uitgevoerd in een lokale omgeving (db en web in dezelfde vm) is dat in productie een paar milliseconden meer. Zeg maar een ms of 4 á 5 per query extra.

Dat lijkt enorm weinig natuurlijk. Maar met 20 queries zit je al op ~100ms aan extra responsetijd van de webserver. In sommige gevallen worden er nog meer queries uitgevoerd, dus dan tikt die overhead wel aan.

Ik begrijp dat er enige latency is vanwege het netwerk. Maar is 4ms per query normaal? Of wellicht andere quick tips?

4ms extra voor een andere infra setup klinkt niet heel vreemd. Ik zou mij eerder afvragen waarom een webserver 20 queries moet doen om een response te geven.

[ Voor 3% gewijzigd door RagingPenguin op 14-01-2024 14:19 ]

[CodeCaster]

RagingPenguin schreef op zondag 14 januari 2024 @ 14:18:
[...]


4ms extra voor een andere infra setup klinkt niet heel vreemd. Ik zou mij eerder afvragen waarom een webserver 20 queries moet doen om een response te geven.

Ja, liever 20 ajax-calls met loading spinners?

[Saven]

RagingPenguin schreef op zondag 14 januari 2024 @ 14:18:
[...]


4ms extra voor een andere infra setup klinkt niet heel vreemd. Ik zou mij eerder afvragen waarom een webserver 20 queries moet doen om een response te geven.

Eens. Hoewel het geen absurd aantal queries is. Ik zie wel eens Wordpress sites met 50+ queries per pagina man man man.

In dit geval wordt veel verschillende algemene data opgehaald, waaronder een aantal counts/aggregates. 't Is ook geen mega issue hoor, maar het viel me wel op. Caching komt later nog aan de orde overigens, waardoor het aantal queries zal afnemen. Maar vind het belangrijk dat de basis an sich gewoon in orde is.

Thanks iig voor je bevestiging Blijf het toch wel een beetje gek vinden die 4ms per query aan overhead voor een server die er bij wijze van spreken naast staat. Ik gok dat Tweakers niet veel minder queries uitvoert op veel pagina's. Daar merk ik dat ook niet echt terug in de TTFB, en zij werken ook niet met ajax spinners.

CodeCaster schreef op zondag 14 januari 2024 @ 14:40:
[...]

Ja, liever 20 ajax-calls met loading spinners?

Meh. Ik snap je zeker, maar is imo meer een dirty hack dan echt een 'fix'. In dit geval ook niet echt nodig natuurlijk. Hangt mss ook af van het soort/hoeveelheid data. Maar het is geen enterprise applicatie ofzo die een database van terbytes met complexe queries moet doorzoeken

[remyz]

Saven schreef op zondag 14 januari 2024 @ 14:16:
[…]

Ik begrijp dat er enige latency is vanwege het netwerk. Maar is 4ms per query normaal? Of wellicht andere quick tips?

Kan je een ping van web- naar databaseserver doen? Hoe lang duurt die ping?

[RagingPenguin]

CodeCaster schreef op zondag 14 januari 2024 @ 14:40:
[...]

Ja, liever 20 ajax-calls met loading spinners?

Dat zou een verbetering zijn t.o.v. 20 queries in sequence achter elkaar doen voordat je pas iets met de data van de eerste query doet

Maar liever queries combineren en parallel doen.

[Saven]

remyz schreef op zondag 14 januari 2024 @ 15:51:
[...]


Kan je een ping van web- naar databaseserver doen? Hoe lang duurt die ping?

Sure!

PING 192.168.2.105 (192.168.2.105) 56(84) bytes of data.
64 bytes from 192.168.2.105: icmp_seq=1 ttl=64 time=1.08 ms
64 bytes from 192.168.2.105: icmp_seq=2 ttl=64 time=1.05 ms
64 bytes from 192.168.2.105: icmp_seq=3 ttl=64 time=1.04 ms
64 bytes from 192.168.2.105: icmp_seq=4 ttl=64 time=1.21 ms
64 bytes from 192.168.2.105: icmp_seq=5 ttl=64 time=1.06 ms
64 bytes from 192.168.2.105: icmp_seq=6 ttl=64 time=1.37 ms
64 bytes from 192.168.2.105: icmp_seq=7 ttl=64 time=1.43 ms
64 bytes from 192.168.2.105: icmp_seq=8 ttl=64 time=1.25 ms
64 bytes from 192.168.2.105: icmp_seq=9 ttl=64 time=1.22 ms
64 bytes from 192.168.2.105: icmp_seq=10 ttl=64 time=1.17 ms
64 bytes from 192.168.2.105: icmp_seq=11 ttl=64 time=1.25 ms
64 bytes from 192.168.2.105: icmp_seq=12 ttl=64 time=1.35 ms
64 bytes from 192.168.2.105: icmp_seq=13 ttl=64 time=1.11 ms
64 bytes from 192.168.2.105: icmp_seq=14 ttl=64 time=1.05 ms

Was een van de eerste dingen die ik deed. Is dus minder dan de 4ms overhead die ik in queries ervaar. Maar ik heb te weinig netwerk kennis om hier echte conclusies uit te trekken

[ Voor 8% gewijzigd door Saven op 14-01-2024 16:09 ]

[RobertMe]

RagingPenguin schreef op zondag 14 januari 2024 @ 15:59:
[...]


Dat zou een verbetering zijn t.o.v. 20 queries in sequence achter elkaar doen voordat je pas iets met de data van de eerste query doet

Maar liever queries combineren en parallel doen.

In een beetje programmeertaal kun je die queries ook wel parallel doen zonder ajax te gebruiken. En ajax heeft natuurlijk ook weer zijn eigen overhead (request sturen, framework dat moet herleiden welke controller / action uit te voeren, autorisatie die eventueel uitgevoerd moet worden, ....

[CodeCaster]

RagingPenguin schreef op zondag 14 januari 2024 @ 15:59:
[...]


Dat zou een verbetering zijn

Niet mee eens, want 20 extra roundtrips naar de webserver die dan ieder voor zich weer naar de database gaan voegen alleen maar meer totale wachttijd toe aan een onbruikbare UI tot alle requests klaar zijn.

t.o.v. 20 queries in sequence achter elkaar doen voordat je pas iets met de data van de eerste query doet

Maar liever queries combineren en parallel doen.

Als de enkele request met 20 queries binnen 100 ms terugkomt, hoef je helemaal niks te doen. Tuurlijk, meer snel is meer mooi, maar 0,1s voor een webpagina terwijl er grotere zaken zijn om aan te pakken is helemaal prima. Parallelle queries zorgen weer voor hun eigen problematiek.

Maar lekker theoretisch prematuur optimaliseren dit. We houden onszelf wel aan het werk.

[ Voor 7% gewijzigd door CodeCaster op 14-01-2024 16:41 ]

[RagingPenguin]

CodeCaster schreef op zondag 14 januari 2024 @ 16:33:
[...]

Niet mee eens, want 20 extra roundtrips naar de webserver die dan ieder voor zich weer naar de database gaan voegen alleen maar meer totale wachttijd toe aan een onbruikbare UI tot alle requests klaar zijn.

Maar je hebt zelden alle data nodig om de hoofd functionaliteit van een website te laten werken. Als je het een beetje tactisch aanpakt laad je eerst alles in wat in de main body boven de fold word getoond en de rest later. Dat je wacht met het tonen van de header tot dat je alle data die in de footer gaat ingeladen hebt is nergens voor nodig.

Dit forum zou bijvoorbeeld ook een stuk soepler werken als ik niet na elke klik zou moeten wachten tot dat de lijst met populaire onderwerpen, administrators en moderator zijn geladen voordat de lijst aan topics/reacties word getoond.

Als de enkele request met 20 queries binnen 100 ms terugkomt, hoef je helemaal niks te doen. Parallelle queries zorgen weer voor hun eigen problematiek.

Tenzij je nog niet eens aan connectie pooling doet zie ik niet wat dat voor problematiek zouden moet opleveren? Je database en data laag zouden helemaal niet moeten weten of twee queries nu wel of niet bij hetzelfde http-request horen.

[remyz]

Saven schreef op zondag 14 januari 2024 @ 16:08:
[...]

Sure!

PING 192.168.2.105 (192.168.2.105) 56(84) bytes of data.
64 bytes from 192.168.2.105: icmp_seq=1 ttl=64 time=1.08 ms
64 bytes from 192.168.2.105: icmp_seq=2 ttl=64 time=1.05 ms
64 bytes from 192.168.2.105: icmp_seq=3 ttl=64 time=1.04 ms
64 bytes from 192.168.2.105: icmp_seq=4 ttl=64 time=1.21 ms
64 bytes from 192.168.2.105: icmp_seq=5 ttl=64 time=1.06 ms
64 bytes from 192.168.2.105: icmp_seq=6 ttl=64 time=1.37 ms
64 bytes from 192.168.2.105: icmp_seq=7 ttl=64 time=1.43 ms
64 bytes from 192.168.2.105: icmp_seq=8 ttl=64 time=1.25 ms
64 bytes from 192.168.2.105: icmp_seq=9 ttl=64 time=1.22 ms
64 bytes from 192.168.2.105: icmp_seq=10 ttl=64 time=1.17 ms
64 bytes from 192.168.2.105: icmp_seq=11 ttl=64 time=1.25 ms
64 bytes from 192.168.2.105: icmp_seq=12 ttl=64 time=1.35 ms
64 bytes from 192.168.2.105: icmp_seq=13 ttl=64 time=1.11 ms
64 bytes from 192.168.2.105: icmp_seq=14 ttl=64 time=1.05 ms

Was een van de eerste dingen die ik deed. Is dus minder dan de 4ms overhead die ik in queries ervaar. Maar ik heb te weinig netwerk kennis om hier echte conclusies uit te trekken

Lijken mij geen vreemde getallen. De volgende vraag is natuurlijk: hoelang duurt een query als je die rechtstreeks (lokaal dus) op de databaseserver uitvoert?

[CodeCaster]

RagingPenguin schreef op zondag 14 januari 2024 @ 16:50:
[...]


Maar je hebt zelden alle data nodig om de hoofd functionaliteit van een website te laten werken. Als je het een beetje tactisch aanpakt laad je eerst alles in wat in de main body boven de fold word getoond en de rest later. Dat je wacht met het tonen van de header tot dat je alle data die in de footer gaat ingeladen hebt is nergens voor nodig.

Dit forum zou bijvoorbeeld ook een stuk soepler werken als ik niet na elke klik zou moeten wachten tot dat de lijst met populaire onderwerpen, administrators en moderator zijn geladen voordat de lijst aan topics/reacties word getoond.

Als je een site (onder andere door middel van caching) zo snel krijgt dat deze pagina bijvoorbeeld in 0,05s (46ms) op je scherm staat, dan moet je absoluut geen kunstgrepen gaan uithalen om data onder de fold of die in menu's staat uitgesteld te gaan laden. Er kan alleen maar meer misgaan, zoals extra latency of zelfs verbroken verbindingen zodra mensen wel gaan scrollen of op dingen gaan klikken, nog afgezien van de extra onderhoudslast door meer verspreide code.

Ik heb een bloedhekel aan loading spinners, throbbers, skeleton screens en wat dies meer zij.

Tenzij je nog niet eens aan connectie pooling doet zie ik niet wat dat voor problematiek zouden moet opleveren? Je database en data laag zouden helemaal niet moeten weten of twee queries nu wel of niet bij hetzelfde http-request horen.

Het uitvoeren van 20 queries in parallel zorgt niet per se voor een applicatie die sneller is, noch onderhoudbaarder, noch monitorbaarder, schaalbaarder, enzovoorts.

Als je zorgt dat die 20 queries snel zijn (normaliseren, denormaliseren waar nodig, indices, caching) dan heb je er geen last van. Als ze traag zijn en je gaat ze in parallel uitvoeren, dan zijn ze nog steeds traag.

[RagingPenguin]

CodeCaster schreef op zondag 14 januari 2024 @ 18:14:
[...]

Het uitvoeren van 20 queries in parallel zorgt niet per se voor een applicatie die sneller is, noch onderhoudbaarder, noch monitorbaarder, schaalbaarder, enzovoorts.

Als je zorgt dat die 20 queries snel zijn (normaliseren, denormaliseren waar nodig, indices, caching) dan heb je er geen last van. Als ze traag zijn en je gaat ze in parallel uitvoeren, dan zijn ze nog steeds traag.

Al doe je ze in parallel dan duurt je request ergens tussen de executie tijd van de traagste tot aan de som van alle executie tijden. Al doe je ze in sequence dan is het gegerandeerd de worst case van in pararell en duurt de request de som van alle execution tijden. Omdat je client niets anders doen dan wachten tijdens het uitvoeren van een database query wil je ze altijd op z'n minst async doen, en is het heel weinig extra moeite om ze in pararell te doen.

En zelfs als ze allemaal snel zijn heb je dat, zie letterlijk de post waar deze discussie mee begon 20 keer de overhead van een query doen achter elkaar is best merkbaar.

Ik zie de rest van je nadelen ook niet echt, tenzij je echt brakke technieken gebruikt. Er is nu niets echt moeilijk aan async wat je code slechter onderhoudbaar zou maken. Monitoring zou ook geen probleem moeten zijn, webserver zijn al een hele tijd async. Schaalbaarheid zou ook niet minder moeten worden, hooguit juist marginaal beter omdat je minder requests tegelijkertijd open hebt. Het klink allemaal een beetje als slappe excusen om te programeren alsof het nog 2005 is.

[CodeCaster]

RagingPenguin schreef op zondag 14 januari 2024 @ 19:14:
[...]


Al doe je ze in parallel dan duurt je request ergens tussen de executie tijd van de traagste tot aan de som van alle executie tijden. Al doe je ze in sequence dan is het gegerandeerd de worst case van in pararell en duurt de request de som van alle execution tijden. Omdat je client niets anders doen dan wachten tijdens het uitvoeren van een database query wil je ze altijd op z'n minst async doen, en is het heel weinig extra moeite om ze in pararell te doen.

En zelfs als ze allemaal snel zijn heb je dat, zie letterlijk de post waar deze discussie mee begon 20 keer de overhead van een query doen achter elkaar is best merkbaar.

Ik zie de rest van je nadelen ook niet echt, tenzij je echt brakke technieken gebruikt. Er is nu niets echt moeilijk aan async wat je code slechter onderhoudbaar zou maken. Monitoring zou ook geen probleem moeten zijn, webserver zijn al een hele tijd async. Schaalbaarheid zou ook niet minder moeten worden, hooguit juist marginaal beter omdat je minder requests tegelijkertijd open hebt. Het klink allemaal een beetje als slappe excusen om te programeren alsof het nog 2005 is.

Async is niet hetzelfde als parallel. En een server heeft maar zoveel cores/threads. Je kunt wel 20 queries in parallel uitvoeren, maar dat betekent niet dat ze allemaal even lang duren als wanneer je ze sequentieel uitvoert, integendeel zelfs. Eén request dat even 20 databasevervindingen opeet is ook niet echt schaalbaar.

[RobertMe]

Is het al tijd voor de "9 vrouwen kunnen ook geen kind baren in 1 maand" opmerking?

[RagingPenguin]

CodeCaster schreef op zondag 14 januari 2024 @ 19:28:

Lees mijn reacties nu gewoon eens voordat je op de Nietes, Nietes, Nietes trein springt

Async is niet hetzelfde als parallel. En een server heeft maar zoveel cores/threads. Je kunt wel 20 queries in parallel uitvoeren, maar dat betekent niet dat ze allemaal even lang duren als wanneer je ze sequentieel uitvoert, integendeel zelfs.

"Al doe je ze in parallel dan duurt je request ergens tussen de executie tijd van de traagste tot aan de som van alle executie tijden. Al doe je ze in sequence dan is het gegerandeerd de worst case van in pararell en duurt de request de som van alle execution tijden."

"ergens tussen" de worst case en best case. En je webserver voert de queries niet uit, dat doet de database server. Je webserver begint alle queries en wacht tot dat de database server antwoord. Tenzij je queries heel snel zijn zal je zien dat een klein aantal thread prima 20 queries kan starten voordat de eerste antwoord. En dan heb je 20 mini-continuations voordat een thread de rest van je request afhandeld.

En terwijl jouw queries worden uitgevoerd kunnen de threads andere nuttige dingen doen. Als je alles lekker blocking sequentieel doet dan hou je threads bezig met niks doen, dat is pas inefficient en slecht schaalbaar.

Simpel gesteld, want:

Eén request dat even 20 databasevervindingen opeet is ook niet echt schaalbaar.

En dat is waarom je een connectie pool gebruikt (zoals ik eerder al zei: "Tenzij je nog niet eens aan connectie pooling doet"). Het enige wat je 20 threadstasks doen is 20 queries bij de connectie pool neerleggen die daar een (bestaande, open) connectie aan toewijst op een manier die de connectie pool bepaald als het meest efficient.

Het is ondertussen 2024, je thread manager, connectiepool en databases server zijn slim genoeg om 20 queries op de meest efficiente manier af te handelen als jij ze gewoon in parallel aanbied.

[ Voor 5% gewijzigd door RagingPenguin op 14-01-2024 20:44 ]

[F.West98]

Ik heb zo het idee dat jullie langs elkaar heen praten: volgens mij heeft @RagingPenguin het over het parallel uitvoeren van queries die behoren bij aparte, tevens parallelle, HTTP requests - waarbij de parallellisatie in de browser plaatsvindt. En volgens mij heeft @CodeCaster het over de code complexiteit die komt kijken bij het parallel uitvoeren van queries die bij dezelfde HTTP request horen - waarbij de parallellisatie in je eigen webserver code plaatsvindt.

En volgens mij hebben jullie allebei gelijk Want natuurlijk is het parallel uitvoeren van DB queries voor parallelle requests helemaal niet moeilijk, dat zou elke tool anno 2024 gewoon moeten kunnen. En natuurlijk is het zelf parallel maken van al die queries binnen je code voor het het verwerken van één request gewoon lastig - parallel programmeren is dat altijd en dat is anno 2024 ook nog niet anders.

(en ja ik ben het met @CodeCaster eens dat 20 HTTP requests echt verschrikkelijk is, en parallellisatie in de backend voor <100ms runtime ook premature optimisation is )
(doet me ineens denken aan https://qwik.builder.io/, waarbij alle frontend zaken on-demand in micro-requests van <1kB worden ingeladen. Ja, dat betekent dus dat de code voor je click-handler pas wordt gedownload als je al hebt geklikt... horrific)

[Firesphere]

Toen ik @F.West98 voor't eerst ontmoette mocht'ie nog niet eens mee drinken op de Devschuur meet, en nu leest'ie @CodeCaster even de les

[Voutloos]

Iedereen geboren in de 90’s is nog steeds tiener, toch?
Shit, ik word oud.

[Merethil]

Voutloos schreef op maandag 15 januari 2024 @ 12:26:
Iedereen geboren in de 90’s is nog steeds tiener, toch?
Shit, ik word oud.

Ik ben geboren in 1991, dus ik ben 32 en toch voelt 1999/2000 nog als een paar jaar terug. Het is dus een aardig universeel ding, zelfs voor mensen die erg jong waren bij de millenniumwisseling

[phex]

Firesphere schreef op maandag 15 januari 2024 @ 10:47:
Toen ik @F.West98 voor't eerst ontmoette mocht'ie nog niet eens mee drinken op de Devschuur meet, en nu leest'ie @CodeCaster even de les

Ondanks dat ik een permanente lurker ben, moet ik hier toch even een plusje voor uitdelen

[RagingPenguin]

Voutloos schreef op maandag 15 januari 2024 @ 12:26:
Iedereen geboren in de 90’s is nog steeds tiener, toch?
Shit, ik word oud.

Ah yes, the late 1900s

[ Voor 39% gewijzigd door RagingPenguin op 16-01-2024 16:44 ]

[RagingPenguin]

Merethil schreef op maandag 15 januari 2024 @ 13:09:
[...]


Ik ben geboren in 1991, dus ik ben 32 en toch voelt 1999/2000 nog als een paar jaar terug. Het is dus een aardig universeel ding, zelfs voor mensen die erg jong waren bij de millenniumwisseling

Dat heb ik niet, maar ik heb wel dat 2019 (en het hele covid gedoe) als vorig jaar voelt ook al is het al vier(!) jaar geleden. En 2015/2016 voelt aan als het jaar daarvoor.

[BarôZZa]

RagingPenguin schreef op dinsdag 16 januari 2024 @ 16:48:
[...]


Dat heb ik niet, maar ik heb wel dat 2019 (en het hele covid gedoe) als vorig jaar voelt ook al is het al vier(!) jaar geleden. En 2015/2016 voelt aan als het jaar daarvoor.

De laatste lockdown was minder dan twee jaar geleden, dus dat covid gedoe is niet raar.

Ik heb er zelf minder last van dat alles kort geleden lijkt, maar ik ben er ook heel bewust mee bezig. Vaak switchen van baan en werkgever, op verschillende plekken wonen, meerdere verre reizen per jaar naar nieuwe locaties, hobby's switchen etc. Zo veel mogelijk nieuwe dingen blijven doen en zo min mogelijk in herhaling vervallen. Luister zelfs amper oude muziek.

[Ryur]

Voutloos schreef op maandag 15 januari 2024 @ 12:26:
Iedereen geboren in de 90’s is nog steeds tiener, toch?
Shit, ik word oud.

Ik ben zelf van bouwjaar '91. Voel mij zelf soms ook oud!
Wij krijgen een stagair die is van 2006 ...
Dat je dan al bijna volwassen bent volgens de wet.

Net zoals als iemand aan mij vraagt: 20 jaar geleden, dan denk ik over mijn jeugd, maar dat is al 30 jaar geleden!

[Oon]

Saven schreef op zondag 14 januari 2024 @ 15:24:
[...]

Eens. Hoewel het geen absurd aantal queries is. Ik zie wel eens Wordpress sites met 50+ queries per pagina man man man.

50 is nog niks voor Wordpress, wij hebben ooit een keer (wij als in ik bij een oude werkgever) een WP website moeten maken voor een grote nieuwssite, multi-site netwerk met een hele berg aan plugins. Bleek uiteindelijk dat iedere plugin z'n eigen wp_options queries deed, waar standaard geen enkele index op zat, en die niet gecached werd.

Dat leidde er toe dat zelfs bij een full page cache er tóch nog plugins (die uit de random volgorde init toevallig eerder dan de full page cache plugin in het rijtje zaten) waren die deze aanroepen deden. Bij een gecachete pagina kwamen we op 200-300 queries, bij een realtime pagina waren het er richting de 900, voor iedere pageview.

Toen zijn we zelf maar indexes gaan toevoegen en hebben we gelukkig een manier kunnen vinden om die calls wél te cachen (obv wat hacky regexes om te zien of de keys gecached mochten worden obv een whitelist) want in die tijd was WP nog niet zo ver dat een plugin die override kon doen, maar wat een systeem zeg

Gelukkig was onze db redelijk snel en ging het om hooguit 1-2ms per query na het toevoegen van indexes, maar man man wie dat ooit bedacht heeft moeten ze even een cursus PHP voor dummies geven

[RobertMe]

Ryur schreef op woensdag 17 januari 2024 @ 09:05:
[...]

Ik ben zelf van bouwjaar '91. Voel mij zelf soms ook oud!
Wij krijgen een stagair die is van 2006 ...
Dat je dan al bijna volwassen bent volgens de wet.

Net zoals als iemand aan mij vraagt: 20 jaar geleden, dan denk ik over mijn jeugd, maar dat is al 30 jaar geleden!

12 vond je niet meer "jeugd"? Zou ik daar zelf ook nog onder scharen. Ik vond mij 20 jaar geleden in ieder geval nog jeugdig, en ik ben (maar) 1 jaartje ouder.

[Saven]

Oon schreef op woensdag 17 januari 2024 @ 09:10:
[...]

50 is nog niks voor Wordpress, wij hebben ooit een keer (wij als in ik bij een oude werkgever) een WP website moeten maken voor een grote nieuwssite, multi-site netwerk met een hele berg aan plugins. Bleek uiteindelijk dat iedere plugin z'n eigen wp_options queries deed, waar standaard geen enkele index op zat, en die niet gecached werd.

Dat leidde er toe dat zelfs bij een full page cache er tóch nog plugins (die uit de random volgorde init toevallig eerder dan de full page cache plugin in het rijtje zaten) waren die deze aanroepen deden. Bij een gecachete pagina kwamen we op 200-300 queries, bij een realtime pagina waren het er richting de 900, voor iedere pageview.

Toen zijn we zelf maar indexes gaan toevoegen en hebben we gelukkig een manier kunnen vinden om die calls wél te cachen (obv wat hacky regexes om te zien of de keys gecached mochten worden obv een whitelist) want in die tijd was WP nog niet zo ver dat een plugin die override kon doen, maar wat een systeem zeg

Gelukkig was onze db redelijk snel en ging het om hooguit 1-2ms per query na het toevoegen van indexes, maar man man wie dat ooit bedacht heeft moeten ze even een cursus PHP voor dummies geven

! De tering. Ik weet eigenlijk niet wat ik erger vind Het feit dat een klant dit liet ontwikkelen, dat dit ontwikkeld werd in Wordpress, dat het bedrijf (werkgever) dergelijke kwaliteit van zijn dienst/product blijkbaar prima vindt, of dat niemand heeft gedacht "Wordpress lijkt me niet een goede optie"

Je zult vast blij zijn dat je er niet meer werkt

[Oon]

Saven schreef op woensdag 17 januari 2024 @ 10:42:
[...]

! De tering. Ik weet eigenlijk niet wat ik erger vind Het feit dat een klant dit liet ontwikkelen, dat dit ontwikkeld werd in Wordpress, dat het bedrijf (werkgever) dergelijke kwaliteit van zijn dienst/product blijkbaar prima vindt, of dat niemand heeft gedacht "Wordpress lijkt me niet een goede optie"

Je zult vast blij zijn dat je er niet meer werkt

Dat laatste sowieso, er werden bij dat bedrijf wat twijfelachtige keuzes gemaakt waar ik geen invloed op had.

De klant heeft in dat geval expliciet voor WordPress gekozen omdat er bestaande plugins waren die ze persé wilden gebruiken (zoals een vroege variant van Yoast SEO ) en daar al een duur thema voor hadden aangeschaft (dat wij daarna opnieuw hebben moeten aanschaffen met de correcte licentie ivm multi-site) dus heel veel keuze hadden we niet, maar met de tijd die daar nog extra in is gaan zitten in development en versterken van een zware overkill infrastructuur (laat staan de kosten van de infra) hadden we ze een heel mooi maatwerksysteem kunnen bouwen

[RobIII]

CA1859: Gebruik indien mogelijk betontypen voor verbeterde prestaties

De Engelse versie is duidelijker: CA1859: Use concrete types when possible for improved performance

[Firesphere]

RobIII schreef op vrijdag 19 januari 2024 @ 10:33:
CA1859: Gebruik indien mogelijk betontypen voor verbeterde prestaties

De Engelse versie is duidelijker: CA1859: Use concrete types when possible for improved performance

Hoe harder het beton, hoe beter.

[.oisyn]

Ik ben toch meer van de uittrekseltypes.

[Lethalis]

Ik ben maar eens aan de slag gegaan met Jenkins om iets van continuous integration te krijgen.

Als nu iemand een build sloopt, krijgen we allemaal een mailtje

Eigenlijk moeten we dit nog koppelen met Home Assistant aan een fysiek zwaailicht dat op kantoor staat

[Styxxy]

RobIII schreef op vrijdag 19 januari 2024 @ 10:33:
CA1859: Gebruik indien mogelijk betontypen voor verbeterde prestaties

De Engelse versie is duidelijker: CA1859: Use concrete types when possible for improved performance

"Delen van dit onderwerp zijn mogelijk machinaal vertaald."

[armageddon_2k1]

Laats Hotwire weer herontdekt. Je vraagt je dan af en toe af waar 'we' in frontend land toch allemaal mee bezig zijn met React en consorten.

[mrdemc]

RobIII schreef op vrijdag 19 januari 2024 @ 10:33:
CA1859: Gebruik indien mogelijk betontypen voor verbeterde prestaties

De Engelse versie is duidelijker: CA1859: Use concrete types when possible for improved performance

Die hele omgeving zit vol met vertaalfouten
Deze kwam ik bijv. ook laatst tegen: https://learn.microsoft.c...rsal-print-ready-printers

Met merken als 'Scherpe', 'Broer', 'Triumph-Overwinnen', 'Konica Buitenwereld', 'Konica Terechtkomen', etc.

[RobIII]

mrdemc schreef op vrijdag 19 januari 2024 @ 15:27:
[...]


Die hele omgeving zit vol met vertaalfouten
Deze kwam ik bijv. ook laatst tegen: https://learn.microsoft.c...rsal-print-ready-printers

Met merken als 'Scherpe', 'Broer', 'Triumph-Overwinnen', 'Konica Buitenwereld', 'Konica Terechtkomen', etc.

WTF

[Caelorum]

Daarom ook al jaren deze add-on geïnstalleerd staan https://addons.mozilla.or...ddon/ffs-msdn-in-english/

[dev10]

armageddon_2k1 schreef op vrijdag 19 januari 2024 @ 15:19:
Laats Hotwire weer herontdekt. Je vraagt je dan af en toe af waar 'we' in frontend land toch allemaal mee bezig zijn met React en consorten.

Ik heb wel eens een podcast zitten luisteren van DHH over het hele idee achter Hotwire en wat hun beweegredenen geweest zijn om dit te maken. Hij zegt daarin best wel wat dingen waar een hoop front-enders zich wellicht aangevallen zullen voelen, maar ergens is het zo gek allemaal nog niet.

Het is jammer dat het vooral goed werkt in combinatie met Ruby on Rails en dat de integratie met andere webframeworks wat achter loopt.

[Janoz]

Ach, na dat hele typescript debacle van hem kan ik DHH gewoon onmogelijk serieus nemen.

[DevWouter]

Janoz schreef op maandag 22 januari 2024 @ 13:38:
Ach, na dat hele typescript debacle van hem kan ik DHH gewoon onmogelijk serieus nemen.

Er zijn wel wat meer developers die dat standpunt hebben tegenwoordig. Typescript lost een bepaald probleem op, maar als je nooit dat probleem ervaart dan kan typescript nooit een oplossing zijn.

Zelf ben ik dol op duidelijk types maar harde garanties.

[Sebazzz]

Janoz schreef op maandag 22 januari 2024 @ 13:38:
Ach, na dat hele typescript debacle van hem kan ik DHH gewoon onmogelijk serieus nemen.

Sommige mensen drijven op controverse, zelfs al hebben ze soms wel gelijk.

[Douweegbertje]

Janoz schreef op maandag 22 januari 2024 @ 13:38:
Ach, na dat hele typescript debacle van hem kan ik DHH gewoon onmogelijk serieus nemen.

Heh, jij zegt het nog netjes.

[Falcon]

Lethalis schreef op vrijdag 19 januari 2024 @ 11:19:
Ik ben maar eens aan de slag gegaan met Jenkins om iets van continuous integration te krijgen.

Als nu iemand een build sloopt, krijgen we allemaal een mailtje

Eigenlijk moeten we dit nog koppelen met Home Assistant aan een fysiek zwaailicht dat op kantoor staat

Usb gestuurde laserlampjes op vaste bureaustoel locaties is ook leuk! Op voorhoofd geprojecteerd met daarachteraan een nerfpijltje.

Leuke voor Google Friday in het kader van betere feedback in de pipelines.

Goed ik draaf door

[RagingPenguin]

dev10 schreef op maandag 22 januari 2024 @ 08:42:
[...]


Ik heb wel eens een podcast zitten luisteren van DHH over het hele idee achter Hotwire en wat hun beweegredenen geweest zijn om dit te maken. Hij zegt daarin best wel wat dingen waar een hoop front-enders zich wellicht aangevallen zullen voelen, maar ergens is het zo gek allemaal nog niet.

Het is jammer dat het vooral goed werkt in combinatie met Ruby on Rails en dat de integratie met andere webframeworks wat achter loopt.

Ach ja, tis wel een beetje typisch web-wereldje om elke paar jaar met hetzelfde (en al decenia bestaande) idee op de proppen te komen en net te doen alsof je het gouden ei hebt gevonden.

[RagingPenguin]

DevWouter schreef op maandag 22 januari 2024 @ 17:08:
[...]


Er zijn wel wat meer developers die dat standpunt hebben tegenwoordig. Typescript lost een bepaald probleem op, maar als je nooit dat probleem ervaart dan kan typescript nooit een oplossing zijn.

Zelf ben ik dol op duidelijk types maar harde garanties.

Hoewel er meer dan genoeg TS fans en haters opdoken was de kern van dat debacle imho toch wel de manier waarop die met de community omging.

[Janoz]

RagingPenguin schreef op maandag 22 januari 2024 @ 19:52:
[...]


Hoewel er meer dan genoeg TS fans en haters opdoken was de kern van dat debacle imho toch wel de manier waarop die met de community omging.

Precies, vooral dat laatste. Zo'n framework is leuk voor de hobby, maar je wilt je bedrijfssoftware niet afhankelijk maken van een dergelijke wispelturige kleuter.

[Firesphere]

Lethalis schreef op vrijdag 19 januari 2024 @ 11:19:
Ik ben maar eens aan de slag gegaan met Jenkins om iets van continuous integration te krijgen.

Als nu iemand een build sloopt, krijgen we allemaal een mailtje

Eigenlijk moeten we dit nog koppelen met Home Assistant aan een fysiek zwaailicht dat op kantoor staat

Als ik me niet vergis, heeft Tweakers HQ zo'n soort zwaailicht systeem...

[Firesphere]

mrdemc schreef op vrijdag 19 januari 2024 @ 15:27:
[...]


Die hele omgeving zit vol met vertaalfouten
Deze kwam ik bijv. ook laatst tegen: https://learn.microsoft.c...rsal-print-ready-printers

Met merken als 'Scherpe', 'Broer', 'Triumph-Overwinnen', 'Konica Buitenwereld', 'Konica Terechtkomen', etc.

WTF?
https://learn.microsoft.c...ns#lexmark-cloud-services

CloudServices van Cloud Services van Cloud Services

[.oisyn]

Hoe staat dit?

.edit: prima

[ Voor 40% gewijzigd door .oisyn op 24-01-2024 23:55 ]

[Merethil]

.oisyn schreef op woensdag 24 januari 2024 @ 23:55:
Hoe staat dit?

.edit: prima

Oh nee, je avatar is anders en nu herken ik je niet meer in één oogopslag.... Verandering is stom!

[azerty]

Nee, terug naar de oude! We kunnen niet tegen verandering

[.oisyn]

Ook maar een nickchange erbij dan?

[Voutloos]

Als je met je avatar breekt, kan je net zo goed je account opheffen.

[Janoz]

.oisyn schreef op donderdag 25 januari 2024 @ 13:43:
Ook maar een nickchange erbij dan?

Terug naar OySiN ? In dat geval is eindelijk mijn ocd stress opgelost van de afgelopen decenia..

[.oisyn]

Voutloos schreef op donderdag 25 januari 2024 @ 14:00:
Als je met je avatar breekt, kan je net zo goed je account opheffen.

Mijn avatar is nog steeds hetzelfde poppetje achter een scherm, hij heeft alleen een upgrade gehad

[ Voor 3% gewijzigd door .oisyn op 25-01-2024 14:22 ]

[DaFeliX]

.oisyn schreef op donderdag 25 januari 2024 @ 13:43:
Ook maar een nickchange erbij dan?

Je zou 'ns moeten weten hoe blij ik hier van zou worden

iets met reguliere expressies die rekening moeten houden met 't feit dat sommige usernames niet aan de tegenwoordige restricties voldoen