De Devschuur Coffee Corner - Iteratie 7

[Patriot]

.oisyn schreef op maandag 25 augustus 2014 @ 17:00:
[...]


Ja. Het is de constructor, dus hij heeft toegang tot alle private variabelen. Dan wordt de __set() alleen nog aangeroepen voor variabelen die nog niet bestaan, wat natuurlijk hooguit alleen bij initialisatie zo is want daarna maak je de variabele aan. Ergo, bovenstaande implementatie is best bullshit

Je hebt helemaal gelijk, stom van me. Laat ik het dan maar gewoon zeggen: Aan de hand van alleen een cosntructor kun je niet weten of het toewijzen van een waarde aan een variabele kan leiden tot een exception. Of beeld je even in dat de waardes in een array worden gestopt met de naam van de variabele als key, dan klopt het voorbeeld

[Sizzla]

PrisonerOfPain schreef op maandag 25 augustus 2014 @ 17:19:
[...]


Wat ik probeer te zeggen dat verschillende lagen verschillende dingen valideren. Je business layer kan bijvoorbeeld zeggen "matched een nederlandse postcode [0-9]{4}\s+[a-zA-Z]{2}" terwijl een database layer kan valideren of de data die je in je varchar veld wilt stoppen wel gewoon past.

Daar zit dan het verschil tussen PHP en Java. Of tussen enterprise ontwikkeling en niet?
Indien in uw databaselaag een fout gegooid wordt dat het niet in een varchar2 past, is dat een technische fout en geen validatie/business fout. Die db fout had je moeten vermijden in je businesslayer.

[incaz]

Sizzla: wat zou er volgens jou dan wel in een setter mogen?

[Sizzla]

in Java: this.field=field; waarbij field private is.

[ Voor 33% gewijzigd door Sizzla op 25-08-2014 17:23 ]

[PrisonerOfPain]

Sizzla schreef op maandag 25 augustus 2014 @ 17:21:
[...]


Daar zit dan het verschil tussen PHP en Java. Of tussen enterprise ontwikkeling en niet?
Indien in uw databaselaag een fout gegooid wordt dat het niet in een varchar2 past, is dat een technische fout en geen validatie/business fout. Die db fout had je moeten vermijden in je businesslayer.

Ik denk dat je een te specifieke betekenis hangt aan het woord validatie .

Desalniettemin blijft het schrijven van "lege" getters en setters een van mijn grootste ergernissen maar die discussie hebben we vorige week (of zo) al gevoerd.

[Sizzla]

PrisonerOfPain schreef op maandag 25 augustus 2014 @ 17:25:
[...]


Ik denk dat je een te specifieke betekenis hangt aan het woord validatie .

Desalniettemin blijft het schrijven van "lege" getters en setters een van mijn grootste ergernissen maar die discussie hebben we vorige week (of zo) al gevoerd.

Klopt, ik zou het woord validatie ten onrechte gelijk stellen aan business validatie. Maar volgens mij valideer je toch altijd tegen regels die eigen zijn aan het functionele? Ik ben niet thuis in de aanpak dat je zou valideren in de data access laag

[ Voor 6% gewijzigd door Sizzla op 25-08-2014 17:29 ]

[Patriot]

Sizzla schreef op maandag 25 augustus 2014 @ 17:21:
[...]


Daar zit dan het verschil tussen PHP en Java. Of tussen enterprise ontwikkeling en niet?
Indien in uw databaselaag een fout gegooid wordt dat het niet in een varchar2 past, is dat een technische fout en geen validatie/business fout. Die db fout had je moeten vermijden in je businesslayer.

Volgens die redenering zou je in je databaselaag nooit iets hoeven proberen te ondervangen

[Sizzla]

Patriot schreef op maandag 25 augustus 2014 @ 17:32:
[...]


Volgens die redenering zou je in je databaselaag nooit iets hoeven proberen te ondervangen

Kan je mij daar dan een voorbeeld van geven, in woorden is goed, welk soort van fouten je zou opvangen in je DB layer, en dus niet doorgegooid wordt?

[alwinuzz]

De conventie in .Net / C# is helder en werkt prima gelukkig. En een property declareren is niet zoveel werk met string Name {get; set;}
Heeft Java geen auto-properties?

[Sizzla]

Zeker, dat heb je met frameworks als Groovy of project lombok. JDK is zelf traag om zo'n features over te nemen. Als ik me niet vergis zit dit wel in de verse Java 8, maar moet ik even opzoeken. Maar ik zie dit eigenlijk meer als een controle, waarbij je moet nadenken of je een veld wil exposen naar buitenaf, en dus die setter/getter schrijft of niet.

[ Voor 29% gewijzigd door Sizzla op 25-08-2014 17:47 ]

[.oisyn]

Sizzla schreef op maandag 25 augustus 2014 @ 17:19:
ik ben juist voor het gebruik van setters, ipv rechtstreeks op de member.

Ok, waarom?
incaz' punt is nou juist dat de traditionele argumenten om voor setters te zijn haaks staan op de eis dat je er totaal geen logica in mag stoppen (het idee is namelijk dat als je setters hebt, het makkelijker wordt om achteraf die logica toe te voegen). Een setter zonder logica waar gegarandeerd ook nooit meer logica ingezet kan of mag worden heeft zijn doel eigenlijk verloren.

Dus, waarom ben jij een voorstander van setters, maar vind je tegelijkertijd dat er geen logica in mag?

[deadinspace]

incaz schreef op maandag 25 augustus 2014 @ 17:22:
Sizzla: wat zou er volgens jou dan wel in een setter mogen?

Sizzla schreef op maandag 25 augustus 2014 @ 17:22:
in Java: this.field=field; waarbij field private is.

Even de rest van de discussie daargelaten, wat is dan nog het nut van getters en setters, als daar altijd alleen maar return this.field; respectievelijk this.field = field; in staat?

[Sizzla]

Sizzla schreef op maandag 25 augustus 2014 @ 17:07:
Om vanuit de businesslaag die setters op te roepen na validatie.

[.oisyn]

Dat is een non-argument, de businesslaag kan ook wel gewoon aan een field assignen.

[EddoH]

Sizzla schreef op maandag 25 augustus 2014 @ 17:22:
in Java: this.field=field; waarbij field private is.

Sorry hoor, maar wat een onzin zeg. Een getter/setter is júist bedoeld om extra logica in te stoppen, anders maak je ze public. Waar ga je anders de benodigde updates bijvoorbeeld verwerken? Dan krijgt de class een methode 'refresh()' of 'update()' oid? Vervolgens vergeet je aan de callende kant een van die methodes aan te roepen en loopt de boel in de soep.

[incaz]

Laten we het er maar op houden dat ik gelukkig niet enterprisy genoeg ben om dat te snappen.

[jip_86]

WPF met OnPropertyChanged is het beste voorbeeld toch

[Sizzla]

Misschien moet de discussie wat genuanceerder over in welke applicaties deze strategiën worden toegepast. Vaak gaat het om herbruikbaarheid (validatie regels erven in overvingsstructuren), loose coupling. Zelfs een simpele check dat je vastketend aan een object door het in de setter te gooien hypotikeerd je domein model. Als je dit afzondert naar een service die je een eigen verantwoordelijkheid geeft, kan je dit toch nog flexibel aanpassen indien die regel er toch ineens uit moet. Dit bovenste is waarschijnlijk een zware overkill indien je met 'simepelere' (met alle respect) domein modellen omgaat, maar toch blijft bovenstaande een good practice. Dit is trouwens de defacto standaard in Java EE. Ook gewoonweg omdat je met 3rd party frameworks zit, die betrouwen op default getters en setters.

Ik kan mij vinden in een besluit dat er wel degelijk een verschil zit in aanpak dat voortvloeit uit de gekozen technologie, en dat soms voor de ene iets waardeloos wordt geacht, maar juist waardevol voor een ander.

[ Voor 20% gewijzigd door Sizzla op 25-08-2014 18:05 ]

[alwinuzz]

Ik ben ook niet enterprisey genoeg om te snappen waarom lege getters en setters beter zijn dan public fields. Tenzij je per regel code wordt betaald
Maar bij java enterprise moet ik altijd hier aan denken: http://discuss.joelonsoft...ult.asp?joel.3.219431.12& (geldt ook voor veel .Net spul trouwens)

Wat is hypotykeerd?

Edit: ow wacht, een standaard, en compatibility met 3d party. Dat zijn tenminste redenen!

[ Voor 12% gewijzigd door alwinuzz op 25-08-2014 18:08 ]

[Caelorum]

incaz schreef op maandag 25 augustus 2014 @ 17:52:
Laten we het er maar op houden dat ik gelukkig niet enterprisy genoeg ben om dat te snappen.

Dit heeft niets met enterprise software te maken (of zelfs maar op een niet hobbykluswijze werken)

.oisyn schreef op maandag 25 augustus 2014 @ 17:49:
Dat is een non-argument, de businesslaag kan ook wel gewoon aan een field assignen.

En dit dus.

Kijk zelf ben ik helemaal geen voorstander van getters en setters, maar dat is een hele andere discussie. Een getter/setter die iets doet dat ik zelf ook kan doen in hetzelfde aantal regels is IMO gewoon helemaal idioot. Dat doe ik liever object.name = "dom object" dan object.SetName("dom object"). Al is het alleen maar omdat in de eerste situatie ik in ieder geval zeker weet wat er gebeurt en ik er in de tweede situatie niet vanuit kan gaan (zelfs als het een "regel" is) dat er niet allerlei side effects zijn (al dan niet tegen de regels in of onopzettelijk gedaan).

[EddoH]

Sizzla schreef op maandag 25 augustus 2014 @ 17:57:
Misschien moet de discussie wat genuanceerder over in welke applicaties deze strategiën worden toegepast. Vaak gaat het om herbruikbaarheid (validatie regels erven in overvingsstructuren), loose coupling. Zelfs een simpele check dat je vastketend aan een object door het in de setter te gooien hypotikeerd je domein model. Als je dit afzondert naar een service die je een eigen verantwoordelijkheid geeft, kan je dit toch nog flexibel aanpassen indien die regel er toch ineens uit moet. Dit bovenste is waarschijnlijk een zware overkill indien je met 'simepelere' (met alle respect) domein modellen omgaat, maar toch blijft bovenstaande een good practice. Dit is trouwens de defacto standaard in Java EE. Ook gewoonweg omdat je met 3rd party frameworks zit, die betrouwen op default getters en setters.

Ik kan mij vinden in een besluit dat er wel degelijk een verschil zit in aanpak dat voortvloeit uit de gekozen technologie, en dat soms voor de ene iets waardeloos wordt geacht, maar juist waardevol voor een ander.

Kun je een concreet voorbeeld geven? Ik kan met de beste wil van de wereld niet begrijpen wat default getters/setters met loose coupling en compatibiliteit met 3rd party sw te maken heeft..

[Rutix]

EddoH schreef op maandag 25 augustus 2014 @ 18:34:
[...]


Kun je een concreet voorbeeld geven? Ik kan met de beste wil van de wereld niet begrijpen wat default getters/setters met loose coupling en compatibiliteit met 3rd party sw te maken heeft..

Dit dus. Ik volg het namelijk ook niet zo en het argument "dit is standard practice in Java EE" legt nog niet uit waarom het een standard practice is

[Firesphere]

Patriot schreef op maandag 25 augustus 2014 @ 16:52:
[...]


Bullshit?

PHP:

function __set($name, $value)
{
  if ($name == "foo" && $value < 0) {
    throw new Exception("Foo not allowed to be less than zero");
  } else {
    $this->{$name} = $value;
  }
}

En dat bewijst... wat precies?

[Merethil]

Rutix schreef op maandag 25 augustus 2014 @ 18:45:
[...]

Dit dus. Ik volg het namelijk ook niet zo en het argument "dit is standard practice in Java EE" legt nog niet uit waarom het een standard practice is

Sterker nog, ik als J2EE developer ben nog nooit tegen deze "standard practice" aangelopen, juist omdat een getter/setter gemaakt is voor validatie of zelfs meer logica in te stoppen. Het gebruik van een public variabele die je écht niet wilt kunnen setten omdat je "nooit" logica daaraan wilt hangen is daar wel de standaard, maar over het algemeen doe je dat niet omdat je altijd de mogelijkheid tot extra logica toevoegen wilt behouden.

[Sizzla]

Het loskoppelen van validatielogica (bvb veld mag enkel waarde hebben > x) in een aparte validatie service/layer/component brengen en dus uit het domein halen is een vorm van loose coupling. De validatie regels zijn apart testbaar, portable, flexibeler etc...

Hibernate is een framework in Java voor ORM. Het mappen en beheren van db records naar objecten. Dit framwork gebruikt de getters en setters van de members die op de enititeiten staan. Wat je wilt is, dat dit een 1:1 mapping is met wat er in de DB zit. De operatie ophalen en terug saven mag liefst geen neveneffecten hebben zoals de entiteit wijzigen. Anders kan je potentieel door data op te halen, je data hebben gewijzigd.

[Patriot]

Firesphere schreef op maandag 25 augustus 2014 @ 18:46:
[...]

En dat bewijst... wat precies?

Nouja, even buiten het feit dat mijn snippet niet klopte omdat hij __set() alleen called op onbestaande variabelen ging het om aan te tonen dat een simpele toewijzing een exception kán gooien.

[Sizzla]

Waar ik dan weer van vind dat dit niet de plaats is om te doen. Overtuigen lukt mij hier niet, omdat er misschien te snel wordt gegrepen naar de simpele manier om meteen public fields te declareren, dan flexibiliteit en structuur te behouden. Maken jullie dan ook nooit een interface als jullie maar 1 implementatie hebben?

[ Voor 67% gewijzigd door Sizzla op 25-08-2014 18:55 ]

[.oisyn]

Sizzla schreef op maandag 25 augustus 2014 @ 18:47:
Hibernate is een framework in Java voor ORM. Het mappen en beheren van db records naar objecten. Dit framwork gebruikt de getters en setters van de members die op de enititeiten staan. Wat je wilt is, dat dit een 1:1 mapping is met wat er in de DB zit. De operatie ophalen en terug saven mag liefst geen neveneffecten hebben zoals de entiteit wijzigen. Anders kan je potentieel door data op te halen, je data hebben gewijzigd.

Je snapt hopelijk dat je daar te maken hebt met kale model objecten. Maar stel je hebt een custom validator, die werkt met instelbare rules. Dus wellicht heb je ergens in je business layer een, jawel, setValidator(). Ja, ook dát is een setter. Waar volgens jou dus geen logica in mag. Sorry, maar dat is absurd. Of ga je dat ook verder abstraheren, met een business layer voor je business layer zodat de extra business layer de validator kan validaten.

[ Voor 10% gewijzigd door .oisyn op 25-08-2014 18:57 ]

[Sizzla]

Ooit gehoord van inversion of control en op te lossen met dependency injection? Het koppelen van stukken logica doe je ook niet zomaar hardcoded. Of wel in PHP?

[.oisyn]

Sizzla schreef op maandag 25 augustus 2014 @ 18:56:
Ooit gehoord van inversion of control en op te lossen met dependency injection?

Ooit gehoord van verschillende methodieken om een systeem te tacklen? IoC en DI zijn geen heilige gralen ofzo.

[Sizzla]

Ik doel toch rechtstreeks op de problematiek die jij aanhaalt om dan maar een setValidator te doen? Niet als algemene oplossing voor alles? Dit zijn tools die je gebruikt om minder code te schrijven en kan gebruiken om deze componenten loosly te koppelen. Lijkt me een klaar antwoord op je vraag.

[ Voor 36% gewijzigd door Sizzla op 25-08-2014 19:00 ]

[incaz]

Want dependency injection is helemaal geen overkill enzo.. ?

Nee, overabstractie is geen good practice, het maakt de boel net zo goed ononderhoudbaar.

Java en 'enterprise software' gaan zo ver in het abstraheren van allerlei zaken dat ze over het hoofd zien dat je sommige dingen gewoon in code wilt uitdrukken omdat het prima past in code. Want voor je het weet krijg je dit soort engigheid: http://thedailywtf.com/Ar...nterprise-User-Agent.aspx

Ergens moet je het echte werk doen. Hoe ver je het ook wegabstraheert, ergens gebeurt het. Wat mij betreft doet het de zaken gewoon in het zicht, in een taal die de devs kennen, met precies de juiste balans tussen abstract en concreet, simpel en complex. Het vinden van die goldilocks-balans is niet altijd eenvoudig, maar meer abstractie is absoluut niet altijd beter.

Gewone code-implementaties (al dan niet van abstracte base classes) kunnen een prima manier zijn om dingen op te lossen op een goede, overzichtelijke, testbare en onderhoudbare manier.

[Sizzla]

Pfja, IoC is een design pattern zoals een ander, waar je eerst van zult afwegen of de complexiteit er mee daalt ipv steigt. Daarom is het afhankelijk met wat voor project je bezig bent. Ik zou ook denken op school waarvoor die design patterns goed zijn, die maken het toch onnodig moeilijk? Je kiest je tools voor de complexiteit die je te wachten staat, en zoals ik al zei, zit daar misschien de nuance waarom dit tot een discussie leidt die niemand snapt.

[EddoH]

Sizzla schreef op maandag 25 augustus 2014 @ 18:47:
Het loskoppelen van validatielogica (bvb veld mag enkel waarde hebben > x) in een aparte validatie service/layer/component brengen en dus uit het domein halen is een vorm van loose coupling. De validatie regels zijn apart testbaar, portable, flexibeler etc...

Hibernate is een framework in Java voor ORM. Het mappen en beheren van db records naar objecten. Dit framwork gebruikt de getters en setters van de members die op de enititeiten staan. Wat je wilt is, dat dit een 1:1 mapping is met wat er in de DB zit. De operatie ophalen en terug saven mag liefst geen neveneffecten hebben zoals de entiteit wijzigen. Anders kan je potentieel door data op te halen, je data hebben gewijzigd.

Zoals ik het begrijp bedoel je alleen maar te zeggen dat de interface consistent moet zijn danwel correct gedrag moet vertonen. Wat de getters en setters intern doen doet er gewoon niet toe. Als een setter een logregel wil schrijven of een update voor eventuele observers wil uitvoeren dan zijn setters prima plekken daarvoor.

[alwinuzz]

Sizzla schreef op maandag 25 augustus 2014 @ 18:50:
..... Maken jullie dan ook nooit een interface als jullie maar 1 implementatie hebben?

Daar ben ik in ieder geval helemaal vanaf gestapt sinds het lezen van een serie posts van Oren Eini / Ayende .

alwinuzz schreef op dinsdag 21 februari 2012 @ 23:16:
[...]

Over een nieuwe kijk op dingen gesproken: volgt iemand het blog van Ayende en zijn serie over architectuur "Limit your abstractions"? (van onder naar boven lezen, dan volg je ook het process en de gedachtegang)
Voor mij is deze serie een enorme eye-opener. Waarom zou je overal een interface voor maken? ICustomerRepository, ICustomerService, ICustomerManager, ICustomerBlabla
En dan elke interface één implementatie. Wat is hiervan de meerwaarde?

Eigenlijk niets, nu ik erover heb nagedacht. Toch was/is dit 'best practice'.
Ik ga het in de toekomst zeker op Ayende's manier proberen: een paar concepten waar een abstractie bij hoort, en de rest zo simpel mogelijk. Geen 100en interfaces meer, maar een stuk of 5.
En dan vooral simpele code, die duidelijk laat zien wat er gebeurt.

Bevalt tot nog toe prima

[.oisyn]

Sizzla schreef op maandag 25 augustus 2014 @ 18:59:
Ik doel toch rechtstreeks op de problematiek die jij aanhaalt om dan maar een setValidator te doen? Niet als algemene oplossing voor alles? Dit zijn tools die je gebruikt om minder code te schrijven en kan gebruiken om deze componenten loosly te koppelen. Lijkt me een klaar antwoord op je vraag.

Ok, fair enough. Maar ben je het er dan mee eens dat jouw gedachtegoed behoorlijk gelimiteerd is tot je eigen belevingswereld? De discussie was een simpele setter in PHP, waarna jij met de opmerking komt dat je setter geen logica moet hebben "of wordt dat gedoogd in PHP?". Het wordt niet alleen "gedoogd" in PHP, het is de normaalste zaak van de wereld in álle programmeertalen, maar blijkbaar niet in de klasse van grote enterprisey applicaties waarin alles enorm weggeabstraheerd is. Tal van alledaagse API's zitten vol met getters en setters, inclusief validation bij het setten.

[ Voor 5% gewijzigd door .oisyn op 25-08-2014 19:34 ]

[EddoH]

https://github.com/hibern...rectPropertyAccessor.java

Regel 175




Overigens een compleet willekeurige file aangeklikt

[Avalaxy]

alwinuzz schreef op maandag 25 augustus 2014 @ 19:15:
[...]

Daar ben ik in ieder geval helemaal vanaf gestapt sinds het lezen van een serie posts van Oren Eini / Ayende .

Sorry voor de misschien domme vraag, maar ik kan niet vinden waar hij met een duidelijke uiteenzetting en oplossing(en) komt? Ik zou ook graag wat minder interfaces hebben, maar ik zie niet in hoe ik dat kan doen zonder mijn applicatie minder loosely-coupled te maken.

[incaz]

Rechtsboven het artikel en dan steeds 'next post'. Soms moet je er een of twee overslaan. (Ik moest ook even kijken.)

[BikkelZ]

incaz schreef op maandag 25 augustus 2014 @ 16:49:
En ik try-catch inderdaad over het algemeen niets tenzij ik exact weet wat ik wil catchen en waarom, en ik denk dat ik daar wat zinnigs mee kan doen. Laat de rest maar klappen hoor.

Inderdaad.

Patriot schreef op maandag 25 augustus 2014 @ 16:52:
[...]


Bullshit?

PHP:

function __set($name, $value)
{
  if ($name == "foo" && $value < 0) {
    throw new Exception("Foo not allowed to be less than zero");
  } else {
    $this->{$name} = $value;
  }
}

Wat je daar doet is het checken op wat de input is en throwen op het moment dat het niet klopt. Ik zeg toch juist dat ik dat ook zou doen?

Ik override niet vaak setters van @property's in Objective-C, je hebt vaak óf side-effects die je meteen ook moet beschrijven in een functienaam om het overzichtelijk te houden of redelijk zinloze checks op > 0, nil ![val equalsTo@""].

[F.West98]

alwinuzz schreef op maandag 25 augustus 2014 @ 19:15:
[...]

Daar ben ik in ieder geval helemaal vanaf gestapt sinds het lezen van een serie posts van Oren Eini / Ayende .


[...]

Bevalt tot nog toe prima

Zijn er echt mensen die dat doen?!
Ik heb echt heel af en toe een interface of abstract class. Vooral in Strategy pattern-implementaties

[RayNbow]

EddoH schreef op maandag 25 augustus 2014 @ 19:54:
https://github.com/hibern...rectPropertyAccessor.java

Regel 175

Je weet dat je ook *rechtstreeks* naar een regel kan linken? Verder is het ook handig om naar een specifieke versie te linken i.p.v. de HEAD:

https://github.com/hibern...ropertyAccessor.java#L175

[Rutix]

F.West98 schreef op maandag 25 augustus 2014 @ 20:31:
[...]

Zijn er echt mensen die dat doen?!
Ik heb echt heel af en toe een interface of abstract class. Vooral in Strategy pattern-implementaties

Ja dat gebeurt. Vooral in grote projecten gebeurt het veel maar ook in kleinere projecten zie ik het soms.

[Patriot]

BikkelZ schreef op maandag 25 augustus 2014 @ 20:19:
[...]


Wat je daar doet is het checken op wat de input is en throwen op het moment dat het niet klopt. Ik zeg toch juist dat ik dat ook zou doen?

Mijn snippet zorgt ervoor dat de toewijzingen in de originele snippet een Exception kunnen gooien (tenminste, als die snippet van mij klopte, want dat is niet helemaal het geval).

Waar het in ieder geval op neer komt is dat er in deze situatie op regel 4 een exception gegooid kan worden, en je alleen kan weten of dat geval is door de context te kennen (standaardgedrag is het niet, maar het was allemaal een beetje tongue-in-cheek en PHP-basherig bedoeld ):

PHP:

function __constructor($foo)
{

  $this->bar = $foo;
}

[BikkelZ]

Ja ik snap nu wat je bedoelt, maar ik zou het dus gewoon lekker laten crashen. User input moet op andere manieren afgehandeld worden en applicatielogica moet gewoon crashen. Kan degene die die functie aanroep niet verwachten dat het mogelijk crasht dan is dat een design probleem. Als je een object aanmaakt wat wel bestaat maar niet de waardes bevat die je verwachtte omdat dat vastliep dan gaat het even verderop vanzelf wel fout.

[Patriot]

BikkelZ schreef op maandag 25 augustus 2014 @ 20:54:
Ja ik snap nu wat je bedoelt, maar ik zou het dus gewoon lekker laten crashen. User input moet op andere manieren afgehandeld worden en applicatielogica moet gewoon crashen. Kan degene die die functie aanroep niet verwachten dat het mogelijk crasht dan is dat een design probleem. Als je een object aanmaakt wat wel bestaat maar niet de waardes bevat die je verwachtte omdat dat vastliep dan gaat het even verderop vanzelf wel fout.

Oh zo, ja, ongetwijfeld hoor. Maargoed, het hele snippet gaf al weinig vertrouwen in de programmeerkunsten. Mijn toevoeging was in die zin ook geen poging om het wat te doen lijken hoor, het ging er (met een knipoog) meer om dat het technisch gezien wel functioneel zou kunnen zijn om op die plek een try catch te hebben.

[Douweegbertje]

Try {
code snippet
{
catch {
enorme shitstorm aan comments
}

Wat een simpele snippet allemaal niet te weeg brengt

_{goede discussies hier, daar niet van..}

[EddoH]

RayNbow schreef op maandag 25 augustus 2014 @ 20:41:
[...]

Je weet dat je ook *rechtstreeks* naar een regel kan linken? Verder is het ook handig om naar een specifieke versie te linken i.p.v. de HEAD:

https://github.com/hibern...ropertyAccessor.java#L175

Lol nee, thx. Ik link eigenlijk nooit naar github. Gebruik het eerlijk gezegd ook te weinig

Edit: wat is de indentation trouwens ruk met die link?

[ Voor 5% gewijzigd door EddoH op 25-08-2014 21:23 ]

[alwinuzz]

F.West98 schreef op maandag 25 augustus 2014 @ 20:31:
[...]

Zijn er echt mensen die dat doen?!
Ik heb echt heel af en toe een interface of abstract class. Vooral in Strategy pattern-implementaties

Het werd als doodnormaal gezien en best-practice om je systeem heel enterprisey in layers te maken met 'services' waarbij je dus een interface had met 1 implementatie. Alles onder het mom van loose coupling en testability. Dit gedoe was afgeleid van hoe het in javaland gebeurde.
Ik volgde deze adviezen als autodidact ook op zonder na te denken, stom. Volgens mij zijn ze er nu in het .net wereldje een beetje vanaf.

En als ik dan iemand die met Java werkt hoor zeggen "Maken jullie dan ook nooit een interface als jullie maar 1 implementatie hebben?", dan krijg ik de kriebels

@Avalaxy, geen domme vraag! Navigeren door blog van Ayende is een ramp, ik zocht me zelf ook suf. Die posts gaan een heel eind door, juist door de kleine stukjes het proces volgen maakte het toendertijd voor mij begrijpelijk.

[BikkelZ]

alwinuzz schreef op maandag 25 augustus 2014 @ 21:22:
[...]

Het werd als doodnormaal gezien en best-practice om je systeem heel enterprisey in layers te maken met 'services' waarbij je dus een interface had met 1 implementatie. Alles onder het mom van loose coupling en testability. Dit gedoe was afgeleid van hoe het in javaland gebeurde.
Ik volgde deze adviezen als autodidact ook op zonder na te denken, stom. Volgens mij zijn ze er nu in het .net wereldje een beetje vanaf.

En als ik dan iemand die met Java werkt hoor zeggen "Maken jullie dan ook nooit een interface als jullie maar 1 implementatie hebben?", dan krijg ik de kriebels

@Avalaxy, geen domme vraag! Navigeren door blog van Ayende is een ramp, ik zocht me zelf ook suf. Die posts gaan een heel eind door, juist door de kleine stukjes het proces volgen maakte het toendertijd voor mij begrijpelijk.

Hoe wil je dan wel naar een situatie gaan waar 100% tests passing betekent dat je zowat geblinddoekt je product kunt release?

Overal interfaces voor gebruiken heeft natuurlijk wel nut als je component per component wil testen. Als ik een mock database adapter kan gebruiken die altijd de zelfde row terug geeft op bepaalde input zonder dat ik daadwerkelijk die hele database nodig heb dan is dat natuurlijk veel beter. In het project waar ik op gewerkt heb waarbij TDD zichzelf echt bewezen heeft in mijn ogen had alles een interface om die reden.

Voor heel veel projecten gebruik ik het dus niet omdat ik gewoon niet tot op dat detail test. Als ik tests schrijf voor mijn eigen software dan maak ik de echte business logic goed testbaar door voor static functions te kiezen en niet overal tussendoor if-thens te gooien maar liever de logica in een apart object te houden. Daardoor zit ik ook niet zo dicht tegen database of UI aan dus hoef ik ook niet te mocken.

[Jan_V]

BikkelZ schreef op maandag 25 augustus 2014 @ 21:37:
[...]


Hoe wil je dan wel naar een situatie gaan waar 100% tests passing betekent dat je zowat geblinddoekt je product kunt release?

Overal interfaces voor gebruiken heeft natuurlijk wel nut als je component per component wil testen. Als ik een mock database adapter kan gebruiken die altijd de zelfde row terug geeft op bepaalde input zonder dat ik daadwerkelijk die hele database nodig heb dan is dat natuurlijk veel beter. In het project waar ik op gewerkt heb waarbij TDD zichzelf echt bewezen heeft in mijn ogen had alles een interface om die reden.

Voor heel veel projecten gebruik ik het dus niet omdat ik gewoon niet tot op dat detail test. Als ik tests schrijf voor mijn eigen software dan maak ik de echte business logic goed testbaar door voor static functions te kiezen en niet overal tussendoor if-thens te gooien maar liever de logica in een apart object te houden. Daardoor zit ik ook niet zo dicht tegen database of UI aan dus hoef ik ook niet te mocken.

In .NET kun je tegenwoordig je klassen gewoon shimmen met het Fakes Framework. Zelf vind ik dat een beetje valsspelen, aangezien het gebruik hiervan betekend dat je code niet loose-coupled is.

Zelf ben ik nog van de 'overal-een-interface-voor-maken'-code. Zal morgen het stuk van Ayende wel even lezen, misschien kom ik dan tot andere inzichten.

[ Voor 4% gewijzigd door Jan_V op 25-08-2014 21:56 ]

[alwinuzz]

Ik heb ook niets tegen interfaces, maar wel tegen interfaces zoals ICustomerRegistrationService met als impl CustomerRegistrationService. Ik probeer met interfaces concepten te abstraheren. Bijvoorbeeld queries en commands. Hiermee dwing je je blablaService op te splitsen in die concepten waardoor het juist behapbare stukjes worden. En die kan je dan goed testen (zelf doe ik dat veel te weinig).

Verderop in die serie posts legt Ayende ook het testing verhaal uit.

[Caelorum]

Mwah, ik gebruik het eigenlijk alleen op plekken waarvan ik het vermoeden heb dat er in de toekomst verschillende implementaties naast elkaar moeten/kunnen bestaan, of op plekken waarbij ik een interface (goh... ^^) voor andere developers wil geven. In het geval van een addon/plugin systeem bijv.
*edit*
Kan dus best eens voorkomen dat ik een interface schrijf met maar 1 implementatie, al zal het niet zo vaak voorkomen

[ Voor 17% gewijzigd door Caelorum op 25-08-2014 22:23 ]

[BikkelZ]

Het klopt wel dat ik in eerste instantie zeker jeuk kreeg van interfaces die geen betekenis hebben maar alleen bestaan voor het testen van een applicatie. Maar ik kan zo gauw geen voorbeeldcode of uitleg vinden zelfs geen serie van posts. Kan iemand mij een TL;DR'etje voor me doen?

[ Voor 10% gewijzigd door BikkelZ op 25-08-2014 22:23 ]

[alwinuzz]

Ik heb geen TLDR voor je, maar wat eerder langskwam was dus "Limit your abstractions":
serie posts van Oren Eini / Ayende . Eerst krijg je een omschrijving van het probleem, dan uitwerking alternatief, daarna laat hij code zien, en vervolgens ook code van de tests.

incaz schreef op maandag 25 augustus 2014 @ 20:17:
Rechtsboven het artikel en dan steeds 'next post'. Soms moet je er een of twee overslaan. (Ik moest ook even kijken.)

[.oisyn]

[ Voor 4% gewijzigd door .oisyn op 25-08-2014 22:55 ]

[Alex)]

alwinuzz schreef op maandag 25 augustus 2014 @ 22:00:
Ik heb ook niets tegen interfaces, maar wel tegen interfaces zoals ICustomerRegistrationService met als impl CustomerRegistrationService.

Zoiets heb ik momenteel ook in een project hangen, een collega heeft die structuur bedacht. Van iedere interface is er inderdaad maar één implementatie, die op zijn beurt via Unity wordt geïnject in Web API-controllers.

Al die controllers bevatten methods die niet veel meer bevatten dan:

C#:

[HttpGet]
public IHttpActionResult List()
{
    return Ok(_customerService.List());
}

Als ik er zo eens naar kijk is het een beetje overengineered.

[Caelorum]

.oisyn schreef op maandag 25 augustus 2014 @ 22:55:
[afbeelding]

Nice ^^

[Megamind]

Alex) schreef op maandag 25 augustus 2014 @ 23:28:
[...]


Zoiets heb ik momenteel ook in een project hangen, een collega heeft die structuur bedacht. Van iedere interface is er inderdaad maar één implementatie, die op zijn beurt via Unity wordt geïnject in Web API-controllers.

Al die controllers bevatten methods die niet veel meer bevatten dan:

C#:

[HttpGet]
public IHttpActionResult List()
{
    return Ok(_customerService.List());
}

Als ik er zo eens naar kijk is het een beetje overengineered.

Hoe wil je anders DI doen? Mijn project heeft ook een interface voor elke implementatie anders geen makkelijke TDD, en 3 tier.

Al zie ik dat ik wel wat laat ben voor deze discussie /

[ Voor 5% gewijzigd door Megamind op 26-08-2014 00:07 ]

[PrisonerOfPain]

Megamind schreef op dinsdag 26 augustus 2014 @ 00:05:
[...]

Hoe wil je anders DI doen? Mijn project heeft ook een interface voor elke implementatie anders geen TDD.

Niet? Je hoeft niet alles in een mock object te stoppen om het te kunnen testen he. Het is niet erg om coupling te hebben (ook niet in TDD). Zolang je maar geen coupling hebt op 'systeem boundries' want dan verlaag je je cohesion.

[ Voor 12% gewijzigd door PrisonerOfPain op 26-08-2014 00:10 ]

[Megamind]

PrisonerOfPain schreef op dinsdag 26 augustus 2014 @ 00:10:
[...]


Niet? Je hoeft niet alles in een mock object te stoppen om het te kunnen testen he. Het is niet erg om coupling te hebben (ook niet in TDD). Zolang je maar geen coupling hebt op 'systeem boundries' want dan verlaag je je cohesion.

Klopt, maar als je het specifiek over C# MVC hebt dan zie ik graag een mock object injected in een controller zodat je een onafhankelijke businesslaag kan maken en je niet persé je controllers hoeft te testen. Net als de datalaag weer in de business geinject kan worden, zodat we niet gelijk integration tests aan het maken zijn.

Dit is meer zo gegroeid omdat bij mijn vorige werkgever alle lagen static waren en je dus geen unit tests kon schrijven alleen integratietests.

[ Voor 17% gewijzigd door Megamind op 26-08-2014 00:22 ]

[Alex)]

Je zou toch gewoon je datalaag in je controllerlaag kunnen injecten en er klaar mee zijn?

[Megamind]

Of EF gelijk in je controller, liever niet. In mijn optiek doet de datalaag niets anders dan CRUD of whatever je wilt naar je data(base). Ik heb een website dat een complex spel is waar behoorlijk wat logic in zit, dan is een testbare businesslaag wel super makkelijk. En als je geen complexiteit in je controllers stopt kan je het risico wel nemen om ze niet te testen.

Maar ik geef toe, in veel situaties waar je niet meer dan wat CRUD doet is het proxiën door een businesslaag overkill

[ Voor 14% gewijzigd door Megamind op 26-08-2014 00:31 ]

[Alex)]

Sowieso, EF. Ik ben nog steeds niet onder de indruk van wat dat ding weet te presteren...

[Megamind]

Is dat niet zo'n beetje met elke ORM

[Avalaxy]

@Interfacesdiscussie: als je MVC of Web API gebruikt moet je je business layer wel injecten als je laatstgenoemde wilt testen. Vanuit unit tests calls doen naar Web API methods is echt niet te doen... Bovendien is testen tegen de database vaak ook niet te doen omdat je geen enkele garantie hebt dat de data wel bestaat in zowel je dev-, test-, acceptatie- als productie-omgevingen, de DAL zul je dus ook moeten injecteren in je business layer.

[Alex)]

Megamind schreef op dinsdag 26 augustus 2014 @ 00:36:
Is dat niet zo'n beetje met elke ORM

Op zich wel.

Ze zijn handig voor het simpele CRUD-werk omdat het veel boilerplate code scheelt, maar voor het wat complexere werk schrijf ik eigenlijk toch liever zelf queries. Ik heb in mijn project een paar LINQ-to-EF-queries die makkelijk 20 tot 25 regels beslaan (.Include, .Where, enz.) en ik hou m'n hart vast voor hoe dat gaat performen als er straks een paar tienduizend rows in de database hangen

[Megamind]

http://www.hibernatingrhinos.com/products/efprof meten = weten Maar sinds code first migrations hou ik me wel graag aan EF vast.

[BikkelZ]

Alex) schreef op dinsdag 26 augustus 2014 @ 01:26:
[...]

Op zich wel.

Ze zijn handig voor het simpele CRUD-werk omdat het veel boilerplate code scheelt, maar voor het wat complexere werk schrijf ik eigenlijk toch liever zelf queries. Ik heb in mijn project een paar LINQ-to-EF-queries die makkelijk 20 tot 25 regels beslaan (.Include, .Where, enz.) en ik hou m'n hart vast voor hoe dat gaat performen als er straks een paar tienduizend rows in de database hangen

Ik ben daar echt pijlsnel van af gestapt van die complexe LINQ-queries en dat wil wat zeggen bij mij aangezien ik toch echt een x aantal jaar echt heb geloofd dat WebForms helemaal goed was en het probleem puur bij mij en mijn gebrek aan kennis lag als ik weer tegen glazen plafonds aan liep waarbij complexiteit en het aantal bugs ineens explodeerden.

Entity betekent dat je een simpele entity hebt en dus niet een complexe geneste query. Je kunt je sprocs gewoon in een object stoppen en zelfs weer zoals een gewone Entity je objecten saven als het moet. Gouden regel: als het te ingewikkeld voelt dan ís het te ingewikkeld.

[Douweegbertje]

Mijn ervaring is juist dat complexe queries een onderdeel zijn van een slecht DB ontwerp. Hiermee geef ik niet gelijk af aan BikkelZ, maar bijv. bij ons kon ik niet eens een ORM gebruiken omdat onze DB ruk was.
Zelfs met entities kun je relaties hebben en/of wat complexere queries uitvoeren. Sterker nog, met de juiste setup zou het zelfs makkelijker moeten zijn. Ik heb ook zat queries die amper te lezen zijn, zo groot. Toch zie ik mogelijkheden om dat netjes te kunnen afvangen...

Entity betekent dat je een simpele entity hebt en dus niet een complexe geneste query

mja niet echt naar mijn mening.
Voor mij is het gewoon een object waar je -alles- mee kan. Of dit nu juist een simpele 'user' is, of een ingewikkelde 'auto' met veel opties.. dat zou niet uit moeten maken. Voor mij is juist een entitie een mooi object waar ik alles mee zou kunnen (auto->optieX('y'))...

[WernerL]

Dit moet wel de meest briljante feedback zijn die ik ooit van een klant heb gehad. "Het werkt te snel" en of ik er een vertraging in kan bouwen...

_{Responsetijd is slechts enkele milliseconden, is het snel is het nog niet goed.}

Gaat over een filter optie die via ajax nieuwe records ophaalt overigens.

[ Voor 13% gewijzigd door WernerL op 26-08-2014 08:50 ]

[Rutix]

WernerL schreef op dinsdag 26 augustus 2014 @ 08:50:
Dit moet wel de meest briljante feedback zijn die ik ooit van een klant heb gehad. "Het werkt te snel" en of ik er een vertraging in kan bouwen...

_{Responsetijd is slechts enkele milliseconden, is het snel is het nog niet goed.}

Gaat over een filter optie die via ajax nieuwe records ophaalt overigens.

Maar wat is de redenering erachter? Wij hebben ook weleens zo'n verzoek gehad en toen zat er vanuit gebruikersperspectief wel goede argumentatie achter.

[Blubber]

The Speed-Up Loop

[Alex)]

Douweegbertje schreef op dinsdag 26 augustus 2014 @ 07:36:
Mijn ervaring is juist dat complexe queries een onderdeel zijn van een slecht DB ontwerp.

Dat ben ik niet per definitie met je eens.

In ons model hebben we een negental entities die erg belangrijk zijn en allemaal met elkaar in verband staan. Het onderliggende idee is een soort winkelmandje voor diensten, waarbij het aantal velden per order line nogal groot isomdat we dit vanuit ons domeinmodel nodig hebben. Ook kent het systeem de mogelijkheid om een orderline 'terug te sturen', ofwel een omgekeerde actie t.o.v. eerder.

We hebben een query waarmee we kunnen bepalen diensten nog ter beschikking staan van de gebruiker, ofwel: alle 'adds' waar nog geen 'remove' voor is.

Dit kun je bepalen door alle tabellen leeg te trekken en het clientside uit te rekenen, dat betekent wel veel netwerkverkeer waarvan 95% uiteindelijk weg wordt gegooid. Daarom willen we het volledig in de database berekenen om daarna alleen maar over de lijn te halen wat van toepassing is.

Hiermee geef ik niet gelijk af aan BikkelZ, maar bijv. bij ons kon ik niet eens een ORM gebruiken omdat onze DB ruk was.

Dat is op zich best wel een prestatie. Wat miste je dan zoal in je datamodel om dat voor elkaar te krijgen?

[WernerL]

Rutix schreef op dinsdag 26 augustus 2014 @ 08:59:
[...]

Maar wat is de redenering erachter? Wij hebben ook weleens zo'n verzoek gehad en toen zat er vanuit gebruikersperspectief wel goede argumentatie achter.

Geen idee wat de reden is, die is niet gegeven. Nouja, ik zet wel een timer tussen de actie van de gebruiker en het daadwerkelijk doorzoeken van de database.

[incaz]

't Is toch wel handig om even na te vragen denk ik. Bij facet search kan ik me namelijk goed voorstellen dat mensen de tijd willen om meerdere opties aan te klikken ipv meteen te refreshen. Als je dan een serverside vertraging bouwt, lost dat het probleem allerminst op, want dan krijg je alsnog 2 refreshes.

[TheNephilim]

incaz schreef op dinsdag 26 augustus 2014 @ 09:45:
't Is toch wel handig om even na te vragen denk ik. Bij facet search kan ik me namelijk goed voorstellen dat mensen de tijd willen om meerdere opties aan te klikken ipv meteen te refreshen. Als je dan een serverside vertraging bouwt, lost dat het probleem allerminst op, want dan krijg je alsnog 2 refreshes.

Yup, inderdaad gewoon 300ms - 500ms lang wachten tot de laatste wijziging. Dan pas een request naar de server sturen.

[incaz]

Ha, eindelijk weer eens een ouderwetse

Ok, geen code maar data, maar toch, 5 minuten and counting.

[Cloud]

TheNephilim schreef op dinsdag 26 augustus 2014 @ 09:50:
[...]


Yup, inderdaad gewoon 300ms - 500ms lang wachten tot de laatste wijziging. Dan pas een request naar de server sturen.

Inderdaad. Hoe stom het ook klinkt, als ie te snel werkt kan het zijn dat de gebruiker het niet tegelijkertijd kan volgen met het intypen. Vrijwel elke zoekmachine die automatisch zoekt, heeft een kleine vertraging. Dan heb je als gebruiker tijd om je ogen van het invoerveld af te halen om naar het resultaat te kijken.

Ik hanteer hier voor een dergelijk scenario ook een timeout.

[EddoH]

Daarnaast wil je natuurlijk niet voor een woord van 10 letters, 10 Ajax requests sturen.

[Rutix]

Precies en daarom is de redenering erachter belangrijk. Sowieso wil ik altijd de reden weten want ik ben niet zo iemand die maar meteen akkoord als er iets door de klant geroepen word want in sommige gevallen weet ik gewoon dat ze daar in de toekomst op terug gaan komen omdat de oplossing die ze hadden bedacht gewoon ruk is . Ik geef daarom liever altijd advies en als ze dan nog doorzagen dan is dat prima maar dan heb ik ze het van tevoren wel verteld

[TheNephilim]

Rutix schreef op dinsdag 26 augustus 2014 @ 11:21:
Precies en daarom is de redenering erachter belangrijk. Sowieso wil ik altijd de reden weten want ik ben niet zo iemand die maar meteen akkoord als er iets door de klant geroepen word want in sommige gevallen weet ik gewoon dat ze daar in de toekomst op terug gaan komen omdat de oplossing die ze hadden bedacht gewoon ruk is . Ik geef daarom liever altijd advies en als ze dan nog doorzagen dan is dat prima maar dan heb ik ze het van tevoren wel verteld

Al mag je dan haast alsnog vastleggen dat je dat advies 'toen' ook daadwerkelijk gegeven hebt!

[Caelorum]

Cloud schreef op dinsdag 26 augustus 2014 @ 10:25:
[...]
Inderdaad. Hoe stom het ook klinkt, als ie te snel werkt kan het zijn dat de gebruiker het niet tegelijkertijd kan volgen met het intypen.[...]

Is niks stoms aan IMO. Je zit gewoon tegen de beperkingen van het menselijk brein aan te werken. Daarnaast willen sommige mensen gewoon altijd vaststellen dat wat ze willen ook daadwerkelijk gebeurt als ze iets hebben gedaan en dan krijg je "rare" eisen aan je interface. Meer ervaren gebruikers zouden wellicht nog tevreden kunnen met de kennis dat wat ze wilden waarschijnlijk ook is gebeurt.
Als voorbeeld bijv. het starten van een programma via het zoekveld in het startmenu van Windows. Mijn moeder zal waarschijnlijk eerst de windows toets indrukken (nadat ik het heb voorgedaan) en dan wachten op het menu en vaststellen dat de tekstcursor daadwerkelijk in het zoekveld zit en dan typen en wachten op het resultaat en dan op enter drukken. Waar ik gewoon alles zo snel achter elkaar zou doen dat de interface het niet of nauwelijks bij zal houden. Dat laatste zou echt enorm verwarrend zijn voor haar als onervaren gebruiker en ook voor die mensen die altijd een bevestiging willen zien (het soort onzekere computergebruiker zeg maar).

TheNephilim schreef op dinsdag 26 augustus 2014 @ 11:21:
[...] Al mag je dan haast alsnog vastleggen dat je dat advies 'toen' ook daadwerkelijk gegeven hebt!

Lang leve de mailtjes en hoe bevredigend ook als je op zo'n toon kan laten merken dat dit wel een herhaling is van een gesprek dat eerder is gevoerd en of ze nu wel meer gewicht aan je mening hangen ^^

[ Voor 13% gewijzigd door Caelorum op 26-08-2014 11:30 ]

[Cloud]

Caelorum schreef op dinsdag 26 augustus 2014 @ 11:29:
[...]
Is niks stoms aan IMO. Je zit gewoon tegen de beperkingen van het menselijk brein aan te werken.

Ik zei niet dat het stom ís, ik zei dat het stom klinkt En dan doel ik op de opmerking 'het filter werkt te snel', iets waarvan je normaliter verwacht dat het niet snel genoeg kan. Er zijn inderdaad volkomen logische verklaringen voor te geven, vanuit gebruikersperspectief

[Martijn19]

incaz schreef op dinsdag 26 augustus 2014 @ 10:20:
Ha, eindelijk weer eens een ouderwetse [afbeelding]

Ok, geen code maar data, maar toch, 5 minuten and counting.

Go is mijn eerste compiled language, geen idee waar je het over hebt

[Caelorum]

Ga eens voor de grap Qt compilen ^^ en dan wel vergeten multicore compilen aan te zetten Na een dag ben je nog steeds bezig....

[ Voor 19% gewijzigd door Caelorum op 26-08-2014 11:54 ]

[Rutix]

Caelorum schreef op dinsdag 26 augustus 2014 @ 11:54:
Ga eens voor de grap Qt compilen ^^ en dan wel vergeten multicore compilen aan te zetten Na een dag ben je nog steeds bezig....

Zelfde heb je met Boost die kan ook best lang duren .

Ik moet Go toch eens gaan uitproberen binnenkort. Hoor er best mooie verhalen over die ik zelf even wil testen voordat ik het geloof.

[Martijn19]

Caelorum schreef op dinsdag 26 augustus 2014 @ 11:54:
Ga eens voor de grap Qt compilen ^^ en dan wel vergeten multicore compilen aan te zetten Na een dag ben je nog steeds bezig....

Geen last van gelukkig, ik maak alleen web-based applicaties

Even iets anders: schaamteloos van het twitter account van Arnoud Wokke afgehaald:

http://www.man-man-man.nl/

code:

setInterval(function() {
      $("#manmanman").append(" man");
}, 150);

[Verwijderd]

Martijn19 schreef op dinsdag 26 augustus 2014 @ 12:05:
[...]

http://www.man-man-man.nl/

Haha dit link ik altijd naar m'n collega's als een klant weer een idiote vraag stelt

[BikkelZ]

WernerL schreef op dinsdag 26 augustus 2014 @ 08:50:
Dit moet wel de meest briljante feedback zijn die ik ooit van een klant heb gehad. "Het werkt te snel" en of ik er een vertraging in kan bouwen...

_{Responsetijd is slechts enkele milliseconden, is het snel is het nog niet goed.}

Gaat over een filter optie die via ajax nieuwe records ophaalt overigens.

Ik heb voor een app wel eens de opdracht gehad dat een call naar de webserver ik meen minstens 200ms moest duren. Dus ik had wat gebouwd wat de tijd bijhield en even bleef wachten op het moment dat het te snel was. Blijkbaar hadden zijn klanten in het verleden weer geklaagd dat hij niks deed op het moment dat het <10ms was, opslaan moest in de psyche van de gebruiker altijd tijd kosten.

Douweegbertje schreef op dinsdag 26 augustus 2014 @ 07:36:
Mijn ervaring is juist dat complexe queries een onderdeel zijn van een slecht DB ontwerp. Hiermee geef ik niet gelijk af aan BikkelZ, maar bijv. bij ons kon ik niet eens een ORM gebruiken omdat onze DB ruk was.
Zelfs met entities kun je relaties hebben en/of wat complexere queries uitvoeren. Sterker nog, met de juiste setup zou het zelfs makkelijker moeten zijn. Ik heb ook zat queries die amper te lezen zijn, zo groot. Toch zie ik mogelijkheden om dat netjes te kunnen afvangen...

Complexe queries heb je nodig op het moment dat je rapporten en dergelijke wil maken, dus hoeveel mensen hebben de helpdesk gebeld maar niet met een Windows probleem tussen juli en september 2012 en in hoeveel telefoontjes was het probleem gemiddeld opgelost.

Dat zijn dingen die ik mensen in code heb zien doen en ik heb het ook wel eens geprobeerd. En misschien lukt het wel maar dan moet j een half jaar later nog een keer die query in om een bepaalde clausule om te kunnen draaien....

Dan doe ik die ellende liever in SQL wat sneller werkt, er precies voor bedoeld is, niet makkelijk maar wel makkelijker voor hetdoel en uiteindelijk toch prima te encapsulaten is naar een object in de meeste ORM's.

Stel nou dat je van die helpdeskquery de Callers wil hebben, wat ook een losse tabel is in je database. Als die sproc dat resultaat gewoon retourneert kun je ook weer die Caller opslaan via je ORM als je hem aangepast hebt ondanks dat je de query waarmee je hem ophaalde niet in code geschreven hebt.

Douweegbertje schreef op dinsdag 26 augustus 2014 @ 07:36:
mja niet echt naar mijn mening.
Voor mij is het gewoon een object waar je -alles- mee kan. Of dit nu juist een simpele 'user' is, of een ingewikkelde 'auto' met veel opties.. dat zou niet uit moeten maken. Voor mij is juist een entitie een mooi object waar ik alles mee zou kunnen (auto->optieX('y'))...

Het is gewoon niet zo dat een database exact 1:1 mapt met de data de je in je applicatie gebruikt en dat hoeft ook helemaal niet maar je kunt gewoon het object waar je applicatie mee werkt wel isoleren van de onderliggende database zodat je niet steeds je applicatie aan moet passen aan je database. Als je connect naar een webservice hoef je toch ook niet te snappen hoe de database er achter er precies uit ziet?

[Gamebuster]

Spannend... aan het onderhandelen over een nieuw uurtarief. Als "het" akkoord gaat, verdien ik straks meer dan het dubbele dan met mijn baan in loondienst van 6 maanden terug.

[kwaakvaak_v2]

Gamebuster schreef op dinsdag 26 augustus 2014 @ 13:39:
Spannend... aan het onderhandelen over een nieuw uurtarief. Als "het" akkoord gaat, verdien ik straks meer dan het dubbele dan met mijn baan in loondienst van 6 maanden terug.

Dat zegt relatief niks he... als je met je baan in loondienst 50 cent per uur kreeg, krijg je straks 1 euro. Maar vergeleken met mensen die 10.000 per dag verdienen met niets kunnen (lees meeste BN'ers) is dat nog steeds een schijntje

[Gamebuster]

kwaakvaak_v2 schreef op dinsdag 26 augustus 2014 @ 13:41:
[...]


Dat zegt relatief niks he... als je met je baan in loondienst 50 cent per uur kreeg, krijg je straks 1 euro. Maar vergeleken met mensen die 10.000 per dag verdienen met niets kunnen (lees meeste BN'ers) is dat nog steeds een schijntje

Weet ik, als ZZPer doe ik mijn bruto uurtarief x0,6 als "netto inkomen". Niet helemaal de realiteit, maar in mijn geval komt het ongeveer op hetzelfde neer. Heb ook bijkomende voordelen als geen BTW op vrijwel alles met een stekker of draadje en voordelen die je krijgt als startend ondernemer.

Het blijft lastig vergelijken, die "meer dan het dubbele" is heel pessimistisch berekend, als ik optimistisch reken is het meer dan 3x zoveel. Hoe je ook de cijfers schuift, het klinkt allemaal erg goed.

[ Voor 23% gewijzigd door Gamebuster op 26-08-2014 13:50 ]

[incaz]

Awesome: http://bost.ocks.org/mike/algorithms/
Note: het trekt op je foon wel de batterij leeg

[RayNbow]

Zucht... YouTube IFrame API...

[alex3305]

Rutix schreef op dinsdag 26 augustus 2014 @ 11:59:
[...]

Zelfde heb je met Boost die kan ook best lang duren .

Ik moet Go toch eens gaan uitproberen binnenkort. Hoor er best mooie verhalen over die ik zelf even wil testen voordat ik het geloof.

Same here. Ik zag leuke code voorbeelden van het Go-team die hier wel handig kunnen zijn wanneer ze uitgebreid worden. Een voorbeeld is o.a. die reverse proxy of blog software.

Het enige wat me nog een beetje tegenstaat is de syntax. Ik vind die van C#/Java gewoon echt ideaal werken, en als ik dan weer ergens aan moet wennen (PHP, Python) dan erger ik mezelf de eerste tijd altijd groen en geel.

[Rutix]

alex3305 schreef op dinsdag 26 augustus 2014 @ 13:57:
[...]

Same here. Ik zag leuke code voorbeelden van het Go-team die hier wel handig kunnen zijn wanneer ze uitgebreid worden. Een voorbeeld is o.a. die reverse proxy of blog software.

Het enige wat me nog een beetje tegenstaat is de syntax. Ik vind die van C#/Java gewoon echt ideaal werken, en als ik dan weer ergens aan moet wennen (PHP, Python) dan erger ik mezelf de eerste tijd altijd groen en geel.

Dat is inderdaad ook 1 van de redenen waarom ik het tot nu toe niet heb geprobeerd . Ik vind de syntax een beetje lelijk op dit moment (ieder zijn smaak hoor ).

[Gamebuster]

Go... het idee is leuk, maar er zijn diverse dingen die mij niet volledig aanspreken. Ben nu Dart aan't proberen.

[Rutix]

Gamebuster schreef op dinsdag 26 augustus 2014 @ 14:26:
Go... het idee is leuk, maar er zijn diverse dingen die mij niet volledig aanspreken. Ben nu Dart aan't proberen.

Heb je ergens neergezet wat je niet aanspreekt? Ik ben eigenlijk daar wel benieuwd naar

[StM]

Er is nog geen JetBrains IDE voor