De Devschuur Coffee Corner - Iteratie ⓫

[Mugwump]

Hydra schreef op woensdag 16 mei 2018 @ 16:35:
[...]


Niks. Hij's ouder dus heeft z'n gelijk ingebouwd. Erg frustrerend.

Ik zou bijna zeggen dat wij dezelfde collega hebben.

Ik heb er ook zo eentje in mijn team zitten die een leuke functietitel heeft vergaard bij zijn detacheerder, maar qua niveau op alle fronten junior is. Wel met de houding alsof hij echt briljant is in zijn werk. Van mij en onze architect wil hij nog wel het één en ander accepteren, maar onze andere developers en onze testers moeten hun mond houden, want hij doet dit werk al langer en weet het dus veel beter. Helaas is het juist omgekeerd en krijgt hij vaak goede feedback op de bagger die hij produceert, maar die weigert hij te aanvaarden.
Gelukkig wordt ie binnenkort vervangen, maar zijn vervanger mag wel aardig gaan puinruimen in dat deel van de codebase.

[bwerg]

Hydra schreef op woensdag 16 mei 2018 @ 17:11:
Sowieso is een taal zelf nooit "compiled" of "interpreted".

Oh ja, dat is nog een wat fundamentelere opmerking...

[Hydra]

Mugwump schreef op woensdag 16 mei 2018 @ 17:19:
Ik zou bijna zeggen dat wij dezelfde collega hebben.

Mja. Dit komt helaas erg vaak voor. Slechte developers doen er alles aan om te verbergen dat ze slecht zijn. Da's makkelijker dan toegeven dat je niet alles weet. Maargoed; jij blij dat 'ie vertrekt in ieder geval. In mijn geval heb ik 't geluk dat ik zelf binnenkort vertrek.

[Mugwump]

Hydra schreef op woensdag 16 mei 2018 @ 17:42:
[...]


Mja. Dit komt helaas erg vaak voor. Slechte developers doen er alles aan om te verbergen dat ze slecht zijn. Da's makkelijker dan toegeven dat je niet alles weet. Maargoed; jij blij dat 'ie vertrekt in ieder geval. In mijn geval heb ik 't geluk dat ik zelf binnenkort vertrek.

Het is een project bij een klant, dus ik kan altijd zelf nog weg. Ik vind het alleen inhoudelijk wel een interessante uitdaging. Het front-end stuk waar hij op zit vind ik dan weer niet zo boeiend, maar het moet ook niet verbaggeren waardoor driekwart van onze dev / test resources daarin gaat zitten. Meneer bleek ook al een aardig "dossier" te hebben opgebouwd bij deze klant qua berispingen vanwege zijn gedrag. Ik viel echt van mijn stoel toen ik dat hoorde. Het is gewoon inhuur, dus ik zou na twee keer zo'n incident gewoon vervanging eisen of zelf vervanging regelen als klant.

[Hydra]

Had pas nog een discussie met management waarin ik stelde dat ze de schade die een slechte developer doen onderschat. Ze geloven me nog steeds niet heb ik 't idee

[Alain]

Een collega van mij kreeg een paar weken terug te horen van een directeur dat hij kwalitatief slechte software had geleverd. De directeur had zich laten informeren door een clubje die nog nooit een letter code van hem hebben gezien. Ik moet toegeven dat het project niet lekker loopt, maar dat heeft niks met zijn code te maken. Dat zit best goed in elkaar (en ja, ik heb de code wel gezien). Iets met aan stoelpoten zagen ...

Gelukkig heeft die directeur de zak gekregen en niet mijn collega.

[Lethalis]

Hydra schreef op woensdag 16 mei 2018 @ 16:35:
[...]
Niks. Hij's ouder dus heeft z'n gelijk ingebouwd. Erg frustrerend.

Dat lijkt me idd erg frustrerend.

Je schrijft dat het op architectuur niveau is. Zou je een voorbeeld kunnen geven van wat hij doet?

Ik probeer op mijn werk iets aan de DLL hell te doen. Bijvoorbeeld een control library die een reference heeft naar een data access library, terwijl het netter was geweest als de controls simpelweg bepaalde gegevens hadden ontvangen via een abstractie en dus niet zelf met de database gaan praten.

Dus stel je hebt een controller die formatting bepaalt op basis van een data dictionary (bijvoorbeeld "klantnummer is altijd een getal van 0 tot 99999999") dan zou je hiervoor een interface kunnen maken (IFormattingController bijvoorbeeld).

De implementatie bepaalt dan waar die gegevens vandaan komen en de control library hoeft daar niks van te weten in principe.

Maar goed, dat vinden mensen vaak te veel werk vergeleken met "add reference" en een paar regels code kloppen met een query.

[Hydra]

Lethalis schreef op donderdag 17 mei 2018 @ 09:48:
Je schrijft dat het op architectuur niveau is. Zou je een voorbeeld kunnen geven van wat hij doet?

Liever niet in detail. Maar hij maakt dingen nodeloos complex zonder enig inzicht in welke problemen het in de toekomst op gaat leveren. En daarnaast doet 'ie het zonder enige vorm van overleg.

[Ryur]

Ik heb vroeger met 2 soorten collega's gewerkt:

1) "Het werkt toch", echt houtje-touwtje
2) Het juist onnodig complex maken. Zelfs voor de meest simpele oplossingen helemaal complex bouwen, meestal "wat als er uiteindelijk een uitbereiding komt?". Ik ben daar 4 jaar geleden weggegaan, en de app heeft maar 1 jaar in productie gedraaid. Daarna heeft een andere softwarebedrijf de opdracht gekregen (waarschijnlijk omdat een aanpassing te duur was)

Van beide situaties werd je niet blij!

[Crazy D]

Lethalis schreef op donderdag 17 mei 2018 @ 09:48:
Ik probeer op mijn werk iets aan de DLL hell te doen. Bijvoorbeeld een control library die een reference heeft naar een data access library, terwijl het netter was geweest als de controls simpelweg bepaalde gegevens hadden ontvangen via een abstractie en dus niet zelf met de database gaan praten.

Dus stel je hebt een controller die formatting bepaalt op basis van een data dictionary (bijvoorbeeld "klantnummer is altijd een getal van 0 tot 99999999") dan zou je hiervoor een interface kunnen maken (IFormattingController bijvoorbeeld).

De implementatie bepaalt dan waar die gegevens vandaan komen en de control library hoeft daar niks van te weten in principe.

Maar goed, dat vinden mensen vaak te veel werk vergeleken met "add reference" en een paar regels code kloppen met een query.

In de basis, eens. Maar ik zie het ook nog weleens dat echt werkelijk alles via interfaces is opgelost terwijl de omgeving waarin die software draait (add-on binnen standaard product) er geen meerwaarde voor is (maar wel de nadelen zoals meer tijd om alle interfaces te maken zonder voordeel die je normaal wel hebt als je interfaces gebruikt).

[Mugwump]

Ryur schreef op donderdag 17 mei 2018 @ 11:28:
Ik heb vroeger met 2 soorten collega's gewerkt:

1) "Het werkt toch", echt houtje-touwtje
2) Het juist onnodig complex maken. Zelfs voor de meest simpele oplossingen helemaal complex bouwen, meestal "wat als er uiteindelijk een uitbereiding komt?". Ik ben daar 4 jaar geleden weggegaan, en de app heeft maar 1 jaar in productie gedraaid. Daarna heeft een andere softwarebedrijf de opdracht gekregen (waarschijnlijk omdat een aanpassing te duur was)

Van beide situaties werd je niet blij!

Het vinden van de juiste mate van structuur is ook precies de uitdaging van software-architectuur. Zeker in agile omgevingen ga je niet meer op voorhand tot in detail uitkauwen wat er moet gebeuren en hoe dat dan gebouwd moet worden. Dan moet je op basis van een redelijk summiere visie en initiële requirements proberen te bepalen hoe je een basisarchitectuur op kunt zetten die anticipeert op wat er allemaal komen gaat. Dat anticiperen betekent vooral dat je de boel zodanig opzet dat je niet gelijk bij nieuwe requirements enorm veel tijd kwijt bent aan het herstructureren van je code of waarbij je na een half jaar eigenlijk overnieuw moet beginnen omdat je vastzit in de bestaande architectuur, die niet meer voldoet.

Eenvoud is ook de essentie van een goede architectuur. Natuurlijk is in een web-based systeem rechtstreeks vanuit een controller een SQL query afvuren op een database lekker snel en simpel, maar hoe ga je dat unit testen? Je bent al snel je halve systeem aan het mocken om basale logica te testen.
Clean Architecture van Robert C. Martin bevat wel hele mooie heldere beschrijvingen van architecturele principes en goede uitleg over nut en noodzaak. In mijn ogen wel een boek dat elke developer gelezen zou moeten hebben.

[TheNephilim]

Mugwump schreef op donderdag 17 mei 2018 @ 11:44:
[...]


Het vinden van de juiste mate van structuur is ook precies de uitdaging van software-architectuur. Zeker in agile omgevingen ga je niet meer op voorhand tot in detail uitkauwen wat er moet gebeuren en hoe dat dan gebouwd moet worden. Dan moet je op basis van een redelijk summiere visie en initiële requirements proberen te bepalen hoe je een basisarchitectuur op kunt zetten die anticipeert op wat er allemaal komen gaat. Dat anticiperen betekent vooral dat je de boel zodanig opzet dat je niet gelijk bij nieuwe requirements enorm veel tijd kwijt bent aan het herstructureren van je code of waarbij je na een half jaar eigenlijk overnieuw moet beginnen omdat je vastzit in de bestaande architectuur, die niet meer voldoet.

Dat denk ik ook, dat structuur/architectuur de grote uitdaging is. Persoonlijk heb ik daar nog wel eens moeite mee; iets zo eenvoudig mogelijk houden, maar wél de juiste beslissingen nemen om alles op de juiste manier weg te zetten.

Eenvoud is ook de essentie van een goede architectuur. Natuurlijk is in een web-based systeem rechtstreeks vanuit een controller een SQL query afvuren op een database lekker snel en simpel, maar hoe ga je dat unit testen? Je bent al snel je halve systeem aan het mocken om basale logica te testen.
Clean Architecture van Robert C. Martin bevat wel hele mooie heldere beschrijvingen van architecturele principes en goede uitleg over nut en noodzaak. In mijn ogen wel een boek dat elke developer gelezen zou moeten hebben.

Daar ben ik de laatste tijd veel mee bezig, goede tests proberen te schrijven, maar dat is vaak nog wel een uitdaging. Feature tests willen nog wel lukken en Unit tests als in "voer x in en verwacht y", maar mocken/api-clients testen/etc. is nog wel een puntje van aandacht.

[Hydra]

Ryur schreef op donderdag 17 mei 2018 @ 11:28:
2) Het juist onnodig complex maken.

Dingen simpel kunnen houden is een van de belangrijkste skills als developer. Eentje die maar heel weinig developers als belangrijk zien helaas. Veel mensen denken dat je 'indruk' maakt door shit zo complex mogelijk te maken.

[Ryur]

Hydra schreef op donderdag 17 mei 2018 @ 12:00:
[...]


Dingen simpel kunnen houden is een van de belangrijkste skills als developer. Eentje die maar heel weinig developers als belangrijk zien helaas. Veel mensen denken dat je 'indruk' maakt door shit zo complex mogelijk te maken.

Zo mee eens!

Ik vind daarin de mening van David Heinemeier Hansson (de ontwikkelaar van Ruby on Rails met een zeer sterke mening) ook zo tof.
Die is van mening als je ook zowat de hele oplossing moet mocken om te gaan Unittesten, ben je dan niet je doel voorbij aan het schieten?
Hoe weet je dan of je mocks wel werken?

Zijn keynote bij de Railsconf 2018 vond ik daarom zo tof:
YouTube: RailsConf 2017: Opening Keynote by David Heinemeier Hansson

[Lethalis]

Crazy D schreef op donderdag 17 mei 2018 @ 11:42:
[...]
In de basis, eens. Maar ik zie het ook nog weleens dat echt werkelijk alles via interfaces is opgelost terwijl de omgeving waarin die software draait (add-on binnen standaard product) er geen meerwaarde voor is (maar wel de nadelen zoals meer tijd om alle interfaces te maken zonder voordeel die je normaal wel hebt als je interfaces gebruikt).

Zoals met alles, kun je er natuurlijk in doorschieten.

Zo zijn er mensen die data access code helemaal opsplitsen in een ICustomerRepository, CustomerRepositoryImpl, CustomerRepositoryMock enzovoorts. Allemaal heel leuk voor als je "ooit eens een andere (database) backend wil gebruiken".

Maar ja, als je dat in de praktijk nooit doet voor bestaande producten, dan heeft dat allemaal geen zin.

Ook zijn er mensen die echt alles willen unit testen, inclusief elke data access code. Dat vind ik ook te ver gaan.

Persoonlijk ben ik dan ook meer een fan van integration tests die daadwerkelijk controleren of je een klant uit een testdatabase kunt opvragen, dan een test die controleert of CustomerRepository.GetCustomerById(int customerId) wel wordt aangeroepen in een mock.

[bwerg]

Lethalis schreef op donderdag 17 mei 2018 @ 12:08:
Ook zijn er mensen die echt alles willen unit testen, inclusief elke data access code. Dat vind ik ook te ver gaan.

code:

foo.setBar(bar)
assert(foo.getBar() == bar)

Yes! Mijn automatisch gegenereerde getter en setter werken!

En helemaal 'next level' is om niet alleen de getter en setter te genereren, maar ook deze unit test.

[ThomasG]

bwerg schreef op donderdag 17 mei 2018 @ 12:33:
[...]

code:

foo.setBar(bar)
assert(foo.getBar() == bar)

Yes! Mijn automatisch gegenereerde getter en setter werken!

En helemaal 'next level' is om niet alleen de getter en setter te genereren, maar ook deze unit test.

Wat op zich niet zo slecht is Dan weet je ten minste zeker dat het altijd volgens de specificatie werkt. Het zal niet de eerste keer zijn dat iemand de setter en/of getter stuk maakt, ookal zijn ze (initieel) 'automatisch' gegenereerd.

[Mugwump]

Lethalis schreef op donderdag 17 mei 2018 @ 12:08:
[...]

Zoals met alles, kun je er natuurlijk in doorschieten.

Zo zijn er mensen die data access code helemaal opsplitsen in een ICustomerRepository, CustomerRepositoryImpl, CustomerRepositoryMock enzovoorts. Allemaal heel leuk voor als je "ooit eens een andere (database) backend wil gebruiken".

Maar ja, als je dat in de praktijk nooit doet voor bestaande producten, dan heeft dat allemaal geen zin.

Ook zijn er mensen die echt alles willen unit testen, inclusief elke data access code. Dat vind ik ook te ver gaan.

Persoonlijk ben ik dan ook meer een fan van integration tests die daadwerkelijk controleren of je een klant uit een testdatabase kunt opvragen, dan een test die controleert of CustomerRepository.GetCustomerById(int customerId) wel wordt aangeroepen in een mock.

Mijn voorkeur gaat doorgaans uit naar middels een BDD-opzet integratietesten uitvoeren om het systeem in z'n geheel te testen. Dus gewoon het hele systeem opspinnen en je testcases afdraaien door API calls te doen, berichten op messaging infrastructuur te zetten of uit te lezen en ga zo maar door. Via de UI testen kan natuurlijk ook, maar dat is doorgaans een stuk trager en dus niet heel geschikt voor relatief korte testruns in een build / release pipeline.

Een collega was al vrolijk begonnen om unit tests voor API controllers te maken om te checken of een API controller netjes een 404 of een 409 teruggeeft als de aanroep van gemockte repositories / services / facades een bepaalde returnwaarde of exception teruggaven, maar die heb ik maar even uitgelegd waarom ik dat echt volkomen loze tests vind.

Unit tests hebben zeker hun nut, maar testen heel specifiek business / domain logica. In mijn huidige project is de kern van het systeem event sourced. Daarin kan je tests van die logica heel makkelijk schrijven in de vorm van event(s) + command = event(s), oftewel given event(s), if command, then event(s). Daarbij heb ik dan een Eventstore interface met eigenlijk alleen een Save(events) en een GetEventstream(streamId) en voor de testsuite gewoon een in-memory implementatie. Dit is secondenwerk en kan mooi als onderdeel van je build draaien.
Voor de niet event sourced onderdelen van het systeem is het gewoon zaak te zorgen dat je de boel goed modelleert in de vorm van aggregates met de juiste encapsulation (van zowel data als gedrag) en isolation. Die hele aggregate weet niets van infrastructuur. Die wordt simpelweg geïnitaliseerd met een bepaalde state, waarna je er operaties op uitvoert met bepaalde resultaten. Prima te unit testen zonder dat je hoeft te mocken.
Als je heel veel aan het mocken bent, dan moet je vooral eens kritisch gaan kijken naar de vraag of je architectuur niet veel te veel tight coupling bevat of dat je hele triviale 'aan elkaar knoop logica' aan het testen bent. Dat laatste moet je wel valideren middels regressie, maar zou ik naar het niveau van integratietests trekken.

[EddoH]

Hydra schreef op donderdag 17 mei 2018 @ 12:00:
[...]


Dingen simpel kunnen houden is een van de belangrijkste skills als developer. Eentje die maar heel weinig developers als belangrijk zien helaas. Veel mensen denken dat je 'indruk' maakt door shit zo complex mogelijk te maken.

En naamgeving... die wordt dan weer graag zo compact mogelijk gehouden. Want hoe cryptischer en korter de naam, hoe meer skillz. Je weet.

Mugwump schreef op donderdag 17 mei 2018 @ 13:22:
[...]

To be honest heb ik geen idee wat je net allemaal hebt uitgelegd

[ Voor 16% gewijzigd door EddoH op 17-05-2018 13:26 ]

[ThomasG]

Mugwump schreef op donderdag 17 mei 2018 @ 13:22:
[...]


Een collega was al vrolijk begonnen om unit tests voor API controllers te maken om te checken of een API controller netjes een 404 of een 409 teruggeeft als de aanroep van gemockte repositories / services / facades een bepaalde returnwaarde of exception teruggaven, maar die heb ik maar even uitgelegd waarom ik dat echt volkomen loze tests vind.

Hoezo zijn dat volkede loze tests? Als het bijvoorbeeld een API is door andere partijen gebruikt wordt is dat toch echt noodzakelijk. Je hebt immers een specificatie hoe de API werkt, dan moet je ook kunnen garanderen dat het ook op die manier werkt. Dus dat het de juiste status codes geeft, ook bij het optreden van een fout.

[acemoo]

EddoH schreef op donderdag 17 mei 2018 @ 13:24:
[...]


En naamgeving... die wordt dan weer graag zo compact mogelijk gehouden. Want hoe cryptischer en korter de naam, hoe meer skillz. Je weet.


[...]


To be honest heb ik geen idee wat je net allemaal hebt uitgelegd

Een variabele genaamd io, mag je raden waar die voor staat.

[Mugwump]

ThomasG schreef op donderdag 17 mei 2018 @ 13:27:
[...]
Hoezo zijn dat volkede loze tests? Als het bijvoorbeeld een API is door andere partijen gebruikt wordt is dat toch echt noodzakelijk. Je hebt immers een specificatie hoe de API werkt, dan moet je ook kunnen garanderen dat het ook op die manier werkt. Dus dat het de juiste status codes geeft, ook bij het optreden van een fout.

Ik bedoel dat dat volkomen loze unit tests zijn. Je mockt immers je halve systeem en checkt alleen een (hopelijk) heel triviaal stukje code. In mijn ogen vang je dit soort zaken af op integratietestniveau. Dan test je namelijk het daadwerkelijke gedrag van je systeem. Als je repositories / services / facades namelijk niet altijd de juiste waardes of exceptions teruggeven, dan kunnen je mocks dat wel doodleuk doen, maar dan werkt je systeem echt niet zoals het hoort.

[EddoH]

br men schreef op donderdag 17 mei 2018 @ 13:27:
[...]


Een variabele genaamd io, mag je raden waar die voor staat.

voor de assignment operator?

[acemoo]

EddoH schreef op donderdag 17 mei 2018 @ 13:32:
[...]


voor de assignment operator?

[farlane]

Mugwump schreef op donderdag 17 mei 2018 @ 13:22:
[...]
Unit tests hebben zeker hun nut, maar testen heel specifiek business / domain logica. In mijn huidige project is de kern van het systeem event sourced. Daarin kan je tests van die logica heel makkelijk schrijven in de vorm van event(s) + command = event(s), oftewel given event(s), if command, then event(s). Daarbij heb ik dan een Eventstore interface met eigenlijk alleen een Save(events) en een GetEventstream(streamId) en voor de testsuite gewoon een in-memory implementatie. Dit is secondenwerk en kan mooi als onderdeel van je build draaien.
Voor de niet event sourced onderdelen van het systeem is het gewoon zaak te zorgen dat je de boel goed modelleert in de vorm van aggregates met de juiste encapsulation (van zowel data als gedrag) en isolation. Die hele aggregate weet niets van infrastructuur. Die wordt simpelweg geïnitaliseerd met een bepaalde state, waarna je er operaties op uitvoert met bepaalde resultaten. Prima te unit testen zonder dat je hoeft te mocken.

Hmm whut ... ?

[.oisyn]

br men schreef op donderdag 17 mei 2018 @ 13:27:
[...]


Een variabele genaamd io, mag je raden waar die voor staat.

Dat doet me denken aan deze instructie op de PowerPC

[EddoH]

Nog een eigenschap van goede programmeurs is om complexe zaken op simpele en heldere wijze uit te leggen

.oisyn schreef op donderdag 17 mei 2018 @ 13:50:
[...]


Dat doet me denken aan deze instructie op de PowerPC

En die instructie doet mij denken aan

[ Voor 72% gewijzigd door EddoH op 17-05-2018 13:57 ]

[Mugwump]

farlane schreef op donderdag 17 mei 2018 @ 13:48:
[...]


Hmm whut ... ?

Stond misschien wat veel jargon in, maar met 'hmm whut ... ' kan ik natuurlijk niet zoveel.

EddoH schreef op donderdag 17 mei 2018 @ 13:53:
Nog een eigenschap van goede programmeurs is om compelxe zaken op simpele en heldere wijze uit te leggen

Hoe je iets uitlegt hangt altijd af van de kennis en achtergrond van je publiek. Die kan ik op een forum als dit natuurlijk niet makkelijk inschatten.

[ Voor 44% gewijzigd door Mugwump op 17-05-2018 13:55 ]

[.oisyn]

EddoH schreef op donderdag 17 mei 2018 @ 13:53:
En die instructie doet mij denken aan
[afbeelding]

En dat plaatje doet me denken aan

[EddoH]

.oisyn schreef op donderdag 17 mei 2018 @ 14:08:
[...]


En dat plaatje doet me denken aan
[afbeelding]

Aha!

Nee ik moest bij het zien van het plaatje aan hele andere dingen denken eerlijk gezegd......

[.oisyn]

Ja, het is idd wel frappant dat menigeen hier zich bezighoudt met tech, maar jij ondertussen denkt aan kinderliedjes. Maar goed, ieder z'n ding he

[ Voor 5% gewijzigd door .oisyn op 17-05-2018 14:28 ]

[EddoH]

.oisyn schreef op donderdag 17 mei 2018 @ 14:11:
Ja, het is idd wel frappant dat menigeen hier zich bezighoudt met tech, maar jij ondertussen denkt aan kinderliedjes. Maar goed, ieder z'n ding he

[farlane]

Mugwump schreef op donderdag 17 mei 2018 @ 13:54:
[...]
Stond misschien wat veel jargon in, maar met 'hmm whut ... ' kan ik natuurlijk niet zoveel.

Het was ook geen verzoek om het verder uit te leggen .... meer een statement.

Hoe je iets uitlegt hangt altijd af van de kennis en achtergrond van je publiek. Die kan ik op een forum als dit natuurlijk niet makkelijk inschatten.

Point (not offense) taken ....

[farlane]

[whoami]

m

Mugwump schreef op donderdag 17 mei 2018 @ 13:22:
[...]


Mijn voorkeur gaat doorgaans uit naar middels een BDD-opzet integratietesten uitvoeren om het systeem in z'n geheel te testen. Dus gewoon het hele systeem opspinnen en je testcases afdraaien door API calls te doen, berichten op messaging infrastructuur te zetten of uit te lezen en ga zo maar door. Via de UI testen kan natuurlijk ook, maar dat is doorgaans een stuk trager en dus niet heel geschikt voor relatief korte testruns in een build / release pipeline.

Een collega was al vrolijk begonnen om unit tests voor API controllers te maken om te checken of een API controller netjes een 404 of een 409 teruggeeft als de aanroep van gemockte repositories / services / facades een bepaalde returnwaarde of exception teruggaven, maar die heb ik maar even uitgelegd waarom ik dat echt volkomen loze tests vind.

Unit tests hebben zeker hun nut, maar testen heel specifiek business / domain logica. In mijn huidige project is de kern van het systeem event sourced. Daarin kan je tests van die logica heel makkelijk schrijven in de vorm van event(s) + command = event(s), oftewel given event(s), if command, then event(s). Daarbij heb ik dan een Eventstore interface met eigenlijk alleen een Save(events) en een GetEventstream(streamId) en voor de testsuite gewoon een in-memory implementatie. Dit is secondenwerk en kan mooi als onderdeel van je build draaien.
Voor de niet event sourced onderdelen van het systeem is het gewoon zaak te zorgen dat je de boel goed modelleert in de vorm van aggregates met de juiste encapsulation (van zowel data als gedrag) en isolation. Die hele aggregate weet niets van infrastructuur. Die wordt simpelweg geïnitaliseerd met een bepaalde state, waarna je er operaties op uitvoert met bepaalde resultaten. Prima te unit testen zonder dat je hoeft te mocken.
Als je heel veel aan het mocken bent, dan moet je vooral eens kritisch gaan kijken naar de vraag of je architectuur niet veel te veel tight coupling bevat of dat je hele triviale 'aan elkaar knoop logica' aan het testen bent. Dat laatste moet je wel valideren middels regressie, maar zou ik naar het niveau van integratietests trekken.

Dus, dan mock je helemaal niets maar heb je een testsuite runnen tegen jouw services / systeem dat op dev draait bv ?
Ik ben momenteel ook bezig aan een project dat gebruik maakt van een hele rits Azure resources en was ook aan het denken hoe dit het beste te testen. Nu kan je idd al die dependent services (Azure Search, Azure Storage, etc...) gaan mocken, maar op een gegeven moment wil ik wel het ganse systeem 'as is' gaan testen.

[Mugwump]

whoami schreef op vrijdag 18 mei 2018 @ 23:12:
m
[...]

Dus, dan mock je helemaal niets maar heb je een testsuite runnen tegen jouw services / systeem dat op dev draait bv ?
Ik ben momenteel ook bezig aan een project dat gebruik maakt van een hele rits Azure resources en was ook aan het denken hoe dit het beste te testen. Nu kan je idd al die dependent services (Azure Search, Azure Storage, etc...) gaan mocken, maar op een gegeven moment wil ik wel het ganse systeem 'as is' gaan testen.

Niet specifiek dev, gewoon tegen 'een omgeving'. Als je met Azure werkt is het zelfs heel mooi om voor elke run van de integratietests gewoon een hele omgeving 'op te spinnen' via ARM templates die je middels VSTS of anders Powersbell uitrolt. Vervolgens draai je de tests tegen die tijdelijke omgeving en daarna gooi je de boel weer weg. Daar kunnen wel wat haken en ogen aan zitten, bepaalde resources hebben best wat tijd nodig voor de in de lucht zijn bijvoorbeeld, maar als je geen al te exotische zaken gebruikt, dan is dat een mooie optie.

Is dat geen optie dan kun je ze ook tegen een bestaande omgeving draaien. Je moet vaak wel even kijken hoe je met state (oftewel data) omgaat. Ik moet in een project nu bv noodgedwongen de testomgeving gebruiken, maar onze testers willen daar ook handmatig testen en niet steeds bestaande data kwijt zijn. Daarvoor heb ik de integratietests zo ingericht dat ze een backup maken van alles in CosmosDb (de enige storage die we vooralsnog gebruiken), de test draaien tegen een "lege omgeving" en daarna de data backups weer terugzetten. Vereist uiteraard wel enige coördinatie om elkaar niet in de weg te zitten, maar dat gaat meestal prima als je maar communiceert.

[orf]

Misschien wel bekend hier (want erg oud), maar ik vond 'm toch best grappig.

https://www.destroyallsoftware.com/talks/wat

Met mooie dingen als:

JavaScript:

[] + []

spoiler:

"" (lege string)

JavaScript:

[] + {}

spoiler:

[object Object]

JavaScript:

{} + []

spoiler:

0

JavaScript:

{} + {}

spoiler:

NaN

En deze

JavaScript:

Array(16).join("wat");

JavaScript:

Array(16).join("wat" + 1);

JavaScript:

Array(16).join("wat" - 1);

spoiler:

Batman

[XWB]

Ja, die laatste kan ik goed waarderen

[Douweegbertje]

Dat moment dat je al 50 mails hebt gehad over de AVG en of ik mij wilt aan/af -melden. 1 voor 1 afgemeld, zoveel partijen waarvan ik niet eens wist dat ik in hun systeem zit. Prima, dan ben ik er nu echt van af.
En vervolgens krijg ik gisteren gewoon weer een nieuwsbrief terwijl ik mij expliciet had afgemeld en voor die periode nooit iets van ze had gehad.
Like seriously, watdefuck.

[XWB]

Herkenbaar ja.

Douweegbertje schreef op zondag 20 mei 2018 @ 16:38:
En vervolgens krijg ik gisteren gewoon weer een nieuwsbrief terwijl ik mij expliciet had afgemeld en voor die periode nooit iets van ze had gehad.

"Sorry meneer, maar door een bugje waren de gegevens van 1 miljoen klanten toch niet helemaal verwijderd"

[Lethalis]

Douweegbertje schreef op zondag 20 mei 2018 @ 16:38:
Dat moment dat je al 50 mails hebt gehad over de AVG en of ik mij wilt aan/af -melden. 1 voor 1 afgemeld, zoveel partijen waarvan ik niet eens wist dat ik in hun systeem zit. Prima, dan ben ik er nu echt van af.
En vervolgens krijg ik gisteren gewoon weer een nieuwsbrief terwijl ik mij expliciet had afgemeld en voor die periode nooit iets van ze had gehad.
Like seriously, watdefuck.

Weet je zeker dat het niet gewoon een trucje was om jouw emailadres te valideren?

Dus dat een spammer dit gebruikt als smoes...

[Douweegbertje]

Lethalis schreef op zondag 20 mei 2018 @ 16:44:
[...]

Weet je zeker dat het niet gewoon een trucje was om jouw emailadres te valideren?

Dus dat een spammer dit gebruikt als smoes...

nah, het is van holder.nl
Alles om maar een extra persoon voor een mailing te krijgen blijkbaar. Ik ken ze verder niet maar ik heb er opeens wel 3 e-mails van gekregen.



en ik had dus bij de eerste mail al helemaal uitgeschreven.. >.<

[ Voor 6% gewijzigd door Douweegbertje op 20-05-2018 17:25 ]

[XWB]

Maar kies je nou de rode of blauwe pil?

[Douweegbertje]

XWB schreef op zondag 20 mei 2018 @ 17:26:
Maar kies je nou de rode of blauwe pil?

Ik kies voor black. M'n blacklist.

Wat veel bedrijven niet snappen is dat als je mij verveeld met je "trash" dat ik je zo hard op m'n blacklist zet dat wij never nooit ever nog zaken gaan doen.

Ik had het laatst nog met een recruiter die graag mij wilde voorzien van een paar developers. Wat hij niet wist is dat ik wist dat hij ook mijn developers benaderde voor functies.. en niet op een hele nette manier ook. In feite is hij nu een potentiële klant kwijt. Lekker handig toch

[CodeCaster]

Fijn, mailproblemen bij Microsoft. Ik heb op mijn primaire Outlook-account een Action Pack gekocht, maar m'n Visual Studio-account (bewust een ander e-mailadres vanwege spam) ontvangt de uitnodiging om mijn organisatie te joinen maar niet, dus kan ik niet inloggen in Visual Studio... Ook komt de orderbevestiging maar niet binnen.

Dan maar verder hobbyen in Community.

[dcm360]

Tja, e-mail afleveren bij Microsoft... Laten we het er maar op houden dat het een onbetrouwbaar proces is. Onderhand ben ik allang blij dat ik e-mail kan afleveren, dat het standaard in de spam komt is nog wel onhandig maar nog wel te overzien. Ik hoop er maar op dat voldoende mensen daar op 'Niet spam' klikken zodat dat zich ook nog oplost. Maar als ook Microsoft zelf er problemen mee heeft geeft wel aan hoe lastig het is

[.oisyn]

Even een oude post oprakelen

.oisyn schreef op zondag 25 februari 2018 @ 02:41:
Zo, hèhè, eindelijk eens werk gemaakt van een Let's Encrypt cert voor mijn Synology NAS zonder dat ik hem publiekelijk toegankelijk hoef te maken. Het heeft wat voeten in aarde gehad, maar volgens mij werkt het renewen nu ook automatisch, middels dns-01 challenge.

Ik denk alleen nog niet dat ik alle relevante services herstart. In ieder geval wel de webservice (nginx), die is het belangrijkste.

Inmiddels is mijn cert ook al een keer automatisch vernieuwd, dus alles lijkt te werken

[farlane]

Dit weekend voor de grap/test eens een node-red server in elkaar gefriemeld in de google cloud. Eigenlijk met best weinig moeite.....

Misschien gaat dat cloud gebeuren wel *echt* functioneren......

[DeluxZ]

farlane schreef op dinsdag 22 mei 2018 @ 12:27:
Dit weekend voor de grap/test eens een node-red server in elkaar gefriemeld in de google cloud. Eigenlijk met best weinig moeite.....

Misschien gaat dat cloud gebeuren wel *echt* functioneren......

Wat zou er nu niet functioneren dan ?

[Cergorach]

Ryur schreef op donderdag 17 mei 2018 @ 12:06:
Zijn keynote bij de Railsconf 2018 vond ik daarom zo tof:
YouTube: RailsConf 2017: Opening Keynote by David Heinemeier Hansson

Dankjewel! Zeer vermakelijk! ;-)

[Mugwump]

DeluxZ schreef op dinsdag 22 mei 2018 @ 16:22:
[...]


Wat zou er nu niet functioneren dan ?

Ik zou niet meer terug willen naar eigen infra in ieder geval.

[Ryur]

Cergorach schreef op dinsdag 22 mei 2018 @ 17:16:
[...]

Dankjewel! Zeer vermakelijk! ;-)

Dat was die van vorig jaar. Ik bedoelde vooral die van dit jaar:
YouTube: RailsConf 2018: Opening Keynote: FIXME by David Heinemeier Hansson

[raptorix]

Van de week ook een recruiter, met een schreeuwerige mail of ik het niet een enorme uitdaging zou vinden om bijvoorbeeld voor bedrijf XXXXX te werken (nu is XXXXX vrij gerenomeerd), echter heeft mijnheer mijn CV dus niet gelezen, anders had hij geweten dat ik 10 jaar aan XXXXX heb gewerkt

[Mercatres]

En toen ging VSTS onderuit

[farlane]

DeluxZ schreef op dinsdag 22 mei 2018 @ 16:22:
[...]
Wat zou er nu niet functioneren dan ?

T'is nieuwerwets en hip, dus er kan van alles niet functioneren.

[R4gnax]

raptorix schreef op dinsdag 22 mei 2018 @ 17:38:
Van de week ook een recruiter, met een schreeuwerige mail of ik het niet een enorme uitdaging zou vinden om bijvoorbeeld voor bedrijf XXXXX te werken (nu is XXXXX vrij gerenomeerd), echter heeft mijnheer mijn CV dus niet gelezen, anders had hij geweten dat ik 10 jaar aan XXXXX heb gewerkt

Paar jaar geleden ook eentje gehad. Belde me per telefoon dat ze een gigantisch goed passende vacature bij bedrijf ABC gevonden hadden voor functie XYZ.

"Ja, mooie functie heh? Die vacature heb ik zelf helpen opzetten omdat we op zoek zijn naar een collega binnen mijn afdeling." Aan de andere kant van de lijn waren ze in elk geval nog wel zelf-bewust genoeg om ruiterlijk toe te geven wat een enorme blamage dat was.


(We hebben trouwens tenminste nog één andere mede-tweaker - een oud-collega van mij - die ook met min-of-meer hetzelfde te maken heeft gehad. Als ik me goed herinner was het een recruiter die hem de functie voorschotelde waar hij al op gesolliciteerd had en op aangenomen was; oude vacture die al een paar maanden vervuld was.)

[DeluxZ]

farlane schreef op dinsdag 22 mei 2018 @ 23:27:
[...]

T'is nieuwerwets en hip, dus er kan van alles niet functioneren.

[farlane]

DeluxZ schreef op woensdag 23 mei 2018 @ 08:21:
[...]

Zeker nooit met Windows Millenium moeten werken? Only half serious trouwens...

Anyways, ik heb een zekere mate van aversie tegen de vendor lock-in die op die manier weer gecreeerd wordt maar dat is een fact of life ben ik bang.

[Mugwump]

farlane schreef op woensdag 23 mei 2018 @ 10:00:
[...]

Zeker nooit met Windows Millenium moeten werken? Only half serious trouwens...

Anyways, ik heb een zekere mate van aversie tegen de vendor lock-in die op die manier weer gecreeerd wordt maar dat is een fact of life ben ik bang.

Je kunt ook gewoon gaan voor de containeroptie. Dan kun je doorgaans relatief makkelijk switchen van cloud platform.
Al mis je dan wel veel voordelen van de cloudplatformen.

[DeluxZ]

farlane schreef op woensdag 23 mei 2018 @ 10:00:
[...]

Zeker nooit met Windows Millenium moeten werken? Only half serious trouwens...

Anyways, ik heb een zekere mate van aversie tegen de vendor lock-in die op die manier weer gecreeerd wordt maar dat is een fact of life ben ik bang.

Uhm, jawel ik heb met Windows ME gewerkt. Wat heeft dat te maken met de cloud ? In de Azure cloud ben je helemaal niet gebonden aan Microsoft spul hoor. Wil jij lekker een Linux bak, have fun.

[Hydra]

Zit in een discussie met iemand op Reddit die claimt dat "premature optimization is the root of all evil" iets is dat 'ie zelf bedacht heeft

farlane schreef op dinsdag 22 mei 2018 @ 12:27:
Misschien gaat dat cloud gebeuren wel *echt* functioneren......

Welkom in 2010

[ Voor 27% gewijzigd door Hydra op 23-05-2018 11:23 ]

[Douweegbertje]

Mugwump schreef op woensdag 23 mei 2018 @ 10:12:
[...]


Je kunt ook gewoon gaan voor de containeroptie. Dan kun je doorgaans relatief makkelijk switchen van cloud platform.
Al mis je dan wel veel voordelen van de cloudplatformen.

eh wat?
Het maakt toch niet uit wat je draait.. als je gewoon zorgt dat je alles "deployed" via een fatsoenlijke manier kan je eigenlijk overal wel provisionen.

Wij draaien nu iets van ~400 servers in een cloud omgeving.. als ik wil rebuild ik morgen alles in AWS.. of Google cloud.

[farlane]

Hydra schreef op woensdag 23 mei 2018 @ 10:57:
Zit in een discussie met iemand op Reddit die claimt dat "premature optimization is the root of all evil" iets is dat 'ie zelf bedacht heeft

Welkom in 2010

Ik kijk graag eerst de kat uit de boom

Dat gezegd hebbende, in-de-cloud over 1Mbit ADSL was destijds niet echt fijn werken.

Wij draaien nu iets van ~400 servers in een cloud omgeving.. als ik wil rebuild ik morgen alles in AWS.. of Google cloud.

Iets zegt me dat dat een wat te positieve voorstelling van zaken is.....

[ Voor 21% gewijzigd door farlane op 23-05-2018 13:05 ]

[Mugwump]

Douweegbertje schreef op woensdag 23 mei 2018 @ 12:31:
[...]


eh wat?
Het maakt toch niet uit wat je draait.. als je gewoon zorgt dat je alles "deployed" via een fatsoenlijke manier kan je eigenlijk overal wel provisionen.

Wij draaien nu iets van ~400 servers in een cloud omgeving.. als ik wil rebuild ik morgen alles in AWS.. of Google cloud.

Als je IAAS afneemt wel ja. Containerization maakt het nog wat makkelijker. Daarentegen heb je wel degelijk flinke vendor lock-in als je cloudspecifieke PaaS / SaaS afneemt. Kijk bijvoorbeeld naar databases. CosmosDb, Redshift of Spanner migreer je niet "even" naar een andere cloud. Azure functions of AWS Lambda's, de verschillende messaging oplossingen per platform en ga zo maar door.

[alienfruit]

Ik zit momenteel te kijken voor een persoonlijk sponsorprojectie hoe ik het beste alles kan deploy middels TeamCity. Vroeger gebruikte ik Capistrano maar ik weet niet of dat nog een goede oplossing is. Iemand enig idee? Ik maak gebruik van Create React App en Express voor de backend.

[Douweegbertje]

farlane schreef op woensdag 23 mei 2018 @ 12:49:

[...]

Iets zegt me dat dat een wat te positieve voorstelling van zaken is.....

Hm nee ik heb gewoon een dynamic inventory, het is ook juist de fundamentele basis van onze opzet. Ik heb wel eens gehad dat er een keer iets goed fout ging. Uiteindelijk heb ik gewoon de server verwijderd en opnieuw opgezet. 10 minuten later draaide het weer.

Of ik nu de resources van X of Y krijg maakt derhalve dus ook niet uit.

Dat je een "vendor lock" hebt ligt totaal aan jezelf en wat je precies gebruikt, maar cloud betekend niet direct een vendor lock.

[farlane]

Douweegbertje schreef op woensdag 23 mei 2018 @ 15:03:
Dat je een "vendor lock" hebt ligt totaal aan jezelf en wat je precies gebruikt, maar cloud betekend niet direct een vendor lock.

In mijn geval had ik (als test) een Ubuntu VM aangemaakt met daarop node-red. Hartstikke mooi, en (waarschijnlijk) vrij makkelijk naar een andere cloud provider te migreren.

Om je "fleet" van IoT devices te beheren echter (mijn use case) vindt Google dat je hun IoT-Cloud component moet gebruiken, want ja makkelijk. Daar ga je dan ....

Het kan natuurlijk ook op een andere manier, maar dan moet je daar zelf dingen voor gaan bouwen/configureren/onderhouden. Daarmee wordt het (op de korte termijn wellicht) wel erg aantrekkelijk om het Google spul te gaan gebruiken.

[Tjolk]

Nog mensen die naar de Dutch PHP Conference gaan volgende maand?

[Douweegbertje]

farlane schreef op woensdag 23 mei 2018 @ 15:19:
[...]

In mijn geval had ik (als test) een Ubuntu VM aangemaakt met daarop node-red. Hartstikke mooi, en (waarschijnlijk) vrij makkelijk naar een andere cloud provider te migreren.

Om je "fleet" van IoT devices te beheren echter (mijn use case) vindt Google dat je hun IoT-Cloud component moet gebruiken, want ja makkelijk. Daar ga je dan ....

Het kan natuurlijk ook op een andere manier, maar dan moet je daar zelf dingen voor gaan bouwen/configureren/onderhouden. Daarmee wordt het (op de korte termijn wellicht) wel erg aantrekkelijk om het Google spul te gaan gebruiken.

In je eerste voorbeeld;

Eigenlijk wil je "2 builds". -> 1 voor de server (en alle packages, configuraties) en de ander voor je "app".

En ja, veel vendors doen er alles aan om diverse "tools" te maken zodat je een vendor lock krijgt

[Mugwump]

Douweegbertje schreef op woensdag 23 mei 2018 @ 15:30:
[...]


In je eerste voorbeeld;

Eigenlijk wil je "2 builds". -> 1 voor de server (en alle packages, configuraties) en de ander voor je "app".

En ja, veel vendors doen er alles aan om diverse "tools" te maken zodat je een vendor lock krijgt

Het is niet puur om een vendor lock-in te krijgen. Het maakt ook je ontwikkeling doorgaans een stuk sneller en je beheer een stuk makkelijker. Een VM opspinnen is niet zo'n punt, maar als je VMs gaat draaien met je eigen messaging infra (of dat nou ActiveMQ, Kafka, Rabbit of whatever is), dan heb je ook expertise nodig op het beheer van dat soort zaken, moet je zelf een vorm van schaalbaarheid gaan inbakken en ga zo maar door. Bij een PaaS-variant ben je doorgaans zelf niet verantwoordelijk voor dat beheer en is er vaak out-of-the-box autoscaling en dergelijke.
Het is vooral een keuze die je maakt. Hoe 'hoger in de stack', des te minder kennis en expertise die je zelf hoeft te hebben over alle technische details omtrent opzet, configuratie, monitoring en beheer, inrichting van failovers en ga zo maar door. Nadeel is dat je dan dus weer niet heel makkelijk migreert van AWS naar Azure of Google Cloud.

[Refox]

Hydra schreef op woensdag 23 mei 2018 @ 10:57:
Zit in een discussie met iemand op Reddit die claimt dat "premature optimization is the root of all evil" iets is dat 'ie zelf bedacht heeft

Toevallig een discussie met Donald Knuth op Reddit?

[Douweegbertje]

Mugwump schreef op woensdag 23 mei 2018 @ 16:28:
[...]


Het is niet puur om een vendor lock-in te krijgen. Het maakt ook je ontwikkeling doorgaans een stuk sneller en je beheer een stuk makkelijker. Een VM opspinnen is niet zo'n punt, maar als je VMs gaat draaien met je eigen messaging infra (of dat nou ActiveMQ, Kafka, Rabbit of whatever is), dan heb je ook expertise nodig op het beheer van dat soort zaken, moet je zelf een vorm van schaalbaarheid gaan inbakken en ga zo maar door. Bij een PaaS-variant ben je doorgaans zelf niet verantwoordelijk voor dat beheer en is er vaak out-of-the-box autoscaling en dergelijke.
Het is vooral een keuze die je maakt. Hoe 'hoger in de stack', des te minder kennis en expertise die je zelf hoeft te hebben over alle technische details omtrent opzet, configuratie, monitoring en beheer, inrichting van failovers en ga zo maar door. Nadeel is dat je dan dus weer niet heel makkelijk migreert van AWS naar Azure of Google Cloud.

yea, helemaal true

Wij doen trouwens Openstack gebruiken. Ik heb af en toe wel eens berekeningen gemaakt maar AWS is letterlijk een factor 10 duurder dan onze oplossing. Such a shame. Als het nou ~2x duurder was had ik ook wel een andere keuze gemaakt.

[Mugwump]

Douweegbertje schreef op woensdag 23 mei 2018 @ 17:00:
[...]


yea, helemaal true

Wij doen trouwens Openstack gebruiken. Ik heb af en toe wel eens berekeningen gemaakt maar AWS is letterlijk een factor 10 duurder dan onze oplossing. Such a shame. Als het nou ~2x duurder was had ik ook wel een andere keuze gemaakt.

Klopt, het scheelt wel fors vaak, zeker als je niet heel makkelijk dynamisch kan schalen.
Ik ziet nu bij een klant die geld zat heeft en doodleuk van ons eist dat we zo hoog mogelijk in de stack gaan zitten, dus daar heb ik een keiharde Microsoft lock-in. Wel weer veel zaken die het leven een heel stuk makkelijker maken.

[DevWouter]

Goed, nieuwe dag, nieuwe kansen op falen. Ik was gisteren bijna klaar met een nieuwe WYSIWYMIGHTGET editor te integreren, maar ik moest nog 1 ding doen.
Gelukkig had ik een todo notitie neer gezet in javascript. Wat ben ik toch slim

JavaScript:

// TODO: Add float

Uhm... Wait... what?
Sinds wanneer heeft javascript floats?
Moest er een dialog getoond worden en moest ik nog het zweven configureren...?

5 minuten later. Oh, ja.... Ik moest afbeeldingen een "float: left" of een "float: right" kunnen geven.

[ Voor 0% gewijzigd door DevWouter op 24-05-2018 10:14 . Reden: Grammar in foute afkorting gefixt ]

[whoami]

Zo, het rondje PullRequest-reviewen zit er na anderhalf uur weer op.

[whoami]

farlane schreef op woensdag 23 mei 2018 @ 15:19:
[...]

In mijn geval had ik (als test) een Ubuntu VM aangemaakt met daarop node-red. Hartstikke mooi, en (waarschijnlijk) vrij makkelijk naar een andere cloud provider te migreren.

Om je "fleet" van IoT devices te beheren echter (mijn use case) vindt Google dat je hun IoT-Cloud component moet gebruiken, want ja makkelijk. Daar ga je dan ....

Het kan natuurlijk ook op een andere manier, maar dan moet je daar zelf dingen voor gaan bouwen/configureren/onderhouden. Daarmee wordt het (op de korte termijn wellicht) wel erg aantrekkelijk om het Google spul te gaan gebruiken.

Van zodra je PaaS gaat, heb je op één of andere manier last van vendor lockin. Maar is dat zo erg ? Ergens kies je voor een technologie en dan ben je daar aan gebonden. Of dat nu in de cloud is of niet.

[Mugwump]

whoami schreef op donderdag 24 mei 2018 @ 10:33:
Zo, het rondje PullRequest-reviewen zit er na anderhalf uur weer op.

Die van mij ook. Tranen in de ogen weer.

[whoami]

Mugwump schreef op donderdag 24 mei 2018 @ 11:08:
[...]


Die van mij ook. Tranen in de ogen weer.

Ik kan niet klagen eigenlijk

[Hydra]

Mugwump schreef op donderdag 24 mei 2018 @ 11:08:
Die van mij ook. Tranen in de ogen weer.

Emotioneel van al die prachtig mooie code die de wereld net een stukje beter gemaakt heeft?

[Mugwump]

whoami schreef op donderdag 24 mei 2018 @ 11:11:
[...]

Ik kan niet klagen eigenlijk

Mijn huidige project bestaat uit twee codebases. Een back end en een front end. Ik ben hoofdzakelijk verantwoordelijk voor de back end, maar doe ook code reviews voor de front end.
In mijn ogen is het belangrijk dat je code schrijft die ook te begrijpen is voor je collega's. Loose coupling, high cohesion, begrijpelijke methodenamen en ga zo maar door. Dan krijg ik dit soort prachtige stukjes code voorschotelt:

C#:

if (viewModel != null)
{            
    if (viewModel.SubViewModels.Any(item => item.Id.Equals(Guid.Empty)))
     {
        var newItem = viewModel.SubViewModels.FirstOrDefault(item => item.Id.Equals(Guid.Empty));
        if (newItem == null)
            return responseMessage;

        var accountId = Context.user.GetCustomProperty("CurrentAccountId");
        if (String.IsNullOrEmpty(viewModel.SourceIdForCopy))
        {
            responseMessage = ItemHandling.CopyItem(newItem, accountId, viewModel.SourceIdForCopy);
        }
        else
        {
            responseMessage = ItemHandling.AddItem(newItem, accountId);
        }

    }
    else
    {
        if (!String.IsNullOrEmpty(viewModel.SelectedItem))
        {
            responseMessage = ItemHandling.UpdateItem(viewModel, viewModel.SelectedItem);
        }
    }
}

[farlane]

whoami schreef op donderdag 24 mei 2018 @ 10:37:
[...]

Van zodra je PaaS gaat, heb je op één of andere manier last van vendor lockin. Maar is dat zo erg ? Ergens kies je voor een technologie en dan ben je daar aan gebonden. Of dat nu in de cloud is of niet.

Aan een technologie gebonden zitten is een groot verschil met aan een vendor gebonden zitten.

[Douweegbertje]

Wellicht een beetje schaamteloze promotie maar we organiseren een event. Ik kan mij voorstellen dat het voor enkele hier best tof kan zijn https://www.eventbrite.co...vider-tickets-46104748544

tl;dr

Een kijkje in onze keuken. Twee talks, gezelligheid en wat drankjes.
Paar onderwerpen die voorbij komen; cloud, openstack, ansible, automation, "onze fouten", misschien wat over clusters & kubernetes.

Gewoon gratis en ik ben nog met domino's bezig om te zien of we pizza's kunnen fixen

[wackmaniac]

Is in de buurt, ik ga het overwegen

[Mugwump]

farlane schreef op donderdag 24 mei 2018 @ 12:59:
[...]

Aan een technologie gebonden zitten is een groot verschil met aan een vendor gebonden zitten.

In een aantal gevallen is dat toch ook gewoon hetzelfde. Gebruik je Oracle of SQL server, dan zit je niet alleen vast aan een technologie, maar ook aan een vendor. En bij open source varianten die door een specifieke partij worden gemaakt zie je ook wel vaak dat je voor 'enterprise features' toch wel van de vendor afhankelijk bent.

[alienfruit]

GDPR crisis meeting, vraag mij echt af wat er nou zo kritiek is voor zo'n conference call

[Marcj]

alienfruit schreef op donderdag 24 mei 2018 @ 13:24:
GDPR crisis meeting, vraag mij echt af wat er nou zo kritiek is voor zo'n conference call

Volgens mij zijn er nu best veel bedrijven in paniek voor morgen. Ook hier moet er nog een aantal dingen tussendoor voor GDPR

[ThomasG]

Marcj schreef op donderdag 24 mei 2018 @ 13:25:
[...]

Volgens mij zijn er nu best veel bedrijven in paniek voor morgen. Ook hier moet er nog een aantal dingen tussendoor voor GDPR

Dat is altijd zo typisch. Bedrijven weten al ruim 2 jaar dat het eraan komt, en alles moet op het laatste moment..

[alienfruit]

Nee hoor, ze zijn hier al 12 maanden mee bezig. Dus daarom snap ik de crisis niet
Hebben ze regelgeving grotendeels aangepast in de laatste paar maanden ofzo?

[ Voor 31% gewijzigd door alienfruit op 24-05-2018 13:34 ]

[Ryur]

alienfruit schreef op donderdag 24 mei 2018 @ 13:33:
Nee hoor, ze zijn hier al 12 maanden mee bezig. Dus daarom snap ik de crisis niet
Hebben ze regelgeving grotendeels aangepast in de laatste paar maanden ofzo?

Nee, maar veel bedrijven kijken niet vooruit

[farlane]

Mugwump schreef op donderdag 24 mei 2018 @ 13:16:
[...]
In een aantal gevallen is dat toch ook gewoon hetzelfde. Gebruik je Oracle of SQL server, dan zit je niet alleen vast aan een technologie, maar ook aan een vendor. En bij open source varianten die door een specifieke partij worden gemaakt zie je ook wel vaak dat je voor 'enterprise features' toch wel van de vendor afhankelijk bent.

Precies mijn punt.

[Tjolk]

ThomasG schreef op donderdag 24 mei 2018 @ 13:32:
[...]
Dat is altijd zo typisch. Bedrijven weten al ruim 2 jaar dat het eraan komt, en alles moet op het laatste moment..

Ellende is alleen dat tot pakweg twee maanden terug de AP nog bij heel veel FAQ items had staan "dit weten we nog niet". Als de autoriteit in kwestie niet weet hoe ze ermee om moeten gaan wordt het lastig om als bedrijf beleid te gaan voeren.

[Hydra]

alienfruit schreef op donderdag 24 mei 2018 @ 13:33:
Nee hoor, ze zijn hier al 12 maanden mee bezig. Dus daarom snap ik de crisis niet
Hebben ze regelgeving grotendeels aangepast in de laatste paar maanden ofzo?

Onze applicatie is ook niet GDPR compliant en er is deze week een blog gepost over GDPR waarin 'we' claimen dat we dat wel zijn.

[Pizzalucht]

Wij hebben van de week een email verstuurd over wijzigingen in de overeenkomsten om te voldoen aan de GDPR.

Ongelofelijk hoe bot sommige mensen kunnen zijn. Mensen die blijven beweren dat ze nooit een account hebben aangemaakt, terwijl we kunnen aantonen dat ze dat wel hebben gedaan. Door in te loggen kan je bij ons je account verwijderen, maar die mensen weigeren dat te doen, omdat wij dit voor hun zouden moeten doen "als ze erom vragen", en als we het niet zouden doen krijgen we volgens hun een boete.

Als mensen een normale reactie kunnen sturen dan wil ik het best even voor ze doen, maar dit soort mensen lijkt te vergeten dat er geen robots maar echte mensen achter de mail zitten.

Ben blij als de GDPR-gekte weer voorbij is

[Hipska]

Nou ik mag toch hopen dat niet iemand manueel naar elke 'klant' een mail heeft gestuurd.

[Pizzalucht]

Hipska schreef op donderdag 24 mei 2018 @ 15:28:
Nou ik mag toch hopen dat niet iemand manueel naar elke 'klant' een mail heeft gestuurd.

Dat niet, maar als iemand reageert komt de mail wel bij support terecht.

[Hydra]

Pizzalucht schreef op donderdag 24 mei 2018 @ 15:31:
Dat niet, maar als iemand reageert komt de mail wel bij support terecht.

GDPR bepaalt dat consent expliciet en op-in is, dus het is terecht dat jullie users je erop wijzen dat zonder expliciete consent jullie zelf de accounts moeten verwijderen.

[Pizzalucht]

Hydra schreef op donderdag 24 mei 2018 @ 15:47:
[...]


GDPR bepaalt dat consent expliciet en op-in is, dus het is terecht dat jullie users je erop wijzen dat zonder expliciete consent jullie zelf de accounts moeten verwijderen.

Die mensen hebben al toestemming gegeven, ze hebben zelf een acount aangemaakt en zijn daarbij akkoord gegaan met de voorwaarden

[Hydra]

Pizzalucht schreef op donderdag 24 mei 2018 @ 15:48:
Die mensen hebben al toestemming gegeven, ze hebben zelf een acount aangemaakt en zijn daarbij akkoord gegaan met de voorwaarden

Pre GDPR ja. Daarbij moet e-mailings apart toestemming voor gevraagd worden en moet unsubscriben van emails makkelijk gemaakt worden, zonder in te hoeven loggen.

Dat jij hier zo laconiek over doet is precies de reden dat we hier nu gelukkig goeie richtlijnen voor hebben.

[ Voor 34% gewijzigd door Hydra op 24-05-2018 15:53 ]

[Hipska]

Inderdaad, en die voorwaarden zijn nu gewijzigd.

[Pizzalucht]

Hydra schreef op donderdag 24 mei 2018 @ 15:51:
[...]


Pre GDPR ja. Daarbij moet e-mailings apart toestemming voor gevraagd worden en moet unsubscriben van emails makkelijk gemaakt worden, zonder in te hoeven loggen.

Dat jij hier zo laconiek over doet is precies de reden dat we hier nu gelukkig goeie richtlijnen voor hebben.

Klopt. Maar je doet nu net alsof het om een mailling list gaat oid. Wij valideren liever dat mensen ook daadwerkelijk toegang hebben tot hun account voordat we zonder controle hun acount verwijderen.

Anyway, dat was niet mijn punt. Ik zei ook dat als mensen een gewone mail sturen we dat ook doen.
Maar wat voor mailtjes mensen sturen is niet normaal. Alsof we de duivel zijn. Wij zijn helemaal geen enge dienst ofzo. Mensen registreren zich zelf bij ons, en de enige data die we opslaan is de data die ze zelf invoeren/uploaden.

[ Voor 32% gewijzigd door Pizzalucht op 24-05-2018 15:56 ]