De Devschuur Coffee Corner - Iteratie ➒

[Otherside1982]

Ik was mijn databank refactoring script aan het testen met een heel deel renames erin en kom nog een fout tegen dus voer ik rollback uit en de databank antwoord met Not in transaction. Oops, ik dacht nochtans dat ik een transactie gestart had. Nu zit ik met een databank waarbij de helft van de te hernoemen tabellen zijn hernoemd Nu mag ik die renames terugdraaien en dan pas verder testen

[Korben]

Otherside1982 schreef op donderdag 09 juli 2015 @ 14:54:
Ik was mijn databank refactoring script aan het testen met een heel deel renames erin en kom nog een fout tegen dus voer ik rollback uit en de databank antwoord met Not in transaction. Oops, ik dacht nochtans dat ik een transactie gestart had. Nu zit ik met een databank waarbij de helft van de te hernoemen tabellen zijn hernoemd Nu mag ik die renames terugdraaien en dan pas verder testen

Wees blij dat je niet de helft van de records hebt verwijderd buiten een transactie

[Martindo]

Korben schreef op donderdag 09 juli 2015 @ 15:03:
[...]

Wees blij dat je niet de helft van de records hebt verwijderd buiten een transactie

Dat zou balen zijn, maar we hebben toch wel goede backups?

[DeluxZ]

F.West98 schreef op donderdag 09 juli 2015 @ 13:36:
Ik geloof wel dat het er twee zijn, maar dat zou niet mogen

edit:
Anyway, dat bleek ook niet zo te zijn, maar er ging iets mis met de koppeling van normale objecten aan EF-objecten als het ware. Het werkt weer

Ik snap soms echt niet hoe je sommige dingen voor elkaar krijgt

[farlane]

Ger schreef op donderdag 09 juli 2015 @ 12:12:
[afbeelding]

Is dat die fluit aflevering?

[Mercatres]

farlane schreef op donderdag 09 juli 2015 @ 17:29:
[...]

Is dat die fluit aflevering?

Haha, ja. Als ze met z'n allen op Risa zitten en Data wat grotten aan het verkennen is, toch?

[Swedish Clown]

Draai vanmorgen tests in Staging omgeving met data van gisteren en alles gaat perfect. Draai ik het met data van vandaag, wordt ik om de oren geslingerd met 500 Internal Server Errors. Aan mijn code is geen letter veranderd sinds vanmorgen.

Van de data van gisteren had ik een deel overgeslagen en dat deel returned netjes status code 200

snip

I know .oisyn dat is jouw avatar

Ook animated plaatjes hoeven niet vol met bloed. Denk daar even aan aub.

[ Voor 20% gewijzigd door BtM909 op 09-07-2015 23:34 ]

[Avalaxy]

Brakkie41 schreef op donderdag 09 juli 2015 @ 18:07:
Draai vanmorgen tests in Staging omgeving met data van gisteren en alles gaat perfect. Draai ik het met data van vandaag, wordt word ik om de oren geslingerd met 500 Internal Server Errors. Aan mijn code is geen letter veranderd sinds vanmorgen.

Wat zegt je logging

[Rutix]

Avalaxy schreef op donderdag 09 juli 2015 @ 18:11:
[...]


Wat zegt je logging

Logging? Wat is dat

[Damic]

Jeej een programma van me (Telemeter Indicator.net) nog eens een update gegeven

[Alex)]

DeluxZ schreef op donderdag 09 juli 2015 @ 17:03:
[...]


Ik snap soms echt niet hoe je sommige dingen voor elkaar krijgt

Misschien heeft hij objecten uit een andere context gebruikt? Al dan niet uit een cache of static variable gehaald.

[Firesphere]

Alles gedaan om m'n server sneller/minder belast te maken. Blijkt het te komen door een constante stroom aan bots. ARGH. Kutbots.

[Damic]

* Damic geeft een jat koffie aan Firespere

[Firesphere]

Damic schreef op donderdag 09 juli 2015 @ 20:20:
* Damic geeft een jat koffie aan Firespere

Kun je beter aan m'n server geven

[Alex)]

Firesphere schreef op donderdag 09 juli 2015 @ 19:55:
Alles gedaan om m'n server sneller/minder belast te maken. Blijkt het te komen door een constante stroom aan bots. ARGH. Kutbots.

HTTP? Dan de useragent van die bots in de blocklist zetten (.htaccess, web.config of whatever floats your boat powers your server)

[Firesphere]

Alex) schreef op donderdag 09 juli 2015 @ 20:33:
[...]

HTTP? Dan de useragent van die bots in de blocklist zetten (.htaccess, web.config of whatever floats your boat powers your server)

Googlebot in m'n blocklist lijkt me lichtelijk onverstandig

Hoewel ik google al verteld heb niet zo irritant te doen, blijven er ruime hoeveelheden requests per seconde binnenkomen. Bing evenzo.

Het zijn geen malicious bots ofzo, die worden wel geblokt in htaccess en door Cloudflare

[Alex)]

Als alternatief een rate limiter inbouwen? Na X requests per seconde een HTTP 420 (Enhance Your Calm) terugsturen?

[Firesphere]

Alex) schreef op donderdag 09 juli 2015 @ 21:23:
Als alternatief een rate limiter inbouwen? Na X requests per seconde een HTTP 420 (Enhance Your Calm) terugsturen?

Dat is wel een optie inderdaad. Ik heb't nu maar laten lopen, maar erg lekker gaat het nog niet dus

[Damic]

Waarom doet google en bing zoveel requests, daar moet toch een reden voor zijn?!

[Firesphere]

Damic schreef op donderdag 09 juli 2015 @ 21:28:
Waarom doet google en bing zoveel requests, daar moet toch een reden voor zijn?!

Ja, als ik het weet zal ik het delen.

[gekkie]

knap geddost worden door googlebot

[Damic]

Is dat soms dezelfde server als die van dat prijs probleempje, misschien ene link dat gbot volgt.

[ieperlingetje]

Firesphere schreef op donderdag 09 juli 2015 @ 20:39:
[...]

Googlebot in m'n blocklist lijkt me lichtelijk onverstandig

Hoewel ik google al verteld heb niet zo irritant te doen, blijven er ruime hoeveelheden requests per seconde binnenkomen. Bing evenzo.

Het zijn geen malicious bots ofzo, die worden wel geblokt in htaccess en door Cloudflare

Bing respecteert Crawl-Delay in robots.txt, dus die zou je kunnen limiteren.

[Firesphere]

Damic schreef op donderdag 09 juli 2015 @ 21:57:
Is dat soms dezelfde server als die van dat prijs probleempje, misschien ene link dat gbot volgt.

Lijkt me sterk dat een resort naar 1 van mijn sites linkt Nee. Ik heb een URL-wijziging doorgevoerd. Dat schijnt ingewikkeld te zijn

ieperlingetje schreef op donderdag 09 juli 2015 @ 21:58:
[...]


Bing respecteert Crawl-Delay in robots.txt, dus die zou je kunnen limiteren.

Bing gaat ook redelijk. Ietwat irritant, maar gaat redelijk. Googlebot daarentegen heeft echt nul respect voor je server en ramt door.

gekkie schreef op donderdag 09 juli 2015 @ 21:43:
knap geddost worden door googlebot

Nah, niet echt een DDoS, maar er komen momenteel ruim een paar duizend requests per minuut binnen van googlebot. Ikke niet grappig vind

[ Voor 50% gewijzigd door Firesphere op 09-07-2015 22:01 ]

[mrmartijn]

Weet je zeker dat het googlebot is en niet gewoon een random bot die googlebot user agent gebruikt?

Het is vrij makkelijk te valideren volgens de google handleiding: https://support.google.com/webmasters/answer/80553?hl=en

[Swedish Clown]

Avalaxy schreef op donderdag 09 juli 2015 @ 18:11:
[...]


Wat zegt je logging

Mijn logging geeft aan dat "TransactionID cannot be linked to a transaction" wat erop wijst dat er wat mis is gegaan met de export van de data dan wel dat die transactions om wat voor reden dan ook niet meer bestaan.

(Dacht dat ik dit in m'n post had geplaatst maar blijkbaar niet )

Zal morgen de gozer in kwestie maar even aanspreken want het probleem ligt zo te zien niet bij mij.

[F.West98]

Alex) schreef op donderdag 09 juli 2015 @ 19:34:
[...]

Misschien heeft hij objecten uit een andere context gebruikt? Al dan niet uit een cache of static variable gehaald.

De Context zou een singleton moeten zijn maar het lijkt erop dat het met async dingen er toch twee zijn aangemaakt. Toen realiseerde ik me dat een context niet door twee dingen tegelijk kan worden gebruikt dus ik heb de context singleton-af gemaakt en nu lukt het prima.

[Megamind]

Waarom wil je je context überhaupt altijd open hebben? Best practice om 'm te openen, te gebruiken en weer te sluiten.

[F.West98]

Megamind schreef op donderdag 09 juli 2015 @ 23:32:
Waarom wil je je context überhaupt altijd open hebben? Best practice om 'm te openen, te gebruiken en weer te sluiten.

Het was geen applicatie-singleton maar een request-singleton. Data-verwerking wordt afgehandeld door services en die delen allemaal één context omdat ze ook entities kunnen uitwisselen, vandaar dat het één context moet zijn.
In de praktijk gebeurt er weinig communicatie tussen de services en kon ik voor dit specifieke geval wat ombouwen waardoor het geen singleton meer hoeft te zijn.

[BtM909]

F.West98 schreef op donderdag 09 juli 2015 @ 23:34:
[...]

Het was geen applicatie-singleton maar een request-singleton. Data-verwerking wordt afgehandeld door services en die delen allemaal één context omdat ze ook entities kunnen uitwisselen, vandaar dat het één context moet zijn.
In de praktijk gebeurt er weinig communicatie tussen de services en kon ik voor dit specifieke geval wat ombouwen waardoor het geen singleton meer hoeft te zijn.

Misschien echt een domme vraag, maar waar bouw jij in hemelsnaam aan? Je bent constant hier aan 't ranten / vragen / praten / "opmerken" over heel veel verschillende onderdelen.

Je bent toch niet een OS aan 't schrijven ofzo?

[Megamind]

F.West98 schreef op donderdag 09 juli 2015 @ 23:34:
[...]

Het was geen applicatie-singleton maar een request-singleton. Data-verwerking wordt afgehandeld door services en die delen allemaal één context omdat ze ook entities kunnen uitwisselen, vandaar dat het één context moet zijn.
In de praktijk gebeurt er weinig communicatie tussen de services en kon ik voor dit specifieke geval wat ombouwen waardoor het geen singleton meer hoeft te zijn.

Ik zou dan eens heel snel gaan zoeken op Dependency Injection met request lifecycles en het Unit of Work pattern

[F.West98]

BtM909 schreef op donderdag 09 juli 2015 @ 23:36:
[...]

Misschien echt een domme vraag, maar waar bouw jij in hemelsnaam aan? Je bent constant hier aan 't ranten / vragen / praten / "opmerken" over heel veel verschillende onderdelen.

Je bent toch niet een OS aan 't schrijven ofzo?

Megamind schreef op donderdag 09 juli 2015 @ 23:39:
[...]

Ik zou dan eens heel snel gaan zoeken op Dependency Injection met request lifecycles en het Unit of Work pattern

Ik werk door aan een bestaand systeem, gewoon een webapplicatie hoor
Het is .NET MVC, maar het idee is dat controllers geen DB-bewerkingen doen en alles via een service-laag gaat. Dus de controllers doen weinig anders dan rechten controleren en opdrachten doorzetten. Een action is weinig anders dan:

C#:

public ActionResult SomeAction() {
    this.Services.SomeService.SomeAction(someParameters);
}

Met dus wat extra eromheen.

Die services verwerken alles, zetten DB-entities om naar service-entities en terug (doel is om de DB-lib niet als reference te hebben in de web-projecten (beheer en niet-beheer)) en doen CRUD.
Soms hebben sommige services elkaar nodig, anders is het allemaal niet heel DRY. Nu gebruikten alle services een eigen DBContext (bij elk request, de services zijn géén singleton) en ging dat dus mis als je DB-entities ging doorspelen.
Toen had ik van de DBContext een singleton gemaakt voor alle services (nog steeds, elk request wordt er een nieuwe gemaakt natuurlijk), maar toen ging daar dus ergens iets mis, en toen bedacht ik dat het niet nodig was een singleton te gebruiken aangezien services helemaal geen DB-entities naar buiten mogen doorsturen (dan zijn die functies ook voor de controllers zichtbaar en dat wil je niet). Toen heb ik een heel erg klein stukje niet-DRY geschreven om een boel ellende te voorkomen. Dus geen singletons meer, en een paar regels dubbele code.

Een nog beter idee: ik ga hier nooit meer zeuren over *iets* omdat het enkel tijd kost aan uitleg

En die service-opzet heb ik niet bedacht maar die stond er al (half) toen ik er aan ging werken

[Douweegbertje]

Ik ben bezig met een conversie van 200k mails. Althans nu bijna klaar..
Wat een drama altijd. Er is geen fatsoenlijke standaard en bij elke conversie krijg je de data 'gewoon zo' en have fun. Soms ook wel logisch hoor, maar zo lastig om rekening te houden met alles wat mogelijk is in zo'n dataset

[Megamind]

F.West98 schreef op donderdag 09 juli 2015 @ 23:49:
[...]


[...]

Ik werk door aan een bestaand systeem, gewoon een webapplicatie hoor

Ik werk ook aan webapplicaties, maar dat is geen excuus om enterprise patterns erdoorheen te drukken

[F.West98]

Megamind schreef op donderdag 09 juli 2015 @ 23:52:
[...]

Ik werk ook aan webapplicaties, maar dat is geen excuus om enterprise patterns erdoorheen te drukken

Zeg dat maar tegen mijn baas

[Alex)]

F.West98 schreef op donderdag 09 juli 2015 @ 23:49:
[...]

Soms hebben sommige services elkaar nodig, anders is het allemaal niet heel DRY. Nu gebruikten alle services een eigen DBContext (bij elk request, de services zijn géén singleton) en ging dat dus mis als je DB-entities ging doorspelen.
(...)

Dependency injection op de ctor's van de services lijken mij dan de meest nette oplossing, dan hoef je niet te kloten met singletons en andere ellende maar doe je het gewoon zo:

C#:

public class SomeController : BaseController
{
     private IAccountService _accountService;

     public SomeController(IAccountService accountService) { /* ... */ }

     [HttpPost]
     public ActionResult Index()
     {
         return View(_accountService.SendPasswordResetEmail(Request.UserHostAddress));
     }
}

public class AccountService : IAccountService
{
    public AccountService(ICommunicationService communicationService, IUnitOfWork unitOfWork) { /* ... */ }
}

public class EmailService : ICommunicationService
{
    public EmailService(IUnitOfWork unitOfWork) { /* ... */ }
}

En de rest laat je over aan Unity (of een andere DI-container naar keuze). Herbruikaar, testbaar, en vrijelijk herconfigureerbaar.

En die service-opzet heb ik niet bedacht maar die stond er al (half) toen ik er aan ging werken

Wij hebben een soortgelijke opzet. Technisch gezien zouden we vanuit onze controllers wel rechtstreeks aan de DbContext kunnen komen, maar dat is een kwestie van discipline.

Onze controllers doen eigenlijk alleen maar het mappen van DB-objecten naar ViewModels en vice versa.

[ Voor 6% gewijzigd door Alex) op 10-07-2015 00:22 ]

[farlane]

Mercatres schreef op donderdag 09 juli 2015 @ 17:39:
[...]

Haha, ja. Als ze met z'n allen op Risa zitten en Data wat grotten aan het verkennen is, toch?

Bedoelde eigenlijk deze : fluit aflevering

[WernerL]

* WernerL kan geen download link vinden op de NPM website. Moet ik persee node.js installeren om NPM te kunnen gebruiken?

Ik wilde vandaag wat met react.js gaan spelen, maar die gebruikt NPM als package manager blijkbaar.

[F.West98]

Alex) schreef op vrijdag 10 juli 2015 @ 00:19:
[...]

Dependency injection op de ctor's van de services lijken mij dan de meest nette oplossing, dan hoef je niet te kloten met singletons en andere ellende maar doe je het gewoon zo:

C#:

public class SomeController : BaseController
{
     private IAccountService _accountService;

     public SomeController(IAccountService accountService) { /* ... */ }

     [HttpPost]
     public ActionResult Index()
     {
         return View(_accountService.SendPasswordResetEmail(Request.UserHostAddress));
     }
}

public class AccountService : IAccountService
{
    public AccountService(ICommunicationService communicationService, IUnitOfWork unitOfWork) { /* ... */ }
}

public class EmailService : ICommunicationService
{
    public EmailService(IUnitOfWork unitOfWork) { /* ... */ }
}

En de rest laat je over aan Unity (of een andere DI-container naar keuze). Herbruikaar, testbaar, en vrijelijk herconfigureerbaar.

Wij hebben het nog iets anders, elke controller extendt een BaseController die een property Services heeft wat een interface is met links naar alle services. De class die die implementeert doet dan een get:

C#:

public class Services {
    private SomeService someService;
    public SomeService SomeService { get { return someService ?? (someService = new SomeService()); } }
}

Dus dan kan je elke service altijd vanuit elke controller aanroepen zonder zelf nog constructors en alles aan te maken, dat scheelt wel veel code. Services benaderen elkaar wel gewoon door een nieuwe service aan te maken in een private field.

[...]

Wij hebben een soortgelijke opzet. Technisch gezien zouden we vanuit onze controllers wel rechtstreeks aan de DbContext kunnen komen, maar dat is een kwestie van discipline.

Onze controllers doen eigenlijk alleen maar het mappen van DB-objecten naar ViewModels en vice versa.

Er zitten hier nog een boel 'oude' controllers in die nog een boel direct tegen de db praten, dat wordt nu langzaamaan omgezet naar die services. Dan heb je de services die dbentities omzetten naar servcieEntities (die handelen dingen als inheritance van data af, en combineren meerdere dbEntities in één serviceEntity) en de controllers zetten die serviceEntities soms nog om in viewmodels als data gecombineerd moet worden. Dus 2 conversies vanaf de DB-entities, dat wel.

[OkkE]

Staat “NPM” niet voor Node.js Package Manager?
Oftewel, je hebt inderdaad Node.js nodig.

[WernerL]

Ja klopt. Ik had node.js ondertussen al gedownload. Probleem is dat NPM voor zoveel zaken gebruikt wordt wat geen fuck met node.js te maken heeft dat ik hoopte dat het ook los te installeren is. Helaas.

[Martijn19]

WernerL schreef op vrijdag 10 juli 2015 @ 09:46:
Ja klopt. Ik had node.js ondertussen al gedownload. Probleem is dat NPM voor zoveel zaken gebruikt wordt wat geen fuck met node.js te maken heeft dat ik hoopte dat het ook los te installeren is. Helaas.

Was vroeger wel het geval, nu niet meer.

[D-Raven]

F.West98 schreef op vrijdag 10 juli 2015 @ 09:45:
[...]

Wij hebben het nog iets anders, elke controller extendt een BaseController die een property Services heeft wat een interface is met links naar alle services. De class die die implementeert doet dan een get:

C#:

public class Services {
    private SomeService someService;
    public SomeService SomeService { get { return someService ?? (someService = new SomeService()); } }
}

Dus dan kan je elke service altijd vanuit elke controller aanroepen zonder zelf nog constructors en alles aan te maken, dat scheelt wel veel code. Services benaderen elkaar wel gewoon door een nieuwe service aan te maken in een private field.

[...]

Er zitten hier nog een boel 'oude' controllers in die nog een boel direct tegen de db praten, dat wordt nu langzaamaan omgezet naar die services. Dan heb je de services die dbentities omzetten naar servcieEntities (die handelen dingen als inheritance van data af, en combineren meerdere dbEntities in één serviceEntity) en de controllers zetten die serviceEntities soms nog om in viewmodels als data gecombineerd moet worden. Dus 2 conversies vanaf de DB-entities, dat wel.

Eigenlijk moet je geen database entiteiten gebruiken als parameters voor je services. Dan heb je niet al die problemen. Elke service representeert een eigen stukje domein, dan mag daar best een collectie van models bij horen. De services zijn dan zelf verantwoordelijk voor het persisten in je database. Database entiteiten komen dan nooit buiten de service die ze beheerd.

Maargoed makkelijker gezegd dan gedaan om zoiets te doen in een legacy code base.

En naast dat ben ik echt _zo_ klaar met EF, met ORM in het algemeen eigenlijk. Ik gebruik steeds meer Dapper, puur omdat ik de standaard ADO.Net api kut vind.

[ Voor 4% gewijzigd door D-Raven op 10-07-2015 10:55 ]

[Chris7]

WernerL schreef op vrijdag 10 juli 2015 @ 09:36:
* WernerL kan geen download link vinden op de NPM website. Moet ik persee node.js installeren om NPM te kunnen gebruiken?

Ik wilde vandaag wat met react.js gaan spelen, maar die gebruikt NPM als package manager blijkbaar.

Je kan React ook direct vanaf de Facebook CDN includen, dan hoef je Node + NPM niet te installeren. Maar om lokaal iets van NPM te gebruiken moet je inderdaad Node.js installeren. Hoewel je altijd naar de bijbehorende repository kunt gaan, daar is vaak een production.js file beschikbaar.

OkkE schreef op vrijdag 10 juli 2015 @ 09:45:
Staat “NPM” niet voor Node.js Package Manager?
Oftewel, je hebt inderdaad Node.js nodig.

Officieel staat het nergens voor, linksboven op de site staat altijd een random uitleg van het acroniem (waar je trouwens ook aan bij kunt dragen).

[Glorificationer426]

F.West98 schreef op vrijdag 10 juli 2015 @ 09:45:
Services benaderen elkaar wel gewoon door een nieuwe service aan te maken in een private field.

En hoe unit test je zo'n service die met een andere service moet communiceren dan?

[WernerL]

Naughty Push Message

Ik doe het nu trouwens maar zonder NPM. Met JSXTransformer.js kan ik ook zonder de react-tools testen.

[F.West98]

D-Raven schreef op vrijdag 10 juli 2015 @ 10:54:
[...]


Eigenlijk moet je geen database entiteiten gebruiken als parameters voor je services. Dan heb je niet al die problemen. Elke service representeert een eigen stukje domein, dan mag daar best een collectie van models bij horen. De services zijn dan zelf verantwoordelijk voor het persisten in je database. Database entiteiten komen dan nooit buiten de service die ze beheerd.

Maargoed makkelijker gezegd dan gedaan om zoiets te doen in een legacy code base.

En naast dat ben ik echt _zo_ klaar met EF, met ORM in het algemeen eigenlijk. Ik gebruik steeds meer Dapper, puur omdat ik de standaard ADO.Net api kut vind.

Nouja dat bedacht ik me dus ook en dat is nu ook hoe het gaat. Er zijn nu nog maar een paar (nu al legacy) plekken waar dat wel gebeurt, verder dus niet.

Glorificationer426 schreef op vrijdag 10 juli 2015 @ 11:10:
[...]

En hoe unit test je zo'n service die met een andere service moet communiceren dan?

Unit Tests???


Die hebben we niet.

[OkkE]

Chris7 schreef op vrijdag 10 juli 2015 @ 11:08:

Officieel staat het nergens voor, linksboven op de site staat altijd een random uitleg van het acroniem (waar je trouwens ook aan bij kunt dragen).

Haha, zitten een paar leuke suggesties tussen.

[wackmaniac]

Glorificationer426 schreef op vrijdag 10 juli 2015 @ 11:10:
[...]

En hoe unit test je zo'n service die met een andere service moet communiceren dan?

Met Mocks lijkt mij

[Glorificationer426]

wackmaniac schreef op vrijdag 10 juli 2015 @ 11:37:
[...]


Met Mocks lijkt mij

No shit Sherlock . Succes met mocken wanneer je service z'n dependencies zelf instantieert in private fields.

[wackmaniac]

Glorificationer426 schreef op vrijdag 10 juli 2015 @ 11:39:
[...]

No shit Sherlock . Succes met mocken wanneer je service z'n dependencies zelf instantieert in private fields.

Ja, dat geeft wel wat uitdagingen

[Lethalis]

Tsja, persoonlijk voel ik trouwens ook meer voor Integration Tests dan voor Unit Tests.

Ik vind het bijvoorbeeld interessanter dat service X goed met service Y praat in een werkelijke omgeving, dan dat hij goed praat met een mock in een speciaal daarvoor ontworpen testomgeving Wat zegt de test dan precies?

En inversion of control werkt encapsulation ook een beetje tegen. Natuurlijk heeft het ook veel voordelen, maar het maakt debuggen ook een stuk complexer. Je kunt jezelf afvragen of je het altijd nodig hebt (die flexibiliteit).

[ Voor 26% gewijzigd door Lethalis op 10-07-2015 12:04 ]

[Glorificationer426]

Lethalis schreef op vrijdag 10 juli 2015 @ 12:02:
Tsja, persoonlijk voel ik trouwens ook meer voor Integration Tests dan voor Unit Tests.

Het één sluit het ander toch niet uit?

Ik vind het bijvoorbeeld interessanter dat service X goed met service Y praat in een werkelijke omgeving, dan dat hij goed praat met een mock in een speciaal daarvoor ontworpen testomgeving Wat zegt de test dan precies?

Dat je unit under test doet wat je verwacht dat hij doet? Namelijk dependency X volgens plan aanroepen met evt. de juiste parameters En goed gedrag vertonen op basis van wat de aanroep retourneert. Tuurlijk kun je proberen om dit allemaal in integratietests te bouwen, maar dat is al een stuk bewerkelijker. Andere voordelen zoals code coverage, en snellere feedback zodra iemand iets incheckt wat bestaande functionaliteit breekt daargelaten. Bij integratietests zul je meestal toch weer eea moeten deployen voordat je weet of er iets mis is gegaan.

En inversion of control werkt encapsulation ook een beetje tegen. Natuurlijk heeft het ook veel voordelen, maar het maakt debuggen ook een stuk complexer. Je kunt jezelf afvragen of je het altijd nodig hebt (die flexibiliteit).

Waarom maakt dat het debuggen zoveel complexer? Als jouw classes eerlijk zijn over welke dependencies ze nodig hebben (beste voorbeeld daarvan is imo alle dependencies via constructor injection), dan maakt dat alles juist erg inzichtelijk. Misschien niet voor de eerste de beste junior die nooit een IoC container gebruikt heeft, maar dat is gewoon een leermomentje.

[Jan_V]

Glorificationer426 schreef op vrijdag 10 juli 2015 @ 11:39:
[...]

No shit Sherlock . Succes met mocken wanneer je service z'n dependencies zelf instantieert in private fields.

Volgens mij is dat wel mogelijk wanneer je het Fakes Framework gebruikt.
Daar kun je met de `.AllInstances` opgeven wat alle instanties moeten doen, ik dacht ook de zelf geinstantieerde objecten.

Of het handig is, is een tweede natuurlijk

[DeluxZ]

C#:

var foobar = (FooBar)null;

Uh.....?

[Alex)]

Afgesproken codestijl dat je overal 'var' gebruikt en nooit een expliciet type?

Dit kan ook:

C#:

var foobar = default(FooBar);

[RobertMe]

Lethalis schreef op vrijdag 10 juli 2015 @ 12:02:
Tsja, persoonlijk voel ik trouwens ook meer voor Integration Tests dan voor Unit Tests.

Ik vind het bijvoorbeeld interessanter dat service X goed met service Y praat in een werkelijke omgeving, dan dat hij goed praat met een mock in een speciaal daarvoor ontworpen testomgeving Wat zegt de test dan precies?

Unit vs integratie tests af hangt natuurlijk ook af van de complexiteit. Voor een simpel systeem zou ik ook meer voelen voor integration tests, zodat je weet dat de samenwerking ook correct is. Maar als je complexere zaken hebt binnen 1 unit is unit testen IMO wel veel handiger (en sneller met testen).

Zo heb ik eens een hele tijd terug iets gemaakt om LINQ expressions om te zetten naar javascript code (KnockouJS). Daarbij is het dan wel veel handiger om unit tests te hebben zodat je snel kunt testen of een bepaalde LINQ expression nog de juiste (JS) string op levert. In plaats van dat je dus bv een volledige pagina gaat opvragen om vervolgens een stukje HTML eruit te halen.

[DeluxZ]

Alex) schreef op vrijdag 10 juli 2015 @ 12:38:
Afgesproken codestijl dat je overal 'var' gebruikt en nooit een expliciet type?

Dit kan ook:

C#:

var foobar = default(FooBar);

Nee, niet afsproken om 'var' te gebruiken. Als het obvious is dat het een string,int etc is ok, maar anders gewoon het Type ipv 'var'.

[Alex)]

Ik gebruik eigenlijk overal var tegenwoordig. Dat vind ik persoonlijk mooier dan overal types neerzetten.

[Glorificationer426]

Jan_V schreef op vrijdag 10 juli 2015 @ 12:29:
[...]

Volgens mij is dat wel mogelijk wanneer je het Fakes Framework gebruikt.
Daar kun je met de `.AllInstances` opgeven wat alle instanties moeten doen, ik dacht ook de zelf geinstantieerde objecten.

Of het handig is, is een tweede natuurlijk

Wel vrij ranzig Maar er is volgens mij inderdaad erg veel mogelijk met Fakes.

[F.West98]

Alex) schreef op vrijdag 10 juli 2015 @ 13:08:
Ik gebruik eigenlijk overal var tegenwoordig. Dat vind ik persoonlijk mooier dan overal types neerzetten.

Mee eens. R# zet bij mij ook overal lijntjes waar var kan, dus dan gaat dat wel snel en makkelijk. Maar als ik straks weer een tijdje Java heb gedaan zal ik toch weer aan var moeten wennen

[Martindo]

Mehh var bah

[Glorificationer426]

F.West98 schreef op vrijdag 10 juli 2015 @ 13:12:
[...]

Mee eens. R# zet bij mij ook overal lijntjes waar var kan, dus dan gaat dat wel snel en makkelijk. Maar als ik straks weer een tijdje Java heb gedaan zal ik toch weer aan var moeten wennen

Simpel:

Java:

public class Var extends Object {
}

[Alex)]

Martindo schreef op vrijdag 10 juli 2015 @ 13:14:
Mehh var bah

Mehh types expliciet specificeren. Zo onnodig en herhalend.

Glorificationer426 schreef op vrijdag 10 juli 2015 @ 13:14:
[...]

Simpel:

Java:

public class Var extends Object {
}

[F.West98]

https://projectlombok.org/features/val.html

[Martindo]

Alex) schreef op vrijdag 10 juli 2015 @ 13:23:
[...]

Mehh types expliciet specificeren. Zo onnodig en herhalend.

[...]

Ik vind het persoonlijker fijner om in de code meer karakters te tikken om aan te geven van welke datatype het object is. Maarja, smaken verschillen zegt men altijd

[Alex)]

Ik heb de laatste weken vooral Python en JavaScript geschreven, dan heb je daar toch niks aan.

[Lethalis]

Glorificationer426 schreef op vrijdag 10 juli 2015 @ 12:19:
[...]
Het één sluit het ander toch niet uit?

Nee inderdaad, maar in 9 van de 10 projecten die vooral veel CRUD zijn, kun je je afvragen of unit tests zin hebben.

Ik heb ook code waar ik wel unit tests gebruik, maar inderdaad vooral omdat die code complex is.

Waarom maakt dat het debuggen zoveel complexer? Als jouw classes eerlijk zijn over welke dependencies ze nodig hebben (beste voorbeeld daarvan is imo alle dependencies via constructor injection), dan maakt dat alles juist erg inzichtelijk.

Omdat het vaak dependency op dependency wordt. Hoe flexibeler de code wordt, hoe meer kleine classes je hebt, hoe complexer het wordt om in 1 oogopslag te zien wat er gebeurt.

Ik zeg niet dat het slecht is, alleen het aantal keer "step into" groeit wel exponentieel

Afhankelijk van het project, weegt het 1 zwaarder dan het ander. Is het een groot en complex project, dan is IoC een asset waar je veel aan hebt. Heeft het project een kleinere scope en lagere complexiteit, dan wordt het overhead. Er is geen silver bullet zeg maar

[WernerL]

F.West98 schreef op vrijdag 10 juli 2015 @ 13:24:
https://projectlombok.org/features/val.html

Waarom gebruikt lombok val ipv var?
val = immutable value.

Ik vind dat ze het aan moeten passen naar var.

[Merethil]

WernerL schreef op vrijdag 10 juli 2015 @ 13:45:
[...]


Waarom gebruikt lombok val ipv var?
val = immutable value.

Ik vind dat ze het aan moeten passen naar var.

Because copyright

[F.West98]

WernerL schreef op vrijdag 10 juli 2015 @ 13:45:
[...]


Waarom gebruikt lombok val ipv var?
val = immutable value.

Ik vind dat ze het aan moeten passen naar var.

Java:

public class var extends lombok.val {}

[WernerL]

F.West98 schreef op vrijdag 10 juli 2015 @ 13:51:
[...]

Java:

public class var extends lombok.val {}

Het is weer vrijdag zeker?

[Alex)]

F.West98 schreef op vrijdag 10 juli 2015 @ 13:51:
[...]

Java:

public class var extends lombok.val {}

O.o

[F.West98]

Ik denk dat lombok 'm dan niet meer herkent helaas.

[Alex)]

Hallo mede-Tweaker die hier (als het goed is ) werkt :W

[ Voor 28% gewijzigd door Alex) op 10-07-2015 13:57 ]

[F.West98]

Oh goed idee. Ook nog een paar LINQ-extension methods maken (kan ook met Lombok) op de lists, lambda zit er al in (of je hebt er een plugin voor) en je bent helemaal klaar om C# te copy pasten in Java

[Swedish Clown]

Alex) schreef op vrijdag 10 juli 2015 @ 13:56:
[afbeelding]

Hallo mede-Tweaker die hier (als het goed is ) werkt :W

Zwaait terug want ik zit een stukje verderop. (I know je zwaait specifiek naar Prisoner)

[Alex)]

Brakkie41 schreef op vrijdag 10 juli 2015 @ 13:58:
[...]


Zwaait terug want ik zit een stukje verderop. (I know je zwaait specifiek naar Prisoner)

Ohja, jij zit ook in Zweden

[RayNbow]

Alex) schreef op vrijdag 10 juli 2015 @ 13:23:
[...]

Mehh types expliciet specificeren. Zo onnodig en herhalend.

Martindo schreef op vrijdag 10 juli 2015 @ 13:25:
[...]

Ik vind het persoonlijker fijner om in de code meer karakters te tikken om aan te geven van welke datatype het object is. Maarja, smaken verschillen zegt men altijd

[Martindo]

[jbdeiman]

RobertMe schreef op vrijdag 10 juli 2015 @ 12:45:
[...]

Unit vs integratie tests af hangt natuurlijk ook af van de complexiteit. Voor een simpel systeem zou ik ook meer voelen voor integration tests, zodat je weet dat de samenwerking ook correct is. Maar als je complexere zaken hebt binnen 1 unit is unit testen IMO wel veel handiger (en sneller met testen).

Zo heb ik eens een hele tijd terug iets gemaakt om LINQ expressions om te zetten naar javascript code (KnockouJS). Daarbij is het dan wel veel handiger om unit tests te hebben zodat je snel kunt testen of een bepaalde LINQ expression nog de juiste (JS) string op levert. In plaats van dat je dus bv een volledige pagina gaat opvragen om vervolgens een stukje HTML eruit te halen.

Het grote voordeel van unit-tests vs integration tests is imo dat je bij unit testen heel gedetailleerde controle doet op je code en daarmee ook na kan gaan "waar" het fout gaat in je code. Voorwaarde daarbij is wel dat je logica in kleine brokken onderbrengt in eigen (kleine) functies stopt, met bepaalde input en afhankelijk daarvan bepaalde output.

Het mooie van een dergelijke manier van werken is dat je geen code (black-box) hebt waar je iets in gooit aan parameters en vervolgens door allerlei keuzes op basis van die input laat gaan om uiteindelijk een bepaalde waarde terug te geven, maar dat je (relatief) simpele constructies hebt die heel goed te testen zijn: Als a in gaat, dan b uit, anders c (bijvoorbeeld). Zogauw diezelfde functie ineens wat anders gaat doen, loopt alle voorheen geschreven code welke gebruik maakt van deze functionaliteit het risico dat er andere waarden/ resultaten terugkomen dan oorspronkelijk was gedacht en daar weer door onverwacht gedrag kunnen geven.

Toegegeven: Vaak is Unit-testen overkill, maar bouw je een groot/ complex systeem wat jaren mee moet, jaren onderhouden moet worden (en ook best aan verandering onderhevig is) zou ik wel aanraden unit-testen toe te gaan passen.

[Swedish Clown]

Alex) schreef op vrijdag 10 juli 2015 @ 13:59:
[...]

Ohja, jij zit ook in Zweden

Je zit/liep dus langs de kade bij Gamla Stan? Mocht je nog tips willen, hoor ik het wel!

[Erwin537]

Volgende week ben ik ook in Zweden te vinden Maar wel meer in het zuiden.

[WernerL]

* WernerL is vanaf 20 augustus in Zweden te vinden

Tweakers meet in Stockholm?

[OkkE]

Pff, Zweden... * OkkE gaat naar Canada, dat is veel toffer.

[Ealanrian]

OkkE schreef op vrijdag 10 juli 2015 @ 14:53:
Pff, Zweden... * OkkE gaat naar Canada, dat is veel toffer.

Met 3 personen in een Seat MII naar de Mont Blanc en dan op de terugweg ff langs Krakow. Wat nou vliegen

[Neverwinterx]

Martindo schreef op vrijdag 10 juli 2015 @ 13:25:
[...]

Ik vind het persoonlijker fijner om in de code meer karakters te tikken om aan te geven van welke datatype het object is. Maarja, smaken verschillen zegt men altijd

Ik gebruik var enkel om echt grote redudantie zoals bij generics tegen te gaan.

C#:

// deze vervang ik wel:
Dictionary<string, string> dic = new Dictionary<string, string>();
// door dit:
var dic = new Dictionary<string, string>();
// maar dit laat ik gewoon zo staan, hier gebruik ik geen var in
// weinig effect in dit geval, zoveel meer tekst is het nu ook niet
Person p = new Person();
// en hier zou ik het al helemaal niet doen, ander zie je niet in een oogopslag van welk type p is
foreach(Person p in persons)

Spijtig dat resharper geen rule heeft om het enkel om die manier toe te passen.

[F.West98]

OkkE schreef op vrijdag 10 juli 2015 @ 14:53:
Pff, Zweden... * OkkE gaat naar Canada, dat is veel toffer.

Pff, Canada... * F.West98 gaat naar Amerika, dat is veel toffer.
(NYC, Niagara Falls en Washington DC)

edit:
Hmmmpf. Namen verzinnen voor libraries. Altijd leuk

[ Voor 9% gewijzigd door F.West98 op 10-07-2015 15:11 ]

[Jegorex]

F.West98 schreef op vrijdag 10 juli 2015 @ 15:11:
[...]

Pff, Canada... * F.West98 gaat naar Amerika, dat is veel toffer.
(NYC, Niagara Falls en Washington DC)

edit:
Hmmmpf. Namen verzinnen voor libraries. Altijd leuk

Je weet dat je vanuit Canada betere fotos kunt maken van de Niagara Falls?

[Alex)]

Brakkie41 schreef op vrijdag 10 juli 2015 @ 14:37:
[...]


Je zit/liep dus langs de kade bij Gamla Stan? Mocht je nog tips willen, hoor ik het wel!

Ik stond op een Djurgårdenferry

[DamadmOO]

Alex) schreef op vrijdag 10 juli 2015 @ 13:56:
[afbeelding]

Hallo mede-Tweaker die hier (als het goed is ) werkt :W

Daar kom ik normaal ook 2 keer per dag langs

[Swedish Clown]

Alex) schreef op vrijdag 10 juli 2015 @ 15:16:
[...]

Ik stond op een Djurgårdenferry

Close enough! Mocht je er nog niet geweest zijn, Vasaamuseet is zeker de moeite waard! Zeker met het weer wat we vandaag hebben

[OkkE]

F.West98 schreef op vrijdag 10 juli 2015 @ 15:11:
[...]

Pff, Canada... * F.West98 gaat naar Amerika, dat is veel toffer.
(NYC, Niagara Falls en Washington DC)

Eigenlijk zou ik ook naar Amerika gaan, helaas ging die vakantie niet meer door.

Ik zwaai wel vanaf de Canadese kant van Niagara Falls.

Jegorex schreef op vrijdag 10 juli 2015 @ 15:15:
[...]

Je weet dat je vanuit Canada betere fotos kunt maken van de Niagara Falls?

Precies!

[BikkelZ]

Ik kreeg een verzoek om een schatting te maken voor de kosten voor het maken van een app. Ik krijg zes screenshots vol met Lorum Ipsum, alleen de namen van de plaatjes van de schermen hadden een beschrijvende naam (scanner.jpg bijvoorbeeld). In de beschrijving staat dat je dingen moet kunnen uploaden om te printen of kunnen scannen. Wat voor dingen dat dan precies zijn of wat de clou is van het scannen: geen idee. Lijkt iets met QR codes te zijn.

Ik zeg dus: ik snap hier geen reet van. Vervolgens zenden ze me een APK toe, die er PRECIES het zelfde uit ziet als de screenshots. Lorem Ipsum overal. Hoe krijg je het voor elkaar om een APK te bouwen die totaal 0 hints richting de gebruiker geeft?

Tja. En dan natuurlijk zonder een vergoeding te krijgen voor de tijd die ik in deze raming ga steken.

[ Voor 6% gewijzigd door BikkelZ op 10-07-2015 15:31 ]

[Swedish Clown]

BikkelZ schreef op vrijdag 10 juli 2015 @ 15:30:
Ik kreeg een verzoek om een schatting te maken voor de kosten voor het maken van een app. Ik krijg zes screenshots vol met Lorum Ipsum, alleen de namen van de plaatjes van de schermen hadden een beschrijvende naam (scanner.jpg bijvoorbeeld). In de beschrijving staat dat je dingen moet kunnen uploaden om te printen of kunnen scannen. Wat voor dingen dat dan precies zijn of wat de clou is van het scannen: geen idee. Lijkt iets met QR codes te zijn.

Ik zeg dus: ik snap hier geen reet van. Vervolgens zenden ze me een APK toe, die er PRECIES het zelfde uit ziet als de screenshots. Lorem Ipsum overal. Hoe krijg je het voor elkaar om een APK te bouwen die totaal 0 hints richting de gebruiker geeft?

Tja. En dan natuurlijk zonder een vergoeding te krijgen voor de tijd die ik in deze raming ga steken.

Sommige gebruikers hebben echt geen kaas gegeten van het aanleveren van requirements/bugreports.

Ik kreeg hier laatst een bugreport met enkel de beschrijven: "App X is kapot" Uhm, welke van de 32 onderdelen van App X is "kapot" en wat er precies bedoelt wordt met "kapot" is nooit duidelijk geworden. Logs zagen er prima uit en unit tests draaide allemaal perfect dus

[BikkelZ]

Brakkie41 schreef op vrijdag 10 juli 2015 @ 15:34:
[...]


Sommige gebruikers hebben echt geen kaas gegeten van het aanleveren van requirements/bugreports.

Ik kreeg hier laatst een bugreport met enkel de beschrijven: "App X is kapot" Uhm, welke van de 32 onderdelen van App X is "kapot" en wat er precies bedoelt wordt met "kapot" is nooit duidelijk geworden. Logs zagen er prima uit en unit tests draaide allemaal perfect dus

Het is echt zo slecht dat ik bijna denk dat het een grap is. Er zit ook het woord "Hotel" in de naam van de app maar ik heb geen idee wat het met een hotel te maken heeft.

Het mooie is van die "hij doet het niet" bug report mensen: neem je de moeite om te vragen wat precies het probleem is. DAT WEET JIJ BETER DAN IK WANT JIJ HEBT HET STUK GEMAAKT

[ Voor 11% gewijzigd door BikkelZ op 10-07-2015 15:47 ]

[OkkE]

Dat is inderdaad ergernis nummer één: “het is kapot” of “het werkt niet (meer)” ...

Daar is maar één antwoord op: “Niet reproduceerbaar.”

[DeluxZ]

OkkE schreef op vrijdag 10 juli 2015 @ 15:46:
Dat is inderdaad ergernis nummer één: “het is kapot” of “het werkt niet (meer)” ...

Daar is maar één antwoord op: “Niet reproduceerbaar.”

Plek er gewoon een label op met "Feature"

[ObiTewodros]

Oh mijn god github werkt niet goed.

[Douweegbertje]

https://status.github.com/graphs/past_day