De Devschuur Coffee Corner - Iteratie ➑

[Jan_V]

alwinuzz schreef op dinsdag 03 februari 2015 @ 20:30:
[...]

Heb je al eens een restore gedaan van die 1 TB?

Ik laatst wel, en dat ging echt heel traag. Als in een maand bezig geweest. Als je dan googlet merk je dat dit een vaker voorkomend probleem is bij CrashPlan. Nja je kan niet alles krijgen voor die prijs.

Initiele backup heeft zo'n 87 dagen geduurd (was net over naar KPN ADSL).

Moet er niet aan denken om te restoren. Gelukkig is eigenlijk niets van die 1TB van 'levensbelang'. Dat staat namelijk allemaal in DropBox en Onedrive.

[Ryur]

PrisonerOfPain schreef op woensdag 04 februari 2015 @ 15:32:
[...]


In welke wereld leef jij waarin Java wel een fatsoenlijk alternatief is voor client applicaties?

De Jetbrains producten vind ik een mooi voorbeeld van GOEDE Java-client applicaties?

[dcm360]

PrisonerOfPain schreef op woensdag 04 februari 2015 @ 15:32:
[...]


In welke wereld leef jij waarin Java wel een fatsoenlijk alternatief is voor client applicaties?

Dat was dan ook weer net niet wat ik wil beweren. Het was meer dat ze de bewering maken dat ze geen Java gebruiken vanwege de lekken erin. In dat geval kan je wel heel veel meer software afschrijven, bijvoorbeeld de win32-api omdat Windows lekken bevat.

[Alex)]

D-Raven schreef op woensdag 04 februari 2015 @ 15:32:
[...]

Overigens, FOK ligt plat. Kom ik ook eens daar, krijg je doctrine exceptions rond de oren gegooid.
Weet ik ook meteen weer waarom ik daar zo weinig kom

Danny ontwikkelt dus nog steeds in prod

[BtM909]

Of hij is alleen vergeten een refresh van z'n db te doen op prod

[_Moe_]

Voor de PHP-lovers en daar bovenop nog eens Laravel-lovers:

Laravel 5 is uit!

[DeluxZ]

_Moe_ schreef op woensdag 04 februari 2015 @ 16:04:
Voor de PHP-lovers en daar bovenop nog eens Laravel-lovers:

Laravel 5 is uit!

Ik ben eigenlijk helemaal afgestapt van PHP en naar ASP.NET ( ) gegaan (in mijn werkomgeving). Prive maar eens proberen, als ik tijd heb...

[ Voor 4% gewijzigd door DeluxZ op 04-02-2015 16:17 ]

[BikkelZ]

kenneth schreef op woensdag 04 februari 2015 @ 15:30:
Heel slim. Zo ontloop je eventuele bugs in DateTime.TryParse!

Liep er vandaag nog tegen aan dat DateTime.TryParse("Gisteren") niet werkte. Dat werkt onder Cocoa wel

[.oisyn]

NIXXES SOFTWARE TO DEVELOP RISE OF THE TOMB RAIDER ON XBOX 360

[ Voor 14% gewijzigd door .oisyn op 04-02-2015 16:18 ]

[Firesphere]

.oisyn schreef op woensdag 04 februari 2015 @ 16:18:
http://www.ign.com/articl...e-tomb-raider-on-xbox-360

[afbeelding]

En wanneer komt de PC versie?

[.oisyn]

I don't know, I just work here.

[Xesxen]

Anders gevraagd: Komt er een PC versie?

[.oisyn]

.oisyn in "De Devschuur Coffee Corner - Iteratie ➑"

[Firesphere]

.oisyn schreef op woensdag 04 februari 2015 @ 16:20:
I don't know, I just work here.

En XBox One dan?

[.oisyn]

Eind dit jaar.

[Mercatres]

.oisyn schreef op woensdag 04 februari 2015 @ 16:24:
Eind dit jaar.

En Raspberry Pi 2?

[.oisyn]

Volgende week.

[Mercatres]

.oisyn schreef op woensdag 04 februari 2015 @ 16:25:
Volgende week.

Woei! Komt goed uit, want m'n Pi heb ik morgen vast

[Firesphere]

En PS2/3/4?

[.oisyn]

Ja fuck zeg, google anders gewoon even

http://en.wikipedia.org/wiki/Rise_of_the_Tomb_Raider

[Mercatres]

.oisyn schreef op woensdag 04 februari 2015 @ 16:27:
Ja fuck zeg, google anders gewoon even

http://en.wikipedia.org/wiki/Rise_of_the_Tomb_Raider

Jij bent degene die het postte.

[.oisyn]

Ja, over de Xbox 360 versie

http://www.gameinformer.c...-tomb-raider-6545651.aspx

Lara will gear up for her new adventure on Xbox One and Xbox 360 this holiday season, but the studio hasn't ruled out the possibility that the game will come to other consoles later on.

[Ealanrian]

.oisyn schreef op woensdag 04 februari 2015 @ 16:27:
Ja fuck zeg, google anders gewoon even

http://en.wikipedia.org/wiki/Rise_of_the_Tomb_Raider

Waarom moeite doen als er iemand is die het weet?

[Firesphere]

.oisyn schreef op woensdag 04 februari 2015 @ 16:27:
Ja fuck zeg, google anders gewoon even

http://en.wikipedia.org/wiki/Rise_of_the_Tomb_Raider

Niet zo aangebrand! Wees blij dat we enige interesse tonen!

[.oisyn]

Ealanrian schreef op woensdag 04 februari 2015 @ 16:29:
[...]

Waarom moeite doen als er iemand is die het weet?

1. Ik weet het niet
2. Als ik het wist mocht ik het niet zeggen, ik ga er vanuit dat iedereen dat hier wel snapt

[WernerL]

Fuck de xbox. Waarom kan er niet eerst een PC versie gemaakt worden?

[Firesphere]

.oisyn schreef op woensdag 04 februari 2015 @ 16:30:
[...]


1. Ik weet het niet
2. Als ik het wist mocht ik het niet zeggen, ik ga er vanuit dat iedereen dat hier wel snapt

Ja, zo werkt't hier natuurlijk niet he. Gewoon antwoord geven!

[alienfruit]

Ja, of de Mac variant... Is toch gewoon op de juiste knop drukken

[ Voor 48% gewijzigd door alienfruit op 04-02-2015 16:46 ]

[wackmaniac]

Daar loop ik de laatste tijd ook tegen aan; Heroes Of Might And Magic III HD, maar een versie voor Mac? Ho maar

[alienfruit]

En dan zit Mac zelfs in de naam van het spel!

[Mercatres]

alienfruit schreef op woensdag 04 februari 2015 @ 16:48:
En dan zit Mac zelfs in de naam van het spel!

Woa! Een 3? Half-Life 3 confirmed!

[Douweegbertje]

alienfruit schreef op woensdag 04 februari 2015 @ 16:48:
En dan zit Mac zelfs in de naam van het spel!

Heb jij dan iets met ritalin, elitair of een nultarief?

[BtM909]

Ok, wie vinden jullie het leukste van alle versies?

---

Trouwens .oisyn, waar is die nude-patch

[.oisyn]

Deze

[ Voor 4% gewijzigd door .oisyn op 04-02-2015 17:16 ]

[Jan_V]

BtM909 schreef op woensdag 04 februari 2015 @ 17:02:
[afbeelding]

Ok, wie vinden jullie het leukste van alle versies?

---

Trouwens .oisyn, waar is die nude-patch

Die rechts boven, high poly

[BM]

BtM909 schreef op woensdag 04 februari 2015 @ 17:02:
[afbeelding]

Ok, wie vinden jullie het leukste van alle versies?

Degene uit de laatste game, vooraan dus. Cute

[.oisyn]

Jan_V schreef op woensdag 04 februari 2015 @ 17:40:
[...]

Die rechts boven, high poly

Da's Lara Croft uit The Guardian of Light. De enige niet-TR Lara.

bovenste rij: TR1, TR The Last Relevation, (iets naar voren) TR Legend, TR Chronicles, TR The Angle of Darkness, LC:GOL
onderste rij: TR Anniversary, Tomb Raider (2013), TR Underworld, TR2/TR3

[ Voor 35% gewijzigd door .oisyn op 04-02-2015 18:18 ]

[jip_86]

Leuk man memory profilen.

- Aanpassing -> Woot zut word opgeruimd
- Undo fix to double check -> Probleem treed weer op (logisch, ik heb de fix gesloopt)
- Pas aanpassing weer toe -> Zut word niet meer opgeruimd

[SPee]

Dat wel uitgevoerd?

[Caelorum]

.oisyn schreef op woensdag 04 februari 2015 @ 17:16:
Deze
[afbeelding]

BtM909 schreef op woensdag 04 februari 2015 @ 17:02:
[...]
Trouwens .oisyn, waar is die nude-patch

Dat dus

[Rutix]

Ryur schreef op woensdag 04 februari 2015 @ 15:34:
[...]

De Jetbrains producten vind ik een mooi voorbeeld van GOEDE Java-client applicaties?

En toch hebben ook die weleens de squirks die ik in bijna alle java applications voorbij zie komen. Alhoewel ze in de producten van Jetbrains veeeeel minder voorkomen

[F.West98]

Wat ik vooral heel irritant vind aan de producten van JetBrains is dat ze na een UAC-melding naar voren springen en leuk geel gaan knipperen in de taakbalk. Ongevraagd.

[dcm360]

Ehm, is dat zo? Daar heb ik geen last van...

[F.West98]

Ik heb daar regelmatig last van op mijn computer. Voor én na mijn Windows herinstallatie.

[Ryur]

Kloppen deze problemen met de "F.West98"-problemen-schema?
Ik ben zelf de tel een beetje kwijt!

[Megamind]

Ik gebruik ook tal van jetbrains producten thuis en op werk, Re# al sinds 2.5 maar nog nooit last van gehad

[ Voor 4% gewijzigd door Megamind op 04-02-2015 20:27 ]

[alienfruit]

Heb ik helemaal geen last van op mijn Mac

[azerty]

F.West98 schreef op woensdag 04 februari 2015 @ 20:01:
Wat ik vooral heel irritant vind aan de producten van JetBrains is dat ze na een UAC-melding naar voren springen en leuk geel gaan knipperen in de taakbalk. Ongevraagd.

Niet alleen na een UAC... Bij mij soms ook in andere gevallen.

[F.West98]

wsitedesign schreef op woensdag 04 februari 2015 @ 21:21:
[...]


Niet alleen na een UAC... Bij mij soms ook in andere gevallen.

Voornamelijk ook Android Studio bedenk ik me nu. PHPStorm nog nooit mee gehad.

Ryur schreef op woensdag 04 februari 2015 @ 20:22:
Kloppen deze problemen met de "F.West98"-problemen-schema?
Ik ben zelf de tel een beetje kwijt!

Nee dus

Dit wel:
WebDAV in WIndows werkt niet, omdat dat een verouderde Windows API vereist, die geen TLS > 1.0 ondersteunt. En laat ik die nu net disabled hebben voor de veiligheid....
http://forum.owncloud.org...c.php?f=23&t=11246#p61202

[Megamind]

http://www.artisanaljavascript.com/

[Alex)]

Wat is Entity Framework toch een ontzettend grote hoop stinkende paardenstront. Ik blijf spijt houden van die keuze.

[PrisonerOfPain]

.oisyn schreef op woensdag 04 februari 2015 @ 16:18:
NIXXES SOFTWARE TO DEVELOP RISE OF THE TOMB RAIDER ON XBOX 360

Heh- balen wij hebben die oude meuk mooi al in /dev/null geparkeerd

[ Voor 9% gewijzigd door PrisonerOfPain op 04-02-2015 22:16 ]

[Creepy]

PrisonerOfPain schreef op woensdag 04 februari 2015 @ 22:16:
[...]


Heh- balen wij hebben die oude meuk mooi al in /dev/null geparkeerd

[Douweegbertje]

Spier gescheurd... wat een timing ook zeg

[frG]

Alex) schreef op woensdag 04 februari 2015 @ 22:15:
Wat is Entity Framework toch een ontzettend grote hoop stinkende paardenstront. Ik blijf spijt houden van die keuze.

Waarom?

[kenneth]

Megamind schreef op woensdag 04 februari 2015 @ 21:50:
http://www.artisanaljavascript.com/

I'm A T-rex Mother Fucker!!!!!!!!!!!!!!!!

[Alex)]

frG schreef op woensdag 04 februari 2015 @ 23:26:
[...]


Waarom?

De bizarre SQL-statements die het ding genereert wanneer je iets doet dat gecompliceerder is dan "SELECT TOP(10) FROM [blogposts] WHERE category = 7;" zijn om te huilen. Als ik zelf m'n SQL had geschreven was ik wat meer tijd kwijt geweest aan het bedenken van wat ik precies nodig had gehad, maar dan had ik wel een stuk zinvollere queries gehad.

Maargoed, water under the bridge. EF was niet mijn keuze en gezien de ervaringen die ik er inmiddels mee heb ga ik het ook nooit meer gebruiken.

[ Voor 13% gewijzigd door Alex) op 04-02-2015 23:45 ]

[Avalaxy]

Tja, je kunt met EF ook gewoon prima je eigen queries schrijven natuurlijk, dat is geen echt argument tegen EF. Verder gewoon zorgen dat je de logger van je context alles naar een debug window laat schrijven en controleren wat voor queries hij er van bakt. So far best wel tevreden met EF6.1.2. Wel opletten dat je lazy-loading, changetracking en dat soort zooi uitzet, dan is er heel goed mee te werken.

Het probleem van EF is voornamelijk dat er een hoop magie in zit waar je als beginnende gebruiker flink jezelf mee in de knoop kunt raken. Denk aan het returnen van een queryable ipv een gematerialiseerd resultaat, lazy-loading die resulteert in talloze extra query's, issues waarbij je per ongeluk wijzigingen doet door met hele objectgrafen te werken en die als geheel te persisten, en natuurlijk brakke LINQ-queries schrijven die resulteren in slechte SQL. Daarom gewoon in de gaten houden, profilen en query plans bekijken

[ Voor 39% gewijzigd door Avalaxy op 04-02-2015 23:51 ]

[BtM909]

kenneth schreef op woensdag 04 februari 2015 @ 23:41:
[...]

I'm A T-rex Mother Fucker!!!!!!!!!!!!!!!!

Hun Bromise is wel grappig @ http://www.artisanaljavascript.com/scripts/brototype.js

Maar verder, wat was precies het nut of idee achter deze website? (behalve aantonen dat er anal in de URI staat en dat de eerste slide naar beneden knop al niet werkt met hun JS

[GateKeaper]

Alex) schreef op woensdag 04 februari 2015 @ 23:42:
[...]

De bizarre SQL-statements die het ding genereert wanneer je iets doet dat gecompliceerder is dan "SELECT TOP(10) FROM [blogposts] WHERE category = 7;" zijn om te huilen. Als ik zelf m'n SQL had geschreven was ik wat meer tijd kwijt geweest aan het bedenken van wat ik precies nodig had gehad, maar dan had ik wel een stuk zinvollere queries gehad.

Laatste keer dat ik EF gebruikt heb, werkte de queries behoorlijk goed. Veelal moet je inderdaad wel weten hoe hij werkt, zodat je de linq / lambda expressies beter kunt opbouwen.

Construct je expressies op een voor EF logische wijze op, en ik kreeg doorgaans toch beste nette queries. Zodra zelf dingen gaat lopen joinen (dus niet meer d.m.v een eenvoudige "Include") dan gaan ze inderdaad raar doen.

Denk dat je alleen wel een andere mind-set moet hebben. Zoveel mogelijk werken met je objecten zoals dit van oorsprong bedoeld was. Je moet niet meer allerlei vreemde vreemde queries willen gaan verzinnen om dynamische objecten te genereren. Een beetje het idee van je volledig overgeven aan EF, ipv toch zelf de touwtjes in handen blijven houden.

Dan maar wat meer info uit je database lezen, zodat je hele object gevuld wordt, ipv die paar velden skippen omdat het toch weer wat dataverkeer scheelt.

[BikkelZ]

Mijn ervaring is dat je in ORM frameworks over het algemeen niet veel verder dan wat CRUD werk moet willen gaan en dat ingewikkeldere dingen gewoon in een ingekapselde sproc moeten gebeuren. 80% van alles wat je met SQL moet doen is simpele CRUD, daar ben je dan van af.

[Douweegbertje]

Ik denk meer dat mensen bij een ORM er pas achter komen hoe ruk hun database structuur is en geven vervolgens een ORM de schuld... Op mn werk hoef ik echt niet iets met een ORM te gebruiken want dan werkt er -niets-.. Tja, dat heeft echt niets te maken met de moeilijke queries die er zijn (en die zijn er), maar meer het feit dat de relaties af en toe ver te zoeken zijn.

[Sardaukar]

Mijn ervaring met ORM's is ook dat mensen menen er 100% van hun data-afhandeling mee te moeten doen. Gewoon, omdat het er is.Terwijl er ook scenario's zijn zoals rapportages waarbij je graag wil terug gaan naar een eigen query.

Daarom stop ik een ORM meestal wel achter een eigen laagje zodat de ORM uiteindelijk een implementatie detail is geworden.

[Jan_V]

Alex) schreef op woensdag 04 februari 2015 @ 23:42:
[...]

Maargoed, water under the bridge. EF was niet mijn keuze en gezien de ervaringen die ik er inmiddels mee heb ga ik het ook nooit meer gebruiken.

Wat zou je dan wel gebruiken? Volgens mij zijn er weinig alternatieven, de meest bekende ORMs in ons landschap zijn EF, NHibernate en LLBLGen doet ook nog een beetje mee.

De hippe Micro-ORMs tel ik even niet mee, daar zijn er vast honderden van.
Ben ook geen fan van EF, heb er te vaak ruzie mee gehad. Maar in mijn geval komt het vast omdat ik het niet goed (genoeg) begrijp en/of oneigenlijk gebruik.

[ Voor 14% gewijzigd door Jan_V op 05-02-2015 09:09 ]

[Xiphalon]

Wat er ook vaak 'mis' gaat is dat men de volledige database als 1 model ziet. Gebruik liever het Bounded Context pattern, dan heb je per Aggregate een eigen (voor EF) DbContext en dan hou de de complexiteit buiten de deur. En het is een stuk beter testbaar.

Voorbeeld bij een verkoop:
Als ik een klant aan een bon koppel, hoef ik niet meer te weten dan zijn naam, adres en hoeveel korting hij krijgt. Voor dat stuk wordt er dus een aparte klant entity gedefinieerd met alleen die attributen.
Bij het onderdeel klantonderhoud heb ik dan wel een volledige klant entity, maar is bijvoorbeeld zijn verkoophistorie niet meer dan een objectje met bonId/datum/totaal/korting.

Noot: de verschillende klant entiteiten kunnen best naar dezelfde database tabel persisteren. Update query's werken dan meestal gewoon, alleen nieuwe klanten kan je in dit geval uiteraard alleen via klantonderhoud maken.

Volgens mij staat er ergens op Chanel 9 een video van Juli Lehrman die dit beter uitlegt dan ik

[Douweegbertje]

Dat kan op zich allemaal wel, maar ik ben deels nog steeds van mening dat je alles in een ORM kan oplossen mits je domweg een goede structuur hebt. Even heel simpel gezegd, als jij wel een relatie kan leggen in je 'moeilijke' query, waarom zou een ORM dat niet kunnen? De enige reden waarom hij dat dan niet zou kunnen is omdat je dan iets mist qua structuur om zo'n koppeling te maken.
Ik heb thuis iets draaien waar technisch gezien een zeer lastige koppeling in zit met een ORM. Op mijn werk heb ik een iets wat simpelere query die never nooit gaat werken in een ORM. Dit ligt aan de structuur van de DB en niets anders.

Daar gegeven kun je soms wel iets los koppelen voor het gemak omdat je dan soms meer werkt naar je ORM dan dat je het simpel houdt...

[AtleX]

Ik gebruik vaak een mengvorm van Code First EF en Dapper. Entity Framework werkt prima voor veel van de eenvoudiger queries die relatief kleine datasets opleveren, de migrations zijn handig en voor programmeurs is het op zich ideaal dat je eigenlijk geen DB meer hoeft te zien. De nadelen zijn er ook, je moet goed opletten met lazy loading, AsNoTracking() als je geen state tracking nodig hebt en ExecuteStoreQuery() voor getunede queries zijn je beste vrienden en een SQL profiler* ernaast openhouden is eigenlijk het beste.

Voor grotere datasets en/of ingewikkeldere queries val ik regelmatig terug naar Dapper. Met Entity Framework's ExecuteStoreQuery() heb ik regelmatig dat 'ie veel moeite, en dus tijd, heeft om de result set naar objecten om te zetten. Dapper is daar veel sneller en soms ook betrouwbaar in, in veel gevallen.

Daarnaast ben ik niet te beroerd om meerdere objecten per table te maken. Eentje die echt de hele tabel met relaties heeft en een paar toegespitste varianten die alleen noodzakelijke data, en vaak geen child objects via joins, bevatten. Als ik de het adres van een organisatie wil tonen, heb ik dan ook de lijst met medewerkers nodig? Om maar een voorbeeld te noemen.

*: Wat bij mij toch vaak al vaste prik is als ik tegen databases aan het praten ben. Als ik zelf queries schrijf begin ik vaak ook in SSMS met de Execution Plan pane open.

[ Voor 7% gewijzigd door AtleX op 05-02-2015 09:37 ]

[Xiphalon]

Dat zeker, met een ORM moet je eigenlijk niet meer zelf de databasestructuur helemaal in de hand hebben.

Maar dat hoort erbij. Beter eerst een object/domein model bedenken en daaruit de database in plaats van andersom. (Wat men helaas nog steeds leert op school...)

[Gomez12]

Xiphalon schreef op donderdag 05 februari 2015 @ 09:37:

Maar dat hoort erbij. Beter eerst een object/domein model bedenken en daaruit de database in plaats van andersom. (Wat men helaas nog steeds leert op school...)

Beter moet men gewoon eens begrijpen dat een rdbms geen objecten-database is. Het zijn gewoon 2 verschillende dingen en als je het maximale uit beide wil halen dan kan je niet of traject a of traject b volgen je zal traject a en traject b moeten volgen en dat ergens moeten koppelen.

[dcm360]

Jeej, al 20 minuten in de wacht bij Strato...

[TheNephilim]

.DS_Store bestanden in een git repository, dat hoort niet

[GateKeaper]

TheNephilim schreef op donderdag 05 februari 2015 @ 11:31:
.DS_Store bestanden in een git repository, dat hoort niet

[TheNephilim]

GateKeaper schreef op donderdag 05 februari 2015 @ 11:33:
[...]

Ik dacht, laat ik nou niet beginnen met de flamerino's, doe jij het

[Mercatres]

Tja, je hebt nu eenmaal verschillende aanpakken. Ik ben ook een voorstander van Code First en dat werkt ook nog eens lekker in combinatie met EF. Zeker omdat je je geen zorgen meer moet maken om je datastructuur (al is het geen slecht idee om af en toe toch eens een kijkje te nemen in SSMS) en dus gewoon verder kunt werken.
Migrations zijn ook een heel groot pluspunt voor development teams.

[D-Raven]

Mercatres schreef op donderdag 05 februari 2015 @ 12:07:
Tja, je hebt nu eenmaal verschillende aanpakken. Ik ben ook een voorstander van Code First en dat werkt ook nog eens lekker in combinatie met EF. Zeker omdat je je geen zorgen meer moet maken om je datastructuur (al is het geen slecht idee om af en toe toch eens een kijkje te nemen in SSMS) en dus gewoon verder kunt werken.
Migrations zijn ook een heel groot pluspunt voor development teams.

Zeker, maar absoluut geen uniek selling point. Of _de_ reden om EF te gebruiken.

http://dbup.github.io/

En zo zijn er nog meer. Sure te tooling zit niet expliciet in VS. Maar dat vind ik persoonlijk niet zo erg.
Sterker nog, ik prefereer zoiets als dbup. Omdat dit uiteindelijk veel eenvoudiger te integreren is in je CI Build omgeving.

[GateKeaper]

Mercatres schreef op donderdag 05 februari 2015 @ 12:07:
Ik ben ook een voorstander van Code First en dat werkt ook nog eens lekker in combinatie met EF. Zeker omdat je je geen zorgen meer moet maken om je datastructuur...

Hoooow... dat is een gevaarlijke uitspraak. Het is zeker niet dat je je geen zorgen meer hoeft te maken om je datastructuur. Ik durf zelfs wel te zeggen dat je er juist net even iets beter over moet nadenken dan wanneer je geen ORM gebruikt. Door er niet meer over na te denken, krijg je opmerkingen als "Wat is EF toch een draak van een beest", of "wat genereert ORM x toch een bagger queries".

Je moet er echter anders over nadenken, en wanneer de setup goed is uitgedacht hoef je de code-queries tijdens het programmeren niet constant te vertalen naar sql-queries. Je kan dus in één taal blijven denken.

[Mercatres]

Mercatres schreef op donderdag 05 februari 2015 @ 12:07:...(al is het geen slecht idee om af en toe toch eens een kijkje te nemen in SSMS)...

Ik zei ook niet dat je er blind op moest vertrouwen, maar het neemt wel een deel van de ontwikkelingscomplexiteit weg.

[GateKeaper]

Mercatres schreef op donderdag 05 februari 2015 @ 12:19:
[...]

Ik zei ook niet dat je er blind op moest vertrouwen, maar het neemt wel een deel van de ontwikkelingscomplexiteit weg.

Dat zag ik, snap ik, en ben het er nog steeds niet mee eens.

[Mercatres]

GateKeaper schreef op donderdag 05 februari 2015 @ 12:36:
[...]


Dat zag ik, snap ik, en ben het er nog steeds niet mee eens.

Ok, ieder zijn voorkeur natuurlijk

[alienfruit]

Performance is niet echt een sterk punt van sommige ORMs

[Aloys]

Grr, wat haat ik verborgen "functionaliteit"! Deze Qt "bug" heeft mij 4 dagen gekost, omdat in een of andere library die ik gebruikte fscanf wordt gebruikt met floats (die in het Nederlands natuurlijk een , hebben ipv een .).

https://bugreports.qt.io/browse/QTBUG-15247

[ Voor 9% gewijzigd door Aloys op 05-02-2015 13:25 ]

[ValHallASW]

alienfruit schreef op donderdag 05 februari 2015 @ 13:15:
Performance is niet echt een sterk punt van sommige ORMs

Ja, net zoals performance is geen sterk punt is van een database als je niet door hebt dat je indices moet gebruiken. Je moet natuurlijk wel weten hóe je die ORM goed gebruikt, en als je die de hele tijd N+1 queries laat doen dan doe je het dus fout

[Hoogie2004]

Ik dacht dat ik dit nooit zou zeggen, maar wat is Xslt toch fijn soms

[alienfruit]

Nou ja, de ORM layer die ik gebruikt heb maakt nou niet de meest optimale queries bij het gebruik van simpele one-to-many relaties. Voor elke relatie een aparte database verbinding etc.

[Sebazzz]

Naar mijn ervaring is het aan laten van lazy loading één van de gevaarlijkste dingen bij een ORM, in ieder geval in een webapplicatie. En uiteraard direct met entiteiten werken, wat zeker bij Web Forms erg makkelijk gaat. Bij MVC wordt je nog een beetje gedwongen om een view-model te maken.

Alex) schreef op woensdag 04 februari 2015 @ 23:42:
[...]

De bizarre SQL-statements die het ding genereert wanneer je iets doet dat gecompliceerder is dan "SELECT TOP(10) FROM [blogposts] WHERE category = 7;" zijn om te huilen. Als ik zelf m'n SQL had geschreven was ik wat meer tijd kwijt geweest aan het bedenken van wat ik precies nodig had gehad, maar dan had ik wel een stuk zinvollere queries gehad.

Sorry, maar boeiend. Als de SQL maar snel uit te voeren is uiteindelijk. Al zijn het 150 regels SQL.

[ Voor 50% gewijzigd door Sebazzz op 05-02-2015 13:36 ]

[DeluxZ]

Sebazzz schreef op donderdag 05 februari 2015 @ 13:34:
Naar mijn ervaring is het aan laten van lazy loading één van de gevaarlijkste dingen bij een ORM, in ieder geval in een webapplicatie. En uiteraard direct met entiteiten werken, wat zeker bij Web Forms erg makkelijk gaat. Bij MVC wordt je nog een beetje gedwongen om een view-model te maken.


[...]

Sorry, maar boeiend. Als de SQL maar snel uit te voeren is uiteindelijk. Al zijn het 150 regels SQL.

In MVC wordt je gedwongen een view-model te maken? Nee hoor..

[.oisyn]

17" of 19"?

[Korben]

.oisyn schreef op donderdag 05 februari 2015 @ 13:49:
17" of 19"?

[afbeelding]

Schijnbaar gebeurt er ook iets met de achterlichten als je grotere velgen neemt, dus misschien is de default selectie veiliger

[TheNephilim]

.oisyn schreef op donderdag 05 februari 2015 @ 13:49:
17" of 19"?

[afbeelding]

Het zijn helemaal geen overdreven velgen, dus kun je er prima 19 inch onder zetten!

[Firesphere]

.oisyn schreef op donderdag 05 februari 2015 @ 13:49:
17" of 19"?

[afbeelding]

Minstens 24", anders hou je geen ruimte over.

[ Voor 5% gewijzigd door Firesphere op 05-02-2015 13:51 ]

[Sebazzz]

DeluxZ schreef op donderdag 05 februari 2015 @ 13:38:
[...]


In MVC wordt je gedwongen een view-model te maken? Nee hoor..

Een beetje wel, het is wel mogelijk om te werken zonder view-model, maar dat werkt zo kut (in het bijzonder dat je entiteiten moet herattachen) dat het lekkerder werkt om een view model te gebruiken

[DeluxZ]

Sebazzz schreef op donderdag 05 februari 2015 @ 13:51:
[...]

Een beetje wel, het is wel mogelijk om te werken zonder view-model, maar dat werkt zo kut (in het bijzonder dat je entiteiten moet herattachen) dat het lekkerder werkt om een view model te gebruiken

Uhm.. herattachen? Nooit hoeven te doen als ik met mijn DBOs in een formulier werk hoor..

[Mercatres]

Visual Studio a.k.a. de memory hog. Zucht.

[Not Pingu]

GateKeaper schreef op donderdag 05 februari 2015 @ 12:18:
[...]


Hoooow... dat is een gevaarlijke uitspraak. Het is zeker niet dat je je geen zorgen meer hoeft te maken om je datastructuur. Ik durf zelfs wel te zeggen dat je er juist net even iets beter over moet nadenken dan wanneer je geen ORM gebruikt. Door er niet meer over na te denken, krijg je opmerkingen als "Wat is EF toch een draak van een beest", of "wat genereert ORM x toch een bagger queries".

Je moet er echter anders over nadenken, en wanneer de setup goed is uitgedacht hoef je de code-queries tijdens het programmeren niet constant te vertalen naar sql-queries. Je kan dus in één taal blijven denken.

Dat is wel interessant, zou je daar wat meer over kunnen uitwijden? De uitspraken die je noemt zijn idd wat in me opkomt bij de meeste ORMs (en dat het ineens ondoordringbare black boxes worden op het moment dat er ergens een bug optreedt). Gaat het dan over indexes, foreign keys en hoe je X-op-Y relaties modelleert?

[alienfruit]

Ai, salaris- en bonusbedragen van 1234,7250 werden afgerond naar 123,7300. Kregen een hoop medewerkers toch te veel salaris Opgelost de 5.000 medewerkers zullen blij met mij zijn

[ Voor 18% gewijzigd door alienfruit op 05-02-2015 14:36 ]

[Jan_V]

alienfruit schreef op donderdag 05 februari 2015 @ 14:35:
Ai, salaris- en bonusbedragen van 1234,7250 werden afgerond naar 123,7300. Kregen een hoop medewerkers toch te veel salaris Opgelost de 5.000 medewerkers zullen blij met mij zijn

Denk dat er een typo in staat, dus dat het 1234,7300 moet zijn.
Maar wiskundig klopt het toch?

Snap dat een werkgever het liever naar beneden afrond. Heb een dergelijke problematiek gehad met een Vecozo koppeling naar bepaalde verzekeraars toe. Die wilden ook dat we naar beneden gingen afronden.

[alienfruit]

Nee, je tikt in 1234,7250 en dat werd vervolgens 1234,7300... Ze willen nu dus precisie met drie decimalen

[Evilbee]

Hehe, ik heb mijn jaarlijkse beoordelingsgesprek op vrijdag de 13e

[_Moe_]

.oisyn schreef op donderdag 05 februari 2015 @ 13:49:
17" of 19"?

[afbeelding]

Ik zou naar het kosten plaatje kijken, al vind ik die 19" wel mooier

[DeluxZ]

Eindelijk tijd om wat te refactoren..

[ Voor 14% gewijzigd door DeluxZ op 06-02-2015 09:23 ]