[alg] Slechtste programmeervoorbeelden deel 4

[MBV]

C#:

isInt("1234fuuuuu!");

[YakuzA]

Haan schreef op woensdag 15 augustus 2012 @ 12:05:
Ik heb weer eens een echt pareltje gevonden

C#:

//Haal de eerste 4 nummers uit het textveld
int i = ConvertString(PostalCode.Substring(0, 4));

private bool isInt(string strNr)
{
    if (strNr == "0" || strNr == "1" || strNr == "2" || strNr == "3" || strNr == "4" || strNr == "5" ||
        strNr == "6" || strNr == "7" || strNr == "8" || strNr == "9")
    {
        return true;
    }
    return false;
}

private int ConvertString(string strNumber)
{
    if (isInt(strNumber.Substring(0, 1)) && isInt(strNumber.Substring(1, 1)) && isInt(strNumber.Substring(2, 1)) &&
        isInt(strNumber.Substring(3, 1)))
    {
        return Convert.ToInt32(strNumber);
    }
    return 0;
}

C#:

ConvertString("1234OepsException");

[Wijnbo]

Haan schreef op woensdag 15 augustus 2012 @ 12:05:
Ik heb weer eens een echt pareltje gevonden

C#:

//Haal de eerste 4 nummers uit het textveld
int i = ConvertString(PostalCode.Substring(0, 4));

private bool isInt(string strNr)
{
    if (strNr == "0" || strNr == "1" || strNr == "2" || strNr == "3" || strNr == "4" || strNr == "5" ||
        strNr == "6" || strNr == "7" || strNr == "8" || strNr == "9")
    {
        return true;
    }
    return false;
}

private int ConvertString(string strNumber)
{
    if (isInt(strNumber.Substring(0, 1)) && isInt(strNumber.Substring(1, 1)) && isInt(strNumber.Substring(2, 1)) &&
        isInt(strNumber.Substring(3, 1)))
    {
        return Convert.ToInt32(strNumber);
    }
    return 0;
}

Dit is wat mij betreft een prima redenen om iemand te ontslaan of op cursus-uit-eigen-zak te sturen. Persoon had werkelijk geen idee waar ie mee bezig was en schijnbaar niet te ballen om collega's te vragen die er WEL verstand van hadden. Dit is ongeveer het zelfde als een buschauffeur die altijd in de 1e versnelling rijdt omdat ie niet beter weet ("maar het werkt toch")

Sowieso, PostalCode wtf? ZipCode komt eerst, met een int.TryParse op de substring.

Verder doet de algemene naamgeving van de methoden me vermoeden dat dit in een framework zit of een copy-paste is van een ander stuk code, wat het dubbel zo erg maakt.

[ Voor 14% gewijzigd door Wijnbo op 15-08-2012 14:11 ]

[CMG]

Sowieso, PostalCode wtf? ZipCode komt eerst, met een int.TryParse op de substring

Postalcode en zipcode zijn het zelfde...

[ Voor 56% gewijzigd door CMG op 15-08-2012 21:45 ]

[Soultaker]

Amras schreef op woensdag 15 augustus 2012 @ 13:03:

C#:

isInt("42")  // false.. FFFFUUUUUUUUU!! :( 

MBV schreef op woensdag 15 augustus 2012 @ 13:38:

C#:

isInt("1234fuuuuu!");

YakuzA schreef op woensdag 15 augustus 2012 @ 13:52:

C#:

ConvertString("1234OepsException");

Volgens mij hebben jullie allemaal niet door dat het hier om private functies gaat die helemaal nooit op deze manier aangeroepen kunnen worden. De code is lelijk en omslachtig maar werkt tenminste wel zoals het moet.

[CMG]

Knap dat je die code durft te verdedigen...

[Grijze Vos]

Soultaker schreef op donderdag 16 augustus 2012 @ 01:21:
[..]
Volgens mij hebben jullie allemaal niet door dat het hier om private functies gaat die helemaal nooit op deze manier aangeroepen kunnen worden. De code is lelijk en omslachtig maar werkt tenminste wel zoals het moet.

En ondanks dat verdient deze programmeur een nekschot.

[armageddon_2k1]

Misschien is dit wel z'n eerste implementatie waardoor de unit tests succeeden
Het mooier maken komt daarna.

[RayNbow]

Soultaker schreef op donderdag 16 augustus 2012 @ 01:21:
[...] De code is lelijk en omslachtig maar werkt tenminste wel zoals het moet.

Uitgaande van strings ter lengte 4 is de vraag of het wenselijk is dat zowel "0000" als "fail" worden geconverteerd naar 0. Nu zijn dit beide geen geldige Nederlandse postcodes en 0 zou de waarde kunnen zijn die ongeldige postcodes representeert, maar dan zit je met het probleem dat een ongeldige postcode als "0123" door de bovenstaande code niet naar 0 omgezet wordt.

[alienfruit]

Ik zou eerst TryParse gebruiken en als dit successvol controleren of het een geldige postcode is. Maar goed, dat is alleen zinvol als je weet dat je alleen Nederlandse postcodes hebt te controleren

[Mormeldier]

Misschien een beetje vergaand, maar als we OO bezig zijn schrijf je toch een ZipCode class met een tryParse() methode die netjes de string checkt a.d.h.v. regular expressions en vervolgens ontleedt? Zo kun je makkelijk uitbreiden naar andere landen.

Maar goed, in mijn beginjaren heb ook wel dergelijke code geschreven En als je embedded bezig bent is die code zo slecht nog niet, want dan heb je geen kant-en-klaar framework met tryParse o.i.d.

[.oisyn]

De hele WTF is dat de cijfers van de postcode geconverteerd worden naar int. Waarom zou je dat in hemelsnaam willen?

[Amras]

Soultaker schreef op donderdag 16 augustus 2012 @ 01:21:
[...]


[...]


[...]


Volgens mij hebben jullie allemaal niet door dat het hier om private functies gaat die helemaal nooit op deze manier aangeroepen kunnen worden. De code is lelijk en omslachtig maar werkt tenminste wel zoals het moet.

Ook voor private functies geldt dat je ze een fatsoenlijke naam moet geven. Een functie die IsInt heet en false teruggeeft voor "42" heeft niet helemaal de juiste naam, dat zou eerder IsDigit o.i.d. moeten zijn.

[Haan]

.oisyn schreef op donderdag 16 augustus 2012 @ 09:50:
De hele WTF is dat de cijfers van de postcode geconverteerd worden naar int. Waarom zou je dat in hemelsnaam willen?

Dat kan ik je wel vertellen, obv die cijfers wordt een postcodegebied opgezocht, waarbij de records een start- en eindrange hebben (dus bijv. 1000 - 1100).
Verder komt deze code uit een Windows workflow, dat dus bij een adres het bijhorende postcodegebied opzoekt.

[Janoz]

Haan schreef op donderdag 16 augustus 2012 @ 10:13:
[...]

Dat kan ik je wel vertellen, obv die cijfers wordt een postcodegebied opgezocht, waarbij de records een start- en eindrange hebben (dus bijv. 1000 - 1100).
Verder komt deze code uit een Windows workflow, dat dus bij een adres het bijhorende postcodegebied opzoekt.

Ja en? Daarvoor hoeven het toch helemaal geen integers te worden?

[Matis]

Misschien willen ze pythagoras toepassen om de postcodes om zo de onderliggende afstand tussen de gemeentes te bepalen

[Zsub]

Amras schreef op donderdag 16 augustus 2012 @ 09:55:
[...]

Ook voor private functies geldt dat je ze een fatsoenlijke naam moet geven. Een functie die IsInt heet en false teruggeeft voor "42" heeft niet helemaal de juiste naam, dat zou eerder IsDigit o.i.d. moeten zijn.

code:

isInt("42"); //false, "42" is een string
isInt(42); //true, 42 is, inderdaad, een integer

[Hydra]

Janoz schreef op donderdag 16 augustus 2012 @ 10:19:
Ja en? Daarvoor hoeven het toch helemaal geen integers te worden?

Uit een lijst alle integers tussen 1000 en 1100 zoeken is wat efficienter dan op basis van stringcompares. Niks mis met voor dat doeleinde postcodes naar een int om te zetten.

Zelf hebben wij ook een toepassing waarbij we via een lookup in een matrix de afstand tussen 2 postcodes (die zijn voorberekend) kunnen opzoeken. Daarvoor doen we ook een integerconversie omdat dat efficienter op te slaan is.

Een andere versie van die toepassing doet het op basis van strings en lookups in een long/lat tabel. Omdat deze ook voor alle buitenlandse postcodes moet werken zijn daar postcodes wel gewoon strings.

Matis schreef op donderdag 16 augustus 2012 @ 10:21:
Misschien willen ze pythagoras toepassen om de postcodes om zo de onderliggende afstand tussen de gemeentes te bepalen

Als je die postcode gebruikt als index in een array van long/lat of RD-coordinaten is het wel handig deze naar int om te zetten. Zie daar het probleem ook niet zo, je weet in NL zeker dat het 4 cijfers zijn en dat ze in de range 1000-9999 vallen.

[ Voor 23% gewijzigd door Hydra op 16-08-2012 10:28 ]

[CMG]

De beste manier om dit te doen (imho) is postcode met een regex valideren (totaal) en dan nummerieke gedeelte met een group capture er uit halen om het te matchen tegen een range. Zoek je niet naar een specifiek formaat, dan is int.TryParse idd de beste oplossing.

[Hydra]

CMG schreef op donderdag 16 augustus 2012 @ 10:26:
De beste manier om dit te doen (imho) is postcode met een regex valideren (totaal) en dan nummerieke gedeelte met een group capture er uit halen om het te matchen tegen een range. Zoek je niet naar een specifiek formaat, dan is int.TryParse idd de beste oplossing.

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

[Matis]

CMG schreef op donderdag 16 augustus 2012 @ 10:26:
De beste manier om dit te doen (imho) is postcode met een regex valideren (totaal) en dan nummerieke gedeelte met een group capture er uit halen om het te matchen tegen een range. Zoek je niet naar een specifiek formaat, dan is int.TryParse idd de beste oplossing.

Waarom een regex? trim (links rechts en intern), strlen == 6, substr(0,4) en dan tryparse

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

Edit; Ninja'd

[ Voor 4% gewijzigd door Matis op 16-08-2012 10:30 ]

[.oisyn]

Hydra schreef op donderdag 16 augustus 2012 @ 10:26:
[...]


Uit een lijst alle integers tussen 1000 en 1100 zoeken is wat efficienter dan op basis van stringcompares.

Bij dom geïmplementeerde string compares wel ja. Maar een postcode bestaat uit 4 chars, dus 32 bits, en die kun je dus prima in 1 keer comparen net zo snel als je een int kan comparen.

[MBV]

Soultaker schreef op donderdag 16 augustus 2012 @ 01:21:
[...]


[...]


[...]


Volgens mij hebben jullie allemaal niet door dat het hier om private functies gaat die helemaal nooit op deze manier aangeroepen kunnen worden. De code is lelijk en omslachtig maar werkt tenminste wel zoals het moet.

Als je ergens een functie van maakt, moet je hem zodanig maken dat hij in een andere context ook werkt (IMHO). Waarom zou je er anders een functie van maken?

.oisyn schreef op donderdag 16 augustus 2012 @ 10:30:
[...]

Bij dom geïmplementeerde string compares wel ja. Maar een postcode bestaat uit 4 chars, dus 32 bits, en die kun je dus prima in 1 keer comparen net zo snel als je een int kan comparen.

Bijvoorbeeld door ze naar int te converteren En dit is C#, dus pointer-trucjes om de 4 characters als integer te interpreteren gaan niet werken.

[ Voor 30% gewijzigd door MBV op 16-08-2012 10:32 ]

[.oisyn]

MBV schreef op donderdag 16 augustus 2012 @ 10:31:
[...]

Als je ergens een functie van maakt, moet je hem zodanig maken dat hij in een andere context ook werkt (IMHO)

Ik ben het totaal niet eens met deze stelling.

Waarom zou je er anders een functie van maken?

Bijvoorbeeld omdat je 'm meerdere keren aanroept binnen dezelfde context. Maar ik begrijp dus dat jij dan liever ziet dat de implementatie van isInt() 4x herhaald wordt in ConvertString()

MBV schreef op donderdag 16 augustus 2012 @ 10:31:
Bijvoorbeeld door ze naar int te converteren

Right. Aftrekken, vermenigvuldigen, optellen (x 4)

En dit is C#, dus pointer-trucjes om de 4 characters als integer te interpreteren gaan niet werken.

En gewoon de charcodes in een int shiften kan natuurlijk niet.

[ Voor 39% gewijzigd door .oisyn op 16-08-2012 10:36 ]

[xPhantom]

Int32.TryParse(PostalCode.Substring(0,4));
Zou in principe toch ook wel gewoon moeten werken lijkt me? Dan kun je aan de hand van de boolean altijd nog bepalen om verder te gaan of niet.

[Hydra]

.oisyn schreef op donderdag 16 augustus 2012 @ 10:32:
En gewoon de charcodes in een int shiften kan natuurlijk niet.

Is dat niet stiekem eigenlijk gewoon hetzelfde als die 4 cijfers gewoon naar een int te converteren?

En ik ben wel benieuwd naar je string compare van 4 characters die net zo efficient is als een int compare eigenlijk.

xPhantom schreef op donderdag 16 augustus 2012 @ 10:34:
Int32.TryParse(PostalCode.Substring(0,4));
Zou in principe toch ook wel gewoon moeten werken lijkt me? Dan kun je aan de hand van de boolean altijd nog bepalen om verder te gaan of niet.

Niks tryparse. Zeker weten dat je postcode goed geformat is en dan als string in je DB opslaan. Als je er dan ergens een int van moet maken is dat prima, maar dan weet je wel zeker dat je alle data hebt en dat deze ook correct is.

[ Voor 40% gewijzigd door Hydra op 16-08-2012 10:45 ]

[CMG]

Matis schreef op donderdag 16 augustus 2012 @ 10:30:
Waarom een regex? trim (links rechts en intern), strlen == 6, substr(0,4) en dan tryparse

Er zijn altijd mensen die een spatie tussen cijfers en letters gedeelte van een postcode typen. Om hier flexibel mee om te gaan zijn regexes perfect.

Matis schreef op donderdag 16 augustus 2012 @ 10:30:
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

Als je regexes moet googlen dan heb je gelijk, als je ze zelf kunt schrijven zijn ze uitermate powerfull... en iets zegt me dat jij ze moet googlen, anders had je die comment nooit gemaakt.

[Orwell]

Nouja, je CPU vindt het geen probleem om gehele DWORD's in één keer te comparen hoor.

Ja, wat oisyn dus vertelt hieronder.

[ Voor 19% gewijzigd door Orwell op 16-08-2012 10:45 ]

[.oisyn]

Hydra schreef op donderdag 16 augustus 2012 @ 10:43:
[...]


Is dat niet stiekem eigenlijk gewoon hetzelfde als die 4 cijfers gewoon naar een int te converteren?

En ik ben wel benieuwd naar je string compare van 4 characters die net zo efficient is als een int compare eigenlijk.

C++:

int strcmp4(char a[4], char b[4])
{
    return *(int*)a - *(int*)b;
}

[Hydra]

.oisyn schreef op donderdag 16 augustus 2012 @ 10:45:

C++:

int strcmp4(char a[4], char b[4])
{
    return *(int*)a - *(int*)b;
}

En nu in Java of .net?

Orwell schreef op donderdag 16 augustus 2012 @ 10:45:
Nouja, je CPU vindt het geen probleem om gehele DWORD's in één keer te comparen hoor.

Ja, wat oisyn dus vertelt hieronder.

Ik had het expliciet over array lookups. Een postcode omgezet naar een int kan je gewoon als array index gebruiken. Dat kan niet met zo'n dword. Postcode 3500 is int value 1398100048.

[ Voor 48% gewijzigd door Hydra op 16-08-2012 10:49 ]

[.oisyn]

Daar ging het niet om.

[CMG]

Hydra schreef op donderdag 16 augustus 2012 @ 10:45:
[...]
En nu in Java of .net?

Dit kan ook in C# met unsafe code

[Matis]

Hydra schreef op donderdag 16 augustus 2012 @ 10:45:
En nu in Java of .net?

C# bij voorkeur, net als in het initiële slechte programmeervoorbeeld.

[Hydra]

.oisyn schreef op donderdag 16 augustus 2012 @ 10:46:
Daar ging het niet om.

Als Java of .Net programmeur gaat het daar wel om, en het voorbeeld was vrij overduidelijk C#. Dat je in C++ creatief kunt goochelen met pointers is leuk maar daar heb je in managed omgevingen niet zo veel aan.

CMG schreef op donderdag 16 augustus 2012 @ 10:46:
Dit kan ook in C# met unsafe code

Tuurlijk. In Java zou je dit ook via JNI in een aparte DLL aan kunnen roepen. Maar als je dat echt zou doen zou je wat mij betreft strafrechtelijk geexecuteerd moeten worden

CMG schreef op donderdag 16 augustus 2012 @ 10:44:
Als je regexes moet googlen dan heb je gelijk, als je ze zelf kunt schrijven zijn ze uitermate powerfull... en iets zegt me dat jij ze moet googlen, anders had je die comment nooit gemaakt.

Het is gewoon onnodig en inefficient om een regex te gebruiken als je al weet dat je alleen de eerste 4 characters naar een int om moet zetten en al zeker weet dat het 4 cijfers zijn. Regexes zijn prima voor validatie maar dan wel bij de user invoer en niet willekeurig verspreid in de code voor zaken die veel simpeler op te lossen zijn.

[ Voor 32% gewijzigd door Hydra op 16-08-2012 10:53 ]

[Orwell]

Over dat initiële voorbeeld dan nog een keertje. Bestaat er niet zoiets als printf/sscanf in C#? Delphi heeft de scanversies ook al niet (da's flink kut). Je zou het dan zo kunnen fixen:

C:

#include <stdio.h>

const char* test = "1234fuu";

bool IsInt(const char* in) {
    int result = 0;
    return (sscanf(test,"[^\n]",&result) == 1);
}

int main() {
    int result = 0;
    if(IsInt(test)) {
        printf("int!\n");
    } else {
        printf("geen int!\n");
    }
    return 0;
}

[MBV]

.oisyn schreef op donderdag 16 augustus 2012 @ 10:32:
[...]

Ik ben het totaal niet eens met deze stelling.

Hmm, zal ik hem eens herformuleren? Als je ergens een functie van maakt, en je kan hem met minimale inspanning generiek bruikbaar maken, zal ik dat altijd doen, en anders komt er een grote waarschuwende comment boven met de pre-condities.

[...]

Bijvoorbeeld omdat je 'm meerdere keren aanroept binnen dezelfde context. Maar ik begrijp dus dat jij dan liever ziet dat de implementatie van isInt() 4x herhaald wordt in ConvertString()

Nou, nee, ik zou liever zien dat ze de in de taal ingebouwde conversie gebruiken (Int.Parse), dan heb je die hele functie niet nodig.

En gewoon de charcodes in een int shiften kan natuurlijk niet.

Dan heb je ze alsnog geconverteerd naar int, maar dan met je eigen hack. Lekker handig, gebruik dan Int.Parse. Ik mag hopen dat ze daar ook wel hebben nagedacht over een snelle implementatie.

CMG schreef op donderdag 16 augustus 2012 @ 10:44:
[...]

Als je regexes moet googlen dan heb je gelijk, als je ze zelf kunt schrijven zijn ze uitermate powerfull... en iets zegt me dat jij ze moet googlen, anders had je die comment nooit gemaakt.

Ik kan best goed regexes schrijven, maar het nadeel is dat het write-only code is.

.oisyn schreef op donderdag 16 augustus 2012 @ 10:46:
Daar ging het niet om.

Daar gaat het wel om: in een interpreted taal kan je dat soort trucjes niet uithalen.

Orwell schreef op donderdag 16 augustus 2012 @ 10:51:
Over dat initiële voorbeeld dan nog een keertje. Bestaat er niet zoiets als printf/sscanf in C#? Delphi heeft de scanversies ook al niet (da's flink kut). Je zou het dan zo kunnen fixen:

Java EN C# hebben daar standaard functies voor. In C# is dat Int.TryParse(String, out value), of Int.Parse die een exception gooit als het niet geparsed kan worden.

[ Voor 12% gewijzigd door MBV op 16-08-2012 10:53 ]

[.oisyn]

MBV schreef op donderdag 16 augustus 2012 @ 10:51:
Dan heb je ze alsnog geconverteerd naar int, maar dan met je eigen hack. Lekker handig, gebruik dan Int.Parse. Ik mag hopen dat ze daar ook wel hebben nagedacht over een snelle implementatie.

Het hele converteren naar int was een hack, weetjenog? Dat deed je omdat je de compares sneller wilde maken. Als dát je drijfveer is, dan kun je de conversie zelf ook sneller maken.

Bijvoorbeeld:

C#:

int Hash(string zip)
{
    [StructLayout(LayoutKind.Explicit)]
    struct data
    {
        [FieldOffset(0)]
        public byte b0;

        [FieldOffset(1)]
        public byte b1;

        [FieldOffset(2)]
        public byte b2;

        [FieldOffset(3)]
        public byte b3;

        [FieldOffset(0)]
        public short i;
    }
    
    data d = new data { (byte)zip[0], (byte)zip[1], (byte)zip[2], (byte)zip[3] };
    return d.i;
}

niet getest, er kunnen wel wat syntaxfouten in zitten maar you get the point.

MBV schreef op donderdag 16 augustus 2012 @ 10:51:
Daar gaat het wel om: in een interpreted taal kan je dat soort trucjes niet uithalen.

Ik hoop dat je beseft dat het geen drol met "interpretedness" te maken heeft.

[ Voor 70% gewijzigd door .oisyn op 16-08-2012 10:54 ]

[Hydra]

.oisyn schreef op donderdag 16 augustus 2012 @ 10:52:
Ik hoop dat je beseft dat het geen drol met "interpretedness" te maken heeft.

Nu zit je te naggen op futiliteiten. Je snapt ook best wat 'ie bedoelt, ondanks dat hij het verkeerd formuleerde.

[MBV]

.oisyn schreef op donderdag 16 augustus 2012 @ 10:52:
[...]

Ik hoop dat je beseft dat het geen drol met "interpretedness" te maken heeft.

Nee, het was een constatering. In de meeste interpreted languages is het niet mogelijk, in veel 'native' talen wel.

En of het er iets mee te maken heeft: denk het wel. Als je ervan uit gaat dat char[4] hetzelfde is als int32, dan kan je de code al niet meer uitvoeren op een powerPC.

[Hydra]

Orwell schreef op donderdag 16 augustus 2012 @ 10:51:
Over dat initiële voorbeeld dan nog een keertje. Bestaat er niet zoiets als printf/sscanf in C#?

Tuurlijk. Het eerste voorbeeld was ook gewoon bagger. Niet in de laatste plaats omdat input validatie en 'dingen-met-je-data-doen' gewoon compleet losstaan van elkaar. Je systeem zou zo in elkaar moeten zitten dat je zeker weet dat alles wat in je DB zit valid postcodes zijn.

[.oisyn]

MBV schreef op donderdag 16 augustus 2012 @ 10:55:
[...]

Nee, het was een constatering. In de meeste interpreted languages is het niet mogelijk, in veel 'native' talen wel.

C# en Java zijn net zo "interpreted" als C++. En C# heeft gewoon support voor pointers.

En of het er iets mee te maken heeft: denk het wel. Als je ervan uit gaat dat char\[4] hetzelfde is als int32, dan kan je de code al niet meer uitvoeren op een powerPC.

Eigenlijk werkt de code alleen op een big-endian architectuur als een PowerPC, maar dat zag gelukkig niemand

Hydra schreef op donderdag 16 augustus 2012 @ 10:54:
[...]


Nu zit je te naggen op futiliteiten. Je snapt ook best wat 'ie bedoelt, ondanks dat hij het verkeerd formuleerde.

Het feit dat ik die reactie plaats wil niet zeggen dat ik tegen de rest van zijn post inga. Daarvoor zul je naar mijn edit moeten kijken.

[ Voor 120% gewijzigd door .oisyn op 16-08-2012 11:01 ]

[Mormeldier]

Volgens mij zijn chars in .NET toch 2 bytes per stuk?

[Orwell]

...

[ Voor 98% gewijzigd door Orwell op 16-08-2012 11:01 ]

[Hydra]

.oisyn schreef op donderdag 16 augustus 2012 @ 10:56:
Het feit dat ik die reactie plaats wil niet zeggen dat ik tegen de rest van zijn post inga. Daarvoor zul je naar mijn edit moeten kijken.

Die edit stond er nog niet toen ik reageerde

Mormeldier schreef op donderdag 16 augustus 2012 @ 10:57:
Volgens mij zijn chars in .NET toch 2 bytes per stuk?

Maakt niet uit AFAIK, als je 'a' naar byte converteert krijg je daarin netjes de ASCII waarde. Het is wel ronduit ranzig programmeren maargoed. Het is bovendien niet efficienter aangezien je voor elke compare 4 casts aan het doen bent en bovendien een nieuw object aanmaakt.

[.oisyn]

Als je in zo'n kuttaal^* werkt dan moet je het natuurlijk ook niet voor elke compare gaan doen. En nieuwe objecten aanmaken was tegenwoordig toch niet meer zo'n probleem? In C# maak je die dingen bovendien gewoon op de stack.


^*

[ Voor 47% gewijzigd door .oisyn op 16-08-2012 11:09 ]

[Caelorum]

C# een kuttaal?

*Snel ninja-editen he!*

[ Voor 47% gewijzigd door Caelorum op 16-08-2012 11:09 ]

[.oisyn]

Nee Java. Ik dacht aan het "nieuw object aanmaken".

[ Voor 70% gewijzigd door .oisyn op 16-08-2012 11:10 ]

[Hydra]

.oisyn schreef op donderdag 16 augustus 2012 @ 11:08:
Als je in zo'n kuttaal^* werkt dan moet je het natuurlijk ook niet voor elke compare gaan doen. En nieuwe objecten aanmaken was tegenwoordig toch niet meer zo'n probleem? In C# maak je die dingen bovendien gewoon op de stack.

Dat nieuwerwetse geneuzel is ook niet te behappen voor ouwe C++-rotten he

[Davio]

Slecht programmeervoorbeeld:

Een collega heeft een 'handige' klasse gemaakt met allemaal constanten (zou eventueel een enum kunnen zijn, maar het zijn er nogal wat), omdat er gebeurteniscodes zijn voor specifieke gebeurtenissen.

De gebeurtenis "aanzetten" heeft bijvoorbeeld code "A001" (door externen opgelegd).

Dan krijg je informatieve dingen als:

C#:

public const string GebeurteniscodeA001 = "A001";
// Wel met de handige comment: Aanzetten van de computer

// Ik zie dan toch liever
public const string Aanzetten = "A001";

[Mormeldier]

Hydra schreef op donderdag 16 augustus 2012 @ 11:03:
[...]

Maakt niet uit AFAIK, als je 'a' naar byte converteert krijg je daarin netjes de ASCII waarde. Het is wel ronduit ranzig programmeren maargoed. Het is bovendien niet efficienter aangezien je voor elke compare 4 casts aan het doen bent en bovendien een nieuw object aanmaakt.

Volgens mij gaat die inderdaad goed zolang je binnen de ASCII character set blijft. Maar volgens de C# language specification krijg je met andere karakters een System.OverflowException. Met unchecked code neemt is de hogere bits gewoon niet mee en is je resultaat dus ook niet echt voorspelbaar.

Bron: http://go.microsoft.com/fwlink/?LinkId=199552 6.2.1 Explicit numeric conversions

[Hydra]

Davio schreef op donderdag 16 augustus 2012 @ 11:17:
Slecht programmeervoorbeeld:

Een collega heeft een 'handige' klasse gemaakt met allemaal constanten (zou eventueel een enum kunnen zijn, maar het zijn er nogal wat), omdat er gebeurteniscodes zijn voor specifieke gebeurtenissen.

De gebeurtenis "aanzetten" heeft bijvoorbeeld code "A001" (door externen opgelegd).

Dan krijg je informatieve dingen als:

C#:

public const string GebeurteniscodeA001 = "A001";
// Wel met de handige comment: Aanzetten van de computer

// Ik zie dan toch liever
public const string Aanzetten = "A001";

Dat is volgens mij een bekende antipattern. Heb ooit ook ruzie lopen maken met een collega dat 'magic numbers' als 1234 in de code niet de bedoeling waren, dus hij maakte er dan overal public const int Nummer1234 = 1234 van

[.oisyn]

Mormeldier schreef op donderdag 16 augustus 2012 @ 11:17:
[...]


Volgens mij gaat die inderdaad goed zolang je binnen de ASCII character set blijft. Maar volgens de C# language specification krijg je met andere karakters een System.OverflowException. Met unchecked code neemt is de hogere bits gewoon niet mee en is je resultaat dus ook niet echt voorspelbaar.

Bron: http://go.microsoft.com/fwlink/?LinkId=199552 6.2.1 Explicit numeric conversions

Allemaal leuk en aardig, maar het ging om de cijfers van een postcode. Die vallen, ook in UTF-16, allemaal binnen 1 byte.

[MBV]

.oisyn schreef op donderdag 16 augustus 2012 @ 10:56:
[...]

C# en Java zijn net zo "interpreted" als C++. En C# heeft gewoon support voor pointers.

Que? C# -> MSIL = Interpreted Language, Java -> java bytecode = interpreted language. In zowel Java als C# is alles een pointer op int, char, byte, double en nog een paar van dat soort types na. Maar dat wil niet zeggen dat ze support hebben voor pointer operaties: je kan niet de 4 chars die in een char-array staan achter elkaar plakken zonder ze met de array-operator eruit te halen, zoals in C/C++ met reinterpret-cast (C-style cast == reinterpret cast in dit geval).

[...]
Eigenlijk werkt de code alleen op een big-endian architectuur als een PowerPC, maar dat zag gelukkig niemand

Voor string-comparison werkt het stiekem op allebei de architecturen, maar dat zag jij gelukkig niet

[...]

Het feit dat ik die reactie plaats wil niet zeggen dat ik tegen de rest van zijn post inga. Daarvoor zul je naar mijn edit moeten kijken.

Ah, ninja-edit. Converteren van het getal-gedeelte van een postcode naar een int is een hack?

.oisyn schreef op donderdag 16 augustus 2012 @ 11:09:
Nee Java. Ik dacht aan het "nieuw object aanmaken".

Die maak je net zo goed aan voor C#. En inderdaad: short-lived objects zijn niet zo'n drama meer, sterker nog: het wordt aangeraden om met read-only objecten te werken, zoals String.

---

Slecht programmeervoorbeeld: we gebruiken hier een tool om statemachines te tekenen, die daar code van maakt. Daar zit ook een soort van programmeertaal in die naar C wordt geconverteerd. Daar zitten weer een soort-van enums in, die naar een rijtje defines worden geconverteerd.

C:

#define WHATEVER_NONE 1
#define WHATEVER_SOMETHING 2
#define WHATEVER_UNINITIALIZED -1

Ergens wordt daar handgeschreven code aangeroepen, die als eerste dit heeft:

C++:

enum {NONE, SOMETHING, UNINITIALIZED} whatever;

void call_from_statemachine(int n)
{
  whatever value = (whatever)n;
}

En nu komt de grap: in de nieuwe versie van de tool worden de volgordes van de enums veranderd... Daar gaan we dus even een stokje voor steken, geen zin om door alle handgeschreven code op zoek te gaan naar impliciete aannames over de waardes van enums.

[ Voor 3% gewijzigd door MBV op 16-08-2012 11:28 ]

[Davio]

Hydra schreef op donderdag 16 augustus 2012 @ 11:23:
[...]


Dat is volgens mij een bekende antipattern. Heb ooit ook ruzie lopen maken met een collega dat 'magic numbers' als 1234 in de code niet de bedoeling waren, dus hij maakte er dan overal public const int Nummer1234 = 1234 van

Ach, ik snap het nog wel bij magic strings, als ik 20 DllImports moet doen, zet ik gewoon bovenin de klasse de naam van de DLL, bijvoorbeeld:

C#:

internal static class NativeMethods
{
    private const string kernel32Dll = "kernel32.dll";

    [DllImport(kernel32Dll, SetLastError = true)]
    internal static extern bool SetSystemTime(ref systemTime); 

    [DllImport(kernel32Dll, SetLastError = true)]
    internal static extern bool SetLocalTime(ref systemTime);
}

Dan heb ik in ieder geval een beetje compile time checking ipv runtime.

[.oisyn]

MBV schreef op donderdag 16 augustus 2012 @ 11:27:
Que? C# -> MSIL = Interpreted Language, Java -> java bytecode = interpreted language.

C++ -> LLVM -> interpreted language
C# -> x86 -> native language.
De taal zegt niets over waar het naartoe gecompileerd wordt. De kern van de zaak is of de taal pointers danwel herinterpretatie van de data (zoals bijv. met unions) toelaat.

Een geïnterpreteerde taal zie ik als een taal die typisch van source-niveau geïnterpreteerd wordt, waardoor je dus ook op sourceniveau die interpretatie kan manipuleren (denk aan variabele variabelnamen en dingen als eval()).

Maar dat wil niet zeggen dat ze support hebben voor pointer operaties: je kan niet de 4 chars die in een char-array staan achter elkaar plakken zonder ze met de array-operator eruit te halen, zoals in C/C++ met reinterpret-cast (C-style cast == reinterpret cast in dit geval).

In C# kan dat gewoon. C# ondersteunt gewoon native pointers. Je assembly is dan weliswaar niet meer pure.

Voor string-comparison werkt het stiekem op allebei de architecturen, maar dat zag jij gelukkig niet

Beweer je nou dat ik niet doorhad dat een string compare altijd goed gaat?

Ah, ninja-edit. Converteren van het getal-gedeelte van een postcode naar een int is een hack?

Ja, het feit dat je die conversie doet is een hack. Net zoals het converteren van telefoonnummer of bankrekeningnummers naar int. Die dingen zijn geen getallen, het zijn tekenreeksen bestaande uit cijfers.

Die maak je net zo goed aan voor C#

Een struct in C# is niet duurder dan een primitive en totaal iets anders dan het aanmaken van een class instance.

[ Voor 11% gewijzigd door .oisyn op 16-08-2012 11:44 ]

[CMG]

Wat een stukje slechte postcode code al niet te weeg kan brengen he?

[Davio]

Je kan in C# pointers gebruiken, dan moet je wel compileren met /unsafe.

[RaZ]

Je bedoelt het stukje postcode-check wat kant nog wal raakt.

Er wordt enkel naar de format gekeken, en niet of die postcode kan bestaan of niet. In Nederland beginnen postcode niet met een 0, dus een pure check of de eerst 4 characters nummeriek zijn, is een check die nergens op slaat.

Dan kom je nog op het punt van de letters die niet gebruikt worden, en diverse combinaties die niet gebruikt worden.

Ik ben geen programmeerheld, maar m'n eigen postcode-check routine die ik in VBA geschreven heb jaren terug, vangt dat soort dingen dan wel weer af. Maar dit komt omdat ik toen op m'n werk dagelijks met idioot grote adressenbestanden heb gewerkt om mailings en anders drukwerk te kunnen adressen.

En omdat elke klant een ander format aanleverd, heb je de ene keer 6 characters en de andere keer 7, en soms al helemaal geen appart postcode-veld. Die mocht ik dan weer vrolijk uit het plaatsnaam veld halen. Soms wel lastig met belgische postcodes. Want de eerst 7 characters uit een belgische plaatsnaam waar de postcode in zit, krijg je een perfecte nederlands postcode terug. De eerst 7 characters van "1000 BRUSSEL" levert "1000 BR" op.

[CMG]

Er zijn gewoon open source CSV bestanden die zelf compiled zijn door gebruikers die erg goed zijn. Heb die zelf omgezet naar een .NET relationeel data model voor dit soort doeleinden



Kun je ook meteen de gemeente en zo vermelden in je front-end.

[Davio]

Altijd leuk, klooien met adressen:

quote: WP

In Lelystad heeft een hele wijk een naam en zijn de straten genummerd. Is het adres Gondel 26-95, ook geschreven als Gondel 2695), dan is dat: wijk Gondel, straat 26 (ook te interpreteren als: straat Gondel 26), huis 95. Het eigenlijke huisnummer is 95, en niet zoals mogelijk gedacht zou kunnen worden 26-95 of 2695.

[Hydra]

CMG schreef op donderdag 16 augustus 2012 @ 11:53:
Er zijn gewoon open source CSV bestanden die zelf compiled zijn door gebruikers die erg goed zijn. Heb die zelf omgezet naar een .NET relationeel data model voor dit soort doeleinden

Voor een paar K heb je zo'n database. Voor bedrijven loont het niet zulke zaken zelf te bouwen. Komt bij dat die 'open source' CSVs nogal outdated zijn.

[Grijze Vos]

CMG schreef op donderdag 16 augustus 2012 @ 11:53:
[...]

Kijk eens naar RSGB.

[CMG]

Hydra schreef op donderdag 16 augustus 2012 @ 12:50:
[...]


Voor een paar K heb je zo'n database. Voor bedrijven loont het niet zulke zaken zelf te bouwen. Komt bij dat die 'open source' CSVs nogal outdated zijn.

Heb mijn tool dan ook te koop gezet voor 399 euro voor bedrijven die het zelf niet willen ontwikkelen/tijd besparen. Toch goedkoper dan de 2500+ die tnt zich rekend, maar goed, gaat beetje off-topic zo.

[Hydra]

CMG schreef op donderdag 16 augustus 2012 @ 13:03:
Heb mijn tool dan ook te koop gezet voor 399 euro voor bedrijven die het zelf niet willen ontwikkelen/tijd besparen. Toch goedkoper dan de 2500+ die tnt zich rekend, maar goed, gaat beetje off-topic zo.

Ik zie alleen een database die een beetje ITer in no time in elkaar kan zetten. De data is wat geld kost, jij biedt geen data aan maar opensource data die niet up to date is en is gebaseerd op wat 'vrijwilligers' ofzo invoeren.

Komt bij dat veel klanten afstanden over de weg willen in plaats van hemelsbreed, dat maakt ook nogal uit.

[PiepPiep]

Ik zit nog te twijfelen hoe ik die postcode zou checken op 4 nummertjes.
Manier 1 is dat ik een tabel in een database zou maken met alle mogelijke nummers en dan een select zou doen en checken of ik iets terug krijg.
Manier 2 is vergelijkbaar, maar dan maak ik in het geheugen een block van 4GB aan en vul ik die bytes met 0 of 1 of het wel of niet een geldige code is, vervolgens gebruik ik die 4 bytes als 1 long pointer binnen dat blok.

*zoekt dekking*

[CMG]

Hydra schreef op donderdag 16 augustus 2012 @ 13:06:
[...]


Ik zie alleen een database die een beetje ITer in no time in elkaar kan zetten. De data is wat geld kost, jij biedt geen data aan maar opensource data die niet up to date is en is gebaseerd op wat 'vrijwilligers' ofzo invoeren.

Komt bij dat veel klanten afstanden over de weg willen in plaats van hemelsbreed, dat maakt ook nogal uit.

Klopt niet helemaal; er is een open source set van CSV's die regelmatig bijgewerkt wordt. Wat ik gedaan heb is deze platte data omgezet naar een datamodel waardoor je die data zo optimala mogelijk kan gebruiken. Zo iets maken kost tijd (en dus geld).

Voor navigatie is het inderdaad niet geschikt, maar in de meeste gevallen vinden mensen het interessant welke locaties binnen een straal van locatie X liggen, daar is dit prima voor.

Als je een DB wilt hebben die ook afstanden over wegen kan berekenen, ben je veel en veel meer geld kwijt dan die 2500 van TNT.

[CMG]

PiepPiep schreef op donderdag 16 augustus 2012 @ 13:10:
Ik zit nog te twijfelen hoe ik die postcode zou checken op 4 nummertjes.
Manier 1 is dat ik een tabel in een database zou maken met alle mogelijke nummers en dan een select zou doen en checken of ik iets terug krijg.
Manier 2 is vergelijkbaar, maar dan maak ik in het geheugen een block van 4GB aan en vul ik die bytes met 0 of 1 of het wel of niet een geldige code is, vervolgens gebruik ik die 4 bytes als 1 long pointer binnen dat blok.

*zoekt dekking*

Als je Manier 2 netjes weghaalt hoeft je niet meteen dekking te zoeken

Wat wil je eigenlijk precies doen?

[PiepPiep]

Ik liep wat achter met lezen wat er in dit topic geleest was.
Paar pagina's terug ging het over een postcode controle.

[CodeCaster]

.oisyn schreef op donderdag 16 augustus 2012 @ 11:26:
[...]

Allemaal leuk en aardig, maar het ging om de cijfers van een postcode. Die vallen, ook in UTF-16, allemaal binnen 1 byte.

Twee.

quote: http://en.wikipedia.org/wiki/UTF-16

The first plane (code points U+0000 to U+FFFF) contains the most frequently used characters and is called the Basic Multilingual Plane or BMP. Both UTF-16 and UCS-2 encode code points in this range as single 16-bit code units that are numerically equal to the corresponding code points.

Edit: ok, witty reply was unwitty.

[ Voor 3% gewijzigd door CodeCaster op 16-08-2012 13:54 ]

[CMG]

PiepPiep schreef op donderdag 16 augustus 2012 @ 13:19:
Ik liep wat achter met lezen wat er in dit topic geleest was.
Paar pagina's terug ging het over een postcode controle.

Maar wat wil je precies doen? Valideren dat het een geldige postcode is? Dat het een geldig postcode formaat is? Wat wil je doen met de postcode?

[Hydra]

CMG schreef op donderdag 16 augustus 2012 @ 13:10:
Klopt niet helemaal; er is een open source set van CSV's die regelmatig bijgewerkt wordt.

Dat is het probleem dus. Die open source sets zijn gewoon niet 100% actueel. En voor een professionele website wil je niet dat iemand een bestaande postcode invoert die jij dan niet kent. Die 'dure' tabellen zijn (AFAIK) op kadasterdata gebaseerd en up to date.

Als je een DB wilt hebben die ook afstanden over wegen kan berekenen, ben je veel en veel meer geld kwijt dan die 2500 van TNT.

Nee hoor:
http://www.postcode.nl/index/156/1/0/drive-time-matrix.html

En 1000E is redelijk peanuts voor een webapplicatie waar sowieso flink wat geld in de ontwikkeling gaat zitten. (Die 1000E is minder dan een dag van mijn consultancytarief). En voor kleine websites gaan ze denk ik geen 399E neerleggen voor een simpele database die iedere developer kan bouwen.

Maargoed. Ieder z'n ding en ik hoop van harte voor je dat je er wat aan verdient

[CMG]

CodeCaster schreef op donderdag 16 augustus 2012 @ 13:22:
[...]

Twee.

[...]

Hij snapt ook wel dat 16-bits twee bytes zijn. Hij bedoelt alleen dat [a-zA-Z0-9] overeind blijft als je het naar char (1 byte) cast

[Hydra]

PiepPiep schreef op donderdag 16 augustus 2012 @ 13:19:
Ik liep wat achter met lezen wat er in dit topic geleest was.
Paar pagina's terug ging het over een postcode controle.

Ik neem aan dat je een geintje maakte met die 2e optie?

Je kunt het in de DB doen of met een gesorteerde lijst in je applicatie. De eerste is makkelijker te onderhouden, de 2e is wat sneller omdat je geen DB roundtrip nodig hebt.

[CodeCaster]

CMG schreef op donderdag 16 augustus 2012 @ 13:23:
[...]


Hij snapt ook wel dat 16-bits twee bytes zijn. Hij bedoelt alleen dat [a-zA-Z0-9] overeind blijft als je het naar char (1 byte) cast

Dan moet 'ie dat zeggen, want zeggen dat een Westers getal in UTF-16 één byte groot is klopt gewoon niet.

@Hydra: ik héb dit topic gelezen hoor, wellicht was de formulering wat onhandig.

[ Voor 17% gewijzigd door CodeCaster op 16-08-2012 13:38 ]

[Hydra]

CodeCaster schreef op donderdag 16 augustus 2012 @ 13:27:
Dan moet 'ie dat zeggen, want zeggen dat een Westers getal in UTF-16 één byte groot is klopt gewoon niet.

Dat zegt 'ie ook gewoon helemaal niet. Als je gewoon het topic had gelezen had je dat wel uit de context meegekregen.

[CMG]

Hydra schreef op donderdag 16 augustus 2012 @ 13:22:
[...]
Dat is het probleem dus. Die open source sets zijn gewoon niet 100% actueel. En voor een professionele website wil je niet dat iemand een bestaande postcode invoert die jij dan niet kent. Die 'dure' tabellen zijn (AFAIK) op kadasterdata gebaseerd en up to date.
[...]
Nee hoor:
http://www.postcode.nl/index/156/1/0/drive-time-matrix.html

En 1000E is redelijk peanuts voor een webapplicatie waar sowieso flink wat geld in de ontwikkeling gaat zitten. (Die 1000E is minder dan een dag van mijn consultancytarief). En voor kleine websites gaan ze denk ik geen 399E neerleggen voor een simpele database die iedere developer kan bouwen.

Maargoed. Ieder z'n ding en ik hoop van harte voor je dat je er wat aan verdient

Ik begrijp je punt heel goed en ik heb ook nooit beweerd dat dit de beste oplossing is, maar zoals je zelf ook zult weten, zijn er genoeg bedrijven waar alles zo goedkoop mogenlijk moet en dat ze dan een aantal nieuwbouw wijken niet direct kunnen ondersteunen boeit dan niet zoveel (laag percentage).

Ik vond het prijspunt wel goed voor mijn doelgroep. Heb het nog nooit verkocht, promoot het verder ook niet (behalve hier omdat het toevallig over postcodes ging) en verwacht ook niet dat het (veel) verkocht zal worden. Heb het ooit voor mezelf gemaakt en had zo iets van: als iemand anders het zelfde wilt doen, is het wellicht handig voor iemand anders.

De Drive Time Matrix (DTM) is een tabel met de reistijden en -afstanden tussen de 4 Positie Postcodegebieden (4PP).

Dit is natuurlijk nog steeds een grove benadering met redelijke afwijking...

[Davio]

Ach, als je wilt weten welke IKEA het dichtste in de buurt is, zal het wel handig zijn.

[CMG]

Davio schreef op donderdag 16 augustus 2012 @ 13:30:
Ach, als je wilt weten welke IKEA het dichtste in de buurt is, zal het wel handig zijn.

Dat kan ook met die OS data; per C6PP (dus nauwkeuriger dan de C4PP) heb je een lat/long die je kunt vergelijke met elkaar.

Grijze Vos schreef op donderdag 16 augustus 2012 @ 12:56:
Kijk eens naar RSGB.

Wel grappig; als ik kijk naar

http://bag.vrom.nl/ufc/fi...kening_en_adressering.pdf

op pagina 6, wordt verwezen naar een domein dat inmiddels 'te koop' staat... lekker handig.

Heb gezocht, maar weinig concreets kunnen vinden er over.

[ Voor 41% gewijzigd door CMG op 16-08-2012 13:33 ]

[Hydra]

CMG schreef op donderdag 16 augustus 2012 @ 13:31:
Dat kan ook met die OS data; per C6PP (dus nauwkeuriger dan de C4PP) heb je een lat/long die je kunt vergelijke met elkaar.

Ah, en de afstand hemelsbreed op 6 posities is volgens jou nauwkeuriger dan de drive distance op 4? Niet dus.

[CMG]

Hydra schreef op donderdag 16 augustus 2012 @ 13:34:
[...]
Ah, en de afstand hemelsbreed op 6 posities is volgens jou nauwkeuriger dan de drive distance op 4? Niet dus.

Als we zouden mierenneuken zou ik kunnen zeggen dat hij het had over afstand (welke het dichtste bij is), daarbij is voor ons natuurlijk reistijd relevant, etc. Ik denk iig dat we het er genoeg over gehad hebben, het is duidelijk dat TNT's DB meer up2date is en extra features bied tegen betaling die handig zijn.

[Hydra]

CMG schreef op donderdag 16 augustus 2012 @ 13:40:
[...]

Als we zouden mierenneuken zou ik kunnen zeggen dat hij het had over afstand (welke het dichtste bij is), daarbij is voor ons natuurlijk reistijd relevant, etc. Ik denk iig dat we het er genoeg over gehad hebben, het is duidelijk dat TNT's DB meer up2date is en extra features bied tegen betaling die handig zijn.

Het ging over jouw reactie op die drive time matrix waarvan jij aangaf dat 4 posities onnauwkeurig was. En dat is, in vergelijking met jouw optie om op 6 posities hemelsbreed te rekenen, gewoon niet zo.

Davio schreef op donderdag 16 augustus 2012 @ 13:30:
Ach, als je wilt weten welke IKEA het dichtste in de buurt is, zal het wel handig zijn.

Natuurlijk. Maar voor een bedrijf als ikea zal die paar k peanuts zijn, en is het belangrijker dat ze alle postcodes hebben. Maar voor dat soort sites wil sowieso ook een nette google-maps integratie hebben en kan je ook prima via de google api de long/lat opvragen voor de postcode waarop die persoon zoekt. Heb je helemaal geen database meer nodig.

[ Voor 30% gewijzigd door Hydra op 16-08-2012 13:45 ]

[CMG]

Hydra schreef op donderdag 16 augustus 2012 @ 13:43:
[...]
Het ging over jouw reactie op die drive time matrix waarvan jij aangaf dat 4 posities onnauwkeurig was. En dat is, in vergelijking met jouw optie om op 6 posities hemelsbreed te rekenen, gewoon niet zo.

Je hebt helemaal gelijk

[Soundless]

CMG schreef op donderdag 16 augustus 2012 @ 13:03:
[...]


Heb mijn tool dan ook te koop gezet voor 399 euro voor bedrijven die het zelf niet willen ontwikkelen/tijd besparen. Toch goedkoper dan de 2500+ die tnt zich rekend, maar goed, gaat beetje off-topic zo.

Maar wel duurder dan http://www.geopostcodes.com/netherlands_zip_codes
+ je hebt hem dan ook nog in allerlei db formaten (voor het gemak)

[CMG]

Soundless schreef op donderdag 16 augustus 2012 @ 14:11:
[...]


Maar wel duurder dan http://www.geopostcodes.com/netherlands_zip_codes
+ je hebt hem dan ook nog in allerlei db formaten (voor het gemak)

Dat is dan ook een eenmalige dump i.p.v. programmatuur om je eigen DB up2date te houden

Zou zo iets ook kunnen doen, van: koop een gemaakte DB voor 99 euro. Zou zo iets er ook bij kunnen doen, maar zoals gezegd: ik heb er niet veel moeite voor gedaan om het te verkopen. Wellicht als ik er ooit eens tijd voor heb, dat ik weet een shop opzet met ideal/paypal

[ Voor 0% gewijzigd door CMG op 16-08-2012 14:15 . Reden: het => heb ]

[.oisyn]

CodeCaster schreef op donderdag 16 augustus 2012 @ 13:22:
[...]

Twee.

Ik bedoel dat de encoding van de cijfers in UTF-16 kleiner zijn dan 256, en dus in een byte passen zonder informatie weg te gooien. "Ze vallen binnen een byte" != "ze zijn een byte"

CodeCaster schreef op donderdag 16 augustus 2012 @ 13:27:
[...]

Dan moet 'ie dat zeggen, want zeggen dat een Westers getal in UTF-16 één byte groot is klopt gewoon niet.

Dat heb ik niet gezegd, dat maak jij ervan.

[ Voor 38% gewijzigd door .oisyn op 16-08-2012 14:20 ]

[Hydra]

CMG schreef op donderdag 16 augustus 2012 @ 14:14:
Dat is dan ook een eenmalige dump i.p.v. programmatuur om je eigen DB up2date te houden

Hoe bedoel je up to date te houden? Van gebruikers verwacht je hopelijk niet dat ze met de hand zelf postcodes toe gaan voegen?

En het hele idee van die databases is gewoon dat je periodiek gewoon in een keer de laatste versie inleest.

[CMG]

Hydra schreef op donderdag 16 augustus 2012 @ 14:18:
[...]
Hoe bedoel je up to date te houden? Van gebruikers verwacht je hopelijk niet dat ze met de hand zelf postcodes toe gaan voegen?

En het hele idee van die databases is gewoon dat je periodiek gewoon in een keer de laatste versie inleest.

Ofcource not. het is een commandline tool die van CSV ->DB opbouwt. je kunt nieuwere versies gewoon inlezen als mutaties. Dus, zodra er update beschikbaar is, kun je met commandline applicatie de data inlezen en je DB bijwerken.

[Hydra]

CMG schreef op donderdag 16 augustus 2012 @ 14:20:
Ofcource not. het is een commandline tool die van CSV ->DB opbouwt. je kunt nieuwere versies gewoon inlezen als mutaties. Dus, zodra er update beschikbaar is, kun je met commandline applicatie de data inlezen en je DB bijwerken.

En dat kan met die databases toch ook gewoon?

[CMG]

Als je steeds een nieuwe DB kan downloaden wel; dat kan zeker. Bij die van 100 euro heb je 30 dagen updates, voor 250 euro een jaar. Wil je 2 jaar of meer aan updates, is mijn oplossing al goedkoper

Is trouwens ook erg beperkt in de licentie; zie http://www.geopostcodes.com/license

•Als u software of applicaties verkoopt of zelfs gratis distribueert met gegevens die door Geopostcodes zijn verstrekt.
•Als u op Internet een product aanbiedt dat gedownload kan worden met gegevens die door Geopostcodes zijn geleverd.
•Als u gegevens van GeoPostcodes wilt gebruiken op verschillende Internetsites.
•In het algemeen als u aan derden een product levert dat mogelijk gegevens - zelfs gedeeltelijke gegevens - bevat die afkomstig zijn uit een door GeoPostcodes geleverd bestand.

etc. Dan heb je dus een licentie van 1300 euro voor een jaar nodig. Vind je het nog steeds handiger?

[ Voor 64% gewijzigd door CMG op 16-08-2012 14:27 ]

[Hydra]

CMG schreef op donderdag 16 augustus 2012 @ 14:25:
Als je steeds een nieuwe DB kan downloaden wel; dat kan zeker. Bij die van 100 euro heb je 30 dagen updates, voor 250 euro een jaar. Wil je 2 jaar of meer aan updates, is mijn oplossing al goedkoper

Jouw oplossing is geen oplossing wat die open source spullen zijn niet up to date. Als mensen wel open-source zouden willen gebruiken omdat geld een issue is gaan ze geen 399 euro uitgeven aan een paar tabelletjes; dat kan iedere developer in een paar minuten opzetten. Importeren van CSV data is niet bepaald een 'product', dat kan iedere DB admin tool.

offtopic:
Interessante site trouwens. Ik zou onderstaande stukjes niet op een google CV zetten:

Hi there, my name is Nick Kusters. Born and raised in Maastricht, the Capital City of the most southern province of The Netherlands. I'm currently <%= Math.Floor(Convert.ToDecimal(DateTime.Now.Date.Subtract(DateTime.Parse("1983-04-18")).Days / 365))%> years old, and a programmer by heart. (read more)

CMG schreef op donderdag 16 augustus 2012 @ 14:25:
etc. Dan heb je dus een licentie van 1300 euro voor een jaar nodig. Vind je het nog steeds handiger?

Dat is redelijk marktconform voor dat soort data. De andere optie is 'gratis' data die niet erg up to date is. Die 399 euro die jij vraagt is voor een doodsimpel databaseschema. Als mensen geen 1000E voor up to date postcodedata willen betalen downloaden ze gewoon gratis data en gaan echt geen 399E uitgeven voor dat schema. Waarom zouden ze?

[ Voor 20% gewijzigd door Hydra op 16-08-2012 14:34 ]

[CMG]

Hydra schreef op donderdag 16 augustus 2012 @ 14:32:
[...]


Jouw oplossing is geen oplossing wat die open source spullen zijn niet up to date. Als mensen wel open-source zouden willen gebruiken omdat geld een issue is gaan ze geen 399 euro uitgeven aan een paar tabelletjes; dat kan iedere developer in een paar minuten opzetten. Importeren van CSV data is niet bepaald een 'product', dat kan iedere DB admin tool.

offtopic:
Interessante site trouwens. Ik zou onderstaande stukjes niet op en google CV zetten:

Hi there, my name is Nick Kusters. Born and raised in Maastricht, the Capital City of the most southern province of The Netherlands. I'm currently <%= Math.Floor(Convert.ToDecimal(DateTime.Now.Date.Subtract(DateTime.Parse("1983-04-18")).Days / 365))%> years old, and a programmer by heart. (read more)

Heb de site tijdje geleden veranderd van ASP.NET naar Razor View engine; die staat al een tijd op het lijstje om te veranderen... = ook al hele oude code, had natuurlijk new DateTime(1983,4,18) moeten zijn, maar 6 jaar geleden had ik ook al beter moeten weten

Ik neem aan dat het niet ging om de datum zelf? Die heb jij namelijk ook gewoon in je profiel staan (19 februari 1980)

[ Voor 4% gewijzigd door CMG op 16-08-2012 14:37 ]

[Hydra]

CMG schreef op donderdag 16 augustus 2012 @ 14:36:
Ik neem aan dat het niet ging om de datum zelf? Die heb jij namelijk ook gewoon in je profiel staan (19 februari 1980)

offtopic:
Euh, het is nogal offtopic maar nee. Het gaat erom dat die zichtbare sourcecode met een brakke datumberekening niet erg professioneel staat. Ik vind sowieso die site niet erg professioneel aandoen. Als je ergens gaat werken gaan ze je googlen. IMHO zou die site niet voor je werken.

[alwinuzz]

Dat kan wisselen. Je hebt toch in je vrije tijd een website gemaakt, terwijl anderen daar te beroerd voor zijn.

[CMG]

Hydra schreef op donderdag 16 augustus 2012 @ 14:45:
[...]

offtopic:
Euh, het is nogal offtopic maar nee. Het gaat erom dat die zichtbare sourcecode met een brakke datumberekening niet erg professioneel staat. Ik vind sowieso die site niet erg professioneel aandoen. Als je ergens gaat werken gaan ze je googlen. IMHO zou die site niet voor je werken.

Geen problemen mee gehad tot nu toe en ben daar ook niet bang voor. Zijn meer dan 1000 mensen die dagelijks van mijn site gebruik maken. Het is dan ook mijn persoonlijke site, geen bedrijfs website die professionaliteit zou moeten uitstralen.

Verder houd ik nu op met de Troll te voeren; heeft lang genoeg geduurt zo

[Hydra]

alwinuzz schreef op donderdag 16 augustus 2012 @ 14:47:
Dat kan wisselen. Je hebt toch in je vrije tijd een website gemaakt, terwijl anderen daar te beroerd voor zijn.

M.i. kun je beter geen eigen site hebben dan eentje waar niet de juiste content op staat. Maargoed, ik gaf het hem vooral aan omdat ik stomtoevallig een foutje op z'n site tegenkwam dat niet heel erg profi overkomt, da's alles.

CMG schreef op donderdag 16 augustus 2012 @ 14:52:
Verder houd ik nu op met de Troll te voeren; heeft lang genoeg geduurt zo

Aggus. Je zal ook eens kritiek krijgen. Prima. Daag. Het ging net over postcodes maar jij laat zelf dat onderwerp vallen voor een simpel offtopic stukje over je website waar ik een bug op tegenkwam. En de issue is dus dat je dagen deelt door 365, een jaar heeft geen 365 dagen. .Net kan prima voor je het totaal aantal jaren tussen 2 data uitrekenen. Graag gedaan.

[ Voor 38% gewijzigd door Hydra op 16-08-2012 14:57 ]

[CMG]

Hydra schreef op donderdag 16 augustus 2012 @ 14:53:
Aggus. Je zal ook eens kritiek krijgen. Prima. Daag. Het ging net over postcodes maar jij laat zelf dat onderwerp vallen voor een simpel offtopic stukje over je website waar ik een bug op tegenkwam.

Ook met het Postcode stuk heb ik al 2x gezegd: ik vind de dat de discussie lang genoeg geduurt heeft, je hebt gelijk m.b.t. die en die punten, etc.

je was met je quote trouwens niet helemaal compleet; boven de leeftijd heeft altijd de broncode gestaan:

<span title="Just to show what kind of programmer I am, this is the code behind my age...: Math.Floor(Convert.ToDecimal(DateTime.Now.Date.Subtract(DateTime.Parse("1983-04-18")).Days / 365))">
<%= Math.Floor(Convert.ToDecimal(DateTime.Now.Date.Subtract(DateTime.Parse("1983-04-18")).Days / 365))%></span>

En de issue is dus dat je dagen deelt door 365, een jaar heeft geen 365 dagen. .Net kan prima voor je het totaal aantal jaren tussen 2 data uitrekenen. Graag gedaan.

En ook hier heb je helemaal gelijk in; m.b.t. schrikkeljaren is er een kleine afwijking; jaren uitlezen was absoluut beter geweest. Heb eerder ook al gezegd dat dit inmiddels 6 jaar oude code is die ik nog eens moet aanpassen, maar ik heb zoveel op mijn lijstje staan, dat het echt geen haast heeft.

Zo is er bijvoorbeeld ook een 'Programming' nav stukje dat gewoon een 404 terug geeft, heb ik op een hoop pagina's 'Thompson' in plaats van 'Thomson' staan en moet ik oude artikelen van vroeger weer opnieuw in de DB importeren en nog 300.000 andere dingen

[ Voor 29% gewijzigd door CMG op 16-08-2012 15:02 ]

[cpf_]

CMG schreef op donderdag 16 augustus 2012 @ 14:58:
[...]

je was met je quote trouwens niet helemaal compleet; boven de leeftijd heeft altijd de broncode gestaan:


quote: <span title="Just to show what kind of programmer I am, this is the code behind my age...: Math.Floor(Convert.ToDecimal(DateTime.Now.Date.Subtract(DateTime.Parse("1983-04-18")).Days / 365))">
<%= Math.Floor(Convert.ToDecimal(DateTime.Now.Date.Subtract(DateTime.Parse("1983-04-18")).Days / 365))%></span>

Eigenlijk maakt dat stukje het een pak erger?

[Hydra]

Kerel, ik probeerde alleen maar te helpen. Dit is wat ik krijg in firefox:


Daarnaast is je berekening gewoon fout. Probeert dit maar eens:

code:

Console.WriteLine(Math.Floor(Convert.ToDecimal(new DateTime(2012,4,17).Subtract(new DateTime(1983,4,18)).Days / 365)));

Volgens deze code ben je op 17 april 2012 al 29, terwijl je de 18e jarig bent. Komt nog eens bij dat het me een raadsels is waarom je op die plek de Convert.ToDecimal doet want .Days is gewoon een integer die je door een andere integer deelt, en dat wordt dus sowieso afgekapt.

Dergelijke fouten zijn ernstige indicatoren wat betreft de skills van een programmer. En het zijn fouten die bugs opleveren die lastig te vinden zijn en een flinke impact kunnen hebben.

CMG schreef op donderdag 16 augustus 2012 @ 14:58:
En ook hier heb je helemaal gelijk in; m.b.t. schrikkeljaren is er een kleine afwijking; jaren uitlezen was absoluut beter geweest.

Joh! Een kleine afwijking? Sorry hoor, maar een programmeur die dergelijke basale fouten maakt wil je niet in de buurt van systemen hebben die ook maar iets enigzins belangrijks met data doen. Hoe genant denk je dat het is als een systeem "gefeliciteerd!" mailtjes gaat sturen op verkeerde data? Om het nog maar niet over echt belangrijke zaken als facturaties te hebben.

En doe niet alsof je het door had, je dacht dat ik het over het parsen van een string had in plaats van het delen door 365.

Het zou je sieren als je je excuses voor die Troll comment aan zou bieden. Ik probeerde je te helpen door een fout op je website aan te wijzen die je een sollicitatiegesprek zou kunnen kosten.

[ Voor 35% gewijzigd door Hydra op 16-08-2012 15:19 ]

[CMG]

Hydra schreef op donderdag 16 augustus 2012 @ 15:15:
Kerel, ik probeerde alleen maar te helpen. Dit is wat ik krijg in firefox:
[[url="[img=640,183]http://tweakers.net/ext/f/OH4jAZmqxXIdw9BtCmwqYfjm/full.png[/img]"]afbeelding[/url]]

Daarnaast is je berekening gewoon fout. Probeert dit maar eens:

code:

Console.WriteLine(Math.Floor(Convert.ToDecimal(new DateTime(2012,4,17).Subtract(new DateTime(1983,4,18)).Days / 365)));

Volgens deze code ben je op 17 april 2012 al 29, terwijl je de 18e jarig bent. Komt nog eens bij dat het me een raadsels is waarom je op die plek de Convert.ToDecimal doet want .Days is gewoon een integer die je door een andere integer deelt, en dat wordt dus sowieso afgekapt.

Dergelijke fouten zijn ernstige indicatoren wat betreft de skills van een programmer. En het zijn fouten die bugs opleveren die lastig te vinden zijn en een flinke impact kunnen hebben.

Math.Floor werkt alleen tegen double of decimal, je moet dus expliciet casten naar een van deze twee.

En je overtrekt het zwaar; dit is iets dat ik snel in html getypt heb voor een persoonlijke website; dat zegt niks over hoe ik een scheduling app zou maken.

[Hydra]

CMG schreef op donderdag 16 augustus 2012 @ 15:19:
Math.Floor werkt alleen tegen double of decimal, je moet dus expliciet casten naar een van deze twee.

Je cast een integer naar een decimal om daar Math.floor op aan te roepen. En je begrijpt niet wat hier misgaat?

En je overtrekt het zwaar; dit is iets dat ik snel in html getypt heb voor een persoonlijke website; dat zegt niks over hoe ik een scheduling app zou maken.

*knip*

[ Voor 11% gewijzigd door MueR op 16-08-2012 16:22 ]