De Devschuur Coffee Corner - Iteratie ⓬

[gekkie]

Xantios schreef op donderdag 5 september 2019 @ 00:53:
Momenteel ruzie aan het maken met een project in php 5.5 wat in elkaar gehackt is door diverse studenten en externe bureaus uit lage lonen landen (politiek correct toch? )

Door de ongelofelijke hoeveelheid ellende en meuk gaat dit gekke dier regelmatig op z’n gezicht, maar zit ik ook wel bijna elke dag achter mijn scherm te lachen “Oh wauw, dit is.... creatief”

Uiteraard druk bezig om t opnieuw te bouwen, maar hierdoor komen de fuck ups eigenlijk aan de lopende band naar boven.

Sommige bedrijven zijn duidelijk in 2002 blijven hangen

Doop het om in Kunst en je kunt er nog meer geld voor vragen

[Xantios]

gekkie schreef op donderdag 5 september 2019 @ 12:23:
[...]

Doop het om in Kunst en je kunt er nog meer geld voor vragen

Met classes van 3000+ regels (meervoud, want dit gebeurt op meerdere plekken) heeft het al genoeg weg van een Rubens

[Woy]

Hydra schreef op donderdag 5 september 2019 @ 11:11:
[...]


Uitzoomen en een screenshot posten

Zo heb ik hier heel lang geleden al eens eerder een screenshot geplaatst van een gegenereerd DB diagram waar ik tegen aan moest praten

[ElkeBxl]

Woy schreef op donderdag 5 september 2019 @ 13:19:
[...]

Zo heb ik hier heel lang geleden al eens eerder een screenshot geplaatst van een gegenereerd DB diagram waar ik tegen aan moest praten

Heeft het kunstwerk een naam?

[Merethil]

ElkeBxl schreef op donderdag 5 september 2019 @ 13:22:
[...]

Heeft het kunstwerk een naam?

"Pantoffeldiertje in rust"

[ Voor 16% gewijzigd door Merethil op 05-09-2019 13:24 ]

[gekkie]

Het ziet er uit als kantklossen voor gevorderden.

[dasfrikandel]

Visual studio heeft als ontbijt, lunch en Diner werkgeheugen op het menu staan denk ik

[bauke1994]

Woy schreef op donderdag 5 september 2019 @ 13:19:
[...]

Zo heb ik hier heel lang geleden al eens eerder een screenshot geplaatst van een gegenereerd DB diagram waar ik tegen aan moest praten

[Afbeelding]

Zo ziet het er bij ons ook ongeveer uit, echter ontbreken de lijntjes bij ons in veel gevallen.

[Hydra]

Woy schreef op donderdag 5 september 2019 @ 13:19:
[...]

Zo heb ik hier heel lang geleden al eens eerder een screenshot geplaatst van een gegenereerd DB diagram waar ik tegen aan moest praten

[Afbeelding]

Lijkt een beetje op zo'n dromenvanger maar dan eentje die gemaakt is door iemand die flink aan het trippen is

[Douweegbertje]

-- oeps, bad image

[ Voor 87% gewijzigd door Douweegbertje op 06-09-2019 15:02 ]

[.oisyn]

Douweegbertje schreef op donderdag 5 september 2019 @ 21:03:
Kwam laatst ook iemand tegen die een vraagje had over zijn data pipeline..
[Afbeelding]

Ja dat werkt dus niet he, plaatjes linken van Slack.

[ Voor 4% gewijzigd door .oisyn op 05-09-2019 23:17 ]

[armageddon_2k1]

Van staging naar prod en dan is de webapp down. Code is identiek. Backend ook. What de fuck? Na veel gegraaf bleek het een initialisatie volgorde issue te zijn met een builder die voor een Builder pattern gebruikt wordt en als singleton geistantieerd wordt, maar een van de gebruikers van de builder deze nog iets aanpaste.... In staging werd service A altijd eerst aangeroepen die de builder gebruikte, maar in prod service B die de builder aanpaste waardoor A op z'n bek ging.

En dat was donderdag....

Ik begin de case voor immutability steeds beter te begrijpen.

[ Voor 15% gewijzigd door armageddon_2k1 op 05-09-2019 21:19 ]

[R4gnax]

armageddon_2k1 schreef op donderdag 5 september 2019 @ 21:14:
Van staging naar prod en dan is de webapp down. Code is identiek. Backend ook. What de fuck? Na veel gegraaf bleek het een initialisatie volgorde issue te zijn met een builder die voor een Builder pattern gebruikt wordt en als singleton geistantieerd wordt, maar een van de gebruikers van de builder deze nog iets aanpaste.... In staging werd service A altijd eerst aangeroepen die de builder gebruikte, maar in prod service B die de builder aanpaste waardoor A op z'n bek ging.

En dat was donderdag....

Ik begin de case voor immutability steeds beter te begrijpen.

Ik kwam laatst bijna precies hetzelfde geval tijdens een code review tegen en maakte er een punt van.
Kreeg als antwoord: "Ja, maar voorbeeld XYZ doet het ook zo met deze API en ik zie eerlijk gezegd niemand hier aanpassingen op maken, dus ik hou het gewoon zo."

Soms...

[Ed Vertijsment]

zo, beetje gaar van een dag lang tests schrijven, maar goed was wel nodig. #achterstalligonderhoud.

[gekkie]

Heb je de tests ook getest, of moet je daar nog tests voor schrijven ?

[armageddon_2k1]

Mijn tests falen nog wel eens en dan blijkt dat mijn testable code helemaal correct is maar m'n testcode niet....

P.s. Gaan er nog mensen naar Kotlinconf in Kopenhagen?

[ Voor 20% gewijzigd door armageddon_2k1 op 06-09-2019 18:45 ]

[Matis]

Wij hebben (unit) tests welke falen wanneer de start van de test niet in dezelfde minuut valt als de assertions

[armageddon_2k1]

Wait what?

[Voutloos]

Er zijn weinig dingen kwalijker dan tests die om zo’n suffe reden geregeld falen. Is bij mij in ieder geval direct een topturbomegaprio fix.

[Mugwump]

Eventual consistency in integratietesten is ook mateloos irritant. Grotendeels af te vangen door te wachten of polling toe te passen, maar het maakt je tests traag en / of niet 100% betrouwbaar.

[Matis]

armageddon_2k1 schreef op zaterdag 7 september 2019 @ 07:55:
Wait what?

Jups, heeft te maken met onze backup manager. Wij maken een zwik files aan en weten zo, op basis van timestamp, welke er wel en niet in de backup mogen zitten. Als het genereren van de files precies over de "minuut" heen gaat, klopt het aantal bestanden niet meer omdat de backup er meer (of minder, afhankelijk van de criteria) in de zip stopt.

We kunnen de test niet aanpassen zonder onze DUT aan te moeten passen. Dat vinden we sowieso een no-go.

We zouden de test er op aan kunnen passen, maar dan missen we een aantal corner cases.

Duivels dilemma, maar we hebben een weloverwogen beslissing genomen om af en toe de test te laten falen.

[Antrax]

R4gnax schreef op donderdag 5 september 2019 @ 21:23:
Ik kwam laatst bijna precies hetzelfde geval tijdens een code review tegen en maakte er een punt van.
Kreeg als antwoord: "Ja, maar voorbeeld XYZ doet het ook zo met deze API en ik zie eerlijk gezegd niemand hier aanpassingen op maken, dus ik hou het gewoon zo."

Dit.

Waarom is dit zo herkenbaar?

[Grijze Vos]

Woy schreef op donderdag 5 september 2019 @ 13:19:
[...]

Zo heb ik hier heel lang geleden al eens eerder een screenshot geplaatst van een gegenereerd DB diagram waar ik tegen aan moest praten

[Afbeelding]

Hmm, dat maakt mij benieuwd hoe ons databeest eruit ziet als ik zo'n plaatje genereer. Welke tool heb je daarvoor gebruikt? (Gebruiken zelf SQL Server, als ik in SSMS alle tabellen wil toevoegen crasht de tool. ))

[armageddon_2k1]

Woy schreef op donderdag 5 september 2019 @ 13:19:
[...]

Zo heb ik hier heel lang geleden al eens eerder een screenshot geplaatst van een gegenereerd DB diagram waar ik tegen aan moest praten

[Afbeelding]

Nondeju. Mag ik vragen wat voor soort applicatie dit is?

[Woy]

Grijze Vos schreef op zaterdag 7 september 2019 @ 17:27:
[...]

Hmm, dat maakt mij benieuwd hoe ons databeest eruit ziet als ik zo'n plaatje genereer. Welke tool heb je daarvoor gebruikt? (Gebruiken zelf SQL Server, als ik in SSMS alle tabellen wil toevoegen crasht de tool. ))

Destijds heb ik volgens mij gebruik gemaakt van de redgate tools. Destijds waren dat ieder geval hele fijne tools, maar het is al weer heel wat jaren geleden dat ik ze gebruikt heb.

armageddon_2k1 schreef op zaterdag 7 september 2019 @ 21:27:
[...]


Nondeju. Mag ik vragen wat voor soort applicatie dit is?

Het was een management applicatie voor melkveehouders.

[armageddon_2k1]

@Woy had elke koe z'n eigen tabel?

[roemerbakker]

Goedemiddag Tweakers!

Ik ben nieuw op het forum en dit leek mij wel een leuk topic om te beginnen, aangezien ik programmeur ben. Mijn meest recente side-projectje is tot stand gekomen doordat ik vol in de 'firing line' van de Zwanenburgbaan van Schiphol woon. Het is een Telegram botje geschreven in Go die het baangebruik van Schiphol bijhoudt doormiddel aan de hand van info van de Luchtverkeersleiding Nederland (lvnl.nl). Zo weet ik wanneer die herrie eindelijk eens ophoud. Het werkt momenteel prima, en ik zal wanneer alles uitvoerig getest is hier een post maken met de code op Github.

Vraagje, weet iemand heuul toevallig of het ook via de een of andere API mogelijk is om te achterhalen welke baan opstijgende/landende vliegtuigen (zullen gaan) gebruiken? Dat zou de functionaliteit van dit botje aardig opkrikken, aangezien ik dan bij het openen van een baan kan voorspellen wanneer deze ongeveer zal sluiten...

Mvg,
Roemer

[gekkie]

armageddon_2k1 schreef op zondag 8 september 2019 @ 18:02:
@Woy had elke koe z'n eigen tabel?

Table partitioning d'avant la lettre ?
Nog wat nachtjes slapen en dan lijkt partitioning eindelijk aardig feature complete in postgres 12

[Woy]

armageddon_2k1 schreef op zondag 8 september 2019 @ 18:02:
@Woy had elke koe z'n eigen tabel?

Nee, het was verder op zich niet eens een erg verkeerd ontworpen database qua structuur, er was hooguit een beetje overdreven genormaliseerd.

[Mugwump]

gekkie schreef op zondag 8 september 2019 @ 18:50:
[...]

Table partitioning d'avant la lettre ?
Nog wat nachtjes slapen en dan lijkt partitioning eindelijk aardig feature complete in postgres 12

Denk dat een paar collega's van me daar niet op kunnen wachten. Die mochten een mooie desktop app porten naar een web app. Die desktop app deed nog aan ouderwets partitioneren. Gewoon lekker zelf tabellen aanmaken over tijdsperioden en dan parallel queryen op verschillende tabellen. Voor de gebruiker 'lekker snel' want je kunt gewoon de meest recente resultaten eerst tonen.
Dat bleek met Postgres partinioning toch niet helemaal zo te werken.
Nou had ik sowieso lekker gekozen voor iets als Elasticsearch aangezien het vrij platte data betreft die eigenlijk volledig doorzocht moet kunnen worden, maar goed.

[bwerg]

armageddon_2k1 schreef op donderdag 5 september 2019 @ 21:14:
Van staging naar prod en dan is de webapp down. Code is identiek. Backend ook. What de fuck? Na veel gegraaf bleek het een initialisatie volgorde issue te zijn met een builder die voor een Builder pattern gebruikt wordt en als singleton geistantieerd wordt, maar een van de gebruikers van de builder deze nog iets aanpaste.... In staging werd service A altijd eerst aangeroepen die de builder gebruikte, maar in prod service B die de builder aanpaste waardoor A op z'n bek ging.

En dat was donderdag....

Ik begin de case voor immutability steeds beter te begrijpen.

Of de case van geen singletons gebruiken voor zaken waarvoor ze niet geschikt zijn... Singetlon builders klinken als een heel slecht idee.

[armageddon_2k1]

bwerg schreef op zondag 8 september 2019 @ 20:27:
[...]

Of de case van geen singletons gebruiken voor zaken waarvoor ze niet geschikt zijn... Singetlon builders klinken als een heel slecht idee.

Ja dat blijkt Het probleem ligt iets genuanceerder, maar we proberen sowieso actief singletons te vermijden in een webserver omgeving omdat het voor erg lastig te voorspellen gedrag zorgt.

[gekkie]

Mugwump schreef op zondag 8 september 2019 @ 19:44:
[...]
Denk dat een paar collega's van me daar niet op kunnen wachten. Die mochten een mooie desktop app porten naar een web app. Die desktop app deed nog aan ouderwets partitioneren. Gewoon lekker zelf tabellen aanmaken over tijdsperioden en dan parallel queryen op verschillende tabellen. Voor de gebruiker 'lekker snel' want je kunt gewoon de meest recente resultaten eerst tonen.
Dat bleek met Postgres partinioning toch niet helemaal zo te werken.
Nou had ik sowieso lekker gekozen voor iets als Elasticsearch aangezien het vrij platte data betreft die eigenlijk volledig doorzocht moet kunnen worden, maar goed.

Postgres partitioning werkt ansich in de basis al prima in 11, alleen foreign keys was nog de belangrijkste ontbrekende feature wat nu in 12 wel kan. Enige wat ik kan bedenken wat nog echt ontbreekt is een soort eenvoudige trigger om een nieuwe partition aan te maken (bijvb tijdsgebaseerd). Je hebt wel een pg_cron extension, maar echt lekker vond ik dat ook weer niet werken.
Het soms kunnen truncaten van hele partities is ook wel handig ipv moeten deleten van een substantieel deel van de data.

Oja en het indien mogelijk (en niet expliciet gewenst) niet gelijk materialiseren van CTE's is ook wel fijn voor de leesbaarheid, kunnen al te lelijke sub-sub-subqueries die er nog waren ivm performance ook in een CTE geduwd worden.

[ Voor 8% gewijzigd door gekkie op 08-09-2019 22:00 ]

[Koenvh]

Woy schreef op zondag 8 september 2019 @ 19:19:
[...]

Nee, het was verder op zich niet eens een erg verkeerd ontworpen database qua structuur, er was hooguit een beetje overdreven genormaliseerd.

Alles in de zesde normaalvorm?

[ThomasG]

Koenvh schreef op maandag 9 september 2019 @ 11:33:
[...]

Alles in de zesde normaalvorm?

Tabellen voor alle datums e.d. voor het geval ze meer dan eens voorkomen, want niets dubbel opslaan

[Grijze Vos]

Als ik die van onze db genereer kom ik op iets soortgelijks uit. Is ook een db met 992 tabellen, dus dat wil wel.

Als ik echter de 4 meest gebruikte tabellen eruit haal (gebruikers, werkgever, werknemer en nog eentje), wordt het al een stuk overzichtelijker.

Ben nu bezig met het verder proberen af te splitsen van losse services in hun eigen schema's, dus dat wordt in de toekomst wat cleaner hoop ik.

[ThomasG]

Grijze Vos schreef op maandag 9 september 2019 @ 12:07:
*knip*

Ben nu bezig met het verder proberen af te splitsen van losse services in hun eigen schema's, dus dat wordt in de toekomst wat cleaner hoop ik.

En wat makkelijker/efficiënter schaalbaar

[Antrax]

roemerbakker schreef op zondag 8 september 2019 @ 18:43:
[...]

Je kunt het beste een aparte topic in Programming openen.

[Hydra]

Woy schreef op zondag 8 september 2019 @ 19:19:
Nee, het was verder op zich niet eens een erg verkeerd ontworpen database qua structuur, er was hooguit een beetje overdreven genormaliseerd.

code:

koe_table:
- id: INT
- naam: INT

naam_table:
- id: INT

letter_table:
- id: INT
- karakter: CHAR(1)

naam_letter_table:
- id: INT
- naam_id: INT
- letter_id: INT
- order: INT

Zo iets?

Ook belangrijk is het om goed de uiers (1 op 1) en aantal tepels per uier (1 op meer met constraints zo tussen de 1 en 8 gok ik, je weet maar nooit) te modelleren

[plofkip]

^{= spoke too soon =}

[ Voor 82% gewijzigd door plofkip op 10-09-2019 11:46 ]

[Lethalis]

Hydra schreef op dinsdag 10 september 2019 @ 11:25:
[...]

code:

koe_table:
- id: INT
- naam: INT

naam_table:
- id: INT

letter_table:
- id: INT
- karakter: CHAR(1)

naam_letter_table:
- id: INT
- naam_id: INT
- letter_id: INT
- order: INT

Zo iets?

Ook belangrijk is het om goed de uiers (1 op 1) en aantal tepels per uier (1 op meer met constraints zo tussen de 1 en 8 gok ik, je weet maar nooit) te modelleren

Als we dan toch al bezig zijn, vergeet de privacywetgeving niet.

Koeien hebben ook behoefte aan privacy! Niet eens een UUID gebruikt om een koe te identificeren

Sowieso moeten gegevens over de uiers en tepels in een aparte database staan en niet direct herleidbaar zijn naar de koe.

[ThomasG]

Lethalis schreef op dinsdag 10 september 2019 @ 12:13:
[...]

Als we dan toch al bezig zijn, vergeet de privacywetgeving niet.

Koeien hebben ook behoefte aan privacy! Niet eens een UUID gebruikt om een koe te identificeren

Sowieso moeten gegevens over de uiers en tepels in een aparte database staan en niet direct herleidbaar zijn naar de koe.

Gelukkig leven koeien nog niet in een politiestaat

spoiler:

[Hydra]

Lethalis schreef op dinsdag 10 september 2019 @ 12:13:
Sowieso moeten gegevens over de uiers en tepels in een aparte database staan en niet direct herleidbaar zijn naar de koe.

Da's wel een punt ja. Valt volgens Domain Driven Design de tepel onder de root-aggregate Koe of is het een eigen root-aggregate? Je weet nooit of je nog eens je domain gaat verbreden om ook de boerin erin te vangen...

Ik zat overigens verkeerd met m'n koe-uier 1:1, het is 1:0-1 natuurlijk...

[ThomasG]

Hydra schreef op dinsdag 10 september 2019 @ 13:17:
[...]

Ik zat overigens verkeerd met m'n koe-uier 1:1, het is 1:0-1 natuurlijk...

Nee, 1:0-1 is fout; 1:1 was goed. Alle koeien hebben uiers, want een koe is namelijk vrouwelijk rund. Een stier is geen koe.

[PrisonerOfPain]

Koenvh schreef op zaterdag 31 augustus 2019 @ 12:33:
@CurlyMo Rust is altijd het beste gereedschap

Ik gebruik nu Rust al anderhalf jaar fulltime als game developer, en ik heb iig de neiging zo ver mogelijk van C++ vandaan te blijven ontwikkeld. Wat een verademing.

[Gropah]

Das allemaal heel leuk, die uier database. Maar hebben jullie er al over nagedacht dat er ook bijgehouden moet worden hoeveel melk een koe produceert? Wat het vetpercentage per unit melk is? En dat de melk van een koe die recent medicijnen heeft gehad, niet in de verkoop mag?

[Hydra]

Gropah schreef op dinsdag 10 september 2019 @ 13:47:
Das allemaal heel leuk, die uier database. Maar hebben jullie er al over nagedacht dat er ook bijgehouden moet worden hoeveel melk een koe produceert? Wat het vetpercentage per unit melk is? En dat de melk van een koe die recent medicijnen heeft gehad, niet in de verkoop mag?

We developen dit agile he, we zijn de komende 6 springs met tepels bezig. Dan komt je melk aan de beurt, da's niet onderdeel van het MVP.

[Gropah]

Hydra schreef op dinsdag 10 september 2019 @ 13:52:
[...]


We developen dit agile he, we zijn de komende 6 springs met tepels bezig. Dan komt je melk aan de beurt, da's niet onderdeel van het MVP.

Maar jongens, wie is de product owner? Want het kan toch niet dat het verkoopbare deel van deze koeien pas over 6 sprints, misschien eens behandeld gaat worden?!?!?!

[Hydra]

Gropah schreef op dinsdag 10 september 2019 @ 13:55:
Maar jongens, wie is de product owner? Want het kan toch niet dat het verkoopbare deel van deze koeien pas over 6 sprints, misschien eens behandeld gaat worden?!?!?!

Berta. Ze is domein expert. De laatste keer dat ik haar naar de prio's vroeg stond ze me blanco aan te staren en bleef ze d'r lunch herkauwen.

[Woy]

Hydra schreef op dinsdag 10 september 2019 @ 13:17:
[...]
Da's wel een punt ja. Valt volgens Domain Driven Design de tepel onder de root-aggregate Koe of is het een eigen root-aggregate?

Sowieso zit je al verkeerd dat Koe een root-aggregate was, dat was namelijk Dier

Gropah schreef op dinsdag 10 september 2019 @ 13:47:
Das allemaal heel leuk, die uier database. Maar hebben jullie er al over nagedacht dat er ook bijgehouden moet worden hoeveel melk een koe produceert? Wat het vetpercentage per unit melk is? En dat de melk van een koe die recent medicijnen heeft gehad, niet in de verkoop mag?

Die gegevens zaten inderdaad allemaal in die database

[ Voor 40% gewijzigd door Woy op 10-09-2019 14:18 ]

[armageddon_2k1]

PrisonerOfPain schreef op dinsdag 10 september 2019 @ 13:33:
[...]


Ik gebruik nu Rust al anderhalf jaar fulltime als game developer, en ik heb iig de neiging zo ver mogelijk van C++ vandaan te blijven ontwikkeld. Wat een verademing.

Interessant. Wat voor soort 'dingen' ontwikkel je dan? Ik weet dat jij ooit aan de Frostbite engine hebt gewerkt. Dus wat is de schaal waarop je het gebruikt (fulltime impliceert fors) en wat ben je zoal tegengekomen?

[.oisyn]

Oh god ze zijn hier ook al besmet met het Rust virus.

[Mugwump]

.oisyn schreef op dinsdag 10 september 2019 @ 14:44:
Oh god ze zijn hier ook al besmet met het Rust virus.

Het wordt tijd dat iemand Cola ontwikkelt. Dat schijnt te helpen tegen Rust.

[Jegorex]

Mugwump schreef op dinsdag 10 september 2019 @ 14:54:
[...]


Het wordt tijd dat iemand Cola ontwikkelt. Dat schijnt te helpen tegen Rust.

En daarna een Cola++?

[Tjolk]

ObjectiveCoke FTW

[Hydra]

.oisyn schreef op dinsdag 10 september 2019 @ 14:44:
Oh god ze zijn hier ook al besmet met het Rust virus.

Go is niet hip meer

Heb zelf onlangs de C++ primer aangeschaft. *flex*

En alles beter dan PHP

[ Voor 8% gewijzigd door Hydra op 10-09-2019 16:19 ]

[Koenvh]

.oisyn schreef op dinsdag 10 september 2019 @ 14:44:
Oh god ze zijn hier ook al besmet met het Rust virus.

Mijn fiets in ieder geval wel. Begonnen met Metal, maar toen toch maar overgegaan op Rust

[armageddon_2k1]

In Rust heb je de hele koe discussie niet nodig van hierboven je hebt gewoon een type daarvoor:
Cow

[Mugwump]

armageddon_2k1 schreef op dinsdag 10 september 2019 @ 17:44:
In Rust heb je de hele koe discussie niet nodig van hierboven je hebt gewoon een type daarvoor:
Cow

Je kunt nog een koe maken van plakjes ook zo te lezen, omgekeerde wereld.

[gekkie]

Mugwump schreef op dinsdag 10 september 2019 @ 14:54:
[...]
Het wordt tijd dat iemand Cola ontwikkelt. Dat schijnt te helpen tegen Rust.

Zou het inderdaad maar niet inchecken met git-cola

[PrisonerOfPain]

armageddon_2k1 schreef op dinsdag 10 september 2019 @ 14:18:
[...]


Interessant. Wat voor soort 'dingen' ontwikkel je dan? Ik weet dat jij ooit aan de Frostbite engine hebt gewerkt. Dus wat is de schaal waarop je het gebruikt (fulltime impliceert fors) en wat ben je zoal tegengekomen?

Vooral als research project word het gebruikt, we hebben er van alles mee proberen uit te zoeken maar hoofdzakelijk als graphics framework om sneller te kunnen itereren dan in de grote engine. Het is relatief snel om wat dingen aan elkaar te maken, uit te testen / te bewijzen en dan over te zetten naar Frostbite. We hebben naast graphics ook entity component systems en asset build systemen (als micro services) ontwikkeld.

[gekkie]

Urghh je kunt python irritant vinden met z'n geforceerde whitespace meuk, maar ik krijg nu toch behoorlijk de schijt van golang wat forceert dat je niets "unused" kunt laten. Ik wil even snel een paar dingen uitcommenten, maar nee .. ga maar lekker alles lang en comment ALLES uit wat er ook maar remote mee te maken heeft.
So much voor de "introduction to go ...." wat voelt als "go away ...".

[ThomasG]

gekkie schreef op woensdag 11 september 2019 @ 14:50:
Urghh je kunt python irritant vinden met z'n geforceerde whitespace meuk, maar ik krijg nu toch behoorlijk de schijt van golang wat forceert dat je niets "unused" kunt laten. Ik wil even snel een paar dingen uitcommenten, maar nee .. ga maar lekker alles lang en comment ALLES uit wat er ook maar remote mee te maken heeft.
So much voor de "introduction to go ...." wat voelt als "go away ...".

blank idenfitier (_)

[Gropah]

ThomasG schreef op woensdag 11 september 2019 @ 14:53:
[...]
blank idenfitier (_)

Of een propere IDE gebruiken die herkent dat iets niet meer gebruikt om hem vervolgens automagisch uit de import lijst te halen (en weer toe te voegen wanneer je de regels uncomment)

[ThomasG]

Gropah schreef op woensdag 11 september 2019 @ 14:56:
[...]


Of een propere IDE gebruiken die herkent dat iets niet meer gebruikt om hem vervolgens automagisch uit de import lijst te halen (en weer toe te voegen wanneer je de regels uncomment)

Dat hangt er maar net vanaf. Soms wil je gewoon even een regel uit commentariëren, bijvoorbeeld tijdens het debuggen. Dan is het niet altijd wenselijk als het vervolgens de rest ook gaat aanpassen, omdat het anders unused is.

[gekkie]

Gropah schreef op woensdag 11 september 2019 @ 14:56:
[...]


Of een propere IDE gebruiken die herkent dat iets niet meer gebruikt om hem vervolgens automagisch uit de import lijst te halen (en weer toe te voegen wanneer je de regels uncomment)

Mjah maar even 1 regel outcommenten zit er dan weer niet in .. want ja die variabele een stuk daar boven is nu useless .. en zo cascade dat lekker door. Tot je inderdaad bij je niet gebruikte imports uit komt.
Mooi getest .. kun je daarna alles weer aanmikken.

Ohhhhh i'm so grumpy dat zelfs sommige cat-pics dat niet kunnen evenaren.

[bwerg]

Ja, daar zijn dus warnings voor uitgevonden... Iets met wielen uitvinden.

[.oisyn]

bwerg schreef op woensdag 11 september 2019 @ 15:41:
Ja, daar zijn dus warnings voor uitgevonden... Iets met wielen uitvinden.

quote: https://golang.org/doc/faq#unused_variables_and_imports

Some have asked for a compiler option to turn those checks off or at least reduce them to warnings. Such an option has not been added, though, because compiler options should not affect the semantics of the language and because the Go compiler does not report warnings, only errors that prevent compilation.

There are two reasons for having no warnings. First, if it's worth complaining about, it's worth fixing in the code. (And if it's not worth fixing, it's not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed.

Waanzin.

[bwerg]

.oisyn schreef op woensdag 11 september 2019 @ 16:03:
[...]


[...]

Waanzin.

Pfff, mooi theoretisch onzinnig geneuzel.

Niks tegen theoretisch geneuzel, hoor. Ik ben een groot liefhebber van theoretisch geneuzel. Maar dan wel zinnig, graag.

Go schreef:
The presence of an unused variable may indicate a bug, while unused imports just slow down compilation, an effect that can become substantial as a program accumulates code and programmers over time. For these reasons, Go refuses to compile programs with unused variables or imports, trading short-term convenience for long-term build speed and program clarity.

En daarvoor heb je dus -Werror.

[ Voor 42% gewijzigd door bwerg op 11-09-2019 16:32 ]

[gekkie]

Valt me nog mee dat ze nog niet beredeneerd hebben dat een "rm -rf /" nuttig zou zijn .. voldoet in iedergeval ook aan de "prevents further compilation" .

[.oisyn]

bwerg schreef op woensdag 11 september 2019 @ 16:22:
En daarvoor heb je dus -Werror.

Of gewoon golint, waar dit soort checks gewoon in thuishoren

[kenneth]

Rob fucking Pike die weet wat goed voor je is

[Koenvh]

Een error zou echt moeten betekenen dat er iets staat wat echt niet compileert, niet iets wat niet zo mooi is, daar gooi je maar een warning voor. Maar mijn filosofie en de belerende filosofie van Go staan sowieso ver uit elkaar. Ik wil gewoon een hakmes waar ik ook m'n eigen benen mee af kan hakken, niet een plastic mesje waar je nauwelijks een boterham mee doormidden krijgt.

[ Voor 24% gewijzigd door Koenvh op 11-09-2019 18:01 ]

[PrisonerOfPain]

.oisyn schreef op woensdag 11 september 2019 @ 16:03:
[...]


[...]

Waanzin.

Ben ik even blij dat ik die taal compleet links heb laten liggen...

[gekkie]

Naja wel een mea culpa .. op zich staat het gedrag netjes in de documentatie op why-golang-sucks
So I should have known ...

[Koenvh]

Overigens kun je wel smerige dingen doen in Go als je echt wilt
https://codegolf.stackexc...uage-unusable/95061#95061

[gekkie]

De workaround is dus gewoon in een if false {} wrappen ... zolang het maar geused wordt in dead code is alles pico bello in orde.

[ThomasG]

gekkie schreef op woensdag 11 september 2019 @ 19:24:
De workaround is dus gewoon in een if false {} wrappen ... zolang het maar geused wordt in dead code is alles pico bello in orde.

Beetje raar van go dat ze wel een error hebben op unused variables, maar niet op dead code..

[RayNbow]

inb4 dead code = error?

[Kalentum]

Koenvh schreef op woensdag 11 september 2019 @ 19:13:
Overigens kun je wel smerige dingen doen in Go als je echt wilt
https://codegolf.stackexc...uage-unusable/95061#95061

Bedankt! Ik kwam dit tegen https://codegolf.stackexchange.com/a/61466

Shakespeare Programming Language!
https://artificialcogniti...-programming-language-spl

[gekkie]

rutgerw schreef op woensdag 11 september 2019 @ 20:47:
[...]


Bedankt! Ik kwam dit tegen https://codegolf.stackexchange.com/a/61466

Shakespeare Programming Language!
https://artificialcogniti...-programming-language-spl

Op zich wel mooi dat je dan in een hoop bedrijven middels prachtige proza een volledig functionele rant kunt maken ..

[Douweegbertje]

Ik zit weer te kloten met data zeg. Een JSON dataset die soms velden wel/niet heeft en velden die soms null zijn. Ik wil dat weer in een in strictere taal/format hebben (avro). Gaat het natuurlijk weer helemaal mis met die nullable fields. Met avro kan ik dan nog wel een soort union type map doen, alleen dan moet ik als eerste entry een null "datatype" meegeven en bijv. een string als tweede. Als mijn data geen null is, dan expliciet in de json iets doen als "foo" : { "string" : "bar" }. Onder de noemer dat hij anders niet weet dat het een string is.

Ik snap gewoon niet dat een "leeg" c.q. null veld niet iets is wat "logisch" zou zijn. Er zijn toch prima use-cases te beschrijven waarbij een result bepaalde data niet heeft. Dat het dan gewoon lekker null is. Of ben ik nu fout aan het redeneren.

[bwerg]

Er zijn ook prima use-cases te bedenken waarin iemands auto stuk is en hij dus vandaag met de fiets gaat maar dan is het nog niet handig om een fiets in te vullen in een veld waar je een auto verwacht.

[Matis]

Pff, ik ben vandaag weer met een stukje monnikenwerk bezig.

We hebben de afgelopen weken gewerkt aan een nieuwe importer om productfeeds van een nieuwe supplier aan te sluiten. Op dit moment is alles qua ontwikkeling klaar en zijn we in de functionele / integratie-test gekomen.

Dit houdt in dat we alle files met producten van de supplier gaan inlezen. In totaal 175 files met een slordige 200.000 producten.

Nu moet ik iedere keer handmatig het commando starten om een nieuwe file in te lezen. Mocht de importer ergens crashen dan moet ik de foutmelding opschrijven en de bijbehorende filename welke stuk ging.
Daarna kan ik bovenstaande herhalen totdat all 175 files zijn afgewerkt. Gelukkig gaat de importer wel automatisch verder wanneer er een bestand volledig succesvol is verwerkt, maar toch. Op dit moment al 37 foutmeldingen Nog 60 files te gaan...


Edit; ik heb het overwogen om te scripten, maar dat zou me uiteindelijk meer tijd kosten (denk ik) dan op deze manier. Hopelijk hoeven we maar 1 iteratie te doen en kunnen we aan het einde van de dag alle bugs inventariseren, zo snel mogelijk fixen en hopelijk zijn dan alle kinken uit de kabel.

[ Voor 14% gewijzigd door Matis op 12-09-2019 11:56 ]

[Olaf van der Spek]

Matis schreef op donderdag 12 september 2019 @ 11:55:
Edit; ik heb het overwogen om te scripten, maar dat zou me uiteindelijk meer tijd kosten (denk ik) dan op deze manier. Hopelijk hoeven we maar 1 iteratie te doen en kunnen we aan het einde van de dag alle bugs inventariseren, zo snel mogelijk fixen en hopelijk zijn dan alle kinken uit de kabel.

Gaan jullie dat in productie ook elke keer handmatig doen?

[Matis]

Olaf van der Spek schreef op donderdag 12 september 2019 @ 12:05:
Gaan jullie dat in productie ook elke keer handmatig doen?

Ja, feitelijk gebeurt dat op deze manier ook al op productie.

Wanneer er een importer stuk loopt, wordt er via Slack een berichtje gestuurd. Hierin wordt dan aangegeven welke importer voor welke supplier vast is gelopen. Dan kunnen we, desgewenst, het probleembestand lokaal downloaden en dan lokaal testen / fixen, valideren, deployen en het bestand opnieuw aanbieden voor de importer.

Maar door dit nu de eerste keren handmatig te doen op mijn lokale omgeving, schiften we al heel veel problemen op ACC en daarna PROD.

[dovo]

Op het werk ben ik een parel van een vendor tegengekomen. Weer zo een casus van _extreme agile containerized cloud native digital application_ buzzword facade, terwijl de achterkant een complete puinhoop is.

Zo goed als alles waar cloud native voor staat doen ze volledig het tegenovergestelde. Niet echt een idee waarom, maar ze pakken heel de tijd uit dat hun python2.6 code in docker steken alles heeft opgelost en dat het de geweldigste architecturele vooruitgang is. Echter draaien alle dockertjes met host networking, gebruiken ze vaak 1000+ lijnen entypoint bash scripts en installeren ze een kernelmodule vanuit docker - want docker is het ultieme product. Resultaat: applicatie is super bagger, debugging is een hel, ligt er constant uit ...

Bugs oplossen duurt 3-6 maanden ( tot zover extreme agile ), en vereist vaak escalaties tot departement manager zodat vendor ons serieus neemt.

Ik krijg het echt van al die mensen die cloud native schreeuwen van de daken, maar niet doorhebben dat hun python2 code migreren en tal van deze "los dat eerst op" zaken belangrijker zijn. Heel die zooi draait op 3 * dual xeon gold met 360ish Gb ram etc. en wanneer ik meer dan twee api calls per seconde doe flapt het systeem eruit, durft de vendor nog te zeggen dat ik zo snel hun api niet mag aanspreken, want als je de uberslome gui gebruikt heb je deze problemen niet.

Momenteel in Go een library aan het schrijven die hun onstabiele API wrapped. Eens zien wat dat zal opleveren, en of dit het product bruikbaar kan maken.

[Mugwump]

Gelukkig is Python 2 eind dit jaar EOL. Niet dat men zich daar wat van aan zal trekken.

[Sandor_Clegane]

dovo schreef op donderdag 12 september 2019 @ 16:32:
Op het werk ben ik een parel van een vendor tegengekomen. Weer zo een casus van _extreme agile containerized cloud native digital application_ buzzword facade, terwijl de achterkant een complete puinhoop is.

Zo goed als alles waar cloud native voor staat doen ze volledig het tegenovergestelde. Niet echt een idee waarom, maar ze pakken heel de tijd uit dat hun python2.6 code in docker steken alles heeft opgelost en dat het de geweldigste architecturele vooruitgang is. Echter draaien alle dockertjes met host networking, gebruiken ze vaak 1000+ lijnen entypoint bash scripts en installeren ze een kernelmodule vanuit docker - want docker is het ultieme product. Resultaat: applicatie is super bagger, debugging is een hel, ligt er constant uit ...

Bugs oplossen duurt 3-6 maanden ( tot zover extreme agile ), en vereist vaak escalaties tot departement manager zodat vendor ons serieus neemt.

Ik krijg het echt van al die mensen die cloud native schreeuwen van de daken, maar niet doorhebben dat hun python2 code migreren en tal van deze "los dat eerst op" zaken belangrijker zijn. Heel die zooi draait op 3 * dual xeon gold met 360ish Gb ram etc. en wanneer ik meer dan twee api calls per seconde doe flapt het systeem eruit, durft de vendor nog te zeggen dat ik zo snel hun api niet mag aanspreken, want als je de uberslome gui gebruikt heb je deze problemen niet.

Momenteel in Go een library aan het schrijven die hun onstabiele API wrapped. Eens zien wat dat zal opleveren, en of dit het product bruikbaar kan maken.

In dit geval slaat Agile op de klant.

[gekkie]

Mugwump schreef op donderdag 12 september 2019 @ 18:32:
Gelukkig is Python 2 eind dit jaar EOL. Niet dat men zich daar wat van aan zal trekken.

Nah het beestje is gewrapped in go en contained in docker .
Als je bent kun je er altijd nog 10 wietplantjes mee bewaken

[Voutloos]

PHP internals is weer smullen vandaag.

Het stemmen op RFC https://wiki.php.net/rfc/engine_warnings is net begonnen. En oudgediende Zeev moet in dictator-toon melden dat dit niet met een RFC kan. :'D https://externals.io/message/106963

Zorg dan gewoon met argumenten dat 1/3e tegen is.

[dovo]

Mugwump schreef op donderdag 12 september 2019 @ 18:32:
Gelukkig is Python 2 eind dit jaar EOL. Niet dat men zich daar wat van aan zal trekken.

Er zal geen migratie naar python3 gebeuren is hun antwoord, ze beweren naar Go te migreren, maar hun experimentele repo waar dit in zit is een boeltje, en de main dev die commits deed is een half jaar geleden naar google vertrokken. Omdat ze gebaseerd zijn op zo een van die kei vage enterprise XML schema architecturen hebben ze ergens in 2012 generateDS.py geforked en nooit geupdatet naar de python3 compatible versie. Hun hele architectuur is dus zo brak tot wortel en een rewrite is de enige oplossing. Maar dat brengt natuurlijk geen bonus in het laatje bij management, dus blijven ze maar alle problemen met hun product naar ons - de kant - doorschuiven. Ik denk dat zij ervan uitgaan dat zolang ze centos7 blijven gebruiken ze nog 5 jaar safe zijn met python2.

Ze gebruiken bijvoorbeeld ook Cassandra om alle data bij te houden, niet omdat Cassandra de juiste database was, de data vereist een ACID compliant database. Ik vermoed dat ze voor Cassandra kozen omdat een of andere zelfverklaarde expert daar een veto heeft getrokken. Als je dus queries op de API loslaat krijg je meestal errors omdat er concurrency/race conditions ontstaan. Door de loadbalancer te skippen, en een van de backend servers direct aan te spreken, kan je alvast een lagere error rate krijgen.

Ik snap gewoon niet hoe dit allemaal kan, in mijn eerste jaar bachelor heb ik professionelere php5 projecten gezien door klasgenoten en die gebruikten nergens input sanitation.

Leuk om deze topic te lezen. Ik dacht dat ik de enige was die niet geobsedeerd is van Dockerize everything en dat Docker vreselijke en obsolete software architecturen maar zal oplossen.

[armageddon_2k1]

@dovo Ik snap echt niet hoe je conclusie kan zijn dat Docker het probleem is hier?

Je noemt een lijst met enorme faals op van de externe partij en dan gaat je laatste alinea over dat je niet onder de indruk bent van Docker.

Right tools for the job enzo en shit in equals shit out. Docker en Kubernetes werkt bij ons geniaal.

[ Voor 59% gewijzigd door armageddon_2k1 op 12-09-2019 21:35 ]

[dovo]

armageddon_2k1 schreef op donderdag 12 september 2019 @ 21:33:
@dovo Ik snap echt niet hoe je conclusie kan zijn dat Docker het probleem is hier?

Docker is niet het probleem, het probleem is dat mensen denken dat Docker de oplossing voor alle andere problemen is door enkel Docker toe te voegen aan het probleem.

[armageddon_2k1]

Prima, maar dat geldt voor letterlijke elke techniek die je tegen die shitpile die jij zojuist beschreven hebt gooit.

[Alex)]

Het enige wat Docker hier 'toevoegt' is dat je een image deployt (of een docker-compose.yml) en dat je niet direct ziet wat er allemaal achter de schermen gebeurt om het überhaupt werkend te krijgen.

Als je een zooitje .py-files had gekregen en een installatiehandleiding van 5 kantjes had je waarschijnlijk gezegd "dit is te complex". Nu heb je dat niet.

[gekkie]

Voutloos schreef op donderdag 12 september 2019 @ 20:54:
PHP internals is weer smullen vandaag.

Het stemmen op RFC https://wiki.php.net/rfc/engine_warnings is net begonnen. En oudgediende Zeev moet in dictator-toon melden dat dit niet met een RFC kan. :'D https://externals.io/message/106963

Zorg dan gewoon met argumenten dat 1/3e tegen is.

Een not so benevolent dictator for life .

Aan de andere kant een potentiele python2/3 in the making. Hoeft op zich niet verkeerd te zijn, maar als je het doet is het wel verstandig om te kijken of je dan niet in één keer een aantal van je zwakheden kunt opruimen ipv maar eentje.

[dovo]

armageddon_2k1 schreef op donderdag 12 september 2019 @ 21:33:
Je noemt een lijst met enorme faals op van de externe partij en dan gaat je laatste alinea over dat je niet onder de indruk bent van Docker.

Right tools for the job enzo en shit in equals shit out. Docker en Kubernetes werkt bij ons geniaal.

Van Docker zelf ben ik tamelijk tevreden. De hele doe alles in docker hype echter niet. Mijn wordpress blog staat gewoon op een shared hosting server, dat werkt prima en ik zie ook geen reden om dat in Docker of Kubernetes te steken. Mijn plex op mijn nas thuis draait tevens ook gewoon als binary en niet in Docker. Voor mij valt dit onder the right tool for the job.

Wanneer je echter een product/software/saas ontwikkeld dat aan een CI/CD pipeline hangt, en changes binnen de twee dagen naar productie wil kunnen sturen in een consistente manier of snel moet kunnen scalen, dan is kubernetes interessant. Kubernetes heeft nog wel serieuze tekortkomingen zoals zeer gelimiteerde ipv6 support, maar door middel van een CDN of loadbalancer als in GCP kan je dat vandaag opvangen.

Zelf gebruiken wij docker runners gekoppeld aan gitlab voor test automation en building, en dat werkt fantastisch. Docker draait hier gewoon ipv6 dual stack zonder problemen (1 lijn code in router, 2 in /etc/docker/daemon.json).

[armageddon_2k1]

Maar echt niemand forceert je toch om je WP site in Docker te hangen? Heeft dat gesprek überhaupt plaatsgevonden?

[kenneth]

armageddon_2k1 schreef op donderdag 12 september 2019 @ 21:33:
@dovo Ik snap echt niet hoe je conclusie kan zijn dat Docker het probleem is hier?

Ik snap niet hoe jouw conclusie kan zijn dat zijn conclusie is dat Docker het probleem is

Toegegeven, het is niet de mooiste zin die in ons taalgebied is geproduceerd maar hij bekritiseert Docker niet, alleen hoe Docker wordt gebruikt om brakke producten mee op te kalefateren (wat, verbazingwekkend, niet werkt).