De Devschuur Coffee Corner - Iteratie ⓫

[alienfruit]

Ja precies en dan nog geld vragen voor papieren rekeningen.

[Mugwump]

Douweegbertje schreef op vrijdag 4 mei 2018 @ 08:40:
Recent had ik een aantal sites onder de loep genomen en best geschrokken over hoe lek die eigenlijk zijn. Gebruik makend van headless technieken maar nog niet helemaal de implicaties begrijpen..

Uiteindelijk op medium een stukje geschreven; https://medium.com/@wiard...also-leaking-6b32b186adf4

Herkennen jullie dit ook? Zelf ervaring mee?

Ik zie 'headless' eigenlijk niet als iets nieuws. Ik bouw al vele jaren APIs die op de één of andere wijze gebruikt worden. Dat kan een (web) front-end applicatie zijn, maar dat kan ook een ander stuk software zijn. In mijn huidige project bouw ik ook weer een API als interface voor een redelijk uitgebreid event-sourced systeem in de finance. Daarbij is security gewoon een hele belangrijke overweging. Een collega van me die een front-end bouwt (wel met een server-side component) dacht dat het voor bepaalde calls wel handig was om de door mij gebouwde API rechtstreeks aan te roepen via een AJAX call, maar die heb ik even teruggefloten. De organisatie waar ik werk vereist dat dit soort endpoints sowieso altijd al op netwerkniveau zijn afgeschermd door middel van bijvoorbeeld IP whitelisting of VNets dus een dergelijke Ajax call resulteert sowieso in een 403.
Ook wie bij welke data mag ligt erg gevoelig. Ik bepaal niet wie wie is of welke rechten iemand heeft. Dat soort zaken worden allemaal centraal geregeld door een (A)AD. Ik valideer enkel of de (JWT) token die ik binnenkrijg ook daadwerkelijk valide is volgens de issuer. Zo ja, dan hanteer ik de claims uit de token. Daar hangt dan wel weer een custom rechtenmodelletje achter waarbij bijvoorbeeld user X de rechten heeft om bij de data van klanten 1,2 en 3 te mogen en bijvoorbeeld weer niet het recht heeft om privacygevoelige zaken te zien, maar wel weer het recht heeft om een aanvraag voor een contractverlening te doen.

Op het moment dat je een 'fat client' applicatie maakt met <insert javascriptframeworkflavouroftheweek>, dan moet je je ten alle tijd bewust zijn van het feit dat elke gebruiker met enige technische kennis in staat is om te zien wat jouw client communiceert met back-end systemen.

[alienfruit]

Altijd leuk blijkbaar was er een hele discussie op het werk over wat software bij een klant, blijkbaar willen ze er weg migreren maar omdat het nog een DOS applicatie vinden ze lastig omdat de business logic in een gekke scripttaal geschreven is. Blijkt het uiteindelijk een scripttaal (Nederlands ) te zijn die mij vader heeft ontwikkeld en waarvoor ik de documentatie heb geschreven. Oftewel ik ben nu de lul

[Alex)]

Kleine wereld, zo blijkt maar weer

[alienfruit]

Klopt, gelukkig ben ik nu in het ouderlijk huis dus eens kijken of nog wat broncode en de oorspronkelijke documentatie kan op duikelen

Wow, een scripttaal geschreven in Basic. I am impressed, pa!

[ Voor 18% gewijzigd door alienfruit op 04-05-2018 14:51 ]

[Cloud]

Douweegbertje schreef op vrijdag 4 mei 2018 @ 08:40:
Recent had ik een aantal sites onder de loep genomen en best geschrokken over hoe lek die eigenlijk zijn. Gebruik makend van headless technieken maar nog niet helemaal de implicaties begrijpen..

Uiteindelijk op medium een stukje geschreven; https://medium.com/@wiard...also-leaking-6b32b186adf4

Herkennen jullie dit ook? Zelf ervaring mee?

Leuke blogpost Geen ervaring mee - ik ben dan ook geen webdeveloper - maar het is eenvoudig om dit erg fout te doen. Fancy frontend, leaky backend.

[alienfruit]

Ja, klopt, soms zit je ook in een spagaat omdat de klant gebruiksvriendelijker berichten wil weergeven naar de gebruiker toe terwijl je dan weer zit met de veiligheid.

[Douweegbertje]

alienfruit schreef op vrijdag 4 mei 2018 @ 15:20:
Ja, klopt, soms zit je ook in een spagaat omdat de klant gebruiksvriendelijker berichten wil weergeven naar de gebruiker toe terwijl je dan weer zit met de veiligheid.

Ja, je verwoord het exact

[farlane]

alienfruit schreef op vrijdag 4 mei 2018 @ 14:15:
Klopt, gelukkig ben ik nu in het ouderlijk huis dus eens kijken of nog wat broncode en de oorspronkelijke documentatie kan op duikelen

Wow, een scripttaal geschreven in Basic. I am impressed, pa!

Niet om je pas te dissen, maar waarom is dat indrukwekkender dan in een andere taal?

[alienfruit]

Voornamelijk omdat ik niet zou weten waar je zo beginnen in QuickBasic 4.5
Ik ga de broncode lezen, eens kijken waar de tokeniser etc is

[ Voor 30% gewijzigd door alienfruit op 04-05-2018 17:17 ]

[farlane]

alienfruit schreef op vrijdag 4 mei 2018 @ 17:10:
Voornamelijk omdat ik niet zou weten waar je zo beginnen in QuickBasic 4.5

QBasic:

10 PRINT "HELLO WORLD"
20 GOTO 10

[alienfruit]

Haha, ja, en gebruikt CALL ABSOLUTE voor dingen. Blijkbaar kan je daarmee assembly code uitvoeren. Verder een heleboel trucjes om een flink tekstbestand in te laden terwijl er niet veel geheugen is etc. Best wel interessant. Change log ook hé 1988

[ Voor 5% gewijzigd door alienfruit op 04-05-2018 23:01 ]

[Flapmo]

Douweegbertje schreef op vrijdag 4 mei 2018 @ 08:40:
Recent had ik een aantal sites onder de loep genomen en best geschrokken over hoe lek die eigenlijk zijn. Gebruik makend van headless technieken maar nog niet helemaal de implicaties begrijpen..

Uiteindelijk op medium een stukje geschreven; https://medium.com/@wiard...also-leaking-6b32b186adf4

Herkennen jullie dit ook? Zelf ervaring mee?

Snap het bericht dat je wilt geven niet helemaal. Voordat react, vue, angular, ... etc. bestond had je ook al een client/server split. Ook toen moest je alleen over het netwerk sturen wat de client mocht zien (i.e. Browser in jouw verhaal). Doe je dat niet dan heb je een leak. Ik zie niet in waarom de nieuwe frameworks hier invloed op hebben behalve dat ze het mainstream hebben gemaakt en door quantiteit er meer broddelaars rondspoken. Als dat je punt was, mee eens .

P.s. Per definitie zijn alle client-side frameworks unsafe en moet je ze ook zo behandelen. Het enige wat je nog kan zien als mitigatie is dat je voor bepaalde zaken kan zeggen dat het alleen unsafe in de executerende context is (e.g. dmv https/correct gebruik van state keys, cookie domains en CORS).

[ Voor 13% gewijzigd door Flapmo op 05-05-2018 11:40 ]

[ThomasG]

Flapmo schreef op zaterdag 5 mei 2018 @ 11:20:
[...]

Snap het bericht dat je wilt geven niet helemaal. Voordat react, vue, angular, ... etc. bestond had je ook al een client/server split. Ook toen moest je alleen over het netwerk sturen wat de client mocht zien (i.e. Browser in jouw verhaal). Doe je dat niet dan heb je een leak. Ik zie niet in waarom de nieuwe frameworks hier invloed op hebben behalve dat ze het mainstream hebben gemaakt en door quantiteit er meer broddelaars rondspoken. Als dat je punt was, mee eens .

P.s. Per definitie zijn alle client-side frameworks unsafe en moet je ze ook zo behandelen. Het enige wat je nog kan zien als mitigatie is dat je voor bepaalde zaken kan zeggen dat het alleen unsafe in de executerende context is (e.g. dmv https/correct gebruik van state keys, cookie domains en CORS).

Bij 'klassieke' websites had je dit probleem niet, omdat het gewoon verborgen was. Er werdt iets uit de database opgehaald, en in een pagina weergegeven. Als er teveel uit de database werd opgehaald maakte dat niet zoveel uit, want je zag het niet en kon er ook niet bij. Veel websites hebben nu een Javascript client een een REST api, maar deze API geeftr vaak te veel informatie terug omdat ze domweg het hele database resultaat in de json stoppen. Je ziet dat niet in de view, maar wel in de request.

[Flapmo]

ThomasG schreef op zaterdag 5 mei 2018 @ 11:56:
[...]
Bij 'klassieke' websites had je dit probleem niet, omdat het gewoon verborgen was. Er werdt iets uit de database opgehaald, en in een pagina weergegeven. Als er teveel uit de database werd opgehaald maakte dat niet zoveel uit, want je zag het niet en kon er ook niet bij. Veel websites hebben nu een Javascript client een een REST api, maar deze API geeftr vaak te veel informatie terug omdat ze domweg het hele database resultaat in de json stoppen. Je ziet dat niet in de view, maar wel in de request.

Pardon? Je zag het niet dus je kon er niet bij? Dat is natuurlijk niet helemaal waar, of beter gezegd, helemaal niet!

De exact zelfde API server van vroeger kan je aansluiten op je react, vue, of angular frontend of andersom, een oude frontend op je nieuwe API server. Het vereist wat extra werk maar alle data die over de lijn gaat kan nadien uitgelezen worden in de browser die het ontvangt; bij pech in browsers die het niet horen te ontvangen (indien niet encrypted verstuurd etc.). Dat heeft niets te maken met de oude of nieuwe technieken.

Los van server side rendering vs client-side rendering. Dat is weer een discussie op zich. Allicht bedoel je dat? Dat de gegevens verwerkt werden op de server en alleen de html page over ging i.p.v. de data om een site te renderen op de client. En dat mensen niet nadenken wat ze naar de client sturen, i.e. ze sturen alles en filteren op de client wat fout is. Feitelijk staat dit los van de gekozen frameworks..

Je titel is dan wat raar gekozen. de frameworks zelf zijn niet leaky, of eigenlijk zijn ze dit per definitie. Beetje een open deur.

[ Voor 41% gewijzigd door Flapmo op 05-05-2018 12:17 ]

[Lethalis]

ThomasG schreef op zaterdag 5 mei 2018 @ 11:56:
[...]
Veel websites hebben nu een Javascript client een een REST api, maar deze API geeftr vaak te veel informatie terug omdat ze domweg het hele database resultaat in de json stoppen. Je ziet dat niet in de view, maar wel in de request.

Ik vind dit zo absurd dat ik het mij bijna niet voor kan stellen. Met de API staat of valt alles en die ontwikkel ik dan ook altijd los van de frontend.

Postman erbij om te testen.

Alles heeft zijn eigen Request en Response classes bij mij. Bovendien wordt elke Request gevalideerd of hij wel geldig is.

Een OrderRequest wordt gevalideerd en vertaald naar een Order. Je schiet dus niet direct een Order in. Een OrderResponse geeft alleen de relevante informatie terug (ordernummer, evt levertijd etc).

En ja dit is meer werk, maar de dag dat iemand direct een Order kan inschieten tegen een verkeerde prijs (om maar wat te noemen) kun je de webapplicatie offline halen.

Ik geef ook gewoon een 400 Bad Request terug als je iets stuurt dat niet okee is.

Met NancyFX heb ik hiervoor een handler geschreven voor de OnError pipeline en gebruik ik FluentValidation. Model binding en validation errors geven dan automatisch een status 400. Eventueel met reason phrase erbij die ik in de client kan weergeven.

Pas als dit goed werkt, begin ik überhaupt aan de frontend met Angular. Daar kan dan security technisch ook minder fout gaan.

[Mugwump]

Ik zie vooral de effecten van het ellendige 'CRUD'-denken terug in die discussie. In veel van dat soort web-based systemen zie je simpelweg een één-op-één mapping die zo ongeveer rechtstreeks van UI naar API naar databasetabel / -structuur gaat. Ik vind dat persoonlijk in het gros van de gevallen een enorm architecturele anti-pattern. Het voorkomt vaak ook juist dat mensen gaan nadenken over zaken als 'welke data moet ik eigenlijk via een API op kunnen vragen / op kunnen slaan?' of 'Wat wil mijn gebruiker eigenlijk bereiken?'. Je gebruiker wil niet de entiteit order wijzigen om de waarde van de boolean cancelled op true te zetten, je gebruiker wil een order annuleren. Misschien moet zo'n verzoek wel handmatig worden beoordeeld door een werknemer wat betekent dat je een heel ander proces moet implementeren. Een hexagonal / ports and adapters architectuur met DTOs, fatsoenlijke scheiding tussen je BL en database en ga zo maar door is natuurlijk wat meer werk. In Java / C# / PHP / Python / enz heb je tegenwoordig allerhande frameworks die op basis van wat simpele datamodelletjes het geheel aan code van persistence t/m REST API voor je genereren. Maar dat mondt bij een beetje complex / schaalbaar systeem toch al wel heel snel uit in 'goedkoop is duurkoop'.

Ik denk dat het concept van een 'REST back end' + "Client side only front end" voor de wat jongere developers onder ons heel nieuw oogt, maar feitelijk is een dergelijk client server model al heel oud. Het gros van de bedrijven draait nog wel desktop applicaties die als client fungeren voor een centraal draaiende back end server. Daarbij kun je dan iets minder makkelijk dan in een browser de communicatie monitoren en 'hacken', maar het is nog steeds prima mogelijk. Natuurlijk is het wel een groot verschil dat de meeste webapplicaties gewoon door iedereen te benaderen zijn, dus dat maakt het probleem wel een stuk groter.

[Douweegbertje]

Flapmo schreef op zaterdag 5 mei 2018 @ 12:05:
[...]

Pardon? Je zag het niet dus je kon er niet bij? Dat is natuurlijk niet helemaal waar, of beter gezegd, helemaal niet!

De exact zelfde API server van vroeger kan je aansluiten op je react, vue, of angular frontend of andersom, een oude frontend op je nieuwe API server. Het vereist wat extra werk maar alle data die over de lijn gaat kan nadien uitgelezen worden in de browser die het ontvangt; bij pech in browsers die het niet horen te ontvangen (indien niet encrypted verstuurd etc.). Dat heeft niets te maken met de oude of nieuwe technieken.

Los van server side rendering vs client-side rendering. Dat is weer een discussie op zich. Allicht bedoel je dat? Dat de gegevens verwerkt werden op de server en alleen de html page over ging i.p.v. de data om een site te renderen op de client. En dat mensen niet nadenken wat ze naar de client sturen, i.e. ze sturen alles en filteren op de client wat fout is. Feitelijk staat dit los van de gekozen frameworks..

Je titel is dan wat raar gekozen. de frameworks zelf zijn niet leaky, of eigenlijk zijn ze dit per definitie. Beetje een open deur.

Wat hij bedoelt is exact wat ik ook bedoelde. Met "je zag het niet dus..." gaat het om bijvoorbeeld om een login. Stel ik pak gewoon een site die de frontend genereert vanuit de server zelf, dus niet via een API.
Je kan dan gewoon veilig en intern je data behandelen en op basis daarvan de frontend prepareren zonder dat een client of de buitenwereld kan zien op basis van welke logica je dat hebt gedaan. Je komt soms in een spagaat tussen; "ik wil mn frontend iets geven, maar ik kan dat niet doen". En zeker valt daar mee te werken, maar 9/10x gaat het hier wel fout.

Het gaat mij niet zo zeer om React of whatever, echter zijn dat wel exact de frameworks waarbij het fout gaat. Ik heb expliciet vermeld in de tekst: hoewel ik ze noem, is dit niet de oorzaak. Ze zijn echter wel de common denominator en derhalve noemenswaardig.

Lethalis schreef op zaterdag 5 mei 2018 @ 13:08:
[...]

Ik vind dit zo absurd dat ik het mij bijna niet voor kan stellen. Met de API staat of valt alles en die ontwikkel ik dan ook altijd los van de frontend.

Postman erbij om te testen.

Alles heeft zijn eigen Request en Response classes bij mij. Bovendien wordt elke Request gevalideerd of hij wel geldig is.

Een OrderRequest wordt gevalideerd en vertaald naar een Order. Je schiet dus niet direct een Order in. Een OrderResponse geeft alleen de relevante informatie terug (ordernummer, evt levertijd etc).

En ja dit is meer werk, maar de dag dat iemand direct een Order kan inschieten tegen een verkeerde prijs (om maar wat te noemen) kun je de webapplicatie offline halen.

Ik geef ook gewoon een 400 Bad Request terug als je iets stuurt dat niet okee is.

Met NancyFX heb ik hiervoor een handler geschreven voor de OnError pipeline en gebruik ik FluentValidation. Model binding en validation errors geven dan automatisch een status 400. Eventueel met reason phrase erbij die ik in de client kan weergeven.

Pas als dit goed werkt, begin ik überhaupt aan de frontend met Angular. Daar kan dan security technisch ook minder fout gaan.

En dit was gewoon dat ik zelf kon querien op username..

[ Voor 25% gewijzigd door Douweegbertje op 05-05-2018 13:53 ]

[F.West98]

Volgens mij gaat het erom dat die frameworks het aantrekkelijker en makkelijker maken om aan client-side rendering te gaan doen, en het bijna noodzakelijk maken een API te bouwen. En onervaren mensen zijn zich minder bewust van de gevaren en begrijpen dan niet goed wat zo'n API doet, waardoor ze het als een soort DB-access systeem opzetten (of niet nadenken over rechten, etc).
Het zijn niet de frameworks zelf die onveilig zijn, maar ze faciliteren wel / ze zetten de deur wel open voor meer bugs en leaks. Kan je dat die frameworks kwalijk nemen? Nee. De devs? Ja.

Maar daarnaast, echt, hoe krijg je het voorelkaar om zulke systemen te bouwen dat je een hele DB record returnt in je API. Echt. Allemachtig.

[Flapmo]

Zijn we het toch allemaal eens. Betaal niet fatsoenlijk voor je web dev en krijg je ook geen fatsoenlijke site. Bullshit in, bullshit out!

[ShitHappens]

Heb hiervan nog een leuk voorbeeld gevonden, in de Tinder webapp.
Via de matches API haalt deze de gevens op over je matches. Deze bevat heel 'normale' data als naam, geslacht, profielomschrijving en URL's van de foto's, laatste bericht etc. Maar bijvoorbeeld ook de volledige geboortedatum (terwijl app enkel leeftijd in jaren toont), datum/tijd van laatste activiteit en het type match.

De profile API toont data over jezelf, uiteraard usersettings en aanverwanten, maar ook aantal resterende 'likes' en wanneer deze zich reset (laat dat gewoon zien in de app joh, keihandig), lat/lon van laatste locatie met amper afwijking etc.

[DeluxZ]

Flapmo schreef op zaterdag 5 mei 2018 @ 16:19:
Zijn we het toch allemaal eens. Betaal niet fatsoenlijk voor je web dev en krijg je ook geen fatsoenlijke site. Bullshit in, bullshit out!

Kon ik dat onze sales mensen maar wijsmaken.. Als je zegt dat iets een dag kost durven ze het nog te verkopen voor een halve dag. Dan doen ze het maar lekker zelf

[CodeCaster]

Mugwump schreef op zaterdag 5 mei 2018 @ 13:23:
Ik zie vooral de effecten van het ellendige 'CRUD'-denken terug in die discussie.

Ik merk dat in de praktijk ook nog steeds. Ik heb aan een systeem gewerkt waarbij "alles" pluggable was door middel van dependency injection, marker interfaces en een startup-methode met zo'n twintig generic klassen, en oh wee als je één van de twintig niet goed had ingevuld, dan donderde de hele zooi in elkaar.

Alles met het excuus "Want dan kunnen we heel snel van databasesysteem wisselen". Want ja, dat doe je ook wekelijks. Het toevoegen van een kolom aan een database zorgde vervolgens voor wijzigingen in zo'n twintig files. En maar klagen dat wijzigingen zo lang duurden.

Ondertussen spuwde de APIs gewoon die volledige klassen uit, die direct (of nou ja, via een klasse of vijf) uit de database kwamen. Oftewel: wil je een databasekolom hernoemen, of erger nog, verplaatsen? Dan had je gegarandeerd een breaking change in je API, en kon je alle clients updaten.

Maar nee, dan proppen we gewoon een property met een lijst van type key-valuepairs (van het type (string, string) uiteraard, want wie wil er ooit iets anders opslaan dan strings?) op het object, dan heb je alle vrijheid om extra data op te slaan! Ja, en gooi de static typedness maar overboord. Oh, en misschien wil je ook niet alle attributen exposen naar de eindgebruiker, dus scrub die zak met properties even voordat je 'm de deur uitdoet.

Er wordt zo vaak geageerd tegen viewmodels en AutoMapper, maar een DTO/ViewModel is gewoon onmisbaar. Neem een Address-klasse, waarbij je bijvoorbeeld bij sommige calls een lijst van te selecteren landen wil meegeven, dan wil je niet je Address-databaseentiteit gaan aanpassen om een [Ignore]d List<Country> Countries-property aan toe te voegen en die te vullen vanuit de domein/service/whateverlaag.

En dat komt inderdaad door het CRUD-denken, maar een boel webapplicaties zíjn in de kern nu eenmaal CRUD-applicaties. Het niet gebruiken van DTO's/VM's lijkt in eerste instantie sneller te werken, totdat een applicatie draait en snel moet kunnen worden aangepast.

Je zou zeggen dat men het na die Mass Assignment-issues rond Ruby een paar jaar geleden (edit: 2012 alweer) zou zijn gaan snappen, namelijk dat je géén databaseentiteiten moet gebruiken in je API-laag, maar helaas. Prutsers gonna pruts.

[ Voor 16% gewijzigd door CodeCaster op 07-05-2018 14:29 ]

[Mugwump]

CodeCaster schreef op maandag 7 mei 2018 @ 14:22:
En dat komt inderdaad door het CRUD-denken, maar een boel webapplicaties zíjn in de kern nu eenmaal CRUD-applicaties. Het niet gebruiken van DTO's/VM's lijkt in eerste instantie sneller te werken, totdat een applicatie draait en snel moet kunnen worden aangepast.

CRUD is in mijn ogen veel meer een werk- en denkwijze dan dat een applicatie zelf 'CRUD' is. Vaak blijkt CRUD helemaal niet zo handig als een applicatie groeit / complexer wordt en het haalt vaak ook alle 'betekenis' uit je applicatie. Helaas is CRUD-denken één van de succesvolste exportproducten van ITers, dus dan krijg je de situatie dat, in plaats van dat de business beschrijft wat ze daadwerkelijk willen, aankomen met requirements als 'als gebruiker moet ik veldje X van entiteit Y kunnen wijzigen'. De business wil echter vrijwel nooit 'veldje X op entiteit Y wijzigen', maar bijvoorbeeld dat een gebruiker zijn of haar wachtwoord kan wijzigen, een gebruiker extra rechten geven, een order (deels) annuleren, een refund aanvragen of wat dan ook. Door je enkel te richten op data een veldjes wijzigen zien vaak zowel developers als business allerlei requirements over het hoofd.

[Crazy D]

DeluxZ schreef op maandag 7 mei 2018 @ 14:06:
Kon ik dat onze sales mensen maar wijsmaken.. Als je zegt dat iets een dag kost durven ze het nog te verkopen voor een halve dag. Dan doen ze het maar lekker zelf

Al geven ze het gratis weg. Gaat er alleen om, wat is de belofte die ze afgeven qua oplevermoment. Dat vind ik relevanter dan voor welk bedrag het verkocht is. Daar is sales tenslotte voor.

[Marc3l]

Mugwump schreef op maandag 7 mei 2018 @ 15:11:
[...]

Door je enkel te richten op data een veldjes wijzigen zien vaak zowel developers als business allerlei requirements over het hoofd.

Heel simpel, dan zal er waarschijnlijk geen/goed FO zijn.

[Mugwump]

Marc3l schreef op maandag 7 mei 2018 @ 16:46:
[...]


Heel simpel, dan zal er waarschijnlijk geen/goed FO zijn.

Klopt, dat noemen ze tegenwoordig Agile.
Maar zeker ook bij grotere complexere projecten zijn ontwerpen vaak vrij onvolledig of snel gedateerd. Zeker als het personeel aan de businesskant met een beetje hoge snelheid rouleert.

[Ryada]

Weet niet of het hier al gepost is maar het is vandaag een leuke dag geweest binnen het .net landschap:

MSDN: .NET Core 3 and Support for Windows Desktop Applications | .NET Blog

MSDN: Visual Studio 2017 version 15.7 and version 15.8 Preview 1 | The Visual...

[Tarkin]

Ik heb hier ook zo'n team zitten. Stel ik de vraag wat is jullie doel van de applicatie? "dat staat op sharepoint, lees het maar"

Vraag je wat doet die applicatie nu? "staat op sharepoint, lees dat 100p tellend FO maar",...

Niet echt bevorderend om te werken, heb je een jaar, dan lees ik je hele documentatie eens

[ Voor 55% gewijzigd door Tarkin op 08-05-2018 08:23 ]

[Matis]

Tarkin schreef op dinsdag 8 mei 2018 @ 08:22:
Ik heb hier ook zo'n team zitten. Stel ik de vraag wat is jullie doel van de applicatie? "dat staat op sharepoint, lees het maar"

Vraag je wat doet die applicatie nu? "staat op sharepoint, lees dat 100p tellend FO maar",...

Niet echt bevorderend om te werken, heb je een jaar, dan lees ik je hele documentatie eens

Ach zo had ik ook een collega:

Ik: Heb je nog wat leuks gedaan van het weekend?
Hij: Kijk maar op Facebook.
Ik: ....

[Lethalis]

Ryada schreef op maandag 7 mei 2018 @ 21:54:
Weet niet of het hier al gepost is maar het is vandaag een leuke dag geweest binnen het .net landschap:

MSDN: .NET Core 3 and Support for Windows Desktop Applications | .NET Blog

MSDN: Visual Studio 2017 version 15.7 and version 15.8 Preview 1 | The Visual...

Ik ga nog even verder lezen, maar erm...

Woohoo!!!!

Vooral die eerste. Dat gaat op mijn werk een serieuze impact hebben

Zodra ik over kan naar het nieuwe project formaat voor Windows Forms projecten (en designers blijven werken etc) doe ik dat meteen. Ik ben namelijk druk bezig om zoveel mogelijk projecten naar git te krijgen op mijn werk, en het mergen van csproj / vbproj is daarbij wat eng.

Met het nieuwe formaat durf ik ook de grote projecten wel aan.

[ Voor 16% gewijzigd door Lethalis op 08-05-2018 15:20 ]

[ZaZ]

Lethalis schreef op dinsdag 8 mei 2018 @ 15:06:
[...]

Ik ga nog even verder lezen, maar erm...

Woohoo!!!!

Vooral die eerste. Dat gaat op mijn werk een serieuze impact hebben

Zodra ik over kan naar het nieuwe project formaat voor Windows Forms projecten (en designers blijven werken etc) doe ik dat meteen. Ik ben namelijk druk bezig om zoveel mogelijk projecten naar git te krijgen op mijn werk, en het mergen van csproj / vbproj is daarbij wat eng.

Met het nieuwe formaat durf ik ook de grote projecten wel aan.

Maar die 'winpacks' draaien dus alleen op Windows. Ik zie nog niet echt het voordeel hiervan, behalve dat je standalone apps kan maken.
Ik kan nu ook al mijn hele backend naar netstandard en core migreren en alleen de GUI in Winforms laten.
Dat heb ik al vaker gedaan en werkt prima. Je zou zelfs als volgende stap dan de GUI in iets als "Eto forms" kunnen maken en dan heb je volledig cross platform desktop apps.

[Lethalis]

ZaZ schreef op dinsdag 8 mei 2018 @ 16:13:
[...]
Maar die 'winpacks' draaien dus alleen op Windows. Ik zie nog niet echt het voordeel hiervan, behalve dat je standalone apps kan maken.
Ik kan nu ook al mijn hele backend naar netstandard en core migreren en alleen de GUI in Winforms laten.
Dat heb ik al vaker gedaan en werkt prima. Je zou zelfs als volgende stap dan de GUI in iets als "Eto forms" kunnen maken en dan heb je volledig cross platform desktop apps.

De voordelen zijn eigenlijk:

1. Nieuw project formaat voor Windows Forms en WPF applicaties dat vele malen beter te mergen is.
2. Door Windows Forms en WPF te ondersteunen op .NET Core laten ze zien dat het geen side project is en dat .NET Core wel degelijk de toekomst is voor alle .NET projecten.

Voor de rest begint de open source community wakker te worden:

https://github.com/AvaloniaUI/Avalonia

[ZaZ]

Lethalis schreef op dinsdag 8 mei 2018 @ 16:25:
[...]

De voordelen zijn eigenlijk:

1. Nieuw project formaat voor Windows Forms en WPF applicaties dat vele malen beter te mergen is.
2. Door Windows Forms en WPF te ondersteunen op .NET Core laten ze zien dat het geen side project is en dat .NET Core wel degelijk de toekomst is voor alle .NET projecten.

Voor de rest begint de open source community wakker te worden:

https://github.com/AvaloniaUI/Avalonia

1. Mergen van project files heb ik eigenlijk nooit zoveel problemen mee. Eerder die verdomde resx en onleesbare designer files die bij Winforms horen, maar wie zegt dat ze daar iets aan gaan veranderen?
2. Ze zetten in op Core, dat is wel duidelijk. Die losse packs is volgens mij meer een sterfhuisconstructie waar ze wat legacy induwen zodat ze eerder de gewone .net kunnen gaan afstoten.

Maar goed, ik zie wel wat het wordt hoor. Het wordt vast uiteindelijk wel weer wat beter en dan migreer ik bestaande meuk gewoon braaf naar wat het dan is. Ik heb alleen niet echt iets gezien dat ik dacht van WOW, dit gaat dingen echt beter maken. Ik kan het meeste nu ook al zonder echt veel moeite.

Avalonia ken ik, maar die heeft niet eens een grid. Ik vind persoonlijk Eto forms prettiger en flexibeler. Kan je zelfs evenuteel per platform nog specifieke delen implementeren.

[Lethalis]

ZaZ schreef op dinsdag 8 mei 2018 @ 16:35:
[...]
1. Mergen van project files heb ik eigenlijk nooit zoveel problemen mee. Eerder die verdomde resx en onleesbare designer files die bij Winforms horen, maar wie zegt dat ze daar iets aan gaan veranderen?
2. Ze zetten in op Core, dat is wel duidelijk. Die losse packs is volgens mij meer een sterfhuisconstructie waar ze wat legacy induwen zodat ze eerder de gewone .net kunnen gaan afstoten.

Maar goed, ik zie wel wat het wordt hoor. Het wordt vast uiteindelijk wel weer wat beter en dan migreer ik bestaande meuk gewoon braaf naar wat het dan is. Ik heb alleen niet echt iets gezien dat ik dacht van WOW, dit gaat dingen echt beter maken. Ik kan het meeste nu ook al zonder echt veel moeite.

Avalonia ken ik, maar die heeft niet eens een grid. Ik vind persoonlijk Eto forms prettiger en flexibeler. Kan je zelfs evenuteel per platform nog specifieke delen implementeren.

1. Mja daar gaan ze waarschijnlijk niks aan veranderen. Die designer files gedragen zich soms ook erg onvoorspelbaar. Code die zomaar ineens ergens anders staat, zonder dat er echt iets veranderd is bijvoorbeeld (alleen maar omdat ik een designer file open die iemand anders gemaakt heeft... dan gaat Visual Studio even de kaarten schudden ofzo).

2. Ik denk dat je op de lange termijn gelijk hebt. Ik hoop op de lange termijn helemaal van Windows Forms en dergelijke verlost te zijn. Ben ook aan het overwegen om Electron (met Angular) of iets dergelijks te gaan gebruiken voor desktop applicaties en sowieso zoveel mogelijk web applicaties te bouwen.

Als dat betekent dat een steeds kleiner deel van onze code .NET zal zijn, so be it. Daar heeft Microsoft het dan zelf naar gemaakt (ironisch genoeg door ons Visual Studio Code en TypeScript te geven).

Ik ben al lang blij dat het nog even aandacht krijgt en het supporten van onze oude projecten daardoor een wat prettigere ervaring zal zijn.

[Ryada]

Er zitten meerdere voordelen aan die winpacks.

een ervan is dat je self contained windows apps kan maken. Waardoor je de runtime in je app hebt. Dit lost het probleem op dat de user altijd hun runtime geinstalleerd moeten hebben en moeten voldoen aan een minimale versie. Ook maakt dit testen makkelijker als je naar .net core 4 zou gaan bijv.

Het andere voordeel is dat je niet meer afhankelijk bent van .net FX of de end user zijn of haar pc. Je hebt nu door je hele app .net core tot je beschikking ipv .net fx. Dit betekend dat je een veel relaxdere API tot je beschikking hebt in je viewmodels/codebehind/welke andere client code die je gebruikt.

Ook zitten er een hoop veranderingen in .net core die nog niet in .net standard zitten. Denk aan Span<T> io streams bijvoorbeeld. Dus je krijgt imo een veel betere API tot je beschikking die ook een stuk sneller is.

[TheNephilim]

Shameless plug: Multiplayer gameserver ontwikkelen

Wat een rust en vrede hier vandaag. Iedereen hard aan de slag om die twee dagen die we deze week missen goed te maken?

[Ryada]

TheNephilim schreef op woensdag 9 mei 2018 @ 11:49:
Shameless plug: Multiplayer gameserver ontwikkelen

Wat een rust en vrede hier vandaag. Iedereen hard aan de slag om die twee dagen die we deze week missen goed te maken?

Vind het ook verdacht stil hierzo, zelf moet ik gewoon werken morgen en overmorgen dus ik werk gewoon net zoals ik normaal werk

[ThomasG]

Ik ben morgen gewoon vrij, en vrijdag verplicht vrij want het gebouw gaat dicht

[alienfruit]

Bij de klant is er een POS systeem die een telefoonnummer alleen tot 9 cijfers kan opslaan... Lekker handig

[Merethil]

alienfruit schreef op woensdag 9 mei 2018 @ 14:53:
Bij de klant is er een POS systeem die een telefoonnummer alleen tot 9 cijfers kan opslaan... Lekker handig

Hier hebben we een CRM met in de webservice een validatie dat een telefoonnummer minstens 10 karakters lang is, en moet beginnen met een 0. In Salesforce, de vervanger van het huidige CRM, hebben we geen validatie; hij mag ook gewoon leeg zijn.
Omdat hij in het oude CRM niet leeg mag zijn en gesynchroniseerd moet blijven, stoppen we bij een leeg telefoonnummer in Salesforce maar tien keer een "0" in het telefoonnummerveld van het oude CRM.

Dit was getest, akkoord bevonden en werkte allemaal prima. Maar toen het in productie stond was de productowner opeens heel verbaasd dat er allemaal "0"en in het oude CRM ontstonden! .... Dus.

Mooier nog, via de database was die validatie er natuurlijk niet, dus vanuit een ander systeem werd data gesynchroniseerd via stored procedure waar, je raadt het al, het telefoonnummer gewoon leeg werd ingevoerd. Als je in het oude CRM de boel opende in de UI was dit dan ook gewoon geen probleem ....Juist.

[kenneth]

Als je in een interface een member als public declareert, dan verwijdert R# de public modifier automatisch. Ben ik blijkbaar niet de enige

[Ryada]

kenneth schreef op woensdag 9 mei 2018 @ 15:58:
Als je in een interface een member als public declareert, dan verwijdert R# de public modifier automatisch. Ben ik blijkbaar niet de enige

Dit is toch de standaard binnen C#? Je kan geen privates definen via een Interface, dus het is zowieso altijd public.

[Mugwump]

TheNephilim schreef op woensdag 9 mei 2018 @ 11:49:
Shameless plug: Multiplayer gameserver ontwikkelen

Wat een rust en vrede hier vandaag. Iedereen hard aan de slag om die twee dagen die we deze week missen goed te maken?

Inderdaad even doorgeramd vandaag inderdaad. Kwam er deze week pas achter dat het alweer Hemelvaart was morgen en vrijdag eigenlijk iedereen bij de klant vrij was, dus maar even het werk van vijf dagen in drie gepropt.

[kenneth]

Ryada schreef op woensdag 9 mei 2018 @ 16:13:
[...]

Dit is toch de standaard binnen C#? Je kan geen privates definen via een Interface, dus het is zowieso altijd public.

Precies. En toch tik ik al tien jaar public. Ik kom er net achter dat R# dat corrigeert dus ik neem aan dat het een veelgemaakte fout is.

[Ryada]

kenneth schreef op woensdag 9 mei 2018 @ 18:57:
[...]

Precies. En toch tik ik al tien jaar public. Ik kom er net achter dat R# dat corrigeert dus ik neem aan dat het een veelgemaakte fout is.

Begrijpelijk. Ik zou het persoonlijk ook niet echt fout noemen net zoals object initializers die heb ik voorheen nog nooit gebruikt ik typte altijd braaf alle properties 1 voor 1 om ze dan ergens naar te assignen. Gelukkig heeft R# mij duidelijk gemaakt hoe het ook kan

[ThomasG]

kenneth schreef op woensdag 9 mei 2018 @ 18:57:
[...]

Precies. En toch tik ik al tien jaar public. Ik kom er net achter dat R# dat corrigeert dus ik neem aan dat het een veelgemaakte fout is.

Het is niet fout, het is enkel redundant omdat het implicit public is en er geen andere access modifier mogelijk is.

[Mugwump]

ThomasG schreef op woensdag 9 mei 2018 @ 19:20:
[...]
Het is niet fout, het is enkel redundant omdat het implicit public is en er geen andere access modifier mogelijk is.

Precies, het is gewoon één van de vele redundancy checks die Resharper doet. Net als "this." weghalen. Vreemd genoeg wordt dat in het genereren van de equalitymembers dan wel weer standaard gedaan, dus je krijgt code issues op hun eigen code generation.

[kenneth]

ThomasG schreef op woensdag 9 mei 2018 @ 19:20:
[...]
Het is niet fout, het is enkel redundant omdat het implicit public is en er geen andere access modifier mogelijk is.

Het is wel fout:



Thuis, geen R#

[RobertMe]

Zo gek is het ook niet dat je bij een interface geen access modifiers kunt gebruiken. Het is immers een interface/API, waarmee je aangeeft hoe anderen het kunnen gebruiken. En als het protected of private zou zijn is het dus geen onderdeel van de interface/API die anderen kunnen gebruiken.

Daarom verbaast het mij ook dat je in PHP wel access modifiers kunt gebruiken in een interface, en IIRC protected of private ook daadwerkelijk worden afgedwongen dat ze moeten bestaan in de implementatie.

[kenneth]

Het is ook hartstikke logisch! Was mijn muscle memory maar logisch

[Mugwump]

RobertMe schreef op woensdag 9 mei 2018 @ 20:49:
Zo gek is het ook niet dat je bij een interface geen access modifiers kunt gebruiken. Het is immers een interface/API, waarmee je aangeeft hoe anderen het kunnen gebruiken. En als het protected of private zou zijn is het dus geen onderdeel van de interface/API die anderen kunnen gebruiken.

Daarom verbaast het mij ook dat je in PHP wel access modifiers kunt gebruiken in een interface, en IIRC protected of private ook daadwerkelijk worden afgedwongen dat ze moeten bestaan in de implementatie.

Het OO-gedeelte van PHP is altijd al een halfbakken poging geweest om Java te kopiëren.
In Java kun je ook gewoon een access modifier meegeven aan een method signature, maar dat mag alleen public zijn. Public is de default voor methods, dus feitelijk is dat overbodig.

Ik ben zelf ook wel redelijk puristisch wat betreft interfaces. Het is niets meer dan een contract dat specifieert wat er verwacht wordt, namelijk een methode met naam A met nul of meer parameters en een return type. Eventueel nog verduidelijkt met wat documentatie. In Java hebben ze nu default methods waarmee je toch implementaties in interfaces kunt toevoegen. Heel slecht idee in mijn ogen, maar ik vond abstract classes al geen goed idee.

[whoami]

ThomasG schreef op woensdag 9 mei 2018 @ 19:20:
[...]
Het is niet fout, het is enkel redundant omdat het implicit public is en er geen andere access modifier mogelijk is.

De access modifier van een interface is by default public, maar dan nog zou dit niet door R# automatisch moeten verwijderd worden (tenzij je dat ergens kan instellen, maar ik betwijfel het).

Daarnaast is het wel fout om een access modifier te specifieren binnen de interface definitie. De members die een interface declareert kan je geen access modifier geven.

Het is niet fout, het is enkel redundant omdat het implicit public is en er geen andere access modifier mogelijk is.

Er is geen andere access modifier mogelijk dan public, maar je kan de interface wel expliciet implementeren

code:

public interface IMelp { void Foo(); }

public class Bar : IMelp
{
    void IMelp.Foo() {}
}

[ Voor 22% gewijzigd door whoami op 09-05-2018 22:13 ]

[F.West98]

Mugwump schreef op woensdag 9 mei 2018 @ 21:44:
[...]


Het OO-gedeelte van PHP is altijd al een halfbakken poging geweest om Java te kopiëren.
In Java kun je ook gewoon een access modifier meegeven aan een method signature, maar dat mag alleen public zijn. Public is de default voor methods, dus feitelijk is dat overbodig.

Ik ben zelf ook wel redelijk puristisch wat betreft interfaces. Het is niets meer dan een contract dat specifieert wat er verwacht wordt, namelijk een methode met naam A met nul of meer parameters en een return type. Eventueel nog verduidelijkt met wat documentatie. In Java hebben ze nu default methods waarmee je toch implementaties in interfaces kunt toevoegen. Heel slecht idee in mijn ogen, maar ik vond abstract classes al geen goed idee.

Default implementations in interfaces snap ik ook niet zo goed tbh. Maar abstract classes vind ik juist de uitvinding van de eeuw, heel handig imo.

[ThomasG]

F.West98 schreef op woensdag 9 mei 2018 @ 22:52:
[...]

Default implementations in interfaces snap ik ook niet zo goed tbh. Maar abstract classes vind ik juist de uitvinding van de eeuw, heel handig imo.

Default methods in interfaces zijn niets meer dan een (noodzakelijke) hack in de compiler sinds Java lamda expressies ondersteund. En omdat lambda expressies in java een verkapte interface zijn, zijn er aan veel bestaande interfaces extra methodes toegevoegd om lambda mogelijk te maken. En omdat ze bij Java van binary compatibility houden, konden ze niets anders dan default methods toevoegen; anders zou alle bestaande code niet meer werken, omdat de implementatie er niet is.

[Scott]

In Swift is het gebruik van default implementations in interfaces heel handig. Het promoot functioneel programmeren (want interfaces hebben geen state), maakt testen makkelijk (want geen to weinig state) en het maakt heel stukken code heel makkelijk herbruikbaar op een andere, wat ons betreft leesbaardere manier dan composition dat doet. Swift zelf gebruikt het ook veel, dus wellicht dat het wat taalafhankelijk is.

[ Voor 10% gewijzigd door Scott op 09-05-2018 23:45 ]

[Mugwump]

Scott schreef op woensdag 9 mei 2018 @ 23:44:
In Swift is het gebruik van default implementations in interfaces heel handig. Het promoot functioneel programmeren (want interfaces hebben geen state), maakt testen makkelijk (want geen to weinig state) en het maakt heel stukken code heel makkelijk herbruikbaar op een andere, wat ons betreft leesbaardere manier dan composition dat doet. Swift zelf gebruikt het ook veel, dus wellicht dat het wat taalafhankelijk is.

Ik vind het nogal vreemd dat je default methods in interfaces zou gebruiken om functioneel programmeren te promoten. Als dat nodig is om mensen "functioneel te laten programmeren" dan vrees ik dat men de principes van functioneel programmeren daarbij ook niet echt lekker toepast.

Dan zou ik waar het kan mensen gewoon lekker in Haskell aan de slag zetten ofzo.

De vraag is waarom je functioneel programmeren zou willen toepassen. In mijn ogen is het voornaamste voordeel van pure functionele code dat het heel schaalbaar is omdat je code zonder state heel makkelijk parallel kunt draaien. Daarbij is het wel cruciaal dat je daar qua architectuur al rekening mee hebt gehouden.

Een mooi voorbeeld was een recent project waarbij zwaar geleund werd op Azure Function met het idee dat dat heel mooi schaalbaar zou zijn. Dat zo'n functions ook, alleen had de betreffende developer doodleuk bedacht dat het wel handig zou zijn om alle functions in de keten (een stuk of tien) state te laten wegschrijven in lezen uit een SQL database met als gevolg dat de hele schaalbaarheid verdwenen was omdat de SQL database gewoon een keiharde bottleneck werd.

[Ryada]

Net Visual Studio maar even geupdate. En heb er nu al spijt van.

Thanks Visual Studio nu heb ik gigantisch veel warnings door mijn hele project heen omdat blijkbaar elke UE4 Macro in een skipped region zit

[Hydra]

F.West98 schreef op woensdag 9 mei 2018 @ 22:52:
Default implementations in interfaces snap ik ook niet zo goed tbh. Maar abstract classes vind ik juist de uitvinding van de eeuw, heel handig imo.

Stel je hebt een interface met twee methodes; eentje die een enkele user by email teruggeeft, en eentje die alle users teruggeeft:

code:

    Optional<User> findByEmail(String email)
    List<User> findAll()

Die eerste kun je een default implementatie meegeven waarbij je gewoon de list doorzoekt:

code:

    default Optional<User> findByEmail(String email) {
        return findAll().findAny(u -> u.email == email)
    }

Het is dan aan de developer om dit zo te laten of zelf een meer efficiente versie te maken. Je gebruikt ze niet vaak maar ze kunnen zeker handig zijn.

[Mugwump]

Hydra schreef op donderdag 10 mei 2018 @ 10:30:
[...]


Stel je hebt een interface met twee methodes; eentje die een enkele user by email teruggeeft, en eentje die alle users teruggeeft:

code:

    Optional<User> findByEmail(String email)
    List<User> findAll()

Die eerste kun je een default implementatie meegeven waarbij je gewoon de list doorzoekt:

code:

    default Optional<User> findByEmail(String email) {
        return findAll().findAny(u -> u.email == email)
    }

Het is dan aan de developer om dit zo te laten of zelf een meer efficiente versie te maken. Je gebruikt ze niet vaak maar ze kunnen zeker handig zijn.

Ik kom eigenlijk nooit dit soort use cases tegen. Deze is ook nogal gezocht moet ik zeggen. Ik wil helemaal geen defaults in een repository interface. De implementatie zal als je users uit een externe bron komen ook enorm inefficient zijn.

Met default methods is feitelijk een vorm van multiple inheritance geïntroduceerd en daar ben ik op zijn zachtst gezegd niet echt fan van.
Dat levert vooral heel veel verwarring op.

[Hydra]

Mugwump schreef op donderdag 10 mei 2018 @ 13:19:
Ik kom eigenlijk nooit dit soort use cases tegen. Deze is ook nogal gezocht moet ik zeggen.

Tuurlijk; het is letterlijk een voorbeeld dat ik terplekke verzonnen heb.

Met default methods is feitelijk een vorm van multiple inheritance geïntroduceerd en daar ben ik op zijn zachtst gezegd niet echt fan van.
Dat levert vooral heel veel verwarring op.

Je kunt in Java niet 2 interfaces implementeren met dezelfde default method implementatie dus het levert geen verwarring op. Multiple inheritance kan nog steeds niet.

[ThomasG]

Hydra schreef op donderdag 10 mei 2018 @ 13:22:
[...]


Tuurlijk; het is letterlijk een voorbeeld dat ik terplekke verzonnen heb.


[...]


Je kunt in Java niet 2 interfaces implementeren met dezelfde default method implementatie dus het levert geen verwarring op. Multiple inheritance kan nog steeds niet.

Ik had liever gezien dat Java de C# Extension methods overnam, in plaats van default methods op interfaces. Dan had je er namelijk veel meer aan gehad. Zo zijn er in java standaard veel packages die net die ene functionaliteit missen. Er zijn wel third party packages die dat oplossen, en die kunnen ook makkelijk van de third-party classes naar de java classes converten. Maar het kan niet makkelijk andersom, omdat die methode er niet is en je die class niet kunt aanpassen. Nu kan dat op andere manieren, maar dan wordt het altijd weer zo lelijk. Kortom, extension methods had beter geweest want kan exact wat default methods doen, plus meer.

[Mugwump]

Hydra schreef op donderdag 10 mei 2018 @ 13:22:
[...]


Tuurlijk; het is letterlijk een voorbeeld dat ik terplekke verzonnen heb.

Dat snap ik, maar het is dus niet echt een lekker voorbeeld.
De Java Function Interface is een voorbeeld waar ze default methods voor compositie gepropt hebben. Bij zoiets enorm generieks kan het op zich ook nog wel al blijf ik het lelijk vinden.

[...]


Je kunt in Java niet 2 interfaces implementeren met dezelfde default method implementatie dus het levert geen verwarring op. Multiple inheritance kan nog steeds niet.

Dat je niet twee interfaces met dezelfde default method signature kunt implementeren klopt, maar er is wel degelijk multiple inheritance. Multiple inheritance is simpelweg het principe dat je van meerdere parents erft. Je kunt bijvoorbeeld een parent class en een interface met een default method hebben. Daar mag bovendien overlap bestaan, want de parent class implementatie krijgt de voorkeur. Ook kun je vele interfaces met default methods implementeren, zolang die maar niet conflicteren.
Het hele idee achter interfaces is dat je een contract definieert. Als je vervolgens twee verschillende interfaces niet tegelijk kunt implementeren omdat het iemand wel handig leek om er util-achtige methoden in te proppen, dan heb je een probleem. Zeker wanneer die interfaces extern zijn.Dat levert in mijn ogen dus verwarring op.

[F.West98]

Ik ben het wel een beetje eens met @Mugwump, interfaces zijn niet bedoeld om ook gedrag te definiëren. Als je per se default implementations wil kan je dus een abstract class gebruiken, maar in situaties waar dat niet praktisch is lijkt mij een trait een veel nettere oplossing dan interface default implementations. Door een trait te gebruiken blijf je wel je API/contract gescheiden houden van je implementatie.

[Douweegbertje]

ah zo chill dat als je iets public maakt op github, dat mensen ook echt gaan contributen. Net een nette PR verwerkt wat een toegevoegde waarde geeft this.

[diondokter]

C# lijkt in versie 8 ook default implementations te krijgen.
YouTube: The future of C#

Ze leggen ook een usecase uit.
Als je een interface al hebt geshipped in een library en je wil je interface updaten in een nieuwe versie, dan is dat een breaking change. Maar als dat op te lossen is door een default te geven, dan is de interface wel te updaten en hoef je niet een 'ILogger2' te maken.

[Harrie_]

In navolging van de eerdere discussie hier (vorige week?) over gare code op scholen...

Er staat in webdesign weer een topic m.b.t. een schoolopdracht waarbij @DJMaze aangeeft dat e.e.a. absoluut niet veilig is. Reactie van TS is dat dat 'op school' nu niet niet ter zake doet en dat veiligheid later volgt. Kan TS in deze natuurlijk ook niets aan doen, maar ik blijf het bizar vinden dat men het op scholen de normaalste zaak van de wereld vind om eerst van alles te leren doen op brakke, onveilige manieren en er dan later een beveiligingssausje overheen te gieten...

[Mitchell]

Een collega stuurde me net een vacature met de meeste belachelijk functie eisen voor een Front-end Developer: https://www.indeed.com/m/...8e5d3e7f1dc3034&from=serp

Ik bedoel, wie kent er nou niet een Front-end developer welke ervaring heeft met Hardware prototyping, Robotics, Ethereum Smart contracts, IPFS, Game programming en Machine learning?

[alienfruit]

Junior ontwikkelaar met 4-6 jaar ervaringen

[DJMaze]

@Harrie_ zie ook ICT-studenten: wat wij leren is verouderd

[Mugwump]

Mitchell schreef op vrijdag 11 mei 2018 @ 10:49:
Een collega stuurde me net een vacature met de meeste belachelijk functie eisen voor een Front-end Developer: https://www.indeed.com/m/...8e5d3e7f1dc3034&from=serp

Ik bedoel, wie kent er nou niet een Front-end developer welke ervaring heeft met Hardware prototyping, Robotics, Ethereum Smart contracts, IPFS, Game programming en Machine learning?

Er staan wel meer bijzondere zaken in.
Bijvoorbeeld "4-6+ jaar ervaring'. Het is of 4-6 jaar ervaring of meer dan vier jaar ervaring. 4-6+ slaat nergens op.
Ook "prototype across multiple disciples of technology" is vrij bijzonder. Ga je je code op mensen schrijven met een stift of bedoelden ze misschien disciplines?

[R4gnax]

Mugwump schreef op zaterdag 12 mei 2018 @ 11:11:
[...]


Er staan wel meer bijzondere zaken in.
Bijvoorbeeld "4-6+ jaar ervaring'. Het is of 4-6 jaar ervaring of meer dan vier jaar ervaring. 4-6+ slaat nergens op.
Ook "prototype across multiple disciples of technology" is vrij bijzonder. Ga je je code op mensen schrijven met een stift of bedoelden ze misschien disciplines?

Wss. bedoelen ze "4 tot 6 jaar, maar liefst nog meer" en ja; het zal ongetwijfeld disciplines zijn. Nog zo'n reden om vacatureteksten door derden te laten proeflezen, i.p.v. blind op een spellings-checker te vertrouwen welke geen context ziet.

Misschien leuk voor wanneer een mislukte interviewer bij een sollicitatie met een pen door je sollicitatiebrief gaat strepen: eventjes de reeds met correcties gemarkeerde vacaturetekst tevoorschijn halen?

whoami schreef op woensdag 9 mei 2018 @ 22:11:
Er is geen andere access modifier mogelijk dan public, maar je kan de interface wel expliciet implementeren

code:

public interface IMelp { void Foo(); }

public class Bar : IMelp
{
    void IMelp.Foo() {}
}

Het wordt pas leuk als je een internal interface explicit implementeert. Op die manier kun je public classes maken waarbij interne details naar privileged assemblies gelekt kunnen worden, zonder dat andere assemblies (via normale wegen) ook aan die details kunnen komen.
(En ja; soms heb je dat echt nodig.)

[ Voor 28% gewijzigd door R4gnax op 12-05-2018 21:24 ]

[Marcj]

Ik ga een interessante week tegemoet, ik ben overgegaan naar een macbook als mijn ontwikkel-laptop. Wennen aan macOS ipv windows gaat wel even duren ben ik bang, maar tot nu toe valt het mee. Het feit dat ik een terminal heb waar gewoon bash draait vind ik iig al wel erg prettig

[DevWouter]

Marcj schreef op maandag 14 mei 2018 @ 09:03:
Ik ga een interessante week tegemoet, ik ben overgegaan naar een macbook als mijn ontwikkel-laptop. Wennen aan macOS ipv windows gaat wel even duren ben ik bang, maar tot nu toe valt het mee. Het feit dat ik een terminal heb waar gewoon bash draait vind ik iig al wel erg prettig

Op windows ram ik vaak ctrl+t terwijl ik in de command prompt ben om vervolgens diep zuchtend win+r,c,m,d,enter te doen.

[Marcj]

DevWouter schreef op maandag 14 mei 2018 @ 09:12:
[...]


Op windows ram ik vaak ctrl+t terwijl ik in de command prompt ben om vervolgens diep zuchtend win+r,c,m,d,enter te doen.

Ik zit nu nog veel te vaak ctrl-c/v te doen, terwijl dat cmd-c/v is. Ach, even weer wennen.

Moet wel zeggen, dat TouchID op een laptop vind ik een grotere meerwaarde dan ik eerst dacht. Helemaal nu hij ook werkt voor sudo

[Ryada]

DevWouter schreef op maandag 14 mei 2018 @ 09:12:
[...]


Op windows ram ik vaak ctrl+t terwijl ik in de command prompt ben om vervolgens diep zuchtend win+r,c,m,d,enter te doen.

Ik gebruik meestal: win+x,a
Dit opent dan wel Powershell maar het doet zijn werk prima

[Vincentio]

Ryada schreef op maandag 14 mei 2018 @ 09:14:
[...]

Ik gebruik meestal: win+x,a
Dit opent dan wel Powershell maar het doet zijn werk prima

cmd+spacebar , terminal, enter.

[DevWouter]

Marcj schreef op maandag 14 mei 2018 @ 09:13:
[...]

Ik zit nu nog veel te vaak ctrl-c/v te doen, terwijl dat cmd-c/v is. Ach, even weer wennen.

Moet wel zeggen, dat TouchID op een laptop vind ik een grotere meerwaarde dan ik eerst dacht. Helemaal nu hij ook werkt voor sudo

Op kantoor (Windows) gebruik ik een los toetsenbord om te voorkomen dat mijn muscle memory in de war raakt. Thuis gebruik gebruik ik alleen de toetsenbord van de MacBook.

Ryada schreef op maandag 14 mei 2018 @ 09:14:
[...]

Ik gebruik meestal: win+x,a
Dit opent dan wel Powershell maar het doet zijn werk prima

Ja.... maaaarrr.... Ik heb iTerm2 zo ingesteld dat het de laatste folder opent.
Bovendien heb ik vaak heleboel terminals/command-prompts open

[ZaZ]

DevWouter schreef op maandag 14 mei 2018 @ 09:12:
[...]


Op windows ram ik vaak ctrl+t terwijl ik in de command prompt ben om vervolgens diep zuchtend win+r,c,m,d,enter te doen.

Ik heb gewoon altijd permanent ConEmu open en global hotkeys voor cmd/powershell/bash.
Werkt prachtig.

[ThomasG]

Vincentio schreef op maandag 14 mei 2018 @ 09:19:
[...]

cmd+spacebar , terminal, enter.

Dat is zo'n beetje alles wat je nodig hebt Spotlight is geniaal, en er is (jammer genoeg) nog steeds geen goede tegenhanger voor op Windows en Linux dat hetzelfde kan of meer. Vooral omdat je er bijvoorbeeld vliegensvlug mee in je mail kunt zoeken met alle toeters en bellen. Documenten kunt bekijken, en als rekenmachine in elke applicatie kunt gebruiken.

Spotlight en Preview is wat ik keihard mis als ik op een Windows systeem zit; en natuurlijk de terminal, hoewel Powershell aardig in de buurt komt. Maar zsh is

[Creepy]

Gnome shell komt aardig in de buurt. Windows toets, term<enter> voor de terminal bijv. Die zoekt ook in documenten om die vervolgens weer direct te kunnen openen. Mail doet ie bij mij niet, en een rekenmachnine moet je ook los starten

[Tjolk]

Marcj schreef op maandag 14 mei 2018 @ 09:03:
Ik ga een interessante week tegemoet, ik ben overgegaan naar een macbook als mijn ontwikkel-laptop. Wennen aan macOS ipv windows gaat wel even duren ben ik bang, maar tot nu toe valt het mee. Het feit dat ik een terminal heb waar gewoon bash draait vind ik iig al wel erg prettig

Gecondoleerd.

Ik heb me een paar jaar terug naar een iMac laten praten, maar er nooit aan kunnen wennen. Na 2 jaar proberen + 1 jaar bedelen ben ik inmiddels lekker aan het werk op Ubuntu. Een verademing.

[Gropah]

Persoonlijk dev ik ook graag op ubuntu en heb ik windows alleen op mijn game PC staan. Heb er alleen op dit moment een beetje broertje dood aan. Ik wou wat neurale netwerken trainen, mijn devtop heeft een 1050 er in zitten, maar mijn game pc een 1070, dus ik wou "even" ubuntu er op knallen. Er was nog een linux partitie met debian maar dat was voor de CPU upgrade dus leek mij goed om even opnieuw te installeren.

Het heeft even geduurd maar ondertussen kan ik booten naar ubuntu. Alleen vind grub windows niet, dus is windows op dit moment onbenaderbaar... Al van alles geprobeerd om windows te vinden met grub maar het werkt niet. Ga eerst windows weer werkend krijgen en dan ga ik proberen om vanuit de windows boot manager naar linux te komen.

Simpel... maar niet heus

[mcDavid]

Gropah schreef op maandag 14 mei 2018 @ 14:41:
Ga eerst windows weer werkend krijgen en dan ga ik proberen om vanuit de windows boot manager naar linux te komen.

Simpel... maar niet heus

Oef! Weet je dat héél zeker? Over het algemeen werkt dat echt ordegroottes kutter dan grub.

Heb je boot-repair gebruikt op Ubuntu? https://help.ubuntu.com/community/Boot-Repair
Fixt bij mij altijd magisch alles.

[Gropah]

mcDavid schreef op maandag 14 mei 2018 @ 14:47:
[...]

Oef! Weet je dat héél zeker? Over het algemeen werkt dat echt ordegroottes kutter dan grub.

Heb je boot-repair gebruikt op Ubuntu? https://help.ubuntu.com/community/Boot-Repair
Fixt bij mij altijd magisch alles.

yup, al gebruikt, maar hij pakt windows niet. En misschien werkt het minder, maar ubuntu is mij op deze machine een stukje minder waard dan de windows install.

Het nare is vooral dat ik, volgens mij, GRUB alleen heb geinstalleerd op de 2e HDD waar ubuntu op staat. De eerste (met daarop windows) zou hij niet aangeraakt moeten hebben. Ik had gedacht dat door hem standaard naar de eerste te laten booten hij standaard naar windows zou gaan, tenzij ik bij het booten naar de boot selectie zou gaan en daar de 2e zou kiezen. Helaas maakt het nu niet uit naar welke schijf ik boot.

Overigens mounten alle schijven nog wel, dus ik heb nog hoop dat het goed gaat komen. Zal nog even wat dingen proberen en anders open ik wel een topic in NOS oid

edit: hmm, misschien is het toch al te laat. bootrec /rebuildbcd geeft 0 installatie's weer

[ Voor 4% gewijzigd door Gropah op 14-05-2018 14:54 ]

[dcm360]

Wellicht UEFI en legacy-mode door elkaar aan het gebruiken? Dat kan rare problemen opleveren. Zo kan ik op mijn pc Windows alleen starten door in het bootmenu van het BIOS Windows te kiezen, en lukt het Grub niet om Windows te starten. Dat het deze kant uitwerkt bij mij is overigens wel bewust, ik zou ook kunnen kiezen voor standaard Windows booten en Linux via het bootmenu, maar Windows kan me meestal wel gestolen worden.

[Gropah]

dcm360 schreef op maandag 14 mei 2018 @ 15:01:
Wellicht UEFI en legacy-mode door elkaar aan het gebruiken? Dat kan rare problemen opleveren. Zo kan ik op mijn pc Windows alleen starten door in het bootmenu van het BIOS Windows te kiezen, en lukt het Grub niet om Windows te starten. Dat het deze kant uitwerkt bij mij is overigens wel bewust, ik zou ook kunnen kiezen voor standaard Windows booten en Linux via het bootmenu, maar Windows kan me meestal wel gestolen worden.

Dat zou inderdaad kunnen, maar naar wat ik zelf op de ubuntu wiki heb gevonden draait mijn ubuntu in UEFI modus. Dus dat zou het probleem volgens mij niet moeten zijn... Of mijn windows moet op BIOS staan. Hmm. Das nog wel een goede. Thanks voor de tip

[ThomasG]

Gropah schreef op maandag 14 mei 2018 @ 14:52:
[...]


yup, al gebruikt, maar hij pakt windows niet. En misschien werkt het minder, maar ubuntu is mij op deze machine een stukje minder waard dan de windows install.

Het nare is vooral dat ik, volgens mij, GRUB alleen heb geinstalleerd op de 2e HDD waar ubuntu op staat. De eerste (met daarop windows) zou hij niet aangeraakt moeten hebben. Ik had gedacht dat door hem standaard naar de eerste te laten booten hij standaard naar windows zou gaan, tenzij ik bij het booten naar de boot selectie zou gaan en daar de 2e zou kiezen. Helaas maakt het nu niet uit naar welke schijf ik boot.

Overigens mounten alle schijven nog wel, dus ik heb nog hoop dat het goed gaat komen. Zal nog even wat dingen proberen en anders open ik wel een topic in NOS oid

edit: hmm, misschien is het toch al te laat. bootrec /rebuildbcd geeft 0 installatie's weer

Om dit soort redenen installeer ik een ander OS altijd op een andere schijf, en koppel ik de schijf met het andere OS altijd fysiek los. Al vaak genoeg gehad dat Windows installeert op schijf 1, en windows de bootloader installeert op schijf 0. Doe je iets met schijf 0, is je bootloader weg.. Als ik dan naar een ander OS will booten, doe ik dat via de sneltoets om de BIOS de bootschijf te laten kiezen. (bijna) net zo gemakkelijk, en bespaart een hoop kopzorgen.

[Gropah]

ThomasG schreef op maandag 14 mei 2018 @ 15:08:
[...]
Om dit soort redenen installeer ik een ander OS altijd op een andere schijf, en koppel ik de schijf met het andere OS altijd fysiek los. Al vaak genoeg gehad dat Windows installeert op schijf 1, en windows de bootloader installeert op schijf 0. Doe je iets met schijf 0, is je bootloader weg.. Als ik dan naar een ander OS will booten, doe ik dat via de sneltoets om de BIOS de bootschijf te laten kiezen. (bijna) net zo gemakkelijk, en bespaart een hoop kopzorgen.

achteraf is altijd makkelijk praten, maar dit is vanaf nu zeker iets wat ik in mijn achterhoofd ga houden. Had eerlijk gezegd ook niet verwacht dat ik hier zo'n drama van zou hebben.

[ZaZ]

Doet me denken aan de laatste keer dat ik met mijn stomme kop iemand die ik niet eens ken heb geholpen.
De vader van mijn buurman (oud mannetje, snapt niets van computers) had een ultrabook die niet meer opstartte.
Ik had er eigenlijk totaal geen zin en dat soort dingen doe ik eigenlijk al tijden niet meer, maar had toen zoiets van "ik kijk er wel eventjes naar"
Ik dacht nog: Ik ga niet heel diep erin en kijk gewoon even een kwartiertje of het iets makkelijks is.
Enfin, Windows start niet door. Ik zie in de BIOS dat ding op legacy staan en dacht niet heel goed na en zette 'm op EUFI met als enige gedachte dat een moderne Windows installatie eigenlijk altijd op UEFI staat.
Gewoon effe proberen of dat het is.
Exit and Save -> Reboot -> Geen bootloader gevonden.
Ok, dan zet ik het wel effe terug en ga ik kijken wat er dan echt aan de hand is.
Reboot -> Del/verschillende F-toetsen -> geen bootloader
Ohja, da's waar ook. Je kan niet meer altijd in de BIOS komen op die manier als ie op EUFI staat!

Kudt

Maarja, zo kan ik 'm niet teruggeven. Als ik ergens aan begin ga ik 'm niet nog kreupeler teruggeven.
Hele avond bezig geweest om een ultrabook uit elkaar te peuteren om op de meest onmogelijke plek de batterij te vinden en 'm op die manier weer op legacy te krijgen.
Daarna was het oorspronkelijke issue in een half uurtje gefixed.
Had ik maar niet zo gehaast te werk gegaan was ik veel eerder klaar.
Of nog beter, had ik maar gewoon meteen nee gezegd, dat doe ik niet meer.

[Marcj]

DevWouter schreef op dinsdag 1 mei 2018 @ 12:58:
[...]

---

Een test die een goeie vriend van mij hanteert is een unit test die opgelost moet worden.

code:

var input = [1, 2, 3, 5, 4,7,6,8, 9];
var expect = [
  [1, 2, 3, 5],
  [4, 7],
  [6, 8, 9]
];

// Implementeer de functie, geef een lijst van reeksen terug op basis van de input. 
// Elke keer als het volgende getal niet oplopend is begin je een nieuwe reeks.
var actual = func(input);

Een behoorlijk aantal van de kandidaten schijnt hier al moeite mee te hebben en een paar van de oplossingen die aan hem getoond werden sloegen nergens op.

Dank voor deze opdracht. Ik heb het net geprobeerd bij een sollicitant en het uitvoeren van deze opdracht gaf me inderdaad veel inzicht! In dit geval helaas niet positief, maar dan zijn we er wel snel achter.

[Harrie_]

@Marcj Mag ik misschien vragen:
- Om wat voor functie het dan gaat
- Wie daarop af komt en wat deze persoon op zijn/haar CV heeft staan?
- Met wat voor oplossing deze persoon op de proppen kwam (had hij/zij überhaupt een oplossing?)

[Mugwump]

Marcj schreef op maandag 14 mei 2018 @ 16:40:
[...]


Dank voor deze opdracht. Ik heb het net geprobeerd bij een sollicitant en het uitvoeren van deze opdracht gaf me inderdaad veel inzicht! In dit geval helaas niet positief, maar dan zijn we er wel snel achter.

Mocht je toevallig Java doen, dan is deze site ook nog wel aardig. Daar moeten mensen wat basale algoritmes implementeren en de resultaten daarvan worden enerzijds automatisch geverifieerd en kun je vervolgens ook bespreken met een kandidaat natuurlijk.

[armageddon_2k1]

Ik zou als sollicitant niet graag willen werken bij een bedrijf dat te laf is om zelf z'n algoritme testjes te verzinnen. Copy-pasten van assessments..... Dan weet je nooit zeker of ze de assessments zelf uberhaubt wel eens gedaan hebben.

[Giesber]

armageddon_2k1 schreef op maandag 14 mei 2018 @ 17:17:
Ik zou als sollicitant niet graag willen werken bij een bedrijf dat te laf is om zelf z'n algoritme testjes te verzinnen. Copy-pasten van assessments..... Dan weet je nooit zeker of ze de assessments zelf uberhaubt wel eens gedaan hebben.

Het maakt eigenlijk niet eens uit of ze de assessments zelf gedaan hebben. Het gaat hem niet om het resultaat, maar om hoe je tot het resultaat komt. Dat je niet wil werken bij bedrijven die dat niet door hebben, dat snap ik ergens wel. Maar het kan ook een eerste selectie zijn om minder gesprekken te moeten voeren.

Waarom mogen testjes (of meer algemeen: code of zelfs werk in het algemeen) trouwens niet gekopieerd worden? Schrijf jij ook je eigen StringUtils.isBlank() misschien? Ik huiver nog meer van bedrijven die denken dat het beter is om het warm water opnieuw uit te vinden dan bedrijven die in de gaten hebben dat anderen beter zijn op bepaalde gebieden.

[Mugwump]

armageddon_2k1 schreef op maandag 14 mei 2018 @ 17:17:
Ik zou als sollicitant niet graag willen werken bij een bedrijf dat te laf is om zelf z'n algoritme testjes te verzinnen. Copy-pasten van assessments..... Dan weet je nooit zeker of ze de assessments zelf uberhaubt wel eens gedaan hebben.

Wil je ook niet werken bij bedrijven die te laf zijn om hun eigen persoonlijkheids- of IQ-tests te ontwikkelen?

[farlane]

Mugwump schreef op maandag 14 mei 2018 @ 16:59:
[...]


Mocht je toevallig Java doen, dan is deze site ook nog wel aardig.

Please import ONLY standard Java 1.5-1.6 classes

Die website is not recommended for new designs .....

[Lethalis]

Mugwump schreef op maandag 14 mei 2018 @ 18:36:
[...]


Wil je ook niet werken bij bedrijven die te laf zijn om hun eigen persoonlijkheids- of IQ-tests te ontwikkelen?

Ik zou liever niet bij een bedrijf willen werken die per se wil dat ik een persoonlijkheids- of IQ test moet doen.

Zeker niet in mijn rol als programmeur. Het is niet alsof ik nou verantwoordelijk ben voor mensenlevens ofzo.

Bovendien vind ik IQ ook privacy gevoelig. Het schept verwachtingen die je misschien helemaal niet waar kunt maken (een hoog IQ betekent niet meteen dat je ook beter presteert, je kan er ook sneller afgeleid door zijn of chaotischer).

Of juist dat je niet aangenomen wordt, omdat de werkgever vreest dat je je teveel gaat vervelen. Terwijl dat niet zo hoeft te zijn.

Daarnaast is het een moment opname. Een slechte score op een IQ test betekent ook niet meteen dat je te dom voor een functie zou zijn.

Kortom, ik vind het helemaal niks.

Ik wil best een paar programmeeropdrachten doen, want daar kom ik immers voor, maar that's it.

PS
Persoonlijkheidstesten zijn ook onbetrouwbaar. Ooit op mijn 13e een test op de middelbare school moeten doen en dat leverde mij een gesprek met mijn mentor op die zei dat ik de test "als een robot" had ingevuld

[ Voor 9% gewijzigd door Lethalis op 15-05-2018 07:07 ]

[armageddon_2k1]

Mugwump schreef op maandag 14 mei 2018 @ 18:36:
[...]


Wil je ook niet werken bij bedrijven die te laf zijn om hun eigen persoonlijkheids- of IQ-tests te ontwikkelen?

Nee, want ik heb zelden meegemaakt dat dat iets toevoegt...Een goede recruiter, een goede manager en HR persoon en je hebt al die peperdure assessments niet nodig :-) (okee, die mensen zijn ook duur). Daarnaast, mijn vrouw is psycholoog en kan me vertellen dat zelfs aan de meest ingewikkelde IQ en persoonlijkheids-tests zoveel haken en ogen zitten dat je bijna een PhD moet hebben om het een beetje te interpreteren

Zo kan ik me herinneren dat er iemand was bij ons die supergoed aansloot, maar z'n karakter was te 'geel' (insight kleurtjes voor de bekenden) en we hadden een roder persoon nodig..... tja

Giesber schreef op maandag 14 mei 2018 @ 18:11:
[...]

Het maakt eigenlijk niet eens uit of ze de assessments zelf gedaan hebben. Het gaat hem niet om het resultaat, maar om hoe je tot het resultaat komt. Dat je niet wil werken bij bedrijven die dat niet door hebben, dat snap ik ergens wel. Maar het kan ook een eerste selectie zijn om minder gesprekken te moeten voeren.

Waarom mogen testjes (of meer algemeen: code of zelfs werk in het algemeen) trouwens niet gekopieerd worden? Schrijf jij ook je eigen StringUtils.isBlank() misschien? Ik huiver nog meer van bedrijven die denken dat het beter is om het warm water opnieuw uit te vinden dan bedrijven die in de gaten hebben dat anderen beter zijn op bepaalde gebieden.

Ojee, wat een aannames.
Als je als bedrijf, of als iemand die een programmeur aanneemt, geen goede case kan verzinnen (danwel uitzoeken) om deze programmeur te testen, dan vraag ik me serieus af wat je in dat gesprek doet. Maar domweg een test-batterij inkopen en de resultaten geautomatiseerd zien.... nee. Wat je zelf al zegt, het ligt eraan hoe iemand tot het resultaat komt. En het denkproces krijg je niet te zien door iemand even een uurtje een online assessment te laten doen.

[ Voor 78% gewijzigd door armageddon_2k1 op 15-05-2018 08:11 ]

[Hydra]

Mugwump schreef op maandag 14 mei 2018 @ 16:59:
Mocht je toevallig Java doen, dan is deze site ook nog wel aardig. Daar moeten mensen wat basale algoritmes implementeren en de resultaten daarvan worden enerzijds automatisch geverifieerd en kun je vervolgens ook bespreken met een kandidaat natuurlijk.

Die hebben wij ook gebruikt en kan ik afraden. Er is een erg beperkte set opdrachten, de site is outdated en ze opdrachten die er zijn, zijn simpel te vinden op internet. Die better programmer is meer een filter om te voorkomen dat je mensen interviewt die liegen op hun CV maar daar faalt het dus in.

Anyway; ik heb een tijdje terug zelf een test gemaakt die eigenlijk gewoon aansluit bij je 'dagelijks' werk. Zit wel wat algoritmisch werk in maar is primair gewoon het bouwen van een service. Ik vind of je dependency injection en testing snapt belangrijker dan dat je een string kunt reversen.

armageddon_2k1 schreef op dinsdag 15 mei 2018 @ 08:05:
Ojee, wat een aannames.
Als je als bedrijf, of als iemand die een programmeur aanneemt, geen goede case kan verzinnen (danwel uitzoeken) om deze programmeur te testen, dan vraag ik me serieus af wat je in dat gesprek doet. Maar domweg een test-batterij inkopen en de resultaten geautomatiseerd zien.... nee. Wat je zelf al zegt, het ligt eraan hoe iemand tot het resultaat komt. En het denkproces krijg je niet te zien door iemand even een uurtje een online assessment te laten doen.

Er zijn eigenlijk 2 test fases: eentje waarin je mensen uit wil filteren die je uberhaupt niet op interview wil hebben, en een tweede waarin je beoordeelt hoe goed iemand nu is. Voor die eerste fase zijn dat soort tests prima.

[ Voor 29% gewijzigd door Hydra op 15-05-2018 08:30 ]