De Devschuur Coffee Corner - Iteratie 3

[Verwijderd]

Het is wel belangrijk dat ik voldoende tutorials/documentatie kan vinden over desbetreffende frameworks hierboven maar ik zal eens die MVVM Light bekijken

THanks!

[R4gnax]

Waster schreef op maandag 11 februari 2013 @ 21:43:
Maar hoe lost Yeoman het probleem op om je serverside kant en je interactieve client side kant te integreren? Ik ben nu bezig mijn eigen visual studio zo in te richten dat ik een mooi proces heb.

Dat lost Yeoman niet op in het geval van Visual Studio en ASP.NET. Ten eerste is Yeoman er op gemaakt om de server kant in Node.js te draaien. Ten tweede is er geen officiële Windows versie van beschikbaar. (Via een 'hack' is de installatie werkend te krijgen, maar daarna is het 'fingers crossed' dat ales in het pakket ook echt werkt.)

Struikrover schreef op maandag 11 februari 2013 @ 22:01:
Volgens mij zijn er vanuit een hoop frameworks ook mogelijkheden om javascript te 'builden' met een service die alle files combineert en minified voor je productieomgeving. Dat lijkt me een redelijk goeie manier, mits je voor je dev omgeving alles dan nog gewoon makkelijk kunt debuggen

Een goede (en imho de beste) methode is om via RequireJS van het AMD patroon gebruik te maken. Forceert je om netjes alles onder te verdelen en traceert automatisch dependencies.

Voor de productie omgeving kun je je script modules via Node.js door de R.js optimizer heen halen, waarbij je netjes via een JSON configuratie op kunt geven welke script modules er als 'root' voor geoptimaliseerde modules moeten dienen. Via extra opties zoals deep/shallow include/exclude op files kun je precies afstemmen wat in welk file terecht komt. (Bijv. om een 'common' build layer te hebben + pagina specifieke build layer, in het geval van multi-page web-apps)

Via loader plugins met speciale builder/optimizer acties kun je ook zaken zoals CSS, i18n resources, etc. inlinen in je geoptimiliseerde file. Als je avontuurlijk bent en bereid bent zelf een loader plugin in elkaar te schroeven, dan kun je bijv. ook de templates voor een client-side templating engine (zoals Mustache) precompilen en het resultaat daarvan inlinen als native JS functies 'ready-to-go'. Da's best een aanrader trouwens; gecombineerd met een 'dunne' set JSON die over de lijn gaat, ipv een 'dikke' string server-side gerenderde HTML, maakt het asynchrone updates echt rete-snel. Werkt nog beter wanneer je een template engine gebruikt die partial updates via live binding op een observable model ondersteunt.


De R.js optimizer is ook nog eens redelijk makkelijk in te stellen om te draaien vanaf een MSBuild target via portable Node.js. Integreren in het gewone VS build proces (incl. build servers en deployment) is goed te doen. Zelf ongeveer een halve dag snuffelen geweest om het voor elkaar te krijgen, maar het was uiteindelijk niet echt moeilijk te noemen.

[ Voor 6% gewijzigd door R4gnax op 12-02-2013 00:04 ]

[Grijze Vos]

EddoH schreef op maandag 11 februari 2013 @ 15:54:
Geez,
ik duik na een lange tijd weer eens in de wereld van web development maar verdrink in de frameworks; Bootstrap, HTML5 Boilerplate, jQuery, LESS, Normalize.css etc etc

En dan heb je nog 25 MVC / MVVM javascript frameworks,

Verwijderd schreef op maandag 11 februari 2013 @ 20:41:
Vraag mij af welke MVVM library het handigst is om mee te werken voor C# en WPF in Win 7? Ik lees daar en daar wat over Prism en Calibur maar ben nog niet uit....

Ik heb een WPF applicatie gebouwd met Caliburn.Micro, en dat werkt wel aardig.
MVVM Light heb ik ook 1x gebruikt, voornamelijk voor de commands, die werken wel netjes. Ik ben verder niet zo kapot van MVVM Light, omdat het m.i. een verkeerde indeling maakt. Je wordt gedwongen je code op te splitsen in een map views en een map viewmodels. Terwijl je juist op functionaliteit je indeling wilt maken, waarbij views en viewmodels die bij elkaar horen in dezelfde namespace zitten. (CM hanteert deze conventie ook overigens.)

Als je applicatie klein is is het niet zo'n issue, behalve dat je je kapot zoekt naar files, maar zodra je functionaliteiten wilt gaan splitten in verschillende dll's e.d. dan heb je een probleem met MVVM Light.

[Verwijderd]

Ik heb ook die Catel MVVM framework gevonden en de documentatie is best vrij duidelijk. Dit ga ik als eerst testen...:) Ben benieuwd want ik heb al zo'n idee in mijn hoofd maar ik wil al van eerste keer goed doen

[Alex)]

Moet je eens (proberen te) beginnen met het maken van een Java-based web application. Je ziet door de bomen het bos niet meer, zoveel frameworks en andere zaken zijn er.

[Down]

Verwijderd schreef op maandag 11 februari 2013 @ 23:12:
Het is wel belangrijk dat ik voldoende tutorials/documentatie kan vinden over desbetreffende frameworks hierboven maar ik zal eens die MVVM Light bekijken

THanks!

Ik heb het proces van MVVM en bijbehorende frameworks uitspitten vorig jaar ook gedaan. Ik heb zowel MVVM Light als Caliburn.Micro (dus niet Caliburn) gebruikt. Wat betreft 'light' vind ik Caliburn.Micro echt light. Het is een heerlijk framework als je het eenmaal snapt. Caliburn.Micro heeft als uitgangspunt 'convention over configuration'. Er zitten veel impliciete regels in m.b.t. databinding (die je overigens wel kunt overriden). Heb je bijvoorbeeld in je view een DataGrid met de naam "Orders" en op je viewmodel een public property genaamd Orders, dan probeert C.M deze automagisch te databinden.

Ik kan het van harte aanraden.

Terwijl je juist op functionaliteit je indeling wilt maken, waarbij views en viewmodels die bij elkaar horen in dezelfde namespace zitten

Dit kreeg ik prima voor elkaar in Caliburn.Micro, je kunt je views en viewmodels in namespaces groeperen.

[ Voor 12% gewijzigd door Down op 12-02-2013 09:48 ]

[Woy]

Down schreef op dinsdag 12 februari 2013 @ 09:39:
[...]


Ik heb het proces van MVVM en bijbehorende frameworks uitspitten vorig jaar ook gedaan. Ik heb zowel MVVM Light als Caliburn.Micro (dus niet Caliburn) gebruikt. Wat betreft 'light' vind ik Caliburn.Micro echt light. Het is een heerlijk framework als je het eenmaal snapt. Caliburn.Micro heeft als uitgangspunt 'convention over configuration'. Er zitten veel impliciete regels in m.b.t. databinding (die je overigens wel kunt overriden). Heb je bijvoorbeeld in je view een DataGrid met de naam "Orders" en op je viewmodel een public property genaamd Orders, dan probeert C.M deze automagisch te databinden.

Caliburn.Micro is inderdaad een super fijn framewok om mee te werken.

[PrisonerOfPain]

Al die C++0x meuk en dit kan nog steeds niet

C++:

auto v = data->getSomeVector();
u32 dataWidth = 2 << sizeof(decltype(v)::value_type);

[curvemod]

Struikrover schreef op maandag 11 februari 2013 @ 22:01:
Volgens mij zijn er vanuit een hoop frameworks ook mogelijkheden om javascript te 'builden' met een service die alle files combineert en minified voor je productieomgeving. Dat lijkt me een redelijk goeie manier, mits je voor je dev omgeving alles dan nog gewoon makkelijk kunt debuggen

Meeste framework doen het zoals hierboven genoemd als AMD module, maar je zou bijvoorbeeld met 'Architect' (https://github.com/c9/architect) ook 'statisch' kunnen compileren. Voordeel daarvan is dat je voor de deploy weet of het stuk gaat op depedencies, bij AMD breekt dit nog steeds je applictie

[mbarie]

Kan iemand onze designer vertellen dat pixelperfecte websites niet meer van deze tijd zijn? . Koppig dier.

Ik heb zo geen zin dit te fixen.

Tot slot doet Smarty magisch. Niet op de leuke manier. Wat een vervelende dag gaat dit worden.

edit:
Tot slot zijn designs er is bij gepakt. Ik heb tot 3 keer toe iets ontvangen met andere uitlijning, afbeeldingsgroottes, etc. Meest vervelende is dat ik toch geen gelijk ga krijgen en ondertussen wel aangekeken wordt op het feit dat we uitlopen

/rant.

[ Voor 73% gewijzigd door mbarie op 12-02-2013 11:27 ]

[Sh4wn]

Voor de verandering heeft Ruby on Rails weer eens een security bug: http://www.zweitag.de/en/...ignment-and-sql-injection

(Al zit het dit keer meer in de JSON parser die RoR gebruikt).

[ Voor 17% gewijzigd door Sh4wn op 12-02-2013 11:37 ]

[Gamebuster]

Als ik me verveel ga ik de feedback/klachten lezen van de site(s). Dat weet altijd mijn humeur te verbeteren.

[GateKeaper]

Sh4wn schreef op dinsdag 12 februari 2013 @ 11:36:
Voor de verandering heeft Ruby on Rails weer eens een security bug: http://www.zweitag.de/en/...ignment-and-sql-injection

(Al zit het dit keer meer in de JSON parser die RoR gebruikt).

Ik ben verder onbekend met Ruby, dus weet ook niet in hoeverre de json parser deel uit maakt van de core van Ruby, maar het klinkt wat twijfelachtig om een JSON parser de schuld te geven van mass assignment. Dat hij de weg ernaar toe vereenvoudigd begrijp ik, maar is hij (de parser) ook de eindverantwoordelijke? Is dat werkelijk de laatste laag voor de database?

[Gamebuster]

Rails bevat ook zoveel "magic", het is dan niet zo vreemd dat het vol beveiligings-issues zit. Toch wel leuk dat het nu allemaal boven komt drijven. Ach ja, dit soort dingen verbeteren de beveiliging alleen maar.

[OkkE]

mbarie schreef op dinsdag 12 februari 2013 @ 11:17:
Kan iemand onze designer vertellen dat pixelperfecte websites niet meer van deze tijd zijn? . Koppig dier.

Is dat niet iets dat je met de projectmanager (of baas) kan bespreken?

Pixel perfect is eerder een management beslissing (hoeveel tijd steken we er in) dat je per project — of bedrijf breed — afspreekt dan iets wat de designer bepaalt, vind ik.

[Korben]

Gamebuster schreef op dinsdag 12 februari 2013 @ 11:42:
Rails bevat ook zoveel "magic", het is dan niet zo vreemd dat het vol beveiligings-issues zit. Toch wel leuk dat het nu allemaal boven komt drijven.

QFT.

[PrisonerOfPain]

Gamebuster schreef op dinsdag 12 februari 2013 @ 11:42:
Rails bevat ook zoveel "magic", het is dan niet zo vreemd dat het vol beveiligings-issues zit. Toch wel leuk dat het nu allemaal boven komt drijven. Ach ja, dit soort dingen verbeteren de beveiliging alleen maar.

Volgens mij zijn het allemaal boze Java developers

[kenneth]

Goede code schrijven is best moeilijk. Gelukkig ben ik aardig op weg dat te leren.

Slechte code ontleden en precies uitvogelen hoe je de kwaliteit verbetert is een vaardigheid die ik echter nog lang niet beheers. Af en toe gewoon kortsluiting in de hersenen door het proberen te begrijpen van code. ASP.NET Web Forms waar bijna alles (UI logica, domeinlogica, data access) in de code behind zit

[Rutix]

kenneth schreef op dinsdag 12 februari 2013 @ 11:54:
Goede code schrijven is best moeilijk. Gelukkig ben ik aardig op weg dat te leren.

Slechte code ontleden en precies uitvogelen hoe je de kwaliteit verbetert is een vaardigheid die ik echter nog lang niet beheers. Af en toe gewoon kortsluiting in de hersenen door het proberen te begrijpen van code. ASP.NET Web Forms waar bijna alles (UI logica, domeinlogica, data access) in de code behind zit

Bedoel je met de code behind de code achter de .aspx ? Zo ja dan is het zeker

[mbarie]

OkkE schreef op dinsdag 12 februari 2013 @ 11:44:
[...]

Is dat niet iets dat je met de projectmanager (of baas) kan bespreken?

Pixel perfect is eerder een management beslissing (hoeveel tijd steken we er in) dat je per project — of bedrijf breed — afspreekt dan iets wat de designer bepaalt, vind ik.

Ik ben absoluut geen voorstander van pixel perfect, maar in dit geval zal het moeten gebeuren... Iedereen die erbij betrokken is is reeds op de hoogte.

Inmiddels achter dat het die (achterlijke) apple emailclient is. Automatisch images schalen als je ze verstuurd . Verder heeft de designer een vrij unieke positie binnen onze organisatie (ondanks dat het een extern bedrijf is) en is er een hoop geschiedenis aan vooraf gegaan. Hij is erg goed in zijn werk hoor, dat mag ook gezegd worden.

[.Gertjan.]

kenneth schreef op dinsdag 12 februari 2013 @ 11:54:
ASP.NET Web Forms waar bijna alles (UI logica, domeinlogica, data access) in de code behind zit

Dat zijn de mooiste! Vooral het feit dat de developers denken met ASPX & ASPX.cs genoeg scheiding in de lagen te hebben

Vandaag met een andere ontwikkelaar besproken dat we voor een bestaand project gaan kijken of we de architectuur en code naar een next-level kunnen tillen. Hoewel de app al een hele tijd in ontwikkeling is en redelijk groot en complex is zien we wel het nut van een verbeterslag in de toekomst Als je dan tevens het principe "laat je kampeerplek schoner achter dan je hem aantrof" hanteert wordt het alleen maar beter

Ook wel eens fijn om te werken met mensen die verbeteringen niet als kritiek zien en ook zelf inzien dat je naarmate je verder raakt je ook steeds nieuwere inzichten krijgt en het geen kwaad kan om eens kritisch naar je code te kijken. Veel mensen zien het als kritiek en gaan meteen met de hakken in het zand. Zelf kijk ik ook regelmatig kritisch naar mijn oude code. Hoewel ik toch al een kleine 8 jaar meedraai heb ik het idee nog steeds nieuwe dingen te leren en steeds weer een slagje efficienter te worden.

Soms best leuk dat programmeren

Ben een tijdje geleden bezig gegaan met code metrics en heb besloten mijn code graag onder de Cyclomatic Complexity van 15 te willen houden. Dit zorgt ervoor dat je snel subfuncties gaat maken en heel strikt houdt aan het principe dat 1 functie maar 1 ding mag doen en dat bij if's nogal snel het daarwerkelijke werk door subroutines laat doen waar je vroeger al het werk snel in de functie zelf zou ketsen.

Ik hoef de tool niet eens vaak te draaien maar gewoon die wetenschap zorgt al voor die mindset, als ik hem dan draai blijk ik vaak zelfs onder de 10 te zitten

[GateKeaper]

.Gertjan. schreef op dinsdag 12 februari 2013 @ 12:28:
[...]
Zelf kijk ik ook regelmatig kritisch naar mijn oude code. Hoewel ik toch al een kleine 8 jaar meedraai heb ik het idee nog steeds nieuwe dingen te leren en steeds weer een slagje efficienter te worden.

Ik denk dat je in dit vakgebied ook pas een probleem hebt wanneer je van mening bent dat je niets meer bij kunt leren.

Dit gebied ontwikkeld zo snel, dat je code van een tijd geleden altijd beter, sneller, compacter of efficiënter kan. Je hebt eerder een probleem wanneer je niet ziet dat je code van een jaar oud (inmiddels) ook anders had gekund, dan wanneer je dat wel ziet.

[armageddon_2k1]

GateKeaper schreef op dinsdag 12 februari 2013 @ 12:39:
[...]Dit gebied ontwikkeld zo snel, dat je code van een tijd geleden altijd beter, sneller, compacter of efficiënter kan. Je hebt eerder een probleem wanneer je niet ziet dat je code van een jaar oud (inmiddels) ook anders had gekund, dan wanneer je dat wel ziet.

Dit heeft wel als nadeel dat als mensen later bij een project betrokken worden (en helemaal als het project al wat langer loopt) heel erg makkelijk kunnen gaan bitchen op alles omdat het tegenwoordig beter/sneller/efficienter kan. Gelukkig is niet iedereen zo

[TheNephilim]

Wat zal ik eens op de kaart voor m'n vriendin zetten; ze krijgt Battlefield 3 van mij

[cenix]

TheNephilim schreef op dinsdag 12 februari 2013 @ 13:20:
Wat zal ik eens op de kaart voor m'n vriendin zetten; ze krijgt Battlefield 3 van mij

Om samen eens een stevig potje te knallen

[Firesphere]

TheNephilim schreef op dinsdag 12 februari 2013 @ 13:20:
Wat zal ik eens op de kaart voor m'n vriendin zetten; ze krijgt Battlefield 3 van mij

"Now I can't miss you anymore"?

[Erwin537]

TheNephilim schreef op dinsdag 12 februari 2013 @ 13:20:
Wat zal ik eens op de kaart voor m'n vriendin zetten; ze krijgt Battlefield 3 van mij

Splitscreen maybe? (zat die optie in BF?)

Zou over enkele generaties een leger van programmeur opa's met pensioen ontstaan die freeware software gaan maken?

[PrisonerOfPain]

TheNephilim schreef op dinsdag 12 februari 2013 @ 13:20:
Wat zal ik eens op de kaart voor m'n vriendin zetten; ze krijgt Battlefield 3 van mij

Oh fuck, ik ga ook maar eens een kaart kopen

[TheNephilim]

cenix schreef op dinsdag 12 februari 2013 @ 13:21:
[...]


Om samen eens een stevig potje te knallen

Firesphere schreef op dinsdag 12 februari 2013 @ 13:22:
[...]

"Now I can't miss you anymore"?

Haha, ja zoiets moet het worden XD Erg lastig

Erwin537 schreef op dinsdag 12 februari 2013 @ 13:23:
[...]

Splitscreen maybe? (zat die optie in BF?)

Zou over enkele generaties een leger van programmeur opa's met pensioen ontstaan die freeware software gaan maken?

Nee, voor op de PC natuurlijk!

Nou ik ga nog eens denken: "I will catch a grenade for you" is te makkelijk XD "Will you join my squad" te saai denk ik...

Ik ga even een kaartje laten maken met dit op de voorkant iig: http://mackaged.deviantar...ver-Ponyfield-3-291066223

---

Misschien deze: http://battlelog-cdn.batt...ats/dogtags/lb/dta013.png

[ Voor 5% gewijzigd door TheNephilim op 12-02-2013 13:34 ]

[.Gertjan.]

armageddon_2k1 schreef op dinsdag 12 februari 2013 @ 13:12:
[...]


Dit heeft wel als nadeel dat als mensen later bij een project betrokken worden (en helemaal als het project al wat langer loopt) heel erg makkelijk kunnen gaan bitchen op alles omdat het tegenwoordig beter/sneller/efficienter kan. Gelukkig is niet iedereen zo

Meh, op zich kan dat geen kwaad. Ik vind dat je best de "oude garde" kunt wijzen op tekortkomingen en kunt kijken of je in de toekomst een nieuwere weg in kunt slaan (en mogelijk gaandeweg de oude logica ook verbeteren). Dat is het voordeel van vers bloed in een project
Zelf heb ik ooit voorgesteld om een hele datalaag om te bouwen, er was voor iedere soort opzoeking een StoredProcedure: GetXById, GetXByName, GetXByNameAndSuperTypeID, etc, destijds voorgesteld om de SP's wat intelligenter te maken. Dat was niet iets wat in 1 dag kon en dat is geleidelijk gegaan, na een half jaar was de hele app omgeschreven naar een onderhoudsvriendelijkere versie

Echter moet men niet blijven hangen in die onvrede, als het niet kan dan houdt het gewoon op. Mensen die op een WebForms project binnen komen en gaan lopen bitchen dat het in MVC moet kunnen beter een andere rol zoeken omdat zoiets gewoon een brug te ver is, maar verder sta ik zelf wel open voor dat soort dingen, mits met waardigheid en achtergrond gebracht. Maar mocht het niet doorgaan moet men niet blijven mekkeren.

Als het goed is krijg ik deze week van onze stagiair te horen waarom hij vindt dat onze data laag naar EntityFramework zou kunnen. Momenteel vullen we zelf onze Entiteiten (wel met een mapper als Dapper) omdat we graag controle wilde houden over de entiteiten en de DB verbindingen, echter schijnt met CodeFirst EF het relatief makkelijk te zijn om te werken met je eigen objecten (en kun je redelijk je DB verbinding in de hand houden), nou kom maar met een voorstel Als het goed werkt scheel mij dat weer code

[Rutix]

.Gertjan. schreef op dinsdag 12 februari 2013 @ 13:41:
[...]

Als het goed is krijg ik deze week van onze stagiair te horen waarom hij vindt dat onze data laag naar EntityFramework zou kunnen. Momenteel vullen we zelf onze Entiteiten (wel met een mapper als Dapper) omdat we graag controle wilde houden over de entiteiten en de DB verbindingen, echter schijnt met CodeFirst EF het relatief makkelijk te zijn om te werken met je eigen objecten (en kun je redelijk je DB verbinding in de hand houden), nou kom maar met een voorstel Als het goed werkt scheel mij dat weer code

Ik wil niet helemaal in detail gaan maar ik vind EF helemaal niet zo goed . Vooral kwa performance enzo kun je heel snel de mist in gaan. Dus hij zou bij mij met hele goede redenen moeten komen

[ Voor 3% gewijzigd door Rutix op 12-02-2013 14:03 ]

[PrisonerOfPain]

Semlor

[Rutix]

yummy doe er mij maar 1

[.Gertjan.]

Rutix schreef op dinsdag 12 februari 2013 @ 14:03:
[...]

Ik wil niet helemaal in detail gaan maar ik vind EF helemaal niet zo goed . Vooral kwa performance enzo kun je heel snel de mist in gaan. Dus hij zou bij mij met hele goede redenen moeten komen

Het is het paradepaardje van Microsoft dus zo heel slecht is het niet vermoed ik, maar zoals bij iedere "DB access helper tool" lever je in op performance vergeleken met het die-hard tegen datareaders aanwerken.

Momenteel ligt een redelijk deel van de development tijd in het bouwen van de dataaccesslaag, dus het maken van de parameterized-queries/storedprocedures en het communiceren met de DBReader/DBConnection. Dit is goed op het vlak van controleerbaarheid, maar een drama qua bouwen er gaat gewoon veel tijd in zitten.

Ik lees redelijk positieve zaken over EF (waarbij natuurlijk wel gezegd wordt dat je het niet te gek moet maken) en het lijkt mij momenteel een redelijk goede oplossing voor DB communicatie. Zeker bij CodeFirst waarbij we wel onze objecten zelf bepalen en ook ons datamodel in de hand kunnen houden (je kunt schijnbaar codefirst op een bestaand model).

Qua argumenten moet hij mij nog overtuigen, maar wij verzetten geen grote hoeveelheden data (we draaien op SQL Express dus boven de 12GB per client komen we niet , momenteel is de gemiddelde DB 30 MB groot en groeien ze alleen wanneer er files worden opgeslagen) dus qua performance ben ik niet zo bang*. Ik wil wel graag zien wat er gebeurt, dus ik ga de boel zeker eens monitoren met een SQL Profiler (ben nooit zo'n fan van "magic", zo wordt een deel van EF-CF soms beschreven), maar wat ik tot nu toe heb gezien van de datamappers van Microsoft (bv Linq2SQL) is dat het best mee valt wat ze doen.

* Sowieso ben ik van mening dat je in sommige gevallen beter in een keer een sloot data kunt ophalen uit de DB dan alles met losse calls. Hoe minder uitstapjes naar de DB hoe duidelijker de code wat mij betreft. Voor de apps die ik bouw is het niet nodig om 10k verbindingen per seconde te kunnen maken

[Rutix]

.Gertjan. schreef op dinsdag 12 februari 2013 @ 14:38:
[...]

Qua argumenten moet hij mij nog overtuigen, maar wij verzetten geen grote hoeveelheden data (we draaien op SQL Express dus boven de 12GB per client komen we niet , momenteel is de gemiddelde DB 30 MB groot en groeien ze alleen wanneer er files worden opgeslagen) dus qua performance ben ik niet zo bang*. Ik wil wel graag zien wat er gebeurt, dus ik ga de boel zeker eens monitoren met een SQL Profiler (ben nooit zo'n fan van "magic", zo wordt een deel van EF-CF soms beschreven), maar wat ik tot nu toe heb gezien van de datamappers van Microsoft (bv Linq2SQL) is dat het best mee valt wat ze doen.

* Sowieso ben ik van mening dat je in sommige gevallen beter in een keer een sloot data kunt ophalen uit de DB dan alles met losse calls. Hoe minder uitstapjes naar de DB hoe duidelijker de code wat mij betreft. Voor de apps die ik bouw is het niet nodig om 10k verbindingen per seconde te kunnen maken

Mijn ervaringen met EF waren dus wel dat hij voor het minst of geringste meteen naar DB ging . Misschien kan je dit wel veranderen of uitzetten hoor maar ik vond dat EF veel DB connecties maakte terwijl ik liever batches van info ophaal of opsla maar ik heb het nooit voor een echt project gebruikt. Ik heb nu een redelijk goede herbruikbare datalaag ready voor ons framework en dus hoef ik alleen SP's te schrijven en datalaag uit te breiden dan .

[ Voor 8% gewijzigd door Rutix op 12-02-2013 14:43 ]

[Down]

Rutix schreef op dinsdag 12 februari 2013 @ 14:03:
[...]

Ik wil niet helemaal in detail gaan maar ik vind EF helemaal niet zo goed . Vooral kwa performance enzo kun je heel snel de mist in gaan. Dus hij zou bij mij met hele goede redenen moeten komen

Dat lijkt me redelijk kort door de bocht. Je kunt in EF zelf zo'n beetje alles tweaken m.b.t. lazy loading en het al dan niet includen van gerelateerde data (navigation properties). Klinkt meer als een gevalletje "ik doe maar wat en nu is het traag"

[Rutix]

Down schreef op dinsdag 12 februari 2013 @ 14:44:
[...]


Dat lijkt me redelijk kort door de bocht. Je kunt in EF zelf zo'n beetje alles tweaken m.b.t. lazy loading en het al dan niet includen van gerelateerde data (navigation properties). Klinkt meer als een gevalletje "ik doe maar wat en nu is het traag"

Ik heb het uitgeprobeerd een poosje terug. Mijn gevoel was toen echt dat het een bloated over-engineered framework was , die ook nog eens slechte dynamic SQL genereerde. Het kan best zijn dat ze dit beter hebben gemaakt hoord maar mijn ervaring toen was En ik heb er toen serieus naar gekeken dus om het maar een gevalletje "ik doe maar wat en nu is het traag" te noemen wil ik niet zeggen .

[.Gertjan.]

Rutix schreef op dinsdag 12 februari 2013 @ 14:41:
[...]

Mijn ervaringen met EF waren dus wel dat hij voor het minst of geringste meteen naar DB ging . Misschien kan je dit wel veranderen of uitzetten hoor maar ik vond dat EF veel DB connecties maakte toen ik het heb uitgeprobeerd .

Ben dan wel erg benieuwd hoe dat zich gaat houden. Ik kan mij voorstellen dat hij op relaties inderdaad de DB in duikt waarbij ik mij nu ineens begin af te vragen of ik dat wel wil vanwege de scheiding van de lagen.

Stel ik heb een Student met een Klas object erin en ik wil iets over de klas weten zit ik niet te wachten dat het Student object zelf maar de DB in gaat (lazyloading), dat betekent namelijk dat de DB logica in de entities komt te zitten... Daar had ik nog niet bij stil gestaan....

Op het moment dat het object de DAL verlaat wil ik eigenlijk alle verbindingen doorknippen... Mijn enities zijn datadragers. Maar scherp opgemerkt van je, die ga ik tegen de stagiair aanmikken. Zelf al zitten kijken op het blog van Scott Hanselman en moet zeggen dat het er wel leuk uit ziet icm CodeFirst (zag in mijn stapel te lezen prints al 2x een afdruk van dat artikel, dat stuk gaat dus steeds op de "interessant stapel" , zo nu en dan wordt mijn gedachten geprikkeld door EF, maar pas 1x in een simpel project gebruikt en nooit echt de diepte in gegaan ).

[Down]

Rutix schreef op dinsdag 12 februari 2013 @ 14:50:
[...]

Ik heb het uitgeprobeerd een poosje terug. Mijn gevoel was toen echt dat het een bloated over-engineered framework was , die ook nog eens slechte dynamic SQL genereerde. Het kan best zijn dat ze dit beter hebben gemaakt hoord maar mijn ervaring toen was En ik heb er toen serieus naar gekeken dus om het maar een gevalletje "ik doe maar wat en nu is het traag" te noemen wil ik niet zeggen .

Dat ben ik benieuwd waar dat gevoel op is gebaseerd. Ik was positief verrast door de kwaliteit van de gegenereerde SQL (welke je runtime gewoon kunt uitlezen overigens), mede dankzij de hoge mate van aanpasbaarheid m.b.t allerlei opties op het datamodel. Combineer dat met code first, Linq, en een fluent API en je hebt een prima ORMDAL generator

.Gertjan. schreef op dinsdag 12 februari 2013 @ 14:51:
[...]
Op het moment dat het object de DAL verlaat wil ik eigenlijk alle verbindingen doorknippen... Mijn enities zijn datadragers.

Kijk eens naar EF powertools (icm de fluent API).

[Rutix]

Lost EF powertools ook al die caching en concurrency problemen op? Want dat was nog 1 van mijn punten die ik had met EF . Ook vond ik de performance echt beblabberd toen ik het los liet op een DB van 50GB en groot aantal tabellen. Maar de meeste applicaties hebben natuurlijk geen db van 50GB

[HMS]

NHibernate > EF. Nuff said

De maturity van NH heeft EF bij lange na nog niet, en ik vind NH ook net wat makkelijker werken. Plus je hebt als het moet een erg krachtige query language tot je beschikking, iets wat EF niet heeft (EF ondersteund alleen LINQ, NH heeft QueryOver, Criteria, HQL, LINQ, etc.).

[kenneth]

Rutix, welke versie van EF heb jij voor het laatst gebruikt? Ik hoor namelijk dat EF5 >>>> EF4. De ontwikkelingen gaan best snel nu bij EF. Hoewel EF inderdaad niet zo volwassen is als NHibernate of LLBLGen.

[frG]

.Gertjan. schreef op dinsdag 12 februari 2013 @ 14:51:
[...]

Ben dan wel erg benieuwd hoe dat zich gaat houden. Ik kan mij voorstellen dat hij op relaties inderdaad de DB in duikt waarbij ik mij nu ineens begin af te vragen of ik dat wel wil vanwege de scheiding van de lagen.

Stel ik heb een Student met een Klas object erin en ik wil iets over de klas weten zit ik niet te wachten dat het Student object zelf maar de DB in gaat (lazyloading), dat betekent namelijk dat de DB logica in de entities komt te zitten... Daar had ik nog niet bij stil gestaan....

Op het moment dat het object de DAL verlaat wil ik eigenlijk alle verbindingen doorknippen... Mijn enities zijn datadragers. Maar scherp opgemerkt van je, die ga ik tegen de stagiair aanmikken. Zelf al zitten kijken op het blog van Scott Hanselman en moet zeggen dat het er wel leuk uit ziet icm CodeFirst (zag in mijn stapel te lezen prints al 2x een afdruk van dat artikel, dat stuk gaat dus steeds op de "interessant stapel" , zo nu en dan wordt mijn gedachten geprikkeld door EF, maar pas 1x in een simpel project gebruikt en nooit echt de diepte in gegaan ).

Dan zou je lazy loading uit kunnen zetten, en zelf de .Includes("TabelNaam") kunnen opgeven toch?
MSDN: Entity Framework Loading Related Entities

[ Voor 4% gewijzigd door frG op 12-02-2013 15:58 ]

[Solopher]

Vandaag weer mijn eerste werkdag na een week in Oostenrijk te zijn geweest. Pff 't lijkt wel een maandag vandaag

[TheNephilim]

Solopher schreef op dinsdag 12 februari 2013 @ 16:01:
Vandaag weer mijn eerste werkdag na een week in Oostenrijk te zijn geweest. Pff 't lijkt wel een maandag vandaag

Haha, ja dan is een bureau toch wat anders dan de witte pistes! ^^

Zoooo, lekker aan het opruimen en ook de todo list aan het aanvullen voor een webshop die bijna klaar is. Echt, zo heb je nooit iets met een webshop gedaan, en zo heb je er inmiddels twee gemaakt!

Je komt wel een boel dingen tegen, zelfs als je al bijna 'klaar' bent. Maar wel een mooie leer voor de volgende keer en daarmee weer een ervaring rijker!

---

Even € 5,- aan wiki gedoneerd De melding bovenaan de wikipedia pagina was zo indringend

[kenneth]

kenneth schreef op dinsdag 12 februari 2013 @ 15:41:
Hoewel EF inderdaad niet zo volwassen is als [...] LLBLGen.

En een half uur later:

'Union' isn't supported, as LLBLGen Pro doesn't support union queries

Grrrrrr

/me gaat ombouwen

edit:

Ah, een kwartier later:

Value cannot be null. Parameter name: constructor

Query werkt wel in LINQPad. Ik heb niets gezegd over volwassenheid

[ Voor 21% gewijzigd door kenneth op 12-02-2013 16:28 ]

[Grijze Vos]

Kenneth, bouw een view in je db en voeg die toe aan LLBLGen. Makkelijkste oplossing denk ik.

Ik vind zelf EF eigenlijk sinds 4.0 wel lekker werken. NHibernate heb ik altijd convoluted gevonden en de learning curve is te stijl aan het begin, waardoor het gewoon onprettig is om je juniors mee op te zadelen. Mgoed, da's mijn mening.

LLBLGen is imho de beste qua query constructie e.d., maar de lack of vs integration (up till now) en Efbe's negatieve houding tegenover code first gaan mij niet meer overtuigen terug te gaan. Wellicht voor hobby projecten, ware het niet dat het dan mij persoonlijk geld zou kosten.

[Ellos]

HMS schreef op dinsdag 12 februari 2013 @ 15:16:
NHibernate > EF. Nuff said

De maturity van NH heeft EF bij lange na nog niet, en ik vind NH ook net wat makkelijker werken. Plus je hebt als het moet een erg krachtige query language tot je beschikking, iets wat EF niet heeft (EF ondersteund alleen LINQ en Entity SQL, NH heeft QueryOver, Criteria, HQL, LINQ, etc.).

FTYF

[OkkE]

Hmm... alle Google diensten onbereikbaar. Blijkbaar hebben er meer mensen last van. Ah well, mooie tijd om naar huis te gaan.

[.oisyn]

't Ligt aan de route. Als ik op mijn werk google.com request gaat het fout. Reroute ik het verkeer via mijn webserver middels een SOCKS proxy dan gaat het wel goed. En dan ook gewoon hetzelfde ip

.edit: search engines lijken weer beschikbaar. Mail.google.com is nog steeds dood though.

[ Voor 18% gewijzigd door .oisyn op 12-02-2013 17:32 ]

[whoami]

* whoami aait NH


Je moet natuurlijk niet alles uit je DB willen trekken als dat niet nodig is. Maar daar heb je natuurlijk projections voor in de ICriteria API.

[kenneth]

Grijze Vos schreef op dinsdag 12 februari 2013 @ 16:58:
Kenneth, bouw een view in je db en voeg die toe aan LLBLGen. Makkelijkste oplossing denk ik.

Heb het al gevonden. Een query naar een eigen type (select new FooBarStruct { a = o.baz }) geeft allerlei rare excepties. Dus een query gemaakt naar een anonymous type en vervolgens een simpele mapper from q in query.ToList() select new FooBarStruct { a = q.a }. Dat werkt wel ... ik vind het maar vaag.

Ik vind zelf EF eigenlijk sinds 4.0 wel lekker werken. NHibernate heb ik altijd convoluted gevonden en de learning curve is te stijl aan het begin, waardoor het gewoon onprettig is om je juniors mee op te zadelen. Mgoed, da's mijn mening.

Ik durf door al die verhalen niet eens met NHibernate te beginnen. Thuis begin ik langzamerhand EF5 te leren kennen en vind het best prettig. Zou zomaar kunnen dat we hier op het werk ook overstappen. Verder erg blij met LLBLGen maar EF lijkt beter aan te sluiten op onze werkwijze. Lijkt. Nog even aankijken

[Down]

kenneth schreef op dinsdag 12 februari 2013 @ 17:35:
[...]
Heb het al gevonden. Een query naar een eigen type (select new FooBarStruct { a = o.baz }) geeft allerlei rare excepties. Dus een query gemaakt naar een anonymous type en vervolgens een simpele mapper from q in query.ToList() select new FooBarStruct { a = q.a }. Dat werkt wel ... ik vind het maar vaag.


[...]
Ik durf door al die verhalen niet eens met NHibernate te beginnen. Thuis begin ik langzamerhand EF5 te leren kennen en vind het best prettig. Zou zomaar kunnen dat we hier op het werk ook overstappen. Verder erg blij met LLBLGen maar EF lijkt beter aan te sluiten op onze werkwijze. Lijkt. Nog even aankijken

Ik vind EF vanaf 4.1 erg prettig moet ik zeggen. Op mijn vorige werk zaten we helaas vast aan een oude versie van LLBLGen (2.6) dat geen Linq ondersteunde . Daarnaast vind ik nadeel van LLBLGen ook dat je er een externe editor voor hebt (die overigens wel goed in elkaar zit). Vergeet ook niet dat je i.c.m. EF T4 templates kunt gebruiken, een zwaar onderschatte feature als je het mij vraagt

[RobIII]

)#*(^@*#&$^@&*(#^$
* RobIII heeft een hekel aan GUI-werk

[R4gnax]

.Gertjan. schreef op dinsdag 12 februari 2013 @ 13:41:
Meh, op zich kan dat geen kwaad. Ik vind dat je best de "oude garde" kunt wijzen op tekortkomingen en kunt kijken of je in de toekomst een nieuwere weg in kunt slaan (en mogelijk gaandeweg de oude logica ook verbeteren). Dat is het voordeel van vers bloed in een project

[...]

Echter moet men niet blijven hangen in die onvrede, als het niet kan dan houdt het gewoon op.

En wat als het oplossen van één probleem op zijn beurt twee of drie nieuwe problemen bloot legt? Wat als twee van die drie problemen opgelost moeten worden om een nieuwe feature te implementeren en dat enkel kan door code die 5 cross-cutting concerns raakt compleet te herschrijven omdat het een onbegrijpelijke, ongestructureerde niet flexibel of herbruikbaar in elkaar gezette bende is?

Bij het merendeel van oude codebases is het zo dat een probleem nooit alleen komt.

Persoonlijk ben ik van mening dat het juist goed is om problemen te blijven benoemen i.p.v. je erbij neer te leggen. Als iedereen zich er bij neer legt zal er nooit verandering op treden en roest alles vast. Op ludieke wijze het 'pareltje van de dag' delen met de rest van je development team vind ik dan eigenlijk lang zo slecht niet om dingen actueel en bespreekbaar te houden. Uiteraard is het wel zaak om niet door te blijven zagen over hetzelfde probleem.

[ Voor 4% gewijzigd door R4gnax op 12-02-2013 19:36 ]

[sky-]

Ik vind dat je altijd naar de context moet kijken. Soms kan je eenmaal niet iets nieuws introduceren. Je kan altijd aangeven wat er beter kan, dat overleggen, daarna is dan te besluiten om actie te ondernemen.

Oude codebases hoeven ook helemaal geen problemen op te leveren. Als de business er goed op draait - er niet constant in gedevved wordt - is het vaak niet eens nodig om het roer helemaal om te gooien.

Het is wel te overwegen dat wanneer de code (en bijbehorende werkwijze) zoveel fouten introduceert dat je er dagen mee bezig bent om iets op te lossen om dan toch maar eens aan te kaarten of er wel op/via de goede manier gewerkt wordt.

[ Voor 0% gewijzigd door sky- op 12-02-2013 20:31 . Reden: typo :x ]

[HMS]

Hmm Jerasure vrij simpel geport naar VC++. Nu nog even een JNI interface maken en kijken of ik de performance van mijn app kan verbeteren. Dat mijn eigen implementatie crap was wist ik, maar ik haalde maar iets van 1 MB/sec . Dat viel even tegen.

~edit:

JNI is black magic.

[ Voor 6% gewijzigd door HMS op 12-02-2013 21:25 ]

[dcm360]

Misschien een stukje dat wel herkenbaar is.

4 jaar geleden was ik eens lui, en zocht ik dus een stukje code om mijn probleempje op te lossen. Na wat zoeken heb ik dat stukje code ook gevonden, al kon dat stukje code eigenlijk al best wel veel dat ik niet nodig had. Maar ach, het was 1 niet al te groot script.

Vandaag de dag is te merken dat dat stukje code niet echt recent meer is. Sinds mn hoster PHP geupgradet heeft, regent het Deprecated-waarschuwingen. Achja, dan kijk ik wel of er een nieuwere versie van is.

Dan blijkt dat dat simpele scriptje dat een beetje overkill was, ondertussen een heel framework te zijn dat nog heel, heel veel meer kan wat ik ook allemaal niet nodig heb.

Kortom, voor dat script gaan de Deprecated-waarschuwingen maar mooi even uit. Wanneer ik er eens tijd voor heb kan ik beter het gehele gammele script dat ik destijd geschreven had herscrhijven.

[Grijze Vos]

Down schreef op dinsdag 12 februari 2013 @ 18:09:
[...]


Ik vind EF vanaf 4.1 erg prettig moet ik zeggen. Op mijn vorige werk zaten we helaas vast aan een oude versie van LLBLGen (2.6) dat geen Linq ondersteunde . Daarnaast vind ik nadeel van LLBLGen ook dat je er een externe editor voor hebt (die overigens wel goed in elkaar zit). Vergeet ook niet dat je i.c.m. EF T4 templates kunt gebruiken, een zwaar onderschatte feature als je het mij vraagt

2.6 ondersteund wel linq afaik.

[Aloys]

RobIII schreef op dinsdag 12 februari 2013 @ 19:08:
)#*(^@*#&$^@&*(#^$
* RobIII heeft een hekel aan GUI-werk

Dan overtuig je de baas toch even dat een CLI veel beter is, kan je veel productiever mee werken (na een te dure cursus die je weer kan verkopen aan de klant)

[Waster]

R4gnax schreef op dinsdag 12 februari 2013 @ 19:34:
[...]


En wat als het oplossen van één probleem op zijn beurt twee of drie nieuwe problemen bloot legt? Wat als twee van die drie problemen opgelost moeten worden om een nieuwe feature te implementeren en dat enkel kan door code die 5 cross-cutting concerns raakt compleet te herschrijven omdat het een onbegrijpelijke, ongestructureerde niet flexibel of herbruikbaar in elkaar gezette bende is?

Bij het merendeel van oude codebases is het zo dat een probleem nooit alleen komt.

Persoonlijk ben ik van mening dat het juist goed is om problemen te blijven benoemen i.p.v. je erbij neer te leggen. Als iedereen zich er bij neer legt zal er nooit verandering op treden en roest alles vast. Op ludieke wijze het 'pareltje van de dag' delen met de rest van je development team vind ik dan eigenlijk lang zo slecht niet om dingen actueel en bespreekbaar te houden. Uiteraard is het wel zaak om niet door te blijven zagen over hetzelfde probleem.

Ik vind het vrij makkelijk gezegd. Toevallig werk ik sinds kort met de meest dramatische codebase. En zelf ben ik juist extreem georganiseerd. De functionele documenten zijn verspreid, en een lap tekst zonder opmaak en geen usecases en opmerkingen, functionaliteit en alles door elkaar. Technische ontwerpen zijn niet compleet vormen geen basis voor wat gebouwd moet worden. De hele codebase is niet gedocumenteerd. Er zijn zoveel schermen die allemaal in dezelfde map staan, zodat je niet eens fatsoenlijk door je project kan navigeren. Over de spaghetti zelf zal ik maar zwijgen. Twintig pagina's open hebben staan in zo'n project is niet prettig. Maar het is onvermijdelijk aangezien er zoveel coupling is. Dat er op iedere pagina tig javascript en css referenties zijn die je moet managen is ook niet fijn. Er zijn ook geen code standaarden ofzo.

Als ik hier iets over wil zeggen dan weet ik niet waar ik moet beginnen. Dan ga ik ego's breken. Dat kun je niet echt maken als junior. En ik kan kan het mijn collega developers niet eens kwalijk nemen. Als het niet gemanaged wordt of niet goed gemanaged, wat kan ik dan doen. De managers die creeeren deze situatie. Als die mij opzadelen met vage en ontbrekende informatie, en ik niet de mogelijkheid heb om contact te hebben met de juiste mensen om dit probleem op te lossen, dan is het onmogelijk voor mij om iets op te leveren van enige kwaliteit. Ik kan ook niet refactoren, want dan breek ik gewoon dingen in één van de honderden pagina's. En er is geen tijd voor etc. etc. Ik kan er hooguit ironisch of sarcastisch over doen.

[Rutix]

Waster schreef op dinsdag 12 februari 2013 @ 23:54:
[...]

Als ik hier iets over wil zeggen dan weet ik niet waar ik moet beginnen. Dan ga ik ego's breken. Dat kun je niet echt maken als junior. En ik kan kan het mijn collega developers niet eens kwalijk nemen. Als het niet gemanaged wordt of niet goed gemanaged, wat kan ik dan doen. De managers die creeeren deze situatie. Als die mij opzadelen met vage en ontbrekende informatie, en ik niet de mogelijkheid heb om contact te hebben met de juiste mensen om dit probleem op te lossen, dan is het onmogelijk voor mij om iets op te leveren van enige kwaliteit. Ik kan ook niet refactoren, want dan breek ik gewoon dingen in één van de honderden pagina's. En er is geen tijd voor etc. etc. Ik kan er hooguit ironisch of sarcastisch over doen.

Dan werk je wel bij een apart bedrijf. In mijn optiek mag je altijd kritiek geven zolang het maar niet is "HET SUCKT" maar wel onderbouwend kritiek. Bij ons mag een Junior echt wel zijn mening geven en dat levert soms interessante discussies op. Ik ben zelf in mijn carrière en daarbuiten ook nooit tegen gekomen dat iemands ego opeens brak omdat ik kritiek had op zijn werk. Dus in die zin heeft R4gnax wel gelijk dat je altijd de problemen mag aankaarten. Of je die problemen ook moet gaan oplossen is een ander verhaal. Als de klant er niet voor wil betalen ga je ook niet alles herschrijven en omgooien, punt. Natuurlijk zul je een goede impact analyse moeten maken en rekening moeten houden met de oude codebase (en de problemen) zodat de klant weet dat die nieuwe feature zo makkelijk nog niet is, maar dat betekent niet dat er opeens geld is om die problemen maar op te lossen .

[ Voor 3% gewijzigd door Rutix op 13-02-2013 08:07 ]

[Erwin537]

Rutix schreef op woensdag 13 februari 2013 @ 08:06:
[...]

Dan werk je wel bij een apart bedrijf. In mijn optiek mag je altijd kritiek geven zolang het maar niet is "HET SUCKT" maar wel onderbouwend kritiek. Bij ons mag een Junior echt wel zijn mening geven en dat levert soms interessante discussies op.

Het kan soms natuurlijk ook een indruk geven he. Als ik als junior binnenkom in een bedrijf (wat hopelijk niet lang meer op zich laat wachten) zal ik niet zomaar commentaar gaan geven, ook al is het opbouwend. Hierbij zal ik eerst eens een tijdje aftasten wat ze wel en niet kunnen hebben voordat ik me er aan waag echte kritiek te geven.

En wat voor cultuur er ook heerst, over het algemeen maak je jezelf niet geliefd als 'je net om de hoek komt kijken' en je gaat al met (opbouwende) kritiek over hun product strooien.

[Rutix]

Erwin537 schreef op woensdag 13 februari 2013 @ 08:13:
[...]

Het kan soms natuurlijk ook een indruk geven he. Als ik als junior binnenkom in een bedrijf (wat hopelijk niet lang meer op zich laat wachten) zal ik niet zomaar commentaar gaan geven, ook al is het opbouwend. Hierbij zal ik eerst eens een tijdje aftasten wat ze wel en niet kunnen hebben voordat ik me er aan waag echte kritiek te geven.

En wat voor cultuur er ook heerst, over het algemeen maak je jezelf niet geliefd als 'je net om de hoek komt kijken' en je gaat al met (opbouwende) kritiek over hun product strooien.

Ja ok, de eerste periode zul je moeten aftasten maar dat geldt niet alleen voor een Junior. Waar ik meer op reageerde was dat het overkwam alsof een Junior geen kritiek mag geven en dat is natuurlijk helemaal niet correct .

[alienfruit]

Maar ja, een halve uurtje puin ruimen. Kost niet veel en ruimt lekker op

[D-Raven]

Doet me denken aan deze blogpost van Dave Ward.

Technical debt is like ketchup

[Rutix]

alienfruit schreef op woensdag 13 februari 2013 @ 08:35:
Maar ja, een halve uurtje puin ruimen. Kost niet veel en ruimt lekker op

Als je maar een half uurtje hoeft puin te ruimen dan was het niet zo'n puinhoop .

[OkkE]

Opera:
"...for all new products Opera will use WebKit as its rendering engine and V8 as its JavaScript engine."

Bron: http://my.opera.com/ODIN/...-users-and-move-to-webkit

[DeluxZ]

OkkE schreef op woensdag 13 februari 2013 @ 09:18:
Opera:
"...for all new products Opera will use WebKit as its rendering engine and V8 as its JavaScript engine."

Bron: http://my.opera.com/ODIN/...-users-and-move-to-webkit

Goed nieuws!

[Flowmo]

You beat me to it

Lees het net ook. Komt niet geheel als verrassing, geruchten speelden al een tijdje. Maar dan nog, ik ben benieuwd wat dit betekent voor het open web. Straks gaat Webkit domineren net als Trident dat deed ten tijde van IE6...

[Alex)]

Erg jammer, dit komt de interoperabiliteit van HTML niet ten goede.

[Radiant]

Zo noemenswaardig is het marktaandeel van Opera nou ook weer niet

Ik vind het wel een goede ontwikkeling. We hebben straks 3 grote rendering engines, daarvoor testen en ontwikkelen is goed te doen i.p.v. dat je rekening moet houden (of mee moet testen, in ieder geval..) met een wildgroei aan kleinere engines. Zolang het marktaandeel van die engines een beetje verdeeld blijft, prima

[Alex)]

Radiant schreef op woensdag 13 februari 2013 @ 09:50:
Zo noemenswaardig is het marktaandeel van Opera nou ook weer niet

Dat klopt, maar Opera heeft wel een significante bijdrage geleverd aan de ontwikkeling van HTML en CSS.

Ik vind het wel een goede ontwikkeling. We hebben straks 3 grote rendering engines, daarvoor testen en ontwikkelen is goed te doen i.p.v. dat je rekening moet houden (of mee moet testen, in ieder geval..) met een wildgroei aan kleinere engines. Zolang het marktaandeel van die engines een beetje verdeeld blijft, prima

Ten tijde van IE waren er ook verschillende engines, de Netscape-engine bestond toen ook al. Toch werd een groot deel van het web 'IE-only' omdat er alleen getest werd in IE. Nu 3 van de 5 grote browsers (IE, Firefox, Chrome, Safari, Opera) op WebKit draaien verwacht ik dat er vooral in WebKit getest zal worden, en dat er ook vooral voor WebKit gebugfixt gaat worden.

Op mobiele websites zie je al dat deze eigenlijk alleen maar voor Safari/Chrome Mobile ontwikkeld worden. Met IE 10 op WP8 val je soms al buiten de boot. Dit krijg je nu wellicht ook (weer) op de desktop.

[Solopher]

Momenteel bezig met een klote opdracht, vooral als je net terug komt van vakantie.

Voor een oude website (5 jaar) een nieuw boekingsproces maken, oude controller bestaat uit 4480 regels code met allerlei functies en uitzonderingen die er later bij in zijn gezet. Nu is het probleem dat ik niet overnieuw mag beginnen maar de huidige code moet aanpassen. Het huidige boekingsproces bestaat uit 13 stappen, dit moet worden teruggebracht worden naar 4.

Ik denk vanaf sratch beginnen in dit geval veel efficiënter is, vooral omdat de gene die het ooit ontwikkeld heeft hier niet meer werkzaam is. En hij nog nooit van standaarden gehoord, waardoor het dus een grote spaghetti zonder comments is.

Maarja, we gaan gewoon verder .

[Radiant]

Verschil in deze is wel dat de gemiddelde consument nog steeds IE als "het internet" ziet en dat wordt meegeleverd met Windows waardoor het altijd veelgebruikt zal blijven. Aan de andere kant is er Webkit die erg populair is op mobiele apparaten, Apple en de wat gevorderde consument die een alternatieve browser installeert.

IE zal nooit heel erg veel marktaandeel verliezen, waardoor je denk ik nooit Webkit-only sites krijgt en Webkit is ook wel weer dusdanig groot dat men daar wel rekening mee moet houden, dus ik verwacht niet dat er snel een keuze gemaakt wordt tussen die twee door ontwikkelaars. Alleen Gecko zou het nog wel eens moeilijk kunnen gaan krijgen..

[Alex)]

Radiant schreef op woensdag 13 februari 2013 @ 10:00:
Verschil in deze is wel dat de gemiddelde consument nog steeds IE als "het internet" ziet en dat wordt meegeleverd met Windows waardoor het altijd veelgebruikt zal blijven. Aan de andere kant is er Webkit die erg populair is op mobiele apparaten, Apple en de wat gevorderde consument die een alternatieve browser installeert.

Volgens een aantal tellerboeren is Google Chrome nu al groter dan Internet Explorer.

Google is al een tijd bezig met een flink media-offensief: reclames op tv, in bushokjes, in kranten, op de homepage van Google.nl ("Wilt u beter internetten? Upgrade nu naar Google Chrome!"), advertenties op websites (via AdSense).

De perceptie "IE is het internet" is wel voorbij.

IE zal nooit heel erg veel marktaandeel verliezen, waardoor je denk ik nooit Webkit-only sites krijgt en Webkit is ook wel weer dusdanig groot dat men daar wel rekening mee moet houden, dus ik verwacht niet dat er snel een keuze gemaakt wordt tussen die twee door ontwikkelaars. Alleen Gecko zou het nog wel eens moeilijk kunnen gaan krijgen..

Gecko krijgt het sowieso moeilijk: Chrome snoept aardig wat marktaandeel af van Firefox. Door de opkomst van tablets en smartphones (met Android en iOS) is WebKit behoorlijk dominant geworden op het internet.

De 'generatie nu' zullen eerder kiezen voor het WebKit-optimaliseren van een site dan voor 'optimaliseren voor alle browsers', verwacht ik.

[alienfruit]

Rutix schreef op woensdag 13 februari 2013 @ 08:38:
Als je maar een half uurtje hoeft puin te ruimen dan was het niet zo'n puinhoop .

Elke dag een half uurtje

Leuk om banners maken. Woehoe!

[ Voor 7% gewijzigd door alienfruit op 13-02-2013 10:12 ]

[OkkE]

Alex) schreef op woensdag 13 februari 2013 @ 09:55:
Ten tijde van IE waren er ook verschillende engines, de Netscape-engine bestond toen ook al. Toch werd een groot deel van het web 'IE-only' omdat er alleen getest werd in IE. Nu 3 van de 5 grote browsers (IE, Firefox, Chrome, Safari, Opera) op WebKit draaien verwacht ik dat er vooral in WebKit getest zal worden, en dat er ook vooral voor WebKit gebugfixt gaat worden.

Denk je dat het nu (voor de overstap van Opera) zo heel veel anders is? Ik heb de afgelopen tijd genoeg geluiden gehoord dat Opera al langer met het probleem zit dat er te weinig rekening met die browser gehouden wordt. Mensen gebruiken de -webkit- en heel soms de -moz- prefix en dan is 't klaar.

Overigens zie ik het niet perse als heel slecht. Ja het is jammer dat er een rendering engine verdwijnt, maar aangezien er toch al zo weinig rekening gehouden werd, is het denk ik voor veel van de gebruikers best positief.

Zo lang er een aantal grote bedrijven meewerken aan WebKit en de source vrij is, zie ik het als een veel minder groot probleem dan vroeger bij "IE-only".

[alienfruit]

Ik zit nu al een tijdje te klooien om mooi een reeks kleuren te kiezen uit een lijstje van 6 zonder dat ze te vaak boven of naast een ander voorkomen. Pain in da butt

[PdeBie]

Solopher schreef op woensdag 13 februari 2013 @ 09:58:
Momenteel bezig met een klote opdracht, vooral als je net terug komt van vakantie.

Voor een oude website (5 jaar) een nieuw boekingsproces maken, oude controller bestaat uit 4480 regels code met allerlei functies en uitzonderingen die er later bij in zijn gezet. Nu is het probleem dat ik niet overnieuw mag beginnen maar de huidige code moet aanpassen. Het huidige boekingsproces bestaat uit 13 stappen, dit moet worden teruggebracht worden naar 4.

Ik denk vanaf sratch beginnen in dit geval veel efficiënter is, vooral omdat de gene die het ooit ontwikkeld heeft hier niet meer werkzaam is. En hij nog nooit van standaarden gehoord, waardoor het dus een grote spaghetti zonder comments is.

Maarja, we gaan gewoon verder .

Waarom mag je niet van scratch beginnen? Als je de goede argumentatie geeft, zullen zij dat ook inzien toch?

[Infinitive]

alienfruit schreef op woensdag 13 februari 2013 @ 10:38:
Ik zit nu al een tijdje te klooien om mooi een reeks kleuren te kiezen uit een lijstje van 6 zonder dat ze te vaak boven of naast een ander voorkomen. Pain in da butt

Graph coloring

[windwarrior]

Infinitive schreef op woensdag 13 februari 2013 @ 10:50:
[...]

Graph coloring

Helaas wel NP-hard

[Alex)]

Misschien kun je uit de voeten met Kuler?

[Intru]

windwarrior schreef op woensdag 13 februari 2013 @ 10:51:
[...]


Helaas wel NP-hard

NP-complete zelfs

[ Voor 3% gewijzigd door Intru op 13-02-2013 11:22 ]

[Sh4wn]

Opzich begrijp ik de keuze van Opera wel goed, en ik hoop dat ze iets meer gaan pushen bij WebKit om het probleem wat op de onderstaande site heel goed beschreven wordt op te lossen.

http://kevinjohngallagher...at-lady-singing-prefixes/

[D-Raven]

Zojuist de laatste hand aan een 50 regels grote Linq statement gelegd.

* D-Raven is niet zeker of hij trots of bang moet zijn

[Rutix]

Ligt er een beetje aan of het duidelijk is geschreven en of je netjes opgesplitst heb over meerdere lijnen

[D-Raven]

Rutix schreef op woensdag 13 februari 2013 @ 12:08:
Ligt er een beetje aan of het duidelijk is geschreven en of je netjes opgesplitst heb over meerdere lijnen

Natuurlijk is het gesplitst over meerdere lijnen, het is alleen dat er zo ontiegelijk veel gebeurd dat het misschien verstandiger is om het refactoren naar verschillende onderdelen, zodat het ook nog een beetje te debuggen is

[Solopher]

pdebie schreef op woensdag 13 februari 2013 @ 10:49:
[...]


Waarom mag je niet van scratch beginnen? Als je de goede argumentatie geeft, zullen zij dat ook inzien toch?

Omdat er op een soort gelijke website, al een "soort" gelijk systeem draait. En ze willen dit dus "één" houden, terwijl alle opties (vroegboekprijzen, reserveringkosten). etc. allemaal hardcoded en verschillend zijn, dus dat argument valt eigenlijk een beetje af.

Ik heb overigens de boel inmiddels aardig opgesplitst, het is gemaakt in CakePHP dus ik heb een plugin gemaakt met hierin aparte config files, controller, views, models etc.

Heb dit natuurlijk wel in overleg met mijn collega's gedaan.
Dit maakt het onderhoud in de toekomst een stuk makkelijker, we kunnen straks een update naar 5 sites tegelijk pushen. Het kost alleen momenteel iets meer werk om overal de hardcoded settings uit te halen en in aparte config files te zetten, en om alle files te vervangen (maar dat moet straks een kwestie van routes vervangen zijn).

Dus begin nu niet helemaal vanaf Scratch maar leg een nieuw wandelpad aan in dit bos zonder kaart.

[BikkelZ]

Binnen twee dagen een nieuwe website gebouwd voor mijn nieuwe frameworkje, moet alleen nog een fatsoenlijke layout voor gemaakt worden en de database moet nog omdat ik SQL 2012 Express niet gedownload krijg omdat hij altijd ergens een keer een netwerkfout geeft. Dan maar een torrent

[_Moe_]

BikkelZ schreef op woensdag 13 februari 2013 @ 13:00:
Binnen twee dagen een nieuwe website gebouwd voor mijn nieuwe frameworkje, moet alleen nog een fatsoenlijke layout voor gemaakt worden en de database moet nog omdat ik SQL 2012 Express niet gedownload krijg omdat hij altijd ergens een keer een netwerkfout geeft. Dan maar een torrent

Dus toch nog wel een dag of 2 werk

[alienfruit]

Nou ja, gewoon random maar gedaan. De overige code maakt de banner te groot. Ik zit nu op 53kB. Op naar de andere tigduizend formaten

[Struikrover]

Poging to namaken soundcloud waveforms: in Python neem ik samples en die stuur ik via JSON door, zodat ik met canvas allemaal rects kan tekenen. Cool idee, hopen dat het lukt

[Firesphere]

Select Distinct iedereen die niet meer heeft ingelogd sinds 1 januari 2012 uit de userlog tabel.
Prima, 1545 records.

Select iedereen uit de usertabel, die volgens de userlog niet meer heeft ingelogd na 1 januari 2012
Prima, 1803 records.
Wacht, wat??

Geen Unique Op Loginnaam

[ Voor 7% gewijzigd door Firesphere op 13-02-2013 14:03 ]

[Jan_V]

Firesphere schreef op woensdag 13 februari 2013 @ 14:00:
Select Distinct iedereen die niet meer heeft ingelogd sinds 1 januari 2012 uit de userlog tabel.
Prima, 1545 records.

Select iedereen uit de usertabel, die volgens de userlog niet meer heeft ingelogd na 1 januari 2012
Prima, 1803 records.
Wacht, wat??

NULL is geen DateTime issue?

[Ijstheefles]

Firesphere schreef op woensdag 13 februari 2013 @ 14:00:
Select Distinct iedereen die niet meer heeft ingelogd sinds 1 januari 2012 uit de userlog tabel.
Prima, 1545 records.

Select iedereen uit de usertabel, die volgens de userlog niet meer heeft ingelogd na 1 januari 2012
Prima, 1803 records.
Wacht, wat??

?

[Verwijderd]

Had niet door dat er een nieuw topic was. Ik zag de Devschuur niet meer voorbijkomen in mijn MyReact. Blijkt dit topic al 24 pagina's verder te zijn

[Douweegbertje]

Ijstheefles schreef op woensdag 13 februari 2013 @ 14:02:
[...]


?

Lees eens verder wat hij zegt?

Geen Unique Op Loginnaam

[Alex)]

[PdeBie]

Alex) schreef op woensdag 13 februari 2013 @ 14:06:
[afbeelding]

QFT

Wij lopen ook al tijden met hetzelfde gezeur.