De Devschuur Coffee Corner - Iteratie ⓫

[Tarkin]

Dus je gaat eerst je implementatie schrijven, dat manueel testen en als dat allemaal goed werkt ga je testen schrijven?

Is het dan niet veel simpeler om eerst je test te schrijven, dan je implementatie (en zorgen dat je test groen is) en indien die weerkerende cycle volledig is, éénmalig manueel testen? Veel sneller volgens mij. en ook veel robuuster. door test first te werken zorg je er ook voor dat je nadenkt over je implementatie. iets wat niet gebeurt als je achteraf testen schrijft, dan test je gewoon af wat je al geschreven hebt.

[CodeCaster]

Tarkin schreef op woensdag 20 september 2017 @ 15:08:
Afgezien van je stijl moet ik je deze keer helemaal gelijk geven Hydra.

Met de stelling komen dat je in een greenfield project niet kan testen. Wanneer kan je dan wel in godsnaam testen?

En testen moeten niet geschreven worden als de code al bestaat, dan ben je nl legacy shit aan het testen en daar klaag je ook over Testen moeten vooraf geschreven worden. TDD first!

Wat ik bedoel is dat er een aanvraag komt à la "Bouw maar een API die dit-en-dat object exposed aan andere teams, met ongeveer deze operaties". Dan kun je fijn TDD, BDD, whatever gaan werken, maar de eerste de beste versie die je laat zien aan het implementerende team wordt afgeschoten omdat zij op basis van het gebruiken ervan pas kunnen bedenken hoe ze het precies willen gaan gebruiken.

Daar zit je dan met je tests die je software perfect afdekken, maar met je software die niet voldoet aan de vraag van de consumers.

En ja, dat is een plannings- en specificatieprobleem, absoluut.

[Styxxy]

Tarkin schreef op woensdag 20 september 2017 @ 15:52:
Dus je gaat eerst je implementatie schrijven, dat manueel testen en als dat allemaal goed werkt ga je testen schrijven?

Is het dan niet veel simpeler om eerst je test te schrijven, dan je implementatie (en zorgen dat je test groen is) en indien die weerkerende cycle volledig is, éénmalig manueel testen? Veel sneller volgens mij. en ook veel robuuster. door test first te werken zorg je er ook voor dat je nadenkt over je implementatie. iets wat niet gebeurt als je achteraf testen schrijft, dan test je gewoon af wat je al geschreven hebt.

Neen. Schrijven code en unit tests samen. De ene schrijft eerst zijn unit test en dan code, de andere omgekeerd (waarbij zo goed als iedereen eerder eerst code maakt en dan unit tests). Het pure TDD idiom doe ik niet; maar ik ontwikkel wel samen met unit tests.

Vaak teken ik eerst het systeem uit, dan schrijf ik code en als ik tevreden ben van mijn code maak ik daar tests op. Je moet niet op voorhand unit tests schrijven hoor...

[Hydra]

CodeCaster schreef op woensdag 20 september 2017 @ 15:54:
Wat ik bedoel is dat er een aanvraag komt à la "Bouw maar een API die dit-en-dat object exposed aan andere teams, met ongeveer deze operaties". Dan kun je fijn TDD, BDD, whatever gaan werken, maar de eerste de beste versie die je laat zien aan het implementerende team wordt afgeschoten omdat zij op basis van het gebruiken ervan pas kunnen bedenken hoe ze het precies willen gaan gebruiken.

Ik maak altijd eerst een service die canned responses teruggeeft voordat ik ga implementeren. Die kunnen ze reviewen en ondertussen bouw ik de tussenliggende lagen. Dat valt prima te combineren. Daarbij; je bepaalt toch samen hoe zo'n API eruit moet zien? Klinkt een beetje als een gevalletje over de muur smijten van requirements en dan achteraf klagen als het niet werkt.

Als je dan naderhand iets over 't hoofd gezien hebt; prima. Maar het grootste deel van wat het moet doen hebben we afgetimmerd. En als Pietje later bedenkt dat 'ie in plaats van een naam aparte voornaam / achternaam velden wil; prima. Dat reworken we dan wel.

En ja, het is gewoon een specificatieprobleem. Ik bespeur aan zowel jouw kant als (vooral) aan de kant van de anderen een soort "ik weet het ook niet meer" gemixt met een gezonde dosis "fuck it". Te veel mensen die te lang op dezelfde plek zitten. Het is ook lastig om je druk te maken over kwaliteit als je de enige bent in een organisatie.

[ThomasG]

Styxxy schreef op woensdag 20 september 2017 @ 15:55:
[...]

Neen. Schrijven code en unit tests samen. De ene schrijft eerst zijn unit test en dan code, de andere omgekeerd (waarbij zo goed als iedereen eerder eerst code maakt en dan unit tests). Het pure TDD idiom doe ik niet; maar ik ontwikkel wel samen met unit tests.

Vaak teken ik eerst het systeem uit, dan schrijf ik code en als ik tevreden ben van mijn code maak ik daar tests op. Je moet niet op voorhand unit tests schrijven hoor...

Maar dat is handig. Stel je maakt een Comparator, dan kun je die al testen voordat je hem daadwerkelijk implementeert. In principe is van alles bekend wat het moet doen, en juist niet. Ik kom er bij mijn unit tests vaak achter dat ik niet helemaal tevreden ben, of een ontwerpfout aan het maken ben. En dan is het dus prettig als ik daar vroeg achter kom.

[CodeCaster]

ThomasG schreef op woensdag 20 september 2017 @ 16:06:
[...]
Maar dat is handig. Stel je maakt een Comparator, dan kun je die al testen voordat je hem daadwerkelijk implementeert. In principe is van alles bekend wat het moet doen, en juist niet. Ik kom er bij mijn unit tests vaak achter dat ik niet helemaal tevreden ben, of een ontwerpfout aan het maken ben. En dan is het dus prettig als ik daar vroeg achter kom.

En we hebben het hier over een niveau of tig hoger.

Natuurlijk kun je een string splitter, een regex of een comparator die wat properties van een object vergelijkt prima unittesten. Je kunt de positieve en negatieve inputs op een bierviltje kwijt en voilá, je testcases.

Het probleem waar het hier om gaat is slecht omschreven business requirements. Volledige applicaties die worden gebouwd op basis van een omschrijving van één regel, in een mailtje, of zo je wil, een bierviltje.

In plaats van dat men gaat steigeren en zegt "Ik programmeer geen letter voordat jij opschrijft wat je wil", en ze daarbij desnoods ook begeleidend, gaat men bouwen en ontwerpen tegelijk, aanpassingen makend terwijl er nog gecompileerd wordt. En dát is niet te testen, mondt uit in ontestbare spaghetticode en zorgt voor overspannen ontwikkelaars en een team dat te bang is om wijzigingen uit te voeren omdat men met een fucking fragiel product zit.

Elke. Keer. Weer.

Hydra schreef op woensdag 20 september 2017 @ 16:01:
[...]
Te veel mensen die te lang op dezelfde plek zitten. Het is ook lastig om je druk te maken over kwaliteit als je de enige bent in een organisatie.

[ Voor 19% gewijzigd door CodeCaster op 20-09-2017 16:17 ]

[ThomasG]

CodeCaster schreef op woensdag 20 september 2017 @ 16:11:
[...]

En we hebben het hier over een niveau of tig hoger.

Natuurlijk kun je een string splitter, een regex of een comparator die wat properties van een object vergelijkt prima unittesten. Je kunt de positieve en negatieve inputs op een bierviltje kwijt en voilá, je testcases.

Het probleem waar het hier om gaat is slecht omschreven requirements. In plaats van dat men gaat steigeren en zegt "Ik programmeer geen letter voordat jij opschrijft wat je wil", gaat men bouwen en ontwerpen tegelijk, aanpassingen makend terwijl er nog gecompileerd wordt. En dát is niet te testen, mondt uit in ontestbare spaghetticode en zorgt voor overspannen ontwikkelaars en een team dat te bang is om wijzigingen uit te voeren omdat men met een fucking fragiel product zit.

Elke. Keer. Weer.

Maar dat is een probleem dat weinig met testen te maken heeft. Er wordt dan gewoon niet (goed) nagedacht over wat er nu eigenlijk gemaakt moet worden. Dat is ook meteen de reden waarom veel (software) projecten veel te duur uitvallen, en de klant niet tevreden is. Het consult en ontwerp, voorzover dat er was, is dan gewoon niet goed gegaan. Wij hebben een project van voor mijn tijd, dat ook zo ontstaan is. En daar hebben we nu nog steeds problemen mee, omdat het niet kan wat het eigenlijk moet doen (doordat er toen gewoon niet is nagedacht).

[Styxxy]

Hydra schreef op woensdag 20 september 2017 @ 16:01:
[...]
Te veel mensen die te lang op dezelfde plek zitten. Het is ook lastig om je druk te maken over kwaliteit als je de enige bent in een organisatie.

Met dan de dooddoener : zo doen we het al 15 jaar en nog "nooit" problemen mee gehad.

[CodeCaster]

Styxxy schreef op woensdag 20 september 2017 @ 16:23:
[...]



Met dan de dooddoener : zo doen we het al 15 jaar en nog "nooit" problemen mee gehad.

Het is toch ook geen probleem dat elke release drie dagen kost, inclusief overwerk ("maar pizza's!"), onnodige stress, databaserestores midden in de nacht en een overbelaste helpdesk voor de week na de uitrol?

ThomasG schreef op woensdag 20 september 2017 @ 16:17:
[...]
Maar dat is een probleem dat weinig met testen te maken heeft. Er wordt dan gewoon niet (goed) nagedacht over wat er nu eigenlijk gemaakt moet worden. Dat is ook meteen de reden waarom veel (software) projecten veel te duur uitvallen, en de klant niet tevreden is. Het consult en ontwerp, voorzover dat er was, is dan gewoon niet goed gegaan. Wij hebben een project van voor mijn tijd, dat ook zo ontstaan is. En daar hebben we nu nog steeds problemen mee, omdat het niet kan wat het eigenlijk moet doen (doordat er toen gewoon niet is nagedacht).

Dat is dus een beetje het punt. Als er geen specs zijn, is er niks te testen. En als het ontestbaar is én er zijn geen specs, zit je in een spagaat: waar moet je beginnen?

[ Voor 49% gewijzigd door CodeCaster op 20-09-2017 16:33 ]

[ThomasG]

CodeCaster schreef op woensdag 20 september 2017 @ 16:30:
[...]

Het is toch ook geen probleem dat elke release drie dagen kost, inclusief overwerk ("maar pizza's!"), onnodige stress, databaserestores midden in de nacht en een overbelaste helpdesk voor de week na de uitrol?

Dat is gewoon onderdeel van de functieomschrijving

[kenneth]

Best leuk, dat Advent of Code (Ik weet, laat ). Oplossingen waar je met brute-forcen er net wel mee wegkomt maar vervolgens met een kleine verandering in het tweede deel wordt gedwongen na te denken en (shudder) nieuwe dingen te leren. Nu een oplossing verbeterd van 14'20 naar 39ms

Over de helft, hierna Project Euler maar eens bekijken.

[Hydra]

Zeker een aanrader. Als vastgeroeste Java dev wordt je aardig gedwongen je informatica skills een beetje van stal te halen.

CodeCaster schreef op woensdag 20 september 2017 @ 16:30:
Het is toch ook geen probleem dat elke release drie dagen kost, inclusief overwerk ("maar pizza's!"), onnodige stress, databaserestores midden in de nacht en een overbelaste helpdesk voor de week na de uitrol?

Ik wil best een keer indien nodig m'n handen uit de mouwen steken. Maar als ik suggesties geef om een release te verbeteren en deze worden dan in de wind geslagen moet je niet later bij mij aankomen om over te gaan werken. Ik heb je tig tijd geleden uitgelegd wat er mis is en hoe we dat kunnen oplossen. Dat jouw app niet live gaat morgen maar over een week is dan echt enorm niet mijn probleem.

Ik doe die shit niet meer. Als het ze niet bevalt gaan ze maar op zoek naar een andere Java dev met 15 jaar ervaring. Gek genoeg doen ze dat dan ook weer niet.

Dat is dus een beetje het punt. Als er geen specs zijn, is er niks te testen.

Als er geen specs zijn, is er niks te bouwen.

[ Voor 84% gewijzigd door Hydra op 20-09-2017 17:44 ]

[gekkie]

Hydra schreef op woensdag 20 september 2017 @ 17:42:
Als er geen specs zijn, is er niks te bouwen.

Tsja dan krijg je het probleem nog dat je specs hebt en Specs.

Moet je weer de specs te specificeren

[ Voor 9% gewijzigd door gekkie op 20-09-2017 18:26 ]

[CodeCaster]

Hydra schreef op woensdag 20 september 2017 @ 17:42:
[...]


Als er geen specs zijn, is er niks te bouwen.

Geloofden maar meer mensen dat. Ik heb de afgelopen jaren honderdduizenden regels code geschreven zien worden op basis van globaal mondeling overleg, zonder in te gaan op details. Of sprint plannings van een paar uur, waarbij het besprokene niet wordt vastgelegd, en men dus maar afgaat op het geheugen van de deelnemers.

Als dat gebeurt, spec ik zelf retroactief in m'n tickets. Ben je het niet eens met de opgeleverde functionaliteit? Had je zelf het ticket moeten aanvullen, en niet een ticket met enkel een titel, of erger (!), een gecopy-pasted mailtje in de body in de sprint moeten slepen.

[ Voor 7% gewijzigd door CodeCaster op 20-09-2017 19:42 ]

[Swedish Clown]

CodeCaster schreef op woensdag 20 september 2017 @ 19:42:
[...]

Geloofden maar meer mensen dat. Ik heb de afgelopen jaren honderdduizenden regels code geschreven zien worden op basis van globaal mondeling overleg, zonder in te gaan op details. Of sprint plannings van een paar uur, waarbij het besprokene niet wordt vastgelegd, en men dus maar afgaat op het geheugen van de deelnemers.

Als dat gebeurt, spec ik zelf retroactief in m'n tickets. Ben je het niet eens met de opgeleverde functionaliteit? Had je zelf het ticket moeten aanvullen, en niet een ticket met enkel een titel, of erger (!), een gecopy-pasted mailtje in de body in de sprint moeten slepen.

Lever je dan zelf "half-bakken" functionaliteit af onder het mom van "had je maar betere specs moeten aanleveren" of ga je terug naar de Product Manager/opdrachtgever om meer/betere specs aan te leveren?

[CodeCaster]

Brakkie41 schreef op woensdag 20 september 2017 @ 21:31:
[...]


Lever je dan zelf "half-bakken" functionaliteit af onder het mom van "had je maar betere specs moeten aanleveren" of ga je terug naar de Product Manager/opdrachtgever om meer/betere specs aan te leveren?

Dat is natuurlijk niet zo zwart-wit te zeggen. Het hangt ook erg van het soort bedrijf en hun werkwijze af.

Doorgaans ben ik echt de beroerdste niet om hiaten in de specs te bespreken waar ik achter kom tijdens het implementeren, maar als het aan mij ligt, ga ik met de product owner of projectmanager zitten om te bespreken wat ze nou precies willen, daarna maak ik het ticket af qua tekst, en overleg dan met een collega over de implementatie alvorens ook maar te beginnen.

Maar soms zijn het echt gevallen waarvan je achteraf hoort van zaken die je alleen met bijzonder inhoudelijke kennis had kunnen voorspellen, en waar je in de implementatie dus geen rekening mee had kunnen houden - let wel, als externe. Dan geef ik dus ook gewoon aan dat ze zulke gevallen érgens moeten omschrijven.

Als het "common knowledge" had moeten zijn voor dat vakgebied, maak dan een Wiki aan of zo.

[Swedish Clown]

CodeCaster schreef op woensdag 20 september 2017 @ 21:39:
[...]

Dat is natuurlijk niet zo zwart-wit te zeggen. Het hangt ook erg van het soort bedrijf en hun werkwijze af.

Doorgaans ben ik echt de beroerdste niet om hiaten in de specs te bespreken waar ik achter kom tijdens het implementeren, maar als het aan mij ligt, ga ik met de product owner of projectmanager zitten om te bespreken wat ze nou precies willen, daarna maak ik het ticket af qua tekst, en overleg dan met een collega over de implementatie alvorens ook maar te beginnen.

Maar soms zijn het echt gevallen waarvan je achteraf van gevallen hoort die je alleen met bijzonder inhoudelijke kennis had kunnen voorspellen, en waar je in de implementatie dus geen rekening mee had kunnen houden - let wel, als externe. Dan geef ik dus ook gewoon aan dat ze zulke gevallen érgens moeten omschrijven.

Als het "common knowledge" had moeten zijn voor dat vakgebied, maak dan een Wiki aan of zo.

Duidelijk en helemaal mee eens T.a.v het overleggen, pairen jullie niet met je collega's bij bepaalde implementaties dan? Hier geld overigens grotendeels hetzelfde principe. Als je als PM of PMO niet de juiste specificaties levert, kunnen wij niet aan de slag. Of we doen een deel waarvan we zeker weten dat dat wel vaststaaten de rest wordt geblokt

Wij pairen/mobben met name bij complexe implementaties en implementaties waar veel beslissen genomen moeten worden t.a.v. de architectuur. Business, zegt "wij willen A". Het is aan ons hoe wij A willen bereiken. Met name dan is pairen/mobben een goede tool om gezamenlijk tot een oplossing te komen en geen gezeur achteraf te krijgen dat bepaalde team members het niet eens zijn met de implementatie. Simpelweg, 2 man hebben eraan gewerkt en tenzij je met hele sterke argumenten komt, wij zijn na meerdere iteraties bij deze (beste) oplossing gekomen

[Tarkin]

CodeCaster schreef op woensdag 20 september 2017 @ 21:39:
[...]

*

Eigenlijk zeggen jullie gewoon nu dat het proces voorafgaand het coden niet voldoende is. En als gevolg daarvan ga je er maar direct van uit dat TDD niet werkt.

TDD is hier niet het probleem, maar eerder het gevolg van gebrekkige analyse/specs die niet/half kloppen. Adresseer eerst dat probleem vooraleer je TDD afserveert.

Ja het is gemakkelijk om te zeggen dat je er niets aan kan doen want corporate doet zus of zo, maar je kan dat ook heel klein beginnen en in je eigen team beginnen verbeteren. Niet dat je morgen ineens het toonvoorbeeld bent van agile/tdd/whatever maar elk klein stapje is toch een stap.

[Swedish Clown]

Tarkin schreef op donderdag 21 september 2017 @ 07:55:
[...]


Eigenlijk zeggen jullie gewoon nu dat het proces voorafgaand het coden niet voldoende is. En als gevolg daarvan ga je er maar direct van uit dat TDD niet werkt.

TDD is hier niet het probleem, maar eerder het gevolg van gebrekkige analyse/specs die niet/half kloppen. Adresseer eerst dat probleem vooraleer je TDD afserveert.

Ja het is gemakkelijk om te zeggen dat je er niets aan kan doen want corporate doet zus of zo, maar je kan dat ook heel klein beginnen en in je eigen team beginnen verbeteren. Niet dat je morgen ineens het toonvoorbeeld bent van agile/tdd/whatever maar elk klein stapje is toch een stap.

Ik heb het idee dat Codecaster het punt van wel/niet en waarom TDD al voorbij is.

Om even op jou in te haken, TDD heeft z'n plaats maar kan/past gewoon niet altijd. Als ik een Kafka listener moet schrijven en data moet importeren van een ander, zijn er meerdere plaatsen in de code waar TDD simpelweg niet zinvol is. Is het te doen? Ja. Is het praktisch? Nee.

Binnen ons team halen we vooral in bij TDD voor het oplossen van bugs en dan met name bij Emergency Releases waar geen uitvoerige nachtelijke tests worden gedraaid.

Alle vormen van testen hebben zo hun plaats en er is geen zilveren kogel die voor elk project of feature werkt.

[Hydra]

Brakkie41 schreef op donderdag 21 september 2017 @ 08:08:
Binnen ons team halen we vooral in bij TDD voor het oplossen van bugs en dan met name bij Emergency Releases waar geen uitvoerige nachtelijke tests worden gedraaid.

Hoe bedoel je dat? Je kunt geen TDD doen om naderhand bugs op te lossen.

[CodeCaster]

Tarkin schreef op donderdag 21 september 2017 @ 07:55:
[...]


Eigenlijk zeggen jullie gewoon nu dat het proces voorafgaand het coden niet voldoende is. En als gevolg daarvan ga je er maar direct van uit dat TDD niet werkt.

Dat klopt. Ik zeg dat testen niet werkt als je geen specs hebt.

Hydra schreef op donderdag 21 september 2017 @ 08:51:
[...]


Hoe bedoel je dat? Je kunt geen TDD doen om naderhand bugs op te lossen.

Je kunt na het ontvangen van een bugreport een test schrijven die faalt als de bug optreedt. Als de test groen is, is de bug opgelost. Right?

Maar als je zo werkt, kun je inderdaad niet zeggen dat je volledige ontwikkelproces test-driven is.

[ Voor 6% gewijzigd door CodeCaster op 21-09-2017 09:03 ]

[Swedish Clown]

CodeCaster schreef op donderdag 21 september 2017 @ 09:02:

[...]

Je kunt na het ontvangen van een bugreport een test schrijven die faalt als de bug optreedt. Als de test groen is, is de bug opgelost. Right?

Maar als je zo werkt, kun je inderdaad niet zeggen dat je volledige ontwikkelproces test-driven is.

Dat dus

[Hydra]

Brakkie41 schreef op donderdag 21 september 2017 @ 09:04:
Dat dus

Test Driven wil zeggen dat je in het ontwikkelen aan de hand van tests je software ontwerpt. Naderhand tests schrijven om te voorkomen dat een bug opnieuw optreedt is de normaalste zaak van de wereld maar heeft echt niks met TDD te maken.

Dat je tests schrijft betekent niet dat je werkt volgens TDD.

[Tarkin]

CodeCaster schreef op donderdag 21 september 2017 @ 09:02:
[...]

Dat klopt. Ik zeg dat testen niet werkt als je geen specs hebt.

Ik zeg hier dat de story dan niet klaar is en niet kan opgenomen worden in de sprint Ze kunnen op hun kop staan maar ofwel goede specs ofwel beginnen we er niet aan.

[...]

Je kunt na het ontvangen van een bugreport een test schrijven die faalt als de bug optreedt. Als de test groen is, is de bug opgelost. Right?

Maar als je zo werkt, kun je inderdaad niet zeggen dat je volledige ontwikkelproces test-driven is.

Reactive is heel hip en trendy, maar dit is gewoon achter de feiten aanhollen. Al helemaal als blijkt dat de bugs gemakkelijk konden gevonden worden als er TDD gewerkt was (en dan heb ik het over die heel obvious nullpointers of andere fouten, functionele fouten kunnen soms wat trickier zijn om van de eerste keer in een test te gieten). Je voelt je heel dom dan als je dat pas opmerkt in PRD en er een patch van mag gemaakt worden

@Hydra ik denk dat we het eens zijn

[ThomasG]

Hydra schreef op donderdag 21 september 2017 @ 09:07:
[...]


Test Driven wil zeggen dat je in het ontwikkelen aan de hand van tests je software ontwerpt. Naderhand tests schrijven om te voorkomen dat een bug opnieuw optreedt is de normaalste zaak van de wereld maar heeft echt niks met TDD te maken.

Dat je tests schrijft betekent niet dat je werkt volgens TDD.

Daarbij wordt er ook vaak verkeerd getest. Er wordt dan wel getest of het werkt zoals het moet in de ideale situatie, maar niet of het bijvoorbeeld de correcte exception geeft bij wanneer het fout gaat. Dan lijkt het allemaal te werken, maar dat kan lelijke bugs en/of crashes geven in production. Nu kun je natuurlijk niet alles testen, maar met zulke dingen kan wel rekening gehouden worden.

[Hydra]

Tarkin schreef op donderdag 21 september 2017 @ 09:08:
Ik zeg hier dat de story dan niet klaar is en niet kan opgenomen worden in de sprint Ze kunnen op hun kop staan maar ofwel goede specs ofwel beginnen we er niet aan.

Precies. Dit is een onderdeel van je proces. Klinkt als een club die 'agile' is en claimt aan 'scrum' te doen maar dat het vooral scrum-but is. Geen ready issues = een lege sprint = ik ga werk doen dat ik vind dat nuttig is. Dashboards maken, CI/CD optimaliseren, etc.

Reactive is heel hip en trendy

Neuh, meer een verkeerde interpretatie van agile. Er zijn echt bakken mensen die denken dat je met agile niet / minder na moet denken over wat je doet. Het tegenovergestelde is waar; maar dat is er lastig in te krijgen.

, maar dit is gewoon achter de feiten aanhollen. Al helemaal als blijkt dat de bugs gemakkelijk konden gevonden worden als er TDD gewerkt was (en dan heb ik het over die heel obvious nullpointers of andere fouten, functionele fouten kunnen soms wat trickier zijn om van de eerste keer in een test te gieten). Je voelt je heel dom dan als je dat pas opmerkt in PRD en er een patch van mag gemaakt worden

Ik doe in principe niet aan "productie support" buiten kantooruren. Software gaat niet spontaan stuk en al helemaal niet op rustige momenten. Die bugs bestonden al en zouden ruim van te voren naar boven gekomen moeten zijn.

Vandaar: software zonder tests is geen software, het is een zooi instructies in een quantum staat. Je weet pas de staat als je het observeert. Software is niet anders.

@Hydra ik denk dat we het eens zijn

[.oisyn]

Oh Xbox, you continue to amaze me

[Merethil]

.oisyn schreef op donderdag 21 september 2017 @ 11:54:
Oh Xbox, you continue to amaze me

[afbeelding]

Mijn collega had net dit pareltje in zijn Windows 10 pro:


Ook bijzonder

[LangTall]

ThomasG schreef op donderdag 21 september 2017 @ 09:17:
[...]
Daarbij wordt er ook vaak verkeerd getest. Er wordt dan wel getest of het werkt zoals het moet in de ideale situatie, maar niet of het bijvoorbeeld de correcte exception geeft bij wanneer het fout gaat. Dan lijkt het allemaal te werken, maar dat kan lelijke bugs en/of crashes geven in production. Nu kun je natuurlijk niet alles testen, maar met zulke dingen kan wel rekening gehouden worden.

Yep, ik haat ondertussen de @Test(expected = IllegalArgumentException.class). En daar dan doodleuk 3 parameters mee testen. Ik wil dan toch graag zien op welke parameter de exception vliegt.

[Hydra]

LangTall schreef op donderdag 21 september 2017 @ 15:04:

Yep, ik haat ondertussen de @Test(expected = IllegalArgumentException.class). En daar dan doodleuk 3 parameters mee testen. Ik wil dan toch graag zien op welke parameter de exception vliegt.

Sowieso is dat een codesmell. Daar heb je ExpectedException rules voor waarin je ook checkt wat de exception message is. Anders kan het 'toevallig' goed gaan omdat er een compleet andere exception ergens gegooid wordt die toevallig IllegalArgumentException subclasses. Bij ons 'mag' het ook niet.

[LangTall]

Hydra schreef op donderdag 21 september 2017 @ 16:10:
[...]


Sowieso is dat een codesmell. Daar heb je ExpectedException rules voor waarin je ook checkt wat de exception message is. Anders kan het 'toevallig' goed gaan omdat er een compleet andere exception ergens gegooid wordt die toevallig IllegalArgumentException subclasses. Bij ons 'mag' het ook niet.

Daar waar ik ze tegenkom als ik toch al wat met die code moet, gaan ze er ook uit en komt er een ExpectedException voor in de plaats.

[Merethil]

Door jullie discussies ben ik mijn eigen hobbyprojecten meer TDD aan gaan pakken. Ik maak nu een begin, haal in en ga alle development daarna in TDD doen (heb toch alle tijd om die projecten te doen, kan ik 't nu makkelijker aanleren en erin verbeteren )

Op mijn werk doen we aan Unit Tests, maar niet aan TDD; meestal worden de tests achteraf geschreven en het gros van onze testen gebeuren handmatig. Daarom maar eens besloten 't aan te gaan pakken in mijn eigen spul.

En warempel, ik schrijf een paar testen en kom direct drie bugs tegen. Ik voel me nu heel voldaan, een beetje stom en dom, en vooral heb ik nu zin om meer testen te schrijven. Dat is echt raar

[Tarkin]

Prachtige quote uit de deliver it cast van deze (of vorige) week: The purpose of TDD is not writing a million tests, it is expressing (in the form of a test) how the code should behave.

Dat die miljoen testen komen is dus eerder een gevolg dan de oorzaak.

[diabolofan]

Merethil schreef op donderdag 21 september 2017 @ 20:39:
En warempel, ik schrijf een paar testen en kom direct drie bugs tegen. Ik voel me nu heel voldaan, een beetje stom en dom, en vooral heb ik nu zin om meer testen te schrijven. Dat is echt raar

Daarom vind ik het bijvoorbeeld helemaal niet erg om een keer alleen maar backend werk te doen (terwijl ik normaal full-stack doe omdat dit zo lekker afwisselend is), omdat het maken (en slagen!) van gemaakte tests inderdaad ook al heerlijke voldoening geeft (en je dus geen frontend hoeft te hebben om het idee te krijgen dat je wat moois gemaakt hebt)

[ Voor 9% gewijzigd door diabolofan op 22-09-2017 11:30 ]

[Merethil]

diabolofan schreef op vrijdag 22 september 2017 @ 11:28:
[...]


Daarom vind ik het bijvoorbeeld helemaal niet erg om een keer alleen maar backend werk te doen (terwijl ik normaal full-stack doe omdat dit zo lekker afwisselend is), omdat het maken (en slagen!) van gemaakte tests inderdaad ook al heerlijke voldoening geeft (en je dus geen frontend hoeft te hebben om het idee te krijgen dat je wat moois gemaakt hebt)

Ik ben heel slecht in frontend voor m'n eigen hobbies, maar dat komt omdat ik gewoon niet goed ben in vormgeving Maar inderdaad, dit zorgt wel voor extra trots in je eigen product

[diabolofan]

Frontend houd voor mij inderdaad in dat ik de data uit m'n api in een door een ander gemaakte template (vaak gekocht bij één van de vele admintemplate bouwers die online te vinden zijn) duw, zodat het er aantoonbaar uitziet...

[DevWouter]

Tarkin schreef op vrijdag 22 september 2017 @ 08:00:
Prachtige quote uit de deliver it cast van deze (of vorige) week: The purpose of TDD is not writing a million tests, it is expressing (in the form of a test) how the code should behave.

Ugh... Ik haat die quote. Het doel is namelijk om de kwaliteit te verbeteren, niet om het gedrag van de code uit te drukken. Men haalt het doel en het middel door elkaar heen.

Tevens geeft TDD geen enkele garantie over het gedrag van je code. Het brengt vertrouwen over het gedrag. 100% coverage is niet hetzelfde als 100% getest.
100% getest is namelijk een stuk uitgebreider en dan moet je echt alle factoren getest hebben.

TDD is geen garantie dat er geen bugs zullen zijn.

/disable rant-mode

[ElkeBxl]

https://medium.freecodeca...eir-helpdesk-b7680ddc2d4c

Beetje leesvoer voor de vrijdagnamiddag

[Hydra]

DevWouter schreef op vrijdag 22 september 2017 @ 11:59:
Ugh... Ik haat die quote. Het doel is namelijk om de kwaliteit te verbeteren, niet om het gedrag van de code uit te drukken. Men haalt het doel en het middel door elkaar heen.

Tevens geeft TDD geen enkele garantie over het gedrag van je code. Het brengt vertrouwen over het gedrag. 100% coverage is niet hetzelfde als 100% getest.
100% getest is namelijk een stuk uitgebreider en dan moet je echt alle factoren getest hebben.

TDD is geen garantie dat er geen bugs zullen zijn.

/disable rant-mode

Dit is echt een compleet verkeerde interpretatie van TDD. Code coverage is absoluut geen doel op zich.

Je code bestaat uit functions. Deze hebben input en output. Sommige veranderen state, andere niet. Wat je tests doen is controleren of met elke input de output en resulterende state is die je verwacht. Tests garanderen dat de code, voor de input die jij geeft, doet wat je verwacht dat het doet. Als het dan iets doet wat je niet verwacht, betekent dat dat je die combinatie van input niet getest hebt. Coverage is niks meer dan een tool om je te laten zien welke code paden (en dus input) je gemist hebt. Hoge code coverage in logica is an sich geen doel maar vaak wel een gevolg van goeie tests. Lage code coverage is daarentegen vrijwel altijd een indicatie van slechte tests.

TDD stelt dat aangezien je toch tests nodig hebt je code testbaar moet zijn. Je kunt dan, aangezien je toch tests moet maken en je code testbaar moet zijn dit het beste dan gewoon maar test-first onwikkelen. Je slaat 3 vliegen in 1 klap; het helpt je met software ontwerp, je bouwt testbare code en je hebt meteen de tests die je toch al hebt moeten schrijven.

Je kunt gedrag van code op verschillende manieren uitdrukken. Plaatjes, psuedocode, maar ook in tests (input en output assertions). TDD doet dus het laatste; wederom omdat je die tests toch al nodig hebt.

Tests geven confidence. Hoe beter de test hoe minder vaak er dingen onverwacht stuk gaan. Niemand claimt ook maar ergens dat je door TDD te gaan gebruiken op magische wijze opeens onfaalbare code hebt. Wat TDD je wel doet is min of meer dwingen die tests meteen te schrijven. En dat kunnen een hoop developers goed gebruiken.

[DevWouter]

Hydra schreef op vrijdag 22 september 2017 @ 12:34:
Dit is echt een compleet verkeerde interpretatie van TDD. Code coverage is absoluut geen doel op zich.

Volgens mij schreef ik dat ook niet. 100% code coverage is alleen een neveneffect als je TDD aanhoud en zoals jij ook aangeeft verder in je betoog is Code Coverage een middel en niet een doel bij TDD.

Hydra schreef op vrijdag 22 september 2017 @ 12:34:
Je code bestaat uit functions. Deze hebben input en output...

En ik maar denken dat code bestaat uit lappen tekst

Hydra schreef op vrijdag 22 september 2017 @ 12:34:
Tests geven confidence. Hoe beter de test hoe minder vaak er dingen onverwacht stuk gaan. Niemand claimt ook maar ergens dat je door TDD te gaan gebruiken op magische wijze opeens onfaalbare code hebt. Wat TDD je wel doet is min of meer dwingen die tests meteen te schrijven. En dat kunnen een hoop developers goed gebruiken.

Om verder discours te voorkomen: Ik ben een fel voorstander van TDD en die quote die genoemd werd is één die ik nogal een afbreuk vind aan wat TDD is en doet. De hoeveelheid tests heeft niks te maken met TDD en TDD is zeker niet nooit bedacht om het gedrag van je code uit te drukken, dat is namelijk een gevolg. Wat Hydra schreef (en wat ik als laatste quote) is een die een factor ∞ beter is.

[F.West98]

Ik heb een oplossing voor deze hele discussie: Geen tests doen

Maar tja ja misschien moet ik ook eens een keertje beginnen met tests. Als ik ooit weer eens tijd heb voor mijn eigen projectjes. Op mn werk gebruiken ze iig wel wat tests, maar vrij lage coverage en lang niet alle devs schrijven nieuwe tests. De core functionaliteit is wel goed gecoverd volgens mij.

[Hydra]

F.West98 schreef op zaterdag 23 september 2017 @ 03:32:

Maar tja ja misschien moet ik ook eens een keertje beginnen met tests.

Ya think?

[Verwijderd]

Wij doen hier ook aan TDD, maar wij zitten met sommige projecten met een probleem: hoe test je iets wat afhankelijk is van een andere applicatie (die op een andere computer moet draaien door de manier waarop het netwerkprotocol is ingericht)?

[Hydra]

Verwijderd schreef op zaterdag 23 september 2017 @ 08:11:
Wij doen hier ook aan TDD, maar wij zitten met sommige projecten met een probleem: hoe test je iets wat afhankelijk is van een andere applicatie (die op een andere computer moet draaien door de manier waarop het netwerkprotocol is ingericht)?

Die mock je weg in je unit tests en integratietests en neem je mee in je e2e tests.

[Tarkin]

Verwijderd schreef op zaterdag 23 september 2017 @ 08:11:
Wij doen hier ook aan TDD, maar wij zitten met sommige projecten met een probleem: hoe test je iets wat afhankelijk is van een andere applicatie (die op een andere computer moet draaien door de manier waarop het netwerkprotocol is ingericht)?

Zoals hierboven gezeg is geweest, werken met een mock. voor unit testen (en meestal zelfs de meeste integratetesten). Je test die andere applicatie ook dus heb je maar een paar testen nodig die echt de integratie testen.

F.West98 schreef op zaterdag 23 september 2017 @ 03:32:
Ik heb een oplossing voor deze hele discussie: Geen tests doen

Maar tja ja misschien moet ik ook eens een keertje beginnen met tests. Als ik ooit weer eens tijd heb voor mijn eigen projectjes. Op mn werk gebruiken ze iig wel wat tests, maar vrij lage coverage en lang niet alle devs schrijven nieuwe tests. De core functionaliteit is wel goed gecoverd volgens mij.

Iets met assumptions, mothers en fuckups...

[Crazy D]

Hydra schreef op zaterdag 23 september 2017 @ 08:23:
Die mock je weg in je unit tests en integratietests en neem je mee in je e2e tests.

Ik snap het concept van unit tests. Ik ontwikkel veel op Exact software, met name Synergy. Dan ben afhankelijk van minimaal een environment object en daarmee database connecties, en de repository van Exact waarin je met maatwerk weer kunt inhaken. Ik ben al best wel regelmatig aan het kijken geweest hoe ik dat zou kunnen mockuppen, maar de afhankelijkheid van die componenten is dusdanig diep, dat zelf voor een formattering van een datum je afhankelijk bent van de library van Exact (die weer kijkt naar de gebruikers instelling). Ik heb er best een tijdje naar zitten kijken en ook met anderen over gehad, maar naar ons idee konden we alleen echt losse routines testen, maar juist de interactie binnen Exact (hetgeen waar het om gaat in het maatwerk...) kun je dan alsnog niet testen.
(en zelfs iets simpels als een stukje maatwerk die zorgt dat als je een nieuwe relatie wilt aanmaken, dat je geen relatienummer gebruikt dat al in een andere database wordt gebruikt, ben je in Exact land dus van een component of 6, 7 afhankelijk). Misschien zou ik daar eens een eigen topic voor moeten maken hoor, maar wat suggesties in welke richting ik nog zou kunnen kijken?

[Alex)]

Ik moet dan denken aan het Facade-pattern, maar ik weet niet in hoeverre dat gaat helpen in jouw specifieke geval.

[Firesphere]

Wanneer is de volgende devschuur meetup?

[Hydra]

Crazy D schreef op zaterdag 23 september 2017 @ 16:49:
Ik snap het concept van unit tests. Ik ontwikkel veel op Exact software, met name Synergy. Dan ben afhankelijk van minimaal een environment object en daarmee database connecties, en de repository van Exact waarin je met maatwerk weer kunt inhaken.

Dat is wel nuttige informatie om vooraf te melden. Ik geef aan hoe ik het zou doen maar ik werk niet binnen een dergelijke dwangbuis. Dus hoe je dat specifiek in Exact zou moeten doen kunnen vermoedelijk alleen andere Exact experts je vertellen. En bij veel van dit soort frameworks is het vaak gewoon "dat kan niet", helemaal toen deze ontwikkeld zijn in de tijd dat testen nog iets vies was.

Ik ben al best wel regelmatig aan het kijken geweest hoe ik dat zou kunnen mockuppen,

Mocken

maar de afhankelijkheid van die componenten is dusdanig diep, dat zelf voor een formattering van een datum je afhankelijk bent van de library van Exact (die weer kijkt naar de gebruikers instelling). Ik heb er best een tijdje naar zitten kijken en ook met anderen over gehad, maar naar ons idee konden we alleen echt losse routines testen, maar juist de interactie binnen Exact (hetgeen waar het om gaat in het maatwerk...) kun je dan alsnog niet testen.

Je bent dan dus niet aan het unit testen. Eigenlijk is vrijwel elke test die je doet op z'n minst een systeemtest en dan merk je dus waarom dit kut is; deze worden heel snel erg complex.

(en zelfs iets simpels als een stukje maatwerk die zorgt dat als je een nieuwe relatie wilt aanmaken, dat je geen relatienummer gebruikt dat al in een andere database wordt gebruikt, ben je in Exact land dus van een component of 6, 7 afhankelijk). Misschien zou ik daar eens een eigen topic voor moeten maken hoor, maar wat suggesties in welke richting ik nog zou kunnen kijken?

Kappen met Exact en gewoon echt software engineering gaan doen? Sorry

[Creepy]

Firesphere schreef op zondag 24 september 2017 @ 09:42:
Wanneer is de volgende devschuur meetup?

Wanneer ben jij in NL?

[Tarkin]

Is er een meetup groep van de devschuur?

[Creepy]

Dat niet, maar eens in de zoveel tijd doen we een Devschuur meet om zo elkaar ook eens IRL te zien.. de vorige is inderdaad alweer ff geleden (maar toen was het ook erg rustig...). Wat en wanneer komt altijd in een los (sticky) topic te staan, en komt gegarandeerd ook wel hier voorbij

Dus als FireSphere nu zegt wanneer ie in NL is, dan plannen we de meet net daarvoor of daarna

[ Voor 15% gewijzigd door Creepy op 24-09-2017 13:52 ]

[Crazy D]

Alex) schreef op zaterdag 23 september 2017 @ 17:49:
Ik moet dan denken aan het Facade-pattern, maar ik weet niet in hoeverre dat gaat helpen in jouw specifieke geval.

Ik moet even tijd zien te maken maar ik ga er induiken, de 1e paar regels klinkt als wellicht een optie.

Hydra schreef op zondag 24 september 2017 @ 09:57:
Kappen met Exact en gewoon echt software engineering gaan doen? Sorry

Haha ja maar wil ik 20 jaar ervaring overboord gooien... (naast ontwikkelen implementeer ik het ook, rapportages, etc, puur programmeren doe ik bij lange na niet 40 uur per week),

[Gropah]

blergh, ranttijd

Ik heb een website geupdate dus ben niet helemaal bekend met de techstack. Het gaat om een node server met express als backend en mongo als database, wat niet helemaal in de usecase past, maar wel hip was ten tijde van orginele maak. Hier en daar wat nieuwe features er in geknald, draait allemaal prima op mijn machine met docker-compose.

Wil het nu online zetten op een VPS van digitalocean maar ik krijg het maar niet aan de praat met dezelfde versies van docker en docker-compose. Ik dacht die tools er juist voor moesten zorgen dat het allemaal makkelijker zou gaan?

Probleem is dat de website niet kan connecten met de database wanneer deze niet op localhost gebind is. Dit wil ik echter liever niet ivm security want ik heb mongo liever niet direct beschikbaar via internet.

Goed, dat werkt niet, dus ik proberen om access management van mongo via de docker proper werkend te krijgen. Tegenwoordig zijn er environment variables MONGO_INITDB_ROOT_USERNAME en MONGO_INITDB_ROOT_PASSWORD. Maar die user heeft geen rechten om nieuwe databases en dergelijke te maken. Dus dan zou ik in de database moeten duiken en dat handmatig moeten doen. Echter, omdat ik nog wel eens aan het kloten ben en nu toch met docker bezig ben wil ik dit natuurlijk het liefst automatisch doen...

Manmanman... ik dacht, dit gaat wel even in een uurtje lukken maar ben er al een deel van de ochtend en de hele middag aan kwijt en het draait nog niet

[Firesphere]

Creepy schreef op zondag 24 september 2017 @ 13:51:
Dat niet, maar eens in de zoveel tijd doen we een Devschuur meet om zo elkaar ook eens IRL te zien.. de vorige is inderdaad alweer ff geleden (maar toen was het ook erg rustig...). Wat en wanneer komt altijd in een los (sticky) topic te staan, en komt gegarandeerd ook wel hier voorbij

Dus als FireSphere nu zegt wanneer ie in NL is, dan plannen we de meet net daarvoor of daarna

Geen idee, hangt een beetje af van hoe duur m'n tattoo gaat worden , maar ik hoop op Maart of Juni, dus als je'm dit jaar plant, ben ik vast niet er bij

[Hydra]

Gropah schreef op zondag 24 september 2017 @ 16:15:
Probleem is dat de website niet kan connecten met de database wanneer deze niet op localhost gebind is. Dit wil ik echter liever niet ivm security want ik heb mongo liever niet direct beschikbaar via internet.

Normaliter laat je een 'app' container met een 'db' container communiceren via een eigen netwerk. Je exposed je db normaliter niet naar buiten (daar kan een andere container niet bij), laat staan via het internet.

Docs: https://docs.docker.com/compose/compose-file/#links

Goed, dat werkt niet, dus ik proberen om access management van mongo via de docker proper werkend te krijgen. Tegenwoordig zijn er environment variables MONGO_INITDB_ROOT_USERNAME en MONGO_INITDB_ROOT_PASSWORD. Maar die user heeft geen rechten om nieuwe databases en dergelijke te maken. Dus dan zou ik in de database moeten duiken en dat handmatig moeten doen. Echter, omdat ik nog wel eens aan het kloten ben en nu toch met docker bezig ben wil ik dit natuurlijk het liefst automatisch doen...

Dan maak je toch een eigen image met je eigen config i.p.v. puur het base image te gebruiken? En wat ik zag in het Mongo docker image kun je zelf bij het maken je user maken.

[Firesphere]

Creepy schreef op zondag 24 september 2017 @ 13:51:
Dat niet, maar eens in de zoveel tijd doen we een Devschuur meet om zo elkaar ook eens IRL te zien.. de vorige is inderdaad alweer ff geleden (maar toen was het ook erg rustig...). Wat en wanneer komt altijd in een los (sticky) topic te staan, en komt gegarandeerd ook wel hier voorbij

Dus als FireSphere nu zegt wanneer ie in NL is, dan plannen we de meet net daarvoor of daarna

Nou, het wordt niet Februari of Maart, dus ga je gang

[Gropah]

Hydra schreef op maandag 25 september 2017 @ 10:05:
[...]


Normaliter laat je een 'app' container met een 'db' container communiceren via een eigen netwerk. Je exposed je db normaliter niet naar buiten (daar kan een andere container niet bij), laat staan via het internet.

Docs: https://docs.docker.com/compose/compose-file/#links

Weer wat geleerd, ik dacht dat je de port moest exposen zonder te mappen naar een port op de host om ze goed te laten linken.

[...]


Dan maak je toch een eigen image met je eigen config i.p.v. puur het base image te gebruiken? En wat ik zag in het Mongo docker image kun je zelf bij het maken je user maken.

Na wat gezoek bleek dat er ook een folder is waarin scripts kunnen staan die in alfabetische volgorde worden uitgevoerd. Dus dat maakt het inderdaad mogelijk

anyways; probleem gevonden, verkeerde config werd geladen

[Ryada]

Ik moet eens goed kijken wist niet eens dat er een programming subforum was. Toch maar eens rondkijken hierzo en gezellig doen.

Laatste tijd ben ik wat aan het proberen met 'n layered applications' in mijn vrije tijd, dat is nog best een uitdaging als je tot noch toe gewend bent om alles in 1 layer te stoppen.
Maarja voor alles is een eerste keer en je leert weer eens wat nieuws.
Nu maar mijn best doen om zo goed mogelijk dit door te krijgen.

[DevWouter]

Ryada schreef op maandag 25 september 2017 @ 12:42:
Laatste tijd ben ik wat aan het proberen met 'n layered applications' in mijn vrije tijd, dat is nog best een uitdaging als je tot noch toe gewend bent om alles in 1 layer te stoppen.
Maarja voor alles is een eerste keer en je leert weer eens wat nieuws.
Nu maar mijn best doen om zo goed mogelijk dit door te krijgen.

Moest even zoeken wat er bedoeld werd met "n layered applications". Ik ken die term, maar de laatste keer dat ik daar bewust mee bezig ben geweest is toch heel wat jaartjes geleden

Komt misschien omdat er zoveel middleware aanwezig is dat het allemaal uit je handen neemt

[ Voor 4% gewijzigd door DevWouter op 25-09-2017 13:31 ]

[.oisyn]

Ik maak ook altijd n layered applications. Met n=1

[Ryada]

.oisyn schreef op maandag 25 september 2017 @ 14:16:
Ik maak ook altijd n layered applications. Met n=1

Haha, ik moet toch een keer aan n=3 gaan ipv vasthouden op n=1
Zit nu een beetje te spelen met PropertyChanged events etc om te zorgen dat ik makkelijk mijn UI kan updaten door alleen maar een property aan te passen in de business layer ^.^

[whoami]

Is die stricte n-layered approach niet al een beetje passé ?

Je hebt nog altijd de UI die gescheiden is van de business logic, maar een echte DAL zoals in die artikelen wordt voorgesteld ? Die wordt meestal ingevuld door één of andere tool / framework en zit eigenlijk vervat in je application-layer

[ Voor 67% gewijzigd door whoami op 25-09-2017 14:53 ]

[Ryada]

Zou best kunnen dat het al een beetje passé is, maar het kan geen kwaad er wat kennis ervan te hebben lijkt mij. Misschien dat ik over een paar uur alweer afhaak van het hele 'n-layered' gedoe. Ik heb nu zowat de noodzaak om reflection te gebruiken om een beetje fatsoenlijk mijn UI layer te updaten zonder er om te moeten vragen (INotifyPropertyChanged is een uitkomst maar cross assembly heb je zowat reflection nodig)

[whoami]

Ryada schreef op maandag 25 september 2017 @ 14:59:
(INotifyPropertyChanged is een uitkomst maar cross assembly heb je zowat reflection nodig)

Hoezo ?
Je subscribed toch gewoon op een event; of dat nu cross-assembly is of niet maakt niet uit.

[Ryada]

whoami schreef op maandag 25 september 2017 @ 15:03:
[...]
Hoezo ?
Je subscribed toch gewoon op een event; of dat nu cross-assembly is of niet maakt niet uit.

Dat klopt, maar als je subscribed in een class en die replicate het naar een andere class is reflection naar mijn mening een iets betere keuze dan handmatig een hele switch in elkaar gaan zetten als je 30 properties hebt ofzo. Meningen kunnen hierover verschillen en ik heb denk ik een andere manier gevonden om dit voor elkaar te krijgen waardoor ik helemaal niet hoef te subscriben op het event.

[whoami]

Heel de bedoeling van INotifyPropertyChanged is dat je met data-binding gaat gaan werken, en dat de databinding zelf zorgt voor het updaten van de ui.

[Ryada]

whoami schreef op maandag 25 september 2017 @ 15:09:
Heel de bedoeling van INotifyPropertyChanged is dat je met data-binding gaat gaan werken, en dat de databinding zelf zorgt voor het updaten van de ui.

Dat snap ik maar heb soms de vervelende eigenschap dat ik veel te moeilijk doe om iets simpels te doen. En dan heb ik zelf niet door dat het simpeler kan. Heb nu gewoon een instance van het object uit de andere assembly in mijn ViewModel gezet en het werkt nu helemaal perfect. Zonder reflection of andere ingewikkelde structuur.

[whoami]

Dus heb je nu een dependency gecreeërd die je misschien niet wil ? (Wellicht tussen jouw BL en UI ?)

[Ryada]

Edit: nvm dit was niet zo een slim idee.

Weet niet zeker of ik de dependency wel of niet wil. Is nogal lastig om daar een oordeel over te hebben als ik voor het eerst met een multiple layered application werk. Ik zou hem wat mooier kunnen maken door een interface in mijn UI layer te maken die alleen de properties die ik nodig heb bevat, zodat het iig not interchangable is mocht ik later een andere BL maken. (niet dat ik verwacht dat dat zal gebeuren maar lijkt me wel wat netter dan de hele implementation in mijn ViewModel te hebben.)

[ Voor 4% gewijzigd door Ryada op 25-09-2017 15:44 ]

[kenneth]

Yay, een O(1)-oplossing uitgevogeld voor een AoC-puzzel (zowel deel 1 als deel 2) waar aan de reddit- en GoT-topics te zien veel mensen O(n) of zelfs O(n²) hadden

[Hydra]

whoami schreef op maandag 25 september 2017 @ 14:51:
Is die stricte n-layered approach niet al een beetje passé ?

Serverless computing or bust.

Ryada schreef op maandag 25 september 2017 @ 15:11:
Dat snap ik maar heb soms de vervelende eigenschap dat ik veel te moeilijk doe om iets simpels te doen.

Ach. Jij herkent tenminste dat je dat doet. Da's al het halve werk

kenneth schreef op maandag 25 september 2017 @ 15:26:
Yay, een O(1)-oplossing uitgevogeld voor een AoC-puzzel (zowel deel 1 als deel 2) waar aan de reddit- en GoT-topics te zien veel mensen O(n) of zelfs O(n²) hadden

Heb AoC gebruikt om Scala te leren. Die code kan ik nu niet meer lezen

[dcm360]

Wat een gepruts bij TransIP. Zojuist een mailtje ontvangen dat per gisteren de algemene voorwaarden gewijzigd zijn In de algemene voorwaarden staat nog letterlijk ook 'Wanneer we onze algemene voorwaarden wijzigen, laten we je dit een maand van tevoren weten.'.

[Acid_Burn]

Ik heb gisteren dezelfde gehad. Behoorlijk faal inderdaad.

[armageddon_2k1]

Dat zijn ook de nieuwe voorwaarden... stond het in de oude ook? Want anders hebben ze gewoon gelijk natuurlijk

[dcm360]

Het is in geen geval redelijk dat ik vandaag pas wordt ingelicht over een wijziging die per gisteren is ingegaan. Stel ik zou het niet eens zijn met de nieuwe voorwaarden, mag ik dan nu ook per gisteren opzeggen?

[ThomasG]

Ik heb helemaal (nog) geen melding gehad over nieuwe voorwaarden, terwijl ik daar al jaren klant ben. En voor zover ik het kan zien via archive.org, staat het al een lange tijd in hun voorwaarden dat ze het een maand van te voren bekend maken.

[dcm360]

Die melding komt dan nog wel denk ik, de e-mail die ik ontving heeft 19 uur in een queue gestaan (bij TransIP). Waarmee ik me dan wel weer afvraag hoe dat werkt met sectie 11.2 uit de algemene voorwaarden (leuk dat je m verzend om 16:30, maar de eerste afleverpoging ligt toch echt ruim later).

[armageddon_2k1]

Maar even gevraagd aan ze dan:
https://twitter.com/avwie/status/912613501922836480

Dus hoop gezeik om niks

[ Voor 15% gewijzigd door armageddon_2k1 op 26-09-2017 12:52 ]

[TheNephilim]

Ik zal eens een balletje opgooien; doen jullie thuis/privé/hobbymatig nog wat aan ontwikkelen?

Zelf moet ik eerlijk zeggen dat het er niet echt van komt, al zijn er plannen genoeg .

[Merethil]

TheNephilim schreef op woensdag 27 september 2017 @ 14:39:
Ik zal eens een balletje opgooien; doen jullie thuis/privé/hobbymatig nog wat aan ontwikkelen?

Zelf moet ik eerlijk zeggen dat het er niet echt van komt, al zijn er plannen genoeg .

Cursusje gamedevelopment in Unity van Udemy, een website bouwen voor m'n vriendin, m'n eigen blog uitbouwen en nog wat andere zut. Jaartje geleden eens een ORM gemaakt voor de lol om meer onderzoek te doen naar hoe generics en zelfgemaakte annotations werken in Java.

Zijn van die dingen waar ik me soms mee bezighoud, maar meestal valt het in het niet bij het gamen of sociale ( ) zaken die veel teveel van je weekend snoepen...

[mcDavid]

TheNephilim schreef op woensdag 27 september 2017 @ 14:39:
Ik zal eens een balletje opgooien; doen jullie thuis/privé/hobbymatig nog wat aan ontwikkelen?

Zelf moet ik eerlijk zeggen dat het er niet echt van komt, al zijn er plannen genoeg .

Hier het zelfde ja. Zeker sinds ik het professioneel doe komt er privé weinig meer van. Typisch gevalletje van je hobby je beroep maken, maar dan geen hobby meer hebben

[Megamind]

mcDavid schreef op woensdag 27 september 2017 @ 15:45:
[...]

Hier het zelfde ja. Zeker sinds ik het professioneel doe komt er privé weinig meer van. Typisch gevalletje van je hobby je beroep maken, maar dan geen hobby meer hebben

Yup, enige wat ik nog doe is nieuwe projecten beginnen met nieuwe technologie om ze na een avondje weer de prullenbak in de mikken.

[Laurens-R]

Sinds dat ik meer manage op m'n werk, merk ik dat ik lang niet meer zo up-to-date ben over de laatste ontwikkelingen als dat ik vroeger was. Ik heb weinig zin om nog in de avond te programmeren en overdag kom ik er ook steeds minder aan toe; gevolg: allemaal jonge gasten die inmiddels rondjes om mee heen rennen qua kennis over de laatste ontwikkelingen

Ik probeer overigens wel regelmatig m'n kennis bij te spijkeren, maar er zit dus wat delay in tov die jonge gasten die net afgestudeerd zijn

[ Voor 17% gewijzigd door Laurens-R op 27-09-2017 16:31 ]

[whoami]

Ik wil best nog wel eens wat doen thuis; ik heb zo een aantal ideetjes maar eigenlijk zijn het geen volwaardige projecten. Eerder experimenten om wat uit te zoeken.
Het ontbreekt me echter meestal aan tijd om daar veel of lang mee bezig te zijn. En als ik dan wel eens tijd heb, dan heb ik in veel gevallen geen zin

[Damic]

Gatver de gatver de gatver Telenet heeft de mijn.telenet pagina's samengevoegd met hun main site, en alles is nu angular en niet al de data dat beschikbaar was op de oude site staat op de nieuwe site kloot hommels. Hoe moet ik nu zien hoeveel data ik heb verbruikt op mijn mobiel abo

[Hydra]

TheNephilim schreef op woensdag 27 september 2017 @ 14:39:
Ik zal eens een balletje opgooien; doen jullie thuis/privé/hobbymatig nog wat aan ontwikkelen?

Ja, ik probeer toch regelmatig een blog post te schrijven of iets dat ongeveer relevant is, maar daar is de laatste maanden weinig van gekomen (vooral vanwege drukte). Daarnaast ben ik op dit moment met Angular 4 bezig (ben in m'n dagelijks werk Java dev).

Ik probeer toch wel een beetje in de buurt te blijven van wat voor m'n werk relevant kan zijn. IoT enzo is ook erg leuk maar daar ga ik toch niks mee doen.

Megamind schreef op woensdag 27 september 2017 @ 15:53:
Yup, enige wat ik nog doe is nieuwe projecten beginnen met nieuwe technologie om ze na een avondje weer de prullenbak in de mikken.

Vandaar ook het blog posts schrijven. Dan dwing ik mezelf tenminste het een beetje 'af' te maken.

[Sebazzz]

Ik doe ook nog thuis ontwikkelen, maar vooral dingen waar in op het werk niet aan toekom. Zoals een single page application schrijven. Rommelen met webpack (wat een heerlijke ervaring trouwens!). En zo neem ik sommige dingen ook weer mee naar het werk.

[.oisyn]

TheNephilim schreef op woensdag 27 september 2017 @ 14:39:
Ik zal eens een balletje opgooien; doen jullie thuis/privé/hobbymatig nog wat aan ontwikkelen?

Zelf moet ik eerlijk zeggen dat het er niet echt van komt, al zijn er plannen genoeg .

Ik ben af en aan bezig met Kol Q l8or 3 (gerebrand naar gewoon KolQ), Hier staat nog een oude versie 2.

Codebase is foetsie gegaan bij een harddisk crash, dus de nieuwe is compleet from scratch geschreven. Ben er eigenlijk aan begonnen omdat ik een client nodig voor mijn arbitrary precision arithmetic library die ik in tandem ontwikkel . Ik worstel nog een beetje met hoe ik de GUI ga doen dus het is momenteel nog een cli app. Ik had al wel een PoC in WPF maar ben er niet echt happy mee. Het liefst zou ik gewoon HTML willen weergeven in een browser control.

Itt Kol Q l8or 2, die feitelijk al wel Turing-complete was, bevat deze daadwerkelijk een volwaardige programmeertaal, inclusief lambda's, closures en objects.

[ Voor 7% gewijzigd door .oisyn op 27-09-2017 21:39 ]

[Swedish Clown]

TheNephilim schreef op woensdag 27 september 2017 @ 14:39:
Ik zal eens een balletje opgooien; doen jullie thuis/privé/hobbymatig nog wat aan ontwikkelen?

Zelf moet ik eerlijk zeggen dat het er niet echt van komt, al zijn er plannen genoeg .

Zoals velen hier, relatief weinig. Ik probeer af en toe wat Open Source werk te doen simpelweg omdat het leuk en regelmatig relevant is. Zo heb ik recent bij een Kafka producer/consumer client voor Erlang alle type specs overhoop gegooid om een eerste zet te doen richting type en style checken van dat project. Was een bak werk maar redelijk te scriptum met wat bash fu en Emacs macros dus al met al weer wat geleerd

Ben laatste tijd met name bezig met puzzelen om performance van Erlavro te verbeteren aangezien die performance niet naar mijn verwachting is en vele malen sneller moet kunnen (in theorie althans).

[xChOasx]

Voor de fans van ShenZen I/O, TIS-100, Manufactorio, etc; ik heb gister 'Silicon Zeroes' ontdekt.

Het is van de makers van Manufactorio, en echt een HEEL leuk spel: https://pleasingfungus.itch.io/silicon-zeroes

Kost wel 14 euro.

[Hydra]

.oisyn schreef op woensdag 27 september 2017 @ 21:37:
Codebase is foetsie gegaan bij een harddisk crash

Dude.

xChOasx schreef op donderdag 28 september 2017 @ 08:03:
Voor de fans van ShenZen I/O, TIS-100, Manufactorio, etc; ik heb gister 'Silicon Zeroes' ontdekt.

Het is van de makers van Manufactorio, en echt een HEEL leuk spel: https://pleasingfungus.itch.io/silicon-zeroes

Kost wel 14 euro.

En daar gaat 't weekend!

[farlane]

xChOasx schreef op donderdag 28 september 2017 @ 08:03:
Voor de fans van ShenZen I/O, TIS-100, Manufactorio, etc; ik heb gister 'Silicon Zeroes' ontdekt.

Het is van de makers van Manufactorio, en echt een HEEL leuk spel: https://pleasingfungus.itch.io/silicon-zeroes

Kost wel 14 euro.

Ik zou 'em kopen, als het op Linux zou draaien.

[ThomasG]

farlane schreef op donderdag 28 september 2017 @ 09:14:
[...]

Ik zou 'em kopen, als het op Linux zou draaien.

https://twitter.com/pleasingfungus/status/909853620597792768

[.oisyn]

Hydra schreef op donderdag 28 september 2017 @ 08:10:
[...]


Dude.

The big crash of 2013, zo'n beetje 15 jaar aan hobby werk verloren gegaan

Sindsdien heb ik een nas en offsite backup

[TheNephilim]

Toch wel aardig wat avond/weekend coders hier dus! ^^

xChOasx schreef op donderdag 28 september 2017 @ 08:03:
Voor de fans van ShenZen I/O, TIS-100, Manufactorio, etc; ik heb gister 'Silicon Zeroes' ontdekt.

Het is van de makers van Manufactorio, en echt een HEEL leuk spel: https://pleasingfungus.itch.io/silicon-zeroes

Kost wel 14 euro.

Ook op Steam te vinden: http://store.steampowered.com/app/684270/Silicon_Zeroes/

.oisyn schreef op donderdag 28 september 2017 @ 09:35:
[...]

The big crash of 2013, zo'n beetje 15 jaar aan hobby werk verloren gegaan

Sindsdien heb ik een nas en offsite backup

Foi, dat is wel echt nasty Als ik wat 'nuttigs' doe gooi ik het eigenlijk altijd meteen op Bitbucket/Github. Behalve dat het makkelijk is, heb je ook meteen een backup van je code.

[Hydra]

.oisyn schreef op donderdag 28 september 2017 @ 09:35:
The big crash of 2013, zo'n beetje 15 jaar aan hobby werk verloren gegaan

Da's knap pijnlijk. Heb zelf al m'n foto's op S3 staan. Weet niet hoe ik 't aan m'n vriendin moet gaan verkopen als we alle foto's van de kinderen van de afgelopen 6 jaar opeens kwijt zijn. Al m'n code staat in bitbucket of gitlab, al heel lang overigens. Vrijwel 't eerste wat ik doe als ik iets begin is een 'git init'.

[.oisyn]

@Hydra Foto's van de kinderen (de oudste is van 2012) staan gelukkig allemaal in de cloud, en waarschijnlijk nog op de flash van de DSLR die we eigenlijk amper gebruiken. We zijn wel wat vakantiekiekjes van voor die tijd kwijt ja, al was mijn vrouw ook wel veel van het daadwerkelijk afdrukken dus de meeste hebben we dan nog wel in analoge vorm

---

CppCon 2017 is momenteel aan de gang , maar god zeg wat zijn ze traag met het releasen van de video's

[azerty]

Damic schreef op woensdag 27 september 2017 @ 19:32:
Gatver de gatver de gatver Telenet heeft de mijn.telenet pagina's samengevoegd met hun main site, en alles is nu angular en niet al de data dat beschikbaar was op de oude site staat op de nieuwe site kloot hommels. Hoe moet ik nu zien hoeveel data ik heb verbruikt op mijn mobiel abo

Had het mailtje ook gekregen, maar nog niet gekeken... Belooft wat als het angular is

[Damic]

azerty schreef op donderdag 28 september 2017 @ 18:57:
[...]


Had het mailtje ook gekregen, maar nog niet gekeken... Belooft wat als het angular is

Werkt redelijk maar er zit natuurlijk vertraging op als je alles elke keer moet ophalen in de plats van alles in cache te plaatsen