De Devschuur Coffee Corner - Iteratie 2

[Matis]

Alex) schreef op dinsdag 11 oktober 2011 @ 13:31:
Ik zit as we speak bij een klant in Amsterdam, ik woon in Breda. Gelukkig hebben we tegenwoordig de Fyra die me in 65 minuten van station tot station brengt.

ALS de Fyra rijdt en ALS hij op volle snelheid rijdt is het prima vertoeven. Laatst de Fyra van Breda naar Amsterdam, uiteindelijk bijna net zo lang over gedaan als dat we over Den Bosch waren gegaan.

[Ram0n]

Hier zo'n 75km afstand op dit moment naar de klant, en op goede dagen doe ik daar 50 minuten over van huis naar een bureau. Op slechte dagen... De A2 is een stuk beter geworden nu, maar ik vrees erg voor het laatste deel van de herst en de winter op de A59.

[PeterSelie]

Dan ben ik toch echt verwend met een 25 minuten reistijd van Amersfoort of Utrecht naar Hilversum..

[Rutix]

Ik reis elke dag 62 km . Prima te doen imo. Amersfoort -> Amsterdam. A1 Is veel beter geworden sinds ze die spitsstrook hebben.

[Alex)]

Rutix schreef op dinsdag 11 oktober 2011 @ 13:43:
[...]

ik vind 65 minuten best meevallen maar rijd die Fyra nog een beetje lekker of is het vaak druk?

Matis schreef op dinsdag 11 oktober 2011 @ 13:43:
[...]

ALS de Fyra rijdt en ALS hij op volle snelheid rijdt is het prima vertoeven. Laatst de Fyra van Breda naar Amsterdam, uiteindelijk bijna net zo lang over gedaan als dat we over Den Bosch waren gegaan.

Ik heb ook wel eens +70 meegemaakt met de Fyra, we waren toen terechtgekomen achter een gestrande trein die geëvacueerd werd, en we konden niet meer van de HSL af. Ook wel eens +20 gehad omdat de treindienstleider een fout maakte en de Fyra in de richting van Roosendaal stuurde ipv Rotterdam.

Maar over het algemeen rijdt hij goed door, en ik heb ook altijd een zitplek

[Hoogie2004]

3,5 uur gezocht naar waarom de refinement van 1 property niet werkt in SharePoint 2010
Staat het vinkje 'Allow this property to be used in scopes' op de managed property uit

Nu nog even een powershell scriptje om dat te fixen

[Rutix]

Poor Hoogie :< . Suckt altijd als het zulke stomme kleine dingetjes zijn.

[Hoogie2004]

Rutix schreef op dinsdag 11 oktober 2011 @ 14:20:
Poor Hoogie :< . Suckt altijd als het zulke stomme kleine dingetjes zijn.

Dit zijn idd echt precies de dingen in SharePoint waar je helemaal simpel van wordt. Eerst de hele refinements definitie in xml uitspitten e.d. en dan is het zoiets waar je overheen kijkt...

1 voordeel, volgende keer dat het niet werkt, is dit het eerste wat je kijkt

[Rutix]

Hoogie2004 schreef op dinsdag 11 oktober 2011 @ 14:25:
[...]

Dit zijn idd echt precies de dingen in SharePoint waar je helemaal simpel van wordt. Eerst de hele refinements definitie in xml uitspitten e.d. en dan is het zoiets waar je overheen kijkt...

1 voordeel, volgende keer dat het niet werkt, is dit het eerste wat je kijkt

The best way to learn is the hard way .

[.Gertjan.]

Rutix schreef op dinsdag 11 oktober 2011 @ 14:27:
[...]

The best way to learn is the hard way .

Dat is een mooie, die kan ik mooi gebruiken in mijn overdracht naar een collega
Daarnaast kan ik hem ook introduceren in de schone kunst der software-archeologie
Die opmerking komt ook hier vandaan

[YopY]

Jeuj promotie / contract onbepaalde tijd

[ValHallen]

YopY schreef op dinsdag 11 oktober 2011 @ 15:17:
Jeuj promotie / contract onbepaalde tijd

Gefeliciteerd

[CodeCaster]

YopY schreef op dinsdag 11 oktober 2011 @ 15:17:
Jeuj promotie / contract onbepaalde tijd

Ondanks dat je je afspraak hebt gemist?

[BM]

Rutix schreef op dinsdag 11 oktober 2011 @ 13:55:
Ik reis elke dag 62 km . Prima te doen imo. Amersfoort -> Amsterdam. A1 Is veel beter geworden sinds ze die spitsstrook hebben.

92kilometer... enkele reis
Tja, nadeel van detachering, maar ik vind het wel prima. Vind autorijden niet vervelend, en kan lekker vroeg beginnen (6:25 loop ik meestal kantoor binnen). Verder is het een erg leuke klant, leuke projecten, dus vermaak me hier prima.
's Ochtends meestal 55 minuten onderweg, 's middags meestal rond de 60. Prima te doen. Heb het idee dat ik hier ook nog wel even zit (werd van de week al geinformeerd of we het een probleem zouden vinden om na nieuwjaar nog wat langer te blijven).

Over het zzp'en: heb er wel eens aan zitten denken, maar denk dat ik dat voorlopig nog even voor me uit schuif. Komende tijd nog meer dan genoeg te leren, en ik zie mezelf nog niet zo netwerken om aan werk te komen. Al is het wel tikje zuur als je je bedenkt wat de klant per uur voor me betaald, en wat ik er netto zelf aan overhoud

[ Voor 18% gewijzigd door BM op 11-10-2011 15:42 ]

[OkkE]

BM schreef op dinsdag 11 oktober 2011 @ 15:41:
[...]

92kilometer... enkele reis

Bij mij, volgens GoogleMaps: 2,0 km, 5 min. (enkele reis).

ZaZ schreef op dinsdag 11 oktober 2011 @ 15:55:
Sinds vorige week (verhuisd) is het nog maar 800 meter naar mijn werk.
Yay

Oude kantoor was ook ±800 meter van mijn huis.

[ Voor 35% gewijzigd door OkkE op 11-10-2011 16:01 ]

[ZaZ]

Sinds vorige week (verhuisd) is het nog maar 800 meter naar mijn werk.
Yay

[TJHeuvel]

2,5km volgens google maps, prima te fietsen. En in de zomer te longboarden :<

[Rutix]

.Gertjan. schreef op dinsdag 11 oktober 2011 @ 15:01:
[...]

Dat is een mooie, die kan ik mooi gebruiken in mijn overdracht naar een collega
Daarnaast kan ik hem ook introduceren in de schone kunst der software-archeologie
Die opmerking komt ook hier vandaan

Ik wist niet dat je crap code produceerde

[Gamebuster]

code:

rm -rf /

KUT! . vergeten!

*hoopt hard dat niets verwijderd is*
*wilde huidige map verwijderen*


#fail

edit2:
Ja tuurlijk, maak nog een keer de exact zelfde fout

[ Voor 80% gewijzigd door Gamebuster op 11-10-2011 16:58 ]

[Cartman!]

700 m, 9 mins aldus Google Maps

edit: lopend dus...

[ Voor 21% gewijzigd door Cartman! op 11-10-2011 16:54 ]

[Rutix]

Gamebuster schreef op dinsdag 11 oktober 2011 @ 16:51:

code:

rm -rf /

KUT! . vergeten!

*hoopt hard dat niets verwijderd is*
*wilde huidige map verwijderen*

[afbeelding]
#fail

Your fail saved you

[Aloys]

Als je flink haast heb kan je het in 2/3 minuten rennen .

[Styxxy]

CodeCaster schreef op dinsdag 11 oktober 2011 @ 15:30:
[...]
Ondanks dat je je afspraak hebt gemist?

Afspraken bedoel je .
Pro tip: geen e-mails naar YopY sturen .

[Matis]

Alex) schreef op dinsdag 11 oktober 2011 @ 14:00:
en ik heb ook altijd een zitplek

Dat is ook niet gek. Damn wat is die meerprijs op die kaartjes onrechtvaardig hoog. Het was dat ik voor de zaak met de trein moest en dus het kaartje kon declareren, anders was ik NO WAY met de Fyra gegaan, maar gewoon tussen het normale (niet denigrerend bedoeld) volk gaan zitten.

[Alex)]

Matis schreef op dinsdag 11 oktober 2011 @ 17:16:
[...]

Dat is ook niet gek. Damn wat is die meerprijs op die kaartjes onrechtvaardig hoog. Het was dat ik voor de zaak met de trein moest en dus het kaartje kon declareren, anders was ik NO WAY met de Fyra gegaan, maar gewoon tussen het normale (niet denigrerend bedoeld) volk gaan zitten.

€ 70 voor een maandtoeslagabonnement vind ik vrij schappelijk, het scheelt (t.o.v. de andere treinen) 80 minuten reistijd per dag.

De eerdere prijzen (zegmaar, prijspeil 2010) waren inderdaad veel te hoog. Sinds de toeslagen met 70% verlaagd zijn is de hoeveelheid reizigers met 300% toegenomen.

Tegenwoordig zijn er in de Fyra staanplaatsen. 6 rijtuigen tijdens de spits is echt niet meer genoeg

Edit: er zit een onhandige tekortkoming in de NS-site: ik heb een maandabonnement Altijd Vrij op m'n OV-chipkaart, met einddatum vandaag. Nu wilde ik vandaag een nieuw abonnement aanschaffen met ingangsdatum morgen, maar dat mag niet, omdat er al een product op m'n OV-chipkaart staat. Dat wordt na middernacht aanschaffen dus

[ Voor 24% gewijzigd door Alex) op 11-10-2011 18:05 ]

[.Gertjan.]

Rutix schreef op dinsdag 11 oktober 2011 @ 16:46:
[...]

Ik wist niet dat je crap code produceerde

Ik krijg ook wel eens een bestaand project onder mijn handen
Mijn "hoofdproject" is een project waarvoor de vorige ICT leverancier de tent is uitgejaagd later bleek niet alleen de partij ruk te zijn, maar de code van het zelfde kaliber Helaas is de tool zo groot en moet er nog zoveel gebeuren dat herbouwen gewoon geen optie is. Het best wat we kunnen doen is:

Laat je kampeerplek schoner achter dan je hem aantrof

Daarbij is het AX welke redelijk beperkt is qua development en waarin men nogal snel hoeken afsnijdt om maar snel op te leveren. Binnen AX zie je vaak: "Het werkt functioneel, dus het zal wel goed zijn".


Code die ik helemaal naar smaak mag opzetten is natuurlijk perfect Hoewel ik natuurlijk ook maar een mens ben. Oh ja? Ja

[alwinuzz]

Implying dat jij goede smaak hebt?

Ben nu build script aan het schrijven met powershell/psake. Wat een verademing na al dat msbuild gepiel. Ben blij dat ik van die 'angle bracket tax' af ben.

[ Voor 68% gewijzigd door alwinuzz op 11-10-2011 20:45 ]

[.Gertjan.]

alwinuzz schreef op dinsdag 11 oktober 2011 @ 20:44:
Implying dat jij goede smaak hebt?

Ben nu build script aan het schrijven met powershell/psake. Wat een verademing na al dat msbuild gepiel. Ben blij dat ik van die 'angle bracket tax' af ben.

Mwa over smaak valt te discussiëren, echter zijn er ook gewoon dingen die absoluut fout zijn En helaas zie ik teveel projecten waar foute dingen in zitten. Vooral DRY (don't repeat youself) en KISS (keep it simple stupid) worden met voeten getreden door veel ontwikkelaars.

Ook zaken als zoveel mogelijk in de sessions en viewstate gooien zijn dingen waarbij ik direct alert ben.

Ik wil niet zeggen dat mijn visie altijd de beste is, maar sommige dingen kunnen gewoon niet meer door de beugel. Je ziet ook direct in de code of een ontwikkelaar ervaren is en of deze "het denken van een ontwikkelaar" bezitten.

Maar nee, ik voel me niet perfect ofzo hoor Ik zie altijd dingen waarvan ik denk: Goh waarom zo? Of, heb je dit niet overwogen? Maar dat heb ik zelfs als ik naar mijn eigen (oude) code kijk. Vaak veranderen je denkbeelden ook tijdens een project waardoor je ook bij je oude code soms je vraagtekens zet. Maar goed een kritisch oog is niet verkeerd lijkt me...

[Evilbee]

Ik heb afgelopen weken bij een klant in Foxhol gezeten. Ook leuk als je daar om 9 uur moet zijn en je woont in Haarlem. Dat zijn 215 kilometers, dus om half 7 weg

Gelukkig kan ik nu de laatste dingen afhandelen vanaf kantoor (~ 5 minuten fietsen).

[PeterSelie]

Evilbee schreef op woensdag 12 oktober 2011 @ 09:46:
Ik heb afgelopen weken bij een klant in Foxhol gezeten. Ook leuk als je daar om 9 uur moet zijn en je woont in Haarlem. Dat zijn 215 kilometers, dus om half 7 weg

Gelukkig kan ik nu de laatste dingen afhandelen vanaf kantoor (~ 5 minuten fietsen).

Compensatie noemt men dat

[Evilbee]

SoaDmaggot schreef op woensdag 12 oktober 2011 @ 09:53:
[...]



Compensatie noemt men dat

Ach, voor een ander project moet ik naar Zwitserland, Noorwegen, Zweden, etc.

Dus een project in Nederland is ook wel eens leuk

[Styxxy]

Evilbee schreef op woensdag 12 oktober 2011 @ 09:57:
[...]
Ach, voor een ander project moet ik naar Zwitserland, Noorwegen, Zweden, etc.

Elke dag op en neer naar Zwitserland, Noorwegen, Zweden, etc. is ook geen pretje .

[Acid_Burn]

Zucht.. een klant wil verborgen teksten op zijn zijn speciaal voor Google. Nu heb ik em er op gewezen dat Google daar niet van houdt en zelfs zijn ranking negatief kan beinvloeden. Ook Bing wil dat niet hebben. Nee, toch moet die tekst er op in een div met display:none

Als ze maar niet bij ons komen zeiken als ze straks niet meer gevonden worden in Google.

[Hoogie2004]

Acid_Burn schreef op woensdag 12 oktober 2011 @ 10:21:
Zucht.. een klant wil verborgen teksten op zijn zijn speciaal voor Google. Nu heb ik em er op gewezen dat Google daar niet van houdt en zelfs zijn ranking negatief kan beinvloeden. Ook Bing wil dat niet hebben. Nee, toch moet die tekst er op in een div met display:none

Als ze maar niet bij ons komen zeiken als ze straks niet meer gevonden worden in Google.

Gewoon die mail-conversatie opslaan en nogmaals het risico aangeven? Dat ze komen zeuren staat vast, de vraag is alleen hoe snel.

[ Voor 5% gewijzigd door Hoogie2004 op 12-10-2011 10:25 ]

[Intru]

Acid_Burn schreef op woensdag 12 oktober 2011 @ 10:21:
Zucht.. een klant wil verborgen teksten op zijn zijn speciaal voor Google. Nu heb ik em er op gewezen dat Google daar niet van houdt en zelfs zijn ranking negatief kan beinvloeden. Ook Bing wil dat niet hebben. Nee, toch moet die tekst er op in een div met display:none

Als ze maar niet bij ons komen zeiken als ze straks niet meer gevonden worden in Google.

Gewoon niet doen, en tegen de klant zeggen dat je de tekst zo ontzettend hidden hebt gemaakt, dat je het zelfs in de bron niet kan zien!

[OkkE]

Acid_Burn schreef op woensdag 12 oktober 2011 @ 10:21:
Zucht.. een klant wil verborgen teksten op zijn zijn speciaal voor Google. Nu heb ik em er op gewezen dat Google daar niet van houdt en zelfs zijn ranking negatief kan beinvloeden. Ook Bing wil dat niet hebben. Nee, toch moet die tekst er op in een div met display:none

Als ze maar niet bij ons komen zeiken als ze straks niet meer gevonden worden in Google.

Ben ik wel benieuwd waarom die klant dat wil...

Beste is inderdaad de mail-conversatie opslaan (of zelfs document laten tekenen). Of je doet het gewoon niet. Ik vind dat je als developer soms dingen (zoals dit) moet weigeren.

[ Voor 4% gewijzigd door OkkE op 12-10-2011 10:28 ]

[TJHeuvel]

Waarom zou je als developer de vraag van een klant weigeren?

Als de klant retarded software wilt, kunnen ze dat krijgen. Natuurlijk kan je ze wijzen op het feit dat het wellicht niet de beste keuze is, maar als ze dit per se willen, en er voor betalen kan je het toch moeilijk weigeren?

[Acid_Burn]

De klant is er van overtuigd dat dit de vindbaarheid in Google ten goede zal komen. Ondanks dat ik hem heb verteld dat dit niet zo is inclusief links naar de dev pagina's van Google zelf (en Bing) wil hij dat er toch in hebben. Mijn baas zegt dan weer, bouw maar in, dan ik ik niet zeggen dat doe ik niet. Dus ik bouw dat gewoon lekker in.

Mail conversaties worden uiteraard gearchiveerd. Dat doe ik standaard (mijn baas trouwens ook).

[OkkE]

TJHeuvel schreef op woensdag 12 oktober 2011 @ 10:35:
Waarom zou je als developer de vraag van een klant weigeren?

Als de klant retarded software wilt, kunnen ze dat krijgen. Natuurlijk kan je ze wijzen op het feit dat het wellicht niet de beste keuze is, maar als ze dit per se willen, en er voor betalen kan je het toch moeilijk weigeren?

Vind ik niet.

Natuurlijk hangt het van het project, de klant en de wens af. Vaak kom je met de vraag "Waarom?" wel achter de bedoeling van de klant en kan je samen een betere oplossing vinden. Maar ik vind dat je bepaalde wensen best mag weigeren, als ze echt stom/slecht zijn.

Nu is dit misschien niet het goede voorbeeld; tekst op display: none is vooral een probleem voor de klant. Maar er zijn best situaties te bedenken, bijvoorbeeld met privacy van bezoekers, of beveiliging van NAW gegevens, waarbij ik vind dat je soms nee moet zeggen tegen een klant. Ondanks dat hij betaalt.

Acid_Burn schreef op woensdag 12 oktober 2011 @ 10:42:
De klant is er van overtuigd dat dit de vindbaarheid in Google ten goede zal komen. Ondanks dat ik hem heb verteld dat dit niet zo is inclusief links naar de dev pagina's van Google zelf (en Bing) wil hij dat er toch in hebben. Mijn baas zegt dan weer, bouw maar in, dan ik ik niet zeggen dat doe ik niet. Dus ik bouw dat gewoon lekker in.

Mail conversaties worden uiteraard gearchiveerd. Dat doe ik standaard (mijn baas trouwens ook).

Sja, als je de klant zelfs links en uitleg hebt gestuurd en hij/zij wil nog steeds zoiets, dan is het misschien wel beter gewoon te zeggen "prima, doen we". Zolang je op papier hebt dat het tegen jullie advies in is, zit je veilig.

[TJHeuvel]

Daar heb je zeker een punt Okke, op punten waar wij de experts in zijn moet je inderdaad wel je grenzen leggen.

Wat ik vaker heb gezien is dat ik het persoonlijk bijvoorbeeld qua user-interactie er niet mee eens bent wat de klant wilt, maar uiteindelijk er toch maar bij neerleg omdat hij er helemaal van overtuigd is.

[Ram0n]

Als het doel voor de klant zelf ook echt is om de ranking te verbeteren is het een lastig punt; het zal inderdaad juist averechts werken, maar als je klant dat niet wil geloven is het een lastige afweging. De klant is tot op bepaalde mate koning, maar jij zit straks inderdaad met het gezeur als ze erachter komen dat je toch gelijk had.

Dus inderdaad goed al die mails e.d. bewaren

Toch wel grappig hoe een bedrijf dan een specialist in armen neemt om hun website te realiseren, om vervolgens niet te luisteren naar het SEO-advies.

[OkkE]

TJHeuvel schreef op woensdag 12 oktober 2011 @ 10:54:
Daar heb je zeker een punt Okke, op punten waar wij de experts in zijn moet je inderdaad wel je grenzen leggen.

Wat ik vaker heb gezien is dat ik het persoonlijk bijvoorbeeld qua user-interactie er niet mee eens bent wat de klant wilt, maar uiteindelijk er toch maar bij neerleg omdat hij er helemaal van overtuigd is.

Klopt, dat gebeurd mij ook nog wel eens. Soms kun je de klant gewoon niet overtuigen. Dan is het helemaal geen probleem om "het gewoon te doen, de klant betaalt".

Van die dingen als Google/Bing bedriegen vind ik een lastig punt. Aan de ene kant vind ik het de klant zijn probleem. Aan de andere kant, hangt wel (direct, of indirect) je naam er aan en vind ik dat je zulke shady-praktijken gewoon niet moet doen. Punt.

Ram0n schreef op woensdag 12 oktober 2011 @ 10:57:
Toch wel grappig hoe een bedrijf dan een specialist in armen neemt om hun website te realiseren, om vervolgens niet te luisteren naar het SEO-advies.

Gelukkig hebben wij dat nog nooit meegemaakt. Wij hebben wel af en toe klanten die benaderd worden door van die "speciale SEO bedrijfjes", gelukkig vertrouwen ze ons eigenlijk altijd meer; wij komen met links en uitleg ipv die buzz-word bingo.

[ Voor 22% gewijzigd door OkkE op 12-10-2011 11:03 ]

[Rutix]

blablabla. Bah ik heb echt geen zin vandaag :<.

[Styxxy]

Rutix schreef op woensdag 12 oktober 2011 @ 11:20:
blablabla. Bah ik heb echt geen zin vandaag :<.

Idem. COBOL kan me echt niet boeien .

[Acid_Burn]

Ram0n schreef op woensdag 12 oktober 2011 @ 10:57:
Toch wel grappig hoe een bedrijf dan een specialist in armen neemt om hun website te realiseren, om vervolgens niet te luisteren naar het SEO-advies.

"Maar in 2000 deden we dat ook"
Ik heb wel vaker opmerkingen van deze klant gekregen die ze duidelijk van een neefje-dat-ook-wel-eens-met-frontpage-aan-de-gang-is-geweest hebben gehad.

Maar goed, ik heb het net ingebouwd. Gemeld dat het er inzit met onderstreept nogmaals dat het de ranking kan beïnvloeden... Meer kan ik niet doen.

[OkkE]

Acid_Burn schreef op woensdag 12 oktober 2011 @ 11:44:
"Maar in 2000 deden we dat ook"
Ik heb wel vaker opmerkingen van deze klant gekregen die ze duidelijk van een neefje-dat-ook-wel-eens-met-frontpage-aan-de-gang-is-geweest hebben gehad.

Dat is altijd verschrikkelijk ja. Gelukkig hebben wij alleen klanten die uiteindelijk toch ons meer geloven dan "dat neefje".

Maar goed, ik heb het net ingebouwd. Gemeld dat het er inzit met onderstreept nogmaals dat het de ranking kan beïnvloeden... Meer kan ik niet doen.

Waar ik dan weer wel benieuwd naar ben: hoe lang het uiteindelijk duurt voor ze een penalty krijgen en hoe ver hun rank zakt.

[Acid_Burn]

Ligt een beetje aan de algoritmen van de zoekmachines denk ik.. Wordt het opgepikt en zo ja, wordt je dan ook direct gestraft. Voor hetzelfde geld gebeurt er niets... of over een half jaar zijn ze ineens niet meer te vinden ofzo. Daarom zeg ik in de mails ook niet dat het absoluut de ranking zal beïnvloeden, maar dat het goed mogelijk is dat etc etc.100% zeker kan je niet zijn. Ik heb ze alleen op de richtlijnen gewezen.

[OkkE]

Acid_Burn schreef op woensdag 12 oktober 2011 @ 11:51:
Ligt een beetje aan de algoritmen van de zoekmachines denk ik.. Wordt het opgepikt en zo ja, wordt je dan ook direct gestraft. Voor hetzelfde geld gebeurt er niets... of over een half jaar zijn ze ineens niet meer te vinden ofzo. Daarom zeg ik in de mails ook niet dat het absoluut de ranking zal beïnvloeden, maar dat het goed mogelijk is dat etc etc.100% zeker kan je niet zijn. Ik heb ze alleen op de richtlijnen gewezen.

I know.

Ik bedoelde ook, ben benieuwd hoe het in dit geval gaat. Elke website is anders, maar interessant om cijfers uit de praktijk te weten ipv altijd maar te speculeren.

[alienfruit]

Ja, de SEO bedrijven zijn vervelend. Ik moest ook een export maken van de website voor zo'n SEO bedrijf. Ik dus mooi de standaard export functionaliteit gebruiken. Gaan ze vervolgens bitchen dat ze niks kunnen met XML bestanden en ik mag geen tijd besteden met import/export functie (klant wilde dat niet betalen) schrijven. Tough luck voor hun

[Snake]

Stuur ze het voorbeeld van BMW? http://blogoscoped.com/archive/2006-02-04-n60.html

[JohnBQ]

Pff weer eens veel moeite met WPF vandaag zeg, steeds vaker dat het erg lastig is om dingen niet lekker snel en simpel in de code te willen doen maar in redelijk onbekend XAML

[MTWZZ]

JohnBQ schreef op woensdag 12 oktober 2011 @ 14:50:
Pff weer eens veel moeite met WPF vandaag zeg, steeds vaker dat het erg lastig is om dingen niet lekker snel en simpel in de code te willen doen maar in redelijk onbekend XAML

wat lukt er niet dan?

[.oisyn]

XAML is op zich vrij simpel, het enige wat het doet is het instantieren van classes (de tags) en het zetten van properties (de attributen)

[alienfruit]

Gloeiende gloeiende, dit systeem is gewoon te sloom voor een paar blur effecten. Hopelijk ziet de klant niet dat ze weg zijn. Anders mogen ze 400 nieuwe systemen kopen als ze de blur effect echt willen

[Verwijderd]

Als je for .. in .. do gebruikt in delphi, en je verwijdert halverwege een element slaat hij een element over. Ik dacht dat dat juist niet het geval was... Daar ben je dan een halve dag mee bezig.

[JohnBQ]

MTWZZ schreef op woensdag 12 oktober 2011 @ 14:53:
[...]

wat lukt er niet dan?

Al een tijdje aan het klooien met het binden van dependency properties in custom controls, in het ene (test)project wel (bijna)werkend maar in het andere (main)project zit het niet goed. Geen errors of meldingen e.d. maar ook geen weergave

.oisyn schreef op woensdag 12 oktober 2011 @ 15:05:
XAML is op zich vrij simpel, het enige wat het doet is het instantieren van classes (de tags) en het zetten van properties (de attributen)

Het is alleen wel flink wennen en zoeken, er zijn ook al regelmatig "oow, is dat alles 8)7" langsgekomen maar het vergt wel een stuk meer tijd dan ff snel in code(-behind) bezig te gaan

[MTWZZ]

JohnBQ schreef op woensdag 12 oktober 2011 @ 15:25:
Al een tijdje aan het klooien met het binden van dependency properties in custom controls, in het ene (test)project wel (bijna)werkend maar in het andere (main)project zit het niet goed. Geen errors of meldingen e.d. maar ook geen weergave

Check nog even of je alles goed instantieert en declareert.

Het is alleen wel flink wennen en zoeken, er zijn ook al regelmatig "oow, is dat alles 8)7" langsgekomen maar het vergt wel een stuk meer tijd dan ff snel in code(-behind) bezig te gaan

Applications = Code + Markup van Charles Petzold heb ik altijd wel een handig boek gevonden

[JohnBQ]

MTWZZ schreef op woensdag 12 oktober 2011 @ 15:37:
[...]

Check nog even of je alles goed instantieert en declareert.


[...]

Applications = Code + Markup van Charles Petzold heb ik altijd wel een handig boek gevonden

Zal er eens naar kijken, bedankt voor de tip!

[st0p]

Kennen jullie het gevoel dat je na 2 maanden werk aan een proejct (wat overigens alle kentekens heeft van een falend it project, belabberde functionele omschrijving, gebrek aan sturing etc etc), je alle code weg wil gooien en overnieuw wil beginnen?

[Megamind]

st0p schreef op woensdag 12 oktober 2011 @ 17:16:
Kennen jullie het gevoel dat je na 2 maanden werk aan een proejct (wat overigens alle kentekens heeft van een falend it project, belabberde functionele omschrijving, gebrek aan sturing etc etc), je alle code weg wil gooien en overnieuw wil beginnen?

Vooral als anderen eraan hebben gezeten: ja, non-stop.

[st0p]

Megamind schreef op woensdag 12 oktober 2011 @ 17:37:
[...]

Vooral als anderen eraan hebben gezeten: ja, non-stop.

Nou dit is 50% mijn eigen code, maar in retroperspectief had ik een aantal zaken fundamenteel anders aangepakt.

[alienfruit]

Ja hoor, alleen heb ik het geluk gehad dat ik het jaar later opnieuw mocht schrijven. Het oude produkt gebruikte bepaalde merknamen alleen hun licentie hiertoe kwam te vervallen. Nu is de code een stuk netter en een berg unit tests voor de moeilijke delen van het project.

Ik heb namelijk nog steeds geen benul hoe je animaties/banners unit test. Ik heb de klasses die de data ophalen wel getest. Maar de weergave er van niet...

[ Voor 22% gewijzigd door alienfruit op 12-10-2011 18:28 ]

[CodeCaster]

Met opnieuw schrijven introduceer je uiteraard nieuwe bugs, maar soms is het wel gerechtvaardigd. Ik zou dat bij een project van mij haast ook mogen doen (fundamentele wijziging voor een tweede versie), maar ja ... bleek dat het wijzigingsverzoek verkeerd geïnterpreteerd was door de opdrachtgever, dus de wijziging was iets minder ingrijpend dan gedacht.

[ Voor 25% gewijzigd door CodeCaster op 12-10-2011 18:51 ]

[Caelorum]

Gehad tijdens afstuderen. Heb zonder overleg +- 8 weken aan code weggegooid om het in een week opnieuw te schrijven in beter onderhoudbare vorm.
Als je een goede reden hebt om de code te herschrijven en het zorgt voor een korter project zie ik persoonlijk geen probleem (Al zou ik als niet-afstudeerder wel eerst even vragen om toestemming ^^)

[Alex)]

Het project waar ik nu op zit is verkocht als 'kleine upgrade', maar eigenlijk zitten we alles opnieuw te doen. Database, reporting, integration, business logic, enzovoorts.

[st0p]

Caelorum schreef op woensdag 12 oktober 2011 @ 19:31:
Gehad tijdens afstuderen. Heb zonder overleg +- 8 weken aan code weggegooid om het in een week opnieuw te schrijven in beter onderhoudbare vorm.
Als je een goede reden hebt om de code te herschrijven en het zorgt voor een korter project zie ik persoonlijk geen probleem (Al zou ik als niet-afstudeerder wel eerst even vragen om toestemming ^^)

Als ik geen enorm dwingende deadline had gehad had ik het gedaan. Het probleem is dat we extern gecertificeerd moeten worden (het gaat om een SOAP koppeling) en dat het aanvragen van een nieuw certificatie slot weken zoniet maanden gaat duren.

Oh, en ik heb een vakantie gepland 2 weken na de deadline. In eerste instantie was de deadline heilig en kon niet overschreden worden, ondertussen ligt de deadline vast omdat ik twee weken erna op vakantie ga. Raaaaaarrrrrrrrrr. Daar ga ik morgen nog wel even wat over zeggen.

[RayNbow]

De R in K&R is er niet meer

RIP

[eamelink]

Ik ben sinds kort bezig met een langlopend project (13 jaar), wat grotendeels in Perl geschreven is, begonnen is als kleine reporting applicatie voor messages tussen een systeem van onze klant en een klant van hun en over de loop der jaren is ge-evolueerd tot een business-critical app, die alle messages intercept en ze afhankelijk van een berg business rules doorstuurt, wijzigt, groupeert, etcetera.

13 jaar oud, grotendeels in Perl, en langzaam ge-evolueerd. En guess what? Het zit gewoon prima in elkaar ! Als je op zo'n project komt dan verwacht je dat het echt een verschrikkelijke puinhoop is, gewoon vanwege de leeftijd en de manier waarop het is gegroeid, maar mijn collega's zijn erg capabele lui die dat beest mooi getemd hebben

Overigens zijn we nu wel langzaam aan het migreren naar een architectuur op basis van Java en Scala, maar dat komt vooral doordat mijn overige collega's en ikzelf de afgelopen vijf tot tien jaar voor het laatst een regel Perl hebben geschreven en de continuïteit een beetje in het geding begint te komen

[.Gertjan.]

Vandaag maar eens de trial van Resharper op mijn machine gezet. Een kijk of het inderdaad zo geweldig is als sommige beweren.

Ik sta overigens wel verbaasd van de eerste wijziging die hij voorstelt: gebruik geen explicite types voor lokale variabele, maar gebruik var Nu ben ik sowieso niet echt een grote voorstander van var omdat ik persoonlijk vind dat het de leesbaarheid niet altijd verbetert.

C#:

var myList = new List<string>(); //Dit wijst zichzelf omdat je bij de new kunt zien wat er gebeurt
var myList = GetSomethingFromSomewhere(); //Dit is wat lastiger omdat je aan de functie niet altijd direct kunt zien wat er terug komt

Mijn eerste reactie op het voorstel was dan ook: "Ow... "... Jaja, ik weet dat je het kunt uitschakelen, maar toch ben ik het niet eens met dat voorstel

Overigens is de collection initializer optie dan wel weer grappig Hij had door dat ik een list maakte en daar een aantal vaste waardes aan toekende en stelde voor deze dan maar direct in de constructor van de list te gooien.

Overigens vind ik het ook wel leuk om te zien dat hij de kleurtjes toont als je een kleurcode ergens gebruikt.

[RayNbow]

.Gertjan. schreef op donderdag 13 oktober 2011 @ 07:20:
Ik sta overigens wel verbaasd van de eerste wijziging die hij voorstelt: gebruik geen explicite types voor lokale variabele, maar gebruik var

Gerelateerde discussie?

\[C#][discussie] Lekker veel var gebruiken?

[.Gertjan.]

RayNbow schreef op donderdag 13 oktober 2011 @ 07:42:
[...]

Gerelateerde discussie?

\[C#][discussie] Lekker veel var gebruiken?

Gelukkig ben ik dus niet de enige die var niet zo leuk vind
Var is voor javascript en daar zou het moeten blijven

[RayNbow]

.Gertjan. schreef op donderdag 13 oktober 2011 @ 07:47:
[...]

Gelukkig ben ik dus niet de enige die var niet zo leuk vind
Var is voor javascript en daar zou het moeten blijven

Daar ben ik niet mee eens.

En om even terug te komen op je codevoorbeeld:

.Gertjan. schreef op donderdag 13 oktober 2011 @ 07:20:

C#:

var myList = new List<string>(); //Dit wijst zichzelf omdat je bij de new kunt zien wat er gebeurt
var myList = GetSomethingFromSomewhere(); //Dit is wat lastiger omdat je aan de functie niet altijd direct kunt zien wat er terug komt

Het is overduidelijk dat je op de 2e regel een Something terugkrijgt. Dat vertelt immers de naam van de methode je.

(Mocht de methode geen Something retourneren, dan heb je een groter probleem. Ga eens snel de naam van de methode fixen! )

[.Gertjan.]

RayNbow schreef op donderdag 13 oktober 2011 @ 07:56:
(Mocht de methode geen Something retourneren, dan heb je een groter probleem. Ga eens snel de naam van de methode fixen! )

Of je altijd het returntype in je functienaam moet gebruiken is ook iets wat aan smaak onderhevig is en waar volgens mij ook diverse discussies over gevoerd kunnen worden. Kijk een functie als GetUser() zal allicht een user teruggeven, maar een functie GetUsers(), tja die geeft Users terug, maar hoe?

Een functie als GetUsers kan een list, array of andere verzameling teruggeven. Hij kan zelfs een custom object teruggeven.

Als ik wil weten wat voor type een bepaalde variabele is ben ik gewend om links van de variabele naam te kjken naar de definitie. Als ik dan een var tegenkom moet ik dus even verder zoeken. Misschien een kwestie van gewenning, maar ik ben er geen fan van

Met al die mooie autocompletes in de IDE is het "extra typen" ook geen argument meer Zou resharper het ook andersom kunnen doen? Dus var's omzetten in "echte" types?

[eamelink]

RayNbow schreef op donderdag 13 oktober 2011 @ 07:56:
Het is overduidelijk dat je op de 2e regel een Something terugkrijgt. Dat vertelt immers de naam van de methode je.

(Mocht de methode geen Something retourneren, dan heb je een groter probleem. Ga eens snel de naam van de methode fixen! )

Maar stel nou dát je inderdaad die methode refactored en je geen Something meer terugkrijgt, dan gaat er toch iets breken in deze methode. En het is dan niet meteen duidelijk wat er mis gaat, want op line twee stop je je ding in een var, en als je hem pas op regel elf gebruikt en er een methode van Something op wil aanroepen, krijg je daar je fout.

Als je een type had gebruikt in plaats van var, dan krijg je de foutmelding meteen bij de assignment en is de oorzaak van het probleem ook direct veel zichtbaarder en duidelijker

In talen als Haskell en Scala is het wat fraaier opgelost, omdat je daar een type annotatie echt als extraatje kan toevoegen aan je code en het wat makkelijker ook weer is te verwijderen. In C# moet je zo te zien code wijzigen om dat te doen.

[ Voor 11% gewijzigd door eamelink op 13-10-2011 08:21 ]

[.Gertjan.]

eamelink schreef op donderdag 13 oktober 2011 @ 08:19:
[...]


Maar stel nou dát je inderdaad die methode refactored en je geen Something meer terugkrijgt, dan gaat er toch iets breken in deze methode. En het is dan niet meteen duidelijk wat er mis gaat, want op line twee stop je je ding in een var, en als je hem pas op regel elf gebruikt en er een methode van Something op wil aanroepen, krijg je daar je fout.

Als je zodanig gaat refactoren dat je returntype veranderd moet toch ook je functie renamen Een functie GetUsers die je een array van Klanten teruggeeft is natuurlijk ook niet de bedoeling

Sowieso is wijzigingen in de "fingerprint" van je functie (returntype en parameters) iets waar je erg mee moet opletten. Zeker als je componenten schrijft die gebruikt worden in meerdere projecten. Wanneer je je interface publiceert moet je eigenlijk van de fingerprint van je functies afblijven. Nadeel is wel dat je dan volgnummers in je objecten en functies moet gebruiken (zie de libraries van Office ).

Als je een type had gebruikt in plaats van var, dan krijg je de foutmelding meteen bij de assignment en is de oorzaak van het probleem ook direct veel zichtbaarder en duidelijker

Dat is inderdaad een goed argument. Maar aan de andere kant hanteren veel mensen dan weer het principe een variabele pas te definieren (en vullen) wanneer je hem nodig hebt, dus tig regels er tussen zal veel mensen niet overkomen.

[Rutix]

.Gertjan. schreef op donderdag 13 oktober 2011 @ 08:03:
[...]


Of je altijd het returntype in je functienaam moet gebruiken is ook iets wat aan smaak onderhevig is en waar volgens mij ook diverse discussies over gevoerd kunnen worden. Kijk een functie als GetUser() zal allicht een user teruggeven, maar een functie GetUsers(), tja die geeft Users terug, maar hoe?

Een functie als GetUsers kan een list, array of andere verzameling teruggeven. Hij kan zelfs een custom object teruggeven.

Als ik wil weten wat voor type een bepaalde variabele is ben ik gewend om links van de variabele naam te kjken naar de definitie. Als ik dan een var tegenkom moet ik dus even verder zoeken. Misschien een kwestie van gewenning, maar ik ben er geen fan van

Ik vind dat je dat dan duidelijk moet maken in de functienaam. Als we nu toch over "leesbaarheid" gaan hebben dan moet je ook dat ook doen in je methods namen. Voordat je GetUsers gaat gebruiken moet je toch ook eerst kijken wat het nou terug geeft? Als je duidelijk was in je method naam dan hoefde je dat ook niet. Dan was het bijvoorbeeld GetUsersList of iets dergelijks. Daar komt bij dat als je muis op de 'var' of method naam houd je kan zien wat het terug geeft.

.Gertjan. schreef op donderdag 13 oktober 2011 @ 08:03:

Met al die mooie autocompletes in de IDE is het "extra typen" ook geen argument meer Zou resharper het ook andersom kunnen doen? Dus var's omzetten in "echte" types?

Ja dat kan. Cursor op die var -> alt+enter en dan staat het er .

Refactor argument gaat hier ook niet helemaal op. Resharper geeft netjes aan als je een method refactored dat er dingen zijn veranderd en vaak ook nog waar het dan fout gaat . Als je explicit types zou gebruiken zou je inderdaad zien dat het daar fout gaat maar dan nog zou je verder moeten gaan kijken waar die variabele word gebruikt. Als je implicit gebruikt gaat het fout op waar je de variabele gebruikt en hoef je dus alleen dat aan te passen wat weer minder werk is.

[ Voor 12% gewijzigd door Rutix op 13-10-2011 08:30 ]

[.Gertjan.]

Rutix schreef op donderdag 13 oktober 2011 @ 08:26:
Voordat je GetUsers gaat gebruiken moet je toch ook eerst kijken wat het nou terug geeft?

Als ik een var zou gebruiken zou ik toch ook enige kennis van het return object moeten hebben Anders weet ik later nog niet wat ik er mee kan

Mijn probleem met var zit meer in het "teruglezen". Zodra ik code schrijf weet ik meestal wat mijn variabele voor type is, ik heb hem tenslotte aangemaakt en heb een bepaald doel met dat ding voor ogen. Echter wanneer ik code van enkele maanden oud terug lees (of van een andere developer) kan een var als ruis werken.

Dat zelfde heb ik ook bij nested for lusjes. Tijdens het schrijven zijn int i, j en k duidelijk, maar lees je het later terug dan is het meestal toch wel:

[D-Raven]

Gaan we nou echt _weer_ die var discussie hebben doe dat lekker in het var-ranting topic \[C#][discussie] Lekker veel var gebruiken?

[.Gertjan.]

D-Raven schreef op donderdag 13 oktober 2011 @ 08:42:
Gaan we nou echt _weer_ die var discussie hebben doe dat lekker in het var-ranting topic \[C#][discussie] Lekker veel var gebruiken?

Leuk, een topic van de GoT begraafplaats opgraven

[Rutix]

.Gertjan. schreef op donderdag 13 oktober 2011 @ 08:30:
[...]

Als ik een var zou gebruiken zou ik toch ook enige kennis van het return object moeten hebben Anders weet ik later nog niet wat ik er mee kan

Mijn probleem met var zit meer in het "teruglezen". Zodra ik code schrijf weet ik meestal wat mijn variabele voor type is, ik heb hem tenslotte aangemaakt en heb een bepaald doel met dat ding voor ogen. Echter wanneer ik code van enkele maanden oud terug lees (of van een andere developer) kan een var als ruis werken.

Dat zelfde heb ik ook bij nested for lusjes. Tijdens het schrijven zijn int i, j en k duidelijk, maar lees je het later terug dan is het meestal toch wel:

Als ik zou lezen: var users = GetUsersList(); dan denk ik al van "Hé! Dat is een lijst met users!" . Als je dan echt nog meer wilt weten dan moet je maar verder kijken.

Hier een voorbeeld die al op eerdere blogs is gebruikt.

C#:

var procs = from p in ServiceController.GetServices()
                 where p.Status == ServiceControllerStatus.Running
                 select p;
procs.ToList().ForEach(p=> Console.WriteLine(p.ServiceName));

procs is zeker een IEnumberable maar dat boeit helemaal niet. Wat mij zou boeien is dat ik weet dat het procs een list is en dat de items een property ServiceName hebben.
Ik vind deze comment wel een mooie:

The underlying type is important to the compiler, but the people that have to read code aren’t compilers right?

[RayNbow]

eamelink schreef op donderdag 13 oktober 2011 @ 08:19:
[...]


Maar stel nou dát je inderdaad die methode refactored en je geen Something meer terugkrijgt, dan gaat er toch iets breken in deze methode. En het is dan niet meteen duidelijk wat er mis gaat, want op line twee stop je je ding in een var, en als je hem pas op regel elf gebruikt en er een methode van Something op wil aanroepen, krijg je daar je fout.

Dit probleem heb je ook in Haskell.

[Alex)]

Mij maakt het niet uit bij GetUsers of ik nou een List, Array of zelfs iets anders terugkrijg. Zolang het maar IEnumerable<T> implementeert zal het me verder een rotzorg zijn.

Sterker nog, ik schrijf dergelijke methodes tegenwoordig vaak zo:

C#:

public IEnumerable<User> GetUsers()
{
    var users = Dal.GetUsers();

    foreach(var user in users)
    {
        yield return ConvertDalToUser(user);
    }
}

[.Gertjan.]

Alex) schreef op donderdag 13 oktober 2011 @ 09:02:
Mij maakt het niet uit bij GetUsers of ik nou een List, Array of zelfs iets anders terugkrijg. Zolang het maar IEnumerable implementeert zal het me verder een rotzorg zijn.

En toen wilde je weten hoeveel items erin zaten... Ehm was dat nou Count of Length Tja dan moet je wel weten of het een List of Array is In jouw geval is het inderdaad niet nodig, maar zodra je ook zaken gaat toevoegen is het zeker nuttig om te weten of je een lijst of array hebt

[Hoogie2004]

.Gertjan. schreef op donderdag 13 oktober 2011 @ 09:06:
[...]

En toen wilde je weten hoeveel items erin zaten... Ehm was dat nou Count of Length Tja dan moet je wel weten of het een List of Array is In jouw geval is het inderdaad niet nodig, maar zodra je ook zaken gaat toevoegen is het zeker nuttig om te weten of je een lijst of array hebt

Linq's extensie .Count() werkt op beide

[.Gertjan.]

Hoogie2004 schreef op donderdag 13 oktober 2011 @ 09:07:
[...]

Linq's extensie .Count() werkt op beide

damnit Jullie winnen....

[Hoogie2004]

.Gertjan. schreef op donderdag 13 oktober 2011 @ 09:09:
[...]

damnit Jullie winnen....

_{Overigens geen idee of het veel scheelt qua performance tussen Linq's Count() en de standaard count op lists/arrays}

[Alex)]

.Gertjan. schreef op donderdag 13 oktober 2011 @ 09:06:
[...]

En toen wilde je weten hoeveel items erin zaten... Ehm was dat nou Count of Length Tja dan moet je wel weten of het een List of Array is

MSDN: Enumerable.Count Method (System.Linq)

In jouw geval is het inderdaad niet nodig, maar zodra je ook zaken gaat toevoegen is het zeker nuttig om te weten of je een lijst of array hebt

Ok, bij toevoegen is het inderdaad een ander verhaal. Daarvoor heb ik altijd IList<T>'s of ICollection<T>'s. Maar veel operaties hebben alleen maar te maken met retrieval

[RayNbow]

Alex) schreef op donderdag 13 oktober 2011 @ 09:02:
Mij maakt het niet uit bij GetUsers of ik nou een List, Array of zelfs iets anders terugkrijg. Zolang het maar IEnumerable<T> implementeert zal het me verder een rotzorg zijn.

Sterker nog, ik schrijf dergelijke methodes tegenwoordig vaak zo:

C#:

public IEnumerable<User> GetUsers()
{
    var users = Dal.GetUsers();

    foreach(var user in users)
    {
        yield return ConvertDalToUser(user);
    }
}

Waarom niet

C#:

public IEnumerable<User> GetUsers() 
{ 
    return from user in Dal.GetUsers()
           select ConvertDalToUser(user);
}

of

C#:

public IEnumerable<User> GetUsers() 
{ 
    return Dal.GetUsers().Select(ConvertDalToUser);
}

?

[Rutix]

.Gertjan. schreef op donderdag 13 oktober 2011 @ 09:09:
[...]

damnit Jullie winnen....

Jeeej weer iemand die zich gewonnen geeft \o/. Ben laatste tijd wel on de roll kwa resharper

[Alex)]

RayNbow schreef op donderdag 13 oktober 2011 @ 09:15:
[...]

Waarom niet

C#:

public IEnumerable<User> GetUsers() 
{ 
    return from user in Dal.GetUsers()
           select ConvertDalToUser(user);
}

of

C#:

public IEnumerable<User> GetUsers() 
{ 
    return Dal.GetUsers().Select(ConvertDalToUser);
}

?

Daar is geen reden voor eigenlijk, gewoon gewenning

ReSharper stelt wel vaak voor om mijn code te rewriten naar wat jij voorstelt

[.Gertjan.]

[b]Hoogie2004 schreef op donderdag 13 oktober 2011 @ 09:11:

C#:

public IEnumerable GetUsers()
{
    var users = Dal.GetUsers();

    foreach(var user in users)
    {
        yield return ConvertDalToUser(user);
    }
}

Bijzonder stukje code.... heb wel eens de yield langs zien komen, maar nooit echt bekeken wat dit doet....

Klopt het dat de yield return de IEnumerable vult? Dit zou in ieder geval het aanmaken van een list en het toevoegen daaraan overbodig maken...

[Rutix]

.Gertjan. schreef op donderdag 13 oktober 2011 @ 09:18:
[...]

Bijzonder stukje code.... heb wel eens de yield langs zien komen, maar nooit echt bekeken wat dit doet....

Klopt het dat de yield return de IEnumerable vult? Dit zou in ieder geval het aanmaken van een list en het toevoegen daaraan overbodig maken...

The yield keyword signals to the compiler that the method in which it appears is an iterator block. The compiler generates a class to implement the behavior that is expressed in the iterator block. In the iterator block, the yield keyword is used together with the return keyword to provide a value to the enumerator object. This is the value that is returned, for example, in each loop of a foreach statement. The yield keyword is also used with break to signal the end of iteration.

en

In a yield return statement, expression is evaluated and returned as a value to the enumerator object; expression has to be implicitly convertible to the yield type of the iterator.

MSDN ftw

[ Voor 11% gewijzigd door Rutix op 13-10-2011 09:21 ]

[Alex)]

The Mystery Behind ‘Yield Return’

[.Gertjan.]

Potverdorie, dat mooi

Net als het stukje:

C#:

public IEnumerable<User> GetUsers()  
{  
    return Dal.GetUsers().Select(ConvertDalToUser); 
}

Ik zit echt te weinig in .NET... Dit zijn mooie dingetjes die ik vaak zelf probeer op te lossen met for/while/etc... Type mezelf een RSI terwijl het dus makkelijker kan

[Rutix]

.Gertjan. schreef op donderdag 13 oktober 2011 @ 09:29:
Potverdorie, dat mooi

Net als het stukje:

C#:

public IEnumerable<User> GetUsers()  
{  
    return Dal.GetUsers().Select(ConvertDalToUser); 
}

Ik zit echt te weinig in .NET... Dit zijn mooie dingetjes die ik vaak zelf probeer op te lossen met for/while/etc... Type mezelf een RSI terwijl het dus makkelijker kan

Resharper geeft gewoon aan dat je het daarin kunt maken dus dan leer je het vanzelf !

Jemig lijkt wel of ik reclame maak voor resharper ofzo :<

[st0p]

RayNbow schreef op donderdag 13 oktober 2011 @ 06:19:
De R in K&R is er niet meer

RIP

printf("Goodbye world.\n");

[.Gertjan.]

Sjonge jonge.... Mijn Visual Studio is TRAAAAAAAAAAAAAG.... Bescheiden WPF solution ingeladen en zit gewoon geregeld meerdere seconden te wachten voordat dat ding een keer reageert... Een selectie doen in de XAML van een WPF file is gewoon bijna onmogelijk door de traagheid... WTF....

Sta je dan met je i5

[OkkE]

Zo irritant altijd, heb je een vraag; na lang zoeken vind je dan eindelijk iemand anders met het zelfde probleem; alleen maar reacties van andere met het zelfde, niemand met een oplossing.

[.Gertjan.]

OkkE schreef op donderdag 13 oktober 2011 @ 09:46:
Zo irritant altijd, heb je een vraag; na lang zoeken vind je dan eindelijk iemand anders met het zelfde probleem; alleen maar reacties van andere met het zelfde, niemand met een oplossing.

Oh dat valt nog mee, dan heb je misschien nog de indruk dat het niet op te lossen is. Vervelender is als een van de reacties van de vrager is met de mededeling: "Never mind, already fixed it"

Y U NO SHARE YOUR SOLUTION

[YopY]

.Gertjan. schreef op donderdag 13 oktober 2011 @ 09:06:
[...]

En toen wilde je weten hoeveel items erin zaten... Ehm was dat nou Count of Length Tja dan moet je wel weten of het een List of Array is In jouw geval is het inderdaad niet nodig, maar zodra je ook zaken gaat toevoegen is het zeker nuttig om te weten of je een lijst of array hebt

Mwa, da's eerder een symptoom van een bracque / inconsistente API dan van het gebruik van var.

Ik heb er iig geen moeite mee dat mijn vars / vals (in Scala) geen type erbij hebben staan - sterker nog, de enige keren dat ik moet kijken wat iets teruggeeft is als ik een Java API aanroep (aangezien dat een Java list ipv een Scala list teruggeeft. Nu zijn die twee wel door elkaar heen te gebruiken natuurlijk).

* YopY verder in Objective-C prutsen gaat met 'top secret' project