De Devschuur Coffee Corner - Iteratie ➑

[kwaakvaak_v2]

Soundless schreef op dinsdag 24 maart 2015 @ 14:35:
[...]

Bij ons gebeuren dit soort dingen op de laatste dag.
Zo kwam gisteren de baas langs bij een collega om te zeggen dat het design niet goed was van de website die hij had gemaakt met als extra's "het moet vandaag af want ik ga morgen naar de klant toe". Dit terwijl de website al vele weken in test staat.

Wat een geluk... de laatste tijd heb ik ongeveer hetzelfde, maar dan 2 dagen na LIVE gang..

[mbarie]

Inmiddels na een uur overleggen met alle betrokkenen een oplossing gevonden voor het probleem. Ben ik de rest van de dag zeker wel mee zoet, maar het is een goede keus die er gemaakt is, en realistisch.

[Gamebuster]

_Moe_ schreef op dinsdag 24 maart 2015 @ 09:30:
Mensen die hier hun tevredenheid over slack willen uiten? Vraag me af of ik het nu wel of niet moet testen.

Wij gebruiken slack Werkt prima

[Alex)]

Wederom haat aan Entity Framework. Updaten van 140 items duurde 30 seconden dankzij die verdomde ChangeTracker. Zodra ik 'm uitzette ging het ineens veel sneller.

En ja, ik weet dat je EF moet leren gebruiken net zoals iedere ander pakket/platform/API/tool (ik wil geen F.West98 zijn ), maar toch sta ik geregeld te kijken van de fratsen die EF uithaalt. Daarbij vergeleken is Sharepoint een stabiel en makkelijk te gebruiken product

Edit: Ohja, en dat hij een nieuwe insert doet als je een reeds opgehaald (en inmiddels detached) object aan een nieuw object koppelt is ook bizar. Dat ding heeft verdorie al een ingevulde key.

[ Voor 23% gewijzigd door Alex) op 24-03-2015 21:35 ]

[Firesphere]

Dat wordt 3 dagen overwerken

[F.West98]

Alex) schreef op dinsdag 24 maart 2015 @ 20:46:
Wederom haat aan Entity Framework. Updaten van 140 items duurde 30 seconden dankzij die verdomde ChangeTracker. Zodra ik 'm uitzette ging het ineens veel sneller.

Wat voor enorm complexe entities heb jij dan wel niet? Ik update honderden tot duizenden entities binnen 2 minuten. Op een trage dualcore VM (2Ghz). Lokaal is dat <20 seconden.

En ja, ik weet dat je EF moet leren gebruiken net zoals iedere ander pakket/platform/API/tool (ik wil geen F.West98 zijn ), maar toch sta ik geregeld te kijken van de fratsen die EF uithaalt. Daarbij vergeleken is Sharepoint een stabiel en makkelijk te gebruiken product

Ik kan EF prima gebruiken

[Avalaxy]

Alex is gewoon een prutser die al z'n onkunde op Entity Framework afreageert

[Ryur]

Firesphere schreef op dinsdag 24 maart 2015 @ 20:47:
Dat wordt 3 dagen overwerken

Wat is er?

[Firesphere]

Ryur schreef op dinsdag 24 maart 2015 @ 22:30:
[...]

Wat is er?

Dit handelen we even via PM af Het was een uiting van frustratie. De achterliggende reden daarentegen, kan en mag ik hier niet publiekelijk delen en doet er ook niet heel veel toe volgens mij.

[ Voor 9% gewijzigd door Firesphere op 24-03-2015 23:32 ]

[farlane]

Waarom post je het dan hier? Eerst klagen en als er vervolgens gevraagd wordt wat er is het niet willen zeggen ....

[Firesphere]

farlane schreef op dinsdag 24 maart 2015 @ 23:27:
Waarom post je het dan hier? Eerst klagen en als er vervolgens gevraagd wordt wat er is het niet willen zeggen ....

Ik klaag even. Dat ik meer details niet hier in-topic wil geven, is volgens mij helemaal niet raar.

[F.West98]

I call vaguebooking

[Alex)]

F.West98 schreef op dinsdag 24 maart 2015 @ 22:17:
[...]


Wat voor enorm complexe entities heb jij dan wel niet? Ik update honderden tot duizenden entities binnen 2 minuten. Op een trage dualcore VM (2Ghz). Lokaal is dat <20 seconden.

Entities met een paar child-collections en nog veel meer ellende eronder, dat gaat wel een niveau of 6 diep. Waar ik overigens niks in heb gewijzigd, wat EF ook gewoon zou moeten weten aangezien alles uit dezelfde DbContext komt.

Ik kan EF prima gebruiken

Jij loopt hier vaak te bitchen als iets niet meteen werkt (al heb je dat de laatste tijd een stuk minder gedaan )

Avalaxy schreef op dinsdag 24 maart 2015 @ 22:20:
Alex is gewoon een prutser die al z'n onkunde op Entity Framework afreageert

Alex is vooral iemand die zich soms verbaast over het bizarre gedrag dat EF ten toon spreidt en die inmiddels een diepgewortelde haat aan het ontwikkelen is voor dat hele ding.

Slechtste architectuurkeuze ooit.

[F.West98]

Alex) schreef op woensdag 25 maart 2015 @ 00:10:
[...]
Entities met een paar child-collections en nog veel meer ellende eronder, dat gaat wel een niveau of 6 diep. Waar ik overigens niks in heb gewijzigd, wat EF ook gewoon zou moeten weten aangezien alles uit dezelfde DbContext komt.

Hmm.. Bij mij is het misschien 2 lagen. Might explain it

[...]

Jij loopt hier vaak te bitchen als iets niet meteen werkt (al heb je dat de laatste tijd een stuk minder gedaan )

Liep*
Laatste tijd niet zo veel meer geprogrammeerd ook, school drukte enzo.

[Cor453]

Ranten is voor mij 80% van de Coffee Corner. Oh wacht, zal ik de topic warning 'ns citeren?
"De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak."

YES

[Alex)]

F.West98 schreef op woensdag 25 maart 2015 @ 00:15:
[...]

Hmm.. Bij mij is het misschien 2 lagen. Might explain it

Het is een vrij complex model, omdat er zoveel afhankelijkheden zijn en alles combineerbaar is. Ook zijn er ene paar tabellen die naar zichzelf verwijzen (parent-child) en zit er ook nog een stukje Entity-Attribute-Value-pattern in.

Al met al best wel complexe objecten, en ik denk echt dat er in het verleden een paar keuzes en foutieve aannames zijn gemaakt die nu erg vervelend lijken uit te pakken. Ik ben er nu dus hard mee bezig om die dingen recht te trekken, zo goed en zo kwaad als het kan.

En daarbij zie ik gewoon dat Entity Framework zich soms erg onvoorspelbaar gedraagt. Als je al een POCO hebt met daarin een gezette primary key, en je hangt die in een nieuw object, dan is het niet bepaald voorspelbaar gedrag als EF ineens een nieuwe insert doet voor een bestaand object.

Dit zegmaar:

C#:

var author = new Author { AuthorId = 1, Name = "Alex" };

using(var ctx = new BooksContext())
{
    ctx.Books.Add(new Book() { Author = author, Name = "1000 kleine stukjes EF-haat voor gevorderden." };
    ctx.SaveChanges();
}

Dat er dan ineens een nieuwe Author wordt aangemaakt...

Liep*
Laatste tijd niet zo veel meer geprogrammeerd ook, school drukte enzo.

[F.West98]

Alex) schreef op woensdag 25 maart 2015 @ 00:25:
[...]

Het is een vrij complex model, omdat er zoveel afhankelijkheden zijn en alles combineerbaar is. Ook zijn er ene paar tabellen die naar zichzelf verwijzen (parent-child) en zit er ook nog een stukje Entity-Attribute-Value-pattern in.

Self-referencing: check, soortvan. Car heeft een property Vehicle, Car extendt Vehicle. Dat een beetje.
De rest: nee. Entity-Attribute-Value?!

Al met al best wel complexe objecten, en ik denk echt dat er in het verleden een paar keuzes en foutieve aannames zijn gemaakt die nu erg vervelend lijken uit te pakken. Ik ben er nu dus hard mee bezig om die dingen recht te trekken, zo goed en zo kwaad als het kan.

En daarbij zie ik gewoon dat Entity Framework zich soms erg onvoorspelbaar gedraagt. Als je al een POCO hebt met daarin een gezette primary key, en je hangt die in een nieuw object, dan is het niet bepaald voorspelbaar gedrag als EF ineens een nieuwe insert doet voor een bestaand object.

Dit zegmaar:

C#:

var author = new Author { AuthorId = 1, Name = "Alex" };

using(var ctx = new BooksContext())
{
    ctx.Books.Add(new Book() { Author = author, Name = "1000 kleine stukjes EF-haat voor gevorderden." };
    ctx.SaveChanges();
}

Dat er dan ineens een nieuwe Author wordt aangemaakt...

Gelukkig is mijn enige probleem dat 'ie *soms* ineens vindt dat ik te veel connections open heb als ik er maar ééntje open heb. Maar dat is dan enkel met een localhost connection (volgens mij) dus de gebruikers ondervinden geen problemen...

[Alex)]

F.West98 schreef op woensdag 25 maart 2015 @ 00:30:
[...]

Self-referencing: check, soortvan. Car heeft een property Vehicle, Car extendt Vehicle. Dat een beetje.
De rest: nee. Entity-Attribute-Value?!

EAV is een soort database-in-een-database-model dat je op zich best veel vrijheid geeft. Je definieert een tabel met entiteiten (je tabellen), nog een tabel met attributen (de kolommen die in iedere tabel bestaan) en een tabel met values (de rijen en hun waardes).

In veel situaties is dit model niet gewenst omdat je alle vormen van referentiële integriteit en constraints kwijtraakt, maar voor sommige scenario's is het uitermate geschikt. Bijvoorbeeld als je werkt met stukjes informatie die niet goed in een klassieke tabelstructuur te vangen zijn of die dynamisch kan veranderen. Ik heb dus zo'n situatie

Het 'grappige' is dat hij ook meteen de ID met 1000 ophoogt.

Gelukkig is mijn enige probleem dat 'ie *soms* ineens vindt dat ik te veel connections open heb als ik er maar ééntje open heb. Maar dat is dan enkel met een localhost connection (volgens mij) dus de gebruikers ondervinden geen problemen...

Oh, die is ook leuk. Dispose je wel netjes je DbContexts enzo?

In mijn project gebruik ik Unity om een DbContext te injecten die ik tijdens vrijwel de hele request-lifecycle gebruik. Unity zorgt uiteindelijk voor het disposen van dat ding, wanneer dat request is afgelopen. Werkt best netjes

[Jan_V]

Alex) schreef op woensdag 25 maart 2015 @ 01:36:
[...]


Oh, die is ook leuk. Dispose je wel netjes je DbContexts enzo?

In mijn project gebruik ik Unity om een DbContext te injecten die ik tijdens vrijwel de hele request-lifecycle gebruik. Unity zorgt uiteindelijk voor het disposen van dat ding, wanneer dat request is afgelopen. Werkt best netjes

Hmm, klinkt handig.
Nog niet eerder aan gedacht om je dbContext ook te injecten. Wordt de dispose dan wel goed afgehandeld? Heb nu namelijk een DAL gemaakt waar de dbContext continu weer wordt aangemaakt, maar dat kan dus wel worden omgebouwd door deze te injecten.

[Alex)]

Jan_V schreef op woensdag 25 maart 2015 @ 09:45:
[...]

Hmm, klinkt handig.

Dat is het ook. Enig minpuntje is dat je niet zomaar var ctx2 = new MyDbContext(); kunt doen (wat nogal makkelijk gedaan is), maar dat je aan je container moet vragen om je een nieuwe instance te geven. Dan krijg je bijvoorbeeld zoiets:

C#:

public class Baz (IUnitOfWork unitOfWork, IUnityContainer unityContainer)
{
    public void ChildUow()
    {
        using(var child = unityContainer.Resolve<IUnitOfWork>())
        { /* piew */ }
    }

    public void ChildType()
    {
        using(var childContainer = unityContainer.CreateChildContainer())
        {
            var childBaz = childContainer.Resolve<Baz>();
        }
    }
}

Nog niet eerder aan gedacht om je dbContext ook te injecten. Wordt de dispose dan wel goed afgehandeld? Heb nu namelijk een DAL gemaakt waar de dbContext continu weer wordt aangemaakt, maar dat kan dus wel worden omgebouwd door deze te injecten.

Ja, Unity handelt de Dispose prima af. Je moet dan wel de juiste LifetimeManager gebruiken voor het aanmaken van je objecten.

Ik gebruik geloof ik (ik kan op dit moment even niet bij de sourcecode van mijn project) vooral de HierarchicalLifetimeManager voor de disposable objecten die ik heb. Unity handelt de rest af, zolang ik mijn containers maar netjes dispose.

[Mercatres]

Unity is inderdaad leuk om mee te werken, pretty straightforward om te gebruiken ook.

[BtM909]

farlane schreef op dinsdag 24 maart 2015 @ 23:27:
Waarom post je het dan hier? Eerst klagen en als er vervolgens gevraagd wordt wat er is het niet willen zeggen ....

Dit is een uitlaatkleptopic, geen leg-hier-je-verantwoording-aftopic

---

F.West98 schreef op woensdag 25 maart 2015 @ 00:15:

Laatste tijd niet zo veel meer geprogrammeerd ook, school drukte enzo.

Ik heb, denk ik, de oplossingen voor *al* je programmeerproblemen

[ Voor 30% gewijzigd door BtM909 op 25-03-2015 10:36 ]

[hylke94]

Totaal geen energie/zin om te werken vandaag en dat vieze weer werkt ook niet bepaald motiverend...

[ Voor 9% gewijzigd door hylke94 op 25-03-2015 10:51 ]

[Gamebuster]

Als het grijs weer is, zeg ik altijd: Ik heb geen zin in werken met dit slechte weer.
Als het mooi weer is, zeg ik altijd: Het is zo mooi weer, ik heb geen zin werken zo.

Conclusie: Het feit dat ik altijd geen zin in werken heb, wordt anders verwoord bij ander weer.

[ Voor 5% gewijzigd door Gamebuster op 25-03-2015 10:53 ]

[farlane]

Firesphere schreef op dinsdag 24 maart 2015 @ 23:31:
Ik klaag even. Dat ik meer details niet hier in-topic wil geven, is volgens mij helemaal niet raar.

BtM909 schreef op woensdag 25 maart 2015 @ 10:35:
[...]
Dit is een uitlaatkleptopic, geen leg-hier-je-verantwoording-aftopic

Prima, ik vond het een beetje een vrouwenactie, that's all.

[kenneth]

farlane schreef op woensdag 25 maart 2015 @ 11:43:

Prima, ik vond het een beetje een vrouwenactie, that's all.

Wat is er vrouwelijk aan die actie?

[OkkE]

Na een beetje vervelende dag gister waarin van alles tegen zat, vandaag weer vol goede moet verder. Waar een nachtje slapen al niet goed voor kan zijn.

[.oisyn]

BtM909 schreef op woensdag 25 maart 2015 @ 10:35:
[...]

Dit is een uitlaatkleptopic, geen leg-hier-je-verantwoording-aftopic

Dat het een uitlaatkleptopic is impliceert niet dat anderen niet om die verantwoording mogen vragen . Het mes snijdt aan twee kanten.

[ Voor 5% gewijzigd door .oisyn op 25-03-2015 12:25 ]

[Merethil]

.oisyn schreef op woensdag 25 maart 2015 @ 12:24:
[...]


Dat het een uitlaatkleptopic is impliceert niet dat anderen niet om die verantwoording mogen vragen

Maar dat iemand erom vraagt betekent niet dat er antwoord gegeven moet worden
Wat een lastig gedoe, Firesphere moet gewoon drie dagen overwerken en dus "sucks to be him"

[Douweegbertje]

.oisyn schreef op woensdag 25 maart 2015 @ 12:24:
[...]


Dat het een uitlaatkleptopic is impliceert niet dat anderen niet om die verantwoording mogen vragen . Het mes snijdt aan twee kanten.

Waarom post je dit?!?

[Merethil]

Douweegbertje schreef op woensdag 25 maart 2015 @ 12:39:
[...]


Waarom post je dit?!?

Waarom vraag je dit!?

[Gamebuster]

Even het topic weer een gezondere wending geven:

PHP is kut. Windows is kut. Mac is awesome. iOS is veel beter dan Android. C# is nep-Java. VI is voor hippies. Emacs is oude rommel. Linux desktop is voor mensen die geen mac kunnen betalen. Micro$oft is voor mensen met een ondergemiddeld IQ. WII U is een awesome console. PS4 en XBOX ONE zijn superieur aan PC gaming.

Zijn we nu weer allemaal gezellige geeks met een haat-liefde verhouding tegenover alles met een stekker?

[ Voor 49% gewijzigd door Gamebuster op 25-03-2015 12:49 ]

[.oisyn]

Douweegbertje schreef op woensdag 25 maart 2015 @ 12:39:
[...]


Waarom post je dit?!?

Omdat ik me overal graag mee bemoei, ik dacht dat jou dat inmiddels wel duidelijk was

[Merethil]

Gamebuster schreef op woensdag 25 maart 2015 @ 12:46:
Even het topic weer een gezondere wending geven:

PHP is kut. Windows is kut. Mac is awesome. iOS is veel beter dan Android. C# is nep-Java. VI is voor hippies. Emacs is oude rommel. Linux desktop is voor mensen die geen mac kunnen betalen. Micro$oft is voor mensen met een ondergemiddeld IQ. WII U is een awesome console. PS4 en XBOX ONE zijn superieur aan PC gaming.

Zijn we nu weer allemaal gezellige geeks met een haat-liefde verhouding tegenover alles met een stekker?

Waarom post je dit?

Ik kan trouwens nog wel herinneren dat jij eigenlijk OS X helemaal crap vond vanwege de geslotenheid (zelfde geldt voor iOS) en dat je graag een Linux systeem wilde, alleen dan eentje waarbij je laptop ook echt meer dan 2 uur op de batterij mee kon en HiDPI geen problemen gaf.... Waarom opeens zo bitter?

[.oisyn]

Merethil schreef op woensdag 25 maart 2015 @ 12:26:
[...]


Maar dat iemand erom vraagt betekent niet dat er antwoord gegeven moet worden

Niemand zegt dat

[BtM909]

.oisyn schreef op woensdag 25 maart 2015 @ 12:24:
[...]


Dat het een uitlaatkleptopic is impliceert niet dat anderen niet om die verantwoording mogen vragen . Het mes snijdt aan twee kanten.

Als we dan toch anal zijn: ik zeg toch niet dat het geen "vraag-hier-om-verantwoording-af-te-leggentopic"?

Elke vraag mag gesteld worden, maar blijkbaar wilt Firephere geen antwoord geven.

[Douweegbertje]

BtM909 schreef op woensdag 25 maart 2015 @ 13:01:
[...]

Als we dan toch anal zijn: ik zeg toch niet dat het geen "vraag-hier-om-verantwoording-af-te-leggentopic"?

Elke vraag mag gesteld worden, maar blijkbaar wilt Firephere geen antwoord geven.

Waarom zeg je nou anal?!

[BtM909]

Douweegbertje schreef op woensdag 25 maart 2015 @ 13:02:
[...]


Waarom zeg je nou anal?!

Omdat ik eerlijk gezegd geen Nederlands woord kan bedenken wat daar in de buurt komt.

[Merethil]

BtM909 schreef op woensdag 25 maart 2015 @ 13:03:
[...]

Omdat ik eerlijk gezegd geen Nederlands woord kan bedenken wat daar in de buurt komt.

Mierenneuken?

[BtM909]

Merethil schreef op woensdag 25 maart 2015 @ 13:03:
[...]


Mierenneuken?

anal: extremely or overly neat, careful, or precise

Wat is de officiële definitie van mierenneuken eigenlijk?

[Merethil]

BtM909 schreef op woensdag 25 maart 2015 @ 13:04:
[...]


[...]


Wat is de officiële definitie van mierenneuken eigenlijk?

Mierenneuken

Mierenneuken, ook wel muggenziften, chicaneren, haarkloven, kommaneuken, of spijkers op laag water zoeken (Van Dale) is het vitten op kleine foutjes en het actief zoeken naar de geringste aanleiding om kritiek te uiten. De etymologie van muggenziften moet in de Bijbel gezocht worden (Mattheus 23:24): Gij blinde leidslieden, die de mug uitzijgt, en

Bron: http://www.encyclo.nl/begrip/Mierenneuken

[BtM909]

Ok cool, want vandale.nl gaf

Geen resultaat voor ' mierenneuken '

[Gamebuster]

Merethil schreef op woensdag 25 maart 2015 @ 12:54:
[...]


Waarom post je dit?

Ik kan trouwens nog wel herinneren dat jij eigenlijk OS X helemaal crap vond vanwege de geslotenheid (zelfde geldt voor iOS) en dat je graag een Linux systeem wilde, alleen dan eentje waarbij je laptop ook echt meer dan 2 uur op de batterij mee kon en HiDPI geen problemen gaf.... Waarom opeens zo bitter?

Ik kan het me niet herinneren dat ik zoiets ergens heb neergezet, maar de argumentatie betreffende accuduur en HiDPI klinkt wel als een klachtenlijst van mij richting Linux.

Heb je linkje?

[Merethil]

Gamebuster schreef op woensdag 25 maart 2015 @ 13:07:
[...]

Ik kan het me niet herinneren dat ik zoiets ergens heb neergezet, maar de argumentatie betreffende accuduur en HiDPI klinkt wel als een klachtenlijst van mij richting Linux.

Heb je linkje?

Ik heb het je horen zeggen, niet zien schrijven

[SPee]

Alex) schreef op woensdag 25 maart 2015 @ 00:25:
[...]

Het is een vrij complex model, omdat er zoveel afhankelijkheden zijn en alles combineerbaar is. Ook zijn er ene paar tabellen die naar zichzelf verwijzen (parent-child) en zit er ook nog een stukje Entity-Attribute-Value-pattern in.

Al met al best wel complexe objecten, en ik denk echt dat er in het verleden een paar keuzes en foutieve aannames zijn gemaakt die nu erg vervelend lijken uit te pakken. Ik ben er nu dus hard mee bezig om die dingen recht te trekken, zo goed en zo kwaad als het kan.

En daarbij zie ik gewoon dat Entity Framework zich soms erg onvoorspelbaar gedraagt. Als je al een POCO hebt met daarin een gezette primary key, en je hangt die in een nieuw object, dan is het niet bepaald voorspelbaar gedrag als EF ineens een nieuwe insert doet voor een bestaand object.

Dit zegmaar:

C#:

var author = new Author { AuthorId = 1, Name = "Alex" };

using(var ctx = new BooksContext())
{
    ctx.Books.Add(new Book() { Author = author, Name = "1000 kleine stukjes EF-haat voor gevorderden." };
    ctx.SaveChanges();
}

Dat er dan ineens een nieuwe Author wordt aangemaakt...

[...]

Hoezo niet voorspelbaar?
M.i. als EF detecteerd dat het object niet vanuit de DB komt, dan betekent het voor EF dat deze aangemaakt moet worden. Als jij dan dat nieuwe object als referentie gebruikt, dan moet EF ook die persisteren, om aan de DB constraints te voldoen. En wordt bij het aanmaken de AuthorId gezet met de nieuwe aangemaakte waarde. En wordt het object aangemerkt als 'verbonden met db'.
Je moet dan niet een nieuwe Author object aanmaken, maar een referentie uit EF ophalen.

(vanuit het oogpunt van een java ontwikkelaar )

[farlane]

kenneth schreef op woensdag 25 maart 2015 @ 11:44:
Wat is er vrouwelijk aan die actie?

Getergd doen en als er gevraagd wordt wat er is dan zeggen dat er niets is, of "laat maar".

[ZaZ]

Ik vind alles kut.
Zelfs kut is kut.

[Grijze Vos]

SPee schreef op woensdag 25 maart 2015 @ 13:21:
[...]
Je moet dan niet een nieuwe Author object aanmaken, maar een referentie uit EF ophalen.

Inderdaad, of je attacht de nieuwe entiteit aan de context. Waardoor de oude wordt opgehaald, en wijzigingen worden doorgevoerd. EF heeft een aantal slechte zaken, maar mensen kunnen ook heel erg overdrijven.

[Hoogie2004]

farlane schreef op woensdag 25 maart 2015 @ 13:22:
[...]

Getergd doen en als er gevraagd wordt wat er is dan zeggen dat er niets is, of "laat maar".

Zoiets?

[farlane]

Hoogie2004 schreef op woensdag 25 maart 2015 @ 13:26:
[...]

Zoiets?
[afbeelding]

Dat dus

[.oisyn]

BtM909 schreef op woensdag 25 maart 2015 @ 13:01:
[...]

Als we dan toch anal zijn: ik zeg toch niet dat het geen "vraag-hier-om-verantwoording-af-te-leggentopic"?

Als we anal zijn dan mist er een werkwoord in die laatste deelzin

[mbarie]

Hele rare bug op development van nieuwe site. Enkel voor Firefox op Mac. Youtube embeds en video ads werken niet. Left click op Youtube of advertentie doet niets, right click ook niet. Hmpf.

[BtM909]

.oisyn schreef op woensdag 25 maart 2015 @ 13:56:
[...]

Als we anal zijn dan mist er een werkwoord in die laatste deelzin

[Megamind]

SPee schreef op woensdag 25 maart 2015 @ 13:21:
[...]


Hoezo niet voorspelbaar?
M.i. als EF detecteerd dat het object niet vanuit de DB komt, dan betekent het voor EF dat deze aangemaakt moet worden. Als jij dan dat nieuwe object als referentie gebruikt, dan moet EF ook die persisteren, om aan de DB constraints te voldoen. En wordt bij het aanmaken de AuthorId gezet met de nieuwe aangemaakte waarde. En wordt het object aangemerkt als 'verbonden met db'.
Je moet dan niet een nieuwe Author object aanmaken, maar een referentie uit EF ophalen.

(vanuit het oogpunt van een java ontwikkelaar )

Daarom kan je beter de FK ID meegeven aan je object ipv een heel object. Scheelt een hoop gedoe.

[F.West98]

Alex) schreef op woensdag 25 maart 2015 @ 01:36:
[...]

EAV is een soort database-in-een-database-model dat je op zich best veel vrijheid geeft. Je definieert een tabel met entiteiten (je tabellen), nog een tabel met attributen (de kolommen die in iedere tabel bestaan) en een tabel met values (de rijen en hun waardes).

In veel situaties is dit model niet gewenst omdat je alle vormen van referentiële integriteit en constraints kwijtraakt, maar voor sommige scenario's is het uitermate geschikt. Bijvoorbeeld als je werkt met stukjes informatie die niet goed in een klassieke tabelstructuur te vangen zijn of die dynamisch kan veranderen. Ik heb dus zo'n situatie

Klinkt inderdaad vrij slecht, maar nu ik het zo hoor is het wel een goede oplossing voor een probleem wat ik een tijd geleden had (meerdere soorten lictenties voor producten, en elke soort licentie heeft een andere inlogvorm (username/pass, code, enz), huidige oplossing vereist dat iedere nieuwe soort een nieuwe class heeft in het model en ook een eigen manier van verwerken heeft in de code.) Maar hoe werk je dan met dit soort gegevens? Je hebt dus niet een 'model' dat compiletime wordt gevalideerd...

[...]

Het 'grappige' is dat hij ook meteen de ID met 1000 ophoogt.

Volgens mij heb ik dat dan ook eens gehad. Ik zit in een tabel met max. 300 entries ook al ineens op 6k+ als ID....

[...]

Oh, die is ook leuk. Dispose je wel netjes je DbContexts enzo?

In mijn project gebruik ik Unity om een DbContext te injecten die ik tijdens vrijwel de hele request-lifecycle gebruik. Unity zorgt uiteindelijk voor het disposen van dat ding, wanneer dat request is afgelopen. Werkt best netjes

Hmm interessant. Misschien daar eens naar kijken voor mijn webclient. Op dit moment heb ik gewoon concurrentconnectiondinges aangezet, dat werkt prima. Het is ook nodig voor een ander (threaded) proces die meerdere connections nodig heeft om geen concurrentmodificationexceptions te krijgen (of hoe die ook maar mogen heten in C#).

[Gamebuster]

HAML 1:

code:

- cache do
  %meta{ charset: "utf-8" }

Resultaat 1e keer laden: (fresh)

HTML:

<meta charset='utf-8'>

Resultaat 2e keer laden: (uit cache)

HTML:

meta charset='utf-8'>

HAML 2:

code:

- cache do
  <meta charset='utf-8'>

Resultaat uit 1e (fresh) en 2e keer laden (cache) gelijk:

HTML:

<meta charset='utf-8'>

Wtf?

[ Voor 39% gewijzigd door Gamebuster op 25-03-2015 15:01 ]

[Jan_V]

F.West98 schreef op woensdag 25 maart 2015 @ 14:37:
[...]

Klinkt inderdaad vrij slecht, maar nu ik het zo hoor is het wel een goede oplossing voor een probleem wat ik een tijd geleden had (meerdere soorten lictenties voor producten, en elke soort licentie heeft een andere inlogvorm (username/pass, code, enz), huidige oplossing vereist dat iedere nieuwe soort een nieuwe class heeft in het model en ook een eigen manier van verwerken heeft in de code.) Maar hoe werk je dan met dit soort gegevens? Je hebt dus niet een 'model' dat compiletime wordt gevalideerd...

[...]

Kijk wel uit met het implementeren van EAV.
Sowieso is het leuk om een keer voor een hobby/schoolopdracht te gebruiken, zodat je weet hoe het werkt en wat de voor- en nadelen zijn. Voor een klant inzetten is iets wat je in eerste instantie beter niet kunt doen, tenzij je zeker weet dat er voldoende voordelen zijn die van groter belang dan de bijkomende nadelen.

In het geval van Alex ga ik er vanuit dat dit vantevoren goed is doordacht

[ Voor 3% gewijzigd door Jan_V op 25-03-2015 15:00 ]

[F.West98]

Ik zou het ook niet zomaar doen

[Alex)]

SPee schreef op woensdag 25 maart 2015 @ 13:21:
[...]


Hoezo niet voorspelbaar?
M.i. als EF detecteerd dat het object niet vanuit de DB komt, dan betekent het voor EF dat deze aangemaakt moet worden. Als jij dan dat nieuwe object als referentie gebruikt, dan moet EF ook die persisteren, om aan de DB constraints te voldoen. En wordt bij het aanmaken de AuthorId gezet met de nieuwe aangemaakte waarde. En wordt het object aangemerkt als 'verbonden met db'.
Je moet dan niet een nieuwe Author object aanmaken, maar een referentie uit EF ophalen.

(vanuit het oogpunt van een java ontwikkelaar )

In de definitie van het object staat geïdentificeerd wat de primary key van het object is, m.i. zou EF slim genoeg moeten zijn om dan te bepalen "Hey, het is een bestaand object. Laat ik dus een update dáárop doen i.p.v. een nieuwe insert" - zo zou ik het tenminste zelf implementeren.

Uiteindelijk ben ik gaan doen wat Megamind al zei, ik zet de FK-identifier en de rest zal me aan m'n reet roesten. Dat het childobject überhaupt werd ingevuld was eigenlijk een bugje, dat eerst niet opviel omdat alles uit dezelfde DbContext kwam.

F.West98 schreef op woensdag 25 maart 2015 @ 14:37:
[...]

Klinkt inderdaad vrij slecht, maar nu ik het zo hoor is het wel een goede oplossing voor een probleem wat ik een tijd geleden had (meerdere soorten lictenties voor producten, en elke soort licentie heeft een andere inlogvorm (username/pass, code, enz), huidige oplossing vereist dat iedere nieuwe soort een nieuwe class heeft in het model en ook een eigen manier van verwerken heeft in de code.) Maar hoe werk je dan met dit soort gegevens? Je hebt dus niet een 'model' dat compiletime wordt gevalideerd...

Als je met EAV wilt werken moet je zelf verdomde goed weten welke datatypes je hebt, hoe je relaties liggen en hoe je de data consistent houdt. Er is tenslotte geen enkele vorm van referentiële integriteit of constraints meer.

Als je model hierop is ingericht hoeft het geen probleem te zijn, maar je moet verdomd goed in de gaten houden waar je mee bezig bent.

Volgens mij heb ik dat dan ook eens gehad. Ik zit in een tabel met max. 300 entries ook al ineens op 6k+ als ID....

Klinkt als hetzelfde ding.

Hmm interessant. Misschien daar eens naar kijken voor mijn webclient. Op dit moment heb ik gewoon concurrentconnectiondinges aangezet, dat werkt prima. Het is ook nodig voor een ander (threaded) proces die meerdere connections nodig heeft om geen concurrentmodificationexceptions te krijgen (of hoe die ook maar mogen heten in C#).

Unity (of soortgelijke producten zoals Autofac, Ninject, enz.) is heerlijk. In het begin is het even wennen, maar het maakt het zoveel makkelijker om je code te testen, of bijvoorbeeld om dingen aan te passen.

Stel, ik heb een klasse met de volgende constructor:

C#:

public class AccessValidator {
    public AccessValidator (IUnitOfWork, IScriptEngine scriptEngine, IFailureHandler failureHandler) { ... } 
}

Als ik hier nu iets aan toevoeg of wijzig hoef ik niet op 30 plekken (5 echte plekken + 25 unit tests) de new-call aan te passen, Unity zorgt er wel voor dat alles blijft werken en dat ik de juiste objecten binnenkrijg.

Wat ik hier doe heet 'constructor injection', een alternatief wat je ook wel ziet is 'property injection' (waarbij de waarde van properties wordt gezet op instances van objecten) maar dat vind ik er altijd een beetje lelijk uitzien. Met constructors maak je tenminste meteen duidelijk wat de afhankelijkheden zijn die een klasse heeft, waarbij dat met properties minder in-your-face is...

Jan_V schreef op woensdag 25 maart 2015 @ 15:00:
[...]

Kijk wel uit met het implementeren van EAV.
Sowieso is het leuk om een keer voor een hobby/schoolopdracht te gebruiken, zodat je weet hoe het werkt en wat de voor- en nadelen zijn. Voor een klant inzetten is iets wat je in eerste instantie beter niet kunt doen, tenzij je zeker weet dat er voldoende voordelen zijn die van groter belang dan de bijkomende nadelen.

Eens.

In het geval van Alex ga ik er vanuit dat dit vantevoren goed is doordacht

Ja, er is zeker goed over nagedacht. We hadden zulke functionaliteit gewoon nodig omdat er veel voorwaarden zijn aan wanneer bepaalde informatie ingevuld mag/moet worden, en dat liet zich niet vangen in een gewone tabelstructuur.

Wat ik doe is dat ik alle gekozen waardes in een Dictionary<string, List<string>>* gooi, die ik vervolgens weer aan een paar IronPython-scripts voer. Die scripts halen informatie uit die dictionary om er weer verdere bewerkingen op te doen.

* In mijn datamodel heb ik enkel te maken met strings, vandaar de keuze voor dat type.

[SPee]

Alex) schreef op woensdag 25 maart 2015 @ 15:23:
[...]
Wat ik hier doe heet 'constructor injection', een alternatief wat je ook wel ziet is 'property injection' (waarbij de waarde van properties wordt gezet op instances van objecten) maar dat vind ik er altijd een beetje lelijk uitzien. Met constructors maak je tenminste meteen duidelijk wat de afhankelijkheden zijn die een klasse heeft, waarbij dat met properties minder in-your-face is...

Vorige week vroeg een collega in de mailgroep: Constructor autowiring vs field autowiring?
Dus gelijk een grote discussie gaande: de ene helft is voor, de andere helft tegen.
Vergelijkbaar met de discussie: spaties of tabs?

[Glorificationer426]

SPee schreef op woensdag 25 maart 2015 @ 15:56:
[...]


Vorige week vroeg een collega in de mailgroep: Constructor autowiring vs field autowiring?
Dus gelijk een grote discussie gaande: de ene helft is voor, de andere helft tegen.
Vergelijkbaar met de discussie: spaties of tabs?

Toch wel een iets ander soort discussie m.i. Op het gebied van dependency injection is de algemene tendens toch wel dat constructor injection de wenselijke manier is. Dit terwijl spaties vs. tabs in veel gevallen een kwestie van conventie en smaak is.

[Korben]

Alex) schreef op woensdag 25 maart 2015 @ 15:23:
[...]

In de definitie van het object staat geïdentificeerd wat de primary key van het object is, m.i. zou EF slim genoeg moeten zijn om dan te bepalen "Hey, het is een bestaand object. Laat ik dus een update dáárop doen i.p.v. een nieuwe insert" - zo zou ik het tenminste zelf implementeren.

Dus elke keer dat je een object maakt met een expliciete key moet EF eerst in de database gaan kijken of dat object al dan niet al bestaat? Daar wordt het niet efficiënter van. Bovendien geef jij door te zeggen 'new X' eigenlijk al aan dat je bedoelt dat het een nieuw object moet zijn. EF is niet kut, jij maakt een heleboel verkeerde aannames.

[Alex)]

Korben schreef op woensdag 25 maart 2015 @ 16:13:
[...]
Dus elke keer dat je een object maakt met een expliciete key moet EF eerst in de database gaan kijken of dat object al dan niet al bestaat? Daar wordt het niet efficiënter van. Bovendien geef jij door te zeggen 'new X' eigenlijk al aan dat je bedoelt dat het een nieuw object moet zijn. EF is niet kut, jij maakt een heleboel verkeerde aannames.

Eigenlijk was het een object dat door een eerdere DbContext was opgehaald, ik had het hier wat versimpeld.

Laten we zeggen: Entity Framework is vast een heel degelijk product, maar ik vind het niet altijd even logisch werken. Er gebeurt zo nu en dan iets teveel magie naar mijn smaak.

[BikkelZ]

Binnenkort weer met C# / .Net aan de slag, één ASP.Net project, een Mac Mono app en een Xamarin app.

[kenneth]

MVC mag ik hopen voor je?

Ik zit tijdelijk op een WebForms-project. /me weent stilletjes

[Mercatres]

kenneth schreef op woensdag 25 maart 2015 @ 16:43:
MVC mag ik hopen voor je?

Ik zit tijdelijk op een WebForms-project. /me weent stilletjes

MVC is tof, WebAPI (wat hetzelfde is, in feite) nog fijner

[TheNephilim]

Vandaag eens met Grunt en Bower aan de slag gegaan! Hoewel het een boel tijd scheelt, is het nogal toveren om het een beetje netjes te krijgen.

[kenneth]

Mercatres schreef op woensdag 25 maart 2015 @ 16:44:
[...]

MVC is tof, WebAPI (wat hetzelfde is, in feite) nog fijner

Inderdaad, helemaal geen design-gedoe en echt alleen maar data overpompen

[Mercatres]

kenneth schreef op woensdag 25 maart 2015 @ 16:49:
[...]

Inderdaad, helemaal geen design-gedoe en echt alleen maar data overpompen

Design is voor loseurs

[BtM909]

TheNephilim schreef op woensdag 25 maart 2015 @ 16:48:
Vandaag eens met Grunt en Bower aan de slag gegaan! Hoewel het een boel tijd scheelt, is het nogal toveren om het een beetje netjes te krijgen.

Bower is leuk voor de opbouw. Laat Grunt links liggen ter faveure van GulpJS.

[Chris7]

TheNephilim schreef op woensdag 25 maart 2015 @ 16:48:
Vandaag eens met Grunt en Bower aan de slag gegaan! Hoewel het een boel tijd scheelt, is het nogal toveren om het een beetje netjes te krijgen.

Ik vind zelf Gulp fijner dan Grunt. Bower ben ik niet zo'n fan van, vond het de laatste keer dat ik het gebruikte meer werk om het goed in het proces te krijgen dan de benodigde libraries handmatig te downloaden.

[TheNephilim]

Ik kwam er zo bij omdat ik ~8 js bestanden onderin m'n HTML had staan en ik dit wilde samenvoegen in één bestand. Toen kwam ik weer op het punt dat updaten dan weer meer werk is en tjah dan is er Bower.

Heb het proces inmiddels wel staan zo ongeveer, het stelt hier ook niet heul veel voor. Maar inderdaad, waar laat je alles en hoe zet je het netjes weg.

Oké; Gulp kwam ik al een paar keer tegen, zal eens kijken wat ik daarmee kan!

[alienfruit]

Bower is vervelend omdat sommige components niet met een pre-build versie komen. Moet je als nog npm install / grunt build doen. Rete irritant.

[Caelorum]

kenneth schreef op woensdag 25 maart 2015 @ 16:43:
[...]
Ik zit tijdelijk op een WebForms-project. /me weent stilletjes

Ik verhoog het met een asp.net vb project dat zijn oorsprong vind in asp en toen is omgezet naar .net 1 en een DB in db design ^^

*edit* ik zou het verhaal erger kunnen maken, maar collega's... Daarnaast leer ik in dit bedrijf wel heel veel nog nooit zo goed moeten nadenken over sideeffects van mijn code en wijzigingen in de data. Het is echt te simpel om alles om te gooien.

[ Voor 28% gewijzigd door Caelorum op 25-03-2015 18:22 ]

[Douweegbertje]

Ik zie zoveel afkorting/termen/namen langskomen. Ik heb mij er zelf nooit echt in verdiept.. mede omdat ons project zoals vaker vermeld één groot ding is waarbij ik niet echt iets nieuws erin kan stoppen
Echter aan de andere kant heb ik zelf nog niet echt een goed gevoel om allerlei 'dependencies' erin te gooien, packages etc etc.
Heeft niemand wat naslagwerk omtrent deze onderwerpen eigenlijk? Gewoon puur op basis van hoe je het allemaal zou kunnen implementeren, wat het profijt er van is etc?


----------------------------------

Deze website is bedoeld voor eigen raadpleging via normaal browser-bezoek. Het is derhalve niet toegestaan om de website op geautomatiseerde wijze te (laten) raadplegen, bijvoorbeeld via scripts, spiders en/of bots.

Eventuele hyperlinks dienen bezoekers rechtstreeks te leiden naar de context, waarbinnen de publieke omroepen content aanbieden. Video- en audiostreams mogen bijvoorbeeld alleen worden vertoond via een link naar een omroeppagina of embedded omroepplayer. Overneming, inframing, herpublicatie, bewerking of toevoeging zijn niet toegestaan. Eveneens is het niet toegestaan technische beveiligingen te omzeilen of te verwijderen, of dit voor anderen mogelijk te maken.

http://www.npo.nl/robots.txt

[ Voor 43% gewijzigd door Douweegbertje op 25-03-2015 19:00 ]

[Alex)]

Vandaag een leuke performancewinst kunnen behalen door een LINQ-query met veel .Include()'s erin op te splitsen in een paar losse queries die de benodigde tabellen vullen, en de rest door EF's magie aan elkaar te knopen. En nog een foreach vervangen door Parallel.ForEach, wat ook nog eens 5 seconden tijdiwinst opleverde.

In totaal heb ik de processingtijd van een bepaald iets nagenoeg gehalveerd, terwijl ik amper iets heb gedaan.

Soms is die magie van EF toch best wel handig

[LEDfan]

alienfruit schreef op woensdag 25 maart 2015 @ 17:19:
Bower is vervelend omdat sommige components niet met een pre-build versie komen. Moet je als nog npm install / grunt build doen. Rete irritant.

Dit! Bower lijikt gewoon git repos to clonen ipv packages te downloaden (wat je van een package manager verwacht). Niet zo gek natuurlijk omdat er voor JS/CSS geen unifrome packages bestaan.
Ook vind ik het lastig dat er geen `bower update` command is. Wel voor elk package indivudeel AFAIK. En er is ook geen "DependencyUpToDateBadge"

Gebruik nu al een tijdje grunt om 20+ kleine AngularJS bestandjes te minifien naar 1 bestand, en hetzelfde met al de dependencies. Ook CSS en HTML templates worden geminified.

Enkel zeer lastig met git merge, dus ik heb de bestanden in .gitingore staan .

EDIT: en Grunt vs Guplp : http://markdalgleish.gith...build-wars-gulp-vs-grunt/

[ Voor 5% gewijzigd door LEDfan op 25-03-2015 19:18 ]

[Megamind]

Alex) schreef op woensdag 25 maart 2015 @ 19:01:
Vandaag een leuke performancewinst kunnen behalen door een LINQ-query met veel .Include()'s erin op te splitsen in een paar losse queries die de benodigde tabellen vullen, en de rest door EF's magie aan elkaar te knopen. En nog een foreach vervangen door Parallel.ForEach, wat ook nog eens 5 seconden tijdiwinst opleverde.

In totaal heb ik de processingtijd van een bepaald iets nagenoeg gehalveerd, terwijl ik amper iets heb gedaan.

Soms is die magie van EF toch best wel handig

Als het nog traag is kan je de queries in SQL Management Studio stoppen en er een execution plan van maken, kan je zien waar de traagheid zit.

[Alex)]

Megamind schreef op woensdag 25 maart 2015 @ 19:11:
[...]

Als het nog traag is kan je de queries in SQL Management Studio stoppen en er een execution plan van maken, kan je zien waar de traagheid zit.

Dat heb ik al gedaan, SSMS stelde voor om een paar indices toe te voegen. Dat hielp ook wel

[Mercatres]

Zo, m'n tweede PHP meetup ever. Ben benieuwd.

[Megamind]

Mercatres schreef op woensdag 25 maart 2015 @ 19:34:
Zo, m'n tweede PHP meetup ever. Ben benieuwd.

[Mercatres]

't Gaat over Doctrine migrations. Wat dus bijna hetzelfde is als EF Code First migrations. Dus niets echt nieuws.

[Ealanrian]

Even wat grafen maken en isomorphism aantonen, dit geeft best leuke afbeeldingen zoals:

Nog even het process wat alle verschillende isomorphismes berekend verbeteren en dit project is klaar.

[Avalaxy]

Alex) schreef op woensdag 25 maart 2015 @ 19:01:
Vandaag een leuke performancewinst kunnen behalen door een LINQ-query met veel .Include()'s erin op te splitsen in een paar losse queries die de benodigde tabellen vullen, en de rest door EF's magie aan elkaar te knopen. En nog een foreach vervangen door Parallel.ForEach, wat ook nog eens 5 seconden tijdiwinst opleverde.

In totaal heb ik de processingtijd van een bepaald iets nagenoeg gehalveerd, terwijl ik amper iets heb gedaan.

Soms is die magie van EF toch best wel handig

Ik heb vandaag het geheugengebruik van een server van 24GB naar 15GB gebracht

Bleek een bug in IIS te zijn.

[Alex)]

Mooie winst!

[TheNephilim]

https://www.digitalocean.com/ + http://wkhtmltopdf.org/ + https://github.com/mikehaertl/phpwkhtmltopdf = voor $5/mo PDFjes genereren

Maar nu toch maar eens naar huis

[ Voor 12% gewijzigd door TheNephilim op 25-03-2015 22:40 ]

[Douweegbertje]

TheNephilim schreef op woensdag 25 maart 2015 @ 22:38:
https://www.digitalocean.com/ + http://wkhtmltopdf.org/ + https://github.com/mikehaertl/phpwkhtmltopdf = voor $5/mo PDFjes genereren

Maar nu toch maar eens naar huis

De logica ontgaat mij enorm hard hier.

[TheNephilim]

Douweegbertje schreef op woensdag 25 maart 2015 @ 22:41:
[...]


De logica ontgaat mij enorm hard hier.

Gewoon het resultaat van een avondje prutsen Bestaande betaalde opties zijn vaak duurder (en niet onbeperkt). Gratis aanbieders vertrouw ik weer niet zomaar, zeker niet als er gevoelige informatie in de PDF zou staan.

Dus je maakt een 'droplet' aan bij DigitalOcean. Dan installeer je wkhtmltopdf, php/nginx/etc. Even een index.php bestandje maken met phpwkhtmltopdf erin en klaar!

[farlane]

TheNephilim schreef op woensdag 25 maart 2015 @ 22:38:
https://www.digitalocean.com/ + http://wkhtmltopdf.org/ + https://github.com/mikehaertl/phpwkhtmltopdf = voor $5/mo PDFjes genereren

Maar nu toch maar eens naar huis

Ik snap het niet, wat is hieraan 'beter' dan lokaal wkhtmltopdf draaien?

[Firesphere]

farlane schreef op woensdag 25 maart 2015 @ 23:17:
[...]


Ik snap het niet, wat is hieraan 'beter' dan lokaal wkhtmltopdf draaien?

Omdat't beter werkt zo, gok ik. Plus, lokaal draaien, PDF generatie is ruk.

[Merethil]

farlane schreef op woensdag 25 maart 2015 @ 23:17:
[...]


Ik snap het niet, wat is hieraan 'beter' dan lokaal wkhtmltopdf draaien?

Performancehit die je anders op je eigen systemen krijgt, en daarnaast kan je dan makkelijk één pak instellingen doen op één server in plaats van op elke server waar je het lokaal op gaat draaien.
Mij lijkt het wel handig.... Aan de andere kant: In ons geval zouden we in onze eigen servergroepen een server neerzetten die dan specifiek dit staat af te handelen. Niet goedkoper, wel nóg fijner gevoel qua veiligheid e.d.

[dcm360]

Gewoon hop een containertje erbij, praktisch geen kosten en het zit meteen achter de firewall. Wat dat betreft overigens, ik dacht dat containers draaien op een VPS van DigitalOcean wel kon. Scheelt weer de overhead van een hele VPS voor iets dat niet heel erg veel resources nodig heeft, maar toch de voordelen van isolatie.

[Devilly]

Internet Explorer has stopped working

Elke keer weer bij een bepaalde actie in onze applicatie in IE11. Het werkt in Chrome en Firefox en volgens mij werkte het ook in IE9.

[OkkE]

Stomme iOS dat geen background-attachment: fixed; ondersteund.

[TheNephilim]

farlane schreef op woensdag 25 maart 2015 @ 23:17:
[...]


Ik snap het niet, wat is hieraan 'beter' dan lokaal wkhtmltopdf draaien?

Misschien wil je hier met meerdere projecten gebruik van maken, dan zou je per project wkhtmltopdf moeten installeren. Vaak niet eens mogelijk bij 'gewone' webhosting.

[Mercatres]

Alright, Slack is wel tof.

[frG]

Welke colorpicker gebruiken jullie? gebruiker nu 1 in de browser, maar ben op zoek naar een goede voor windows, met shortcut toetsencombinatie..

[hylke94]

frG schreef op donderdag 26 maart 2015 @ 13:16:
Welke colorpicker gebruiken jullie? gebruiker nu 1 in de browser, maar ben op zoek naar een goede voor windows, met shortcut toetsencombinatie..

De laatste keer heb ik de afbeelding geopend in Paint.net. Daar kun je ook de kleuren uit halen.

[frG]

hylke94 schreef op donderdag 26 maart 2015 @ 13:18:
[...]


De laatste keer heb ik de afbeelding geopend in Paint.net. Daar kun je ook de kleuren uit halen.

Ja dat begrijp ik, maar is niet snel en efficiënt

[hylke94]

frG schreef op donderdag 26 maart 2015 @ 13:19:
[...]


Ja dat begrijp ik, maar is niet snel en efficiënt

Deze dan: ColorPix?

Edit: Google

[ Voor 15% gewijzigd door hylke94 op 26-03-2015 13:26 ]