De Devschuur Coffee Corner - Iteratie 3

[Verwijderd]

Pfff 1100 is wel boven budget

[Robbiedobbie]

Als ik de stoel op dat plaatje zie, lijkt hij me niet eens comfortabel zitten Een gevalletje design boven functionaliteit?

[Verwijderd]

Ben best trots op vakantie zonder laptop mee.. studie boeken zitten nog netjes in de tas ( hint van vriendin dat als ik ze er uithaal dat ze dan buiten liggen helpt best wel )

[BikkelZ]

Robbiedobbie schreef op vrijdag 09 augustus 2013 @ 20:24:
Als ik de stoel op dat plaatje zie, lijkt hij me niet eens comfortabel zitten Een gevalletje design boven functionaliteit?

Hangt van de bekleding af:



Ik vind dat oude vieze bruine leer ook wel lekker retro eigenlijk...



Of een namakertje uit China met zo'n meshrug

[SPee]

Oeh, die is mooi.

[dcm360]

Oja, natuurlijk geeft inArray een Number terug. Verklaart in ieder geval wel waarom mn code die met || onderzocht of een element in 1 van mn 2 lijsten zit wat raar deed.

[BikkelZ]

SPee schreef op vrijdag 09 augustus 2013 @ 23:04:
Oeh, die is mooi.

145 pond? Die had er vandaag al gestaan....

http://www.retailzone.com...office-chair---brown.html

[Cor453]

Ik programmeer gewoon op de vloer. Dát is pas een goeie stoel. Mis af en toe wel de rugleuning.

[mrc4nl]

Cor453 schreef op zaterdag 10 augustus 2013 @ 00:17:
Ik programmeer gewoon op de vloer. Dát is pas een goeie stoel. Mis af en toe wel de rugleuning.

tip: moet je eens met je buik op je bureau liggen en dan programmeren

[Cor453]

mrc4nl schreef op zaterdag 10 augustus 2013 @ 00:49:
[...]

tip: moet je eens met je buik op je bureau liggen en dan programmeren

Ja is dat prettig? Nooit geprobeerd eigenlijk, ik lig liever op m'n rug en dan m'n laptop zo schuin over m'n gezicht. Dat werkt pas echt fijn

[Firesphere]

Ik werk in het bloed van een ieder die me tegenstaat

spoiler:

Helaas is dat momenteel voornamelijk muggen- en fruitvliegbloed

[ Voor 40% gewijzigd door Firesphere op 10-08-2013 00:55 ]

[Cor453]

Firesphere schreef op zaterdag 10 augustus 2013 @ 00:55:
Ik werk in het bloed van een ieder die me tegenstaat

spoiler:

Helaas is dat momenteel voornamelijk muggen- en fruitvliegbloed

Fijn. Mogen we daar blij mee zijn? Als het nu maandagmorgen zou zijn dan zou ik je niet durven tegenspreken. Ik zou toch zweren dat ik mij dan bedreigd zou voelen. Alhoewel... krijg ik dan ook een plekje aan de muur

[Firesphere]

Cor453 schreef op zaterdag 10 augustus 2013 @ 00:57:
[...]


Fijn. Mogen we daar blij mee zijn? Als het nu maandagmorgen zou zijn dan zou ik je niet durven tegenspreken. Ik zou toch zweren dat ik mij dan bedreigd zou voelen. Alhoewel... krijg ik dan ook een plekje aan de muur

Mijn collega's zijn ook al tot de conclusie gekomen dat ik leef in een constante wens alles en iedereen dood te maken Dus, blijf maar uit de buurt. Tenzij je koffie hebt. Of bier. Of whisky.

[Cor453]

/me Heeft het bier net op...

Iets zegt mij dat ik nu begrijp waarom in doordeweeks de koffie de devschuur "ingeslingerd" wordt... Jij wilt er gewoon iets of iemand mee doodgooien he

[Firesphere]

Cor453 schreef op zaterdag 10 augustus 2013 @ 01:02:
/me Heeft het bier net op...

Iets zegt mij dat ik nu begrijp waarom in doordeweeks de koffie de devschuur "ingeslingerd" wordt... Jij wilt er gewoon iets of iemand mee doodgooien he

SSSSSSST!

[Cor453]

JONGUHS!! Ik heb de allergrootste wens van Firesphere ontdekt! Hij wil met een koffiekan iemands hoofd bashen! Wie biedt zich aan

[Firesphere]

Eh, iedereen weet dat ik zo sociaal als een stoeptegel ben.
En dan ook het liefst de betreffende stoeptegel tegen andermans hoofd aan laat klappen met flinke vaart
Jij bent nieuw hier?

(Nee, ik heb geen moordneigingen, maar ik ben wel zo sociaal/subtiel als een baksteen)

[ Voor 4% gewijzigd door Firesphere op 10-08-2013 01:09 ]

[Cor453]

Firesphere schreef op zaterdag 10 augustus 2013 @ 01:08:
Eh, iedereen weet dat ik zo sociaal als een stoeptegel ben.
En dan ook het liefst de betreffende stoeptegel tegen andermans hoofd aan laat klappen met flinke vaart

(Nee, ik heb geen moordneigingen, maar ik ben wel zo sociaal/subtiel als een baksteen)

Wat geeft dat nou. Je bent toch programmeur? Je gebruikt gewoon standaard het excuus dat je chagrijnig bent wegens te weinig koffie. Niemand die jou daarom zo bekritiseren of wel?

Beetje anders, maar in dezelfde categorie: als iemand langskomt die ik niet wil spreken dan doe ik gewoon heel achterlijk. Als die persoon dan later vraagt van: hoe zat het nou? Dan zeg ik gewoon: mwah... te weinig koffie.

[Firesphere]

Cor453 schreef op zaterdag 10 augustus 2013 @ 01:11:
[...]


Wat geeft dat nou. Je bent toch programmeur? Je gebruikt gewoon standaard het excuus dat je chagrijnig bent wegens te weinig koffie. Niemand die jou daarom zo bekritiseren of wel?

Beetje anders, maar in dezelfde categorie: als iemand langskomt die ik niet wil spreken dan doe ik gewoon heel achterlijk. Als die persoon dan later vraagt van: hoe zat het nou? Dan zeg ik gewoon: mwah... te weinig koffie.

Ik gebruik koffie nooit als excuus! Als iemand vraagt "Hoe zat dat nou" is't antwoord gewoon "Ik wil niet met jou praten".

En da's geen grapje, ik heb echt ultra-sociale skills.
Opmerkingen die ik te horen heb gekregen in de 4 maand dat ik voor m'n nieuwe baas werk:
> Jij haat gewoon echt alles.
> Je hebt zo'n prachtige blik, zo'n blik van "Hou nu eens je bek, ik ben aan het werk"
/ of de variatie
> "Als jij zo kijkt houden zelfs klanten hun mond en vragen ze of ze bang moeten zijn" (Ik zit zo'n 20 meter verderop, net buiten het zicht van de vergaderzaal)
> Jij bent niet anti-sociaal. Je bent gewoon een alleshater.
> Is er ook iets waar jij niet direct op reageert met "Tief op ik heb wel wat beters te doen"?

(En zo kan ik wel even door gaan)

---

Hmmm, zonder Minigun op m'n iPad houdt'ie het ongeveer 30 seconden langer vol. Zou ik dan toch een bugje hebben?

[Ealanrian]

Probeer je Facebook weer te slopen?

[Matis]

Pff, ik ben nog altijd op zoek naar de heilige graal hoe een datum netjes te printen.
Standaard doet date het zo:

za aug 10 13:31:00 CEST 2013

Naast het feit dat ik sws de maand en de dag om zou draaien, vind ik het nog steeds niet lekker lezen

[Firesphere]

Ealanrian schreef op zaterdag 10 augustus 2013 @ 10:13:
Probeer je Facebook weer te slopen?

Nee, ik was aan't proberen m'n iPad weer tot leven te brengen.

[Ealanrian]

De vliegenmepper iPad of heb je een nieuwe ook al weer gesloopt?

[Firesphere]

De nieuwe, die doet ook stuk zijn. Niet mijn schuld dit keer

[Cor453]

Ja ja. zeggen ze allemaal. Maar ondertussen?

[Ealanrian]

Er moest gewoon weer een vlieg sterven.

[Firesphere]

Nee, deze is echt uit eigen vrijwillige keuze dood gegaan

[ThomasG]

Firesphere schreef op zaterdag 10 augustus 2013 @ 14:49:
Nee, deze is echt uit eigen vrijwillige keuze dood gegaan

Hij zag de bui al hangen natuurlijk

[Verwijderd]

Toen de vlieg Firesphere's blik zag, verloor hij spontaan de wil om te leven.

[Firesphere]

[Styxxy]

Of de vlieg vloog spontaan onder de nieuwe iPad zodat hij dood ging .

[Verwijderd]

Levensgevaarlijke apparaten hoor, die apple dingen.

[Alex)]

Matis schreef op zaterdag 10 augustus 2013 @ 13:32:
Pff, ik ben nog altijd op zoek naar de heilige graal hoe een datum netjes te printen.
Standaard doet date het zo:

za aug 10 13:31:00 CEST 2013

Naast het feit dat ik sws de maand en de dag om zou draaien, vind ik het nog steeds niet lekker lezen

ISO 8601.

[ Voor 3% gewijzigd door Alex) op 10-08-2013 17:55 ]

[Verwijderd]

Alex) schreef op zaterdag 10 augustus 2013 @ 17:55:
[...]

ISO 8601.

Heb ik altijd de meest logische manier gevonden. Van groot naar klein sorteren, net zoals je bij tijd doet:
Jaar maand dag uur minuut seconde.

[Verwijderd]

Ik kreeg opeens een runtime error in een van mijn progsels. "invalid operator <". Die heb ik echt nog nooit gezien... Je zou denken dat dat soort errors wel compile time af te vangen zijn.

Edit: ahaa, er zit een assert in voor als je std::sort aanroept met een strict-weak ordering operator<.

[ Voor 22% gewijzigd door Verwijderd op 10-08-2013 22:08 ]

[Matis]

Verwijderd schreef op zaterdag 10 augustus 2013 @ 19:56:
Heb ik altijd de meest logische manier gevonden. Van groot naar klein sorteren, net zoals je bij tijd doet:
Jaar maand dag uur minuut seconde.

Wetenschappelijk gezien ben ik het met je eens, maar ik vind het niet prettig lezen. Zeker bij logfiles niet.

[Firesphere]

Matis schreef op zaterdag 10 augustus 2013 @ 23:39:
[...]

Wetenschappelijk gezien ben ik het met je eens, maar ik vind het niet prettig lezen. Zeker bij logfiles niet.

Niet??

Ik juist wel, vooral bij importeren!
Sort by column A than B than C than D than E than F

Instantly alles gesorteerd op jaar-maand-dag-uur-minuut-seconde

Hoe ideaal wil je't hebben?

[Firesphere]

Iemand hier een apple-fanboy? Ik mag mijn minigun/gattlingun app vrijgeven!

Ik heb alleen 1 klein probleempje.... de broncode staat op m'n backupdisk. Die ongeveer 10 minuten geleden compleet gecrasht is en met geen mogelijkheid weer tot leven te brengen....

[Megamind]

En je source repo is ook gecrashed?

[Firesphere]

Repo is private uiteraard. Dat is per definitie. Iets met niets vrij geven

Ik heb hier een hdd die niet wil opstarten, maar waar dus de hele minigun op staat. En ik heb de sourcecode verwijderd van m'n pc zelf dus.

Minigun is nog wel beschikbaar voor approved FB employees trouwens. En ondanks dat ik de minigun heb gemaakt, val ik nog niet in die categorie

[ Voor 26% gewijzigd door Firesphere op 11-08-2013 02:40 ]

[Megamind]

Maar je kan je source niet meer uit een centrale repo halen? Ik werk zelf met SVN dus alles staat op een SVN server. Als je alleen lokaal GIT of Mercury gebruikt dan wordt het lastig.

[Firesphere]

Megamind schreef op zondag 11 augustus 2013 @ 02:46:
Maar je kan je source niet meer uit een centrale repo halen? Ik werk zelf met SVN dus alles staat op een SVN server. Als je alleen lokaal GIT of Mercury gebruikt dan wordt het lastig.

Misschien zegt "private repo" iets
Ik kan de broncode wel terug halen, maar die is niet gelijk aan de minigun die ik mag publiceren.

[ Voor 12% gewijzigd door Firesphere op 11-08-2013 02:50 ]

[Megamind]

Wat is het probleem dan?

[Firesphere]

lees nog eens wat ik zeg?

Ja, ik kan bij de private repository, maar de huidige minigun mag ik niet vrijgeven, ik mag alleen de public vrijgeven. Wat daar bovenop zit wat ik evt. mag vrijgeven, staat wel in de repo, maar ik weet niet wat er wel en niet mag.

Ik mag minigun ook niet publiek maken zelf. Iets met een NDA enzo

[Megamind]

Maar op je gecrashde HDD staat een versie die je wel mag vrijgeven?

[Firesphere]

Ja, ga jij nu mijn harddisk redden? 2TB aan platterdisks.

[Megamind]

Nope

[Firesphere]

Megamind schreef op zondag 11 augustus 2013 @ 02:59:
Nope

Hmmmm....Ook niet als ik er voor betaal?

Nee, deze disk is gecrasht en dat is gewoon kut voor mij. De raid heeft niet op tijd de boel kunnen bijwerken omdat de disk crashte bij de write. Tenminste, dat is wat ik uit de error-logs haal.

Of het echt een write-error was doet er niet heel veel toe, aangezien ik nog steeds "nope, no way" zal zeggen op een verzoek om mijn hdd's te onderzoeken.

Pluspunt, dit was de laatste set met platters, vanaf nu heb ik alleen nog maar SSD's

[Megamind]

Ik gebruik alleen nog HDD's voor m'n Xbox en Wii Heb nog een 3TB als noodbackup liggen maar de rest staat als ZFS raid thuis en alle belangrijke dingen worden naar de Amazon cloud gesynct (kost me wel 1 USD per maand!).

[Verwijderd]

Je kan zien dat het vandaag zondag is. Het is al 9 uur geweest en nog niemand heeft om koffie geschreeuwd.

[Verwijderd]

*Stiekem een bakje zet in de hoop dat Fir3SpH3re me niet zal doodkijken straks*
Jij ook Darkstone?

[Robbiedobbie]

Verwijderd schreef op zondag 11 augustus 2013 @ 11:01:
*Stiekem een bakje zet in de hoop dat Fir3SpH3re me niet zal doodkijken straks*
Jij ook Darkstone?

Fir3SpH3re kijkt iedereen dood Er is een reden waarom alle ipads, harde schijven en vliegen sterven daar!

[alienfruit]

Als je in een private repo is het toch geen probleem? Gewoon terug na de tag/branch met die code ?

[Ealanrian]

Ik was onderweg en had dus geen tijd om om koffie te schreeuwen .
Om half 10 een bespreking op zondag op drie kwartier rijden was toch een beetje slechte planning.

[ Voor 43% gewijzigd door Ealanrian op 11-08-2013 15:31 ]

[azerty]

Het is hier wel rustig vandaag

[Alex)]

Afgelopen nacht heb ik -eindelijk- eens wat tijd gemaakt om te spelen met Entity Framework Code First (5.0.0) i.c.m. ASP.NET Web API 2. Het had even wat voeten in de aarde om alles werkend te krijgen, maar ik kan nu wel zulke requests afvuren:
GET /api/v1/users/38/subscriptions.json
PUT /api/v1/users/38/subscriptions/24
DELETE /api/v1/users/38/subscriptions/19

[Ealanrian]

Zo jammer dit:

C:

static const char * const BUNDLE = "bundle";
static const char * const BUNDLE_ID = "bundle.id";
static const char * const BUNDLE_SIGNER = "bundle.signer";
static const char * const BUNDLE_SYMBOLICNAME = "bundle.symbolicName";
static const char * const BUNDLE_VERSION = "bundle.version";

Op alfabetische volgorde ziet het er niet mooi uit, op lengte word het weer lelijk omdat het niet op alfabet staat...

[Verwijderd]

Tabs ertussen zodat de = aligned staan

[Ealanrian]

Ook dat is lelijk want de values komen dan niet mooi op lijn . Achja ik zal er maar mee moeten leren leven denk ik

[pedorus]

Ik vind het vooral jammer dat je een constante introduceert voor een string die je waarschijnlijk maar 1 keer wordt gebruikt. Wordt de code niet leesbaarder door. Zelfs al zou de string ooit wijzigen, dan ziet het er niet uit:

C:

static const char * const BUNDLE_SYMBOLICNAME = "details.name.symbolic"; 

[Avalaxy]

Alex) schreef op zondag 11 augustus 2013 @ 18:52:
Afgelopen nacht heb ik -eindelijk- eens wat tijd gemaakt om te spelen met Entity Framework Code First (5.0.0) i.c.m. ASP.NET Web API 2. Het had even wat voeten in de aarde om alles werkend te krijgen, maar ik kan nu wel zulke requests afvuren:
GET /api/v1/users/38/subscriptions.json
PUT /api/v1/users/38/subscriptions/24
DELETE /api/v1/users/38/subscriptions/19

Hoe doe jij je versioning met web api? Is dat makkelijker geworden in V2?

[Verwijderd]

pedorus schreef op zondag 11 augustus 2013 @ 20:08:
Ik vind het vooral jammer dat je een constante introduceert voor een string die je waarschijnlijk maar 1 keer wordt gebruikt. Wordt de code niet leesbaarder door. Zelfs al zou de string ooit wijzigen, dan ziet het er niet uit:

C:

static const char * const BUNDLE_SYMBOLICNAME = "details.name.symbolic"; 

De constante introduceert een handige manier om alles in 1x te renamen met ctrl-f of vergelijkbare acties. Je weet nooit waar die string verder nog wordt gebruikt...

[Alex)]

Avalaxy schreef op zondag 11 augustus 2013 @ 20:09:
[...]


Hoe doe jij je versioning met web api? Is dat makkelijker geworden in V2?

Bij Web API V1 kun je gebruikmaken van de IHttpControllerSelector-service om te bepalen welke controller geladen moet worden. Je kunt dan bijvoorbeeld namespaces gebruiken om dat te bepalen: Implementing API versioning in ASP.NET Web API.

Bij ASP.NET Web API V2 zit Attribute-based routing standaard ingebakken, ik heb daar gebruik van gemaakt bij het opzetten van mijn controllers. De controller/action/id-based routes die er standaard in zitten zijn voor mijn gevoel net iets te inflexibel.

[Ealanrian]

pedorus schreef op zondag 11 augustus 2013 @ 20:08:
Ik vind het vooral jammer dat je een constante introduceert voor een string die je waarschijnlijk maar 1 keer wordt gebruikt. Wordt de code niet leesbaarder door. Zelfs al zou de string ooit wijzigen, dan ziet het er niet uit:

C:

static const char * const BUNDLE_SYMBOLICNAME = "details.name.symbolic"; 

Aangezien dit deel is van een public header die gebruikt gaat worden om services aan te spreken zullen ze vrij veel gebruikt worden verwacht ik. En daar komt bij het is deel van de spec (OSGi) waar ik helaas geen inspraak in heb.

[drm]

pedorus:
Ik vind het vooral jammer dat je een constante introduceert voor een string die je waarschijnlijk maar 1 keer wordt gebruikt. Wordt de code niet leesbaarder door. Zelfs al zou de string ooit wijzigen, dan ziet het er niet uit:

C:

static const char * const BUNDLE_SYMBOLICNAME = "details.name.symbolic"; 

Het wordt imo juist leesbaarder omdat de intentie duidelijker zichtbaar wordt. Als je een string constant "as is" gebruikt is niet duidelijk dat het iets bijzonders betekent. Als je er een symbol van maakt wel.

[pedorus]

Verwijderd schreef op zondag 11 augustus 2013 @ 20:14:
De constante introduceert een handige manier om alles in 1x te renamen met ctrl-f of vergelijkbare acties. Je weet nooit waar die string verder nog wordt gebruikt...

Je hoeft mij niet uit te leggen waar een constante voor dient Maar stel je hebt bijvoorbeeld properties:

Java:

    Properties props = new Properties();
    props.put("bundle.version", "3.1.0");

Dan zie ik daar liever niet het volgende:

Java:

public static final String BUNDLE_VERSION = "bundle.version";
[...]
    props.put(BUNDLE_VERSION, "3.1.0");

Want daar wordt de code echt niet leesbaarder of beter door. En mocht je het later alsnog willen, dan is het letterlijk 3 klikken met de muis. Zie ook http://thedailywtf.com/Articles/Soft_Coding.aspx

[Avalaxy]

Alex) schreef op zondag 11 augustus 2013 @ 20:18:
[...]


Bij Web API V1 kun je gebruikmaken van de IHttpControllerSelector-service om te bepalen welke controller geladen moet worden. Je kunt dan bijvoorbeeld namespaces gebruiken om dat te bepalen: Implementing API versioning in ASP.NET Web API.

Bij ASP.NET Web API V2 zit Attribute-based routing standaard ingebakken, ik heb daar gebruik van gemaakt bij het opzetten van mijn controllers. De controller/action/id-based routes die er standaard in zitten zijn voor mijn gevoel net iets te inflexibel.

Nice Tijdens de beta van V1 liepen we er tegenaan met een schoolproject. Toen was het vrij omslachtig.

[PrisonerOfPain]

Verwijderd schreef op zondag 11 augustus 2013 @ 19:11:
Tabs ertussen zodat de = aligned staan

En dat is weer kut met merges en toekomstige edits.

[BikkelZ]

pedorus schreef op zondag 11 augustus 2013 @ 20:08:
Ik vind het vooral jammer dat je een constante introduceert voor een string die je waarschijnlijk maar 1 keer wordt gebruikt. Wordt de code niet leesbaarder door. Zelfs al zou de string ooit wijzigen, dan ziet het er niet uit:

C:

static const char * const BUNDLE_SYMBOLICNAME = "details.name.symbolic"; 

Als iemand "waarschijnlijk" gaat zeggen word ik al meteen achterdochtig

[Ealanrian]

pedorus schreef op zondag 11 augustus 2013 @ 20:55:
[...]

Je hoeft mij niet uit te leggen waar een constante voor dient Maar stel je hebt bijvoorbeeld properties:

Java:

    Properties props = new Properties();
    props.put("bundle.version", "3.1.0");

Dan zie ik daar liever niet het volgende:

Java:

public static final String BUNDLE_VERSION = "bundle.version";
[...]
    props.put(BUNDLE_VERSION, "3.1.0");

Want daar wordt de code echt niet leesbaarder of beter door. En mocht je het later alsnog willen, dan is het letterlijk 3 klikken met de muis. Zie ook http://thedailywtf.com/Articles/Soft_Coding.aspx

Nu grijp ik even puur terug op kennis van C wat we ooit een keer in de lessen hebben gehad dus in mijn volgende stuk kunnen fouten zitten maar hoe het volgens mij dus is:

C:

static const char * const BUNDLE_SYMBOLICNAME = "details.name.symbolic";

Dit maakt een pointer (BUNDLE_SYMBOLICNAME) die een constant is en dus niet kan veranderen, maar de value (details.name.symbolic) kan veranderen. Hier door kan ik dus in mijn C code de property ophalen op basis van de pointer in plaats van een string compare doen.

Nogmaals ik ben niet 100% zeker van deze uitleg maar ik vermoed dat dit de reden is waarom het zo is gedaan. Als ik het fout heb hoor ik het graag want dan leer ik weer

--edit--
Dit in combinatie met het feit dat er meerdere bundles zullen zijn die gebruik gaan maken van de event admin zal het waarschijnlijk worden dat deze vaker gebruikt gaat worden. Ja BikkelZ ook hier waarschijnlijk

[ Voor 7% gewijzigd door Ealanrian op 11-08-2013 23:17 ]

[Matis]

PrisonerOfPain schreef op zondag 11 augustus 2013 @ 21:49:

En dat is weer kut met merges en toekomstige edits.

Om nog maar te zwijgen over hoe text editors omgaan met tabs.

[.oisyn]

Ealanrian schreef op zondag 11 augustus 2013 @ 23:13:
maar de value (details.name.symbolic) kan veranderen.

Hoe dan? Een string literal is ook const.

Hier door kan ik dus in mijn C code de property ophalen op basis van de pointer in plaats van een string compare doen.

Helaas, hij is static. Elke translation unit kan dus zijn eigen pointer krijgen. Als je dat op die manier wilt doen dan moet je een extern const char[] definieren.

[BikkelZ]

Ealanrian schreef op zondag 11 augustus 2013 @ 23:13:

Dit in combinatie met het feit dat er meerdere bundles zullen zijn die gebruik gaan maken van de event admin zal het waarschijnlijk worden dat deze vaker gebruikt gaat worden. Ja BikkelZ ook hier waarschijnlijk

Niet voor niks mijn onderschrift al jaren!

[Alex)]

Ik lees verschillende dingen over het gebruik van DbContext:

- Gebruik 'm zo kort mogelijk, bijvoorbeeld in een using-statement
- Gebruik 'm binnen een instance van een class, en dispose 'm daarna, maar maak 'm niet static, want de DbContext gaat steeds meer geheugen innemen
- "Je kunt 'm gerust static maken"

Een reden om een DbContext static te maken zou zijn om de uitvoertijd van requests omlaag te brengen (wat bij Web API wel fijn is) omdat de DbContext dan niet iedere keer geïnitialiseerd hoeft te worden, maar ik weet niet zo goed of dit nou aan te raden is of niet.

[Avalaxy]

Lees dit maar: http://blog.jongallant.co...dispose-on-dbcontext.html

Ik laat hem zelf per request leven, dus hij wordt wel regelmatig gedisposed, maar niet eke keer als ik hem eventjes niet nodig heb.

[ Voor 42% gewijzigd door Avalaxy op 12-08-2013 00:39 ]

[Kips]

zo, weer terug van vakantie...

* Kips zegt hallo allemaal!

[Geerrrt]

Eindelijk weer lekkere leverworst!

[Sebazzz]

Alex) schreef op maandag 12 augustus 2013 @ 00:33:
Een reden om een DbContext static te maken zou zijn om de uitvoertijd van requests omlaag te brengen (wat bij Web API wel fijn is) omdat de DbContext dan niet iedere keer geïnitialiseerd hoeft te worden

Zo duur is dat echter niet. EF's equivalent van NHibernate's SessionFactory wordt onder de motorkap maar slechts één keer per application domain geinitialiseerd.

[Woy]

Alex) schreef op maandag 12 augustus 2013 @ 00:33:
Ik lees verschillende dingen over het gebruik van DbContext:

- Gebruik 'm zo kort mogelijk, bijvoorbeeld in een using-statement
- Gebruik 'm binnen een instance van een class, en dispose 'm daarna, maar maak 'm niet static, want de DbContext gaat steeds meer geheugen innemen
- "Je kunt 'm gerust static maken"

Een reden om een DbContext static te maken zou zijn om de uitvoertijd van requests omlaag te brengen (wat bij Web API wel fijn is) omdat de DbContext dan niet iedere keer geïnitialiseerd hoeft te worden, maar ik weet niet zo goed of dit nou aan te raden is of niet.

Het initialiseren van een DbContext zal alleen de eerste keer "zwaar" zijn. Daarna is het een redelijk eenvoudige object allocatie. Je moet vooral kijken hoe je je DbContext gebruikt, in feite is het gewoon een implementatie van het Unit of Work pattern, en dat is dan ook hoe ik hem zou gebruiken. Binnen een webapplicatie is het dus vaak dat je er per request een aan (laat) maken.

Sebazzz schreef op maandag 12 augustus 2013 @ 08:09:
[...]

Zo duur is dat echter niet. EF's equivalent van NHibernate's SessionFactory wordt onder de motorkap maar slechts één keer per application domain geinitialiseerd.

DbContext lijkt dan ook meer op een (N)Hibernate Session

[ Voor 13% gewijzigd door Woy op 12-08-2013 08:18 ]

[Ealanrian]

.oisyn schreef op maandag 12 augustus 2013 @ 00:21:
[...]

Hoe dan? Een string literal is ook const.


[...]

Helaas, hij is static. Elke translation unit kan dus zijn eigen pointer krijgen. Als je dat op die manier wilt doen dan moet je een extern const char[] definieren.

Bedankt voor de uitleg, weer wat geleerd . Ik vond mijn uitleg al raar klinken vanochtend, misschien toch nog eens dat boek open slaan..

En goedemorgen mensen

[ Voor 13% gewijzigd door Ealanrian op 12-08-2013 08:48 ]

[PrisonerOfPain]

Ealanrian schreef op maandag 12 augustus 2013 @ 08:44:
[...]

Bedankt voor de uitleg, weer wat geleerd . Ik vond mijn uitleg al raar klinken vanochtend, misschien toch nog eens dat boek open slaan..

En goedemorgen mensen

Als je ze toch zo wil gebruiken, waarom is het dan geen enum met een losse toString functie?

[Robbiedobbie]

Goedemorgen allemaal!

Today is a good day
Op mijn traject met trein zou koperdiefstal zijn waardoor geen treinen rijden. Op de een of andere manier rijdt de trein die ik moet pakken wel gewoon

[GateKeaper]

Alex) schreef op maandag 12 augustus 2013 @ 00:33:
Ik lees verschillende dingen over het gebruik van DbContext:

- Gebruik 'm zo kort mogelijk, bijvoorbeeld in een using-statement
- Gebruik 'm binnen een instance van een class, en dispose 'm daarna, maar maak 'm niet static, want de DbContext gaat steeds meer geheugen innemen
- "Je kunt 'm gerust static maken"

Een reden om een DbContext static te maken zou zijn om de uitvoertijd van requests omlaag te brengen (wat bij Web API wel fijn is) omdat de DbContext dan niet iedere keer geïnitialiseerd hoeft te worden, maar ik weet niet zo goed of dit nou aan te raden is of niet.

Ik gebruik 'm zelf gewoon zo lang mogelijk. Pas hij het recyclen van de application in IIS komt de DbContext te vervallen. Heb er nooit problemen mee gehad, zou dus ook niet weten waarom ik dat zou moeten veranderen.

[Douweegbertje]

Heb al zelf ff koffie gepakt hoor F!reSph3re. Had ik wel even nodig op deze ochtend

[farlane]

Robbiedobbie schreef op maandag 12 augustus 2013 @ 09:14:
Goedemorgen allemaal!

Today is a good day
Op mijn traject met trein zou koperdiefstal zijn waardoor geen treinen rijden. Op de een of andere manier rijdt de trein die ik moet pakken wel gewoon

Denk dat ze het gewoon even zonder veiligheidssysteem doen. Wat kan er nou helemaal gebeuren?

[D-Raven]

God wat lag mn bed goed vanmorgen...

Misschien had ik gisterenavond toch maar wat eerder moeten stoppen met die Star Trek mod voor Sins .

[D-Raven]

GateKeaper schreef op maandag 12 augustus 2013 @ 09:25:
[...]


Ik gebruik 'm zelf gewoon zo lang mogelijk. Pas hij het recyclen van de application in IIS komt de DbContext te vervallen. Heb er nooit problemen mee gehad, zou dus ook niet weten waarom ik dat zou moeten veranderen.

Is het niet zo dat de DbContext instances tracked en daarmee instanties van je entities vasthoud ? Meen me te herinneren dat het dmv EventHandlers koppelingen voorkomt dat entities daadwerkelijk door de GC worden opgeruimd, en dat je daardoor een memory leak creeert.

Iets wat je met ObjectTrackingEnabled=false op kunt lossen, of door je DbContext te disposen..

Maargoed, dit was met vorige versies van EF, weet niet zeker of dit nu nog steeds een probleem is. Zo vaak gebruik ik EF niet, en als ik het gebruik dan is dat eigenlijk altijd in het 1 context per request patroon.

[Ealanrian]

PrisonerOfPain schreef op maandag 12 augustus 2013 @ 09:09:
[...]


Als je ze toch zo wil gebruiken, waarom is het dan geen enum met een losse toString functie?

Ik had natuurlijk even google kunnen gebruiken voor direct het juiste antwoord...
Zoals pedorus al zei word het wel gebruikt.

[b]pedorus schreef op zondag 11 augustus 2013 @ 20:55:

Java:

public static final String BUNDLE_VERSION = "bundle.version";
[...]
    props.put(BUNDLE_VERSION, "3.1.0");

Want daar wordt de code echt niet leesbaarder of beter door. En mocht je het later alsnog willen, dan is het letterlijk 3 klikken met de muis. Zie ook http://thedailywtf.com/Articles/Soft_Coding.aspx

De reden waarom er statics worden gebruikt is de architectuur in OSGi. Hierbij word een applicatie opgedeeld in verschillende bundles en elke bundle heeft een hele set aan properties zoals de bundle version maar ook dingen als welke interfaces er beschikbaar zijn als remote service.

OSGi is dus al aangekomen bij het punt "mocht je het later alsnog willen". Ik heb nog een hoop te leren maarja daarvoor ben ik nog jong

[Firesphere]

Zo. Koffie?

[GateKeaper]

D-Raven schreef op maandag 12 augustus 2013 @ 09:32:
[...]
Is het niet zo dat de DbContext instances tracked en daarmee instanties van je entities vasthoud ? Meen me te herinneren dat het dmv EventHandlers koppelingen voorkomt dat entities daadwerkelijk door de GC worden opgeruimd, en dat je daardoor een memory leak creeert.

Iets wat je met ObjectTrackingEnabled=false op kunt lossen, of door je DbContext te disposen..

Maargoed, dit was met vorige versies van EF, weet niet zeker of dit nu nog steeds een probleem is. Zo vaak gebruik ik EF niet, en als ik het gebruik dan is dat eigenlijk altijd in het 1 context per request patroon.

Weet zo uit mijn hoofd even niet meer hoe het exact is ingeregeld, maar mijn DbContext wordt geïnitialiseerd door Autofac, en die houdt zo'n application scope sessie vast.

Die fout die je noemt heb ik wel eens binnen een request sessie gehad doordat reeds gelade entities weer werden "gebind", maar niet tussen verschillende requests in. Dit was in mijn geval echt een fout van mijzelf, doordat ik "offline" entities terug wou verbinden aan de context voordat ik ze ging saven, terwijl ze al in de context geladen waren.

Memory leaks heb ik geen last van. Geheugen verbruik is gedurende de 24 uur (application recycle) gewoon stabiel.

[Solopher]

Lekker bakkie!

Laatste week voor mijn vakantie :d. Laatste vakantie was eind januari. Deze week maar eens besteden om lopende punten af te ronden.

[Ealanrian]

1 vakantie per jaar is toch al zat?

[Alex)]

Ealanrian schreef op maandag 12 augustus 2013 @ 10:01:
1 vakantie per jaar is toch al zat?

Nee?

[D-Raven]

GateKeaper schreef op maandag 12 augustus 2013 @ 09:55:
[...]


Weet zo uit mijn hoofd even niet meer hoe het exact is ingeregeld, maar mijn DbContext wordt geïnitialiseerd door Autofac, en die houdt zo'n application scope sessie vast.

Ah, maar dat is iets anders als dat je hier zei:

Pas hij het recyclen van de application in IIS komt de DbContext te vervallen.

Waarschijnlijk heb je bij de autofac registratie gezegd: InstancePerHttpRequest dan wordt het aan het einde van de httprequest weer opgeruimd. Tenminste, ik neem aan dat het niet als een SingleInstance() geregistreerd wordt.

Die fout die je noemt heb ik wel eens binnen een request sessie gehad doordat reeds gelade entities weer werden "gebind", maar niet tussen verschillende requests in. Dit was in mijn geval echt een fout van mijzelf, doordat ik "offline" entities terug wou verbinden aan de context voordat ik ze ging saven, terwijl ze al in de context geladen waren.

Memory leaks heb ik geen last van. Geheugen verbruik is gedurende de 24 uur (application recycle) gewoon stabiel.

Ik noemde niet echt een fout, meer een probleem. Ik ben nog even aan het graven gegaan. En het gebeurd nog steeds. De DbContext gebruikt INotifyPropertyChanged e.d. om changes op je entiteit te tracken zodat het efficient updates e.d. kan uitvoeren. Deze eventhandler registraties worden pas opgeruimd als je dbcontext disposed wordt.
Dus als je je dbcontext per request gebruikt is het prima. Maar als je een static ref bijhoud of iets van een singleton patroon toepast, dan ga je een probleem krijgen.

Maar als jij inderdaad offline entities gaat binden naar je context dan zul je hoogstwaarschijnlijk gewoon een per request patroon toepassen omdat je anders continue meldingen krijgt dat het entiteit al gebind is (vanuit de vorige request oid).

tldr; Het zal wel goed zijn

[OkkE]

Ealanrian schreef op maandag 12 augustus 2013 @ 10:01:
1 vakantie per jaar is toch al zat?

Als ik meer vrije dagen* zou hebben, was ik zeker 2x per jaar gegaan.

*) Mijn vakanties zijn gemiddeld een maand lang.

[Ealanrian]

OkkE schreef op maandag 12 augustus 2013 @ 10:05:
[...]

Als ik meer vrije dagen* zou hebben, was ik zeker 2x per jaar gegaan.

*) Mijn vakanties zijn gemiddeld een maand lang.

Kan je geen vrije dagen bij kopen ofzo? en twee keer per jaar 1 maand op vakantie, ik zou niet eens weten waar ik zo lang heen moet . 1 keer in de 2 jaar een week of 2 vind ik al wel zat eigenlijk

[Woy]

Ealanrian schreef op maandag 12 augustus 2013 @ 10:07:
[...]

Kan je geen vrije dagen bij kopen ofzo? en twee keer per jaar 1 maand op vakantie, ik zou niet eens weten waar ik zo lang heen moet . 1 keer in de 2 jaar een week of 2 vind ik al wel zat eigenlijk

Ja als student zijnde wel, maar ik merk toch wel dat ik ondertussen wel wat meer vakantie kan gebruiken. Ik ben nu net door mijn vakantiedagen van vorig jaar heen, maar even een weekje er tussenuit was toch wel erg nodig.

[GateKeaper]

D-Raven schreef op maandag 12 augustus 2013 @ 10:03:
[...]
Waarschijnlijk heb je bij de autofac registratie gezegd: InstancePerHttpRequest dan wordt het aan het einde van de httprequest weer opgeruimd. Tenminste, ik neem aan dat het niet als een SingleInstance() geregistreerd wordt.

Nee, het is niet de InstancePerHttpRequest, ben de naam even kwijt, dat zou ik moeten opzoeken. Maar het komt neer op InstancePerApplicationRecycle.

Ik noemde niet echt een fout, meer een probleem. Ik ben nog even aan het graven gegaan.

Snap ik

Maar als jij inderdaad offline entities gaat binden naar je context dan zul je hoogstwaarschijnlijk gewoon een per request patroon toepassen omdat je anders continue meldingen krijgt dat het entiteit al gebind is (vanuit de vorige request oid).

Jup, en dat doe ik dus ook niet meer. Begreep toen dat ik niet hoefde te binden als je ergens anders in dezelfde request de entities al ophaald. Mijn gevoel zegt alleen, dat als een singleton principe wat ik dus eigenlijk via Autofac heb (voor mijn gevoel) een probleem zou zijn, dat ik diezelfde soort fouten dan tussen de verschillende request ook zou moeten hebben. Maar dat gebeurd niet.

Ik ga nu een gevaarlijke aanname doen, maar ik denk dat SaveChanges ook het een en ander released ofzo. Wat ik op drukke momenten wel merk, is dat er Concurrency problemen op kunnen treden.

Gebruiker A laad entity X, voert wijzigingen door, gebruiker B laad entity X, voert wijzigingen door, en gebruiker A slaat deze op. Gebruiker B krijgt nu een concurrency probleem. Gelukkig is dit met EF vrij eenvoudig af te vangen. Kwestie van een "lastmodified" veld toevoegen, en die markeren als concurrency-check-field.

[Woy]

@GateKeaper: Ik zou toch nog eens goed naar je implementatie kijken, zover ik weet is DbContext niet thread safe, dus als jij 1 instantie deelt met alle requests kan dat heel goed concurrency problemen opleveren ja. Het LastModified field is niet de oplossing die je wil hebben voor dit probleem, maar is alleen een oplossing tegen meerdere DbContext'en die tegelijkertijd het object willen updaten.

[OkkE]

Ealanrian schreef op maandag 12 augustus 2013 @ 10:07:
[...]

Kan je geen vrije dagen bij kopen ofzo? en twee keer per jaar 1 maand op vakantie, ik zou niet eens weten waar ik zo lang heen moet . 1 keer in de 2 jaar een week of 2 vind ik al wel zat eigenlijk

Dagen kopen gaat me dan weer net te ver.

Enne, waar naar toe is (voor mij) echt geen probleem; er zijn nog zo veel landen in de wereld waar ik niet geweest ben. En een maand om een land te ontdekken is ook helemaal niet veel, is mijn ervaring.