De Devschuur Coffee Corner

[_Erikje_]

of gewoon niet, net of je dan de enige ICT bent die het niet doet

documenteren is zo overrated

[alex3305]

_Erikje_ schreef op woensdag 06 oktober 2010 @ 15:58:
of gewoon niet, net of je dan de enige ICT bent die het niet doet

documenteren is zo overrated

Documenteren is zeer belangrijk, en vooral wanneer je code door meerdere mensen gebruikt kan of gaat worden. Daarnaast helpt het jezelf meer en duidelijker inzicht te krijgen in de code die je zelf schrijft, wat dan weer ten goede komt van de code kwaliteit .

---

Daarnaast heb ik net zelf een mooi stukje PHP geschreven al zeg ik het zelf. Het schiet (semi-)dynamisch een query af waarmee gebruikersgegevens worden opgehaald en netjes in een geneste array gestopt worden, waardoor het gemakkelijk bruikbaar is in de frontend van de website.

[YopY]

_Erikje_ schreef op woensdag 06 oktober 2010 @ 15:58:
of gewoon niet, net of je dan de enige ICT bent die het niet doet

documenteren is zo overrated

Joh? In dat geval, zou je precies het doel en de toepassing van Wrapper uit willen leggen? Of wat de ComponentLifecycleException toevoegt aan Java's eigen Exception en/of wanneer je hem toe moet passen? Of wat voor uitvoer de Crypt class en zijn methodes heeft? Of wat de VotingHandler precies doet en/of waar je hem voor kunt gebruiken?

m.a.w: documenteren is alleen overrated als je het zelf nooit nodig gehad hebt of dacht te hebben, of dat je nog denkt dat je alles wel weet door naar de code te kunnen kijken. Maar als je met een closed-source codebase van vele duizenden regels moet werken...

[TJHeuvel]

Hehe, lekkere documentatie bij die wrapper.

public interface Wrapper

Wrapper interface.

getUUID()

Get a UUID identifier for this object.

setId(int id)

Sets the objectid of the wrapped object.

In ieder geval, ik hoop dat _erikje_ het niet serieus bedoelde

[ZaZ]

CyCloneNL schreef op woensdag 06 oktober 2010 @ 16:57:
Hehe, lekkere documentatie bij die [url=http://api.gxdeveloperweb.com/javadoc/nl/gx/webmanager/wrapper/

Haha, ja viel me ook al op. Soms zie je ook in code van die dingen zoals

C:

i++; //tel een op bij i

De bedoeling is goed, maar zo heb je er niets aan

[TJHeuvel]

Waar ik me aan erger is incomplete comments:

C:

i++; //tel een op bij i, en return het origineel

Comment's schrijven is soms best lastig, vooral als het geforceerd wordt. Vaak is het moeilijk te benoemen, en ga je snel omschrijven wat het doet, niet hoe.

[Sebazzz]

Gewoon het juiste hoofdstuk in Code Complete 2 laten doornemen.

[Jan_V]

Probeer zelf de laatste tijd zo weinig mogelijk commentaar te schrijven, tenzij ik er echt niet uit kom met self-explaining code. Sowieso als je methoden maakt van niet meer dan 20 regels groot kun je ook weinig dingen er in doen die de naam van de methode of variabelen niet duidelijk maken. Is uiteraard nogal lastig om in een keer bij legacy projecten door te voeren

Bij een project waar ik nu mee werk heb ik eerst alle doelloze comments maar weggehaald, regels zoals ZaZ hierboven al aanhaalt.
Heb met opzet comments ook met grijze achtergrond laten weergeven in VS, zodat ze meer opvallen

[Matis]

Wikipedia: BogoMips

Had er nog nooit van gehoord, maar kwam het toevallig tegen in de phpsysinfo-class.
Kun je bij de eerstvolgende verjaardag aan de oom die denkt heel wat te weten, vragen hoeveel BogoMIPS zijn CPU heeft

Mijn Xeon E5620 @ 2.40GHz heeft overigens (volgens phpsysinfo) 4787 BogoMIPS

[Hillie]

Goed commentaar schrijven bij code is mijns inziens een kwestie van abstractievermogen. Niet iedere codeklopper is daartoe in staat, dus dan krijg je van die nietszeggende "i++; //tel 1 bij i op" comments. Goede commentaren geven duidelijkheid over het doel van een stuk code en hoe het in grote lijnen bereikt wordt, dit begeleid door meer detail waar nodig. Daarom heb ik bijvoorbeeld ook enorm de pest aan codevoorbeelden in academische werken (net voor de gein CLRS weer eens aan het doorbladeren), die kwistig met generieke variabelenamen strooien en dan een alinea nodig hebben om uit te leggen wat ieder k,l,m,n,x,y,z'tje doet.

[Sebazzz]

Hillie schreef op woensdag 06 oktober 2010 @ 22:58:
Goed commentaar schrijven bij code is mijns inziens een kwestie van abstractievermogen.

Kan je programmeren met een slecht abstractievermogen?

[Soultaker]

Goed programmeren is ook een kwestie van abstraheren. Maar er zijn natuurlijk ook genoeg mensen werkzaam als programmeur die daar minder goed in zijn, en dan krijg je inderdaad van dat zinloze commentaar omdat ze het grote plaatje niet zien. Of je die mensen nog programmeur wil noemen of PHP-codeklopper-tweede-klas daar kun je over discussiëren. (Ik heb vaak het idee dat ze juist programmeur genoemd worden, en dat de goede programmeurs dan eerder engineer of architect genoemd worden. Jammer vind ik persoonlijk.)

[ Voor 11% gewijzigd door Soultaker op 07-10-2010 00:29 ]

[D-Raven]

Soultaker schreef op donderdag 07 oktober 2010 @ 00:28:
Goed programmeren is ook een kwestie van abstraheren. Maar er zijn natuurlijk ook genoeg mensen werkzaam als programmeur die daar minder goed in zijn, en dan krijg je inderdaad van dat zinloze commentaar omdat ze het grote plaatje niet zien. Of je die mensen nog programmeur wil noemen of PHP-codeklopper-tweede-klas daar kun je over discussiëren. (Ik heb vaak het idee dat ze juist programmeur genoemd worden, en dat de goede programmeurs dan eerder engineer of architect genoemd worden. Jammer vind ik persoonlijk.)

Mee eens, een goede "programmeur"/"ontwikkelaar" kenmerkt zich door de skill om goed problemen te kunnen ontleden in zijn elementaire onderdelen en deze vervolgens in een goed model om te kunnen zetten. Als je daar al fout gaat dan wordt je code ook een grote rotzooi, dan is je kennis over een platform of bepaalde ontwikkel taal/omgeving volstrekt irrelevant.

M.a.w analytisch vermogen.

[RayNbow]

Helaas zijn er talen waarin je beperkt wordt waarover je kunt abstraheren...

[Hydra]

RayNbow schreef op donderdag 07 oktober 2010 @ 09:55:
Helaas zijn er talen waarin je beperkt wordt waarover je kunt abstraheren...

Oh? Je kunt OO programmeren in assembly. Ik denk dat de developer eerder de beperkende factor is dan de taal. Ik zie niet waarom een taal je beperkt in het analyseren van een probleem en het opdelen daarvan in z'n componenten.

Sebazzz schreef op woensdag 06 oktober 2010 @ 23:16:
Kan je programmeren met een slecht abstractievermogen?

Tuurlijk. Slechte programmeurs bij de vleet.

CyCloneNL schreef op woensdag 06 oktober 2010 @ 16:57:
Hehe, lekkere documentatie bij die wrapper.

Wrapper interface.


Get a UUID identifier for this object.

Sets the objectid of the wrapped object.

In ieder geval, ik hoop dat _erikje_ het niet serieus bedoelde

Dat soort documentatie komt ook door tools die je 'dwingen' documentatie te schrijven voor elke public member van een class. In 90% van de gevallen is dat nuttig, maar in het geval van veel typische java beans die getters en setters hebben als getName() en getId() is het echt volledig overbodig.

[ Voor 56% gewijzigd door Hydra op 07-10-2010 10:18 ]

[jip_86]

Abstract denken is toch ook zo ongeveer de enigste ingangseis voor de opleiding Informatica. Je kunt met elk profiel zo instromen vanaf de HAVO. Bij cultuur heb je dan wiskunde nodig in je pakket wat een beetje de indicatie is voor abstract denken.

[Hydra]

jip_86 schreef op donderdag 07 oktober 2010 @ 10:16:
Abstract denken is toch ook zo ongeveer de enigste ingangseis voor de opleiding Informatica. Je kunt met elk profiel zo instromen vanaf de HAVO. Bij cultuur heb je dan wiskunde nodig in je pakket wat een beetje de indicatie is voor abstract denken.

Sorry hoor, maar in mijn tijd waren er bijzonder weinig eisen bij HBO-Informatica en gezien het niveau van wat er nu van die opleiding afkomt is het echt niet beter geworden. In welk opzicht werd volgens jou 'geeist' dat iemand abstract kan denken?

[CodeCaster]

Ik ben wel een beetje van het debuggen. Maar vandaag...

De service die onder zijn eigen account in zijn eigen Application Pool draait in IIS mag lokaal gewoon schrijven naar folders waar zijn account rechten toe heeft. Als ik hem echter naar een share wil laten schrijven krijg ik op de share-directory een "access is denied" in m'n log.

De user heeft Full Control op de share, en op de directory waar hij moet schrijven heeft 'ie dat ook. De IIS-site draait als "Full (internal)", dat wil zeggen met de meest mogelijke rechten. En tóch... Auditing aangezet op de directory, en daaruit lijkt het dat hij niet eens bij de share uitkomt.

Oh. Alles qua rechten verwijderen en opnieuw instellen did the trick. Windows

Ah well. Kan ik dit mooi documenteren voor de installatie bij de klant.

[ Voor 4% gewijzigd door CodeCaster op 07-10-2010 10:44 ]

[Hydra]

CodeCaster schreef op donderdag 07 oktober 2010 @ 10:23:
Oh. Alles qua rechten verwijderen en opnieuw instellen did the trick. Windows

Ah well. Kan ik dit mooi documenteren voor de installatie bij de klant.

Wij hebben een issue met een Java tool die niet van een netwerkshare die gemapt is naar een drive (S:) kan lezen. Je kunt gewoon met CMD.exe navigeren naar die S: drive en files catten enzo, maar new File("s:\bestaandefile.txt").exists() is gewoon keihard false. Wuut? Uiteindelijk de configuratie maar zo aangepast dat 'ie van de share (//hostname/s/bestaandefile.txt) wijst en dat werkt wel.

En het leuke is dat we het op kantoor niet kunnen reproduceren, daar werkt het wel

[Matis]

Hydra schreef op donderdag 07 oktober 2010 @ 11:07:
Wij hebben een issue met een Java tool die niet van een netwerkshare die gemapt is naar een drive (S:) kan lezen. Je kunt gewoon met CMD.exe navigeren naar die S: drive en files catten enzo, maar new File("s:\bestaandefile.txt").exists() is gewoon keihard false. Wuut? Uiteindelijk de configuratie maar zo aangepast dat 'ie van de share (//hostname/s/bestaandefile.txt) wijst en dat werkt wel.

En het leuke is dat we het op kantoor niet kunnen reproduceren, daar werkt het wel

Dat is een bekent probleem binnen Windows. Hetzelfde probleem heb ik ook met PHP. Die kan niet van een network-share lezen en/of schrijven.
TENZIJ je PHP zelf een network-share laat aanmaken met dezelfde rechten, dan kan hij er ineens wel mee overweg.

[whoami]

raaaagh Access ....

Syntax error in date , terwijl ik helemaal niet zie wat er verkeerd kan zijn aan:

code:

#2010/10/06T11:34:36.127#

Heb al deze ook geprobeerd, maar steeds hetzelfde:

code:

#2010-10-06T11:34:36.127#
#20101006T11:34:36.127#

[Haan]

Gebruikt Acces wel de 'T' tussen datum en tijd?

[CodeCaster]

Was Access niet verschrikkelijk locale-afhankelijk? Zoek de verschillen:

How to store, calculate, and compare Date/Time data in Microsoft Access
How to store, calculate, and compare Date/Time data in Microsoft Access

[.oisyn]

Hydra schreef op donderdag 07 oktober 2010 @ 10:13:
[...]


Oh? Je kunt OO programmeren in assembly. Ik denk dat de developer eerder de beperkende factor is dan de taal. Ik zie niet waarom een taal je beperkt in het analyseren van een probleem en het opdelen daarvan in z'n componenten.

Mwoa, een abstractielaag opzetten in quickbasic is toch behoorlijk lastig, wegens gemis aan functie- en objectpointers

[ Voor 29% gewijzigd door .oisyn op 07-10-2010 11:45 ]

[RayNbow]

Hydra schreef op donderdag 07 oktober 2010 @ 10:13:
[...]


Oh? Je kunt OO programmeren in assembly.

Fijn dat je dat kunt, maar probeer nu eens dit in een mainstream-taal naar keuze:

code:

public class Fix<F> {
    public F<Fix<F>> in;
}

[Hydra]

.oisyn schreef op donderdag 07 oktober 2010 @ 11:45:
Mwoa, een abstractielaag opzetten in quickbasic is toch behoorlijk lastig, wegens gemis aan functie- en objectpointers

Ah, QuickBasic. Those good ol' GOTO days

Ik ben 16 jaar terug ofzo bezig geweest met een LORD kloon in quickbasic, ergste spaghetti code die ik ooit geschreven heb. Na een week programmeer-pauze kon ik al geen kaas meer maken van m'n eigen app

RayNbow schreef op donderdag 07 oktober 2010 @ 11:50:
Fijn dat je dat kunt, maar probeer nu eens dit in een mainstream-taal naar keuze:

Java:

public class Fix<F> {
    public F<Fix<F>> in;
}

Zijn generics voor jou een voorwaarde voor OO programmeren?

[ Voor 23% gewijzigd door Hydra op 07-10-2010 11:52 ]

[RayNbow]

Hydra schreef op donderdag 07 oktober 2010 @ 11:51:
[...]

Zijn generics voor jou een voorwaarde voor OO programmeren?

Ik had het over abstraheren, jij kwam met OO aanzetten. Ik vraag aan jou om een mainstream taal aan te wijzen waarin ik over typeconstructors kan abstraheren.

[.oisyn]

RayNbow schreef op donderdag 07 oktober 2010 @ 11:50:
[...]

Fijn dat je dat kunt, maar probeer nu eens dit in een mainstream-taal naar keuze:

code:

public class Fix<F> {
    public F<Fix<F>> in;
}

Ok

C++:

template<template<class> class F> class Fix
{
public:
    F<Fix<F>> in;
};

Wat het moet doen? Geen idee... Maar dat kun je zelf vast wel uitleggen

[YopY]

Zijn generics niet gewoon syntactische suiker voor casts en compile-time typesafety? (om maar een paar buzzwords te misbruiken)

Voor zover ik weet / wist worden generics in Java intern gewoon omgezet naar casts en dergelijke.

[.oisyn]

In .Net niet (daarom kun je daar wel valuetypes gebruiken en dingen new'en en zo)

[RayNbow]

.oisyn schreef op donderdag 07 oktober 2010 @ 12:01:
[...]


Ok

C++:

template<template<class> class F> class Fix
{
public:
    F<Fix<F>> in;
};

Bah... C++... Jammer dat dat nog een mainstream taal is.

Wat het moet doen? Geen idee... Maar dat kun je zelf vast wel uitleggen

Fixed points, maar dan voor datatypes.

In Haskell:

Haskell:

newtype Fix f = In {out :: f (Fix f)}

Een voorbeeld van een recursief datatype:

Haskell:

data Expr
 = Num Int
 | Add Expr Expr
 | Sub Expr Expr
 | Mul Expr Expr
 | Div Expr Expr

En nu hetzelfde datatype, maar dan gedefinieerd als een fixed point:

Haskell:

data ExprF r
 = Num Int
 | Add r r
 | Sub r r
 | Mul r r
 | Div r r

type Expr = Fix ExprF

[ Voor 0% gewijzigd door RayNbow op 07-10-2010 17:15 . Reden: typo ]

[Hydra]

RayNbow schreef op donderdag 07 oktober 2010 @ 12:01:
Ik had het over abstraheren, jij kwam met OO aanzetten. Ik vraag aan jou om een mainstream taal aan te wijzen waarin ik over typeconstructors kan abstraheren.

Ik had het over abstractie in de zin van problemen oplossen, niet de letterlijke taal-abstracties waar jij mee aankomt.

[CodeCaster]

Vijfhonderd regels gepasseerd in één Stored Procedure.

[Woy]

CodeCaster schreef op donderdag 07 oktober 2010 @ 15:09:


Vijfhonderd regels gepasseerd in één Stored Procedure.

Ik zou eerder zeggen:

[CodeCaster]

Het is een soort 'switchboard'-SP, die op zijn beurt weer een stuk of vijftien andere SP's aanroept. Er moet na het ontvangen van een soap-verzoek een bult data worden opgeslagen in diverse tabellen.

Nu kon ik ervoor kiezen om vanuit de service de vijftien SP's apart aan te roepen, of dit. Dit was sneller en imho beter te onderhouden.

Het grootste gedeelte van de code doet niets meer dan variabelen doorpassen naar aanroepen van andere SP's en eventuele returnwaarden opslaan in lokale variabelen om in een latere SP-aanroep weer te gebruiken.

[ Voor 30% gewijzigd door CodeCaster op 07-10-2010 15:42 ]

[pedorus]

whoami schreef op donderdag 07 oktober 2010 @ 11:34:
raaaagh Access ....

Syntax error in date , terwijl ik helemaal niet zie wat er verkeerd kan zijn aan:

code:

#2010/10/06T11:34:36.127#

T moet een spatie zijn. Daarnaast, als je echt milliseconden wil: MS Access Can Handle Millisecond Time Values--Really.

CodeCaster schreef op donderdag 07 oktober 2010 @ 15:09:


Vijfhonderd regels gepasseerd in één Stored Procedure.

Je gaat voor een plekje op tdwtf?

[MTWZZ]

CodeCaster schreef op donderdag 07 oktober 2010 @ 15:09:


Vijfhonderd regels gepasseerd in één Stored Procedure.

jongen, je begint net
De grootste hier is +/-1100 regels

[Soultaker]

RayNbow schreef op donderdag 07 oktober 2010 @ 12:30:
Fixed points, maar dan voor datatypes.

Ik ken fixed points en fixed point combinators, maar ik snap nog steeds niet wat hier precies gebeurt... leg eens uit? edit: Na er nog eens goed naar gekeken te hebben, lijkt Fix een fixed point combinator voor datatypes te zijn. (Ik ben niet zo bekend met de Haskell syntax, vandaar dat ik de definitie van Fix op zichzelf niet echt kan parsen). Maar wat is daar het nut van in het geval van Haskell? Fixed point combinators zijn nuttig om recursie te introduceren in systemen die dat niet direct ondersteunen (zoals ongetypeerde lambda-calculus) maar wat is het profijt daarvan in een taal als Haskell, die dat wel ondersteunt?

Ergens kun je ook té veel abstractie introduceren, ben ik bang, waardoor je werknemers met een 140+ IQ moet inhuren om je codebase te kunnen onderhouden.

[ Voor 34% gewijzigd door Soultaker op 07-10-2010 16:40 ]

[Hydra]

Woy schreef op donderdag 07 oktober 2010 @ 15:19:


Ik zou eerder zeggen:

Zo'n Oracle DBA die alle business logic in SP's wil hangen

[YopY]

Woeii, webserver valt alweer om (gisteren ook van 2 tot 7 onderuit geweest) en niemand (noch de hostingpartij, noch de ontwikkelaar van de software) weet wat er aan de hand is .

(Natuurlijk: de hostingpartij is een I&A afdeling die het er wat bij doet (ze hebben een bak bij XS4ALL te staan), en de ontwikkelaar van de software is niet helderziend. Mogelijk ligt het probleem ook binnen Tomcat.)

Tijd voor een nieuwe server.

[RayNbow]

Soultaker schreef op donderdag 07 oktober 2010 @ 16:36:
[...]

Ik ken fixed points en fixed point combinators, maar ik snap nog steeds niet wat hier precies gebeurt... leg eens uit? edit: Na er nog eens goed naar gekeken te hebben, lijkt Fix een fixed point combinator voor datatypes te zijn. (Ik ben niet zo bekend met de Haskell syntax, vandaar dat ik de definitie van Fix op zichzelf niet echt kan parsen).

De hier gebruikte syntax is de record-syntax voor datatypes. Vaak wordt een datatype of newtype als volgt gedeclareerd:

Haskell:

data Foo = Bar Int | Quux String

-- Constructors voor type Foo:
--   Bar :: Int -> Foo
--   Quux :: String -> Foo

Om een Int of een String uit een Foo te krijgen, moet je patternmatchen. Soms is patternmatchen wat omslachtig of verwarrend (bijv. wanneer een constructor veel velden kent). Zonder record-syntax zou je hulpfuncties kunnen introduceren:

Haskell:

data Person = Person String Int

getName :: Person -> String
getName (Person n _) = n

getAge :: Person -> Int
getAge (Person _ a) = a

Met record-syntax kun je dit vervangen door het volgende:

Haskell:

data Person = Person {getName :: String, getAge :: Int}

Met de eerder gegeven definitie van Fix

Haskell:

newtype Fix f = In {out :: f (Fix f)}

heb je de volgende constructor en functie:

code:

In :: f (Fix f) -> Fix f
out :: Fix f -> f (Fix f)

* RayNbow ziet trouwens dat er een "f" mist in z'n vorige post en heeft dat gefixt.

Maar wat is daar het nut van in het geval van Haskell? Fixed point combinators zijn nuttig om recursie te introduceren in systemen die dat niet direct ondersteunen (zoals ongetypeerde lambda-calculus) maar wat is het profijt daarvan in een taal als Haskell, die dat wel ondersteunt?

Door de recursieve structuur uit het oorspronkelijke Expr-datatype te distilleren kun je door ExprF aan te passen makkelijker variaties op Expr definieren.

Een goed voorbeeld kun je vinden in deze blogpost. In de blogpost begint de auteur met een datatype voor kale expressies en een datatype voor expressies met positieinformatie. Door naar de overeenkomsten en verschillen te kijken leidt hij stap voor stap Fix af.

Ergens kun je ook té veel abstractie introduceren, ben ik bang, waardoor je werknemers met een 140+ IQ moet inhuren om je codebase te kunnen onderhouden.

Dat zou best kunnen, maar abstracte concepten zijn sowieso lastig te leren. De volgende paragraaf geeft het probleem imho goed weer:

quote: http://byorgey.wordpress....e-monad-tutorial-fallacy/

Abstraction, intuition, and the “monad tutorial fallacy”
While working on an article for the Monad.Reader, I’ve had the opportunity to think about how people learn and gain intuition for abstraction, and the implications for pedagogy. The heart of the matter is that people begin with the concrete, and move to the abstract. Humans are very good at pattern recognition, so this is a natural progression. By examining concrete objects in detail, one begins to notice similarities and patterns, until one comes to understand on a more abstract, intuitive level. This is why it’s such good pedagogical practice to demonstrate examples of concepts you are trying to teach. It’s particularly important to note that this process doesn’t change even when one is presented with the abstraction up front! For example, when presented with a mathematical definition for the first time, most people (me included) don’t “get it” immediately: it is only after examining some specific instances of the definition, and working through the implications of the definition in detail, that one begins to appreciate the definition and gain an understanding of what it “really says.”
[...]

[roy-t]

Woohooo!

Net gehoord dat ik 2e ben geworden met mijn artiekel over XNA en de Farseer physics engine in de 'Sgt. Conker XNA Tutorial Contest'.

Toch fijn als je niet voor niets blogt en artikelen schrijft

Linkje uitslag: http://www.sgtconker.com/...ine-xna-tutorial-contest/

[/spam]

[Woy]

@roy-t: Gratz

[Matis]

roy-t schreef op donderdag 07 oktober 2010 @ 17:46:
Woohooo!

Net gehoord dat ik 2e ben geworden met mijn artiekel over XNA en de Farseer physics engine in de 'Sgt. Conker XNA Tutorial Contest'.

Toch fijn als je niet voor niets blogt en artikelen schrijft

Linkje uitslag: http://www.sgtconker.com/...ine-xna-tutorial-contest/

[/spam]

Waarom niet eerste

Gefeliciteerd man

[alex3305]

roy-t schreef op donderdag 07 oktober 2010 @ 17:46:
Woohooo!

Net gehoord dat ik 2e ben geworden met mijn artiekel over XNA en de Farseer physics engine in de 'Sgt. Conker XNA Tutorial Contest'.

Toch fijn als je niet voor niets blogt en artikelen schrijft

Linkje uitslag: http://www.sgtconker.com/...ine-xna-tutorial-contest/

[/spam]

Mooie tutorial heb je geschreven. Terechte tweede plaats, alhoewel de eerste plaats tutorial ook erg goed is. Ben je overigens ook al met Farseer 3 bezig? Daar ben ik laatst namelijk mee bezig geweest en deze nieuwe versie heeft toch wel wat leuke dingen georven van Box2D.

[Verwijderd]

Woei wel met een hoop andere dingen bezig dan programmeren tegenwoordig, nu bijvoorbeeld net wat onderzoeken en papers aan het lezen over afwijkingen in de hersenen bij autismepatienten.
Maarrrr, voor datzelfde vak zijn we inmiddels ook op neurale netwerken aangeland en dan is het toch opeens wel weer heel erg leuk om iets uit de mouwen te kunnen schudden

[Soultaker]

RayNbow schreef op donderdag 07 oktober 2010 @ 17:43:
De hier gebruikte syntax is de record-syntax voor datatypes.

Bedankt voor de uitleg. Ik heb 'm nu.

Een goed voorbeeld kun je vinden in deze blogpost. In de blogpost begint de auteur met een datatype voor kale expressies en een datatype voor expressies met positieinformatie. Door naar de overeenkomsten en verschillen te kijken leidt hij stap voor stap Fix af.

Dat ziet er interessant uit! Ga ik eens rustig doorlezen als ik wat minder gaar ben.

[roy-t]

alex3305 schreef op donderdag 07 oktober 2010 @ 20:30:
[...]

Mooie tutorial heb je geschreven. Terechte tweede plaats, alhoewel de eerste plaats tutorial ook erg goed is. Ben je overigens ook al met Farseer 3 bezig? Daar ben ik laatst namelijk mee bezig geweest en deze nieuwe versie heeft toch wel wat leuke dingen georven van Box2D.

Thanks,

Ik had me net helemaal verdiept in Farseer om daarna die tutorial te schrijven (zo leer ik een nieuw framework het beste) en 1 dag na het origineel inzenden van die tutorial kwam Farseer 3 officieel uit .

Op dit moment gebruik ik Farseer 2 voor Hollandia en daar ben ik zo druk mee dat ik tijdens dit project me iig niet in Farseer 3 ga inlezen. Daarna zeker wel want het is een heerlijk framework.

Edit: g**d ik sta nog steeds niet op de Hollandia site . Ben toch bijna een half jaar lead-dev geweest en nu samen met iemand anders dev (geen echte lead meer, we werken nu meestal aan verschillende dingen en de PM/artiesten sturen ons direct aan).

[ Voor 12% gewijzigd door roy-t op 07-10-2010 23:52 ]

[alex3305]

Eén tip om met Farseer 3 te beginnen is gewoon de demo suite te bekijken en lichtelijk te analyseren. Ditzelfde hebben wij ook gedaan destijds. Dan leer je er al heel veel van.

Overigens heeft wel een van onze groepsleden destijds een nieuw texture to polygon geschreven/geïmplementeerd. Heel indrukwekkend en werkte nagenoeg perfect. Dat was overigens ook één van de hoofdredenen waarom wij destijds voor Farseer 3 gekozen hebben, alhoewel deze in beta was.

[YopY]

En vandaag verder met: No Shit Sherlock.

Java:

        // Call super onSubmit
        super.onSubmit(params);

Java:

        // Write the sorted list of all entities to the reference data
        referenceData.put("allEntities", entityList);

Java:

    // Static logger for this class
    private static final Logger LOG = Logger.getLogger(PatatjeMet.class.getName());

Java:

    /**
     * Sets the Custom panel.
     * @param panel the Custom panel to set
     */
    public void setPanel(BamiBallenPanel panel) {
       this.panel = panel;
    }

Java:

    /**
     * Returns the help button.
     * @return the help button
     */
    public PanelButton getHelpButton() {
        return myHelpButton;
    }

duz.

[Jan_V]

Je zult het allemaal maar hebben moeten schrijven....

[defcon84]

PatatjeMet, BamiBallenPanel, ...

[DEiE]

defcon84 schreef op vrijdag 08 oktober 2010 @ 11:58:
PatatjeMet, BamiBallenPanel, ...

Er was iemand in mijn projectgroep twee jaar terug die zijn classes en variables echt zo moemde

[defcon84]

DEiE schreef op vrijdag 08 oktober 2010 @ 12:41:
[...]

Er was iemand in mijn projectgroep twee jaar terug die zijn classes en variables echt zo moemde

daarmee dat ie niet meer in je projectgroep zit?

[Jan_V]

Ik ga er voor het gemak van uit dat jullie niet een snackbar applicatie aan het schrijven waren?

[AtleX]

DEiE schreef op vrijdag 08 oktober 2010 @ 12:41:
[...]

Er was iemand in mijn projectgroep twee jaar terug die zijn classes en variables echt zo moemde

Ik heb een AtleX.SwissArmyKnife library en een methode in 1 van mijn projecten heet TakeOverTheWorld(), die wordt gebruikt om superuser binnen het systeem te worden.

[edit]
En daar heb ik een jaar terug ook al eens over gepost in dit topic. AtleX in "De Devschuur Coffee Corner"

[ Voor 16% gewijzigd door AtleX op 08-10-2010 13:27 ]

[YopY]

Ach, gewoon wat random woorden in elkaar geplempt, had geen zin om de echte zooi te gebruiken .

En vandaag is een dag waarop ik eigenlijk heel productief kan zijn, maar waarbij ik blijkbaar vastzit op het prutsen en doen van kleine dingen. Wat ook heel leuk / leerzaam is, overigens.

(Dat zijn overigens stukjes code uit een automagisch gegenereerde 'demo' applicatie / component, mogelijk dacht de schrijver daarvan dat hij zo duidelijk mogelijk moest zijn met dat soort dingen)

[Hillie]

Het lastige is dat dit soort voor de hand liggende commentaren (de laatste) wel aangemoedigd wordt door allerlei auto-docs tools. De eerste paar lijken me vooral op filevulling.

[flowerp]

YopY schreef op vrijdag 08 oktober 2010 @ 10:42:
En vandaag verder met: No Shit Sherlock.

Java:

    /**
     * Returns the help button.
     * @return the help button
     */
    public PanelButton getHelpButton() {
        return myHelpButton;
    }

duz.

Idd, No Shit. Zulke dingen kom ik helaas ook nog met zeer grote regelmaat tegen.

Ook dingen als:

Java:

      // public constructor
      public SomeClass() {
      }

Java:

public class Person {

    String name; // the name
    String surName; // the surname
    Date dayOfBirth; // the dayOfBirth
}

En dit dan geschreven door developers met '8 jaar Java ervaring'.

1 keer heb ik trouwens een project gezien waar een andere developer er de draak mee begon te steken:

Java:

      // public constructor
      public SomeClass() { // openings brace for constructor
          // empty line, oh no, now it has a comment. (does nothing)
      } // closing brace for constructor

Geen idee of de oorspronkelijke programmeur de hint ooit heeft opgevangen.

Iets ander geval van "no shit" commenting:

Java:

@Stateless
public class someBean {

    // Injects the entitymanager, which is a helper class to store objects in the database with Hibernate
    @PersistenceContext
    EntityManager entityManager;

}

Dat valt onder een pattern van useless commenting waar bij elk gebruik van code X, de client X gaat zitten uit te leggen. In moderatie kan dat af en toe nog wel eens handig zijn, maar als het bovenstaande comment identiek zo'n 50+ keer in de code staat dan is het toch wat minder handig...

[D-Raven]

Nog meer mensen die NHDay aan het volgen zijn op USTREAM ?

link

[alienfruit]

Zulk commentaar vind ik wel handig als ik een week later er weer mee ana de slag moet na een week andere 3-4 projecten. Beetje uitleg over het grove idee van hoe het zou moeten werken vind ik dan wel handig.

Bagger applicatie is dat Eclispe toch ook! Hangt weer eens als ik een project wil openen

[ Voor 18% gewijzigd door alienfruit op 11-10-2010 09:20 ]

[HuHu]

YopY schreef op vrijdag 08 oktober 2010 @ 10:42:
En vandaag verder met: No Shit Sherlock.

Java:

    /**
     * Sets the Custom panel.
     * @param panel the Custom panel to set
     */
    public void setPanel(BamiBallenPanel panel) {
       this.panel = panel;
    }

Java:

    /**
     * Returns the help button.
     * @return the help button
     */
    public PanelButton getHelpButton() {
        return myHelpButton;
    }

duz.

Deze twee vind ik best wel oké eigenlijk. Ze voegen weinig toe als je naar de code kijkt, maar aangezien het JavaDoc commentaar is verschijnen ze wel in een automatisch gegenereerd documentatie bestand. Grote kans ook nog dat het (deels) automatisch gegenereerd commentaar is.

Voor de volledigheid van je documentatie is het ook nodig dat je dan dit soort "nutteloze" commentaren erbij plaatst.

[Janoz]

Nou, ze zijn we degelijk nutteloos. Ten eerste staat de informatie 2x in het javadoc, maak daar dan gewoon 1x van. Ten tweede bied het geen enkele extra informatie dan de naam van de methode. Als dit blijkbaar alle informatie is die er is, dan heeft het toevoegen van javadoc ook geen enkel nut. De methode naam is blijkbaar al duidelijk genoeg op zichzelf. Zonder het javadoc komt de methode ook wel in je documentatie terecht.

@alienfruit:
Wanneer je als JEE ontwikkelaar dat stuk commentaar nodig hebt boven

Java:

    @PersistenceContext 
    EntityManager entityManager; 

dan heb je het verkeerde vak gekozen. Het php equivalent qua stupide commentaar is :

PHP:

//We starten de sessie zodat we de waarde van sommige variabelen ook nog in het volgende request weten
session_start()

Ja, ik weet dat het ene gaat over ORM en het andere over sessies. Waar het meer om gaat is dat je in je commentaar uit moet leggen wat er zo vreemd* is aan je eigen applicatie. Je moet niet gaan lopen uitleggen hoe het platform werkt. Je mag wel verwachten dat degene die met je project bezig is dat weet/zelf uit kan zoeken.

* vreemd: Als je code compleet normaal en self explaining was dan had je theoretisch gezien helemaal geen commentaar nodig.

[jbdeiman]

@Janoz
Het is bijna niet te doen je code compleet self explaining te houden. => Niet zonder goede comments.
Denk bijvoorbeeld aan een functie waarin verschillende controles (dit kunnen voor elk soort controle weer andere methods zijn) worden uitgevoerd.

Bijv. bij de aanroep van de functie zal je boven die functie zetten wat die allemaal controleert/ waarop die controleert:
dit:

PHP:

if(check_input($value) )
{
    //do something
}

is natuurlijk op zich wel duidelijk, maar in de check_input() functie zal je wel moeten aangeven waarop die controleert/ wat er gebeurt of uitgefilterd wordt en natuurlijk ook wat er gereturnt wordt.

[BM]

Aargh.

Al hele dag bezig om te achterhalen waarom een bepaalde webrequest niet uitgevoerd word. Timeout op 5 minuten, code binnen try-catch blok, overal logstatements, maar niks helpt.... zodra de code bereikt word lijkt het hele systeem te stoppen. Geen foutmelding, geen logging, geen breakpoints dit hitten, niks...

Zo word problemen oplossen toch knap lastig...

[Megamind]

BM schreef op maandag 11 oktober 2010 @ 11:08:
Aargh.

Al hele dag bezig om te achterhalen waarom een bepaalde webrequest niet uitgevoerd word. Timeout op 5 minuten, code binnen try-catch blok, overal logstatements, maar niks helpt.... zodra de code bereikt word lijkt het hele systeem te stoppen. Geen foutmelding, geen logging, geen breakpoints dit hitten, niks...

Zo word problemen oplossen toch knap lastig...

En je kan niet je debugger stap voor stap laten lopen om te kijken waar het fout gaat?

[jbdeiman]

Ik weet niet waar je alles logt, maar ik doe vaak zoiets:
echo 'hier komt die 1';
echo 'hier komt die 2';

of iets vergelijkbaars in PHP. Meteen aan het begin bij de request, en op elk punt waar het mis zou kunnen gaan. Dan kan je in elk geval de plaats van het probleem waarschijnlijk lokaliseren.

[Janoz]

jbdeiman schreef op maandag 11 oktober 2010 @ 10:13:
@Janoz
Het is bijna niet te doen je code compleet self explaining te houden. => Niet zonder goede comments.
Denk bijvoorbeeld aan een functie waarin verschillende controles (dit kunnen voor elk soort controle weer andere methods zijn) worden uitgevoerd.

Klopt. Ik heb het ook over theoretisch. De 'no shit sherlock'-voorbeelden van hierboven zijn echter keurige voorbeelden van code die het commentaar blijkbaar helemaal niet nodig hebben. Je zou eigenlijk wel moeten streven naar code die zo min mogelijk commentaar nodig heeft. Als je echt een enorme bak commentaar bij je methode hebt dan is die methode blijkbaar veel te ingewikkeld en is het dus een kandidaat om gerefactored te worden naar een wat simpelere vorm.

Bijv. bij de aanroep van de functie zal je boven die functie zetten wat die allemaal controleert/ waarop die controleert:
dit:

PHP:

if(check_input($value) )
{
    //do something
}

is natuurlijk op zich wel duidelijk, maar in de check_input() functie zal je wel moeten aangeven waarop die controleert/ wat er gebeurt of uitgefilterd wordt en natuurlijk ook wat er gereturnt wordt.

Het werkelijke probleem is dus eigenlijk dat die functie veel te veel verantwoordelijkheden heeft .

[Alex)]

Duidelijk maandagochtend: de SharePoint-webapplicatie waarmee ik verder wil devven geeft alleen maar 404's...

[alienfruit]

@Janoz: Aah, okay. Dat is inderdaad overbodig. Maar ik zet wel commentaar neer bij magische numbers voor het tekenen van figuren of bugs in de runtime. Of overige hot fixes.

[CodeCaster]

quote: http://thedailywtf.com/Ar...mentation-Done-Right.aspx

• Requirements Documentation are produced to capture what the business/customer believes the software should do. Of course, Acceptance testing often validates that what sounds good on paper doesn't work as well in practice, and usually these problems are found at the last minute, leaving the requirements document woefully out of date. They're best archived.
• Design Documentation includes things like Class Diagrams, which can be helpful for discussing initial design concepts. But like requirements, they rarely keep with the first development iteration, let alone remain relevant for future developers. As such, they too should be archived.

Ik vind dat Alex hier overdrijft, en zelfs neigt naar cowboy coding! Ik denk dat hij in dit geval een beetje te veel uitgaat van de ideale wereld waar hij zelf eerder voor waarschuwt. Hij schrijft immers voornamelijk zijn eigen software waar zijn klanten mee moeten leren werken, en niet zoals zo velen van ons software voor klanten waarbij jij de gedachtengang van de klant moet vertalen naar code.

Je hebt geen garantie dat de medewerker van de klant die de opdracht geeft of de programmeur die het coden doet over vijf jaar nog bij de respectievelijke bedrijven werkt. Kennis kan verloren gaan. Daar zit je dan, zonder requirements-en design-documentatie en zonder programmeur die de "briljante" software heeft geschreven en met de klant die een aanpassing wil.

[Haan]

alienfruit schreef op maandag 11 oktober 2010 @ 11:33:
@Janoz: Aah, okay. Dat is inderdaad overbodig. Maar ik zet wel commentaar neer bij magische numbers voor het tekenen van figuren of bugs in de runtime. Of overige hot fixes.

Magic numbers moet je sowieso zoveel mogelijk voorkomen Als je daar een (const / final) variabele van maakt met de juiste naam, heb je er ook geen commentaar meer voor nodig

[ Voor 44% gewijzigd door Haan op 11-10-2010 11:36 ]

[alex3305]

jbdeiman schreef op maandag 11 oktober 2010 @ 11:14:
Ik weet niet waar je alles logt, maar ik doe vaak zoiets:
echo 'hier komt die 1';
echo 'hier komt die 2';

of iets vergelijkbaars in PHP. Meteen aan het begin bij de request, en op elk punt waar het mis zou kunnen gaan. Dan kan je in elk geval de plaats van het probleem waarschijnlijk lokaliseren.

Ik doe altijd hetzelfde als ik iets niet kan vinden of wanneer iets niet werkt op een onverklaarbare wijze. Wat je daarnaast ook nog kunt doen, wanneer de pagina automatisch gerefreshed wordt, is:

PHP:

echo '<script type="text/javascript">alert("Hier komt die 1")</script>';

Daarnaast wil display errors aanzetten in de WAMP/php.ini weleens flink van pas komen!

[alienfruit]

Magic numbers moet je sowieso zoveel mogelijk voorkomen Als je daar een (const / final) variabele van maakt met de juiste naam, heb je er ook geen commentaar meer voor nodig

Hehe, klopt helemaal... bedoelde meer hoe ik het aan de waarde kwam (komt het uit het psd of niet etc.)

[ Voor 10% gewijzigd door alienfruit op 11-10-2010 11:48 ]

[BM]

Megamind schreef op maandag 11 oktober 2010 @ 11:11:
[...]

En je kan niet je debugger stap voor stap laten lopen om te kijken waar het fout gaat?

Heb de fout gevonden.... had de MSDN documentatie wat nauwkeurig moeten doorlezen

http://msdn.microsoft.com...t.getresponse(VS.90).aspx
When using the POST method, you must get the request stream, write the data to be posted, and close the stream. This method blocks waiting for content to post; if there is no time-out set and you do not provide content, the calling thread blocks indefinitely.

* BM voelt zich best stom

[YopY]

HuHu schreef op maandag 11 oktober 2010 @ 09:21:
[...]

Deze twee vind ik best wel oké eigenlijk. Ze voegen weinig toe als je naar de code kijkt, maar aangezien het JavaDoc commentaar is verschijnen ze wel in een automatisch gegenereerd documentatie bestand. Grote kans ook nog dat het (deels) automatisch gegenereerd commentaar is.

Voor de volledigheid van je documentatie is het ook nodig dat je dan dit soort "nutteloze" commentaren erbij plaatst.

D'r zit wat in natuurlijk. Maar dit is eigenlijk triviale documentatie, dat je ook kunt laten genereren. Jammer dat Javadoc dat niet zelf al doet, eigenlijk. Pas als er meer gebeurt dan dat de functienaam aangeeft zou je moeten documenteren.

(Overigens zijn setters en getters eigenlijk passé, helaas zijn ze nog nodig in een aantal use cases (dwz met externe libraries, Spring in dit geval).

[Janoz]

Aangezien ik het idee heb dat je een hengel uitgooit hap ik maar even toe: Waarom zijn Getters en Setters passé? (En dan neem ik niet aan dat je iets als Lombok bedoeld)

[alex3305]

Getters en Setters zijn mijn inziens handig om de toegankelijkheid van bepaalde velden te controleren. Waarnaast je ook logica uit kunt voeren wanneer een bepaalde waarde gezet of opgevraagd wordt. Beide zaken worden lastiger naarmate je alleen maar velden zult gebruiken.

Overigens vind ik zogenaamde properties (en vooral auto-properties), zoals deze in onder andere C# zitten wel mooier dan get- en set-methodes.

[Haan]

Hoe zit dan nu met getters/setters in Java? Als ze 'passé' zijn neem ik aan dat er een betere constructie voor is intussen? (à la properties in .NET). Ik neem tenminste aan dat jullie niet terug gaan naar public fields

[defcon84]

Haan schreef op maandag 11 oktober 2010 @ 13:57:
Hoe zit dan nu met getters/setters in Java? Als ze 'passé' zijn neem ik aan dat er een betere constructie voor is intussen? (à la properties in .NET). Ik neem tenminste aan dat jullie niet terug gaan naar public fields

properties in .NET doen niets anders dan getters en setters maken, niet?

[pedorus]

defcon84 schreef op maandag 11 oktober 2010 @ 15:26:
[...]

properties in .NET doen niets anders dan getters en setters maken, niet?

Het is het verschil in leesbaarheid tussen 8 regels of 1 regel code, en [Propertynaam]= ipv set[Propertynaam](). Typisch stukje .net:

C#:

    public string Name { get; set; }

[Janoz]

Het enige verschil is dat het in .NET wat syntactische suiker is en in Java een sneltoets combo van je IDE. De laatste heeft vervolgens wel het nadeel dat het niet snel zichtbaar is wanneer er is anders dan de standaard get of set gebeurt. Lombok is daarvoor wel een mooie oplossing. Dan heb je hetzelfde als bij .NET.

Ik ben echter nog steeds nieuwsgierig naar de onderbouwing bij YopY's statement.

[Woy]

defcon84 schreef op maandag 11 oktober 2010 @ 15:26:
[...]

properties in .NET doen niets anders dan getters en setters maken, niet?

Ja het is alleen een iets andere syntax, maar uiteindelijk is er gewoon een get/set methode. Het voordeel van de auto properties is dat die ook automatisch de implementatie doet, en je die eventueel altijd later nog anders in kunt vullen zonder je publieke interface te veranderen.

[ Voor 24% gewijzigd door Woy op 11-10-2010 15:44 ]

[CodeCaster]

pedorus schreef op maandag 11 oktober 2010 @ 15:32:
[...]

Het is het verschil in leesbaarheid tussen 8 regels of 1 regel code, en [Propertynaam]= ipv set[Propertynaam](). Typisch stukje .net:

C#:

    public string Name { get; set; }

Een beter voorbeeld vind ik:

C#:

    public string Name { get; private set; }

[ Voor 1% gewijzigd door CodeCaster op 11-10-2010 15:48 . Reden: Moet ik het wel goed doen... ]

[Dricus]

In .NET heeft die syntactische suiker ook nog wel gevolgen voor hoe die getters en setters in je assembly terecht komen. Open maar eens een assembly in ILDASM. Dan zie je dat er voor properties netjes een get_Property method en een set_Property method is. Daarnaast zie je dat er ook een property wordt gedeclareerd waarin verwezen wordt naar deze getter en setter. Ik neem aan dat de runtime voor het benaderen van properties dus eerst dit record bijlangs zal moeten (op z'n minst één keer).

Het verschil met handmatig getters en setters maken is naast de syntax dan dus ook dat het op runtime niveau een klein beetje anders werkt. Properties in .NET zijn dus wel ietsiepietsie meer dan alleen syntactische suiker. Het verschil is klein, maar het is er wel .

[.oisyn]

Dricus schreef op maandag 11 oktober 2010 @ 15:47:
Ik neem aan dat de runtime voor het benaderen van properties dus eerst dit record bijlangs zal moeten (op z'n minst één keer).

Bij het jitten ja. Als je een method aanroept gaat hij ook niet @ runtime een string-based lookup doen op de methodnaam. Uiteindelijk compilet dat gewoon naar een directe verwijzing.

[Dricus]

.oisyn schreef op maandag 11 oktober 2010 @ 15:50:
Bij het jitten ja. Als je een method aanroept gaat hij ook niet @ runtime een string-based lookup doen op de methodnaam. Uiteindelijk compilet dat gewoon naar een directe verwijzing.

Ik zat m'n uitspraak net even te verifiëren en wilde mezelf net even gaan corrigeren op basis van mijn bevindingen, maar je bent me voor . Zal die registratie van properties in assemblies dan dus alleen ten behoeve van de compiler en code completion/browsen in Visual Studio zijn?

[MrPepper]

Damn, ik wordt hier als PHP beginner echt helemaal hysterisch...
Waarom krijg is als ik de volgende code schrijft:

PHP:

<?php
setlocale(LC_ALL, 'nl_NL');
echo date("j F");
?>

Niet gewoon 12 oktober (dus in het nederlands?). Nu is de uitvoer nog steeds engels, iemand enig idee wat ik fout doe?

[Verwijderd]

Hmm, leuk om er naar 2 uur debuggen achter te komen dat je een reserved woord gebruikt als modelnaam...

[Voutloos]

MrPepper schreef op dinsdag 12 oktober 2010 @ 23:50:
Damn, ik wordt hier als PHP beginner echt helemaal hysterisch...
Waarom krijg is als ik de volgende code schrijft:

PHP:

<?php
setlocale(LC_ALL, 'nl_NL');
echo date("j F");
?>

Niet gewoon 12 oktober (dus in het nederlands?). Nu is de uitvoer nog steeds engels, iemand enig idee wat ik fout doe?

Controleer altijd de return value van alle system calls. Dus wat vertelt setlocale jou?

[MrPepper]

Uhm, ik vind het een beetje genant om te zeggen maar return values heb ik tot nu toe nog niet behandelt, ik kan zo 1,2,3 ook niet googlen hoe je deze opvraagt. Dus; hoe vraag je return values op?

[Verwijderd]

PHP:

<?php
$var = setlocale(LC_ALL, 'nl_NL');
?>

[Styxxy]

MrPepper schreef op woensdag 13 oktober 2010 @ 00:17:
Uhm, ik vind het een beetje genant om te zeggen maar return values heb ik tot nu toe nog niet behandelt, ik kan zo 1,2,3 ook niet googlen hoe je deze opvraagt. Dus; hoe vraag je return values op?

Daarvoor is de documentatie raadplegen handig . Voor php kan je die op http://www.php.net/ vinden.

In dit geval: http://be.php.net/manual/en/function.setlocale.php, hij geeft dus FALSE terug als het niet lukt.
(De oorzaak van jouw probleem kan bijvoorbeeld liggen aan het feit dat de NL-locals niet geïnstalleerd zijn op die server.)

[.oisyn]

En toen ging je de documentatie van date() eens lezen

To format dates in other languages, you should use the setlocale() and strftime() functions instead of date().

C++:

setlocale(LC_ALL, 'nl_NL');
echo strftime("%e %B");

13 oktober

[ Voor 18% gewijzigd door .oisyn op 13-10-2010 00:30 ]

[MrPepper]

Oké bedankt allen, het is als beginner soms een beetje onoverzichtelijk maar fijn dat jullie me even op weg hebben geholpen! (ik moest trouwens setlocale(LC_ALL, 'nld_NLD'); gebruiken omdat mijn server via windows liep)

[YopY]

Janoz schreef op maandag 11 oktober 2010 @ 13:08:
Aangezien ik het idee heb dat je een hengel uitgooit hap ik maar even toe: Waarom zijn Getters en Setters passé? (En dan neem ik niet aan dat je iets als Lombok bedoeld)

ach, meer een soort van onderbuikgevoel dat die dingen in veel gevallen niet nodig zijn. Een voorbeeld uit mijn eigen ervaring: je hebt een model class met informatie dat ook in een database staat. De klassieke manier om een object van dat type te vullen met de informatie uit de database is door in de functie die de query uitvoert door de resultaten te lopen en per veld een setter aan te roepen.

Een alternatieve manier zou zijn om deze verantwoordelijkheid aan de class zelf door te geven, door een constructor of factory method te maken die op basis van de resultset het object initialiseert of een nieuwe instantie aanmaakt met de resultaten in de resultset.

Zo'n zelfde object wordt ook wel beheerd en bijgewerkt door een formulier aan de gebruikerskant. In plaats van in een controller (of via de viewlaag zelfs, spring binding) getters / setters aan te roepen met nieuwe gegevens zou je ook een ctor of update methode toe kunnen passen die de invoer zelf verwerkt.

Mogelijk meer een intern idee dan iets uit ervaring, overigens, gewoon iets dat ik vaker toe wil passen. Ik heb het idee dat, en dan vooral bij java, er uit automatisme een set setters / getters wordt toegevoegd voor (bijna) alle velden, terwijl dat eigenlijk niet eens zo vaak nodig is. Maar dat is iets waar ik nog eens mee moet werken. Moet nodig een andere baan zien te vinden waar ik echt mag programmeren, .

iig, ik zie dat de discussie boven mij ontaard is in iets van syntax en regels code, maar ik doel meer op de daadwerkelijke noodzaak van setters / getters en mogelijke design patterns (om maar een buzzword toe te voegen) waardoor die dingen in zijn geheel niet meer nodig zijn. Ik zal eens een voorbeeld bedenken en een aantal manieren om deze te benaderen.

Voorbeeld 1: Standaard model-object met setters en getters voor de verschillende properties.

Java:

class Car {
    private Brand brand;
    private String modelName;
    private Engine engine;
    private List<Wheel> wheels;
    
    public void setBrand(Brand brand);
    public void setModelName(String modelName);
    public void setEngine(Engine engine);
    public void setWheels(List<Wheel> wheels);
    public void addWheel(Wheel wheel);
    
    public Brand getBrand();
    public String getModelName();
    public Engine getEngine();
    public List<Wheel> getWheels();
}

Voorbeeld 2: 'Immutable' implementatie, alleen getters, properties worden ingesteld in de ctor:

Java:

class Car {
    private Brand brand;
    private String modelName;
    private Engine engine;
    private List<Wheel> wheels;
    
    public Car(Brand brand, String modelName, Engine engine, List<Wheel> wheels) {
        // setje validaties
        this.brand = brand;
        this.modelName = modelName;
        this.engine = engine;
        this.wheels = wheels;
    }
    
    public Brand getBrand();
    public String getModelName();
    public Engine getEngine();
    public List<Wheel> getWheels();
}

Voorbeeld 3: Immutable met factory methods op basis van een database ResultSet en een Map (mogelijk formulierinput):

Java:

class Car {
       // snip
    
    public static List<Car> fromResultSet(ResultSet resultSet) {
        List<Car> results = new ArrayList<Car>();
        while (rs.next()) {
            results.add(buildFromResultSet(resultSet);
        }
    }
    
    private static Car buildFromResultSet(ResultSet resultSet) {
        if (rs.isBeforeFirst()) {
            throw new IllegalStateException("blargh, resultset moet eerst hasnext doen enso");
        }
        return new Car(Brand.fromResultSet(resultSet), rs.getString("modelName"), Engine.fromResultSet(resultSet), Wheel.fromResultSet(resultSet));
    }
    
    public static Car fromMap(Map<String, Object> map) {
        return new Car(Brand.fromMap(map), map.get("modelName"), Engine.fromMap(map), Wheel.fromMap(map));
    }
}

Voorbeeld 4: Mutable dmv een invoer-object (zoals iets uit een formulier):

Java:

        // snip
    public static Car updateFromForm(Map<String, String> map) {
        this.modelName = map.get("modelName");
        // etc
    }

Voorbeeld 5: Rij in database pleuren zonder getters:

Java:

    // NamedPreparedStatement bestaat niet vzviw, heb het zelf even bedacht omdat je 
    // met een gewone prepared statement een parameterIndex mee moet geven. Omdat
    // deze methode / deze class daar niks vanaf weet moet het zo maar even.
    public toStatement(NamedPreparedStatement statement) {
        this.brand.toStatement(statement);
        statement.setString("modelName", modelName);
        this.engine.toStatement(statement);
        for (Wheel w : this.wheels) {
            w.toStatement(statement);
        }
    }

Na een paar voorbeelden heb ik het idee dat mijn voorbeeld-class (3 objecten en maar één standaard ding) misschien niet optimaal is. Maar het idee zou wel duidelijk moeten zijn - door gebruik te maken van factory methods en dergelijke heb je geen setters of getters meer nodig. En ik meen me te herinneren dat veel mensen zo'n soort aanpak een goed iets vinden, omdat je zo de representatie van een bepaald object in een database binnen de class zelf houdt. De boze buitenwereld hoeft zo niet te weten dat een Car een Engine heeft, zolang dat niet voor de boze buitenwereld van praktisch nut is.

Natuurlijk zijn er genoeg voorbeelden te bedenken waar dat wel bij nodig zou zijn. Natuurlijk krijg je zo ook een class dat behoorlijk veel verantwoordelijkheid krijgt (maar die verantwoordelijkheid kun je weer splitsen, ook zonder je interne informatie publiek toegangkelijk te maken).

Of dit alles ook daadwerkelijk betere code oplevert... nouja, dat weet ik niet, ik heb het nog nooit echt toe kunnen passen. Alles is dan ook volledig theoretisch.

[.oisyn]

Immutable objecten zijn overigens erg handig voor concurrency en STM. Gezien de opkomst van de noodzaak van multicore programming en daarmee multicore design patterns heb je dus weldegelijk gelijk dat getters en setters passé zijn , desalniettemin zou ik dat niet zo durven stellen.

[ Voor 9% gewijzigd door .oisyn op 13-10-2010 11:55 ]

[roy-t]

Achievements voor programmeurs: http://forums.somethingaw...read.php?threadid=3355600

erg grappig

[ Voor 42% gewijzigd door roy-t op 13-10-2010 13:07 ]

[YopY]

.oisyn schreef op woensdag 13 oktober 2010 @ 11:54:
Immutable objecten zijn overigens erg handig voor concurrency en STM. Gezien de opkomst van de noodzaak van multicore programming en daarmee multicore design patterns heb je dus weldegelijk gelijk dat getters en setters passé zijn , desalniettemin zou ik dat niet zo durven stellen.

Mijn verwoordingen zijn in een groot aantal gevallen behoorlijk onjuist en/of overdreven, toegegeven .

En nu wil ik ook achievements op de werkvloer, geintegreerd in Trac / SVN, Eclipse en mijn email. Zo van "Refer to the readily available documentation 50 times" en de onmogelijk te halen "finish all requirements within budget and time and acceptable quality"-achievement.

[Laurens-R]

"finish all requirements within budget and time and acceptable quality"

Dat is sowieso een onmogelijk achievement, omdat het blijkbaar heel erg moeilijk is om te definieeren wat acceptable quality uberhaubt is.